W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2013

Re: Transport related API need

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 22 Aug 2013 12:44:53 +0000
To: Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3804EF@ESESSMB209.ericsson.se>
On 2013-08-22 07:31, Harald Alvestrand wrote:
> On 08/20/2013 06:46 PM, Hutton, Andrew wrote:
>> It should I know be possible for the receiver of the offer to
>> ignore the bundle option and everything to work but I believe there
>> should be a clean API that can be used to tell the browser not to
>> even attempt bundling without relying on the application to modify
>> SDP.
> I'm not convinced that the case exists in the real world where
> offering bundling is harmful.

To me the obvious use case would be for a browser to browser session 
where the app knows that separate transports would be beneficial 
(perhaps the access network can apply different treatment based on 5-tuple).

In this case both end-points support Bundle, and it would be used unless 
the app can ask for it not to be used.

However, I guess you can get the same result by sending the different 
tracks over different PeerConnections (given that they would use the 
same CNAME so they can be synchronized at playout).

> If we need it, I agree that it should be possible to just twist an
> API knob. I'm just not finding the need compelling.

To it seems that the knob (if we conclude there should be such a knob) 
should be placed on the PeerConnection constructor - when creating a PC 
you can ask it to not use Bundle.

> (This is an useful case to consider; I think that if we call this
> one way or the other, it will make precedent for other items where
> SDP negotiation *should* result in things working OK, but people
> still want to do SDP mangling of an offer).
Received on Thursday, 22 August 2013 12:45:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC