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-0340.xml 28KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680
  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>COnferences with LIghtweight BRIdging (COLIBRI)</title>
  10. <abstract>This specification defines an XMPP extension that allows
  11. real-time communications clients to discover and interact with
  12. conference bridges that provide conference mixing or relaying
  13. capabilities.
  14. </abstract>
  15. &LEGALNOTICE;
  16. <number>0340</number>
  17. <status>Deferred</status>
  18. <type>Standards Track</type>
  19. <sig>Standards</sig>
  20. <approver>Council</approver>
  21. <dependencies>
  22. <spec>XEP-0167</spec>
  23. </dependencies>
  24. <supersedes/>
  25. <supersededby/>
  26. <shortname>colibri</shortname>
  27. <discuss>jingle</discuss>
  28. <author>
  29. <firstname>Emil</firstname>
  30. <surname>Ivov</surname>
  31. <org>jitsi.org</org>
  32. <email>emcho@jitsi.org</email>
  33. <jid>emcho@sip-communicator.org</jid>
  34. </author>
  35. <author>
  36. <firstname>Lyubomir</firstname>
  37. <surname>Marinov</surname>
  38. <org>jitsi.org</org>
  39. <email>lubo@jitsi.org</email>
  40. <jid>lubo@sip-communicator.org</jid>
  41. </author>
  42. &fippo;
  43. <revision>
  44. <version>0.2</version>
  45. <date>2017-09-11</date>
  46. <initials>XEP Editor (jwi)</initials>
  47. <remark>Defer due to lack of activity.</remark>
  48. </revision>
  49. <revision>
  50. <version>0.1</version>
  51. <date>2014-01-08</date>
  52. <initials>psa</initials>
  53. <remark><p>Initial published version approved by the XMPP Council.</p></remark>
  54. </revision>
  55. <revision>
  56. <version>0.0.2</version>
  57. <date>2013-12-04</date>
  58. <initials>ei/ph</initials>
  59. <remark>
  60. <p>Added usecases.</p>
  61. </remark>
  62. </revision>
  63. <revision>
  64. <version>0.0.1</version>
  65. <date>2013-05-30</date>
  66. <initials>ei/lm</initials>
  67. <remark>
  68. <p>First draft.</p>
  69. </remark>
  70. </revision>
  71. </header>
  72. <section1 topic='Introduction' anchor='intro'>
  73. <p>
  74. &xep0298; defines a way for XMPP agents to establish and
  75. participate in tightly coupled conference calls. Such conference
  76. calls would typically involve a number of regular participants
  77. that establish direct one-to-one sessions with a single entity,
  78. often referred to as a focus agent. Focus agents are generally
  79. responsible for making sure that media sent from one call
  80. participant would be distributed to all others so that everyone
  81. would effectively hear or see everyone else. In other words they
  82. often act as media mixers.
  83. </p>
  84. <p>
  85. Depending on the mixing technology used by media mixers, they may
  86. require significant bandwidth, processing resources or both. It is
  87. hence common for mixers to be hosted on dedicated servers that can
  88. provide such resources. They are then made reachable as
  89. rendez-vous points and conference call participants are required
  90. to call in, in order to join a conference call. This requires a
  91. certain amount of pre-call configuration to be completed by the
  92. service maintainers in order to create conference rooms and grant
  93. proper access to the expected participants. The authorization
  94. credentials are then often relayed to the participants in
  95. preparation of the call by other means, such as IM or mail.
  96. </p>
  97. <p>
  98. In certain situations, such pre-call preparations are
  99. inconvenient and it is important for users to be able to establish
  100. ad-hoc conference calls. One way to achieve this is for user
  101. agents themselves to act as focus agents and media mixers.
  102. Everyone else just calls the user at the focus agent, who then can
  103. decide whether to accept or reject the calls as they arrive. This
  104. works particularly well for audio only calls as the amount of
  105. bandwidth and processing resources that they require is generally
  106. within reach for end-user devices.
  107. </p>
  108. <p>
  109. The situation is quite different for video calls. Media decoding
  110. and especially encoding require considerably more resources with
  111. video than they do with audio. Today, encoding a single video flow
  112. with an acceptable quality is often the maximum that can be
  113. expected from an end-user device. The advantages that come with
  114. Moore's law will likely be insufficient to improve this, given the
  115. massive shift toward mobile devices and the ever-increasing user
  116. expectations toward video quality.
  117. </p>
  118. <p>
  119. Therefore, this specification (COLIBRI) aims to provide a means
  120. for user agents to interact with conference mixers. Such
  121. interaction allows user agents to allocate mixing channels,
  122. indicate what conferences they should be attached to, what
  123. integers the various payload types map to, etc. Using COLIBRI
  124. would hence allow any user agent to organize conference calls and
  125. act as a signalling focus by outsourcing the actual media mixing
  126. to a dedicated mixer.
  127. </p>
  128. </section1>
  129. <section1 topic='Terminology' anchor='terms'>
  130. <dl>
  131. <di>
  132. <dt>
  133. Focus or Focus Agent
  134. </dt>
  135. <dd>
  136. The terms apply to XMPP agents that, in terms of signalling,
  137. stand at the center of a tightly-coupled conference call. In
  138. other words, all conference participants establish a &xep0166;
  139. session with and only with that agent. Focus Agents are not
  140. necessarily performing media mixing themselves. In fact, the
  141. very purpose of this specification is to provide them with a
  142. means of handling this elsewhere.
  143. </dd>
  144. </di>
  145. <di>
  146. <dt>
  147. Mixer or Bridge
  148. </dt>
  149. <dd>
  150. Throughout this document the term is used to depict an
  151. entity that is responsible for mixing and delivering to
  152. conference participants all media exchanged in a conference
  153. call. Mixers or bridges can provide their service by either
  154. performing Content Mixing, or RTP translation or both.
  155. </dd>
  156. </di>
  157. <di>
  158. <dt>
  159. Content Mixing
  160. </dt>
  161. <dd>
  162. The term refers to a kind of media processing where the
  163. content of multiple input RTP streams is "mixed" into a single
  164. output stream. In conference calls audio mixing
  165. implementations generally simply add and adjust all source
  166. audio streams to produce their single output stream. Video
  167. content mixing, on the other hand, is often implemented by
  168. creating composite images containing individual frames from
  169. the input streams. Another common implementation consists in
  170. producing an output that is identical to one of the input
  171. streams, often the one belonging to a currently active
  172. speaker.
  173. </dd>
  174. </di>
  175. <di>
  176. <dt>
  177. RTP Translation
  178. </dt>
  179. <dd>
  180. <cite>RFC 3550</cite> defines a translator as "an intermediate
  181. system that forwards RTP packets with their synchronization
  182. source identifier intact." This specification respects that
  183. definition but it also uses "RTP Translation" in opposition
  184. with "Content Mixing". Conference bridges that perform RTP
  185. translation simply redirect each incoming RTP packet to all
  186. participants, often excluding the one where it came from.
  187. Contrary to content mixing, rtp translation generally requires
  188. less processing resources since it does not involve media
  189. manipulation. Bandwidth requirements on the other hand, could
  190. be significantly higher with RTP translation than with content
  191. mixing.
  192. </dd>
  193. </di>
  194. </dl>
  195. </section1>
  196. <section1 topic='Requirements' anchor='reqs'>
  197. <p>
  198. The extension defined herein is designed to meet the following
  199. requirements:
  200. </p>
  201. <ol>
  202. <li>
  203. Provide a means for conference focus agents to interact with
  204. conference mixers in order to configure payload type mappings
  205. and allocate ports or other resources that they could then
  206. advertise in Jingle sessions so that all media would traverse
  207. the bridge.
  208. </li>
  209. <li>Impose no COLIBRI specific requirements on non-focus
  210. participants so that any Jingle supporting client would be able
  211. to participate.
  212. </li>
  213. <li>[TODO] Anything else?</li>
  214. </ol>
  215. </section1>
  216. <section1 topic='How It Works' anchor='howitworks'>
  217. <p>
  218. This section provides a friendly introduction to COLIBRI.
  219. </p>
  220. <p>
  221. In essence, the goal of COLIBRI is to provide focus agents with a
  222. way of using remote mixers as if as they were available locally.
  223. The most important part of that is the possibility to allocate
  224. ports on the mixer interfaces and then use these ports when
  225. establishing Jingle sessions with the various participants.
  226. </p>
  227. <p>
  228. Every participant in the conference call is assigned one port for
  229. RTP data and one for RTCP. An RTP/RTCP port couple is called a
  230. channel. Each participant would use one channel per media type.
  231. That is, a client participating with audio only would get one
  232. channel, while another one that joins with both audio and video
  233. would get two: one for audio and one for video.
  234. </p>
  235. <p>
  236. Channels are used for streams from the bridge to participants and
  237. from participants to the bridge. Typically a channel would contain
  238. one stream from a participant to a bridge, for example their
  239. webcam or desktop, and one or more streams in the opposite
  240. direction (e.g. webcam or desktop streams from other participants
  241. to the one using this channel). This is not a requirement though
  242. and a channel can certainly be used for transportation of multiple
  243. streams in both directions in cases where one bridge is connected
  244. to another.
  245. </p>
  246. <p>
  247. Typically channels would be created by the entity controlling a
  248. conference call. This could either be a conferencing server or a
  249. smart client capable of handling conferences. We would refer to
  250. both of these as the "focus". In either case, the important part
  251. is that the focus terminates all signalling. It is a signalling
  252. endpoint and it is responsible for all aspects of call signalling
  253. including offer/answer.
  254. </p>
  255. <p>
  256. In other words, when setting up a conference, a focus would first
  257. allocate the necessary channels, then directly initiate sessions
  258. (invite) other participants into the call. Only, when sending the
  259. invitations to these participants, the focus would use the
  260. transport information (addresses and ports) that it would have
  261. received from the COLIBRI bridge, rather than its own.
  262. </p>
  263. <!--
  264. discovery
  265. creating a conference call
  266. modifying a conference call
  267. defining payload types
  268. supports transcoding
  269. get supported formats
  270. Mixing vs. RTP translation
  271. RTP/RTCP channels
  272. RAW UDP
  273. ICE UDP
  274. ZRTP
  275. composited / switched
  276. -->
  277. </section1>
  278. <section1 topic='Use cases' anchor='usecases'>
  279. <section2 topic='Creating a conference' anchor='usecases-create'>
  280. <p>
  281. The most important thing about setting up a conference is the
  282. creation of channels for every participant. Conference setup is
  283. not the only chance an organiser gets to declare all
  284. participants but typically when a conference call is setup it
  285. is because there are at least some number of known participants
  286. and there would be no point in delaying channel creation for
  287. them.
  288. </p>
  289. <p>
  290. The following example shows how Romeo creates an audio/video
  291. conference at a bridge, requesting that three participant
  292. channels be created.
  293. </p>
  294. <example caption='Creating a conference'><![CDATA[
  295. SEND: <iq from='romeo@montague.lit/orchard'
  296. id='zid615d9'
  297. to='garden.montague.lit'
  298. type='set'>
  299. <conference xmlns='http://jitsi.org/protocol/colibri'>
  300. <content name='audio'>
  301. <channel initiator='true'>
  302. [optional payload and transport description]
  303. </channel>
  304. <channel initiator='true'/>
  305. ...
  306. <channel initiator='true'/>
  307. </content>
  308. <content name='video'>
  309. <channel initiator='true'/>
  310. ...
  311. <channel initiator='true'/>
  312. </content>
  313. </conference>
  314. </iq>
  315. ]]></example>
  316. <p>
  317. Notice how the 'initiator' channel above is set to true. The
  318. setting determines ICE and DTLS/SRTP behaviour for the bridge.
  319. In this specific case, 'initiator' being set to 'true' Romeo is
  320. requesting that the bridge behave as the initiator of the
  321. session which means that it would try to be the controlling ICE
  322. agent and also assume the 'dtls-actpass' role for DTLS/SRTP
  323. negotiation. A value of 'false' would have meant that the bridge
  324. would behave as the controlled ICE agent and assume the
  325. 'dtls-active' role.
  326. </p>
  327. <p>
  328. When sending its result back, the bridge confirms creation of
  329. the requested channels and it also delivers transport
  330. information that would be necessary for participants to
  331. transport media to the bridge. These would most often include
  332. ICE candidates, ufrag and pwd parameters, and DTLS fingerprints.
  333. </p>
  334. <p>
  335. Note that ICE is not mandatory for use and COLIBRI bridges can
  336. just as well perform Hosted NAT Traversal using latching and a
  337. RAW-UDP transport.
  338. </p>
  339. <example caption='Result'><![CDATA[
  340. RECV: <iq type='result' to='romeo@montague.lit/orchard'
  341. from='garden.montague.lit'
  342. id='zid615d9'>
  343. <conference xmlns='http://jitsi.org/protocol/colibri'
  344. id='cafb6f2c8197818e'>
  345. <content name='audio'>
  346. <channel rtp-level-relay-type='mixer' direction='recvonly'
  347. initiator='true' id='c6a142b7cf728fd0' expire='60'>
  348. <source xmlns='urn:xmpp:jingle:apps:rtp:ssma:0' ssrc='3716204482'/>
  349. <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
  350. pwd='5d0mj' ufrag='amiq'>
  351. <fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-1'>
  352. 99:...:F6
  353. </fingerprint>
  354. <candidate type='host' protocol='udp' id='ca' ip='10.0.1.1'
  355. component='1' port='5144' foundation='3' generation='0'
  356. priority='2113932031' network='0'/>
  357. <candidate type='host' protocol='udp' id='ga' ip='10.0.1.1'
  358. component='2' port='5145' foundation='3' generation='0'
  359. priority='2113932030' network='0'/>
  360. </transport>
  361. </channel>
  362. ...
  363. </content>
  364. <content name='video'>
  365. <channel rtp-level-relay-type='mixer' direction='recvonly'
  366. initiator='true' id='c9726594ccb4ede7' expire='60'>
  367. ...
  368. </channel>
  369. ...
  370. </content>
  371. </conference>
  372. </iq>
  373. ]]></example>
  374. <p>
  375. The above "result" also contains the following elements of
  376. interest for every channel:
  377. </p>
  378. <p>
  379. - an ID that is necessary for any further modification from that
  380. the focus wants to set on a channel. [FIXME: clients should be
  381. able to specify these id-s so as not to rely on ordering to
  382. identify channels and get complexes thinking they are SDP
  383. parsers]
  384. </p>
  385. <p>
  386. - an rtp-level-relay-type attribute with possible values of
  387. 'mixer' and 'translator' indicating how the bridge is going to
  388. deliver data on a specific channel [FIXME: this would definitely
  389. need to be specifiable from the client].
  390. </p>
  391. <p>
  392. - mixer channels would also include ssrc-s for that channels in
  393. question. This is particularly necessary when SSRC-s need to be
  394. announced to participants (because people never learned how RTP
  395. works and are afraid from anything that wasn't explicitly
  396. announced with an Offer/Answer exchange). Generally such
  397. announcements would be possible by simply propagating SSRCs that
  398. other participants announce. In a mixed flow however the SSRC
  399. would belong to the mixer (or COLIBRI bridge) so it would need
  400. to be known in advance.
  401. attribute
  402. </p>
  403. <p>
  404. - the initiator value is echoed
  405. </p>
  406. <p>
  407. - expire describes how many seconds the bridge will keep the
  408. channel open without media activity
  409. </p>
  410. </section2>
  411. <section2 topic='Updating payload information for a channel' anchor='usecases-update-payload'>
  412. <p>
  413. Channel updates can happen for various reasons. The following
  414. examples illustrate two of them:
  415. </p>
  416. <p>
  417. - specifying payload types. While payload types in RTP are
  418. sometimes static (e.g. for older codecs such as G.711), this is
  419. not always the case for more recent types, which need to be
  420. assigned dynamically during session establishment. The tricky
  421. part here is that dynamic means dynamic so every participant in
  422. a conference call may end up expecting different payload types.
  423. As a result, a COLIBRI bridge SHOULD know about everyone's
  424. expectations, which is why channels are updated with payload
  425. types. Note that if a bridge does see unknown payload types it
  426. MUST still relay them to other participants as they might have
  427. used some other mechanism to make sure they know what they
  428. mean.
  429. </p>
  430. <p>
  431. - DTLS/SRTP fingerprints.
  432. </p>
  433. <example caption='Focus updates payload information for a channel'>
  434. <![CDATA[
  435. SEND: <iq to='garden.montague.lit' from='romeo@montague.lit/orchard'
  436. type='set' id='74s'>
  437. <conference xmlns='http://jitsi.org/protocol/colibri'
  438. id='cafb6f2c8197818e'>
  439. <content name='audio'>
  440. <channel id='c6a142b7cf728fd0' initiator='true'>
  441. <payload-type id='111' name='opus' clockrate='48000' channels='2'/>
  442. <payload-type id='0' name='PCMU' clockrate='8000' channels='1'/>
  443. <payload-type id='8' name='PCMA' clockrate='8000' channels='1'/>
  444. <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
  445. ufrag='WP+qAQZGnDhhM+87' pwd='0Uxdzy9gTryxAkmAx2LD1TYR'>
  446. <fingerprint hash='sha-256' xmlns='urn:xmpp:jingle:apps:dtls:0'
  447. setup='active'>
  448. 08:...:C7
  449. </fingerprint>
  450. </transport>
  451. </channel>
  452. </content>
  453. <content name='video'>
  454. <channel id='c9726594ccb4ede7' initiator='true'>
  455. <payload-type id='100' name='VP8' clockrate='90000' channels='1'/>
  456. <payload-type id='116' name='red' clockrate='90000' channels='1'/>
  457. <payload-type id='117' name='ulpfec' clockrate='90000' channels='1'/>
  458. <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
  459. ufrag='hpx55NAN46sNYwF+' pwd='hkg/YRpjXZx4qDG3KbzB3qr1'>
  460. <fingerprint hash='sha-256' xmlns='urn:xmpp:jingle:apps:dtls:0'
  461. setup='active'>
  462. 08:...:C7
  463. </fingerprint>
  464. </transport>
  465. </channel>
  466. </content>
  467. </conference>
  468. </iq>
  469. ]]></example>
  470. <p>
  471. Note that while the result in this case is essentially an
  472. acknowledgement, it still carries a full representation of the
  473. bridge.
  474. </p>
  475. <example caption='Result'><![CDATA[
  476. RECV: <iq to='romeo@montague.lit/orchard' from='garden.montague.lit'
  477. type='result' id='74s'>
  478. <conference xmlns='http://jitsi.org/protocol/colibri'
  479. id='cafb6f2c8197818e'>
  480. <content name='audio'>
  481. <channel rtp-level-relay-type='mixer' direction='recvonly'
  482. initiator='true' id='c6a142b7cf728fd0' expire='60'>
  483. <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
  484. pwd='5d0mj' ufrag='amiq'>
  485. <fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-1'>
  486. 99:...:F6
  487. </fingerprint>
  488. <candidate type='host' protocol='udp' id='ca' ip='10.0.1.1' component='1'
  489. port='5144' foundation='3' generation='0' priority='2113932031'
  490. network='0'/>
  491. <candidate type='host' protocol='udp' id='ga' ip='10.0.1.1' component='2'
  492. port='5145' foundation='3' generation='0' priority='2113932030'
  493. network='0'/>
  494. </transport>
  495. </channel>
  496. ...
  497. </content>
  498. <content name='video'>
  499. <channel rtp-level-relay-type='translator' initiator='true'
  500. id='c9726594ccb4ede7' expire='60'>
  501. ...
  502. </channel>
  503. ...
  504. </content>
  505. </conference>
  506. </iq>
  507. ]]></example>
  508. </section2>
  509. <section2 topic='Updating transport information for a channel' anchor='usecases-update-transport'>
  510. <example caption='Result'><![CDATA[
  511. SEND: <iq to='garden.montague.lit' from='romeo@montague.lit/orchard'
  512. type='set' id='1581'>
  513. <conference xmlns='http://jitsi.org/protocol/colibri' id='cafb6f2c8197818e'>
  514. <content name='audio'>
  515. <channel id='c6a142b7cf728fd0' initiator='true'>
  516. <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'>
  517. <candidate foundation='2241210590' component='1' protocol='udp'
  518. priority='2113937151' ip='192.168.2.101' port='61141' type='host'
  519. generation='0' network='1' id='1234'/>
  520. </transport>
  521. </channel>
  522. </content>
  523. </conference>
  524. </iq>
  525. ]]></example>
  526. <!--
  527. <p>FIXME: Describe trickle ice?</p>
  528. <p>FIXME: ufrag/pwd missing? required?</p>
  529. -->
  530. <example caption='Result'><![CDATA[
  531. RECV: <iq type='result' to='romeo@montague.lit/orchard' from='garden.montague.lit' id='1581'>
  532. <conference xmlns='http://jitsi.org/protocol/colibri' id='cafb6f2c8197818e'>
  533. <content name='audio'>
  534. <channel rtp-level-relay-type='translator' initiator='true'
  535. id='c6a142b7cf728fd0' expire='60'>
  536. <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
  537. pwd='5d0mja27fgl83r9tsl1b9gkk4f' ufrag='amiqp'>
  538. <fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-1'>
  539. 99:..:F6
  540. </fingerprint>
  541. <candidate type='host' protocol='udp' id='1' ip='10.0.1.1' component='1'
  542. port='5144' foundation='3' generation='0' priority='2113932031' network='0'/>
  543. <candidate type='host' protocol='udp' id='2' ip='10.0.1.1' component='2'
  544. port='5145' foundation='3' generation='0' priority='2113932030' network='0'/>
  545. </transport>
  546. </channel>
  547. </content>
  548. </conference>
  549. </iq>
  550. ]]></example>
  551. <p>Essentially that information is the transport description from
  552. the bridge. <!-- Do we need that? FIXME -->
  553. </p>
  554. </section2>
  555. <section2 topic='Adding a new channel' anchor='usecases-addchannel'>
  556. <p>
  557. ICE candidates are another reason why a focus might want to
  558. update a channel. Earlier examples indicated how conference
  559. setup could be completed without providing any transport
  560. information whatsoever. Whenever that is the case, such
  561. information would need to be provided through channel
  562. modification.
  563. </p>
  564. <example caption='Adding a new channel'><![CDATA[
  565. SEND: <iq to='garden.montague.lit' from='romeo@montague.lit/orchard' type='get' id='247'>
  566. <conference xmlns='http://jitsi.org/protocol/colibri' id='cafb6f2c8197818e'>
  567. <content creator='initiator' name='audio'>
  568. <channel initiator='true'/>
  569. </content>
  570. <content creator='initiator' name='video'>
  571. <channel initiator='true'/>
  572. </content>
  573. </conference>
  574. </iq>
  575. ]]></example>
  576. <example caption='Result'><![CDATA[
  577. RECV: <iq type='result' to='romeo@montague.lit/orchard' from='garden.montague.lit' id='247'>
  578. <conference xmlns='http://jitsi.org/protocol/colibri' id='49a91b4f6694bc6a'>
  579. <content name='audio'>
  580. <channel rtp-level-relay-type='mixer' direction='recvonly' initiator='true'
  581. id='e97d7f794fbed74b' expire='60'>
  582. <source xmlns='urn:xmpp:jingle:apps:rtp:ssma:0' ssrc='2579640556'/>
  583. <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
  584. pwd='75e88spurhqbih628ord5a3l9b' ufrag='6c7a6'>
  585. <fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-1'>
  586. A9:...:2F
  587. </fingerprint>
  588. <candidate type='host' protocol='udp' id='1' ip='10.0.1.1' component='1'
  589. port='5168' foundation='3' generation='0' priority='2113932031'
  590. network='0'/>
  591. <candidate type='host' protocol='udp' id='2' ip='10.0.1.1' component='2'
  592. port='5169' foundation='3' generation='0' priority='2113932030'
  593. network='0'/>
  594. </transport>
  595. </channel>
  596. </content>
  597. <content name='video'>
  598. <channel rtp-level-relay-type='translator' initiator='true'
  599. id='b4557f274216f99a' expire='60'>
  600. <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
  601. pwd='1oriuuhjfq6884ln9d3g1rjq13' ufrag='3gh3o'>
  602. <fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-1'>
  603. D7:...:C2
  604. </fingerprint>
  605. <candidate type='host' protocol='udp' id='1' ip='10.0.1.1' component='1'
  606. port='5170' foundation='3' generation='0' priority='2113932031'
  607. network='0'/>
  608. <candidate type='host' protocol='udp' id='2' ip='10.0.1.1' component='2'
  609. port='5171' foundation='3' generation='0' priority='2113932030'
  610. network='0'/>
  611. </transport>
  612. </channel>
  613. </content>
  614. </conference>
  615. </iq>
  616. ]]></example>
  617. </section2>
  618. </section1>
  619. <!--
  620. <section1 topic='Use with Jingle' anchor='use-with-jingle'>
  621. <p>TODO: a non-normative section showing the flow of jingle sessions and bridge interaction</p>
  622. </section1>
  623. -->
  624. <section1 topic='Determining Support' anchor='support'>
  625. <p>If an entity supports COLIBRI, it SHOULD advertise that fact by
  626. returning
  627. a feature of "http://jitsi.org/protocol/colibri" in response to
  628. a &xep0030;
  629. information request.
  630. </p>
  631. <example caption="Service Discovery Information Request"><![CDATA[
  632. <iq from='kingclaudius@shakespeare.lit/castle'
  633. id='ku6e51v3'
  634. to='belfry.shakespeare.lit'
  635. type='get'>
  636. <query xmlns='http://jabber.org/protocol/disco#info'/>
  637. </iq>
  638. ]]></example>
  639. <example caption="Service Discovery Information Response"><![CDATA[
  640. <iq from='belfry.shakespeare.lit'
  641. id='ku6e51v3'
  642. to='kingclaudius@shakespeare.lit/castle'
  643. type='result'>
  644. <query xmlns='http://jabber.org/protocol/disco#info'>
  645. <feature var='http://jitsi.org/protocol/colibri'/>
  646. </query>
  647. </iq>
  648. ]]></example>
  649. <p>In order for an application to determine whether an entity
  650. supports this
  651. protocol, where possible it SHOULD use the dynamic, presence-based
  652. profile
  653. of service discovery defined in &xep0115;. However, if an
  654. application has
  655. not received entity capabilities information from an entity, it
  656. SHOULD use
  657. explicit service discovery instead.
  658. </p>
  659. </section1>
  660. <section1 topic='Security Considerations' anchor='security'>
  661. <p>PENDING</p>
  662. </section1>
  663. <section1 topic='Open Issues' anchor='issues'>
  664. <p>PENDING</p>
  665. </section1>
  666. <section1 topic='XML Schemas' anchor='schema'>
  667. <p>PENDING</p>
  668. </section1>
  669. <section1 topic='Acknowledgements' anchor='acks'>
  670. <p>Jitsi's participation in this specification is funded by the
  671. NLnet
  672. Foundation.
  673. </p>
  674. </section1>
  675. </xep>