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='[EMAIL PROTECTED]/orchard'
id='jingle1'
to='[EMAIL PROTECTED]/balcony'
type='set'>
<jingle xmlns='urn:xmpp:tmp:jingle'
action='session-initiate'
initiator='[EMAIL PROTECTED]/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator'
name='this-is-the-audio-content'
==> type='audio'>
<description xmlns='urn:xmpp:tmp:jingle:apps:audio-rtp'
profile='RTP/AVP'>
<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'/>
</description>
<transport xmlns='urn:xmpp:tmp:jingle:transports:ice-udp'/>
</content>
<content creator='initiator'
name='this-is-the-video-content'
==> type='video'>
<description xmlns='urn:xmpp:tmp:jingle:apps:video-rtp'
profile='RTP/AVP'>
<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>
<payload-type id='28' name='nv' clockrate='90000'/>
<payload-type id='25' name='CelB' clockrate='90000'/>
<payload-type id='32' name='MPV' clockrate='90000'/>
</description>
<transport xmlns='urn:xmpp:tmp:jingle:transports:ice-udp'/>
</content>
</jingle>
</iq>
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
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
