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

[Harald Alvestrand <[e-mail]>]

On 08/01/2012 08:56 PM, Jonathan Lennox wrote:
> 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.
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.

>
> 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
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...
>         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.
Interop's what's currently giving us trouble with the current 
description proposal, so I agree that's critical.
>
> * 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.
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).
>
> * 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.
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!