For the benefit of the doubter ... Media sessions can only be changed if the change was offered. 3261 allowed provisional responses which can provide none reliable preview of the answer. What is not clear was if the preview would be treated as the final response in case it reached the UAC. Let us say the 183 did not reach the uac and the 200 Ok and the 183 (which did not reach the UAC ) contained different versions, what would be the mechanism of the UAC that the SDP is different?
Dmitry Akindinov wrote: > Hello, > > Paul Kyzivat wrote: > >> The specs say that the SDP in the 183 and the 200 must be the same. They >> do not say what to do if they are different. Nor do they require the >> recipient to check if they are different. >> >> The maxim of "be conservative in what you send, liberal in what you >> accept" can help here, but only to a point. Being liberal in what you >> accept only helps if the *way* you choose to be liberal is consistent >> with the way the sender violated the rules. >> >> In this case you can be liberal in (at least) two ways: >> >> - process the 183, and then ignore what is in the 200, assuming >> it will be the same. >> >> - process the 183, then when the 200 arrives process that as well >> as if you had never received the 183. >> > > This appears the best approach: to treat SDP in 18x and 200 > independently. E.g. after a forking proxy there may be several reliable > 18x with different SDPs from different sources and then 200 with a new > SDP from a completely new source. The payload in the final response is > what matters for the dialog to be set up. > > >> Of course the problem is that the sender who sends different values in >> the 183 and the 200 doesn't know *if* that will be allowed by the >> recipient, nor what the result will be if it is allowed. Rather than >> concentrating on what the recipient should do, it would be better for >> you to concentrate on ensuring that you send the right thing. >> > > The senders may be independent from each other (two or more devices > registered to same AOR). > > >> Paul >> >> Brett Tate wrote: >> >>>> I think, the UE should not reject the call based >>>> on this problem with the SDP. >>>> >>> I agree. However in general, a vendor can of course choose to enforce >>> strict compliance when considered necessary. However such strict >>> enforcement can cause interop problems with those not yet fully >>> compliant to a particular RFC. >>> >>> >>> >>>> It must not consider the answer in non-reliable >>>> response as final and should be able to process >>>> 200 Ok sdp as the final one. >>>> >>> RFC 3261 section 13.2.1 bullet 2 is somewhat ambiguous about how things >>> should be processed if the "preview" SDP is different from the answer >>> SDP. Because of the wording of the last sentence, it could be >>> interpreted as the "preview" SDP takes precedence over the answer SDP if >>> they are different. And I don't recall if >>> http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-02 >>> provides any further guidance concerning the matter beyond indicating >>> that they must be the same. >>> >>> RFC 3261 section 13.2.1 bullet 2: >>> "If the initial offer is in an INVITE, the answer MUST be in a reliable >>> non-failure message from UAS back to UAC which is correlated to that >>> INVITE. For this specification, that is only the final 2xx response to >>> that INVITE. That same exact answer MAY also be placed in any >>> provisional responses sent prior to the answer. The UAC MUST treat the >>> first session description it receives as the answer, and MUST ignore any >>> session descriptions in subsequent responses to the initial INVITE." >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
