Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

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.



New Member

we  have a similar issue.

we  have a similar issue. However, I see the re-invite going out to the ISP and they respond with a 481 Call/Transaction does not exist 


014656: May 27 21:17:48.976: //468349/15DC7AC19236/SIP/Msg/ccsipDisplayMsg:
SIP/2.0 481 Call/transaction does not exist
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK7F7281585
From: "user"<sip:user@x.x.x.x:5060>;tag=33C9F2EC-ABA
To: <sip:user@y.y.y.y;user=phone>;tag=1947102518-1401224470143-
Call-ID: BW160110143270514-272249375@x.x.x.x
CSeq: 101 INVITE
Timestamp: 1401225468
Content-Length: 0


Did you get any additional feed back on this. 


New Member

Hi, I lowered these values in

Hi, I lowered these values in CUCM and then it worked:

you can also try to lower these values on CUBE:

min-se and session-expires


Hope that helps

All that does is prolong the

All that does is prolong the time before the issue occurs.

New Member

Thanks for the info. I

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

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?

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.

There's a CUBE in the middle,

There's a CUBE in the middle, can you capture:


debug ccsip messages

debug voice ccapi inout


Please also attach the sh run from the CUBE.






-- Jorge Armijo Please remember to rate helpful responses and identify helpful or correct answers.
CreatePlease to create content