E1 R2 - Call from Cisco phone ok to PSTN, but call from Skype fails

[voip7372]

We would like to make it so our users in Brazil can also use their Skype for Business client to make phone calls out to the PSTN. I have the routing setup and the correct calling party and called party digits make it to the router (the PSTN gateway) but once the call hits the E1 R2 circuit, the call from Skype fails. I compared the debug vpm signal output and the calls look the same up to the point where I see a 'htsp_dialing_done' message. After that, the calls look different in the debug and the Skype will will fail after a few seconds.

For the failed Skype call, if I call my mobile number in the US, I sometimes see a ring on my mobile for a split second and then it disappears and in the debug vpm signal output, I see the call closing down.

I'm not very familiar with troubleshooting the vpm signal debugs so if you guys/gals have some experience with this and can spot a clue in the attached debugs for two call examples, please let me know what I should be looking for/troubleshooting. To me, it seems as if something along the line in the Skype call doesn't think the call is actually finished being connected so it tears the call down. Just a guess but I'm not sure.

If you look at the attached Word document, you can view the debugs for the good and bad calls side by side if you change the viewing layout to 'Web Layout' (and assuming your monitor is wide enough also).

Please note that all calls are working fine from Cisco desk phones and CIPC. It's only the Skype calls that are failing and so far it seems like only International and maybe National calls fail as well. I tested the same thing for a Mexico site we have (same type of circuit) and the same thing happens there. I was able to complete a call to a local number in the city where our office is, but a national and international call failed for the Mexico site as well, so I think it's the same behavior for each site and both have E1 R2 circuits.

Also, the exact same type of config (to send a call from Skype for Business out to the PSTN) works fine in our US offices using SIP trunks from the PSTN. Those E1 R2 circuits take forever (by today's standard) to connect a call and start ringing, but it works great, connects quickly and rings quickly using the same config in the US with SIP trunks as the PSTN access. Could this somehow be related to a timer that Skype has and it thinks the call isn't progressing so Skype tears down the call? It does seem to work ok if I call a local number, like I mentioned before. But so far I've not been able to get it working if I call national numbers inside Brazil from the Brazil E1 circuit and it's also not working for international calls.

Here are a few snips of the config in the 3925 related to the E1 circuit. if you needed to see that:

voice call convert-discpi-to-prog
voice rtp send-recv

controller E1 0/0/0
framing NO-CRC4
line-termination 75-ohm
ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani
cas-custom 0
country brazil use-defaults
metering
category 2
answer-signal group-b 1
trunk-group telefonica 1
description Telefonica Voice E1

voice-port 0/0/0:0
translation-profile incoming TP-Incoming
translation-profile outgoing TP-Outgoing
cptone BR

dial-peer voice 51 pots
incoming called-number .
direct-inward-dial

dial-peer voice 10 pots
trunkgroup telefonica 1
description OUTGOING CALLS
destination-pattern 0.T

dial-peer voice 11 pots
trunkgroup telefonica 1
description OUTGOING SERVICE CALLS
destination-pattern 019.
forward-digits 3

dial-peer voice 12 pots
trunkgroup telefonica 1
description OUTGOING EMERGENCY CALLS
destination-pattern 0190
forward-digits 3

sip-ua
no remote-party-id
retry invite 2
timers buffer-invite 5000

show voice port 0/0/0:0
R2 Slot is 0, Subslot is 0, Sub-unit is 0, Port is 0
Type of VoicePort is R2
Operation State is UP
Administrative State is UP
No Interface Down Failure
Description is not set
Noise Regeneration is enabled
Non Linear Processing is enabled
Non Linear Mute is disabled
Non Linear Threshold is -21 dB
Music On Hold Threshold is Set to -38 dBm
In Gain is Set to 0 dB
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancellation NLP mute is disabled
Echo Cancellation NLP threshold is -21 dB
Echo Cancel Coverage is set to 128 ms
Echo Cancel worst case ERL is set to 6 dB
Playout-delay Mode is set to adaptive
Playout-delay Nominal is set to 60 ms
Playout-delay Maximum is set to 1000 ms
Playout-delay Minimum mode is set to default, value 40 ms
Playout-delay Fax is set to 300 ms
Connection Mode is normal
Connection Number is not set
Initial Time Out is set to 15 s
Interdigit Time Out is set to 10 s
Call Disconnect Time Out is set to 60 s
Ringing Time Out is set to 180 s
Wait Release Time Out is set to 30 s
Companding Type is A-law
Rx A bit no conditioning set
Rx B bit no conditioning set
Rx C bit no conditioning set
Rx D bit no conditioning set
Tx A bit no conditioning set
Tx B bit no conditioning set
Tx C bit no conditioning set
Tx D bit no conditioning set
Region Tone is set for BR
Station name None, Station number None
Translation profile (Incoming): TP-Incoming
Translation profile (Outgoing): TP-Outgoing
lpcor (Incoming):
lpcor (Outgoing):

Voice card specific Info Follows:
Line Signalling Type is r2-digital
Register Signalling Type is r2-compelled
Country setting is brazil
Answer Signal is group-b 1
Category is set to 2
NC Congestion is set to 4
KA is set to 0
KD is set to 0
Caller Digits is set to 1
Request Category is set to 0
End of DNIS is set to False
DNIS Digits min is 0 and max is 0
ANI Digits min is 0 and max is 0
Group A Callerid End is set to False
Metering is on
Release Ack is set to False
Unused ABCD Bits Mask configured: 0 0 0 0
Inverting ABCD Bits Mask configured: 0 0 0 0
Debounce Time is set to 40ms
Release Guard Time is set to 2000ms
Seizure Ack Time is set to 100ms
Answer Guard Time is set to 0ms
ANI Timeout is set to 0s

DS0 channel specific status info:
IN OUT
PORT CH SIG-TYPE OPER STATUS STATUS TIP RING
=============== == ============ ==== ====== ====== === ====
0/0/0:0 01 r2-digital up answered idle
0/0/0:0 02 r2-digital up answered idle
0/0/0:0 03 r2-digital up idle answered
0/0/0:0 04 r2-digital dorm idle idle
0/0/0:0 05 r2-digital dorm idle idle
0/0/0:0 06 r2-digital dorm idle idle
0/0/0:0 07 r2-digital dorm idle idle
0/0/0:0 08 r2-digital dorm idle idle
0/0/0:0 09 r2-digital dorm idle idle
0/0/0:0 10 r2-digital dorm idle idle
0/0/0:0 11 r2-digital dorm idle idle
0/0/0:0 12 r2-digital dorm idle idle
0/0/0:0 13 r2-digital dorm idle idle
0/0/0:0 14 r2-digital dorm idle idle
0/0/0:0 15 r2-digital dorm idle idle
0/0/0:0 17 r2-digital dorm idle idle
0/0/0:0 18 r2-digital dorm idle idle
0/0/0:0 19 r2-digital dorm idle idle
0/0/0:0 20 r2-digital dorm idle idle
0/0/0:0 21 r2-digital dorm idle idle
0/0/0:0 22 r2-digital dorm idle idle
0/0/0:0 23 r2-digital dorm idle idle
0/0/0:0 24 r2-digital dorm idle idle
0/0/0:0 25 r2-digital dorm idle idle
0/0/0:0 26 r2-digital dorm idle idle
0/0/0:0 27 r2-digital dorm idle idle
0/0/0:0 28 r2-digital dorm idle idle
0/0/0:0 29 r2-digital dorm idle idle
0/0/0:0 30 r2-digital dorm idle idle
0/0/0:0 31 r2-digital dorm idle idle

[R0g22]

The logs are not complete wherein the R2 events and/or the Group A/B events being sent/received are truncated towards the right. Enable the following and then make a test call from skype -

debug vpm signal
debug voip vtsp default
debug voip vtsp session
debug voip ccapi inout

Share the logs in a text file please.

[voip7372]

Thanks.   I attached the info you asked for,  The names/numbers have been changed for privacy, but otherwise it's all the original data from the debug output.  

EDIT:  I'll need to upload a different version of this.  Coming soon....

[voip7372]

You know, I just realized the number I changed in the debug for posting here wasn't changed in the places where the individual digits appear...so when you're looking at the debug, please note the digit string with the digits all together are the number I used as a dummy number for posting here, but the numbers you see in the debug that has individual digits is the unchanged number.  Hope that doesn't make it too confusing, but I think you may have already spotted that and that part isn't what's the problem anyway.   Just something to take note of to avoid confusion.

[voip7372]

Let me know if you already downloaded that text file I uploaded previously.  I just realized it had unaltered/real numbers in it so I wanted to remove it.   I can edit it again to change the real number to the dummy number I was using as example if you still need it.  If you already got it though, that's ok with me :-)    Just didn't want to leave it here for the public.  

[R0g22]

Send me the file in a PM.

[voip7372 · Accepted solution]

Sent.

Update from my colleague that manages the Skype side.  I mentioned to him it seems like some kind of timer expiring that is causing the call to disconnect (just my guess/idea) and he said the SIP trunk in Skype/Lync that's connected to CUCM has this timer mentioned below.  When I just now did a test call to an international number and timed the call, it failed right around 10 seconds.  A call to a local number connected in about 5.5 seconds.  So, I think it's possible this might be our problem (unless you find something else in the debugs).

Skype server setting for the SIP trunk to CUCM:

outbound routing failover timer 

Enable outbound routing failover timer should be selected to enable fast failover. The gateway associated with this trunk can give notification within 10 seconds that it is processing an outbound call. Rerouting to another trunk will occur if this notification is not received by the Mediation Server. On networks where latency may delay the response time or the gateway takes longer than 10 seconds to respond, the fast failover should be disabled.

[voip7372 · Accepted solution]

I confirmed the change to remove the 10 second timer on the SIP trunk in Skype/Lync solved the problem.  After my colleague disabled that timer in Skype, it worked.  That makes sense because the call looked good and just died for no reason after about 10 seconds.  Local calls were ok because they are fewer digits and these ancient E1 R2 circuits were able to dial those local numbers fast enough so the 10 second timer on Skype wasn't hit.  

Anyway, that's what the problem is/was.  

Thanks for offering to look at the debugs!

[voip7372]

This is a view of the setting in Skype, in case it helps someone in the future (if someone is using the same type of call flow we are).  Skype/Lync Server > CUCM > SIP trunk to PSTN gateway router > PSTN gateway router > E1 R2 circuit/PSTN