[Standards] Jingle: one RTP application type to bind them all?

Peter Saint-Andre stpeter at stpeter.im
Thu May 29 20:13:02 UTC 2008


On 05/29/2008 1:38 PM, Robert McQueen wrote:
> Peter Saint-Andre wrote:
>> Back in April, Olivier Cr�te questioned whether we really need separate
>> application types for RTP audio (XEP-0167) and RFC video (XEP-0180):
>>
>> http://mail.jabber.org/pipermail/standards/2008-April/018554.html
>>
>> Olivier suggested that we could simply negotiate one RTP "channel" and
>> use it for anything that RTP can do -- voice, video, real-time text (RFC
>> 4103), etc. I have not seen a lot of enthusiasm for this idea, but I
>> would like to make sure that we have consensus on keeping things as-is
>> before moving forward with the Jingle specs. If you have feedback on
>> this issue, please weigh in on the standards at xmpp.org list.
> 
> I think I'm in favour of this, given the two XEPs seem to be copies of
> each other. We could just have one RTP/AVP description XEP, with a media
> type field. 

Yes I looked into that a while back. For instance we might have this:

<jingle>
  <content type='audio'>
    <description xmlns='urn:xmpp:jingle:apps:rtp'>
      <payload-type/>
      <payload-type/>
      <payload-type/>
    </description>
    <transport xmlns='urn:xmpp:tmp:jingle:transports:ice-udp'/>
  </content>
  <content type='video'>
    <description xmlns='urn:xmpp:jingle:apps:rtp'>
      <payload-type/>
      <payload-type/>
      <payload-type/>
    </description>
    <transport xmlns='urn:xmpp:tmp:jingle:transports:ice-udp'/>
  </content>
</jingle>

Then I thought about extending that model further. For example, let's
say we want to use Jingle to negotiate a shared XHTML editing session
using SXE [1] or direct bytestreams or whatever (I'm not focused on the
transport right now). We might then have this:

<jingle>
  <content type='text' subtype='html'>
    <description xmlns='urn:xmpp:jingle:apps:xhtml'/>
    <transport xmlns='urn:xmpp:tmp:jingle:transports:sxe'>
  </content>
</jingle>

It's not clear to me how helpful the content type and subtype are. For
example you might have the same information for a file transfer:

<jingle>
  <content type='text' subtype='html'>
    <description xmlns='urn:xmpp:jingle:apps:file-transfer'/>
    <transport xmlns='urn:xmpp:tmp:jingle:transports:ibb'>
  </content>
</jingle>

Or contrast an SVG whiteboarding session and an SVG image transfer:

<jingle>
  <content type='application' subtype='svg+xml'>
    <description xmlns='urn:xmpp:jingle:apps:xhtml'/>
    <transport xmlns='urn:xmpp:tmp:jingle:transports:sxe'>
  </content>
</jingle>

vs.

<jingle>
  <content type='application' subtype='svg+xml'>
    <description xmlns='urn:xmpp:jingle:apps:file-transfer'/>
    <transport xmlns='urn:xmpp:tmp:jingle:transports:ibb'>
  </content>
</jingle>

So you can't tell everything from the media type.

And we actively don't want to include the full media type information
for audio or video because that's what you're negotiating via the
payload types:

<jingle>
  <content type='audio' subtype='??????'>
    <description xmlns='urn:xmpp:jingle:apps: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'/>
      <payload-type id='102' name='iLBC'/>
      <payload-type id='4' name='G723'/>
      <payload-type id='0' name='PCMU' clockrate='16000'/>
      <payload-type id='8' name='PCMA'/>
      <payload-type id='13' name='CN'/>
    </description>
    <transport xmlns='urn:xmpp:tmp:jingle:transports:ice-udp'/>
  </content>
</jingle>

So while I think that including the media type as attributes of the
<content/> element is helpful in some instances, it doesn't give you
everything you need in order to determine whether you want to accept the
negotiation or whatever.

/psa

[1] http://www.xmpp.org/extensions/inbox/sxe.html



-------------- 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/20080529/8be9806c/attachment.bin>


More information about the Standards mailing list