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

[Paul Kyzivat <[e-mail]>]

On 5/22/13 6:55 PM, Justin Uberti wrote:
> I think we could do this using the existing syntax, e.g.
>
> an offer of a=group:BUNDLE A B C would indicate that the offerer would
> prefer A, B, and C to be muxed onto A, and
> an answer of a=group:BUNDLE C A would indicate that the answerer is
> going to mux C and A onto C, and send B unbundled.

That would work. I don't have an objection to it.
But I'm also ok with choosing based on static ordering of m-lines.

Whether to allow m-lines with zero ports in the bundle is a separate 
question. This approach could still work with that, as long as the zero 
ones aren't listed first, or the rules are adjusted to use the first in 
the answer bundle that is non-zero.

IIRC the desire to allow zero port m-lines in a bundle was so that an 
offer could indicate what it wants to bundle even though it doesn't want 
to assign ports yet. If that is still of interest then we shouldn't take 
it away.

	Thanks,
	Paul

>
> On Wed, May 22, 2013 at 7:11 AM, Kevin Dempsey <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Would it make it simpler if the offer included an attribute in
>     bundled m= lines that said where to send the media if bundle is
>     supported by the answerer; and for the answer to include an
>     attribute that said where it was going to send the media (ie. to the
>     bundled destination or the unbundled destination)
>
>
>     On 22 May 2013 14:55, Paul Kyzivat <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         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
>
>
>         _________________________________________________
>         mmusic mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/__listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>
>
>