Joel: Hope you're doing well. The 183 does not contain a RSeq or Require header. I can use built-in normalization scripts for inserting these headers, but this is after the provisional response is processed by the internal SIP stack, leading to the UAS throwing an error upon receipt of the PRACK w/ Rack.
This was very useful information so thanks again. For an immediate solution, we're likely going to insert a different SBC between the UAC and UAS in the call flow that's capable of sending a reliable provisional response... it's either this or temporarily convert this integration to H.323 with fast start while the vendor continues to work internally on this problem. I've sent a few of your comments to the vendor in hopes of getting this resolved at the development level. Thanks for the detailed response once again! - Daniel From: joeldod...@gmail.com [mailto:joeldod...@gmail.com] On Behalf Of Joel Dodson Sent: Tuesday, February 25, 2014 9:22 PM To: Daniel Pagan Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] UPDATE w/ Offer || RFC 3311 Hi Daniel, glad it was helpful. Sounds like you're stuck between a rock and hard place. Does the 183 contain an RSeq header? If the vendor cannot add require 100rel, do they actually include an RSeq? If not, you can't really send a PRACK (at least not a legitimate one). If the 183 does have an RSeq header but no require 100rel, that's a very odd stack. It sounds like the vendor either needs to fully implement reliable provisional responses or introduce another hack where they allow session renegotiation when they really shouldn't. And to expect someone to send a PRACK when there's no require 100rel just sounds crazy. How does this vendor inter-operate with anyone? I'd hesitate to try to get the vendor to support the UPDATE without receiving the PRACK. From a developers perspective, it's hard to believe introducing a hack like that is much less work than fully supporting reliable provisional responses. Considering they're expecting a PRACK, they must already have some support for reliable provisional responses, why not just finish the job. But the big problem is what do you do now. Assuming you can't switch vendors, and assuming you can't get them to make changes that meet your timeline, and assuming you have to get this working, I'd suggest making your UAC as compliant as possible in this situation. If they do include an RSeq header, assume that implies there's also a require 100rel header as well and proceed down the path of reliable provisional responses (send the PRACK). If they don't include an RSeq header, you'll probably want to ask their developers what they're expecting in the RAck header in the PRACK. You'll definitely want to keep this code isolated and don't start sending PRACKs to all provisional responses you receive. good luck, Joel On Tue, Feb 25, 2014 at 5:41 PM, Daniel Pagan <dpa...@fidelus.com<mailto:dpa...@fidelus.com>> wrote: Joel: Thanks for such a quick and informative response and I'll certainly dig around the archives as you suggested. If you don't mind, I'd like to close this with one final set of questions and scenario. The UAS involved in this call-flow is (currently) incapable of sending provisional responses with a Require header containing a 100rel option, so the 183 w/ SDP, as you mentioned below, technically does not fall under the category of reliable provisional responses. After reading the statement I quoted earlier once more, the following sentence stands out: "the UPDATE can contain an offer if the callee generated an answer in a reliable provisional response". So with that said, since the callee is not transmitting a true reliable provisional response to the caller, and is incapable of sending a provisional with Requires: 100rel, would you agree that the UAS in this scenario should not be requiring PRACK in order to accept the UPDATE? It's confirmed by vendor developers that the callee is requiring a PRACK for the 183 it transmitted, but without it being a true reliable provisional response, would you agree that the callee's SIP stack should not require the PRACK when the initial require ment simply isn't being achieved? It seems to me that RFC 3311 and 3262 clearly outline the requirements in order for this UPDATE to be accepted and the callee in our scenario is not meeting one of the those requirements, which leads me to think that requiring PRACK (in this scenario) at the UAS is a bit illogical. Thanks once more for your feedback, Joel! - Daniel From: joeldod...@gmail.com<mailto:joeldod...@gmail.com> [mailto:joeldod...@gmail.com<mailto:joeldod...@gmail.com>] On Behalf Of Joel Dodson Sent: Tuesday, February 25, 2014 6:46 PM To: Daniel Pagan Cc: sip-implementors@lists.cs.columbia.edu<mailto:sip-implementors@lists.cs.columbia.edu> Subject: Re: [Sip-implementors] UPDATE w/ Offer || RFC 3311 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<mailto: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<mailto: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
