Re: Transport related API need

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:

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.

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.


_____________
Roman Shpount