Re: Transport related API need

On Mon, Aug 12, 2013 at 2:38 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 2013-08-12 02:57, Roman Shpount wrote:
> >If  browser implements iLBC codec, it would most likely need to list iLBC
> > codec twice, one with with codec format parameter mode=20 and another
> > with format parameter mode=30. Here is an example:
> >
> > m=audio 49120 RTP/AVP 97 98
> > a=rtpmap:97 iLBC/8000/1
> > a=rtpmap:98 iLBC/8000/1
> > a=fmtp:97 mode=20
> > a=fmtp:98 mode=30
>
> I haven't followed that discussion, so I don't understand why. Is this
> something specific to iLBC? And what is the use case.
>
>
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.

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.
_____________
Roman Shpount