cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1494
Views
0
Helpful
3
Replies

Peer unable to send PRACK to CUCM

Alfonso Vila
Level 1
Level 1

Hello,

I'm having an issue with a dialer that is connected to my CUCM through a SIP trunk. It is using Early Offer and thus CUCM sends it a "183 Session Progress" message. This message is not ALLOWed in the first INVITE and the peer does not accept if (and does not reply with a PRACK), so the call drops 4 seconds after ringing.

Is there any possibility to disable progress messages (strip) in the CUCM?

The CUCM routes the call to a H323 GW, running IOS 12.4, with progress_ind already set to disable, but it keeps dropping every call arriving from the SIP trunk.

I don't know if is someone finds any other way to make it work. I'm a little bit lack of ideas right now...

Thank you all in advance!

Alfonso Vila

3 Replies 3

Jonathan Schulenberg
Hall of Fame
Hall of Fame

Something about your statement doesn't add up. You say that the dialer is doing an Early Offer (meaning that it included SDP in its INVITE to CUCM); however, it won't accept a 183 Session Progress (which includes CUCM's SDP response). In this scenario there would be no PRACK. PRACK is only needed if it's a Delayed Offer call with Early Media (i.e. there was no SDP in the INVITE; the 183 message is the first SDP exchange). In this scenario PRACK is needed to finish the SDP exchange.

If it's an Early Offer call, 183 would be the expected response so it can finish the SDP exchange and cut audio through.

Can you clarify or attach the SIP dialog (either CCM SDI traces or a wireshark)?

Please remember to rate helpful responses and identify helpful or correct answers.

Hi Jonathan, and thank you for your time!

In this scenario the call travels from SIP dialer => CUCM => H323 GW => PSTN, so the progress is notified by the GW and so a 183 message is sent to the dialer to place the two way audio on call establishment (ring tone). You can see the flow in the attached image:

The INVITE carries one side SDP (g711a) and the GW notifies progress, that is notified to the trunk (183), that is not ACKed with a Provisional Response ACK (PRACK), and when the timeout expires the GW drops the call (4 seconds).

Let me go back to my first answer: can I supress this behaviour and let only the 200 message (establishment) complete the two way audio and disable the Session Progress in a IOS 12.4 + CUCM environment?

Hello again,

In the end we found that the CUCM was not sending OLCAck to the H323 GW (prior to the OLCAck from the GW), and the call dropped at last.

The configuration change that solved the issue was enabling Early Offer on the H323 config in the GW. It keeps registering MTP resources (preferably on the IOS), but now works flawlessly.

Hope this helps to anyone with a similar issue.

Jonathan, thank you for your time!

Regards,

Alfonso