UPDATE for CFNA causing 491 Request Pending

[givanov]

Hello experts,

I am having the following strange CFNA problem:

Call flow: ITSP - SIP - CUCM - SCCP - Phone A (forward after 10 seconds to phone B, forward after 10 seconds to phone C, then back to A).

Carrier sends INVITE with EO; CUCM responds with 100 and 180 without SDP. 10 seconds later CUCM sends UPDATE for the call being forwarded to phone B, but ITSP throws back 491 Request pending. User experience is the caller keeps constant ringing where the called number (phone B or C) can pick up the call, but hears nothing.

I assume that the ITSP expects SDP with 180 (or 183) to establish the session before we can Update it. Is there a way to force CUCM use SDP with 180 or use 183 with SDP to go around this problem. Once again no CUBE involved. Or shuold the carrier be able to process the UPDATE even without the SDP from CUCM.

SIP trunk is direct between CUCM and carrier and has MTP required checked.

CUCM is 10.5, recently upgraded from 8.5. Issue started after the upgrade. It is most probably a parameter that is new in 10.5, but can't seem to find it.

Thank you in advance!

[Venkatesh Perumal]

Hi,

check on 180/183 from cube, if those messages contain 'require:100rel' parameter, 

if it does, then enable 100 rel in CUCM and test a call.

https://www.cisco.com/c/en/us/support/docs/voice/session-initiation-protocol-sip/116086-configure-cube-cucm-sip-00.html

Regards,

Venkatesh

[givanov]

Hi Venkatesh,

Thank you for your response. There's no CUBE, it's direct SIP to the SP, but I believe it is the same. The thing is that the issue happens with incomming call so the 180 is being sent FROM CUCM and not to it.

The INVITE has 100rel supported, and not require, but I can give that a shot.

INVITE sip:029391987@192.168.13.11:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.10.34.97:5060;branch=z9hG4bKknrlnr207g2mghers8b0.1
Call-ID: SDifk9601-6bd818f2f36e289822e4d1fa0c0d3eb1-ags9010030
From: <sip:024001440@10.10.34.97;user=phone>;tag=SDifk9601-3g63ux3u-CC-1000
To: <sip:029391987@192.168.13.11;user=phone>
CSeq: 1 INVITE
Contact: <sip:024001440@10.10.34.97:5060;transport=udp>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
User-Agent: United.Com
Supported: 100rel
Max-Forwards: 69
Content-Length: 235
Content-Type: application/sdp
v=0
o=ucom 5281119 5281119 IN IP4 10.10.34.97
s=Sip Call
c=IN IP4 10.10.34.97
t=0 0
m=audio 20122 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

[Ayodeji Okanlawon]

Just seeing this while looking at another issue and I believe your analysis is correct. UPDATE can only be used with early dialogs ( or confirmed dialog)..This is a section from the RFC

It is important
   to note that a reliable provisional response will always create an
   early dialog at the UAC.  Creation of this dialog is necessary in
   order to receive UPDATE requests from the callee.

 So you need to change this to include PRACK before CUCM can send an UPDATE.

Cisco's use of UPDATE is not really compliant with RFC. This is why most times UPDATEs creates issues with SIP providers. UPDATE should only be sent once an early dialog is established.