Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

[Christer Holmberg <[e-mail]>]

Hi Hadriel,

My opinion is also that intermediaries will handle offers with the same port value. But, there were other opinions, so we agreed on the two-O/A mechanism.

Regarding the modified semantics of port zero in bundle-only m- lines, if we want to change the semantics only for WebRTC, it means we can only allow bundle-only for WebRTC. Because, I don't think we want to have different semantics for port zero bundle-only m- lines depending on whether they are used in WebRTC or not...

Regards,

Christer



Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Hadriel Kaplan [[e-mail]]
To: Christer Holmberg [[e-mail]]
CC: mmusic [[e-mail]]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

On Aug 8, 2013, at 9:04 AM, Christer Holmberg <[e-mail]> wrote:

> Another advantage of using different port numbers is that it provides a fallback in case the remote endpoint does not support, or does not want to use BUNDLE.

Yes, except as far as I can tell all devices (and even intermediaries) handle an offer with the same port number just fine.  But that's just a personal observation, and dangerous to assume ALL of them handle it fine; that's why I didn't argue for long that we should use the same port number in the offer - because it concerned me that someone knew of at least one implementation that didn't handle it well. (not that we can truly accommodate ALL implementations anyway, but it's got to be a heck of a lot higher than simple majority, and as close to 100% as we can get)


> However, for bundle-only m- lines such fallback is not needed - they are ONLY going to be used IF the remote endpoint chooses to use BUNDLE.
> ...and, based on the agreed scope, the Offerer KNOWS that the remote endpoint supports BUNDLE, so the "one implementation that doesn't handle it" will not be there :)

For WebRTC sure - but we were talking about using BUNDLE generically.  Or at least that's what I thought you were asking about.  If we're only talking about using BUNDLE for WebRTC, then not only do you not need to use a port=0, but you also don't need a second offer/answer, etc.


>> Also, from a purely protocol perspective, it seems quite logical to me to use a port number of 0 for an m-line you literally don't want to use if the far-end doesn't support
>> BUNDLE - a port number of 0 effectively means "disabled" today, and that's basically what you want.
>
> Well, one could also say that it means "Here are some m- lines  I want to bundle, with this port, but only if you (the remote endpoint) wants to use bundle." :)

We can certainly change the semantics of SDP offers with port=0 for WebRTC, but I think it would be really dangerous to change its semantics for general use.


>> What I think should happen is the UAS should send an SDP answer using port=0 for those same m-lines, and the UAC should then send a new offer with those m-lines having the real port number of the bundle transport, and the far-end should answer that in the same fashion.
>
> The problem is that the grouping framework does not allow, in SDP Answers, usage of port=0 in grouped m- lines. It would require an update of the RFC, and I think we want to avoid that.

Considering the number of docs the Unified-Plan proposes to either create, change, update or whatever... methinks having BUNDLE update the grouping framework RFC is rather a minor nit. :)

-hadriel