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.
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.. 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 receiver. 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 [EMAIL PROTECTED] Collabora Ltd
signature.asc
Description: This is a digitally signed message part
