[Standards] Jingle drafts

Olivier Crête olivier.crete at collabora.co.uk
Fri Apr 11 15:03:13 UTC 2008

On Fri, 2008-04-11 at 11:43 +0100, Paul Witty wrote:
> Olivier Crête wrote:
> > 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
> > anything..
> >   
> The spec doesn't make it clear if it is acceptable to send multiple 
> candidates in one message; I can't see any reason why it shouldn't be 
> permitted.  However, ICE will inevitably cause candidates to be 
> generated in multiple events (some instantly, some waiting for responses 
> from STUN and TURN servers).  Because the instantly generated candidates 
> will be local, and therefore the highest priority, if an aggressive 
> implementation of ICE is used, when the two clients are on the same 
> network, it would be possible for ICE to complete before a STUN binding 
> response is ever received.

True, except that it means that an ICE implementation has to behave
slightly differently for Jingle and SIP. And it makes signalling-only
gatewaying difficult, since there is no way to know when all the
candidates have been received and its time to send the SDP.

> > 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
> > receiver.
> >   
> I believe that it should be possible to do H.264 without any information 
> being send from the sender to the receiver, although this means forgoing 
> the symmetry in capabilities which RFC 3984 mandates.

Maybe for h.264, but for Vorbis or Theora, you absolutely need to send
the config-data from the header, otherwise you can't decode anything.
And having the exact same semantics as SIP/SDP makes it possible to do
signalling-only translation/gatewaying.

> > 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.
> >   
> There's no need to mandate the "events" parameter; If absent, we assume 
> 0-9, *, # and A-D.  It should be possible to restrict this though, 
> (probably to 0-9, * and #), in which case putting:
> <parameter name='events' value='0-11'/>
> within the payload type tag would be the way to do this.  Note 'events', 
> not 'event', as in 2.4.1 of RFC 4733.

Sorry for not being clear, I'm just saying that for the <parameter> tag,
the name attribute should be required and not be empty, and if the SDP
doesnt provide a a=b format, we should use the name from the mime-type.

> > 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?
> >   
> Height and width are required for some codecs (H.261) to specify the 
> maximum we can receive, while others do crazier things (H.264).  In 
> fact, most of the none-required attributes seem to be codec-specific, 
> and should probably be outside the scope of XEP-0180.

Yes, for H.263 too, but that's clearly codec-specific.

> > 7. Error Handling
> > Why is unsupported-codecs here but not in Jingle audio ?
> >   
> Because everything will have G.711 in common? :-D

Not if G.711 is only recommended.

> > 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.
> >   
> Because we negotiate one audio channel, one video channel, and one DTMF 
> channel.
> XMPP DTMF has timing information: all the messages are sent in real time 
> (within the constraints of TCP), so button press durations can be 
> reasonably accurately recovered.

I don't really understand how DTMF is not audio. I always see
audio/telephone-event and audio/tone as very highly compressed
specialised codecs. And again, if RFC4733 is treaded like any other
codec, it makes signalling-only gatewaying possible.

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/6deac1f5/attachment.sig>

More information about the Standards mailing list