> -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Paul Kyzivat > Sent: 26 April 2011 22:42 > To: sipping@xxxxxxxx > Subject: Re: [Sipping] Late comment on > draft-ietf-sippping-sip-offeranswer-14 > > John, > > On 4/26/2011 9: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. > > It was precisely issues like this that led to the statements you are > taking issue with. > > As I understand it, what you describe is not permitted - you can't > reduce the number of m-lines, even by changing the o-line. [JRE] Where is that stated normatively? > > This does put a burden on the 3pcc device - to patch up the SDP. [JRE] This MIGHT be feasible, but it goes way beyond just manipulating version numbers. Basically the B2BUA would have to retain state about which m-lines are in use in each leg of the call (i.e., to B and to C) and perform mappings each time a SDP is passed through (e.g., the second m-line from B becomes the third m-line to C and vice versa). I wonder how many implementations do this today? > I would actually prefer to have a change that would loosen up > what can > be done in this regard but it would be a normative change with pretty > severe backward compatibility issues. > > > 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? > > I think you are describing "SessionS Initiation Protocol", not the > "Session Initiation Protocol". AFAIK you only get one session per > invite-dialog-usage. [JRE] Again, where is that stated normatively? > > > 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. > > I think the mechanism requires a normative change to SIP. [JRE] That depends - it is unclear to me what normative statements are broken by starting a new session with a new o-line. John > > But I'm interested to hear what others think about this. > > > A simple fix would be to delete the entire bullet beginning > "In the o-line, only the version number may change". > > Its awfully late - in the category of the "it ain't happening > unless you > lodge a complaint with the IESG". > > But regardless of that, it seems we have a difference of opinion here > about what the standard is, and should discuss it. > > Thanks, > Paul > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > Use sip@xxxxxxxx for new developments of core SIP > _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
