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

[Christer Holmberg <[e-mail]>]

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.

Earlier you said that “shared address” is one of the PROPERTIES of a bundled m- line, and that is what I was referring to. Other than that, we would not have to talk about “shared” or “unique” addresses, as you suggest.

“BUNDLED m= lines are grouped together and share a bunch of properties. Amongst those properties is that they share IP addresses,”

Regards,

Christer