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

[Christer Holmberg <[e-mail]>]

Hi,

>>> 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.
>
> There are different ways an offerer can tell the remote bundle endpoint on which port it prefers to receive media.
>
> But, again, if there is an intermediary that doesn't understand bundle, it will send according to the ports indicated in the m= lines.
>
> The way we solve that is by sending the second offer, with identical port numbers. So, the sooner we send that second offer, the sooner we get rid of the problem about where to send the media :)

Actually, correcting myself.

The intermediary will of course forward media only towards the bundle port (however it is indicated), as the answerer is only sending towards that port.

The problem is that the intermediary may trigger error events when it detects media types etc not negotiated for that port. So, for THAT reason the second offer needs to be sent asap :)

Regards,

Christer






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

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic