SIP UPDATE call disconnect

[Dennis Mink]

We are using SIP provider (203.52.0.167 in the diagram below, same as aces.com.au).

I am having an issue when dialing for instance 0300003876 from 88855670.

In diagram below 10.61.64.254 is the CUBE and 10.61.2.82 is CUCM.  The problem with the call is, it rings, then I get a 1-2 second message say "please leave a message for.." and I get cut off halfway this message. 

I can see a large number of SIP UPDATES coming from the far end, I am guessing this is because the far end has realised that the callee is not available and wants to chnage the session by sending me a new SDP trough SIP UPDATE  (as opposed to a re-INVITE).  eventually I receive a 408 Request time out, which probably causes the call to be disconnected prematurely.

The full SIP trace is included in attachment, I am not sure how the CUBE should deal with these updates, as it is obviously not passing it on to CUCM (as per diagram). 

Just want to get a general understanding of what is going on here. 

thanks Folks.

(I will rate if useful)

[Mohammed al Baqari]

Hi Dennis, 

Your CUCM didn't acknowledge 183 message from CUBE. You need to configure 100Rel under your SIP profile for the CUBE trunk.

For time being use Send PRACK if 1xx Contains SDP

[Dennis Mink]

Mo,

I am assuming you are referring to this:

currently its set to "disabled", can you enlighten me on what changing it is going to do?

thanks

[Mohammed al Baqari · Accepted solution]

Yes I am referring to this. 

If you look at your translatorX diagram, provider is sending 180withSDP and CUBE is sending PRACK. Provider is acknowledging this with 200OK. 

This means that your CUBE is doing cut-through to hear early-media such as ringback. The 180withSDP is from the provider to tell the CUBE about provider's IP/Port/Codec used for early media. CUBE needs to acknowledge it (which is happening) with PRACK that shares CUBE's IP/Port for provider to send early-media rtp stream.

Now looking at the second call leg, CUBE is sending 183 message to CUCM with CUBE's SDP details (IP/Port/Codec) to perform early-media and send RTP stream. CUCM needs to acknowledge this with PRACK to share the IP Phone's details (IP/Port) to receive the RTP stream. Since this option isn't enabled CUCM isn't acknowledging 183 with PRACK and CUBE is timing out after couple of seconds, i.e. early media isn't working.

Once you enable this option then you will have proper early-media working and cut-through successful. 

[Dennis Mink]

Thanks Mo,

full points there

lI changed the SIP profile, and enabling Rel1XX prack fixed it.

good to learn something new.