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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf