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

[Robert Sparks <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf