Re: Transport related API need

On Tue, Sep 3, 2013 at 3:47 PM, Cullen Jennings (fluffy)
<fluffy@cisco.com>wrote:

>
> 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.
>

I am still not sure you do follow.


>  >
> > 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.
>

I am talking about the case were browser creates the offer. Well behaved
remote party is supposed to use the first codec in the browser offer even
though this is not something desired for this application. I am looking for
a way to overwrite the codec order in the offer without rewriting entire
SDP. Pushing iSAC in front of OPUS in browser offer is an example of things
I currently need to do.


> 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.
>
>
There are plenty of people on this list who think that reordering codecs in
browser offer has a real use case for them. You seem to disagree.


> >
> > 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.
>
>
All I am saying here that if we agree on the point that JS application
should be able to reorder codecs in SDP offer, it should be able to specify
order where the same codec is present multiple times with different
parameters and different payload types. Codec parameters can change what
codec means and right now the only way to specify multiple mutually
exclusive parameter sets for the same code is to specify codec multiple
times in SDP with different payload types. BTW, I was providing the use
case with iLBC as an example and not providing the solution. Please read
more carefully.
_____________
Roman Shpount