[cisco-voip] SIP Stack & Trace Question

[Daniel Pagan]

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/20140213/fd7b8d1b/attachment.html>