SIP calls drop after 15 minutes in Branch office. Re-Invite not propagated by Carrier
Have remote branch office phones connected to CUCM 9.1. Just transitioned to SIP service via CUBE in this branch office. Have outbound calling functioning properly (calls stayed connected until hung up). Inbound calls drop at 15 minutes.
In troubleshooting I’ve found that the SIP Re-Invite never makes it to the far side if I call from another branch. I traced a call from another branch office running SIP with a CUBE (with phones connected to CUCM as well) and called the branch having the problem via the PSTN. Both sides negotiated successfully and I let the call stay connected. At 15 minutes, the branch that initiated the call sent a SIP Re-Invite (via CUCM and then the CUBE) to the far side. The far side (called side) never received the SIP Re-Invite. At about 16 minutes CUCM at the called site sent a BYE thinking the call was not still connected.
I contacted the carrier (International Carrier in the UK) and gave him the SIP traces. Carrier came back with the following
“advise customer that the o line in the sdp doesn't change and that is why the re-invite doesn't propagte to the other side. The reinvite is not needed howevr to keep a call up. I recommended that UK CPE be checked furhter to determine why the cause =86 BYE is sent form it as there is no spec of RFC requiring a reinvite every 15 mins. “
Is there a way to solve this via CUCM? It would appear to me that SIP would need a mechanism to close out calls and the Re-Invite would be it.
Thanks for the info. I reconfigured the min-se on the CUBE. However, the 200 okw SDP from the CM is still sending 1800. I noticed that the invite from the SP does not have MAx session defined. In my opinion since the CM can not agree on the MAx session it trays to renegotiate the call by half of max session of 1800 sec which is 15 minutes. I had engaged the SP to investigate why they call is not sending the max session and why are they tearing down the call.
That means they've already cleared the call which usually means the refresh wasn't sent before the timer on the ISP side expired. We'll need to see the traces for the full call to look at timing and which side was supposed to have the refresher role for that leg.
Can you attach the traces? Take a look at RFC4028. We need to see which side is the refresher for both sides of the call. Devices should never forward refresh re-invites unless they are also acting as the refresher role so that may be working as expected. Refresher is per leg so CUCM may be the refresher between CUCM and CUBE but the ITSP may be the refresher between the CUBE and ITSP. It can create some complicated scenarios.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...
If you have 2 ISR routers, one acting as Failover, do we need to have both the same number of SRST licenses on the 2 routers?
No. You will only need the SRST licenses on the primary router. Because this feature...
You have reached the Cisco Logistics Support Center.. To Check Status of your RMA, visit Product Returns & Replacements (RMA).
Need help? Contact us by Phone or Email.
Phone: 1800 553 2447 Option 4