source: draft-ietf-stox-media.xml

Last change on this file was 79, checked in by stpeter@…, 9 years ago

04

  • Property svn:mime-type set to text/xml
File size: 60.1 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
3 <!ENTITY rfc768 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml">
4 <!ENTITY rfc793 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
5 <!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
6 <!ENTITY rfc2616 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
7 <!ENTITY rfc3261 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
8 <!ENTITY rfc3264 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
9 <!ENTITY rfc3550 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
10 <!ENTITY rfc3551 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
11 <!ENTITY rfc4855 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4855.xml">
12 <!ENTITY rfc3711 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
13 <!ENTITY rfc3959 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3959.xml">
14 <!ENTITY rfc3960 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3960.xml">
15 <!ENTITY rfc4566 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
16 <!ENTITY rfc4733 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4733.xml">
17 <!ENTITY rfc4585 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml">
18 <!ENTITY rfc5124 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5124.xml">
19 <!ENTITY rfc5245 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
20 <!ENTITY rfc5888 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5888.xml">
21 <!ENTITY rfc6120 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6120.xml">
22 <!ENTITY rfc7081 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7081.xml">
23]>
24
25<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
26
27<?rfc comments="yes" ?>
28<?rfc inline="yes" ?>
29<?rfc compact="yes" ?>
30<?rfc subcompact="no" ?>
31<?rfc iprnotified="no" ?>
32<?rfc sortrefs="yes"?>
33<?rfc strict="yes" ?>
34<?rfc symrefs="yes" ?>
35<?rfc toc="yes" ?>
36<?rfc tocdepth="1"?>
37
38<rfc category='std' docName='draft-ietf-stox-media-04' ipr='trust200902'>
39
40  <front>
41    <title abbrev="SIP-XMPP Interworking: Media Sessions">
42      Interworking between the Session Initiation Protocol (SIP) and the
43      Extensible Messaging and Presence Protocol (XMPP): Media Sessions
44    </title>
45    <author initials='P.' surname='Saint-Andre'
46            fullname='Peter Saint-Andre'>
47      <organization>&amp;yet</organization>
48      <address>
49        <postal>
50          <street>P.O. Box 787</street>
51          <city>Parker</city>
52          <region>CO</region>
53          <code>80134</code>
54          <country>USA</country>
55        </postal>
56        <email>ietf@stpeter.im</email>
57      </address>
58    </author>
59    <author initials="S." surname="Ibarra"
60            fullname="Saul Ibarra Corretge">
61      <organization>AG Projects</organization>
62      <address>
63        <postal>
64          <street>Dr. Leijdsstraat 92</street>
65          <code>2021RK</code>
66          <city>Haarlem</city>
67          <country>The Netherlands</country>
68        </postal>
69        <email>saul@ag-projects.com</email>
70      </address>
71    </author>
72    <author initials='E.' surname='Ivov' fullname='Emil Ivov'>
73      <organization abbrev='Jitsi'>Jitsi</organization>
74      <address>
75        <postal>
76          <street></street>
77          <city>Strasbourg</city>
78          <code>67000</code>
79          <country>France</country>
80        </postal>
81        <phone>+33-177-624-330</phone>
82        <email>emcho@jitsi.org</email>
83      </address>
84    </author>
85    <date/>
86    <area>Applications</area>
87    <keyword>SIP</keyword>
88    <keyword>XMPP</keyword>
89    <keyword>Jingle</keyword>
90    <abstract>
91      <t>
92        This document defines a bidirectional protocol mapping for use
93        by gateways that enable the exchange of media signalling
94        messages between systems that implement the Session Initiation
95        Protocol (SIP) and systems that implement the Jingle extensions to
96        the Extensible Messaging and Presence Protocol (XMPP).
97      </t>
98    </abstract>
99  </front>
100
101  <middle>
102
103    <section title="Introduction" anchor="intro">
104      <t>The Session Initiation Protocol <xref target="RFC3261"/> is a widely-deployed technology for the management of media sessions (such as voice and video calls) over the Internet. SIP itself provides a signalling channel via TCP <xref target='RFC0793'/> or UDP <xref target='RFC0768'/>, over which two or more parties can exchange messages for the purpose of negotiating a media session that uses a dedicated media channel such as the Real-time Transport Protocol (RTP) <xref target='RFC3550'/>.  The Extensible Messaging and Presence Protocol (XMPP) <xref target='RFC6120'/> also provides a signalling channel, typically via TCP (although HTTP and WebSocket bindings also exist).</t>
105      <t>Given the significant differences between XMPP and SIP, traditionally it was difficult to combine the two technologies in a single user agent (although nowadays such implementations are not uncommon, as described in <xref target='RFC7081'/>).  As a result, in 2005 some developers wishing to add media session capabilities to XMPP clients defined a set of XMPP-specific session negotiation protocol extensions called Jingle <xref target='XEP-0166'/>.</t>
106      <t>Thankfully, Jingle was designed to easily map to SIP for communication through gateways or other transformation mechanisms.  Nevertheless, given the significantly different technology assumptions underlying XMPP and SIP, Jingle is naturally different from SIP in several important respects:</t>
107      <t>
108        <list style='symbols'>
109          <t>Base SIP messages and headers use a plaintext format similar in some ways to the Hypertext Transport Protocol <xref target='RFC2616'/>, whereas Jingle messages are pure XML. Mappings between SIP headers and Jingle message syntax are provided below.</t>
110          <t>The SIP payloads defining session semantics use the Session Description Protocol <xref target='RFC4566'/>, whereas the equivalent Jingle payloads are defined as XML child elements of the Jingle &lt;content/&gt; element.  However, the Jingle specifications defining such child elements specify mappings to SDP for all Jingle syntax, making the mapping relatively straightforward.</t>
111          <t>The SIP signalling channel has historically often been transported over UDP, whereas the signalling channel for Jingle is XMPP over TCP. Mapping between the transport layers typically happens within a gateway using techniques below the application level, and therefore is not addressed in this specification.</t>
112        </list>
113      </t>
114      <t>Consistent with existing specifications for mapping between SIP and XMPP (see <xref target='I-D.ietf-stox-core'/> and other related specifications), this document describes a bidirectional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement SIP and systems that implement the XMPP Jingle extensions.</t>
115      <t>It is important to note that SIP and Jingle sessions can be gatewayed in a rather simple fashion if all media was always routed and potentially even transcoded through a gateway.  This specification defines a mapping that allows gateways to (wherever possible) only intervene at the signalling level, letting user agents exchange media in an end-to-end manner. Such gateways focus on handling handling RTP session establishment and control within the context of what users would perceive as "calls". This document is hence primarily dealing with calling scenarios as opposed to generic media sessions with SIP.</t>
116      <t>The discussion venue for this document is the mailing list of the STOX WG; visit https://www.ietf.org/mailman/listinfo/stox for subscription information and discussion archives.</t>
117    </section>
118
119    <section title="Intended Audience" anchor="audience">
120      <t>The documents in this series are intended for use by software developers who have an existing system based on one of these technologies (e.g., SIP), and would like to enable communication from that existing system to systems based on the other technology (e.g., XMPP).  We assume that readers are familiar with the core specifications for both SIP <xref target='RFC3261'/> and XMPP <xref target='RFC6120'/>, with the base document for this series <xref target='I-D.ietf-stox-core'/>, and with the following media-related specifications:</t>
121      <t>
122        <list style='symbols'>
123          <t>RTP Profile for Audio and Video Conferences with Minimal Control <xref target='RFC3551'/></t>
124          <t>The Secure Real-time Transport Protocol (SRTP) <xref target='RFC3711'/></t>
125          <t>SDP: Session Description Protocol <xref target='RFC4566'/></t>
126          <t>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols <xref target='RFC5245'/></t>
127          <t>Jingle <xref target='XEP-0166'/></t>
128          <t>Jingle RTP Sessions <xref target='XEP-0167'/></t>
129          <t>Jingle ICE-UDP Transport Method <xref target='XEP-0176'/></t>
130          <t>Jingle Raw UDP Transport Method <xref target='XEP-0177'/></t>
131        </list>
132      </t>
133    </section>
134
135    <section title="Terminology" anchor="terms">
136      <t>A number of technical terms used here are defined in <xref target="RFC3261"/>, <xref target="RFC6120"/>, <xref target='XEP-0166'/>, and <xref target='XEP-0167'/>.  The term "JID" is short for "Jabber Identifier".</t>
137      <t>In flow diagrams, SIP traffic is shown using arrows such as "***&gt;" whereas XMPP traffic is shown using arrows such as "...&gt;".</t>
138      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target='RFC2119'/>.</t>
139    </section>
140
141    <section title="Compatibility with Offer/Answer Model" anchor="jingle-oacompat">
142      <t>Even if Jingle semantics have many similarities with those used in SIP, there are some use cases that cannot be handled in exactly the same way due to the Offer/Answer model used in SIP in conjunction with SDP.</t>
143      <t>More specifically, mapping SIP and SDP Offer/Answer to XMPP is often complicated due to the difference in how each handles backward compatibility. Jingle, as most other XMPP extensions, relies heavily on the XMPP extension for service discovery <xref target='XEP-0030'/>. In other words, XMPP entities are able to verify the capabilities of their intended peer before actually attempting to establish a session with it.</t>
144      <t>SDP Offer/Answer on the other hand uses a least common denominator approach where every SDP offer has to be understandable by legacy endpoints. Newer, unsupported aspects in this offer can therefore only appear as optional, or their use needs to be limited to subsequent Offer/Answer exchanges once their support has been confirmed.</t>
145      <t>Use of "trickle ICE" (see <xref target='I-D.ietf-mmusic-trickle-ice'/> and <xref target='I-D.ivov-mmusic-trickle-ice-sip'/>) is one example where this issue occurs. SIP endpoints need to always behave like so-called "vanilla ICE" agents when sending their first offer and make sure they gather all candidates before sending a SIP INVITE. This is necessary because otherwise ICE agents with no support for trickle can prematurely declare failure. Jingle endpoints, on the other hand, can verify support for trickle ICE prior to engaging in a session and adapt their behavior accordingly.</t>
146      <t>In order to work around this disparity in relation to communication of transport candidates, <xref target='XEP-0176'/> defines an Offer/Answer support mode through the "urn:ietf:rfc:3264" feature tag. When an XMPP entity such as a client (or, significantly, a gateway to a SIP system) advertises support for this feature, the entity indicates that it needs to receive multiple transport candidates in the initial offer, instead of receiving them in a continuous trickle over time.  Although implementations conforming to this specification MUST support the Offer/Answer model with Jingle, such endpoints are not required to actually declare support for the "urn:ietf:rfc:3264" service discovery feature since this would mean that they too would be reachable only through Offer/Answer semantics not also through trickle-ICE semantics.)</t>
147    </section>
148
149    <section title="Syntax Mappings" anchor="jingle-syntax">
150      <section title="Generic Jingle Syntax" anchor="jingle-syntax-generic">
151        <t>Jingle is designed in a modular fashion, so that session description data is generally carried in a payload within the generic Jingle elements, i.e., the &lt;jingle/&gt; element and its &lt;content/&gt; child. The following example illustrates this structure, where the XMPP stanza is a request to initiate an audio session (via the &lt;content/&gt; and &lt;description/&gt; elements) using a transport of RTP over raw UDP (via the &lt;transport/&gt; element).</t>
152        <figure>
153          <preamble>Example 1: Structure of a Jingle session initiation request</preamble>
154          <artwork><![CDATA[
155| <iq from='romeo@example.net/v3rsch1kk3l1jk'
156|     id='ne91v36s'
157|     to='juliet@example.com/t3hr0zny'
158|     type='set'>
159|   <jingle xmlns='urn:xmpp:jingle:1'
160|           action='session-initiate'
161|           initiator='romeo@example.net/v3rsch1kk3l1jk'
162|           sid='a73sjjvkla37jfea'>
163|     <content creator='initiator'
164|              media='audio'
165|              name='this-is-the-audio-content'
166|              senders='both'>
167|       <description xmlns='urn:xmpp:jingle:app:rtp:1'>
168|         <payload-type id='96' name='speex' clockrate='16000'/>
169|         <payload-type id='97' name='speex' clockrate='8000'/>
170|         <payload-type id='18' name='G729'/>
171|         <payload-type channels='2'
172|                       clockrate='16000'
173|                       id='103'
174|                       name='L16'/>
175|         <payload-type id='98' name='x-ISAC' clockrate='8000'/>
176|       </description>
177|       <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
178|         <candidate id='v3c18fgg' ip='10.1.1.104'
179|                    port='13540' generation='0'/>
180|       </transport>
181|     </content>
182|   </jingle>
183| </iq>
184          ]]></artwork>
185        </figure>
186        <t>In the foregoing example, the syntax and semantics of the &lt;jingle/&gt; and &lt;content/&gt; elements are defined in the core Jingle specification <xref target='XEP-0166'/>, the syntax and semantics of the &lt;description/&gt; element qualified by the 'urn:xmpp:jingle:app:rtp:1' namespace are defined in the Jingle RTP specification <xref target='XEP-0167'/>, and the syntax and semantics of the &lt;transport/&gt; element qualified by the 'urn:xmpp:jingle:transport:raw-udp' namespace are defined in the Jingle Raw UDP specification <xref target='XEP-0177'/>. Other &lt;description/&gt; elements are defined in specifications for the appropriate application types (see for example <xref target='XEP-0234'/> for file transfer) and other &lt;transport/&gt; elements are defined in the specifications for appropriate transport methods (see for example <xref target='XEP-0176'/>, which defines an XMPP profile of ICE <xref target='RFC5245'/>).</t>
187        <t>At the core Jingle layer, the following mappings are defined.</t>
188        <figure>
189          <preamble>Table 1: High-Level Mapping from XMPP to SIP</preamble>
190          <artwork><![CDATA[
191+--------------------------------+--------------------------------+
192|           Jingle               |             SIP                |
193+--------------------------------+--------------------------------+
194| <jingle/> 'action'             | [ see next table ]             |
195+--------------------------------+--------------------------------+
196| <jingle/> 'initiator'          | [ no mapping ]                 |
197+--------------------------------+--------------------------------+
198| <jingle/> 'responder'          | [ no mapping ]                 |
199+--------------------------------+--------------------------------+
200| <jingle/> 'sid'                | local-part of Dialog ID        |
201+--------------------------------+--------------------------------+
202| local-part of 'initiator'      | <username> in SDP o= line      |
203+--------------------------------+--------------------------------+
204| <content/> 'creator'           | [ no mapping ]                 |
205+--------------------------------+--------------------------------+
206| <content/> 'name'              | no mandatory mapping *         |
207+--------------------------------+--------------------------------+
208| <content/> 'senders' value of  | a= line of sendrecv, recvonly, |
209| both, initiator, responder, or | sendonly, or inactive          |
210| none                           |                                |
211+--------------------------------+--------------------------------+
212          ]]></artwork>
213        </figure>
214        <t>* In can be appropriate to map to the a=mid value defined in <xref target='RFC5888'/>.</t>
215        <t>The 'senders' attribute is optional in Jingle, with a default value of "both"; thus in case the attribute is absent the SDP direction value MUST be considered as 'sendrecv'.</t>
216        <t>The 'action' attribute of the &lt;jingle/&gt; element has 15 allowable values. In general they should be mapped as shown in the following table, with some exceptions as described below.</t>
217        <figure>
218          <preamble>Table 2: Mapping of Jingle Actions to SIP Methods</preamble>
219          <artwork><![CDATA[
220+-------------------+------------------------------+
221| Jingle Action     | SIP Method                   |
222+-------------------+------------------------------+
223| content-accept    | INVITE response (1xx or 2xx) |
224+-------------------+------------------------------+
225| content-add       | INVITE request               |
226+-------------------+------------------------------+
227| content-modify    | INVITE request               |
228+-------------------+------------------------------+
229| content-reject    | unused in this mapping       |
230+-------------------+------------------------------+
231| content-remove    | INVITE request               |
232+-------------------+------------------------------+
233| description-info  | unused in this mapping       |
234+-------------------+------------------------------+
235| security-info     | unused in this mapping       |
236+-------------------+------------------------------+
237| session-accept    | INVITE response (1xx or 2xx) |
238+-------------------+------------------------------+
239| session-info      | [varies]                     |
240+-------------------+------------------------------+
241| session-initiate  | INVITE request               |
242+-------------------+------------------------------+
243| session-terminate | BYE                          |
244+-------------------+------------------------------+
245| transport-accept  | unused in this mapping       |
246+-------------------+------------------------------+
247| transport-info    | unused in this mapping       |
248+-------------------+------------------------------+
249| transport-reject  | unused in this mapping       |
250+-------------------+------------------------------+
251| transport-replace | unused in this mapping       |
252+-------------------+------------------------------+
253          ]]></artwork>
254        </figure>
255      </section>
256
257      <section title="Application Formats" anchor="jingle-syntax-application-formats">
258        <t>Jingle application formats for audio and video exchange via RTP are specified in <xref target='XEP-0167'/>. These application formats effectively map to the "RTP/AVP" profile specified in <xref target='RFC3551'/> and the "RTP/SAVP" profile specified in <xref target='RFC3711'/>, where the media types are "audio" and "video" and the specific mappings to SDP syntax are provided in <xref target='XEP-0167'/>.</t>
259        <t>(As stated in <xref target='XEP-0167'/>, future versions of that specification might define how to use other RTP profiles such as "RTP/AVPF" and "RTP/SAVPF" as defined in <xref target='RFC4585'/> and <xref target='RFC5124'/> respectively.)</t>
260      </section>
261
262      <section title="Raw UDP Transport Method" anchor="jingle-syntax-udp">
263        <t>A basic Jingle transport method for exchanging media over UDP is specified in <xref target='XEP-0177'/>. This transport method involves the negotiation of an IP address and port only. It does not provide NAT traversal, effectively leaving the task to intermediary entities. The Jingle 'ip' attribute maps to the connection-address parameter of the SDP c= line and the 'port' attribute maps to the port parameter of the SDP m= line. Use of SIP without ICE would generally map to use of Raw UDP on the XMPP side of a session.</t>
264      </section>
265
266      <section title="ICE-UDP Transport Method" anchor="jingle-syntax-ice">
267        <t>A more advanced Jingle transport method for exchanging media over UDP is specified in <xref target='XEP-0176'/>.  Under ideal conditions this transport method provides NAT traversal by following the Interactive Connectivity Exchange methodology specified in <xref target='RFC5245'/>.</t>
268        <t>The relevant SDP mappings are provided in <xref target='XEP-0176'/>, however there are a few syntax incompatibilities which need to be addressed by gateways conforming to this specification:</t>
269        <t>
270          <list style='symbols'>
271            <t>
272              The 'foundation' attribute is defined as a number in
273              Jingle (unsigned byte) whereas ICE
274              <xref target='RFC5245'/> defines it as a string, which
275              can contain letters, digits and the '+' and '/' symbols.
276              Gateway applications MUST therefore convert ICE
277              originating foundations into integer numbers and they
278              MUST guarantee that such a conversion preserves
279              foundation uniqueness. The exact mechanism for the
280              conversion is undefined.
281            </t>
282            <t>
283              Jingle defines a 'generation' attribute which is used
284              to determine if an ICE restart is required. This
285              attribute has no counterpart in SIP as ICE restarts are
286              initiated by detecting a change in the ICE ufrag and
287              password. Gateways MUST therefore increase the
288              generation number when they detect such changes.
289            </t>
290            <t>
291              The 'id' attribute defined by Jingle has no SIP
292              counterpart thus applications are free to choose means
293              to generate unique identifiers across the different
294              candidates of an ICE generation.
295            </t>
296            <t>The 'network' attribute defined by Jingle has no
297              counterpart in SIP and SHOULD be ignored.
298            </t>
299          </list>
300        </t>
301<t>[[OPEN ISSUE: describe handling of ICE restarts.]]</t>
302      </section>
303    </section>
304
305    <section title="Call Hold" anchor="call-hold">
306      <t><xref target="RFC3264"/> stipulates that streams are placed on hold by setting their direction to "sendonly". A session is placed on hold by doing this for all the streams it contains.  The same semantics are also supported by Jingle through the "senders" element and its "initiator" and "responder" values (XEP-0166 also defines a value of "none", which maps to an a= value of "inactive").</t>
307      <t>The following example shows how the responder would put the call on hold (i.e., temporarily stop listening to media sent by the initiator) using a Jingle content-modify action and a modified value for the 'senders' attribute (here "responder" to indicate that the responder might continue to send media, such as hold music).</t>
308        <figure>
309          <preamble>Example 2: Call hold via 'senders' attribute</preamble>
310          <artwork><![CDATA[
311| <iq from='juliet@capulet.lit/balcony'
312|     id='hz73n2l9'
313|     to='romeo@montague.lit/orchard'
314|     type='set'>
315|   <jingle xmlns='urn:xmpp:jingle:1'
316|           action='content-modify'
317|           initiator='romeo@montague.lit/orchard'
318|           sid='a73sjjvkla37jfea'>
319|     <content creator='initiator'
320|              media='audio'
321|              name='this-is-the-audio-content'
322|              senders='responder'/>
323|   </jingle>
324| </iq>
325          ]]></artwork>
326        </figure>
327      <t>In addition to these semantics, however, the Jingle RTP Sessions specification <xref target='XEP-0167'/> also defines a more concise way for achieving the same end, which consists in sending a "hold" command within a "session-info" action, as shown in the following example.</t>
328        <figure>
329          <preamble>Example 3: Call hold via session-info action</preamble>
330          <artwork><![CDATA[
331| <iq from='juliet@capulet.lit/balcony'
332|     id='xv39z423'
333|     to='romeo@montague.lit/orchard'
334|     type='set'>
335|   <jingle xmlns='urn:xmpp:jingle:1'
336|           action='session-info'
337|           initiator='romeo@montague.lit/orchard'
338|           sid='a73sjjvkla37jfea'>
339|     <hold xmlns='urn:xmpp:jingle:apps:rtp:info:1'/>
340|   </jingle>
341| </iq>
342          ]]></artwork>
343        </figure>
344      <t>Gateways that receive a "hold" command from their Jingle side MUST generate a new offer on their SIP side, placing all streams in a "sendonly" state.</t>
345      <t>When relaying offers from SIP to XMPP however, gateways are not required to translate "sendonly" attributes into a "hold" command as this would not always be possible (e.g. when not all streams have the same direction). Additionally such conversions might introduce complications in case further offers placing a session on hold also contain other session modifications.</t>
346      <t>It is possible that, after one entity has put the other on hold, the second entity might put the first entity on hold.  In this case, the effective direction would then be "inactive" in SDP and "none" in Jingle.</t>
347    </section>
348
349    <section title="Early Media" anchor="early-media">
350      <t><xref target="RFC3959"/> and <xref target="RFC3960"/> describe a number of scenarios relying on "early media". While similar attempts have also been made for XMPP, support for early media is not currently widely supported in Jingle implementations. Therefore, gateways SHOULD NOT forward SDP answers from SIP to Jingle until a final response has been received, except in cases where the gateway is in a position to confirm specific support for early media by the endpoint (one approach to such support can be found in <xref target="XEP-0269"/> but it has not yet been standardized).</t>
351      <t>Gateways MUST however store early media SDP answers when they are sent inside a reliable provisional response. In such cases, a subsequent final response can follow without an actual answer and the one from the provisional response will need to be forwarded to the Jingle endpoint.</t>
352    </section>
353   
354    <section title="Detecting Endless Loops" anchor="loops">
355      <t><xref target="RFC3261"/> defines a "Max-Forwards" header that allows intermediate entities such as SIP proxies to detect and prevent loops from occurring. The specifics of XMPP make such a prevention mechanism unnecessary for XMPP-only environments.  With the introduction of SIP-to-XMPP gatewaying, however, it would be possible for loops to occur where messages are being repeatedly forwarded from XMPP to SIP to XMPP to SIP, etc.</t>
356      <t>To compensate for the lack of a "Max-Forwards" header in SIP, gateways MUST therefore keep track of all SIP transactions and Jingle sessions that they are currently serving and they MUST block re-entrant messages.</t>
357
358<t>[[OPEN ISSUE: In order for this to work, we need a consistent way of translating dialog IDs into Jingle sessions, and vice versa, so that the following can be verified: jingleSessID == toJingleSessID(toSipCallID( jingleSessID )).  We need to mention mention spirals here as well. Alice could call Bob, but Bob forwards his call to Romeo. A spiral on the SIP side could end up becoming a loop if the gateway is in between.]]</t>
359
360    </section>
361
362    <section title="SDP Format-Specific Parameters" anchor="fmtp">
363      <t><xref target="RFC4566"/> defines "a=fmtp" attributes for the transmission of format specific parameters as a single transparent string. Such strings can be used to convey either a single value or a sequence of parameters, separated by semi-colons, commas or whatever delimiters are chosen by a particular payload type specification.</t>
364      <t><xref target="XEP-0167"/> on the other hand defines a &lt;parameter/&gt; element as follows:</t>
365        <figure>
366          <artwork><![CDATA[
367  <parameter name="paramName" value="paramValue"/>
368          ]]></artwork>
369        </figure>
370      <t>A sequence of parameters is thus transmitted as an array of distinct name/value couples, at least in the context of the Jingle RTP extension.</t>
371      <t>These differences make it impossible to devise a generic mechanism that accurately translates format parameters from Jingle RTP to SDP without the specifics of the payload being known to the gateway. In general this is not a major problem because many or most of the media type definitions supported in existing Jingle implementations follow the normal semicolon-separated parameter model. One likely exception is the RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals <xref target='RFC4733'/>.</t>
372      <t>For implementations that wish to provide a general-purpose translation method, this specification makes the following recommendations:</t>
373      <t>
374        <list style='numbers'>
375          <t>Gateways that are aware of the formats in use SHOULD parse all format parameters and generate &lt;parameter/&gt; arrays and "a=fmtp" values accordingly.</t>
376          <t>When translating Jingle RTP to SIP, gateways that have no explicit support for the formats that are being negotiated SHOULD convert the list of &lt;parameter/&gt; elements into a single string, containing a sequence of "name=value" pairs, separated by a semi-colon and a space (i.e. "; ").</t>
377          <t>When translating SIP to Jingle RTP, gateways that have no explicit support for the formats that are being negotiated SHOULD tokenize the "a=fmtp" format string using one delimiter from the following list: ";", "; ", ",", ", ". The resulting tokens SHOULD then be parsed as "name=value" pairs. If this process does actually yield any such pairs, they SHOULD be used for generating the respective &lt;parameter/&gt; elements. If some of the tokens cannot be parsed into a "name=value" pair because they do not conform to the convention suggested in <xref target='RFC4855'/>, or in case the format string couldn't be tokenized with the above delimiters, the remaining strings SHOULD be used as a value for the "value" attribute of the &lt;parameter/&gt; element and the corresponding "name" attribute SHOULD be left empty.</t>
378        </list>
379      </t>
380      <t>Here is an example of the foregoing transformations, using the aforementioned example of DTMF digits:</t>
381      <figure>
382        <preamble>SDP with format data</preamble>
383        <artwork><![CDATA[
384      a=rtpmap:100 telephone-event/8000
385      a=fmtp:100 0-15,66,70
386        ]]></artwork>
387      </figure>
388      <figure>
389        <preamble>Jingle transformation</preamble>
390        <artwork><![CDATA[
391  <parameter name="" value="0-15,66-70"/>
392        ]]></artwork>
393      </figure>
394    </section>
395
396    <section title="Dialog Forking" anchor="forking">
397      <t><xref target="RFC3261"/> defines semantics for dialog forking.  Such semantics have not been defined for Jingle and need to be hidden from XMPP endpoints.</t>
398      <t>To achieve this, a SIP-to-XMPP gateway MUST NOT forward more than one provisional response on the Jingle side. Typically they would do so only for the first provisional response they receive and ignore the rest. This provisional response SHOULD be forwarded as if it originated from a "user@host" address (i.e., a "bare JID") corresponding to the AOR URI found in the "From" header of the SIP provisional response. The gateway MUST NOT attempt to translate GRUUs into full JIDs because it cannot know at this stage which of the dialogs established by these provisional responses will be used for the actual session.</t>
399      <t>Likewise, a gateway conforming to this specification MUST NOT forward more than a single final response received through SIP to the Jingle side.  The gateway SHOULD terminate the SIP sessions whose received final response wasn't forwarded to the Jingle side.</t>
400    </section>
401
402    <section title="Sample Scenarios" anchor="jingle-scenarios">
403      <t>The following sections provide sample scenarios (or "call flows") that illustrate the principles of interworking from Jingle to SIP. These scenarios are not exhaustive.</t>
404
405      <section title="Basic Voice Chat" anchor="jingle-scenarios-basic">
406        <t>The protocol flow for a basic voice chat for which an XMPP user (juliet@example.com) is the initiator and a SIP user (romeo@example.net) is the responder. The voice chat is consummated through a gateway. To simplify the example, the Jingle transport method negotiated is "raw user datagram protocol" as specified in <xref target='XEP-0177'/>.</t>
407        <figure>
408          <artwork><![CDATA[
409XMPP       XMPP      XMPP-to-SIP    SIP-to-XMPP     SIP         SIP
410User      Server      Gateway        Gateway       Server       User
411 |           |            |              |            |          |
412 | (F1) XMPP |            |              |            |          |
413 | session-  |            |              |            |          |
414 | initiate  |            |              |            |          |
415 |..........>|            |              |            |          |
416 |           | (F2) XMPP  |              |            |          |
417 |           | session-   |              |            |          |
418 |           | initiate   |              |            |          |
419 |           |...........>|              |            |          |
420 |           | (F3) XMPP  |              |            |          |
421 |           | IQ-result  |              |            |          |
422 |           |<...........|              |            |          |
423 | (F4) XMPP |            |              |            |          |
424 | IQ-result |            |              |            |          |
425 |<..........|            |              |            |          |
426 |           |            | (F5) SIP INVITE           |          |
427 |           |            |**************************>|          |
428 |           |            |              |            | (F6) SIP |
429 |           |            |              |            | INVITE   |
430 |           |            |              |            |*********>|
431 |           |            |              |            | (F7) SIP |
432 |           |            |              |            | 180      |
433 |           |            |              |            | ringing  |
434 |           |            |              |            |<*********|
435 |           |            |              | (F8) SIP   |          |
436 |           |            |              | 180 ringing|          |
437 |           |            |              |<***********|          |
438 |           | (F9) XMPP session-info    |            |          |
439 |           | (ringing)                 |            |          |
440 |           |<..........................|            |          |
441 | (F10) XMPP|            |              |            |          |
442 | session-  |            |              |            |          |
443 | info      |            |              |            |          |
444 | (ringing) |            |              |            |          |
445 |<..........|            |              |            |          |
446 | (F11) XMPP|            |              |            |          |
447 | IQ-result |            |              |            |          |
448 |..........>|            |              |            |          |
449 |           | (F12) XMPP |              |            |          |
450 |           | IQ-result  |              |            |          |
451 |           |...........x|              |            |          |
452 |           |            |              |            | (F13) SIP|
453 |           |            |              |            | 200 OK   |
454 |           |            |              |            |<*********|
455 |           |            |              | (F14) SIP  |          |
456 |           |            |              | 200 OK     |          |
457 |           |            |              |<***********|          |
458 |           | (F15) XMPP session-accept |            |          |
459 |           |<..........................|            |          |
460 | (F16) XMPP|            |              |            |          |
461 | session-  |            |              |            |          |
462 | accept    |            |              |            |          |
463 |<..........|            |              |            |          |
464 | (F17) XMPP|            |              |            |          |
465 | IQ-result |            |              |            |          |
466 |..........>|            |              |            |          |
467 |           | (F18) XMPP |              |            |          |
468 |           | IQ-result  |              |            |          |
469 |           |...........>|              |            |          |
470 |           |            | (F19) SIP ACK             |          |
471 |           |            |**************************>|          |
472 |           |            |              |            | (F20) SIP|
473 |           |            |              |            | ACK      |
474 |           |            |              |            |*********>|
475 |           |            |              |            |          |
476 |<====================MEDIA SESSION OVER RTP===================>|
477 |           |            |              |            |          |
478 |           |            |              |            | (F21) SIP|
479 |           |            |              |            | BYE      |
480 |           |            |              |            |<*********|
481 |           |            |              | (F22) SIP  |          |
482 |           |            |              | BYE        |          |
483 |           |            |              |<***********|          |
484 |           | (F23) XMPP session-       |            |          |
485 |           | terminate                 |            |          |
486 |           |<..........................|            |          |
487 | (F24) XMPP|            |              |            |          |
488 | session-  |            |              |            |          |
489 | terminate |            |              |            |          |
490 |<..........|            |              |            |          |
491 | (F25) XMPP|            |              |            |          |
492 | IQ-result |            |              |            |          |
493 |..........>|            |              |            |          |
494 |           | (F26) XMPP |              |            |          |
495 |           | IQ-result  |              |            |          |
496 |           |...........x|              |            |          |
497          ]]></artwork>
498        </figure>
499        <t>The packet flow is as follows.</t>
500        <t>First the XMPP user sends a Jingle session-initiation request to the SIP user.</t>
501        <figure>
502          <preamble>Example 4: Jingle session-initiate (F1)</preamble>
503          <artwork><![CDATA[
504|   <iq from='juliet@example.com/t3hr0zny'
505|       id='hu2s61f4'
506|       from='romeo@example.net/v3rsch1kk3l1jk'
507|       type='set'>
508|     <jingle xmlns='urn:xmpp:jingle:1'
509|             action='session-initiate'
510|             initiator='juliet@example.com/t3hr0zny'
511|             sid='a73sjjvkla37jfea'>
512|       <content creator='initiator'
513|                media='audio'
514|                name='this-is-the-audio-content'>
515|         <description xmlns='urn:xmpp:jingle:app:rtp:1'>
516|           <payload-type id='96' name='speex' clockrate='16000'/>
517|           <payload-type id='97' name='speex' clockrate='8000'/>
518|           <payload-type id='18' name='G729'/>
519|         </description>
520|         <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
521|           <candidate component='1' generation='0' id='u3gscv289p'
522|                      ip='192.0.2.101' port='49172'/>
523|         </transport>
524|       </content>
525|     </jingle>
526|   </iq>
527        ]]></artwork>
528        </figure>
529        <t>The gateway returns an XMPP IQ-result to the initiator on behalf of the responder.</t>
530        <figure>
531          <preamble>Example 5: XMPP IQ-result from gateway (F3)</preamble>
532          <artwork><![CDATA[
533|   <iq from='juliet@example.com/t3hr0zny'
534|       id='hu2s61f4'
535|       to='romeo@example.net/v3rsch1kk3l1jk'
536|       type='result'/>
537        ]]></artwork>
538        </figure>
539        <t>The gateway transforms the Jingle session-initiate action into a SIP INVITE.</t>
540        <figure>
541          <preamble>Example 6: SIP transformation of Jingle session-initiate (F5)</preamble>
542          <artwork><![CDATA[
543|   INVITE sip:romeo@example.net SIP/2.0
544|   Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9
545|   Max-Forwards: 70
546|   From: Juliet Capulet <sip:juliet@example.com>;tag=t3hr0zny
547|   To: Romeo Montague <sip:romeo@example.net>
548|   Call-ID: 3848276298220188511@example.com
549|   CSeq: 1 INVITE
550|   Contact: <sip:juliet@client.example.com;transport=tcp>
551|   Content-Type: application/sdp
552|   Content-Length: 184
553
554|   v=0
555|   o=alice 2890844526 2890844526 IN IP4 client.example.com
556|   s=-
557|   c=IN IP4 192.0.2.101
558|   t=0 0
559|   m=audio 49172 RTP/AVP 18 96 97
560|   a=rtpmap:96 sppex/16000
561|   a=rtpmap:97 speex/8000
562|   a=rtpmap:18 G729
563        ]]></artwork>
564        </figure>
565        <t>The responder returns a SIP 180 Ringing message.</t>
566        <figure>
567          <preamble>Example 7: SIP 180 Ringing message (F7)</preamble>
568          <artwork><![CDATA[
569|   SIP/2.0 180 Ringing
570|   Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9;\
571|        received=192.0.2.101
572|   From: Juliet Capulet <sip:juliet@example.com>;tag=t3hr0zny
573|   To: Romeo Montague <sip:romeo@example.net>;tag=v3rsch1kk3l1jk
574|   Call-ID: 3848276298220188511@example.com
575|   CSeq: 1 INVITE
576|   Contact: <sip:romeo@client.example.net;transport=tcp>
577|   Content-Length: 0
578        ]]></artwork>
579        </figure>
580        <t>The gateway transforms the ringing message into XMPP syntax.</t>
581        <figure>
582          <preamble>Example 8: XMPP transformation of SIP 180 Ringing message (F7)</preamble>
583          <artwork><![CDATA[
584|   <iq from='romeo@montague.net/v3rsch1kk3l1jk'
585|       id='ol3ba71g'
586|       to='juliet@example.com/t3hr0zny'
587|       type='set'>
588|     <jingle xmlns='urn:xmpp:jingle:1'
589|             action='session-info'
590|             initiator='juliet@example.com/t3hr0zny'
591|             sid='a73sjjvkla37jfea'>
592|       <ringing xmlns='urn:xmpp:jingle:apps:rtp:info:1'/>
593|     </jingle>
594|   </iq>
595        ]]></artwork>
596        </figure>
597        <t>The initiator returns an IQ-result acknowledging receipt of the ringing message, which is used only by the gateway and not transformed into SIP syntax.</t>
598        <figure>
599          <preamble>Example 9: XMPP entity acknowledges ringing message (F11)</preamble>
600          <artwork><![CDATA[
601|  <iq from='juliet@example.com/t3hr0zny'
602|      id='ol3ba71g'
603|      to='romeo@example.net/v3rsch1kk3l1jk'
604|      type='result'/>
605        ]]></artwork>
606        </figure>
607        <t>The responder sends a SIP 200 OK to the initiator in order to accept the session initiation request.</t>
608        <figure>
609          <preamble>Example 10: SIP user accepts session request (F13)</preamble>
610          <artwork><![CDATA[
611|   SIP/2.0 200 OK
612|   Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9;\
613|        received=192.0.2.101
614|   From: Juliet Capulet <sip:juliet@example.com>;tag=t3hr0zny
615|   To: Romeo Montague <sip:romeo@example.net>;tag=v3rsch1kk3l1jk
616|   Call-ID: 3848276298220188511@example.com
617|   CSeq: 1 INVITE
618|   Contact: <sip:romeo@client.example.net;transport=tcp>
619|   Content-Type: application/sdp
620|   Content-Length: 147
621|
622|   v=0
623|   o=romeo 2890844527 2890844527 IN IP4 client.example.net
624|   s=-
625|   c=IN IP4 192.0.2.201
626|   t=0 0
627|   m=audio 3456 RTP/AVP 97
628|   a=rtpmap:97 speex/8000
629        ]]></artwork>
630        </figure>
631        <t>The gateway transforms the 200 OK into a Jingle session-accept action.</t>
632        <figure>
633          <preamble>Example 11: XMPP transformation of SIP 200 OK (F15)</preamble>
634          <artwork><![CDATA[
635|   <iq from='romeo@example.net/v3rsch1kk3l1jk'
636|       id='pd1bf839'
637|       to='juliet@example.com/t3hr0zny'
638|       type='set'>
639|     <jingle xmlns='urn:xmpp:jingle:1'
640|             action='session-accept'
641|             initiator='juliet@example.com/t3hr0zny'
642|             responder='romeo@example.net/v3rsch1kk3l1jk'
643|             sid='a73sjjvkla37jfea'>
644|       <content creator='initiator'
645|                media='audio'
646|                name='this-is-the-audio-content'>
647|         <description xmlns='urn:xmpp:jingle:app:rtp:1'>
648|           <payload-type id='97' name='speex' clockrate='8000'/>
649|         </description>
650|         <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
651|           <candidate id='9eg13am7' ip='192.0.2.101'
652|                      port='49172' generation='0'/>
653|         </transport>
654|       </content>
655|     </jingle>
656|   </iq>
657        ]]></artwork>
658        </figure>
659        <t>If the payload types and transport candidate can be successfully used by both parties, then the initiator acknowledges the session-accept action.</t>
660        <figure>
661          <preamble>Example 12: XMPP user acknowledges session-accept (F17)</preamble>
662          <artwork><![CDATA[
663|   <iq from='romeo@example.net/v3rsch1kk3l1jk'
664|       id='pd1bf839'
665|       to='juliet@example.com/t3hr0zny'
666|       type='result'/>
667        ]]></artwork>
668        </figure>
669        <t>The parties now begin to exchange media. In this case they would exchange audio using the Speex codec at a clockrate of 8000 since that is the highest-priority codec for the responder (as determined by the XML order of the &lt;payloadtype/&gt; children).</t>
670        <t>The parties can continue the session as long as desired.</t>
671        <t>Eventually, one of the parties (in this case the responder) terminates the session.</t>
672        <figure>
673          <preamble>Example 13: SIP user ends session (F21)</preamble>
674          <artwork><![CDATA[
675|   BYE sip:juliet@client.example.com SIP/2.0
676|   Via: SIP/2.0/TCP client.example.net:5060;branch=z9hG4bKnashds7
677|   Max-Forwards: 70
678|   From: Romeo Montague <sip:romeo@example.net>;tag=8321234356
679|   To: Juliet Capulet <sip:juliet@example.com>;tag=9fxced76sl
680|   Call-ID: 3848276298220188511@example.com
681|   CSeq: 1 BYE
682|   Content-Length: 0
683        ]]></artwork>
684        </figure>
685        <t>The gateway transforms the SIP BYE into XMPP syntax.</t>
686        <figure>
687          <preamble>Example 14: XMPP transformation of SIP BYE (F23)</preamble>
688          <artwork><![CDATA[
689| <iq from='romeo@example.net/v3rsch1kk3l1jk'
690|     id='rv301b47'
691|     to='juliet@example.com/t3hr0zny'
692|     type='set'>
693|   <jingle xmlns='urn:xmpp:jingle:1'
694|           action='session-terminate'
695|           initiator='juliet@example.com/t3hr0zny'
696|           sid='a73sjjvkla37jfea'/>
697|     <reason>
698|       <success/>
699|     </reason>
700|   </jingle>
701| </iq>
702        ]]></artwork>
703        </figure>
704        <t>The initiator returns an IQ-result acknowledging receipt of the session termination, which is used only by the gateway and not transformed into SIP syntax.</t>
705        <figure>
706          <preamble>Example 15: XMPP user acknowledges end of session (F25)</preamble>
707          <artwork><![CDATA[
708  <iq from='romeo@example.net/v3rsch1kk3l1jk'
709    id='rv301b47'
710    to='juliet@example.com/t3hr0zny'
711    type='result'/>
712        ]]></artwork>
713        </figure>
714      </section>
715    </section>
716
717    <section title='IANA Considerations' anchor="iana">
718      <t>This document has no actions for the IANA.</t>
719    </section>
720
721    <section title='Security Considerations' anchor="sec">
722      <t>Detailed security considerations for session management are given for SIP in <xref target='RFC3261'/> and for XMPP in <xref target='XEP-0166'/> (see also <xref target='RFC6120'/>).  The security considerations provided in <xref target='I-D.ietf-stox-core'/> also apply.</t>
723    </section>
724
725  </middle>
726
727  <back>
728
729    <references title="Normative References">
730
731      <reference anchor='I-D.ietf-stox-core'>
732        <front>
733          <title>Interworking between the Session Initiation Protocol
734            (SIP) and the Extensible Messaging and Presence Protocol
735            (XMPP): Core
736          </title>
737          <author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
738            <organization/>
739          </author>
740          <author initials='A' surname='Houri' fullname='Avshalom Houri'>
741            <organization/>
742          </author>
743          <author initials='J' surname='Hildebrand' fullname='Joe Hildebrand'>
744            <organization/>
745          </author>
746          <date month='February' day='11' year='2014'/>
747          <abstract>
748            <t>As a foundation for the definition of
749              application-specific, bidirectional protocol mappings
750              between the Session Initiation Protocol (SIP) and the
751              Extensible Messaging and Presence Protocol (XMPP), this
752              document specifies the architectural assumptions
753              underlying such mappings as well as the mapping of
754              addresses and error conditions.
755            </t>
756          </abstract>
757        </front>
758        <seriesInfo name='Internet-Draft' value='draft-ietf-stox-core-11'/>
759        <format type='TXT'
760                target='http://www.ietf.org/internet-drafts/draft-ietf-stox-core-11.txt'/>
761      </reference>
762
763      &rfc2119;
764      &rfc3261;
765      &rfc3551;
766      &rfc4855;
767      &rfc3711;
768      &rfc4566;
769      &rfc4733;
770      &rfc5245;
771      &rfc6120;
772
773      <reference anchor="XEP-0030">
774        <front>
775          <title>Service Discovery</title>
776          <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
777            <organization/>
778            <address>
779              <email>jhildebr@cisco.com</email>
780            </address>
781          </author>
782          <author initials="R." surname="Eatmon" fullname="Ryan Eatmon">
783            <organization/>
784            <address>
785              <email>reatmon@jabber.org</email>
786            </address>
787          </author>
788          <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
789            <organization/>
790            <address>
791              <email>stpeter@jabber.org</email>
792            </address>
793          </author>
794          <date day="6" month="June" year="2008"/>
795        </front>
796        <seriesInfo name="XSF XEP" value="0030"/>
797        <format type="HTML" target="http://xmpp.org/extensions/xep-0030.html"/>
798      </reference>
799
800      <reference anchor="XEP-0166">
801        <front>
802          <title>Jingle</title>
803          <author initials="S." surname="Ludwig" fullname="Scott Ludwig">
804            <organization/>
805            <address>
806              <email>scottlu@google.com</email>
807            </address>
808          </author>
809          <author initials="J." surname="Beda" fullname="Joe Beda">
810            <organization/>
811            <address>
812              <email>jbeda@google.com</email>
813            </address>
814          </author>
815          <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
816            <organization/>
817            <address>
818              <email>stpeter@jabber.org</email>
819            </address>
820          </author>
821          <author initials="R." surname="McQueen" fullname="Robert McQueen">
822            <organization/>
823            <address>
824              <email>robert.mcqueen@collabora.co.uk</email>
825            </address>
826          </author>
827          <author initials="S." surname="Egan" fullname="Sean Egan">
828            <organization/>
829            <address>
830              <email>seanegan@google.com</email>
831            </address>
832          </author>
833          <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
834            <organization/>
835            <address>
836              <email>jhildebr@cisco.com</email>
837            </address>
838          </author>
839          <date day="20" month="June" year="2007"/>
840        </front>
841        <seriesInfo name="XSF XEP" value="0166"/>
842        <format type="HTML" target="http://xmpp.org/extensions/xep-0166.html"/>
843      </reference>
844
845      <reference anchor="XEP-0167">
846        <front>
847          <title>Jingle RTP Sessions</title>
848          <author initials="S." surname="Ludwig" fullname="Scott Ludwig">
849            <organization/>
850            <address>
851              <email>scottlu@google.com</email>
852            </address>
853          </author>
854          <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
855            <organization/>
856            <address>
857              <email/>
858            </address>
859          </author>
860          <author initials="S." surname="Egan" fullname="Sean Egan">
861            <organization/>
862            <address>
863              <email>seanegan@google.com</email>
864            </address>
865          </author>
866          <author initials="R." surname="McQueen" fullname="Robert McQueen">
867            <organization/>
868            <address>
869              <email>robert.mcqueen@collabora.co.uk</email>
870            </address>
871          </author>
872          <date day="17" month="February" year="2009"/>
873        </front>
874        <seriesInfo name="XSF XEP" value="0167"/>
875        <format type="HTML" target="http://xmpp.org/extensions/xep-0167.html"/>
876      </reference>
877
878      <reference anchor="XEP-0176">
879        <front>
880          <title>Jingle ICE-UDP Transport Method</title>
881          <author initials="J." surname="Beda" fullname="Joe Beda">
882            <organization/>
883            <address>
884              <email>jbeda@google.com</email>
885            </address>
886          </author>
887          <author initials="S." surname="Ludwig" fullname="Scott Ludwig">
888            <organization/>
889            <address>
890              <email>scottlu@google.com</email>
891            </address>
892          </author>
893          <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
894            <organization/>
895            <address>
896              <email/>
897            </address>
898          </author>
899          <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
900            <organization/>
901            <address>
902              <email>jhildebrand@jabber.com</email>
903            </address>
904          </author>
905          <author initials="S." surname="Egan" fullname="Sean Egan">
906            <organization/>
907            <address>
908              <email>seanegan@google.com</email>
909            </address>
910          </author>
911          <date day="26" month="February" year="2009"/>
912        </front>
913        <seriesInfo name="XSF XEP" value="0176"/>
914        <format type="HTML" target="http://xmpp.org/extensions/xep-0176.html"/>
915      </reference>
916
917      <reference anchor="XEP-0177">
918        <front>
919          <title>Jingle Raw UDP Transport</title>
920          <author initials="J." surname="Beda" fullname="Joe Beda">
921            <organization/>
922            <address>
923              <email>jbeda@google.com</email>
924            </address>
925          </author>
926          <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
927            <organization/>
928            <address>
929              <email/>
930            </address>
931          </author>
932          <author initials="S." surname="Ludwig" fullname="Scott Ludwig">
933            <organization/>
934            <address>
935              <email>scottlu@google.com</email>
936            </address>
937          </author>
938          <author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
939            <organization/>
940            <address>
941              <email>jhildebrand@jabber.com</email>
942            </address>
943          </author>
944          <author initials="S." surname="Egan" fullname="Sean Egan">
945            <organization/>
946            <address>
947              <email>seanegan@google.com</email>
948            </address>
949          </author>
950          <date day="11" month="February" year="2009"/>
951        </front>
952        <seriesInfo name="XSF XEP" value="0177"/>
953        <format type="HTML" target="http://xmpp.org/extensions/xep-0177.html"/>
954      </reference>
955
956    </references>
957
958    <references title="Informative References">
959
960<reference anchor='I-D.ietf-mmusic-trickle-ice'>
961<front>
962<title>Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol</title>
963<author initials='E' surname='Ivov' fullname='Emil Ivov'>
964    <organization />
965</author>
966<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
967    <organization />
968</author>
969<author initials='J' surname='Uberti' fullname='Justin Uberti'>
970    <organization />
971</author>
972<date month='February' day='7' year='2014' />
973<abstract><t>This document describes an extension to the Interactive Connectivity Establishment (ICE) protocol that allows ICE agents to send and receive candidates incrementally rather than exchanging complete lists.  With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete.  The above mechanism is also referred to as "trickle ICE".</t></abstract>
974</front>
975<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-trickle-ice-01' />
976<format type='TXT'
977        target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-01.txt' />
978</reference>
979
980<reference anchor='I-D.ivov-mmusic-trickle-ice-sip'>
981<front>
982<title>A Session Initiation Protocol (SIP) usage for Trickle ICE</title>
983<author initials='E' surname='Ivov' fullname='Emil Ivov'>
984    <organization />
985</author>
986<author initials='E' surname='Marocco' fullname='Enrico Marocco'>
987    <organization />
988</author>
989<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
990    <organization />
991</author>
992<date month='October' day='13' year='2013' />
993<abstract><t>The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model.  The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking.  This document defines usage semantics for Trickle ICE with SIP.</t></abstract>
994</front>
995<seriesInfo name='Internet-Draft' value='draft-ivov-mmusic-trickle-ice-sip-01' />
996<format type='TXT'
997        target='http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-sip-01.txt' />
998</reference>
999
1000      &rfc768;
1001      &rfc793;
1002      &rfc2616;
1003      &rfc3264;
1004      &rfc3550;
1005      &rfc3959;
1006      &rfc3960;
1007      &rfc4585;
1008      &rfc5124;
1009      &rfc5888;
1010      &rfc7081;
1011
1012<reference anchor="XEP-0234">
1013  <front>
1014    <title>Jingle File Transfer</title>
1015    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
1016      <organization/>
1017      <address>
1018        <email>stpeter@jabber.org</email>
1019      </address>
1020    </author>
1021    <date day="08" month="February" year="2012"/>
1022  </front>
1023  <seriesInfo name="XSF XEP" value="0234"/>
1024  <format type="HTML" target="http://xmpp.org/extensions/xep-0234.html"/>
1025</reference>
1026
1027      <reference anchor="XEP-0269">
1028        <front>
1029          <title>Jingle Early Media</title>
1030          <author initials="D." surname="Cionoiu"
1031                  fullname="Diana Cionoiu">
1032            <organization/>
1033            <address>
1034              <email>diana@null.ro</email>
1035            </address>
1036          </author>
1037          <author initials="P." surname="Saint-Andre"
1038                  fullname="Peter Saint-Andre">
1039            <organization/>
1040            <address>
1041              <email>stpeter@jabber.org</email>
1042            </address>
1043          </author>
1044          <date day="19" month="May" year="2009"/>
1045        </front>
1046        <seriesInfo name="XSF XEP" value="0269"/>
1047        <format type="HTML" target="http://xmpp.org/extensions/xep-0269.html"/>
1048      </reference>
1049
1050    </references>
1051
1052    <section title="Acknowledgements" anchor="acks">
1053      <t>Thanks to Dave Crocker, Philipp Hancke, Paul Kyzivat, and Jonathan Lennox for their feedback.</t>
1054      <t>The authors gratefully acknowledge the assistance of Markus Isomaki and Yana Stamcheva as the working group chairs and Gonzalo Camarillo and Alissa Cooper as the sponsoring Area Directors.</t>
1055      <t>Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier versions of this document.</t>
1056    </section>
1057
1058  </back>
1059
1060</rfc>
Note: See TracBrowser for help on using the repository browser.