Re: Transport related API need

On Aug 27, 2013, at 2:07 PM, Roman Shpount <roman@telurix.com> wrote:

> 
> On Tue, Aug 27, 2013 at 1:48 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:
> > This particular example is specific to iLBC. In this particular offer,
> > the party specifies that it can support iLBC with 20 and 30 ms ptimes
> > and remote party can switch between those two ptimes at will be sending
> > packets with different payload types.
> 
> I still don't get the purpose of this. But if this is something that is
> commonly used for iLBC I would expect browsers that support iLBC to use
> it in the offer - without any specific input from the application.
> 
> >
> > The concept itself is more generic though and applies to any codec
> > parameters. If you can specify the same codec with different parameters,
> > you generally let the remote party know that you support receiving an
> > audio codec with any of those parameter combinations and that remote
> > party can switch between those parameter combinations at will by
> > changing payload type. This does not apply to Opus/VP8/G.711, so if no
> > other codecs are implemented this would not make a difference, but would
> > be quite common otherwise. For example, listing iLBC with two different
> > payload types is something I commonly see with SIP end points supporting
> > this codec.
> >
> > P.S. All of those examples are just to point out that we would need
> > constraints to provide a prioritized list of codecs with parameters,
> > where codecs may repeat with different parameter values, i.e. I need a
> > constraint where I would prefer Opus to iLBC 20 ms, and iLBC 20ms to
> > G.729, and G.729 to iLBC 30 ms.
> 
> It seems to me that the browser is in a much better position than the
> application to prioritize between codecs in many cases. For example, the
> browser could know which of the video codecs available are HW
> accelerated, and which uses SW encoding/decoding.
> 
> 
> I understand that you did not follow the discussion from the start but my points are:

I did follow it, I just don't agree. 

> 
> 1. Application implementer should be able to overwrite default codec order in browser offer or answer. This is negotiation and browser is not in possession of all the information here. Most basic example, if H.264 is implemented by the browser, and application developer wants it preferred over VP8, since he knows that the call with H.264 can be connected to his equipment better/cheaper/faster then VP8, but VP8 is supported by remote end point and will be preferred if present first in the offer. This is extremely common. One more example is when you communicating through a transcoding SBC with a network which supports iSAC natively and transcodes OPUS. Implementer would want to set iSAC preferred over OPUS when present.

The transcoder should pick the optimal for the transcoder and the browser should honor that. To be specific, if the SBC creates the offer, it should make sure that the non transcoded codec comes first and the browsers should go with that choice. If the browser creates the offer, then if lists both in it's order of preference but the SBC can override that preference order and choose the non transcoded one. 

Now of course I'm not saying applications should not be able to reorder the codecs if they want, I'm just saying it not something I see a real use case for the JS to need to be able to do. What will happen is JS will be written that preferences codec A and when a new and better codec comes out after the JS was written, it will be harder to migrate to. 



> 
> 2. When specifying preferred order of codecs it should be possible to specify the same codec multiple times with different parameters, or exclude codecs with particular parameter values, since the same code with different parameters can actually be encoded quite differently. See example with iLBC offer. Application developer might want to prefer 20 ms iLBC over 30 ms iLBC, or disable one of the all together.

I prefer you got to the use case you were interested in instead of specifying the solution and then we might be able to sort out how to deal with that use case.  


> 
> 
> _____________
> Roman Shpount
>

Received on Tuesday, 3 September 2013 19:48:11 UTC