I believe the current text in the draft reflects the discussion from 2007 at <http://www.ietf.org/mail-archive/web/sipping/current/msg13812.html>
To summarize, while we think there may be implementations that interpret a change of session-id as a session reset, RFC3264 doesn't support the notion. The top-level assumption of 3264 is that there is one SDP session associated with a SIP dialog. (See in particular: <http://www.ietf.org/mail-archive/web/sipping/current/msg13845.html> <http://www.ietf.org/mail-archive/web/sipping/current/msg13870.html> and <http://www.ietf.org/mail-archive/web/sipping/current/msg13912.html>) The thread explores places where some folks would like to things to be different, but those things will need normative updates, probably to more than one RFC. I believe the text in the draft is consistent with what our current specs say. For the normative updates we would need to make for this particular topic, I think restarting the debate on the RAI list (with pointers to SIPCORE and MMUSIC) is the right thing to do. RjS On Apr 26, 2011, at 8:37 AM, Elwell, John wrote: > I know last call finished already, but the following has just been brought to > my attention: > > In section 5.2.5 > "Changing the o-line, > except version number value, during the session is an error case. > The behavior when receiving such a non-compliant offer/answer SDP > body is implementation dependent. " > I would content this is NOT an error situation, or at least not an error in > the case where a NEW session is being signalled. > > Consider a 3PCC situation along the lines described in section 7 of RFC 3725. > The controlling B2BUA converts a session between UA A and UA B into a session > between UA B and UA C. Prior to this conversion, UA B has received UA A's SDP > (SDP A). As a result of the conversion, UA B receives UA C's SDP (SDP C). > > SDP C is likely to be completely different from SDP A. Therefore just a > change of version number in the o-line is insufficient and would probably > violate RFC 3264. In particular, if SDP A has 2 m-lines and SDP C has only > one m-line, the change from 2 m-lines to 1 m-line is not permitted according > to RFC 3264. So although RFC 3725 talks about the controlling B2BUA adjusting > version numbers, that is insufficient in some cases. > > The text of 5.2.5 then goes on to say: > "The behavior when receiving such a non-compliant offer/answer SDP > body is implementation dependent." > It is not clear what this fails to comply with. I can find nothing in RFC > 3264 that stops you sending a new o-line if there is a new session. Yes, it > would be non-compliant if only modifying an existing session, but how does > the recipient know whether or not it is a new session, and therefore whether > or not it is valid? > > It then goes on to recommend use of Replaces in this situation (i.e. change > of session): > "If a UA needs to negotiate a > 'new' SDP session, it should use the INVITE/Replaces method." > But Replaces is not feasible if the UA concerned does not support it (and > hence "should", presumably). So there will still be cases where a controlling > B2BUA is forced to change the o-line (not just the version) in order to > comply with RFC 3264. > > So there needs to be a mechanism for changing to a 'new' session without > relying on Replaces. As far as I can see, there is no standards track RFC > that forbids changing the o-line to achieve this, so this new Informational > draft should not attempt to make that change, and in particular should not do > so without proposing an alternative solution. > > A simple fix would be to delete the entire bullet beginning "In the o-line, > only the version number may change". > > John > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
