Re: Transport related API need

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