CUBE SIP trunk audio dying after specific time

[CUCM55120]

We have had reports from users that audio on their calls is going dead after 7 and a half minutes on calls to certain outside numbers and users are having to hang up and call again with it happening repeatedly. After some investigation we have been able to trace these calls on our call logger and have seen the pattern of a user having repeated calls from same number with interval of 7 minutes 30. We have not been able to reproduce the issue ourselves and the issue seems to only occur when being called (and possibly calling) by specific numbers, which we suspect to be other organisations using SIP (testing from a mobile phone and PSTN line has been fine).

We moved to SIP a little while back and have 2 CUBEs handling calls round robin. We have checked our config on the CUBEs (all setup by our provider) and have noticed some inconsistencies between the configs and some inconsistencies between settings on the CUBEs and the same parameters in CUCM that we suspect may be an issue.

On both CUBEs the SIP timers are set:
min-se 450 session-expires 900

With 450 seconds being 7 and half minutes we suspected this timer was possibly causing our issues but currently our provider isn't convinced but has agreed we should change this anyway. In CUCM parameters the min-se timer is 900 and expires is 1800.

The other inconsistency noted is that on one CUBE under SIP config we have bindings to the interface which is the link to our network:

sip
bind control source-interface GigabitEthernet0/0
bind media source-interface GigabitEthernet0/0
min-se 450 session-expires 900

but on the other CUBE the two bind config lines are not there.

On both CUBEs the bind config lines are also added for each dial peer but on one of the CUBEs two of the dial peers going to our CUCM nodes only have the bind media line and not the bind control.

Some quick reading about the bind command and related issues suggests incorrect configuration can cause dropping or audio issues if devices are unsure about the IPs involved in a call? I don't have a great deal of knowledge with IOS and CUBE but it seems to me that there is no reason for these differences in our CUBE configs.

Any help appreciated on this. Thanks.

[CUCM55120]

We have just been able to replicate the issue with a partner organisation who are with the same SIP provider as us. When they call us after 7 minutes 30 the audio will die but the call will remain connected. Have had a look on the CUBEs to check the status of the call and it remains active on our CUBE and can't see anything odd.

What would be the best way to debug the issue on the CUBE while the call is active? Thanks.

[Ayodeji Okanlawon]

Hi,

What this looks like is a session expire timer issue. Your current configuration ( just on the face of what I am seeing, may have to dig deeper into configs to verify) is set to 900s.

This =15 minutes. By default session refresh needs to happen at 7.5 minutes into the call. If the party responsible for initiating the session refresh doesnt do this, then the call gets terminated.

So to determine who is responsible either the UAC or the UAS ( this is indicated during the session establishment in the SIP signaling), we will need to look at the logs.

Here is what you can do..

1. Enable debug ccsip messages on your gateway

2. make a call to the affected number and make note of the time you started the call

3. Turn off the debug ( download the logs-check that your call is present in the gateway logs)

4. When its 6.5 minutes into the call, start the debug again ( debug ccsip messages)

5. Turn off the debug after 1.5 minutes ( by this time, the sip signaling for session refresh should have happened and we will know why the call is not staying up at this point

6. attach the logs here.

Here is how to properly setup debug on your gateway

service sequence-numbers
service timestamps debug datetime localtime msec
logging buffered 10000000 debug
no logging console
no logging monitor
default logging rate-limit
default logging queue-limit

Then..

<Enable debugs, then test again.>

debug ccsip mess

<Enable session capture to txt file in terminal program.> (such as Putty)

then do the ff:

terminal length 0
show logging

[CUCM55120]

Have taken some traces and I have noticed that after 7:30 minutes the codec of the RTP packets changes. Initially the phone is sending and receiving g711a and then after 7:30 minutes the session is refreshed and the phone starts sending g711u but incoming packets are still in g711a. Is this possibly the source of the issue?

I suspect the issue to most likely be related to our CUBE configurations but I have little knowledge of IOS and CUBE configuration so we are very reliant on our provider. I have compared the config of both and it appears loads of commands are present on one and not on the other and there are lots of inconsistencies between them. The CUBEs were setup by two different engineers from our provider on different days and so far they don't seem interested in checking the configs of them for anything that might be causing the issue. As it can only be replicated by asking another specific organisation to call us and wait 7:30 minutes we are very limited in what we can do to troubleshoot whilst replicating the issue.