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

[Christer Holmberg <[e-mail]>]

Hi,

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

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




On 8/1/12 11:56 AM, 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.
>
> 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
> [e-mail]
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic