Re: Late comment on draft-ietf-sippping-sip-offeranswer-14

> -----Original Message-----
> From: sipping-bounces@...
> [mailto:sipping-bounces@...] On Behalf Of Paul Kyzivat
> Sent: 26 April 2011 22:42
> To: sipping@...
> 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.

> 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.

>
> > 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.

>
> 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@... for questions on current sip
> Use sip@... for new developments of core SIP
>