Using the same "o=" line for different SDPs violates RFC 4566 section 5.2.
"<sess-version> is a version number for this session description. Its usage is up to the creating tool, so long as <sess-version> is increased when a modification is made to the session data. Again, it is RECOMMENDED that an NTP format timestamp is used." " In general, the "o=" field serves as a globally unique identifier for this version of this session description, and the subfields excepting the version taken together identify the session irrespective of any modifications. For privacy reasons, it is sometimes desirable to obfuscate the username and IP address of the session originator. If this is a concern, an arbitrary <username> and private <unicast-address> MAY be chosen to populate the "o=" field, provided that these are selected in a manner that does not affect the global uniqueness of the field." From: satish agrawal [mailto:[email protected]] Sent: Tuesday, July 02, 2013 2:21 AM To: Brett Tate Cc: Paolo Nardi; [email protected] Subject: Re: [Sip-implementors] Increasing SDP version number after a previous Offer has been rejected Extract from RFC 3264, The agent receiving the offer MAY generate an answer, or it MAY reject the offer. The means for rejecting an offer are dependent on the higher layer protocol. The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the offer (which may be absence of a session). Means if the offer is rejected with 488 then it should used the same "o=" line. Thanks, Satish On Mon, Jul 1, 2013 at 3:28 PM, Brett Tate <[email protected]<mailto:[email protected]>> wrote: > In case an Offer modification is issued after a previous > modification was rejected (e.g. re-INVITE answered with > 488), should SDP version number increase by 1 wrt the > previous Offer? Or should it increase by 1 wrt the SDP > for which the Offer/Answer model was closed before the > first re-INVITE? >From an Offer/Answer perspective, either would likely work. However from an >RFC 4566 perspective, it is incorrect to use the same origin line for a >different SDP. Thus assuming that the SDP is different from both the >successful and subsequent unsuccessful offer/answer negotiation, the SDP >origin line version number would be higher than both. And for completeness... since the UAS might not see all the prior SDP versions, it should allow the SDP version to increase by more than 1. _______________________________________________ Sip-implementors mailing list [email protected]<mailto:[email protected]> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- Thanks & Regards Satish Agrawal New Delhi-24. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
