Hi Daniel, from RFC 3262 (http://tools.ietf.org/html/rfc3262) page 4:
"The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. In addition, it MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field." The 183 you received is not technically a reliable provisional response thus the SDP does not constitute an official answer. Regarding why there is an SDP in a non-reliable provisional response... If you dig around the archives of sip-implementors and other sip oriented mailing lists you'll see numerous threads on what does it mean to have an SDP in a non-reliable provisional response and what happens if the real answer (in a reliable response, provisional or final) is different from the first SDP. The bottom line seemed to be from Postel's Law, "Be liberal in what you accept, and conservative with what you send." It's been a long time since I read any of those threads but my take on it was, you can try using the first SDP, and it might work, but it's not technically the completion of the offer/answer negotiation. And you can't attempt to renegotiate the session until the existing offer/answer is officially complete. Hope that helps, Joel On Tue, Feb 25, 2014 at 3:03 PM, Daniel Pagan <dpa...@fidelus.com> wrote: > Folks: > > I'm reviewing an issue involving a SIP integration and would like your > feedback on the behavior of the UAS in comparison with RFC 3311. To begin, > the call flow is as follows: > > UAC ==== UAS > >>> INVITE w/SDP offer > 100 Trying <<< > 183 w/ SDP answer <<< > >>> UPDATE w/SDP offer > 500 Internal Svr Error <<< > > The behavior we're suspicious about is the 500 response to the UAC's > UPDATE request. It's been confirmed that the 500 response was sent because > the UAS is waiting for the UAC to PRACK the 183 w/ SDP answer (this 183 > does not contain Require: 100rel). However, reading the sections "5.1 > Sending an UPDATE" and "5.2 Receiving an UPDATE" in RFC 3311 lead me to > believe the 500 response should not be sent in this call flow, and instead > the UAS should accept the UPDATE offer. I'm looking for some help in > clarifying whether or not this is correct and, if the UAS should accept the > UPDATE in this call flow, to provide vendor developers with some supporting > evidence in hopes of getting it corrected. > > The RFC sections I'm referring to: > > 5.1 Sending an UPDATE > ... for the caller: > o If the UPDATE is being sent before completion of the initial INVITE > transaction, and the initial INVITE contained an offer [true], the UPDATE > can contain an offer if the callee generated an answer in a reliable > provisional response [UAS sent 183 w/ SDPanswer?], and the caller has > received answers to any other offers it sent in either PRACK or UPDATE > [caller did not send other offers - does not apply], and has generated > answers for any offers it received in an UPDATE from the callee [no offers > were sent from callee]. > > ** The first two conditions appear to be true, and the caller has not sent > any other offers nor received other offers to which it did not answer. > Because the first two conditions apply and the last two aren't applicable, > it seems to me the UPDATE should be accepted by the UAS. > > 5.2 Receiving an UPDATE > 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. > > > ** The resulting 500 response from the UAS does in fact contain a > Retry-After header. However, the condition for sending this 500 response > that does not match our call flow states, "the UAS has received an offer to > which it has not yet generated an answer". In our call-flow, the UAS has > indeed answered the previous offer via 183 w/ SDP, which leads me to > believe the 500 response is not appropriate for this call-flow. > > One thing about this call-flow that might go against this theory is the > "reliable provisional" mentioned in the 1st section. Please correct me if > I'm wrong, but the "reliable provisional response" referenced by the first > RFC section above simply refers to our 183 w/SDP provisional message, > correct? In other words, when this RFC specifically mentions "if the callee > generated a reliable provisional response", does it automatically assume > 180/183 followed by PRACK or does it simply refer to a 180/183? > > Any assistance and clarification on this would be greatly appreciated. > Thanks ahead of time for reading through this and enjoy your day! > > - Daniel > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
