SIP calls drop after 15 minutes in Branch office. Re-Invite not propagated by Carrier

[kenneth.meyers]

All,

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!

Ken

[OQ]

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:
Received: 
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. 

Regards. 

[c.hennrich]

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

[Brian Meade]

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

[OQ]

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. 

[Brian Meade]

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.

[wilsonsant]

Hi Brian,

My Customer is having the same problem. Had any solution about this?

Thanks,

Regards,

Wilson

[wilsonsant]

Hi Oquinones,

My Customer is having the same problem. Had any solution about this?

Thanks,

Regards,

Wilson

[Brian Meade]

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.

[Jorge Armijo]

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.

HTH

~jorge

[wilsonsant]

Hi Jorge Armijo,

My Customer is having the same problem. Was possible identificar the root cause?

Thanks,

Wilson

[wilsonsant]

Hi Kennet,

My Customer is having the same problem. Was possible found the solution for this?

Thanks,

Regards,

Wilson