[cisco-voip] SIP Stack & Trace Question

[Daniel Pagan]

Wrapping up on this one...

The SIP Stack error below occurred because CUCM (as the UAS) received an UPDATE request before receiving a PRACK for its 183 w/ answer. Possible solution is to have CUCM send a Require: 100rel in the 183 answer, forcing the UAC to PRACK before sending the update, but the caveat in our scenario is that NRS v5.5 does not support PRACK.

The UPDATE request from the NRS is sent during a blind transfer event. I guess another solution would be for the NRS to use REFER instead of UPDATE, but I cannot say whether or not this is possible from the Nortel side. However, because the NRS doesn't support sending PRACK, and CUCM is requiring PRACK before receiving an update (as per RFC 3311), it seems we're stuck between a rock and a hard place unless it turns out the NRS can use REFER. The vendor supporting the NRS is investigating this side of it further.

Relevant information
https://tools.ietf.org/html/rfc3311#section-5
https://tools.ietf.org/html/rfc3262#section-3

While on the topic of documentation, and please correct me if I'm mistaken, but I think the following Cisco doc should be updated:

SIP Profile - 1xxRel
"Note: Even if you make the above change, CUCM can support reliable responses only by sending PRACK as a UAC; however, for now, it cannot send 180/183 with the Require: 100rel header as a UAS."  http://www.cisco.com/image/gif/paws/116086/116086-configure-cube-cucm-sip-00.pdf

A more accurate statement would be that CUCM can send a Require: 100rel header and option as a UAS only when meeting the following prerequisites:


1.       First receiving 100rel in either the Supported: or Require: headers within the INVITE from the UAC

| and |

2.       Enabling Rel1XX Option on the SIP Profile to "Send PRACK for all 1xx Messages".

Setting this option to "Send PRACK if 1xx Contains SDP" will not force CUCM to send a reliable provisional response to the UAC.

|  or  |

3.       Adding a SIP normalization script that inserts the Require header with 100rel option (UAC must support it)

Thank you for helping out on this earlier, Brian.

- Daniel

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Daniel Pagan
Sent: Thursday, February 13, 2014 6:16 PM
To: Brian Meade (brmeade); cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] SIP Stack & Trace Question

Brian:

Thanks for the response.

I'd have to review traces for a non-transfer scenario but it's my understanding that, in this scenario, the 183 w/SDP from CUCM was the answer in the offer/answer model - the offer being Nortel's INVITE w/SDP. Just after allocation of the MTP, SIP Interface shows "SIPInterface-(292194)::handleOutgoingSDPAnswer", which, correct me if I'm wrong, should complete the offer/answer:

INVITE (SDP offer)           --> CUCM
100 Trying                            <--
183 (SDP answer)             <--
183 (No SDP)
UPDATE (SDP)                   -->
== SIP/Stack/Error/0x0/Last Offer not answered yet
== Note: Context ID (ccb=<id>) matches the ID created at the start of the dialogue
500 Internal SvrErr           <--

Thoughts? Thanks again Brian.

- Daniel

From: Brian Meade (brmeade) [mailto:brmeade at cisco.com]
Sent: Thursday, February 13, 2014 5:59 PM
To: Daniel Pagan; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: SIP Stack & Trace Question

Daniel,

It seems to me like CUCM is waiting for an answer to the offer it sent in the 183 w/SDP.  In a non-transfer scenario, does the Nortel side normally send a PRACK at that point?  Possibly the Nortel side is sending the Update before the PRACK?

Thanks,
Brian

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Daniel Pagan
Sent: Thursday, February 13, 2014 5:08 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] SIP Stack & Trace Question

Folks:

I'm reviewing an issue and looking for some feedback on a specific SIP stack error. In a nutshell, what appears to be happening is CUCM (8.6.2.24090-1) responding to an UPDATE request with a 500 Internal Server Error in a very specific transfer call flow:

.::: Call is established :::
.::: Nortel Begins a xfer to CUCM :::

Nortel             ====                CUCM
>>>        INVITE  w/SDP
                100 Trying                           <<<

=======DA Successful
=======Outbound to ITSP
=======MTP Required on Rx SIP Trunk
=======MTP resource allocated
=======SDI trace events show SIPInterface-(292194)::handleOutgoingSDPAnswer once media info is collected for MTP

                183 w/ SDP (for MTP)        <<<

=====ITSP returns 183 w/ SDP

                183 no SDP                          <<<
>>>        UPDATE w/SDP

=====SIP stack detects an existing connection
=====SIP stack detects an SDP offer has yet to be answered

                500 Internal Svr Error     <<<
                w/ retry-timer header
                ::: Call Xfer attempt fails :::

The SIP stack trace excerpt that raised a flag states:
SIP/Stack/Error/0x0/Last Offer not answered yet
This occurs after the UPDATE w/ SDP offer is received and immediately before the 500 response is generated.
SDI traces show the event was added to the UAS response table using same context ID created for the original INVITE.

With this error in mind I decided to review the RFC for SIP UPDATE and found a very interesting piece of information:

"If an UPDATE is received that contains an offer, and the UAS has
   generated an offer (in an UPDATE, PRACK or INVITE) to which it has
   not yet received an answer, the UAS MUST reject the UPDATE with a 491
   response.  Similarly, if an UPDATE is received that contains an
   offer, and the UAS has received an offer (in an UPDATE, PRACK, or
   INVITE) to which it has not yet generated an answer, the UAS MUST
   reject the UPDATE with a 500 response, and MUST include a Retry-After
   header field with a randomly chosen value between 0 and 10 seconds."

http://www.rfc-editor.org/rfc/rfc3311.txt

The 500 response to the UPDATE does indeed contain a Retry-After header. CUCM did generate an answer (see above) but SIP stack detects the last offer wasn't answered.  Although the Nortel PBX doesn't reattempt after x seconds, a related RFC states the UAC *may* reattempt but it's not a requirement. With that said, I'm wondering if anyone can help answer a few questions:


1.       Has anyone encountered this before?

2.       Bug toolkit doesn't return any good matches. Perhaps there's an internal defect?

3.       The 2nd 183 from CUCM (with no SDP) contains a CSeq header for the original INVITE from Nortel.
This is the most recent provisional from CUCM in response to the offer from Nortel.
My initial thought is CUCM is referring back to this 2nd 183 when determining no answer was generated for the last offer. This would explain the 500 response w/ Retry-After header and the SIP stack error stating that an answer has yet to be generated.
:: Note: Call-ID headers are confirmed to be consistent throughout the SDI traces reviewed
:: Note: The Allow header contains UPDATE
:: Note: CUBE is not involved in this call-flow

4.       Can anyone tell me what CCB is in the context of UAS response tables? Seeing quite a few "Adding to Response/Request Table" also piques my interest. Is there anything useful from a troubleshooting standpoint from these tables when the ccb=<ID> is identified and marked in Notepad++?

Thoughts?

Thanks ahead of time.

- Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140319/c34f31c5/attachment.html>