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

From: Randell Jesup <[email-masked]>
Date: Tue, 31 Oct 2006 18:27:23 -0500

"Desineni, Harikishan" <[email-masked]> writes:
>> > Indeed, RFC4585 is referring to RFC 3388 for such grouping.  Per
>> > RFC4585, overloading two "m=" lines isn't a violation of the standard
>> > when negotiating RTP/AVP and RTP/AVPF profiles.
>> 
>> Unfortunately, though, SDP parsers that don't implement
>> RFC4585 aren't aware of RFC4585's permission to do this.
>
>A reasonably good SDP parser which understands grouping (RFC3388) and
>FID semantics would reject a grouped "m=" line offered with unknown RTP
>profile. 

There's an SDP parser (and application) that understands and handles RFC 3388?
1/2 :-)  Seriously, I'm sure there are some, and I'm also pretty darn certain
they're rare.  I'd love it if I was wrong.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

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

---

From: Randell Jesup <[email-masked]>
Date: Tue, 31 Oct 2006 18:27:23 -0500

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 31 Oct 2006 14:26:34 -0800

> > RFC4585, Section 4.4, Example 3 allows grouping of media
> > lines with the same transport address and port. I copied
> > it below FYI.  Even though RFC 3388 prohibits such
> > transport overloading, RFC 4585 allows such signaling for
> > profile negotiation (between RTP/AVP and RTP/AVPF).
> 
> Are we going to declare RFC4585's example normative?

It is already of "SHOULD" strength, which is quite strong.

> 
> > Indeed, RFC4585 is referring to RFC 3388 for such grouping.
> > Per RFC4585,
> > overloading two "m=" lines isn't a violation of the standard when
> > negotiating RTP/AVP and RTP/AVPF profiles.
> 

> 
> > It is an already established
> > concept in RFC4585. Probably there are existing implementations
which
> > already support such signaling. Any new signaling solution can only
be
> > an alternative to the solution used in the following example.
> 
> Is there consensus in MMUSIC with that position?

I expect that it would be the case, given that the signaling described
in RFC4585 is of "SHOULD" strength. IMHO, new/better signaling from
MMUSIC can only be an alternative to RFC4585 example that was pointed
out.

> 
> -d
> 
> 
> > --->
> >   m=video 51372 RTP/AVP 98 99
> >       c=IN IP4 224.2.1.184
> >       a=rtpmap:98 H263-1998/90000om ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf24H-0000Q5-Au
	for [email-masked]; Tue, 31 Oct 2006 17:26:51 -0500
Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 14:26:34 -0800
From: "Desineni, Harikishan" <[email-masked]>
To: "Dan Wing" <[email-masked]>, "Joerg Ott" <[email-masked]>,
	"Francois Audet" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], "Srinivasamurthy,
	Naveen" <[email-masked]>, "Jayaram, Ranjith" <[email-masked]>,
	Flemming Andreasen <[email-masked]>, Joerg Ott <[email-masked]>,
	"Ludwin, Albert" <[email-masked]>, "Leung,
	Nikolai" <[email-masked]>
Subject: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer

> > RFC4585, Section 4.4, Example 3 allows grouping of media
> > lines with the same transport address and port. I copied
> > it below FYI.  Even though RFC 3388 prohibits such
> > transport overloading, RFC 4585 allows such signaling for
> > profile negotiation (between RTP/AVP and RTP/AVPF).
> 
> Are we going to declare RFC4585's example normative?

It is already of "SHOULD" strength, which is quite strong.

> 
> > Indeed, RFC4585 is referring to RFC 3388 for such grouping.
> > Per RFC4585,
> > overloading two "m=" lines isn't a violation of the standard when
> > negotiating RTP/AVP and RTP/AVPF profiles.
> 

> 
> > It is an already established
> > concept in RFC4585. Probably there are existing implementations
which
> > already support such signaling. Any new signaling solution can only
be
> > an alternative to the solution used in the following example.
> 
> Is there consensus in MMUSIC with that position?

I expect that it would be the case, given that the signaling described
in RFC4585 is of "SHOULD" strength. IMHO, new/better signaling from
MMUSIC can only be an alternative to RFC4585 example that was pointed
out.

> 
> -d
> 
> 
> > --->
> >   m=video 51372 RTP/AVP 98 99
> >       c=IN IP4 224.2.1.184
> >       a=rtpmap:98 H263-1998/90000
> >       a=rtpmap:99 H261/90000
> >       m=video 51372 RTP/AVPF 98 99
> >       c=IN IP4 224.2.1.184
> >       a=rtpmap:98 H263-1998/90000
> >       a=rtpmap:99 H261/90000
> >       a=rtcp-fb:* nack
> >       a=rtcp-fb:98 nack rpsi
> > 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].
> >
> >

> >       a=rtpmap:99 H261/90000
> >       m=video 51372 RTP/AVPF 98 99
> >       c=IN IP4 224.2.1.184
> >       a=rtpmap:98 H263-1998/90000
> >       a=rtpmap:99 H261/90000
> >       a=rtcp-fb:* nack
> >       a=rtcp-fb:98 nack rpsi
> > 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].
> >
> >

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 16:31:25 -0800

> It is already of "SHOULD" strength, which is quite strong.

But using the same IP address/port violates two MUST NOTs in RFC3388:

   If several codecs have to be sent to the same IP address and port,
   the traditional SDP syntax of listing several codecs in the same "m"
   line MUST be used.  FID MUST NOT be used to group "m" lines with the
   same IP address/port.  Therefore, an SDP like the one below MUST NOT
   be generated.

Also, RFC4585's reference to RFC3388 is informational, not normative.  So
RFC4585 can't be trying to override RFC3388's section which prohibits this.

> FID semantics would reject a grouped "m=" line offered with 
> unknown RTP profile. 

RFC3388 is very clear in its prohibition of m= lines with matching 
IP address/port.  It's unclear, from RFC3388, what an SDP parser
is supposed to do if receives SDP described in section 7.5.3 of 
RFC3388 -- no matter if it understands the RTP profile.

Worse, an SDP parser that doesn't understand RFC3388 is left to
its own devices as to the meaning of two m= lines with the same
IP address and port -- it's undefined.  

> > > already support such signaling. Any new signaling 
> > > solution can only be

I expect this will be an active discussion at the upcoming MMUSIC
session in San Diego.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Nov 2006 10:36:24 -0800

(removed most of the CC list, as MMUSIC's mailman configuration was
complaining about too many recipients.)

...
> However, we are discussing a slightly different SDP offer 
> where the two "m=" lines differ in RTP profiles, which is 
> clearly not in the scope if RFC3388 as such SDP offer 
> was probably not a possibility at the time of its writing. 

RTP/SAVP existed at the time RFC3388 was written.  

draft-ietf-avt-srtp-00, which defined RTP/SAVP, was a WG 
document in February 2001.  draft-ietf-mmusic-fid-06, which
is the last document prior to RFC, was published in February
2002 -- a year after SAVP was an AVT working group item.

But I doubt the problems of multiple RTP profiles signaled 
in offer/answer were well understood at the time RFC3388
was written.  Was was understood, when RFC3388 was written,
was that a non-RFC3388-aware SDP parser would have unknown
behavior if it received two "m=" lines with the same IP
address and port -- that's why RFC3388 prohibited it.

In any event, section 7.5.3 of RFC3388 doesn't provide an 
escape clause allowing grouping different RTP profiles with 
the same port number.

> RFC4585 went ahead and suggested a potential solution based
> on the grouping concept presented in RFC3388.
>
> I am not against better signaling applicable to all RTP profiles. I'd
> like to emphasize that RFC4585 has already published a suggested
> solution with (IP address, port) overloading with the help of few
> examples, which are unarguably valid when signaling a stream with both
> AVP and AVPF profiles.

I don't agree, but that's fine.

Do we agree with the disadvantages of grouping as described
in Flemming's 
draft-andreasen-mmusic-sdp-capability-negotiation-01.txt section 3.1?

-d

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Wed, 1 Nov 2006 12:31:20 -0800

> I don't agree, but that's fine.

Let me be more clear here. I support (IP address,port) overloading due
to the examples and the "SHOULD" requirement in RFC4585. It gives an
impression that grouping is encouraged when signaling AVPF profile.

Section 3 (Review of existing work) of Flemming's draft did not address
the details presented in RFC4585. Hence the review presented in that
section is currently incomplete. It would be better to update the draft
with the fact that RFC4585 allows grouping with transport address and
port overloading (Note: RFC4585 has some examples with transport
overloading while using AVPF)and add more analysis resulting from
considering RFC4585.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Nov 2006 12:55:34 -0800

> impression that grouping is encouraged when signaling AVPF profile.

Yes, I believe I understand your viewpoint.

> Section 3 (Review of existing work) of Flemming's draft did 
> not address the details presented in RFC4585.  Hence the review 
> presented in that section is currently incomplete.  It would be 
> better to update the draft with the fact that RFC4585 allows 
> grouping with transport address and port overloading (Note: 
> RFC4585 has some examples with transport overloading while 
> using AVPF) and add more analysis resulting from 
> considering RFC4585.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 1 Nov 2006 19:16:17 -0600

This is all very interesting, but the real issue is that RFC 4585
contradicts 
RFC 3388. 

RFC 3388 is pretty clear about port overloading (i.e., Thou Shalt Not).

RFC 4585 "allows" it almost by accident.

One of those draft is wrong and needs an errata.

Other people have tried to make the case for port overloading (including
Dan and myself). Flemming also discussed it in his own draft. Then there

are places where people "think" port overloading is allowed, but it is 
actually not true.

I agree with Dan: this really needs to be discussed in San Diego. Right
now,
this is really a free-for-all.

> -----Original Message-----
> From: Desineni, Harikishan [mailto:[email-masked]] 
> Sent: Wednesday, November 01, 2006 12:31 PM
> To: Dan Wing
> Cc: Flemming Andreasen; [email-masked]; [email-masked]
> Let me be more clear here. I support (IP address,port) 
> overloading due to the examples and the "SHOULD" requirement 
> in RFC4585. It gives an impression that grouping is 
> encouraged when signaling AVPF profile.
> 
> not address the details presented in RFC4585. Hence the 
> review presented in that section is currently incomplete. It 
> would be better to update the draft with the fact that 
> RFC4585 allows grouping with transport address and port 
> overloading (Note: RFC4585 has some examples with transport 
> overloading while using AVPF)and add more analysis resulting 
> from considering RFC4585.
> 
> > 
> > Do we agree with the disadvantages of grouping as described in 
> > Flemming's draft-andreasen-mmusic-sdp-capability-negotiation-01.txt 
> > section 3.1?
> > 
> > -d
> > 
>

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Wed, 1 Nov 2006 10:11:48 -0800

> RFC4585 can't be trying to override RFC3388's section which prohibits
this.

Irrespective of the whether the reference is normative or informative, 
RFC4585 allows the grouping using RFC3388 as a choice.

RFC 3388 lists RTP RFC (1889) as an informative reference. That does not
mean that RFC3388 is not so serious about RTP RFC and all the "MUST" and
"MUST NOT" statements. The definition of "SHOULD" in RFC2119 does not
limit its strength based on whether a reference is informative or
normative. So I do not quite agree with your statement on the
interpretation of "SHOULD" over informative references.

> RFC3388 -- no matter if it understands the RTP profile.
RFC3388 addresses only one case where multiple codecs are signaled to
transport to the same IP address, port and implicitly with the same RTP
profile (as there was probably only one RTP profile at that time of its
writing). It did not describe the possible answer for the offer in 7.5.3
as such an SDP offer is not valid.

However, we are discussing a slightly different SDP offer where the two
"m=" lines differ in RTP profiles, which is clearly not in the scope if
RFC3388 as such SDP offer was probably not a possibility at the time of
its writing. RFC4585 went ahead and suggested a potential solution based
on the grouping concept presented in RFC3388.

---

From: Joerg Ott <[email-masked]>
Date: Thu, 02 Nov 2006 17:02:22 +0200

> Are we going to declare RFC4585's example normative?

No.  An example is by definition an example and this one, in
particular, has a disclaimer underneath.  We have seen with
various SIP specs that people often implement by example
rather than reading the spec.

Actually, using port equality for indicating alternatives
came originally from the O/A examples document which only
documented behavior of some existing implementations.

So, this did not grow in MMUSIC nor in AVT.

> RFC4585 aren't aware of RFC4585's permission to do this.

Well, first of all, RFC 4585 does not have normative text.
Second, nodes not aware of RFC 4585 will not understand the
AVPF line and ignore the media session altogether.

Still, we ought to have a grouping mechanism, but RFC 4585
was clearly not the place to specify this.

>>concept in RFC4585. Probably there are existing implementations which
>>already support such signaling. Any new signaling solution can only be

They have been around a couple of years ago.

> Is there consensus in MMUSIC with that position?

I do not know.  But we (as WG co-chairs) raised the grouping
discussion before and there appeared not to be so much interest.
I hope this will change now.

Joerg

---

From: Joerg Ott <[email-masked]>
Date: Sun, 05 Nov 2006 01:16:30 +0200

> they're rare.  I'd love it if I was wrong.

:-)

(acutally, I think this is the right starting point)

Well, looking at what we currently have, let me try some
constructive discussion here (yes, we have a potential issue
here in terms of inconsistency; but, hey, we have had those
before and I believe they are much more "potential" than many
others).

Here is a proposal to beat up (which I am making specifically for
the AVPF-SAVPF or AVP-SAVP cases, since this triggered the whole
discussion):

We are concerned about peers having to figure in an O/A exchange
how to agree in an ideally backward-compatible fashion on a common
mode of operation.  We have RFC 3388, RFC 4566, RFC 4585, the SAVPF
draft and some yet unspecified grouping format; let's call this
latter thing AP (= alternative proflie) just for the sake of
brevity).

We can have UAs supporting secury (UA_S) and other not doing
so (UA_P, P = plain).  We also may have future UAs that support
the "AP" grouping scheme and RFC 3388 (UA_G).  They clearly do
not exist at this point because we do not have AP define.

Let me make the assertion that we do not have currently so many
deployed UA_S.  We have also no UA_G type endpoints.

So, we have 9 permutations of who can call whom

1. Whenever a UA_P initiates a dialog, this is straightforward:
    no secure profile will show up and we are done.  This covers
    the first three cases: UA_P -> *

2. A UA_S does not know about grouping and so it will send
    either only AVP or SAVP but not both.  A receiving UA_S
    will always accept, a UA_P only accept AVP and reject
    everything else as not supported, and a UA_G will also
    accept a simple non-grouped thing.  This covers the
    next three cases: UA_S -> *

    In detail:

    UA_S -> UA_P: even if the disallowed port grouping
    was used, UA_P would not understand it and reject the
    SAVP session because it does not support security.

    UA_S -> UA_S: I tend to assert that Even if UA_S exist,
    they will not have gotten the strange idea of offering two
    media session descriptions with the same port number
    simply because this is not defined according to RFC 4566.
    If they have, they are simply non-compliant to SDP and
    we can't help them.

    UA_S -> UA_G: According to the rule "be conservative in
    what you send and liberal in what you accept" a UA_G
    would follow guidance---to be written up in the "AP"
    spec---and would thus even be able to notice the
    wrong implementation on the other side and react
    accordingly.

    Most importantly, for the latter two cases, note that
    there is a logical difference between offering to
    compatible profiles such as AVP and AVPF on a single
    port (which could be legimate as I mentioned earlier)
    and offering two incompatible profiles such as AVP
    and SAVP.

3. UA_G -> UA_P: If UA_G includes a grouped description
    UA_P will not understand it and interpret the m=
    lines independently.  This is plain RFC 3388 without
    any overloading of any sort.  Since UA_P does not
    understand the secure alternative, it will simply
    reject it.

    UA_G -> UA_G: Both will understand the "AP" grouping
    semantics and everything is fine.

    UA_G -> UA_S: In this case, UA_S may get confused
    because it receives a secure and an insecure m= description
    (not using the same port number because UA_G will be aware
    and not do this).

    If UA_S accepts both (would probably be the first IP phone
    to accept two audio streams at least I have seen), the
    UA_G would figure this out quickly because the answer
    will not contain the grouping attributes, so it can
    re-INVITE and leave just the secure session active.

    If UA_S accepts just one, this also solves the problem.
    UA_G can tell from the SDP description that the grouping
    attributes were not properly returned.

    The worst case that can happen is that UA_S choses the
    unsecure session even though it would support the secure
    variant as well.  After the initial call setup, UA_G might
    probe whether renegotiation to the secure secure is possible.

So, the only problematic cases are the ones where UA_S receive
calls from other UA_S (which want to do port-based grouping even
or from UA_G.  The latter issue exists independent of the port
grouping discussion since no endpoint is required to understand
RFC 3388.

The next step would be to write the "AP" grouping spec, suggest
that endpoints wanting to support SAVP* also support RFC 3388
and make people aware of this.  The corner cases appear to be
acceptable for an interim period and proper grouping should be
implemented in any case.

I hope I did not miss too much but I guess you will tell me :-)
It's only meant as a starting point to get some systematic
approach into the whole discussion.

Joerg

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Nov 2006 16:32:16 -0800

...
...
>    understand the secure alternative, it will simply

Agreed.

But this does require obtaining a UDP port for every RTP profile in the
offer, which adds to ICE processing and adds another NAT pinhole for every
RTP profile that is negotiated.  I don't know how grouping would work with
ICE's current architecture.

We need the ability to select RTP profiles independant of selecting
transport address.

>    to accept two audio streams at least I have seen),

The problem is more nuanced if an offerer wants best-effort SRTP.  Near as I
can tell, RFC3388 implies that the offerer's first grouped media line is the
offerer's most-preferred media line in that group (but I can't see where it
outright states this (*)).  

Let's assume that we required SAVP-capable endpoints to support RFC3388bis
(as you described later; see below).  An offerer that wants best-effort SRTP
is still in a dilemma:  should SAVP or AVP appear first in the SDP?  In
order to get SRTP with an SRTP-capable UA_G, the offerer needs to place SAVP
first; but in order to get RTP with a UA_P, the offerer will place AVP
first.

    (*) The identification-tag might be able to express this in
        RFC3388bis; in RFC3388, however, the value of the
        identification-tag appears to only provide a label.  I 
        don't find text in RFC3388 that says that a media 
        stream with "1" is more-preferred than a media stream 
        with "2".  RFC3388bis could fix this.

...
> approach into the whole discussion.

Thanks for the detailed email.  It helped me grasp the situation.

I sincerely believe we need the ability to use the same transport address
for different RTP profiles.  To do this with grouping, we would have to
revise RFC3388 to allow port overloading; let's call that RFC3388bis, whose
only change would be to eliminate RFC3388's prohibition of port overloading.
If we created RFC3388bis, we could mandate that RFC3388bis be used to
negotiate RTP profiles.  But that still won't get non-RFC3388bis-aware
endpoints to know what they're supposed to do when they see port-overloaded
media lines.  I suppose we could declare them to be broken.  But that's a
lot of endpoints.

-d

---

From: Joerg Ott <[email-masked]>
Date: Wed, 08 Nov 2006 03:32:37 +0200

> We need the ability to select RTP profiles independant of selecting

That would be desirable, indeed.

> outright states this (*)).  

Yepp.  I deliberately left the best effort part out of the
consideration since the mail already got too long.

> first; but in order to get RTP with a UA_P, the offerer will place AVP

At this point I would assume that not so many less SAVP-capable
SIP endpoints, so that putting AVP first would probably serve
interoperability.

I am afraid, we may have to made some tradeoff of this kind.
This does not go away if you offer SAVP in an attribute for
caps negotiation (see below).

We have many endpoints and some may need to be upgraded to
do secure RTP with all options as we want them to.  Given
my own experience with a small zoo of different SIP endpoints,
we should not rule out this option as this has been practice
in the past.  If we can hurt a bit more now and get something
solid finally sorted out, I would want to go for this.

>>approach into the whole discussion.

What I should have added here: while the above discussion assumed
some kind of grouping for UA_G, Flemming's capability negotiation
draft could serve as a baseline to achieve the same purpose.  It
may even not have some of the issues with plain grouping.

Yet, we have grouping and it would be nice to ultimately get
agreement on where the boundaries for the grouping framework
lie.  The earlier we define this (and what we expect to be
the future solution), the fewer issues with a huge installed
base we will have.

> media lines.  I suppose we could declare them to be broken.  But that's a

We'll have to do something here to fix this.  And I am afraid we won't
get around declaring some of them 'broken' in some respect.  But the
earlier we do this the better.  And of course, we need to pick our
mechanism of choice fairly quickly.

Joerg

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 7 Nov 2006 17:11:58 -0800

> only change would be to eliminate RFC3388's prohibition of port

I believe this is the best way to solve this problem. With the proposed
change, RFC3388bis well be well aligned with the latest SDP RFC4566. It
is also possible to state in rfc3388bis that the media sections be
listed in preferred order.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 15 Nov 2006 21:55:10 -0500

Nice break-down. The only problem I see here is that you assume that 
endpoints properly reject individual media streams in an SDP offer when 
there is more than one. There is a lot of endpoints out there that won't 
do that (especially the ones known as MGCs or CAs, that more or less 
blindly just forward the SDP to the device controlled endpoint using 
Megaco/H.248 or MGCP).

-- Flemming