Session Initiation Proposal Investigation (sipping)

Elwell, John | 26 Apr 2011 15:37

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

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

(Continue reading)

headers

Paul Kyzivat | 26 Apr 2011 23:41

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

This does put a burden on the 3pcc device - to patch up the SDP.

(Continue reading)

headers

Elwell, John | 27 Apr 2011 09:41

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


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

(Continue reading)

headers

DRAGE, Keith (Keith | 27 Apr 2011 11:17

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

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

(Continue reading)

headers

Elwell, John | 27 Apr 2011 14:36

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


> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:keith.drage <at> alcatel-lucent.com] 
> Sent: 27 April 2011 10:18
> To: Elwell, John; Paul Kyzivat; sipping <at> ietf.org
> 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 
> 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

(Continue reading)

headers

Robert Sparks | 27 Apr 2011 17:43

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

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

(Continue reading)