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
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
