I agree with Dale and Brett, sort of. Brett is right that the UAC is correct in ignoring the change in the 200. Dale is right that the UAS is wrong in sending different SDP in the 180 and 200.
See http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-13.txt Thanks, Paul On 2/10/2011 12:06 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: sip-implementors-boun...@lists.cs.columbia.edu > [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > bijoy.prak...@wipro.com [bijoy.prak...@wipro.com] > > What I want to confirm is that if this behaviour from the 3rd party is > proper that is changing the media port in 200 OK after sending another > port in 180 Ringing. > _______________________________________________ > > Assuming that the 180 and 200 have the same to-tag (and so are part of the > same early dialog), the behavior is improper. The SDP in a non-100rel > provisional response must be the same as the SDP in the 2xx response. See > RFC 3261 section 13.2.1: > > o 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. > > Dale > > _______________________________________________ > 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
