cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
7222
Views
5
Helpful
11
Replies
Highlighted
Beginner

CUBE SIP 'session-expires' missing at first refresh.

Hi,

We've been testing the UPDATE method for refreshes since we removed it on the CUBE at initial install some years ago. Our interrop team has requested us to help test if we can re-enable the UPDATE method between CUBE and SP but we are still faced with calls being dropped at 1/2 session-expires timer setting, same as all those years ago.

Since our initial install we've upgraded our CUBE IOS from 15.1 to 15.4 so I was hoping it would work this time around. Here are my findings:

LAB Setup: MIN-SE set to 90 on CUCM and CUBE.

When we make test calls traces show session-expires is accepted at 90s. The SP makes an inbound call and is set to refresh as UAC. When the first UPDATE comes in from the SP, the CUBE sends a Re-Invite onwards to CUCM but the session-expires field is missing. The Min-SE field is there but nothing more. From this point onwards I can only speculate what happens as 900s (yes 900, not a typo) later the call drops.

From rfc4028 is states that if the session-expires timer field is missing then CUCM does not expect updates anymore so I assume it defaults back to 1800s. The SP still expects refreshes and at roughly 900s it drops the call because CUCM did not send any updates that was expected at 90s intervals as negotiated in the initial INVITE shown below.

Min-SE: 90

Cisco-Guid: 4253898488-2458391013-2889204248-3239308476

User-Agent: Cisco-SIPGateway/IOS-15.4.3.M4

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE

Timestamp: 1448441677

Contact: <sip:+27122267002@10.231.227.6:5060>

Expires: 180

Allow-Events: telephone-event

Max-Forwards: 35

Session-Expires: 180;refresher=uac

Any ideas why the CUBE does not send the session-expires field to CUCM? Calls from In to Out works fine for some reason as we, the CUBE, is now NOT the refresher, its the SP SBC that is the refresher. It's all a bit confusing but hey, maybe someone has an idea.

Below is the first Re-Invite/Update from CUBE to CUCM. Notice no Session-Expires field. From this point +-900s later the call drops.

Min-SE: 90

Cisco-Guid: 4253898488-2458391013-2889204248-3239308476

User-Agent: Cisco-SIPGateway/IOS-15.4.3.M4

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 102 INVITE

Max-Forwards: 70

Timestamp: 1448441768

Contact: <sip:+27122267002@10.231.227.6:5060>

Expires: 180

Allow-Events: telephone-event <-- Somewhere here should be Session-Expires

Content-Type: application/sdp

Content-Length: 294

v=0

Thanks,

Ingo

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

Great... Hope it will work for you, please update the results once you're done.

So you didn't had even 'session refresh' command configured under sip mode? So you've two choices here, either enable session refresh globally (under sip) OR in respective dial-peer with the command you've specified. Minimum and session expire timer can be configured using 'min-se xxxx session-expires xxxx' under sip mode.

When configured under dial-peer, following document specifies various combinations and respective result;

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_proto/configuration/xe-3s/cube-proto-xe-3s-book/voi-trust-firewall-3.html#GUID-173970A8-DFF6-464B-9896-F4AB539F9AFD

- Vivek

View solution in original post

11 REPLIES 11
Highlighted
Engager

Hi Ingo,

Can you share the SIP trace of complete call?

- Vivek

Highlighted

Please find attached my ccsip messages debug output. Here are some IP info you will need:

192.168.9.130 - SP side of CUBE

10.231.227.6 - Inside of CUBE

165.143.252.241 - CUCM

Other IPs are SBC and Application servers on the SP side. EG 165.148.7.7, SP SBC and 10.190.23.105 I think is their Application Server.

Call Flow: CUCM -(SIP)- CUBE -(SIP)- SP SBC

Highlighted

Let's us try to analyze what is happening here;

When we make test calls traces show session-expires is accepted at 90s.

No, session-expire is negotiated to 180 seconds. Only min-se is 90 sec which indicates that session-expires can not be lower than 90 seconds. Further session should be refreshed at the rate of half of session expriy timer which will becomse 90 sec (half of 180 sec).

The SP makes an inbound call and is set to refresh as UAC. When the first UPDATE comes in from the SP, the CUBE sends a Re-Invite onwards to CUCM but the session-expires field is missing. The Min-SE field is there but nothing more. From this point onwards I can only speculate what happens as 900s (yes 900, not a typo) later the call drops.

So on the call leg of service provider, SP is agreed to send refresh since it's UAC. You're right on reciept of first refresh from SP, Re-INVITE sent by CUBE to CUCM is without session-expire. This means that session timers won't be used anymore on the call leg of CUBE and CUCM and call will never fail because of session timer.

From rfc4028 is states that if the session-expires timer field is missing then CUCM does not expect updates anymore so I assume it defaults back to 1800s. The SP still expects refreshes and at roughly 900s it drops the call because CUCM did not send any updates that was expected at 90s intervals

What RFC says is if session-expire header is not present in request, session timer won't be used any more. This doens't mean that call will be disconnected after session timer since session timer is not negotiated at all.

However service provider doesn't expect any refresh because it has been agreed to become refresher (UAC) so it's service provider who will always send the refresh request and you can see that at the interval of 90 sec (half of sesssion-expiry timer negotiated), there is UPDATE message from service provider.

In absence of session refresh between CUBE and CUCM, it should not impact service provider because service provider already sending UPDATE continuously. 

Moroever call is being disconnected after roughly 1138 sec by service provider and this value is much higher than the session timer negotiated viz 180 sec. Call started at 10:54:38 and last long untill 11:13:36

In my opinion, you should check with service provider to see the actual reason of getting BYE message. This could also be because of normal call clearing OR something else.

One thing I'm not sure on the call leg of CUBE and CUCM, since session timer was negotiated successfully and CUBE was negotiated as to send refresh (UAC), then why later on Re-INVITE sent by CUBE was without session-expiry header.

- Vivek

Highlighted

Hi Vivek,

Sorry for the 90s/180s statement at the top but you understood what I was trying to say.

I agree that the different call legs, one from CUBE to SP and the other from CUBE to CUCM should not have any impact on each other. On the otherhand, I set my CUBE Min-SE timer to 90 and the call leg between CUBE and SP stayed on 1800 (default). Only after I changed the CUCM setting to 90 did the CUBE-SP call leg reflect 90s. This to me showed that there is some sort of interworking, or passthru, happening between CUCM and SP call legs even though they are seperate SIP sessions.

I will speak to the SP engineer again to get an exact reason for the BYE message. Also the fact that the CUBE now suddenly stops sending refreshes back to CUCM is also strange. Let me see what the SP engineer says.

Ingo

Highlighted

See CSCuj49936. Looks very similar to our issue. I am investigating...

Highlighted

I don't think that bug is impacting us because in our case it's not CUCM who is disconnecting a call.

However one thing is common in bug and our case. CUCM is sending UPDATE without session-expirty header and in our case, it's CUBE sending Re-INVITE to CUCM without session-expiry header.

By the way, respective bug descripption in itself is confusing. When CUBE responds with 200 OK with refresher as UAS, that means it's CUBE which will send UPDATE/Re-INVITE periodically and not CUCM. So why CUCM will send UPDATE to CUBE after 900 sec b/c it's UAC in that case :)

- Vivek

Highlighted

Hmm... I have it that the CUBE sends the Re-INVITE and from the point of view of the CUBE he is the UAC and the CUCM the UAS. The Re-INVITE mentioned in the bug says the CUBE sends Re-INVITE back to CUCM with UAS meaning that the CUBE designates the CUCM (or UAS from his point of view) to be the refresher as was initially 'contracted' by the CUCMs initial INVITE to the CUBE.

But perhaps it's in relation to the Initial INVITE only and not the Re-INVITES... I think you might be right.

I am just waiting on the SP guy to return, I noticed an anomaly on his network so would want to clarify that first. For some reason he suddenly sends an update at 11:09:40 and then stops. It could be the cause why the call drops from his side.

Highlighted

Who is UAC or UAS for session refresher will depend on who has initiated the dialog. In the respetive bug, CUBE has sent 200 OK with refresher value set to UAS. Since CUCM has generated a dialog, CUCM will be UAC and CUBE will be UAS and hence CUBE will generate the session refresh request periodically.

If CUBE could have sent refresher value set to uac, that should be CUCM responsible for refresh request.

So once call  has been matured, CUBE should start sending refresh request, but now will inlcude refresher as UAC b/c CUBE is generating refresh request.

And yes, you've correctly mentioned that there is no UPDATE from SP after 11:09:40 and got directly BYE at 11:13:36. SP should definitely tell what exactly happened at thier end.

- Vivek 

Highlighted

Success!!

After some investigation I found the following command that I added to the Dial-Peer facing the SP.

voice-class sip session refresh

This had the effect of keeping the UPDATES going and both Inbound and Outbound calls were successful in our LAB setup. The missing 'session-expire' field is now also visible as it was missing previously. My next test would be on a Production CUBE and I am confident it will work there as well.

Highlighted

Great... Hope it will work for you, please update the results once you're done.

So you didn't had even 'session refresh' command configured under sip mode? So you've two choices here, either enable session refresh globally (under sip) OR in respective dial-peer with the command you've specified. Minimum and session expire timer can be configured using 'min-se xxxx session-expires xxxx' under sip mode.

When configured under dial-peer, following document specifies various combinations and respective result;

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_proto/configuration/xe-3s/cube-proto-xe-3s-book/voi-trust-firewall-3.html#GUID-173970A8-DFF6-464B-9896-F4AB539F9AFD

- Vivek

View solution in original post

Highlighted

Correct, I didn't have it under SIP or Dial-Peer. In the LAB I only added it under the Dial-Peer and in the semi-production environment I will put it under the global SIP configuration. At this point in time we use all the defaults so we are back on 1800s for Production - it just takes a bit longer to do a test :-)

I'm guessing the command wasn't supported when we first installed the CUBE and with subsequent upgrades it is now available. The CUBE did go through a H/W upgrade and a few IOS upgrades already and we never had the need to re-enable the UPDATE method until now.

Content for Community-Ad