Subject: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session

From: Jonathan Lennox <[email-masked]>
Date: Wed, 1 Aug 2012 14:56:33 -0400

As I mentioned at the mic, BUNDLE currently generates an implicit combined description of the bundled RTP session, and a lot of the problems and standardization issues we're having relate to the fact that the bundled session's media description is implicit.  Therefore, you need a lot of language specifying when parts of bundled m=lines must be the same, when they must be different, and when they may be independent.  Such specifications would need to be defined for every existing SDP attribute used in offer-answer, and every new SDP attribute going forward.

The alternative to having an implicit description, I think, would be to have an explicit description.  The basic idea is to have a new m-line representing the bundled session explicitly, defined in a way that a non-bundle-aware endpoint should see it as an unknown type of m-line and reject it.  The BUNDLE grouping semantic then says that you either use all the traditional m-lines, rejecting the bundled one, or you use the one bundled m-line, rejecting all the others.

As a straw man example, a variant of bundle-negotiation-00's example offer with ICE:

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar baz
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
       m=video 10002 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10002 typ host
       m=bundle 10000 RTP/AVP 0 8 97 31 32
       a=mid:baz
       b=AS:1200
       a=full-rtpmap:0 audio/PCMU/8000
       a=full-rtpmap:8 audio/PCMA/8000
       a=full-rtpmap:97 audio/iLBC/8000
       a=full-rtpmap:31 video/H261/90000
       a=full-rtpmap:32 video/MPV/90000
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host

Points to note:

* Outside the m=bundle line and its attributes, this is entirely current-standard SDP.

* The m=bundle is a complete description of an entirely separate m-line; if it's used, the other m-lines in the group are rejected and the information they carry is ignored.

* We'll need to make sure that we have a syntax for this new m-line (what I've called m=bundle) that existing implementations will reject (with port 0), rather than interpreting as an SDP syntax error.  We'll need input from interop people to know what's safe to do here.

* The ports and ICE candidates specified in the m=bundle line are entirely up to the whim of the offerer; they may overlap with one of the other m-lines, but don't have to.

* Because the media type of the payload types isn't given by the m-line, we need new syntax to specify the top-level media type.  I've called this "full-rtpmap", but this is just a strawman.

* Because there's one list of payload types, the RFC 3264 payload preference order needs a bit of finessing. I'd suggest saying that the preference order should be interpreted independently per media type.

* There's obviously no way to do a=sendonly/recvonly independently for audio and video; you'd need to do it on the source level, with (if you're doing it in SDP) something like my source-selection draft.

* There's an obvious syntax to send an offer that means "support BUNDLE, or fail" -- just send the m=bundle line, without the grouped independent lines.  Whether we'd want to allow such an offer is a separate question.

--
Jonathan Lennox
[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Aug 2012 23:33:04 -0700

Jonathan,

This proposal is interesting.

IIUC, if answerer supports and accepts the bundle, then everything from 
the other bundled m-lines is ignored. Right?

If so, then *everything* that would have been specified in each of those 
media sections is ignored, and must be restated after the bundle m-line. 
But isn't one of the points of this allow separate settings for things 
per-m-line? The directionality is one of those things that you mention, 
but there are lots of others. I think we decided there were at least 
three categories:
- those that are independent for each bundled media sections
- those that are summed across all the bundled media sections
- those that are the max across each of the bundled media sections
- (are there other possibilities?)

Clearly your proposal can handle those that are summed, and those where 
the max is used. But not those that are independent. (The directionality 
attributes are an example that you mentioned.)

A potential alternative would be for the answer to reject the bundled 
m-lines other than m=bundle, but then both sides would still honor the 
attributes and other things from the rejected bundled m-lines. But this 
might not be feasible, since I think there is a normative requirement in 
O/A to ignore all the stuff from rejected m-lines.

Another possibility: your proposal is starting to smell a bit like 
cap-neg. Maybe we could make cap-neg serve for this.

	Thanks,
	Paul

On 8/1/12 11:56 AM, Jonathan Lennox wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Aug 2012 20:54:52 +0200

Hi,

> O/A to ignore all the stuff from rejected m-lines.

I am not sure whether there is such requirement, but I guess it depends on how one reads the spec and how you define "ignore" :)

But, it IS an issue that we need to think about, whether we "duplicate" information into the m=bundle line, or whether we
can "reference" information in the other m= lines (even if their ports are set to zero).

In any case I do think that we will need SOME information in the m=bundle line, e.g. information that intermedairies need (bandwidth etc

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 Aug 2012 11:11:32 +0200

> The alternative to having an implicit description, I think, would be to have an explicit description.  The basic idea is to have a new m-line representing the bundled session explicitly, defined in…
Deja vu! I think we discussed this option (really fixing the rtpmap 
syntax) a year ago, and dropped it because it was too big a change....

It's cleaner, MUCH cleaner. The biggest disadvantage I see at the moment 
(not knowing anything about how the interop would work out) is that it's 
another reset.

>         a=group:BUNDLE foo bar baz
Nit: I think the bundled a=mid should be first.... we might want to call 
the grouping something other than BUNDLE, since that name is already 
showing up in implementations, assuming the current syntax...
> * We'll need to make sure that we have a syntax for this new m-line (what I've called m=bundle) that existing implementations will reject (with port 0), rather than interpreting as an SDP syntax er…
Interop's what's currently giving us trouble with the current 
description proposal, so I agree that's critical.
> * Because the media type of the payload types isn't given by the m-line, we need new syntax to specify the top-level media type.  I've called this "full-rtpmap", but this is just a strawman.
I'd like to call it "mime-rtp-map", but that's my personal bias showing 
:-) (the bad thing about current rtpmap is that it maps only part of the 
mime type).
> * There's an obvious syntax to send an offer that means "support BUNDLE, or fail" -- just send the m=bundle line, without the grouped independent lines.  Whether we'd want to allow such an offer is…
I don't see a reason to forbid it :-) - once all the equipment that 
doesn't do BUNDLE is decommissioned, we can get rid of the m=<type> 
syntax altogether and just regard "m=bundle" as a token that we keep 
around for historical reasons.

Ever the optimist!

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Aug 2012 05:06:49 -0700

> Deja vu! I think we discussed this option (really fixing the rtpmap syntax) a year ago, and dropped it because it was too big a change.

> It's cleaner, MUCH cleaner. The biggest disadvantage I see at the moment (not knowing anything about how the interop would work out) is that it's another reset.

[BA] There are other issues as well. How do you express the desire to multiplex a layered codec which is itself a grouping in Jonathan's proposal?

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 Aug 2012 14:17:14 +0200

> [BA] There are other issues as well. How do you express the desire to multiplex a layered codec which is itself a grouping in Jonathan's proposal?
Bernard, since I'm so easily confused by how people transmit layers of 
layered codecs, can you illustrate the particular scheme you want to 
use, and can't think of how to represent in Jonathan's scheme?

("same SSRC in multiple RTP sessions" is quite hard to multiplex; 
"different SSRCs in one RTP session" doesn't seem to affect this 
proposal at all)

                        Harald

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 9 Aug 2012 09:57:19 -0700

> use, and can't think of how to represent in Jonathan's scheme?

[BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency in SDP". An
example of how this would be used with H.264/SVC is included in RFC 6190, Section 7.3.4:

      a=group:DDP L1 L2
      m=video 20000 RTP/AVP 96
      a=rtpmap:96 H264/90000
      a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
      a=mid:L1
      m=video 20002 RTP/AVP 97
      a=rtpmap:97 H264-SVC/90000
      a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
       mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
      3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
      a=mid:L2
      a=depend:97 lay L1:96
Here the a=depend line is expressing the decoding dependency (layered in this case). 

Let us assume that there is also audio, as in Jonathan's example:

       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
Does the entire SDP offer with BUNDLE and dependency grouping  look like this (ignoring RTP/RTCP mux for the moment)? 

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE foo L1 L2 baz
       a=group:DDP L1 L2
       m=audio 10000 RTP/AVP 0 8 98
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:98 iLBC/8000
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
       m=video 20000 RTP/AVP 96
       a=rtpmap:96 H264/90000
       a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
       a=mid:L1
       m=video 20002 RTP/AVP 97
       a=rtpmap:97 H264-SVC/90000
       a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
       mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
      3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
       a=mid:L2
       a=depend:97 lay L1:96
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host
       m=bundle 10000 RTP/AVP 0 8 96 97 98
       a=mid:baz
       b=AS:1200
       a=full-rtpmap:0 audio/PCMU/8000
       a=full-rtpmap:8 audio/PCMA/8000
       a=full-rtpmap:98 audio/iLBC/8000
       a=full-rtpmap:96 H264/90000
       a=full-rtpmap:97 H264-SVC/90000
       a=depend:97 lay L1:96
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Aug 2012 01:35:36 +0200

Hi,

One question: within the m=bundle description, does the "a=depend:97 lay L1:96" attribute provide all information needed for the decoding dependency, or does the receiver also need to look for the "a=group:DDP L1 L2" attribute?

(This is related to a more general question we need to answer: do we explicitly add all information to the m=bundle description, or can we "reference" information from the m=audio/video/etc descriptions?)

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Bernard Aboba [[email-masked]]
Sent: Thursday, August 09, 2012 7:57 PM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session

      a=group:DDP L1 L2
      m=video 20000 RTP/AVP 96
      a=rtpmap:96 H264/90000

       v=0

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 10 Aug 2012 07:45:31 +0200

> Here the a=depend line is expressing the decoding dependency (layered 

Interesting..... I do not see a way in that syntax to express a 
relationship between multiple video tracks in the same session. Is this 
expected to be done by matching SSRC across the sessions?

> Does the entire SDP offer with BUNDLE and dependency grouping look 
> like this (ignoring RTP/RTCP mux for the moment)?
>
>         v=0
I think you can't BUNDLE L1 and L2 together, since the whole point of 
having L1 and L2 is transport separation, and if SSRC matching is used 
to figure out which video stream in L2 is an enhancement layer for which 
video stream in L1, mapping them into the same RTP stream would be 
physically impossible.

So if one BUNDLEs audio and L1 video, the SDP should look like this:
>         a=group:BUNDLE foo L1 baz
>         a=group:DDP L1 L2

That is - "you can't get there from here, so you shouldn't try".

(I think there's a possibility of carrying all these in a single session 
using MSID to represent the relationships, but that's not something I 
want to chew on for the moment.)

             Harald

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 25 Aug 2012 13:41:11 +0000

On Aug 9, 2012, at 9:57 , Bernard Aboba wrote:

>        c=IN IP4 
> host.atlanta.com
>        a=candidate:1 1 UDP 1694498815 
> host.atlanta.com
>  10000 typ host
>        m=video 20000 RTP/AVP 96
>        a=rtpmap:96 H264/90000
>        a=candidate:1 1 UDP 1694498815 
> host.atlanta.com
>  20002 typ host
>        a=candidate:1 1 UDP 1694498815 
> host.atlanta.com
>  10000 typ host
> 
> 
>  

I think it will work better if it just looked like 

       v=0

       t=0 0

       a=group:DDP L1 L2

that seems to have all the same information as the version with m=bundle thing and AFAIC some firewalls are going to remove all the stuff under the m=bundle line as it is not a recognized media type.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 25 Aug 2012 16:27:58 +0200

> that seems to have all the same information as the version with m=bundle thing and AFAIC some firewalls are going to remove all the stuff under the m=bundle line as it is not a recognized media typ…
Not taking a position, but having firewalls remove all the m=bundle 
stuff (and presumably also the a=group:BUNDLE line) is, in my view, 
actually an advantage of this approach. (If the firewall removes the 
m=bundle and not the a=group:BUNDLE, we're left with a somewhat strange 
SDP.)

Cullen, I note you're using different port numbers on the m= sections. 
Are you assuming the semantics from a=group:TOGETHER - that one picks 
the first one?

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 25 Aug 2012 10:01:31 -0700

The different port number issue arises in multiple contexts here.  Firstly, it arises within the dependency grouping.  RFC 6190 allows layers to use different ports as well as allowing multiple layers to be sent to the same port. While the SDP example in RFC 6190 (which I copied) shows different ports being offered, in practice, I believe that H.264/SVC implementations typically prefer using the same port.  However, using the same port in an SDP offer can cause answerers to reject the SDP as invalid, which is presumably why that approach was chosen for the RFC 6190 example. So the potential solution is to offer different ports, and have the answer respond with the same port.  Secondly, the issue arises with the bundle grouping. 

Cullen -- did you mean to include "baz" on the 
a=group:BUNDLE foo L1 L2 baz

line, since the a=mid:baz line is now gone? 

On Aug 25, 2012, at 7:28, "Harald Alvestrand" <[email-masked]> wrote:

> Not taking a position, but having firewalls remove all the m=bundle stuff (and presumably also the a=group:BUNDLE line) is, in my view, actually an advantage of this approach. (If the firewall removes the m=bundle and not the a=group:BUNDLE, we're left with a somewhat strange SDP.)
> 
> Cullen, I note you're using different port numbers on the m= sections. Are you assuming the semantics from a=group:TOGETHER - that one picks the first one?
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 25 Aug 2012 20:35:55 +0200

Hi,

> The different port number issue arises in multiple contexts here.  Firstly, it arises within the dependency grouping.  RFC 6190 allows 
> layers to use different ports as well as allowing multiple layers to be sent to the same port. While the SDP example in RFC 6190 
> (which I copied) shows different ports being offered, in practice, I believe that H.264/SVC implementations typically prefer using the 
> same port.  However, using the same port in an SDP offer can cause answerers to reject the SDP as invalid, which is presumably why 
> that approach was chosen for the RFC 6190 example. So the potential solution is to offer different ports, and have the answer respond with the same port. 

That is what Harald's original TOGETHER proposal was all about, and where I had issues (related to intermediares who assume that the offered ports are used, and if the offer wants to set the multiplex port to zero).

So, IF people think that offering the same port will cause problem, and IF people think that an m=bundle m- line would be removed, maybe the only option is to have 2 offer/answers: the first is a "normal" offer, with different ports, and if the answerer indicates that it supports bundle then the second offer will be sent with the same port.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 27 Aug 2012 10:03:02 +0200

> So, IF people think that offering the same port will cause problem, and IF people think that an m=bundle m- line would be removed, maybe the only option is to have 2 offer/answers: the first is a "…
If "m=bundle m-line is removed" means "we'll negotiate the old style 
session with old equipment", then that's a success, not a failure.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Aug 2012 10:39:47 +0200

Hi,

>>> The different port number issue arises in multiple contexts here.  
>>> Firstly, it arises within the dependency grouping.  RFC 6190 allows 
>>> layers to use different ports as well as allowing multiple layers to 
>>> be sent to the same port. While the SDP example in RFC 6190 (which I 
>>> copied) shows different ports being offered, in practice, I believe that H.264/SVC implementations typically prefer using the same port.  However, using the same port in an SDP offer can cause answerers to reject the SDP as invalid, which is >>>presumably why that approach was chosen for the RFC 6190 example. So the potential solution is to offer different ports, and have the answer respond with the same port.
>> So, IF people think that offering the same port will cause problem, and IF people think that an m=bundle m- line would be removed, maybe the only option is to have 2 offer/answers: the first is a "normal" offer, with different ports, and if the answerer >>indicates that it supports bundle then the second offer will be sent with the same port.
>If "m=bundle m-line is removed" means "we'll negotiate the old style session with old equipment", then that's a success, not a failure.

Agree. There would be no multiplexing, but the session establishment would still succeed.

Regards,

Christer

>>>>> Bernard, since I'm so easily confused by how people transmit 
>>>>> layers of layered codecs, can you illustrate the particular scheme 
>>>>> you want to use, and can't think of how to represent in Jonathan's scheme?
>>>> [BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency 
>>>> in SDP". An example of how this would be used with H.264/SVC is included in RFC 6190, Section 7.3.4:
>>>>
>>>>        a=group:DDP L1 L2
>>>>        m=video 20000 RTP/AVP 96
>>>>        a=rtpmap:96 H264/90000
>> m=bundle and not the a=group:BUNDLE, we're left with a somewhat 
>> strange SDP.)
>>