[Standards] Jingle drafts

Peter Saint-Andre stpeter at stpeter.im
Fri Apr 11 15:35:07 UTC 2008


Olivier Crête wrote:
> Hello,
> 
> 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
> suggestions.

Thanks for your feedback.

> 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 main reason candidates are sent one at a time is to maintain
compatibility with Google Talk, which is a pre-ICE technology (though
similar in many ways to ICE). The schema does limit the <transport/>
element to one <candidate/> element at a time:

   <xs:element ref='candidate' minOccurs='0' maxOccurs='1'/>

I'm not sure if it would break anything to allow multiple candidates at
at time, but perhaps someone from the Google Talk team could weigh in on
that issue. I agree that allowing multiple candidates in a <transport/>
element would simplify gatewaying to standard ICE implementations, at
least for the initial ICE negotiation.

> 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

Right you are. XEP-0176 needs to be harmonized with XEP-0166 on this point.

> 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) ?

I think the optionality of the 'profile' attribute is a throwback to the
days when XEP-0167 was not explicitly limited to RTP. I think you're
right that we should make it required, and set the default to "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). 

From my conversations with Robert McQueen and Sean Egan at ClueCon last
year, I understand that there is a lot of variability in how particular
codecs are negotiated. It's not clear to me if it is possible to address
all the edge cases (and I'm not even aware of them all). We were not
consciously trying to stray from the offer/answer model, and if we can
maintain compatibility then I'm all for it.

> 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'm very much in favor of recommending PCMA/U, but mandating it would be
> a problem because its relatively high bandwidth. 

Duly noted. :)

> 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.

Doesn't this belong in XEP-0181 (Jingle DTMF)?

> Jingle video
> 
> Why is this separate from jingle-audio? It seems to be mostly
> copy-pasted content. Even the examples use Speex. 

Well that's wrong. Probably a copy-and-paste error.

> 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. 

IMHO that makes it harder to discover the capabilities on the other end,
but we could overcome that problem with proper disco features.

> That would also give us free "text" type for
> synchronized subtitles (there is some RFC about that somewhere).

I can't find an RFC about this. Perhaps you mean the following I-D?

http://tools.ietf.org/html/draft-schmidt-mmusic-media-dependency-00

> 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?

I think we were simply trying to make sure that parameters communicated
in the SDP were not lost on the Jingle side of a gateway.

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

XEP-0167 is correct -- clearly we did not remove this from XEP-0180 to
track changes to XEP-0166.

> Jingle DTMF
> 
> Why is RFC4733 negotiated separately from others audio codecs? It seems
> to be redundant with the regular negotiation of codecs.

If audio/tone and audio/telephone-event are full-fledged audio codecs
then I think that makes more sense. Presumably if both endpoints support
those codecs then they could be used over RTP without any further
negotiation.

> Maybe there should just be an "on/off" negotiation of the XMPP DTMF
> method separate from the use of RFC 4733. 

Yes that makes sense for XEP-0181.

> 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.

Well now is the time to fix the XMPP DTMF definition so that it includes
the timing info. I think Sean and I had glossed over the timing aspect
of DTMF when we first wrote XEP-0181.

> I hope my observations can help improve the Jingle drafts.

I think so, thanks. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080411/447a9c0b/attachment.bin>


More information about the Standards mailing list