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

[Suhas Nandakumar <[e-mail]>]

On Wed, May 22, 2013 at 3:55 PM, Justin Uberti <[e-mail]> 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.
>
>
> Agree with this. This also fits with the way to categorization for Attr
Muxing as TRANSPORT.

>
> On Wed, May 22, 2013 at 7:11 AM, Kevin Dempsey <[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]> 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]
>>> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>>>
>>
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>