-----Original Message----- From: Ettore Benedetti [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 1:18 AM To: [email protected]; Gummadidala, Ravi Subject: Re: [Sip-implementors] RFC3264 atomicity?
Hi Ravi, what Alice does in the case you showed is to accept the offer by replacing the current session with an inactive one, since all streams are rejected. Instead, Alice should reject the offer, so as to maintain the original audio exchange. The key point here is that rejecting an offer (with a non-2xx final response) is different from sending back an answer (in a 2xx) with all streams rejected. The latter does modify the session, the former does not. This explains how to reject an offer. How do we reject the answer? Once the UA generates an answer does its view of the session not change? It does not know whether the peer UA will accept/reject the answer. So depending on whether the peer UA accepts or rejects the answer the view of the session for the two UAs may be different. Am I missing something here? However, note that sometimes rejecting the offer as a whole is impossible. Think of a SIP response bearing it because of an empty-INVITE initiated transaction. The result has then to be brought back by the ACK, which has always to contain a successful and correct response. This somehow spoils the atomic property of the RFC3264 exchange. Regards, Ettore Ettore Benedetti THALES COMMUNICATIONS B.V. Bestevaer 46, 1271 ZA Huizen The Netherlands Unclassified >>> "Gummadidala, Ravi" <[EMAIL PROTECTED]> 9/8/05 7:23:16 PM >>> RFC3264 says that the offer/answer model is atomic. If the answer is rejected, the session reverts to the state prior to the offer (which may be absence of a session). Consider the following initial offer/answer exchange to setup a session v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 The callee, Bob, does not want to receive or send the first video stream, so he returns the SDP below as the answer: v=0 o=bob 2890844730 2890844730 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 49920 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 At some point later, Bob decides to change the audio payload format and offers the following SDP in the offer: v=0 o=bob 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 49920 RTP/AVP 100 a=rtpmap:100 EVRC/8000 m=video 0 RTP/AVP 31 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 Alice does not support EVRC and so generates the following answer which I think constitutes a rejection of Bob's modified offer v=0 o=alice 2890844526 2890844527 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 0 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 This causes the session to have no audio anymore. In the context of this example, what does "atomic" mean? Alice rejected Bob's modified offer however this rejection is done by generating an answer using the rules of RFC3264. Should both Alice and Bob now revert their view of the session to the one setup by the first offer/answer exchange? In other words, following this modified offer/answer do they still exchange audio using PCMU or no longer exchange any audio? -Ravi. _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
