[cisco-voip] SIP Stack & Trace Question
Brian Meade (brmeade)
brmeade at cisco.com
Thu Feb 13 18:42:43 EST 2014
Daniel,
That seems to be correct from the RFCs I just took a quick look at. Would have to take a look in the SDLs to see if CUCM is actually putting the SIPInterface into a sessionEstablished state after it sends the 183 w/SDP. It may still be waiting for the Prack though before it marks it as sessionEstablished.
In the incoming Invite from the Nortel side, does it have 100rel in the supported or required headers?
Ideally, this would be our call flow:
A B
| |
|-------------(1) INVITE SDP1--------------->|
|<-----------(2) 100 Trying--------------------|
|<------(3) 183 Session Progress SDP2-----|
|-------------(4) PRACK---------------------->|
| |
|<--------(5) 200 OK (PRACK)----------------|
| |
|<----------(6) 183 Session Progress--------|
| |
|-----------------(7) PRACK------------------>|
| |
|<------------(8) 200 OK (PRACK)------------|
| |
|-------------(9) UPDATE SDP3-------------->|
| |
|<--------(10) 200 OK (UPDATE) SDP4------|
| |
| |
|<-----------(11) 200 OK (INVITE)------------|
| |
|------------------(12) ACK------------------->|
| |
Thanks,
Brian Meade
From: Daniel Pagan [mailto:dpagan at fidelus.com]
Sent: Thursday, February 13, 2014 6:16 PM
To: Brian Meade (brmeade); cisco-voip at puck.nether.net
Subject: RE: 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/20140213/11423dec/attachment.html>
More information about the cisco-voip
mailing list