RE: Transport related API need

As Stefan stated below a knob on the PeerConnection constructor to not bundle would also do the job.

Andy

> -----Original Message-----
> From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com]
> Sent: 22 August 2013 13:45
> To: Harald Alvestrand
> Cc: public-webrtc@w3.org
> Subject: 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 13:00:03 UTC