Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

["Parthasarathi R" <[e-mail]>]

Eric,

 

<snip>

Again, you need to distinguish between *endpoints* and filtering
middleboxes.

</snip>

 

IMO, it is not possible to identify "endpoint" and "filtering middleboxes"
based on the protocol exchanges. Both webrtc browser and webrtc gateway
handles ICE, SRTP-DTLS, same codecs, SDP in the same way. There is no way to
identify WebRTC browser to distinguish whether the remote side is a browser
or media gateway during WebRTC session. Please explain in case it is
possible to distinguish the remote side is WebRTC browser or WebRTC GW from
the originating browser.

 

Thanks

Partha

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Eric Rescorla
Sent: Sunday, August 11, 2013 8:21 PM
To: Christer Holmberg
Cc: mmusic_ietf.org; Paul Kyzivat
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only
m- lines?

 

 

 

On Sun, Aug 11, 2013 at 6:11 AM, Christer Holmberg
<[e-mail]> wrote:

Hi,

>> I think making sure all entities have the correct port numbers is
critical in making sure the media will flow.
>
> There is a difference between "making sure the media will flow" and
"before media can
> flow at all".
> For instance, Neither Firefox nor Chrome current does a second O/A
> transaction and yet media flows just fine in most cases, since they are
operating
> in an unmediated environment. Obviously, this is a best-case scenario, but
similarly
> there are going to be mediated environments which are perfectly happy with
a second
> O/A exchange with non-zero ports.

There are also environements where a single offer, with identical port
numbers, work just fine, because the receiver will be able to handle it even
if it doesn't support BUNDLE.

However, we are defining a generic mechanism, supposed to work in different
environments.

 

"different environments" != "arbitrary lossage by any middlebox in the
universe"

 

Again, you need to distinguish between *endpoints* and filtering
middleboxes.

 

 

But, sure, if the community thinks that we shall define different options,
depending on environments etc, we can do that...

 

Which is not what I said.

 

-Ekr

 

Regards,

Christer





-----Original Message-----
From: Eric Rescorla [[e-mail]]
To: Christer Holmberg [[e-mail]]

CC: Justin Uberti [[e-mail]]; [e-mail] [[e-mail]];
Paul Kyzivat [[e-mail]]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only
m- lines?





On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg
<[e-mail]> wrote:

Hi,


>>> Requiring a second offer to add the bundle-only m-lines defeats the
purpose of bundle-only.
>> We already require a second offer. I know that some people, including
yourself, want to change that, but that is nothing we have agreed on.
>>
>>> a) The delay to do an O/A will often exceed the time to allocate
candidates, for small numbers of streams; bundle-only was meant to avoid
this candidate latency.
>> You do not have to allocate ports for the bundle-only m- lines.
>>
>>> b) Once you have the initial answer, you know whether the other side
supports BUNDLE, so you can take the appropriate action (and so there is no
need for bundle-only).
>>>
>>> If SIP can't deal with the bundle-only concept, then WebRTC apps that
care about latency will have to decide whether they are running in
WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will be
bundled in the initial offer; in compatibility mode, 2 offer-answers will be
needed.
>> There are no "modes" in BUNDLE today :)
>>
> Of course there are. The handling in a reinvite case is distinct from the
initial offer, so that is modal behavior.


Sure, but you were talking about "WebRTC-only mode" and "compatibility
mode", and my point is that currently the procedures for initial offers,
subsequent offers etc are the same.


>>> This would be a somewhat unfortunate outcome, so I'd like to see
bundle-only (or something like it) work.
>> I don't think the second offer is going to cause any latency. Also, keep
in mind that you only need the 2nd Offer/Answer during the session
establishment. As agreed in Berlin, in mid-session changes you do NOT need 2
offer/answers.
>
> Please provide support for this statement. It seems clear that a 2nd offer
adds _at least_ 1 RTT latency.


Sure, but I don't think that is going to be a practical problem.



Well, I'd like to see a more convincing argument than "some middleboxes are
sad" when you
do that.




First, there are deployed legacy SIP systems that use even more O/A
transactions during session establishment. And, in your case I assume you
are even going to use something more "lightweight" than SIP to carry your
Offer/Answers.

Second, as WebRTC mandates usage of ICE, you are often going to need a
subsequent O/A anyway.



It's important to distinguish between round-trips that are in the critical
path for media
flowing and those which are not.


-Ekr