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

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: 26 April 2011 22:42
> To: [e-mail]
> 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>