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

[Elwell, John]

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
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Paul Kyzivat]

John,

Post by Elwell, John
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.

This does put a burden on the 3pcc device - to patch up the SDP.
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.

Post by Elwell, John
"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.

Post by Elwell, John
"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.

Post by Elwell, John
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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Elwell, John]

-----Original Message-----
Sent: 26 April 2011 22:42
Subject: Re: [Sipping] Late comment on
draft-ietf-sippping-sip-offeranswer-14
John,

Post by Elwell, John
I know last call finished already, but the following has
In section 5.2.5
"Changing the o-line,
except version number value, during the session is

an error case.

Post by Elwell, John
The behavior when receiving such a non-compliant

offer/answer SDP

Post by Elwell, John
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.

Post by Elwell, John
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).

Post by Elwell, John
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.

Post by Elwell, John
"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?

Post by Elwell, John
It then goes on to recommend use of Replaces in this
"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.

Post by Elwell, John
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.

Post by Elwell, John
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

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[DRAGE, Keith (Keith)]

What people should be doing and what people are doing as short cuts are two different things.

If a B2BUA (aka 3PCC) attempts to manipulate the SDP in any way shape or form, then it has to become responsible for the integrity of the SDP that results. It cannot just merge media lines and hope it gets away with it.

And I would not phrase that as patching up the SDP - the 3PCC has to become the SDP protocol entity. After all, RFC 3725 that you reference for this scenario states:

From here, new parties can be added, removed, transferred, and so on,
as the controller sees fit. In many cases, the controller will be
required to modify the SDP exchanged between the participants in
order to affect these changes. In particular, the version number in
the SDP will need to be changed by the controller in certain cases.
If the controller should issue an SDP offer on its own (for example,
to place a call on hold), it will need to increment the version
number in the SDP offer. The other participant in the call will not
know that the controller has done this, and any subsequent offer it
generates will have the wrong version number as far as its peer is
concerned. As a result, the controller will be required to modify
the version number in SDP messages to match what the recipient is
expecting.

To me this clearly indicates that the controller has become responsible for the SDP contents.

Regards

Keith

-----Original Message-----
Of Elwell, John
Sent: 27 April 2011 08:42
Subject: Re: [Sipping] Late comment on draft-ietf-sippping-sip-
offeranswer-14

-----Original Message-----
Sent: 26 April 2011 22:42
Subject: Re: [Sipping] Late comment on
draft-ietf-sippping-sip-offeranswer-14
John,

Post by Elwell, John
I know last call finished already, but the following has
In section 5.2.5
"Changing the o-line,
except version number value, during the session is

an error case.

Post by Elwell, John
The behavior when receiving such a non-compliant

offer/answer SDP

Post by Elwell, John
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.

Post by Elwell, John
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).

Post by Elwell, John
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.

Post by Elwell, John
"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?

Post by Elwell, John
It then goes on to recommend use of Replaces in this
"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.

Post by Elwell, John
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.

Post by Elwell, John
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

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Elwell, John]

-----Original Message-----
Sent: 27 April 2011 10:18
Subject: RE: [Sipping] Late comment on
draft-ietf-sippping-sip-offeranswer-14
What people should be doing and what people are doing as
short cuts are two different things.
If a B2BUA (aka 3PCC) attempts to manipulate the SDP in any
way shape or form, then it has to become responsible for the
integrity of the SDP that results. It cannot just merge media
lines and hope it gets away with it.

[JRE] Exactly, so it should do minimal manipulation, ideally none at all. So when B finds itself talking to A and then talking to C, B should receive first of all A's SDP and then C's SDP - these will have different o-lines. If the controller also generates its own SDP from time to time, e.g., for placing a session on hold, this will put the version numbers on the two legs out of step, and the controller will need to compensate for that - this is the example given in RFC 3725. But manipulation beyond that should not be necessary - it should just pass SDP through.

And I would not phrase that as patching up the SDP - the 3PCC
has to become the SDP protocol entity. After all, RFC 3725
From here, new parties can be added, removed, transferred,
and so on,
as the controller sees fit. In many cases, the controller will be
required to modify the SDP exchanged between the participants in
order to affect these changes. In particular, the version
number in
the SDP will need to be changed by the controller in certain cases.
If the controller should issue an SDP offer on its own
(for example,
to place a call on hold), it will need to increment the version
number in the SDP offer. The other participant in the
call will not
know that the controller has done this, and any subsequent offer it
generates will have the wrong version number as far as its peer is
concerned. As a result, the controller will be required to modify
the version number in SDP messages to match what the recipient is
expecting.

[JRE] This example talks about modifying version numbers, but I would claim that is not good enough. It would need to modify the rest of the o-line in order to prevent the recipient receiving SDPs with different o-lines. But I don't read that in RFC 3725.

To me this clearly indicates that the controller has become
responsible for the SDP contents.

[JRE] In my opinion the text of RFC 3725 is not clear - it talks about the controller modifying SDP, and the particular example given just talks about modifying the version number. Yet what Keith seems to be claiming is that the controller does more than that - implying that the controller generates its own SDP based on some information received in SDP from the remote party.

John

Regards
Keith

-----Original Message-----
Of Elwell, John
Sent: 27 April 2011 08:42
Subject: Re: [Sipping] Late comment on draft-ietf-sippping-sip-
offeranswer-14

-----Original Message-----
Sent: 26 April 2011 22:42
Subject: Re: [Sipping] Late comment on
draft-ietf-sippping-sip-offeranswer-14
John,

Post by Elwell, John
I know last call finished already, but the following has
In section 5.2.5
"Changing the o-line,
except version number value, during the session is

an error case.

Post by Elwell, John
The behavior when receiving such a non-compliant

offer/answer SDP

Post by Elwell, John
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.

Post by Elwell, John
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).

Post by Elwell, John
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.

Post by Elwell, John
"The behavior when receiving such a non-compliant

offer/answer SDP

Post by Elwell, John
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?

Post by Elwell, John
It then goes on to recommend use of Replaces in this
"If a UA needs to negotiate a
'new' SDP session, it should use the

INVITE/Replaces method."

Post by Elwell, John
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.

Post by Elwell, John
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.

Post by Elwell, John
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

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Robert Sparks]

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

Post by Elwell, John
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 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?
"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
https://www.ietf.org/mailman/listinfo/ietf