Subject: Re: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer

From: Joerg Ott <[email-masked]>
Date: Thu, 02 Nov 2006 16:24:12 +0200

Hi Francois,

sorry for the response delay.  I just returned from travel and did not
have connectivity during the recent mail flood.  I'll respond to this
one and then try to work my way backwards.

> Perhaps a simple statement upfront to clarify it would help.
> 
> For example, the  first paragraph of Page 7 currently state:
> 
>    Different RTP profiles MAY be used in different media sessions.
>    For negotiation of a media description, the four profiles AVP,
>    AVPF, SAVP, and SAVPF are mutually exclusive.  Note, however, that
>    SAVP and SAVPF entities MAY be mixed in a single RTP session (see
>    section 4).  Also, the offer/answer mechanism MAY be used to offer
>    alternatives for the same media session (e.g. using the same
>    transport parameters) and allow the answered to choose one of the
>    profiles.
> 
> It could be emphasised that what you are really saying is that the
> alternatives are using multiple media descriptions (i.e., multiple m
> lines)
> in a single media session. Something like:
> 
>    Different RTP profiles MAY be used in different media sessions.
>    For negotiation of a media description, the four profiles AVP,
>    AVPF, SAVP, and SAVPF are mutually exclusive.  Note, however, that
>    SAVP and SAVPF entities MAY be mixed in a single RTP session (see
>    section 4).  Also, the offer/answer mechanism MAY be used to offer
>    alternatives for the same media session (e.g. using the same
>    transport parameters and multiple media descriptions) and allow 
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    the answered to choose one of the profiles.

That could work.

> Also, in section 1.1, the description of (SDP) media description could
> be clarified with something like:
> 
>    (SDP) media description:
>         This term refers to the specification given in a single m=
>         line in an SDP message.  An SDP media description may define
>         only one RTP session.  Grouping of m= lines in SDP (each with 
>                                                            ^^^^^^^^^^
>         their own distinct transport address as described in [9]) may
> cause
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         several SDP session level descriptions to define (alternatives
>         of) the same RTP session for the same media type.
>  
> Or something along those lines.

Adding this sentence would kill one interesting use case: For example,
AVP and AVPF can work in the same session in a mixed operation (while
AVO anf SAVP cannot).  For mixed operation to be possible, however,
these tools MUST use the same transport addresses.

Therefore, the above description needs to be a bit more explicit about
what it allows in order not to defeat perfectly legitimate use cases.

But you brought up an important point for which I need to scan the
draft spec in depth.  I will collect further items from the other
mails and reply one by one (but this may take a day or two) and
then hopefully get a revised spec within two weeks or so that reflects
these clarifications.

Thanks,
Joerg

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 2 Nov 2006 15:47:59 -0600

> Adding this sentence would kill one interesting use case: For 
> example, AVP and AVPF can work in the same session in a mixed 
> operation (while AVO anf SAVP cannot).  For mixed operation 
> to be possible, however, these tools MUST use the same 
> transport addresses.

So you are speaking in favor of port overloading?

Am I misunderstanding you?

What I am worried about is RFCs allowing port overloading, and others
saying it's illegal.

> Therefore, the above description needs to be a bit more 
> explicit about what it allows in order not to defeat 
> perfectly legitimate use cases.
> 
> But you brought up an important point for which I need to 
> scan the draft spec in depth.  I will collect further items 
> from the other mails and reply one by one (but this may take 
> a day or two) and then hopefully get a revised spec within 
> two weeks or so that reflects these clarifications.
> 
> Thanks,
> Joerg
> 
> 
>

---

From: Joerg Ott <[email-masked]>
Date: Fri, 03 Nov 2006 00:10:08 +0200

> So you are speaking in favor of port overloading?

No.

> Am I misunderstanding you?

Yes.

> What I am worried about is RFCs allowing port overloading, and others

Please distinguish between:

1) the same transport address being indicated in otherwise explicitly
    grouped media session (grouped using some fid + whathaveyou
    attribute)

2) the same port number being used to infer grouping.

These two things are fundamentally different.  What I am saying is that
there are legitimate use cases for 1) while all of us agree that we do
not want 2).

One reason for confusion appears to be one example in RFC 4585
from which I would not want to try and infer 1) but some people might
be able to even though it states that you should do explicit grouping
(but cannot list it in the example as the respective attribute does
not yet exist).

The other reason for confusion is RFC 3388 which wants to prevent people
from using multiple m= lines to specify alternate codecs but phrases
this in a way that you could construe as "do not use the same transport
address for two m= lines".

And we have RFC 4566 which states that two m= lines with the same
transport address do not imply grouping and that their semantics is
undefined -- obviously until you define something meaningful.

This is where I think we are.  All we need to do is to define a
proper grouping.

Joerg

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Nov 2006 14:25:05 -0800

> > What I am worried about is RFCs allowing port overloading, 
> > and others saying it's illegal.
> 

I agree that would be the cleanest, architecturally.

But unless the endpoint understands the grouping syntax and 
semantics, the new syntax and semantics are invisible to such
an endpoint.  I mean, that is the problem with RFC3388 -- if
you send RFC3388 SDP to an endpoint that doesn't understand
RFC3388 it will parse the SDP following normal SDP rules
which say each m= line is a separate RTP session.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 2 Nov 2006 16:37:20 -0600

Ok, I understand what you are saying now.

But I don't think this is clear at all in those documents.

The dependency on media grouping needs to be made obvious. Otherwise,
it looks to the reader like it is using port overloading without
media grouping.

> -----Original Message-----
> From: Joerg Ott [mailto:[email-masked]] 
> Sent: Thursday, November 02, 2006 2:10 PM
> To: Audet, Francois (SC100:3055)
> Cc: Joerg Ott; [email-masked]; [email-masked]; 
> [email-masked]; Joerg Ott; Flemming Andreasen; Dan Wing
> Subject: Re: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer
> 
>

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 2 Nov 2006 16:39:25 -0800

> > (but cannot list it in the example as the respective attribute does
    RFC4585 did list 1) as a sample option. 
     "A sample framework by which this can be achieved is defined in
[10]."

> > undefined -- obviously until you define something meaningful.

RFC 4566 did list 1) as an option (Of course, not normative)

"an explicit grouping framework (for example, [18]) should instead
 be used to express the intended semantics."

> which say each m= line is a separate RTP session.

This is a fundamental problem with FID semantics defined in RFC3388 and
sec 8.4.2 describes how to address this issue.

Sec 8.4.2 of RFC3388 suggests that the offer re-try without "group".
That may not look good, but is not too bad either. Those end points
which crash when they look at transport overloaded "m=" lines are
anyways faulty s/w implementations and it is unlikely that majority of
deployed s/w is unstable to such an extent. And with the (majority of
good) end points that do not crash, it is possible to continue the
session.
 
In any case, not supporting the fallback approach suggested by RFC3388
is risky.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Nov 2006 20:52:05 -0800

> This is a fundamental problem with FID semantics defined in 
> RFC3388 and sec 8.4.2 describes how to address this issue.
> 
> Sec 8.4.2 of RFC3388 suggests that the offer re-try without 
> "group".  That may not look good, but is not too bad either. 

That probably works alright with RTSP, but doesn't work with SIP forking due
to HERFP (Heterogeneous Error Response Forking Problem).

-d

> Those end points which crash when they look at transport 
> overloaded "m=" lines are anyways faulty s/w implementations 
> and it is unlikely that majority of deployed s/w is unstable 
> to such an extent. And with the (majority of good) end points 
> that do not crash, it is possible to continue the session.
>

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 3 Nov 2006 13:01:51 -0800

> "group".  
> > That may not look good, but is not too bad either.
> 
> That probably works alright with RTSP, but doesn't work with 
> SIP forking due to HERFP (Heterogeneous Error Response 
> Forking Problem).
> 

HERFP is a problem with SIP that anyways needs to be solved at some
other place. 

> -d
> 
> 
> > Those end points which crash when they look at transport overloaded 
> > "m=" lines are anyways faulty s/w implementations and it is 
> unlikely 
> > that majority of deployed s/w is unstable to such an 
> extent. And with 
> > the (majority of good) end points that do not crash, it is 
> possible to 
> > continue the session.
> >

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Nov 2006 13:39:40 -0800

> HERFP is a problem with SIP that anyways needs to be solved at some

I admit to not following it closely, but it seems HERFP hasn't yet
been solved in SIP or SIPPING.

However, let's assume, for a minute, that HERFP is solved.  If my
endpoint supports supports RTP, SRTP, feedback, and running RTP over
DCCP or over UDP, I would need to send an SDP that contains 8 m-lines
(RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF, DCCP/RTP/AVP, DCCP/RTP/SAVP,
DCCP/RTP/AVPF, DCCP/RTP/SAVPF), and each m-line would have duplicated
ICE attributes for all of the UDP transports and all of the
m-lines would have duplicated codec attributes.  This makes for a
_very_ long SDP, and requires anyone receiving it to understand
port overloading.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Nov 2006 16:41:18 -0600

Actually let's NOT assume HERFP is solved...

> From: Dan Wing [mailto:[email-masked]] 
> Sent: Friday, November 03, 2006 1:40 PM
> To: 'Desineni, Harikishan'
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer
> 
> > > That probably works alright with RTSP, but doesn't work with SIP 
> > > forking due to HERFP (Heterogeneous Error Response 
> Forking Problem).
> > 
> I admit to not following it closely, but it seems HERFP 
> hasn't yet been solved in SIP or SIPPING.
> 
> However, let's assume, for a minute, that HERFP is solved.  
> If my endpoint supports supports RTP, SRTP, feedback, and 
> running RTP over DCCP or over UDP, I would need to send an 
> SDP that contains 8 m-lines (RTP/AVP, RTP/AVPF, RTP/SAVP, 
> RTP/SAVPF, DCCP/RTP/AVP, DCCP/RTP/SAVP, DCCP/RTP/AVPF, 
> DCCP/RTP/SAVPF), and each m-line would have duplicated ICE 
> attributes for all of the UDP transports and all of the 
> m-lines would have duplicated codec attributes.  This makes 
> for a _very_ long SDP, and requires anyone receiving it to 
> understand port overloading.
> 
> -d
>

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 3 Nov 2006 15:36:00 -0800

> _very_ long SDP, and requires anyone receiving it to understand

Agreed

>From standards perspective, we have to keep the port overloading a valid
concept when an end point supports only AVP and AVPF (due to RFCs 4585
and 4566). This does not mean that alternate signaling (Flemming's
draft) cannot be used for the same purpose. IMO, Felmming's draft should
put more details on port overloading when an end point supports only AVP
and AVPF. It might be acceptable if the draft recommends that grouping
be not used when the proposed (compact) signaling is available. This
would result in less (or NO) confusion from a set of existing standard
documents (RFCs:3388,4566,4585 and RFC No for Flemming's draft).

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Nov 2006 16:35:45 -0800

> > DCCP or over UDP, I would need to send an SDP that contains 
> > 8 m-lines (RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF, DCCP/RTP/AVP, 
> > DCCP/RTP/SAVP, DCCP/RTP/AVPF, DCCP/RTP/SAVPF), and each m-line 
> > would have duplicated ICE attributes for all of the UDP 
> > transports and all of the m-lines would have duplicated 
> > codec attributes.  This makes for a _very_ long SDP, and 
> > requires anyone receiving it to understand port overloading.
> 
> Agreed
> 
> From standards perspective, we have to keep the port 
> overloading a valid concept when an end point supports 
> only AVP and AVPF (due to RFCs 4585 and 4566). 

But the standards contradict each other, and do not support port overloading
as a valid concept.  

Specifically, RFC4566 (SDPnew) says:

  The semantics of multiple "m=" lines using the same transport
  address are undefined.  This implies that, unlike limited past
  practice, there is no implicit grouping defined by such means and
  an explicit grouping framework (for example, [18]) should instead
  be used to express the intended semantics.

[18] is RFC3388 (grouping).  As we have discussed, RFC3388 explicitly
disallows using the same port on multiple media lines, and RFC3388 does not
contain an exception to that rule for different RTP profiles.

It may have been the intent of RFC4566 to allow port overloading with
grouping by non-normatively citing grouping, but there is no mistaking
section 7.5.3 of RFC3388 which clearly says this is illegal.

> This does not mean that alternate signaling (Flemming's draft)
> cannot be used for the same purpose.  IMO, Felmming's draft should
> put more details on port overloading when an end point supports only
> AVP and AVPF. It might be acceptable if the draft recommends that
> grouping be not used when the proposed (compact) signaling is
> available.  This would result in less (or NO) confusion from a set
> of existing standard documents (RFCs:3388,4566,4585 and RFC No for
> Flemming's draft).

-d

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 3 Nov 2006 21:35:57 -0800

> > From standards perspective, we have to keep the port overloading a 
> > valid concept when an end point supports only AVP and AVPF (due to 
> > RFCs 4585 and 4566).
> 
> But the standards contradict each other, and do not support 
> port overloading as a valid concept.  
> 

Interpretation: In the absence of grouping, transport overloading does
not signal implicit grouping and the semantics are undefined. Explicit
grouping is allowed however semantics need to be expressed.

> [18] is RFC3388 (grouping).  As we have discussed, RFC3388 
> explicitly disallows using the same port on multiple media 
> lines, and RFC3388 does not contain an exception to that rule 
> for different RTP profiles.
> 
> It may have been the intent of RFC4566 to allow port 
> overloading with grouping by non-normatively citing grouping, 
> but there is no mistaking section 7.5.3 of RFC3388 which 
> clearly says this is illegal.

RFC 3388 is based on an obsoleted (very old)SDP RFC 2327. Its semantics
on transport overloading contradict with the latest SDP RFC 4566 (SDP
new), which allows transport overloading.

>From RFC4585 (RTPAVPF profile)

 Note that these two m= lines SHOULD be grouped by some appropriate
   mechanism to indicate that both are alternatives actually conveying
   the same contents.  A sample framework by which this can be
   achieved is defined in [10].

[10] is RFC3388. Based on the RFC4566 (SDP new) non-normative citing
which allows transport overloading with explicit grouping, RFC4585
suggested such usage with clear semantics "to indicate that both are
alternatives actually conveying the same contents". Hence, RFC4585 is
properly following RFC4566 by defining the semantics for explicit
grouping. It makes sense why explicit grouping is of "SHOULD" strength
here.

RFC3388 has defined its own grouping semantics (disallowing transport
overloading) when multiple codecs are targeted to one port. Of course,
it also denied transport overloading in general(probably unwantedly, as
it does not know about RFC4566-SDP new). RFC3388 and its explcit
grouping semantics are not correct with respect to latest SDP RFC 4566.
RFC3388 is correct only with respect to obsolted SDP RFC2327.

To conclude, 

RFC4585 is not the culprit as it is compliant with what was stated in
SDP new (RFC4566).

The root cause for this confusion is RFC3388, which is based on an
obsolted SDP RFC 2327. 

RFC3388 is contradicting with RFC4566 (SDP new). This is due to
advancement of SDP after the publication of RFC3388.

Also, RFC3388 is correct with respect to its normative and informative
references.

Given the above, any argument based on RFC3388 does not hold strong
here.

> 
> > This does not mean that alternate signaling (Flemming's 
> draft) cannot 
> > be used for the same purpose.  IMO, Felmming's draft should 
> put more 
> > details on port overloading when an end point supports only AVP and 
> > AVPF. It might be acceptable if the draft recommends that 
> grouping be 
> > not used when the proposed (compact) signaling is available.  This