[Standards] Jingle drafts

Peter Saint-Andre stpeter at stpeter.im
Fri Apr 11 17:22:57 UTC 2008

Peter Saint-Andre wrote:
> Olivier Crête wrote:
>> On Fri, 2008-04-11 at 09:35 -0600, Peter Saint-Andre wrote:
>>> Olivier Crête wrote:
>>>> 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).
>>> 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
>> RFC 4103 would be an example, although I'm not certain if having
>> text-as-rtp is really good for something like XMPP, making it
>> supportable would probably make gatewaying easier.
> Yeah I think we have text communication pretty well covered in XMPP. :)
> But for synchronized voice+video+text you're right. We have not
> considered use cases like that (again, we're trying to keep things simple).
> I suppose what you're saying is that we would have a generalized way to
> negotiate an RTP transport, and what you do with that transport is up to
> you (it could be voice, it could be video, it could be real-time text,
> it could be anything that that the RTP folks dream up). If we go down
> that path, then we'd need a different way to discover capabilities
> before the negotiation begins. Right now discovery depends on namespaces
> like urn:xmpp:jingle:audio-rtp and urn:xmpp:jingle:video-rtp. But I
> suppose we can define disco features that are used in service discovery
> and entity capabilities (e.g., one feature for each media type), which
> would be separate from the RTP negotiation itself.
> /me ponders...

The more I think about this, the more I like it.

So for instance, modifying Example 36 from XEP-0167 would yield:

<iq from='romeo at montague.lit/orchard'
    to='juliet at capulet.lit/balcony'
  <jingle xmlns='urn:xmpp:tmp:jingle'
          initiator='romeo at montague.lit/orchard'
    <content creator='initiator'
==>          type='audio'>
      <description xmlns='urn:xmpp:tmp:jingle:apps:audio-rtp'
        <payload-type id='96' name='speex' clockrate='16000'/>
        <payload-type id='97' name='speex' clockrate='8000'/>
        <payload-type id='18' name='G729'/>
        <payload-type id='103' name='L16' clockrate='16000' channels='2'/>
        <payload-type id='98' name='x-ISAC' clockrate='8000'/>
      <transport xmlns='urn:xmpp:tmp:jingle:transports:ice-udp'/>
    <content creator='initiator'
==>          type='video'>
      <description xmlns='urn:xmpp:tmp:jingle:apps:video-rtp'
        <payload-type id='99' name='theora' clockrate='90000'>
          <parameter name='delivery-method' value='inline'/>
          <parameter name='configuration' value='somebase16string'/>
          <parameter name='height' value='720'/>
          <parameter name='sampling' value='YCbCr-4:2:2'/>
          <parameter name='width' value='1280'/>
        <payload-type id='28' name='nv' clockrate='90000'/>
        <payload-type id='25' name='CelB' clockrate='90000'/>
        <payload-type id='32' name='MPV' clockrate='90000'/>
      <transport xmlns='urn:xmpp:tmp:jingle:transports:ice-udp'/>

I think the 'type' attribute would correspond to a Content Type as
registered at http://www.iana.org/assignments/media-types/ (e.g.,
"audio" or "video"), although I suppose nothing stops us from defining
an optional 'subtype' attribute so that people could use Jingle to
negotiate things like 'application/javascript' (!) or whatever. For
audio and video the subtypes are captured by the payload-types, but
that's not necessarily true for other MIME types.

Still pondering...


Peter Saint-Andre

-------------- 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/a6e846df/attachment.bin>

More information about the Standards mailing list