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

[Emil Ivov <[e-mail]>]

What happens when the offerer knows the answerer has bundle support, sends
all m-lines with the same port, then the answerer splits the first line
away from the bundle? Would the answerer still send everything to the same
port?

If so, I don't see why it should be different in the case where the offerer
could not make the assumption about the bundle support.

--sent from my mobile
On May 20, 2013 4:39 PM, "Paul Kyzivat" <[e-mail]> wrote:

> 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:mmusic-bounces@ietf.**org <[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://www.ietf.org/mailman/listinfo/mmusic>
>>>>>
>>>>>
>>>> -- https://jitsi.org
>>>> ______________________________**_________________ 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<https://www.ietf.org/mailman/listinfo/mmusic>
>