No Description
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

xep-0180.xml 27KB

  1. <?xml version='1.0' encoding='UTF-8'?>
  2. <!DOCTYPE xep SYSTEM 'xep.dtd' [
  3. <!ENTITY % ents SYSTEM 'xep.ent'>
  4. %ents;
  5. ]>
  6. <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
  7. <xep>
  8. <header>
  9. <title>Jingle Video via RTP</title>
  10. <abstract>
  11. Note: This specification has been retracted in favor of XEP-0167, which now
  12. consolidates both audio and video chat via RTP and therefore contains the
  13. content originally published in this specification; please refer to XEP-0167
  14. for the most up-to-date definition of XMPP video chat.
  15. This specification defines a Jingle application type for negotiating a video
  16. chat or other video session.
  17. The application type uses the Real-time Transport Protocol (RTP) for the
  18. underlying media exchange and provides a straightforward mapping to Session
  19. Description Protocol (SDP) for interworking with SIP media endpoints.
  20. </abstract>
  22. <number>0180</number>
  23. <status>Retracted</status>
  24. <type>Standards Track</type>
  25. <sig>Standards</sig>
  26. <approver>Council</approver>
  27. <dependencies>
  28. <spec>XMPP Core</spec>
  29. <spec>XEP-0166</spec>
  30. </dependencies>
  31. <supersedes/>
  32. <supersededby>
  33. <spec>XEP-0167</spec>
  34. </supersededby>
  35. <shortname>NOT_YET_ASSIGNED</shortname>
  36. &stpeter;
  37. <author>
  38. <firstname>Milton</firstname>
  39. <surname>Chen</surname>
  40. <email></email>
  41. </author>
  42. <revision>
  43. <version>0.13</version>
  44. <date>2008-06-04</date>
  45. <initials>psa</initials>
  46. <remark><p>Retracted in favor of XEP-0167, which now consolidates both audio and video chat via RTP and therefore contains the content originally published in this specification.</p></remark>
  47. </revision>
  48. <revision>
  49. <version>0.12</version>
  50. <date>2008-05-28</date>
  51. <initials>psa</initials>
  52. <remark><p>Specified default value for profile attribute; clarified relationship to SDP offer-answer model; moved some attributes from payload-type element to optional parameter elements.</p></remark>
  53. </revision>
  54. <revision>
  55. <version>0.11</version>
  56. <date>2008-02-28</date>
  57. <initials>psa</initials>
  58. <remark><p>Moved profile attribute from XEP-0166 to this specification.</p></remark>
  59. </revision>
  60. <revision>
  61. <version>0.10</version>
  62. <date>2007-11-27</date>
  63. <initials>psa</initials>
  64. <remark><p>Further editorial review.</p></remark>
  65. </revision>
  66. <revision>
  67. <version>0.9</version>
  68. <date>2007-11-15</date>
  69. <initials>psa</initials>
  70. <remark><p>Editorial review and consistency check.</p></remark>
  71. </revision>
  72. <revision>
  73. <version>0.8</version>
  74. <date>2007-05-23</date>
  75. <initials>psa</initials>
  76. <remark><p>Corrected examples to use video codecs; added clockrate attribute.</p></remark>
  77. </revision>
  78. <revision>
  79. <version>0.7</version>
  80. <date>2007-05-23</date>
  81. <initials>psa</initials>
  82. <remark><p>More completely specified how to include SDP parameters and codec-specific parameters (same approach as in XEP-0167); added and corrected Theora examples.</p></remark>
  83. </revision>
  84. <revision>
  85. <version>0.6</version>
  86. <date>2007-04-17</date>
  87. <initials>psa</initials>
  88. <remark><p>Specified Jingle conformance, including the need to use a lossy transport and the process of sending and receiving video content.</p></remark>
  89. </revision>
  90. <revision>
  91. <version>0.5</version>
  92. <date>2007-03-23</date>
  93. <initials>psa</initials>
  94. <remark><p>Added negotiation flow and SDP mapping; renamed to mention RTP as the associated transport; corrected negotiation flow to be consistent with SIP/SDP (each party specifies a list of the payload types it can receive); added profile attribute to content element in order to specify RTP profile in use.</p></remark>
  95. </revision>
  96. <revision>
  97. <version>0.4</version>
  98. <date>2006-12-21</date>
  99. <initials>psa</initials>
  100. <remark><p>Modified spec to use provisional namespace before advancement to Draft (per XEP-0053).</p></remark>
  101. </revision>
  102. <revision>
  103. <version>0.3</version>
  104. <date>2006-08-23</date>
  105. <initials>psa</initials>
  106. <remark><p>Modified namespace to track XEP-0166.</p></remark>
  107. </revision>
  108. <revision>
  109. <version>0.2</version>
  110. <date>2006-07-12</date>
  111. <initials>psa</initials>
  112. <remark><p>Updated to use content type instead of media type.</p></remark>
  113. </revision>
  114. <revision>
  115. <version>0.1</version>
  116. <date>2006-03-23</date>
  117. <initials>psa/mc</initials>
  118. <remark><p>Initial version.</p></remark>
  119. </revision>
  120. <revision>
  121. <version>0.0.1</version>
  122. <date>2006-03-20</date>
  123. <initials>psa/mc</initials>
  124. <remark><p>First draft.</p></remark>
  125. </revision>
  126. </header>
  127. <section1 topic='Introduction' anchor='intro'>
  128. <p class='box'><em>Note: This specification has been retracted in favor of &xep0167;, which now consolidates both audio and video chat via RTP and therefore contains the content originally published in this specification; please refer to XEP-0167 for the most up-to-date definition of XMPP video chat.</em></p>
  129. <p>&xep0166; can be used to initiate and negotiate a wide range of peer-to-peer sessions. One session type of interest is video chat. This document specifies a format for describing Jingle video sessions, where the media exchange occurs using the Real-time Transport Protocol (see &rfc3550;).</p>
  130. </section1>
  131. <section1 topic='Requirements' anchor='reqs'>
  132. <p>The Jingle application format defined herein is designed to meet the following requirements:</p>
  133. <ol>
  134. <li>Enable negotiation of parameters necessary for video chat.</li>
  135. <li>Map these parameters to the Session Description Protocol (SDP; see &rfc4566;) to enable interoperability.</li>
  136. <li>Define informational messages related to video chat.</li>
  137. </ol>
  138. </section1>
  139. <section1 topic='Jingle Conformance' anchor='conformance'>
  140. <p>In accordance with Section 8 of <cite>XEP-0166</cite>, this document specifies the following information related to the Jingle Video via RTP application type:</p>
  141. <ol>
  142. <li><p>The application format negotiation process is defined in the <link url='#negotiation'>Negotiating a Jingle Video Session</link> section of this document.</p></li>
  143. <li><p>The semantics of the &DESCRIPTION; element are defined in the <link url='#format'>Application Format</link> section of this document.</p></li>
  144. <li><p>A mapping of Jingle semantics to the Session Description Protocol is provided in the <link url='#sdp'>Mapping to Session Description Protocol</link> section of this document.</p></li>
  145. <li><p>A Jingle video session SHOULD use a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;.</p></li>
  146. <li>
  147. <p>Content is to be sent and received as follows:</p>
  148. <ul>
  149. <li><p>Outbound video content shall be encoded into RTP packets and each packet shall be sent individually over the transport. Each inbound packet received over the transport is an RTP packet.</p></li>
  150. </ul>
  151. </li>
  152. </ol>
  153. </section1>
  154. <section1 topic='Application Format' anchor='format'>
  155. <p>A Jingle video session is described by a content type that contains one application format and one transport method. The application format consists of one or more encodings contained within a wrapper &lt;description/&gt; element qualified by the 'urn:xmpp:tmp:jingle:apps:video-rtp' namespace &NSNOTE;. In the language of <cite>RFC 4566</cite> each encoding is a payload-type; therefore, each &lt;payload-type/&gt; element specifies an encoding that can be used for the audio stream, as illustrated in the following example.</p>
  156. <example caption="Video description format"><![CDATA[
  157. <description xmlns='urn:xmpp:tmp:jingle:apps:video-rtp'>
  158. <payload-type id='96' name='theora' clockrate='90000'>
  159. <parameter name='height' value='720'/>
  160. <parameter name='width' value='1280'/>
  161. <parameter name='delivery-method' value='inline'/>
  162. <parameter name='configuration' value='somebase16string'/>
  163. <parameter name='sampling' value='YCbCr-4:2:2'/>
  164. </payload-type>
  165. <payload-type id='28' name='nv' clockrate='90000'/>
  166. <payload-type id='25' name='CelB' clockrate='90000'/>
  167. <payload-type id='32' name='MPV' clockrate='90000'/>
  168. </description>
  169. ]]></example>
  170. <p>The &DESCRIPTION; element is intended to be a child of a &CONTENT; element as specified in <cite>XEP-0166</cite>.</p>
  171. <p>The &DESCRIPTION; element SHOULD possess a 'profile' attribute that specifies the profile of RTP in use as would be encapsulated in SDP (e.g., "RTP/AVP" or "UDP/TLS/RTP/SAVP"). If not included, the default value of "RTP/AVP" MUST be assumed.</p>
  172. <p>The encodings SHOULD be provided in order of preference by placing the most-preferred &PAYLOADTYPE; element as the first child of the &DESCRIPTION; element (etc.).</p>
  173. <p>The allowable attributes of the &PAYLOADTYPE; element are as follows:</p>
  174. <table caption='Payload-Type Attributes'>
  175. <tr>
  176. <th>Attribute</th>
  177. <th>Description</th>
  178. <th>Datatype/Units</th>
  179. <th>Inclusion</th>
  180. </tr>
  181. <tr>
  182. <td>channels</td>
  183. <td>The number of channels (e.g., 2 for stereoscopic video)</td>
  184. <td>positiveInteger (defaults to 1)</td>
  185. <td>OPTIONAL</td>
  186. </tr>
  187. <tr>
  188. <td>clockrate</td>
  189. <td>The sampling frequency in Hertz</td>
  190. <td>positiveInteger</td>
  191. <td>RECOMMENDED</td>
  192. </tr>
  193. <tr>
  194. <td>id</td>
  195. <td>A unique identifier for the payload type</td>
  196. <td>positiveInteger</td>
  197. <td>REQUIRED</td>
  198. </tr>
  199. <tr>
  200. <td>name</td>
  201. <td>A name for the payload type</td>
  202. <td>string</td>
  203. <td>RECOMMENDED for static payload types, REQUIRED for dynamic payload types</td>
  204. </tr>
  205. </table>
  206. <p>In Jingle Video, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of <cite>RFC 3551</cite>. The payload IDs are represented in the 'id' attribute.</p>
  207. <p>Each &lt;payload-type/&gt; element MAY contain one or more child elements that specify particular parameters related to the payload. For example, as described in &rtptheora;, the "configuration", "configuration-uri", "delivery-method", "height", "sampling", and "width" parameters may be specified in relation to usage of the Theora <note>See &lt;<link url=''></link>&gt;.</note> codec. Where such parameters are encoded via the "fmtp" SDP attribute, they shall be represented in Jingle via the following format:</p>
  208. <code><![CDATA[
  209. <parameter name='foo' value='bar'/>
  210. ]]></code>
  211. <p>Note: The parameter names are effectively guaranteed to be unique, since &IANA; maintains a registry of SDP parameters (see &lt;<link url=''></link>&gt;).</p>
  212. </section1>
  213. <section1 topic='Negotiating a Jingle Video Session' anchor='negotiation'>
  214. <p>When the initiator sends a session-initiate stanza to the responder, the &DESCRIPTION; element includes all of the payload types that the initiator can send and/or receive for Jingle video, each one encapsulated in a separate &PAYLOADTYPE; element (the rules specified in &rfc3264; SHOULD be followed regarding inclusion of payload types).</p>
  215. <example caption="Initiation"><![CDATA[
  216. <iq from=''
  217. to=''
  218. id='jinglevideo1'
  219. type='set'>
  220. <jingle xmlns='urn:xmpp:tmp:jingle'>
  221. action='session-initiate'
  222. initiator=''
  223. sid='v1d30k1ll3dth3r4d10st4r'>
  224. <content content='initiator' name='this-is-the-video-content'>
  225. <description xmlns='urn:xmpp:tmp:jingle:apps:video-rtp' profile='RTP/AVP'>
  226. <payload-type id='96' name='theora' clockrate='90000'>
  227. <parameter name='height' value='720'/>
  228. <parameter name='width' value='1280'/>
  229. <parameter name='delivery-method' value='inline'/>
  230. <parameter name='configuration' value='somebase16string'/>
  231. <parameter name='sampling' value='YCbCr-4:2:2'/>
  232. </payload-type>
  233. <payload-type id='28' name='nv' clockrate='90000'/>
  234. <payload-type id='25' name='CelB' clockrate='90000'/>
  235. <payload-type id='32' name='MPV' clockrate='90000'/>
  236. </description>
  237. <transport xmlns='urn:xmpp:tmp:jingle:transports:ice-tcp'/>
  238. </content>
  239. </jingle>
  240. </iq>
  241. ]]></example>
  242. <p>Upon receiving the session-initiate stanza, the responder determines whether it can proceed with the negotiation. The general Jingle error cases are specified in <cite>XEP-0166</cite> and illustrated &xep0167;. In addition, the responder must determine if it supports any of the payload types advertised by the initiator; if it supports none of the offered payload types, it must reject the session by returning a &notacceptable; error with a Jingle-Video-specific condition of &lt;unsupported-codecs/&gt;:</p>
  243. <example caption="Responder does not support any of the codecs"><![CDATA[
  244. <iq from=''
  245. id='jingleaudio1'
  246. to=''
  247. type='error'>
  248. <error type='cancel'>
  249. <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  250. <unsupported-codecs xmlns='urn:xmpp:tmp:jingle:apps:video:errors'/>
  251. </error>
  252. </iq>
  253. ]]></example>
  254. <p>If there is no error, the responder acknowledges the session initiation request:</p>
  255. <example caption="Responder acknowledges session-initiate request"><![CDATA[
  256. <iq from=''
  257. id='jinglevideo1'
  258. to=''
  259. type='result' />
  260. ]]></example>
  261. <p>If the responder wishes to accept the content definition, it MUST send a content-accept action to the initiator, which SHOULD include a list of the payload types that it can send and/or receive. The list that the responder sends MAY include any payload types (not a subset of the payload types sent by the initiator) but SHOULD retain the ID numbers specified by the initiator. The order of the &PAYLOADTYPE; elements indicates the responder's preferences, with the most-preferred types first.</p>
  262. <example caption="Responder accepts content type"><![CDATA[
  263. <iq from=''
  264. to=''
  265. id='jinglevideo2'
  266. type='set'>
  267. <jingle xmlns='urn:xmpp:tmp:jingle'>
  268. action='content-accept'
  269. initiator=''
  270. sid='v1d30k1ll3dth3r4d10st4r'>
  271. <content content='initiator' name='this-is-the-video-content'>
  272. <description xmlns='urn:xmpp:tmp:jingle:apps:video-rtp' profile='RTP/AVP'>
  273. <payload-type id='96' name='theora' clockrate='90000'>
  274. <parameter name='height' value='720'/>
  275. <parameter name='width' value='1280'/>
  276. <parameter name='delivery-method' value='inline'/>
  277. <parameter name='configuration' value='somebase16string'/>
  278. <parameter name='sampling' value='YCbCr-4:2:2'/>
  279. </payload-type>
  280. <payload-type id='32' name='MPV' clockrate='90000'/>
  281. <payload-type id='33' name='MP2T' clockrate='90000'/>
  282. </description>
  283. <transport xmlns='urn:xmpp:tmp:jingle:transports:ice-tcp'/>
  284. </content>
  285. </jingle>
  286. </iq>
  287. ]]></example>
  288. <p>The initiator acknowledges the 'content-accept' with an empty IQ result:</p>
  289. <example caption="Initiator acknowledges modified application type"><![CDATA[
  290. <iq from=''
  291. to=''
  292. id='jinglevideo2'
  293. type='result'/>
  294. ]]></example>
  295. <p>After successful transport negotiation (for the ICE-UDP method, see <cite>XEP-0176</cite>), the responder then accepts the session:</p>
  296. <example caption="Responder definitively accepts the session"><![CDATA[
  297. <iq from=''
  298. id='accept1'
  299. to=''
  300. type='set'>
  301. <jingle xmlns='urn:xmpp:tmp:jingle'
  302. action='session-accept'
  303. initiator=''
  304. responder=''
  305. sid='v1d30k1ll3dth3r4d10st4r'>
  306. <content content='initiator' name='this-is-the-video-content'>
  307. <description xmlns='urn:xmpp:tmp:jingle:apps:video-rtp' profile='RTP/AVP'>
  308. <payload-type id='96' name='theora' clockrate='90000'>
  309. <parameter name='height' value='720'/>
  310. <parameter name='width' value='1280'/>
  311. <parameter name='delivery-method' value='inline'/>
  312. <parameter name='configuration' value='somebase16string'/>
  313. <parameter name='sampling' value='YCbCr-4:2:2'/>
  314. </payload-type>
  315. <payload-type id='32' name='MPV' clockrate='90000'/>
  316. <payload-type id='33' name='MP2T' clockrate='90000'/>
  317. </description>
  318. <transport xmlns='urn:xmpp:tmp:jingle:transports:ice-tcp'>
  319. <candidate component='1'
  320. foundation='1'
  321. generation='0'
  322. ip=''
  323. network='1'
  324. port='45664'
  325. priority='1694498815'
  326. protocol='udp'
  327. pwd='asd88fgpdd777uzjYhagZg'
  328. rel-addr=''
  329. rel-port='8998'
  330. rem-addr=''
  331. rem-port='3478'
  332. type='srflx'
  333. ufrag='8hhy'/>
  334. </transport>
  335. </content>
  336. </jingle>
  337. </iq>
  338. ]]></example>
  339. <p>And the initiator acknowledges session acceptance:</p>
  340. <example caption="Initiator acknowledges session acceptance"><![CDATA[
  341. <iq from=''
  342. to=''
  343. id='accept1'
  344. type='result' />
  345. ]]></example>
  346. <p>Note: For more examples, see <cite>XEP-0167</cite>.</p>
  347. </section1>
  348. <section1 topic='Mapping to Session Description Protocol' anchor='sdp'>
  349. <p>The SDP media type for Jingle Video via RTP is "video" (see Section 8.2.1 of <cite>RFC 4566</cite>).</p>
  350. <p>If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to a media field defined in <cite>RFC 4566</cite>. The generic format for the media field is as follows:</p>
  351. <code><![CDATA[
  352. m=<media> <port> <transport> <fmt list>
  353. ]]></code>
  354. <p>In the context of Jingle video sessions, the &lt;media&gt; is "video", the &lt;port&gt; is the preferred port for such communications (which may be determined dynamically), the &lt;transport&gt; is whatever profile is negotiated via the 'profile' attribute of the &CONTENT; element in the Jingle negotiation (e.g., "RTP/AVT"), and the &lt;fmt list&gt; is the payload-type ID.</p>
  355. <p>For example, consider the following static payload-type:</p>
  356. <example caption="Jingle format for static payload-type"><![CDATA[
  357. <payload-type id="28" name="nv"/>
  358. ]]></example>
  359. <p>That Jingle-formatted information would be mapped to SDP as follows:</p>
  360. <example caption="SDP mapping of static payload-type"><![CDATA[
  361. m=video 9000 RTP/AVP 28
  362. ]]></example>
  363. <p>If the payload type is dynamic (payload-type IDs 96 through 127 inclusive), it SHOULD be mapped to an SDP media field plus an SDP attribute field named "rtpmap".</p>
  364. <p>For example, consider a VC-1 payload such as that described in &rfc4425;:</p>
  365. <example caption="Jingle format for dynamic payload-type"><![CDATA[
  366. <payload-type id='98' name='vc1'/>
  367. ]]></example>
  368. <p>That Jingle-formatted information would be mapped to SDP as follows:</p>
  369. <example caption="SDP mapping of dynamic payload-type"><![CDATA[
  370. m=video 49170 RTP/AVP 98
  371. a=rtpmap:98 vc1/90000
  372. ]]></example>
  373. <p>As noted, if additional parameters are to be specified, they shall be represented as attributes of the &lt;payload-type/&gt; element or its child &lt;parameter/&gt; element, as in the following example.</p>
  374. <example caption="Jingle format for dynamic payload-type with parameters"><![CDATA[
  375. <payload-type id='96' name='theora' clockrate='90000'>
  376. <parameter name='height' value='720'/>
  377. <parameter name='width' value='1280'/>
  378. <parameter name='delivery-method' value='inline'/>
  379. <parameter name='configuration' value='somebase16string'/>
  380. <parameter name='sampling' value='YCbCr-4:2:2'/>
  381. </payload-type>
  382. ]]></example>
  383. <p>That Jingle-formatted information would be mapped to SDP as follows:</p>
  384. <example caption="SDP mapping of dynamic payload-type with parameters"><![CDATA[
  385. m=video 49170 RTP/AVP 98
  386. a=rtpmap:96 theora/90000
  387. a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720;
  388. delivery-method=inline; configuration=somebase16string;
  389. ]]></example>
  390. </section1>
  391. <section1 topic='Error Handling' anchor='errors'>
  392. <p>The Jingle-Video-specific error conditions are as follows:</p>
  393. <table caption='Other Error Conditions'>
  394. <tr>
  395. <th>Jingle Video Condition</th>
  396. <th>XMPP Condition</th>
  397. <th>Description</th>
  398. </tr>
  399. <tr>
  400. <td>&lt;unsupported-codecs/&gt;</td>
  401. <td>&notacceptable;</td>
  402. <td>The recipient does not support any of the offered video encodings.</td>
  403. </tr>
  404. </table>
  405. </section1>
  406. <section1 topic='Determining Support' anchor='support'>
  407. <p>If an entity supports Jingle video exchanges via RTP, it MUST advertise that fact by returning a feature of "urn:xmpp:tmp:jingle:apps:video" in response to &xep0030; information requests &NSNOTE;.</p>
  408. <example caption="Service discovery information request"><![CDATA[
  409. <iq from=''
  410. id='disco1'
  411. to=''
  412. type='get'>
  413. <query xmlns=''/>
  414. </iq>
  415. ]]></example>
  416. <example caption="Service discovery information response"><![CDATA[
  417. <iq from=''
  418. id='disco1'
  419. to=''
  420. type='result'>
  421. <query xmlns=''>
  422. ...
  423. <feature var='urn:xmpp:tmp:jingle'/>
  424. <feature var='urn:xmpp:tmp:jingle:apps:video-rtp'/>
  425. ...
  426. </query>
  427. </iq>
  428. ]]></example>
  429. <p>Naturally, support may also be discovered via the dynamic, presence-based profile of service discovery defined in &xep0115;.</p>
  430. </section1>
  431. <section1 topic='Informational Messages' anchor='info'>
  432. <p>Informational messages may be sent by either party within the context of Jingle to communicate the status of a Jingle video session, device, or principal. The informational message MUST be an IQ-set containing a &JINGLE; element of type "session-info". No informational message payload elements have yet been defined for Jingle Video via RTP, but they may be specified in a future version of this document.</p>
  433. </section1>
  434. <section1 topic='Implementation Notes' anchor='impl'>
  435. <section2 topic='Codecs' anchor='impl-codecs'>
  436. <p>Support for the Theora codec is RECOMMENDED.</p>
  437. </section2>
  438. </section1>
  439. <section1 topic='Security Considerations' anchor='security'>
  440. <p>In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged; for example, in the case of UDP, that would include Datagram Transport Layer Security (DTLS) as specified in &rfc4347;. &sdpdtls; defines such methods for the Session Description Protocol; the relevant RTP profile (e.g., "UDP/TLS/RTP/SAVP" for transporting the RTP stream over DTLS with UDP) shall be specified as the value of the &CONTENT; element's 'profile' attribute.</p>
  441. </section1>
  442. <section1 topic='IANA Considerations' anchor='iana'>
  443. <p>This document requires no interaction with &IANA;.</p>
  444. </section1>
  445. <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  446. <section2 topic='Protocol Namespaces' anchor='ns'>
  447. <p>Until this specification advances to a status of Draft, its associated namespaces shall be:</p>
  448. <ul>
  449. <li>urn:xmpp:tmp:jingle:apps:video</li>
  450. <li>urn:xmpp:tmp:jingle:apps:video:errors</li>
  451. </ul>
  452. <p>Upon advancement of this specification, the &REGISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.</p>
  453. <p>The following namespaces are requested, and are thought to be unique per the XMPP Registrar's requirements:</p>
  454. <ul>
  455. <li>urn:xmpp:jingle:app:video-rtp</li>
  456. <li>urn:xmpp:jingle:app:video-rtp:errors</li>
  457. </ul>
  458. </section2>
  459. <section2 topic='Jingle Application Formats' anchor='registrar-content'>
  460. <p>The XMPP Registrar shall include "video-rtp" in its registry of Jingle application formats. The registry submission is as follows:</p>
  461. <code><![CDATA[
  462. <application>
  463. <name>video-rtp</name>
  464. <desc>Jingle sessions that support video exchange via the Real-time Transport Protocol</desc>
  465. <transport>lossy</transport>
  466. <doc>XEP-0180</doc>
  467. </application>
  468. ]]></code>
  469. </section2>
  470. </section1>
  471. <section1 topic='XML Schemas' anchor='schema'>
  472. <section2 topic='Application Format' anchor='schema-content'>
  473. <code><![CDATA[
  474. <?xml version='1.0' encoding='UTF-8'?>
  475. <xs:schema
  476. xmlns:xs=''
  477. targetNamespace='urn:xmpp:tmp:jingle:apps:video-rtp'
  478. xmlns='urn:xmpp:tmp:jingle:apps:video-rtp'
  479. elementFormDefault='qualified'>
  480. <xs:element name='description'>
  481. <xs:complexType>
  482. <xs:sequence>
  483. <xs:element ref='payload-type' minOccurs='0' maxOccurs='unbounded'/>
  484. </xs:sequence>
  485. <xs:attribute name='profile' use='required' type='xs:string' default='RTP/AVP'/>
  486. </xs:complexType>
  487. </xs:element>
  488. <xs:element name='payload-type'>
  489. <xs:complexType>
  490. <xs:sequence minOccurs='0' maxOccurs='unbounded'>
  491. <xs:element ref='parameter'/>
  492. </xs:sequence>
  493. <xs:attribute name='channels' type='xs:integer' use='optional' default='1'/>
  494. <xs:attribute name='clockrate' type='xs:short' use='optional'/>
  495. <xs:attribute name='id' type='xs:unsignedByte' use='required'/>
  496. <xs:attribute name='name' type='xs:string' use='optional'/>
  497. </xs:complexType>
  498. </xs:element>
  499. <xs:element name='parameter'>
  500. <xs:complexType>
  501. <xs:simpleContent>
  502. <xs:extension base='empty'>
  503. <xs:attribute name='name' type='xs:string' use='required'/>
  504. <xs:attribute name='value' type='xs:string' use='required'/>
  505. </xs:extension>
  506. </xs:simpleContent>
  507. </xs:complexType>
  508. </xs:element>
  509. <xs:simpleType name='empty'>
  510. <xs:restriction base='xs:string'>
  511. <xs:enumeration value=''/>
  512. </xs:restriction>
  513. </xs:simpleType>
  514. </xs:schema>
  515. ]]></code>
  516. </section2>
  517. <section2 topic='Errors' anchor='schema-errors'>
  518. <code><![CDATA[
  519. <?xml version='1.0' encoding='UTF-8'?>
  520. <xs:schema
  521. xmlns:xs=''
  522. targetNamespace='urn:xmpp:tmp:jingle:apps:video:errors'
  523. xmlns='urn:xmpp:tmp:jingle:apps:video:errors'
  524. elementFormDefault='qualified'>
  525. <xs:element name='unsupported-codecs' type='empty'/>
  526. <xs:simpleType name='empty'>
  527. <xs:restriction base='xs:string'>
  528. <xs:enumeration value=''/>
  529. </xs:restriction>
  530. </xs:simpleType>
  531. </xs:schema>
  532. ]]></code>
  533. </section2>
  534. </section1>
  535. </xep>