Re: [Stox] stox-media: format parameter translation

[Peter Saint-Andre <[e-mail]>]

On 1/9/14, 10:22 AM, Jonathan Lennox wrote:
> This is the issue I brought up at the Interim -- I'll try to put it
> in writing.
>
> The point I raised is that the stox-media draft's section on format
> parameter translation should try to focus on media types which are
> actually used by existing, deployed Jingle clients, since this is
> probably a relatively small set.  The important question is which
> payload formats in use by existing Jingle clients have SDP fmtp
> formats that don't follow the normal semicolon-separated parameter
> model.
>
> I of course haven't done a full inventory of such payload formats,
> but two that seem reasonably likely and I think should be
> particularly called out are:
>
> audio/telephone-event: RFC 4733: the fmtp contains the value of an
> implicit "events" parameter.

That one seems relevant.

> audio/red: RFC 2198, with its media type registration in RFC 3555:
> the fmtp is the payload types of the encompassed formats.  The RFC
> 3555 definition of the actual media type parameters is weird (in an
> attempt to make it self-contained), and I doubt that any Jingle
> client that does RED would actually use it that way. So we need to
> figure out what any actual Jingle implementations do.
>
> Does anyone have a reasonably-authoritative list of which RTP payload
> formats are supported by existing Jingle clients?

I do not, but it's a small enough universe that we can poll the 
developers. (I expect it's mostly limited to common audio and video 
payloads - Speex, Opus, etc. - but we'll find out.)

> Does anyone know
> of any other real-world usage of codecs that have unusual fmtp
> encodings?

I think audio/telephone-event is a possibility.

> Someone on the call mentioned that they thought that
> Speex's was weird, but as far as I can tell, it's a normal
> semicolon-separated encoding.

Agreed.

Peter