[Jingle] Mappings of "raw" SDP fmtp attributes

Justin Uberti juberti at google.com
Tue Mar 22 17:22:56 CST 2011


As discussed in the "RTP Retransmission Payload Format" thread, the current
mechanism in XEP-0167 for mapping SDP format-specific
parameters<http://xmpp.org/extensions/xep-0167.html#sdp> is
not well-specified for parameters that are not of the format
"key1=value1;key2=value2".

The current text in section 4 indicates:

*Each <payload-type/> element MAY contain one or more child elements that
specify particular parameters related to the payload. For example, as
described in RFC 5574 <http://tools.ietf.org/html/rfc5574>
[13<http://xmpp.org/extensions/xep-0167.html#nt-id89171>],
the "cng", "mode", and "vbr" parameters can be specified in relation to
usage of the Speex [14 <http://xmpp.org/extensions/xep-0167.html#nt-id89153>]
codec. Where such parameters are encoded via the "fmtp" SDP attribute, they
shall be represented in Jingle via the following format:
*
<parameter name='foo' value='bar'/>


This works for SDP lines like

 "a=fmtp:96 vbr=on;cng=on"

but does not work for the fmtp parameter for the RED audio codec, a
slash-delimited list of payload types to use in RED

 "a=fmtp:117 0/5"

I propose that we amend the text above to say that "Parameters that are not
of the form key=value will be represented in their raw form, with name set
to "fmtp" and value set to the raw contents of the parameter, e.g.:
<parameter name='fmtp' value='0/5'/>. The name "fmtp" is chosen as a value
that is unlikely to be seen as a legitimate parameter name."

Any objections to this proposal?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20110322/83dbcb1b/attachment.htm>


More information about the Jingle mailing list