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

[Christer Holmberg <[e-mail]>]

Hi,

> If I understand your question, you're asking why bundle-only m-lines would use a port number of 0 in the offer, instead of using the same port number as the regular bundle m-line they're going to transport-bundle with?

Yes.

> I believe the rationale was basically argued about before, either in IETF 86 Orlando or IETF 85 Atlanta.  It gets back to the original debate about whether a BUNDLE offer should 
> use the same port numbers or different ones, for bundle m-lines (what was called "BUNDLE vs. CRUNDLE" if I recall correctly).
>
> One WG participant argued against using the same port numbers for bundle lines.  His argument was that since it was never described in an RFC, and he knew of one implementation 
> that didn't handle it well, that therefore we couldn't send an offer using the same port numbers until we found out if the far-end supported BUNDLE or not.
>
> That's what drove the decision to use different port numbers even in regular bundle cases, afaik.

Correct. 

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.

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 :) 

> Therefore, even for bundle-only lines, we can't use the same non-0 port number for them, because the same theoretical issue will exist.

Well, I think there will be some cases where we will have to allow the same port number. Bundle-only is one case, trickle ICE another (where one can assign port 9 for multiple m- lines).

> 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." :)

> What I don't think is right, is (1) having the far-end send an SDP answer back that sets a real port number for those same "disabled" m-lines, and (2) not requiring 
> another offer/answer exchange that then uses the correct (same) port numbers for the previously-disabled m-lines.

So far I agree with you on this one :)

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

Also, if the Answerer chooses to use BUNDLE, as it DOES include its bundle port for all other m- lines, I think it should also do it for the bundle-only m- lines.

Regards,

Christer



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

> Hi,
>  
> As has been indicated, bundle-only can only be used when one knows that the receiver, and possible intermediaries etc, support it.
>  
> So, based on that assumption, my question is: why do we need port 0? Why not assign the suggested bundle port to the bundle-only m- lines from the beginning? As the bundle port is anyway going to be used (even if the receiver does not want to use bundle), there is no need to reserve additional ports for bundle-only m- lines.
>  
> Regards,
>  
> Christer
>  
> 
> 
> Sent from Windows using TouchDown (www.nitrodesk.com) 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic