Paul, I don't think Being strict with what you send and liberal with what you receive applies in this case. If only the version number differs, then treat it as stray would do the trick (since you should assume that getting a different version in the SDP should have the same effect if you process it or not). I am assuming that the UA is already sending RTP packets before the receipt of the 200 OK. Now, given that the 200 OK arrives with a different version... would you suggest that it affect the already established media stream in line with being liberal of what we receive since it clearly violates the specs? The only benefit in doing so is if not only the version was different but also the session description itself is different. In which case I would strongly favor sticking to the 183 SDP.
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. > > 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. > > 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
