[Standards] Jingle drafts

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Fri Apr 11 18:18:47 UTC 2008


On Friday 11 April 2008 8:03 am, Olivier Crête wrote:
> 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.

Right, but we would still have Speex as mandatory to implement.  As Paul 
mentioned, this may require transcoding at gateways, but the point is Jingle 
audio should never fail for codec reasons (provided transcoding audio is 
practical, maybe someone with experience can comment on this).

-Justin



More information about the Standards mailing list