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

[Christer Holmberg <[e-mail]>]

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
> 

-- 
https://jitsi.org