Re: [MMUSIC] Bundle offer with different ports - where to expect media?

[Paul Kyzivat <[e-mail]>]

On 5/22/13 1:00 AM, Justin Uberti wrote:

> Taking into account Emil's suggestion as well, this leads to this
> restatement of the rules:
>
> 1.1) An offerer must be prepared to receive unbundled traffic on the
> offered ports, as if talking to a legacy endpoint.
> 1.2) An offerer must be prepared to receive bundled traffic on any port,
> except the port associated with the last m= line.
> 2) Once the answer is received, the decision on bundled/unbundled and
> which ports to use is finalized.
> 2.1) BUNDLEd m= lines use the port of the m= line that appears first in
> the bundle.
> 2.2) Unused ports can be discarded at this point.
> 3.1) m= lines offered with distinct ports may be omitted from the bundle
> answer, in line with RFC 5888.
> 3.2) m= lines offered with the same port may not be omitted from the
> bundle answer, since there is no unbundled port from them to fall back to.
> 3.3) m= lines that are rejected are omitted from the bundle answer, per
> RFC 5888.
>
> Quick check on 2.1: are we using the m= line that appears first in the
> SDP, or the m= line that appears first in the a=group:BUNDLE?

IMO it would be best to use the lexically first m-line that has a 
non-zero port and that appears in the bundle group of the answer.

Alternately, it *could* be the m-line with non-zero port that appears 
first in the bundle group of the answer. But if so, the exception in 1.2 
would also need to be correspondingly adjusted.

AFAICT the only reason to mention that exception in 1.2 is that might 
provide an opportunity for optimization, by setting up the port with 
simpler code that doesn't support bundling. I don't see a requirement in 
5888 that the bundle group in the answer be ordered the same way as in 
the offer. So the one m-line guaranteed not to receive bundled traffic 
would then not be predictable at the time of the offer, so could not be 
exploited. This problem doesn't exist if the lexical ordering of m-lines 
is used.

	Thanks,
	Paul