[Standards] XEP-0167: Jingle RTP Sessions - payload type parameters w/o value?

Jonathan Lennox lennox at cs.columbia.edu
Wed Jun 17 15:19:27 UTC 2020


There was also a brief discusson of this and related issues in STOX at
https://mailarchive.ietf.org/arch/msg/stox/FgU-TvQED1aOuM80iCBka8vp3tc/ .

The SDP for the case you quoted would look like:

m=audio 12346 RTP/AVP 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

The telephone-event payload type is specified in RFC 4733.  Technically
(according to the media type registration) the content of the fmtp field is
an implicit "events" parameter, but the "events" parameter name isn't
encoded into SDP for historical reasons.


The other "weird" payload type format that's likely to show up in Jingle
clients is audio/red -- its SDP looks like

m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 red/8000/1
a=fmtp:121 0/5


I don't believe there was ever any consensus about the right way to encode
these codecs into Jingle.

For telephone-event my suggestion is to special-case it (senders should
insert "events" as the parameter name, receivers should presume the
parameter is "events").

For red I'm less certain - I'm curious what existing Jingle clients do.


On Wednesday, June 17 2020, "Daniel Gultsch" wrote to "XMPP Standards" saying:

> There is a 2011 thread on the same topic:
> https://mail.jabber.org/pipermail/jingle/2011-March/001438.html that
> as far as I can tell (my personal archives don’t go back that far)
> never went anywhere.
> 
> Am Mi., 17. Juni 2020 um 14:17 Uhr schrieb Daniel Gultsch <daniel at gultsch.de>:
> >
> > Hi,
> >
> > I've seen a couple of Jingle RTP implementations in the wild that send
> > XML looking like this: (note the lack o a 'name' attribute)
> >
> > <payload-type channels="1" name="telephone-event" clockrate="8000" id="101">
> >   <parameter value="0-15" xmlns="urn:xmpp:jingle:apps:rtp:1"/>
> > </payload-type>
> >
> > which is illegal according to the (non normative) scheme (both name
> > and value are required attributes) whereas the normative text doesn’t
> > say anything on whether either or both value and name can be omitted.
> >
> > Can someone more familiar with what this actually maps to clarify?
> >
> > Note that the implementations sending this are parsing this from firefoxes SDP.
> >
> > cheers
> > Daniel
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

-- 
Jonathan Lennox
lennox at cs.columbia.edu


More information about the Standards mailing list