Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 (Part I)

[Eric Rescorla <[e-mail]>]

On Mon, Oct 3, 2016 at 1:07 PM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
>
> OVERALL
>
>
>
> >The overall framing of this document as being about attaching multiple
>
> >m= sections to a single "shared address" is extremely problematic,
>
> >for two reasons:
>
> >
>
> >- With ICE there isn't actually any notion of a shared address except
>
> >  in some vague sense. I suppose you could argue that because with
>
> >  ICE you are required to specify a port on the m= line then you
>
> >  still have a concept of an address, but that's not true in
>
> >  trickle ICE, where the port is 9, so all m= lines share the same
>
> >  address/port. So, actually when you use trickle a whole bunch of
>
> >  the statements in this document are wrong.
>
> >
>
> >- A lot more is being overloaded here than addresses. In fact, a whole
>
> >  pile of semantics are being overloaded, so the way to think about
>
> >  this is actually as gluing a whole bunch of m= lines together at
>
> >  the transport level.
>
> >
>
> > I think the right concept here is not "shared address" but "bundle group"
>
> > and the document should be written in that way, namely that there are
>
> > a  bunch of m= lines in a bundle group and the one with the bundle tag
>
> > is the one that sets all the shared parameters.
>
>
>
> It is true that the actual port value in the m- line, and the IP address
> in the c- line address, represent the address that is actually being used.
>
>
>
> But, even with ICE there is a shared address, isn’t there? Yes, that
> shared address may change, but at any given time there will be one address
> that is shared among the media streams within the BUNDLE group. Or?
>
>
>
> Not if you trickle, no. Then all the m= lines have the same address
> whether they are bundled or not.
>
>
>
>
>
> Ok, I hear you. You are basically saying that it doesn’t matter whether
> bundled m- lines share addresses or not – the ONLY thing that matters is
> that the m- line associated with the bundle tag contains the address to be
> used.
>
>
>
> The reason we mandated shared addresses, once the usage of BUNDLE had been
> negotiated, was because of intermediaries that don’t support BUNDLE (to
> make sure they send media towards the correct address). But, maybe we don’t
> need to worry about anymore – BUNDLE probably won’t work reliably with
> such intermediaries anyway…
>
>
>
> Also, there is at least once case where the address matters: when you add
> a new m- line to a bundle group. If you use a unique address, and the
> answerer does not accept the m- line in the BUNDLE group, it can be used
> un-bundled. If you use a shared address, the answerer will have to reject
> the m- line.
>
>
>
> I think this is all true, but what I am trying to say here is, I think,
> conceptually different:
>
>
>
> BUNDLED m= lines are grouped together and share a bunch of properties.
> Amongst those properties is that they share IP addresses, but it's not the
> only thing they share, nor is it it the indicator that they are shared
> (that's the a=group:BUNDLE list). So the top-line category isn't shared
> vs/unique IP address but rather bundled vs. unbundled.
>
>
>
> Correct.
>
>
>
> The best thing, as far as the address in the m- line is concerned, would
> be to simply use normal SDP procedures (read: unique addresses) also for
> bundled m- lines. And, if the offerer wants to make sure a mid-session
> added m- line gets accepted in the bundle group (or otherwise is rejected)
> he would use bundle-only – in the same way it’s used in the initial offer.
>
>
>
> Then a “shared address” would only be a property of the BUNDLE group – not
> related to the address put in the m- line.
>

I worry that we're not communicating. I would have this document never
refer to "shared" or "unique" addresses and instead refer to bundled or
unbundled m= lines.

-Ekr



> Regards,
>
>
>
> Christer
>