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

[Paul Kyzivat <[e-mail]>]

I agree with Christer's analysis here. The bundle port must be one 
associated with an m-line that is accepted, and included in the bundle, 
in the answer. That means the bundle port may not be the one from the 
first bundled m-line in the offer.

A corollary of that is that the offerer needs to be prepared to receive 
bundled media on any of the ports listed in the offer.

	Thanks,
	Paul

On 5/20/13 9:27 AM, Christer Holmberg wrote:
> Hi,
>
>>> Agree with Emil but think maybe the question was meant to be on which
>>> port(s) it needs to be able to receive bundled media.
>>>
>>> This is covered by the last para in section 6.3 which states that the
>>> answerer MUST use the port and everything else relating to the 1st m=
>>> line. So far I thought this to be reasonable and even if the 1st m=
>>> line is rejected this can still be the bundle port.
>>
>> +1
>
> I agree that is what the spec currently says.
>
> But, again, the following can happen:
>
> 1) The answerer rejects the 1st m- line; or
>
> 2) The answerer accepts the 1st m- line, but removes it from the bundle group. Yes, in this case the answerer WILL send media on that port, but ONLY media associated with that m- line (as it is no long part of the bundle group). The media associated with the remaining m- lines in the bundle group has to be sent somewhere else.
>
> Again, once the second offer has been sent, the "bundle port" is explicitly signaled (as each m- line in the bundle group uses the same port number).
>
> Regards,
>
> Christer
>
>
>
>>> -----Original Message----- From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Emil Ivov Sent: 20 May
>>> 2013 13:13 To: Christer Holmberg Cc: [e-mail] Subject:
>>> Re: [MMUSIC] Bundle offer with different ports - where to expect
>>> media?
>>>
>>> Hey Christer,
>>>
>>> On 20.05.13, 14:43, Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>> Currently BUNDLE defines that the first offer is sent with separate
>>> port
>>>> numbers (later, if the answerer has indicated support of BUNDLE, the
>>>> offerer will send a second offer, with identical port numbers).
>>>>
>>>> Some people have indicated that the offerer shall be able to receive
>>>> data already when the first offer has been sent. The question is on
>>>> which port(s) it needs to be able to receive media.
>>>
>>> Do we really have a choice here? We send the offer with different
>>> port numbers so that it would work with endpoints that have no
>>> knowledge of bundle. Such endpoints can start streaming media to any
>>> port. Bundled devices can, on the other hand, start streaming media
>>> on the bundle port.
>>>
>>> So in other words, the offerer need to expect media arriving on any
>>> port just as it needs to expect any stream arriving on the bundle
>>> port.
>>>
>>> This would be consistent with what we do for rtcp-mux.
>>>
>>> Emil
>>>
>>>
>>>>
>>>>
>>>>
>>>> -          Some have suggested the port of the first non-zero m-
>>>> line within the offered bundle group.
>>>>
>>>> -          Some have suggested ANY port
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The issue with assuming the first non-zero m- line is that the
>>> answerer
>>>> in the answer may reject it (put the port to zero), or remove it
>>>> from the bundle group (which people seem to want to allow). In both
>>>> cases
>>> it
>>>> would be strange to assume the first m- line.
>>>>
>>>>
>>>>
>>>> Now, in case e.g. ICE is used, the offerer will be able to send the
>>>> second offer before any media is received to begin with. But, the
>>>> offerer could still receive STUN connectivity checks on any of the
>>>> ports, until the second offer has been sent.
>>>>
>>>>
>>>>
>>>> We need text in BUNDLE about this, so comments/inputs are welcome
>>>> :)
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________ mmusic mailing list
>>>> [e-mail] https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>> -- https://jitsi.org
>>> _______________________________________________ mmusic mailing
>>> list [e-mail] https://www.ietf.org/mailman/listinfo/mmusic
>>
>