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

[Emil Ivov <[e-mail]>]

On 20.05.13, 16:14, Hutton, Andrew wrote:
> 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

> We could say that any port in the bundle could be used but I don't
> see this gains us anything.

Agreed.

Emil
> 
> Andy
> 
> 
> 
> 
>> -----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