[Standards] Jingle drafts

Olivier Crête olivier.crete at collabora.co.uk
Fri Apr 11 05:11:12 UTC 2008


I'm one of the developers of Farsight, a media streaming library.
Farsight is used as part of Telepathy to implement Jingle audio/video.
I've recently read the jingle draft and I have a few questions and

Jingle ICE-UDP

Is it really required to send candidates separately instead of sending
them in one batch? Sending them in one batch like the ICE-19 draft says
would make having a single implementation for Jingle/SIP more simple.
Also, ICE-19 needs to order all of the candidates pair before it does

5. Protocol description
The content-replace is being sent before the content-accept, which
contradicts the Jingle XEP which says that content-replace can not come
in the PENDING state, but must be after session-accept

Jingle audio

4. Application format
Why make the name attribute of the payload-type tag optional at all? Why
is the profile optional? and if it stays optional a default should be
specified (probably RTP/AVP) ?

5. Negotiation
Why make the semantics slightly different from those proposed in RFC
3264 (SDP Offer/Answer) ? The "declare what we can receive" differs from
how SOA is used with some codecs (eg. H.264, see RFC 3984 section
8.2.2). That also means that it does not accommodate codecs such as
H.264 has have config-data that has to be sent from the sender to the

I'm very much in favor of recommending PCMA/U, but mandating it would be
a problem because its relatively high bandwidth. And RFC4733 should
probably be mandated for audio/tone and audio/telephone-event. In the
case of audio/telephone-event, the optional properties (the fmtp line in
SDP) does not have the a=b format, we should probably mandate the
parameter name "event" for the list of supported event types.

Jingle video

Why is this separate from jingle-audio? It seems to be mostly
copy-pasted content. Even the examples use Speex. So most of my
questions on Jingle audio apply here too. It would probably be more
simple to have a single Jingle-rtp XEP  with a media="" attribution in
the content tag. That would also give us free "text" type for
synchronized subtitles (there is some RFC about that somewhere).

4. Application format
Why is the height/width specified? Why most payload types, it can change
dynamically without the signalling being notified, for example in the
case of H.263. How does width/height related to x/y? Are x/y coordinates
inside a width/height sized area or is width/height the size of the
rectangle displayed at x/y ? In either case, both the size of the
picture and of the full frame should probably be included? And what is
the use case for these?

7. Error Handling
Why is unsupported-codecs here but not in Jingle audio ?

Jingle DTMF

Why is RFC4733 negotiated separately from others audio codecs? It seems
to be redundant with the regular negotiation of codecs.
Maybe there should just be an "on/off" negotiation of the XMPP DTMF
method separate from the use of RFC 4733. Also, sine, XMPP dtmf doesnt
not include any timing information, it could be argued that it is
actually less real-time than RFC 4733 DTMF.

I hope my observations can help improve the Jingle drafts.

Olivier Crête
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080411/18a4d01a/attachment.sig>

More information about the Standards mailing list