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

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

On 3/25/14 2:58 AM, Saúl Ibarra Corretgé wrote:
>
> On Mar 20, 2014, at 4:50 AM, Peter Saint-Andre wrote:
>
>> 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.
>>
>
> Same goes for H264 format AFAIS. It has many parameters, but in the end it's just a list of attribute=value separated by semicolons.

Agreed. I'm doing some research into the most common payload types and 
will report back soon regarding my findings.

Peter

-- 
Peter Saint-Andre
https://andyet.com/