Changeset 79


Ignore:
Timestamp:
21/03/14 02:55:07 (9 years ago)
Author:
stpeter@…
Message:

04

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-stox-media.xml

    r78 r79  
    1515 <!ENTITY rfc4566 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
    1616 <!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">
    1719 <!ENTITY rfc5245 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
    1820 <!ENTITY rfc5888 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5888.xml">
    1921 <!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">
    2023]>
    2124
     
    8790    <abstract>
    8891      <t>
    89         This document defines a bi-directional protocol mapping for use
     92        This document defines a bidirectional protocol mapping for use
    9093        by gateways that enable the exchange of media signalling
    91         messages between systems that implement the Jingle extensions to
    92         the Extensible Messaging and Presence Protocol (XMPP) and those
    93         that implement the Session Initiation Protocol (SIP).
     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).
    9497      </t>
    9598    </abstract>
     
    99102
    100103    <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>
    101107      <t>
    102         The Session Initiation Protocol <xref target="RFC3261"/>
    103         is a widely-deployed technology for the management of media
    104         sessions (such as voice and video calls) over the Internet. SIP
    105         itself provides a signalling channel (sometimes via the User
    106         Datagram Protocol <xref target='RFC0768'/>), over which two or
    107         more parties can exchange messages for the purpose of
    108         negotiating a media session that uses a dedicated media channel
    109         such as the Real-time Transport Protocol
    110         <xref target='RFC3550'/>.
     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>
    111113      </t>
    112       <t>
    113         The Extensible Messaging and Presence Protocol (XMPP)
    114         <xref target='RFC6120'/>
    115         also provides a signalling channel, typically via the
    116         Transmission Control Protocol <xref target='RFC0793'/>. Given the
    117         significant differences between XMPP and SIP, it is difficult to
    118         combine the two technologies in a single user agent. Therefore,
    119         developers wishing to add media session capabilities to XMPP
    120         clients have defined an XMPP-specific negotiation protocol
    121         called Jingle <xref target='XEP-0166'/>.
    122       </t>
    123       <t>
    124         However, Jingle was designed to easily map to SIP for
    125         communication through gateways or other transformation
    126         mechanisms. Therefore, consistent with existing specifications
    127         for mapping between SIP and XMPP (see
    128         <xref target='I-D.ietf-stox-core'/>
    129         and other related specifications), this document describes a
    130         bidirectional protocol mapping for use by gateways that enable
    131         the exchange of media signalling messages between systems that
    132         implement SIP and those that implement the XMPP Jingle
    133         extensions.
    134       </t>
    135       <t>
    136         It is important to note that SIP and Jingle sessions can be
    137         gateway-ed in a rather simple fashion if all media was always
    138         routed and potentially even transcoded in through a gateway.
    139         This specification aims to define a mapping that goes beyond the
    140         above and allows gateways to (wherever possible) only intervene
    141         at the signalling level, letting user agents exchange media in
    142         an end-to-end manner. Such gateways would likely focus on
    143         handling handling RTP session establishment and control within
    144         the context of what users would perceive as "calls". This
    145         document is hence primarily dealing with calling scenarios as
    146         opposed to generic media sessions with SIP.
    147       </t>
    148       <t>
    149         The discussion venue for this document is the mailing list of
    150         the STOX WG; visit https://www.ietf.org/mailman/listinfo/stox
    151         for subscription information and discussion archives.
    152       </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>
    153117    </section>
    154118
     
    162126          <t>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols <xref target='RFC5245'/></t>
    163127          <t>Jingle <xref target='XEP-0166'/></t>
    164           <t>Jingle RTP Sessions <xref target='XEP-0166'/></t>
     128          <t>Jingle RTP Sessions <xref target='XEP-0167'/></t>
    165129          <t>Jingle ICE-UDP Transport Method <xref target='XEP-0176'/></t>
    166130          <t>Jingle Raw UDP Transport Method <xref target='XEP-0177'/></t>
     
    171135    <section title="Terminology" anchor="terms">
    172136      <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>
    173       <t>In flow diagrams, SIP/MSRP traffic is shown using arrows such as "***&gt;" whereas XMPP traffic is shown using arrows such as "...&gt;".</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>
    174138      <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>
    175139    </section>
    176140
    177     <section title="Compatibility with Offer/Answer model"
    178              anchor="jingle-oacompat">
    179       <t>
    180         Even if Jingle semantics have many similarities with those used
    181         in SIP, there are some use cases that cannot be handled in
    182         exactly the same way due to the Offer/Answer model used in SIP
    183         in conjunction with SDP.
    184       </t>
    185       <t>
    186         More specifically, mapping SIP and SDP Offer/Answer to XMPP is
    187         often complicated due to the difference in how each handles
    188         backward compatibility. Jingle, as most other XMPP extensions,
    189         relies heavily on the protocol's advanced service discovery
    190         <xref target='XEP-0030'/> mechanisms. In other words, XMPP entities are
    191         able to verify the capabilities of their intended peer before
    192         actually attempting to establish a session with it.
    193       </t>
    194       <t>
    195         SDP Offer/Answer on the other hand uses a least common
    196         denominator approach where every SDP offer has to be
    197         understandable by legacy endpoints. Newer, unsupported aspects
    198         in this offer can therefore only appear as optional or their use
    199         be limited to subsequent Offer/Answer exchanges, once their
    200         support has been confirmed.
    201       </t>
    202       <t>
    203         Use of "trickle ICE" (see <xref target='I-D.ietf-mmusic-trickle-ice'/>
    204         and <xref target='I-D.ivov-mmusic-trickle-ice-sip'/>)
    205         is one example where
    206         the issue occurs. SIP endpoints need to always behave as
    207         vanilla ICE agents when sending their first offer and make sure
    208         they gather all candidates before sending a SIP INVITE. This is
    209         necessary because otherwise ICE agents with no support for
    210         trickle can prematurely declare failure. Jingle endpoints, on
    211         the other hand can verify support for trickle ICE prior to
    212         engaging in a session and adapt their behaviour accordingly.
    213       </t>
    214       <t>
    215         In order to work around such issues, <xref target='XEP-0176'/>
    216         defines an Offer/Answer support mode through the
    217         "urn:ietf:rfc:3264" feature tag. It indicates that a specific
    218         XMPP entity can only be contacted through the use of
    219         Offer/Answer semantics. Implementations conforming to
    220         this specification MUST support Offer/Answer model with Jingle.
    221         Note that such endpoints are not required to actually declare
    222         support for this tag because this would mean that they too would
    223         only be reachable through Offer/Answer semantics.
    224       </t>
    225     </section>
    226 
    227     <section title="Overview" anchor="jingle-overview">
    228       <t>
    229         As mentioned, Jingle was designed in part to enable
    230         straightforward protocol mapping between XMPP and SIP.
    231         However, given the significantly different technology
    232         assumptions underlying XMPP and SIP, Jingle is naturally
    233         different from SIP in several important respects:
    234       </t>
    235       <t>
    236         <list style='symbols'>
    237           <t>
    238             Base SIP messages and headers use a plaintext format
    239             similar in some ways to the Hypertext Transport Protocol
    240             <xref target='RFC2616'/>, whereas Jingle messages are pure
    241             XML. Mappings between SIP headers and Jingle message
    242             syntax are provided below.
    243           </t>
    244           <t>
    245             The SIP payloads defining session semantics use the
    246             Session Description Protocol <xref target='RFC4566'/>,
    247             whereas the equivalent Jingle payloads are defined as XML
    248             child elements of the Jingle &lt;content/&gt; element.
    249             However, the Jingle specifications defining such child
    250             elements specify mappings to SDP for all Jingle syntax,
    251             making the mapping relatively straightforward.
    252           </t>
    253           <t>
    254             The SIP signalling channel has historically often been
    255             transported over UDP, whereas the signalling channel for
    256             Jingle is XMPP over TCP. Mapping between the transport
    257             layers typically happens within a gateway using techniques
    258             below the application level, and therefore is not
    259             addressed in this specification.
    260           </t>
    261         </list>
    262       </t>
     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>
    263147    </section>
    264148
    265149    <section title="Syntax Mappings" anchor="jingle-syntax">
    266150      <section title="Generic Jingle Syntax" anchor="jingle-syntax-generic">
    267         <t>
    268           Jingle is designed in a modular fashion, so that session
    269           description data is generally carried in a payload within
    270           the generic Jingle elements, i.e., the &lt;jingle/&gt;
    271           element and its &lt;content/&gt; child. The following
    272           example illustrates this structure, where the XMPP stanza is
    273           a request to initiate an audio session using RTP over a raw
    274           UDP transport.
    275         </t>
    276         <figure>
    277           <artwork><![CDATA[
    278 <iq from='romeo@example.net/v3rsch1kk3l1jk'
    279   id='ne91v36s'
    280   to='juliet@example.com/t3hr0zny'
    281   type='set'>
    282 <jingle xmlns='urn:xmpp:jingle:1'
    283         action='session-initiate'
    284         initiator='romeo@example.net/v3rsch1kk3l1jk'
    285         sid='a73sjjvkla37jfea'>
    286   <content creator='initiator'
    287            media='audio'
    288            name='this-is-the-audio-content'
    289            senders='both'>
    290     <description xmlns='urn:xmpp:jingle:app:rtp:1'>
    291       <payload-type id='96' name='speex' clockrate='16000'/>
    292       <payload-type id='97' name='speex' clockrate='8000'/>
    293       <payload-type id='18' name='G729'/>
    294       <payload-type channels='2'
    295                     clockrate='16000'
    296                     id='103'
    297                     name='L16'/>
    298       <payload-type id='98' name='x-ISAC' clockrate='8000'/>
    299     </description>
    300     <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
    301       <candidate id='v3c18fgg' ip='10.1.1.104'
    302                  port='13540' generation='0'/>
    303     </transport>
    304   </content>
    305 </jingle>
    306 </iq>
     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>
    307184          ]]></artwork>
    308185        </figure>
    309         <t>In the foregoing example, the syntax and semantics of the
    310           &lt;jingle/&gt; and &lt;content/&gt; elements are defined in
    311           the core Jingle specification <xref target='XEP-0166'/>, the syntax and semantics of the
    312           &lt;description/&gt; element qualified by the
    313           'urn:xmpp:jingle:app:rtp:1' namespace are defined in the
    314           Jingle RTP specification <xref target='XEP-0167'/>, and the syntax and semantics of
    315           the &lt;transport/&gt; element qualified by the
    316           'urn:xmpp:jingle:transport:raw-udp' namespace are defined in
    317           the Jingle Raw UDP <xref target='XEP-0177'/>. Other &lt;description/&gt;
    318           elements are defined in specifications for the appropriate
    319           application types (see for example <xref target='XEP-0234'/>)
    320           and other &lt;transport/&gt; elements are defined in the
    321           specifications for appropriate transport methods (see for
    322           example <xref target='XEP-0176'/>, which defines an XMPP
    323           profile of <xref target='RFC5245'/>).
    324         </t>
    325         <t>At the core Jingle layer, the following mappings are
    326           defined.
    327         </t>
    328         <figure>
    329         <preamble>Table 1: High-Level Mapping from XMPP to SIP</preamble>
     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>
    330190          <artwork><![CDATA[
    331191+--------------------------------+--------------------------------+
     
    353213        </figure>
    354214        <t>* In can be appropriate to map to the a=mid value defined in <xref target='RFC5888'/>.</t>
    355         <t>
    356           The 'senders' attribute is optional in Jingle; thus in case the
    357           attribute is absent it is RECOMMENDED that the direction value is
    358           considered as 'sendrecv'.
    359         </t>
    360         <t>The 'action' attribute of the &lt;jingle/&gt; element has
    361           15 allowable values. In general they should be mapped as
    362           shown in the following table, with some exceptions as
    363           described herein.
    364         </t>
    365         <figure>
    366         <preamble>Table 2: Mapping of Jingle Actions</preamble>
    367           <artwork><![CDATA[
    368 +-------------------+-----------------+
    369 | Jingle Action     | SIP Method      |
    370 +-------------------+-----------------+
    371 | content-accept    | INVITE response |
    372 |                   | (1xx or 2xx)    |
    373 +-------------------+-----------------+
    374 | content-add       | INVITE request  |
    375 +-------------------+-----------------+
    376 | content-modify    | INVITE request  |
    377 +-------------------+-----------------+
    378 | content-reject    | unused          |
    379 +-------------------+-----------------+
    380 | content-remove    | INVITE request  |
    381 +-------------------+-----------------+
    382 | description-info  | unused          |
    383 +-------------------+-----------------+
    384 | security-info     | unused          |
    385 +-------------------+-----------------+
    386 | session-accept    | INVITE response |
    387 |                   | (1xx or 2xx)    |
    388 +-------------------+-----------------+
    389 | session-info      | [varies]        |
    390 +-------------------+-----------------+
    391 | session-initiate  | INVITE request  |
    392 +-------------------+-----------------+
    393 | session-terminate | BYE             |
    394 +-------------------+-----------------+
    395 | transport-accept  | unused          |
    396 +-------------------+-----------------+
    397 | transport-info    | unused          |
    398 +-------------------+-----------------+
    399 | transport-reject  | unused          |
    400 +-------------------+-----------------+
    401 | transport-replace | unused          |
    402 +-------------------+-----------------+
     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+-------------------+------------------------------+
    403253          ]]></artwork>
    404254        </figure>
    405255      </section>
    406256
    407       <section title="Application Formats"
    408                anchor="jingle-syntax-application-formats">
    409         <t>
    410           Jingle application formats for audio and video exchange via RTP are
    411           specified in <xref target='XEP-0167'/>. These application
    412           formats effectively maps to the "RTP/AVP" profile specified
    413           in <xref target='RFC3551'/> and the "RTP/SAVP" profile
    414           specified in <xref target='RFC3711'/>, where the media types are "audio" and
    415           "video", and the specific mappings to SDP syntax are provided in
    416           <xref target='XEP-0167'/>.
    417         </t>
    418         <t>As stated in
    419           <xref target='XEP-0167'/> future versions of this
    420           specification might define how to use other RTP profiles
    421           such as "RTP/AVPF" and "RTP/SAVPF" as defined in RFC4585 and
    422           RFC5124 respectively.
    423         </t>
     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>
    424260      </section>
    425261
    426       <section title="Raw UDP Transport Method"
    427                anchor="jingle-syntax-udp">
    428         <t>
    429           A basic Jingle transport method for exchanging media over
    430           UDP is specified in <xref target='XEP-0177'/>. This transport
    431           method involves the negotiation of an IP address and port
    432           only. It does not provide NAT traversal, effectively leaving
    433           the task to intermediary entries. The Jingle 'ip' attribute
    434           maps to the connection-address parameter of the SDP c= line
    435           and the 'port' attribute maps to the port parameter of the
    436           SDP m= line. Use of SIP without ICE would generally map to
    437           use of Raw UDP on the XMPP side of a session.
    438         </t>
     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>
    439264      </section>
    440265
    441       <section title="ICE-UDP Transport Method"
    442                anchor="jingle-syntax-ice">
    443         <t>
    444           A more advanced Jingle transport method for exchanging
    445           media over UDP is specified in <xref target='XEP-0176'/>.
    446           Under ideal conditions this transport method provides NAT
    447           traversal by following the Interactive Connectivity Exchange
    448           methodology specified in <xref target='RFC5245'/>.
    449         </t>
    450         <t>
    451           The relevant SDP mappings are provided in
    452           <xref target='XEP-0176'/>, however there are a few syntax
    453           incompatibilities which need to be addressed by gateways
    454           conforming to this specification:
    455         </t>
     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>
    456269        <t>
    457270          <list style='symbols'>
     
    469282            <t>
    470283              Jingle defines a 'generation' attribute which is used
    471               to determine if an ICE restart is required. Such
     284              to determine if an ICE restart is required. This
    472285              attribute has no counterpart in SIP as ICE restarts are
    473               detected by detecting a change in the ICE ufrag and
     286              initiated by detecting a change in the ICE ufrag and
    474287              password. Gateways MUST therefore increase the
    475288              generation number when they detect such changes.
     
    484297              counterpart in SIP and SHOULD be ignored.
    485298            </t>
    486 
    487 <t>[[OPEN ISSUE: describe handling of ICE restarts.]]</t>
    488 
    489299          </list>
    490300        </t>
     301<t>[[OPEN ISSUE: describe handling of ICE restarts.]]</t>
    491302      </section>
    492303    </section>
    493304
    494305    <section title="Call Hold" anchor="call-hold">
    495       <t>
    496         <xref target="RFC3264"/> stipulates that streams are placed on
    497         hold by setting their direction to "sendonly". A session is
    498         placed on hold by doing this for all the streams it contains.
    499         The same semantics are also supported by Jingle through the
    500         "senders" element and its "initiator" and "responder" values
    501         (XEP-0166 also defines a value of "none", which mapes to an
    502         a= value of "inactive").
    503       </t>
    504         <figure>
    505           <artwork><![CDATA[
    506               [example to follow]
     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>
    507325          ]]></artwork>
    508326        </figure>
    509       <t>
    510         In addition to these semantics however Jingle also defines a
    511         more concise way for achieving the same, which consists in
    512         sending a "hold" command within a "session-info" action:
    513       </t>
    514         <figure>
    515           <artwork><![CDATA[
    516 <iq from='juliet@capulet.lit/balcony'
    517     id='xv39z423'
    518     to='romeo@montague.lit/orchard'
    519     type='set'>
    520   <jingle xmlns='urn:xmpp:jingle:1'
    521           action='session-info'
    522           initiator='romeo@montague.lit/orchard'
    523           sid='a73sjjvkla37jfea'>
    524     <hold xmlns='urn:xmpp:jingle:apps:rtp:info:1'/>
    525   </jingle>
    526 </iq>
     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>
    527342          ]]></artwork>
    528343        </figure>
    529       <t>
    530         Gateways that receive a "hold" command from their Jingle side
    531         MUST generate a new offer on their SIP side, placing all streams
    532         in a "sendonly" state.
    533       </t>
    534       <t>
    535         When relaying offers from SIP to XMPP however, gateways are not
    536         required to translate "sendonly" attributes into a "hold"
    537         command as this would not always be possible (e.g. when not all
    538         streams have the same direction). Additionally such conversions
    539         might introduce complications in case further offers placing a
    540         session of hold also contain other session modifications.
    541 
    542       </t>
    543 
    544       <t>[[OPEN ISSUE: do we need to mention double hold here? That is, when you put me on hold after I did it first. Direction would then be "inactive".]]</t>
    545 
    546     </section>
     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
    547349    <section title="Early Media" anchor="early-media">
    548       <t>
    549         <xref target="RFC3959"/> and <xref target="RFC3960"/> describe
    550         a number of scenarios relying on "early media". While similar
    551         attempts have also been made for XMPP <xref target="XEP-0269"/>
    552         support for early media is not currently widely supported in
    553         Jingle implementations. Therefore, gateways SHOULD NOT forward
    554         SDP answers from SIP to Jingle until a final response has been
    555         received, except in cases where the gateway is in a position to
    556         confirm specific support for early media
    557         by the endpoint (one approach to such support can be found in
    558         <xref target="XEP-0269"/> but it has not yet been standardized).
    559       </t>
    560       <t>
    561         Gateways MUST however store early media SDP answers when they
    562         are sent inside a reliable provisional response. In such cases,
    563         a subsequent final response may follow without an actual answer
    564         and the one from the provisional response will need to be
    565         forwarded to the Jingle endpoint.
    566       </t>
     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>
    567352    </section>
    568353   
    569354    <section title="Detecting Endless Loops" anchor="loops">
    570       <t>
    571         <xref target="RFC3261"/> defines a "Max-Forwards" header that
    572         allows intermediate entities such as SIP proxies to detect and
    573         prevent loops from occurring. The specifics of XMPP make such
    574         a prevention mechanism unnecessary for XMPP-only environments.
    575         With the introduction of SIP-to-XMPP gatewaying however, it
    576         would be possible for loops to occur where messages are being
    577         repeatedly forwarded from XMPP to SIP to XMPP to SIP, etc.
    578       </t>
    579       <t>
    580         To compensate for the lack of a "Max-Forwards" header in SIP,
    581         gateways MUST therefore keep track of all SIP transactions and
    582         Jingle sessions that they are currently serving and they MUST
    583         block re-entrant messages.
    584       </t>
    585       <t>
    586         [[OPEN ISSUE:
    587         In order for this to work, we need a consistent way
    588         of translating dialog IDs into Jingle sessions, and vice versa,
    589         so that the following can be verified:
    590           jingleSessID == toJingleSessID(toSipCallID( jingleSessID )).
    591         We need to mention mention spirals here as well. Alice could call
    592         Bob, but Bob forwards his call to Romeo. A spiral on the SIP
    593         side could end up becoming a loop if the gateway is in between.]]
    594       </t>
    595     </section>
     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
    596362    <section title="SDP Format-Specific Parameters" anchor="fmtp">
    597       <t>
    598         <xref target="RFC4566"/> defines "a=fmtp" attributes for the
    599         transmission of format specific parameters as a single
    600         transparent string. Such strings can be used to convey either a
    601         single value or a sequence of parameters, separated by
    602         semi-colons, commas or whatever delimiters are chosen by a
    603         particular payload type specification.
    604       </t>
    605       <t>
    606         <xref target="XEP-0167"/> on the other hand defines a
    607         "&lt;parameter/&gt;" element as follows:
     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>
    608365        <figure>
    609366          <artwork><![CDATA[
     
    611368          ]]></artwork>
    612369        </figure>
    613         A sequence of parameters is thus transmitted as an array of
    614         distinct name/value couples, at least in the context of the
    615         Jingle RTP extension.
    616       </t>
    617       <t>
    618         These differences make it impossible to devise a generic
    619         mechanism that accurately translates format parameters from
    620         Jingle RTP to SDP without the specifics of the payload being known
    621         to the gateway. This specification therefore makes the following
    622         recommendations for a best-effort attempt at translation:
    623       </t>
     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>
    624373      <t>
    625374        <list style='numbers'>
    626           <t>
    627             Gateways that are aware of the formats in use SHOULD parse
    628             all format parameters and generate "&lt;parameter/&gt;" arrays
    629             and "a=fmtp" values accordingly.
    630           </t>
    631           <t>
    632             When translating Jingle RTP to SIP, gateways that have no
    633             explicit support for the formats that are being negotiated
    634             SHOULD convert the list of "&lt;parameter/&gt;" elements into
    635             a single string, containing a sequence of "name=value"
    636             pairs, separated by a semi-colon and a space (i.e. "; ").
    637           </t>
    638           <t>
    639             When translating SIP to Jingle RTP, gateways that have no
    640             explicit support for the formats that are being negotiated
    641             SHOULD tokenize the "a=fmtp" format string using one delimiter
    642             from the following list: ";", "; ", ",", ", ". The
    643             resulting tokens SHOULD then be parsed as "name=value"
    644             pairs. If this process does actually yield any such pairs,
    645             they SHOULD be used for generating the respective
    646             "&lt;parameter/&gt;" elements. If some of the tokens cannot be
    647             parsed into a "name=value" pair because they do not conform to
    648             the convention suggested in <xref target='RFC4855'/>, or in case the format
    649             string couldn't be tokenized with the above delimiters, the
    650             remaining strings SHOULD be used as a value for the
    651             "value" attribute of the "&lt;parameter/&gt;" element and the
    652             corresponding "name" attribute SHOULD be left empty.
    653           </t>
     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>
    654378        </list>
    655379      </t>
    656       <t>Here is an example of the foregoing transformations, using DTMF as described in <xref target='RFC4733'/>.</t>
     380      <t>Here is an example of the foregoing transformations, using the aforementioned example of DTMF digits:</t>
    657381      <figure>
    658382        <preamble>SDP with format data</preamble>
     
    671395
    672396    <section title="Dialog Forking" anchor="forking">
    673       <t>
    674         <xref target="RFC3261"/> defines semantics for dialog forking.
    675         Such semantics have not been defined for Jingle and need to be
    676         hidden from XMPP endpoints.
    677       </t>
    678       <t>
    679         To achieve this, a SIP-to-XMPP gateway MUST NOT forward more than
    680         one provisional response on their Jingle side. Typically they
    681         would do so only for the first provisional response they receive
    682         and ignore the rest. This provisional response SHOULD be
    683         forwarded as if it originated from a "user@host" Jabber ID (i.e.,
    684         a "bare JID")
    685         corresponding to the AOR URI found in the "From" header of the
    686         SIP provisional response. The gateway MUST NOT attempt to
    687         translate GRUUs into full JIDs because it cannot know at this
    688         stage which of the dialogs established by these provisional
    689         responses will be used for the actual session.
    690       </t>
    691       <t>
    692         Likewise, gateways conforming to this specification MUST NOT forward
    693         more than a single final response received through SIP to the Jingle side.
    694         The gateway SHOULD terminate the SIP sessions whose received final response
    695         wasn't forwarded to the Jingle side.
    696       </t>
     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>
    697400    </section>
    698401
    699402    <section title="Sample Scenarios" anchor="jingle-scenarios">
    700       <t>
    701         The following sections provide sample scenarios (or "call
    702         flows") that illustrate the principles of interworking from
    703         Jingle to SIP. These scenarios are not exhaustive.
    704       </t>
    705 
    706       <section title="Basic Voice Chat"
    707                anchor="jingle-scenarios-basic">
    708         <t>
    709           The protocol flow for a basic voice chat for which an XMPP
    710           user (juliet@example.com) is the initiator and a SIP user
    711           (romeo@example.net) is the responder. The voice chat is
    712           consummated through a gateway. To simplify the example, the
    713           Jingle transport method negotiated is "raw user datagram protocol"
    714           as specified in <xref target='XEP-0177'/>.
    715         </t>
    716         <figure>
    717           <artwork><![CDATA[
    718 INITIATOR               GATEWAY                RESPONDER
    719   |                        |                       |
    720   | session-initiate       |                       |
    721   |----------------------->|                       |
    722   | IQ-result (ack)        |                       |
    723   |<-----------------------|                       |
    724   |                        | INVITE                |
    725   |                        |---------------------->|
    726   |                        | 180 Ringing           |
    727   |                        |<----------------------|
    728   | session-info (ringing) |                       |
    729   |<-----------------------|                       |
    730   | IQ-result (ack)        |                       |
    731   |----------------------->|                       |
    732   |                        | 200 OK                |
    733   |                        |<----------------------|
    734   | session-accept         |                       |
    735   |<-----------------------|                       |
    736   | IQ-result (ack)        |                       |
    737   |----------------------->|                       |
    738   |                        | ACK                   |
    739   |                        |---------------------->|
    740   |                   MEDIA SESSION                |
    741   |<==============================================>|
    742   |                        | BYE                   |
    743   |                        |<----------------------|
    744   | session-terminate      |                       |
    745   |<-----------------------|                       |
    746   | IQ-result (ack)        |                       |
    747   |----------------------->|                       |
    748   |                        | 200 OK                |
    749   |                        |---------------------->|
    750   |                        |                       |
     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|              |            |          |
    751497          ]]></artwork>
    752498        </figure>
    753499        <t>The packet flow is as follows.</t>
    754         <t>First the XMPP user sends a Jingle session-initiation
    755           request to the SIP user.
    756         </t>
    757         <figure>
    758           <artwork><![CDATA[
    759   <iq from='juliet@example.com/t3hr0zny'
    760     id='hu2s61f4'
    761     from='romeo@example.net/v3rsch1kk3l1jk'
    762     type='set'>
    763   <jingle xmlns='urn:xmpp:jingle:1'
    764           action='session-initiate'
    765           initiator='juliet@example.com/t3hr0zny'
    766           sid='a73sjjvkla37jfea'>
    767     <content creator='initiator'
    768              media='audio'
    769              name='this-is-the-audio-content'>
    770       <description xmlns='urn:xmpp:jingle:app:rtp:1'>
    771         <payload-type id='96' name='speex' clockrate='16000'/>
    772         <payload-type id='97' name='speex' clockrate='8000'/>
    773         <payload-type id='18' name='G729'/>
    774       </description>
    775       <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
    776         <candidate component='1' generation='0' id='u3gscv289p'
    777                    ip='192.0.2.101' port='49172'/>
    778       </transport>
    779     </content>
    780   </jingle>
    781   </iq>
    782         ]]></artwork>
    783         </figure>
    784         <t>The gateway returns an XMPP IQ-result to the initiator on
    785           behalf of the responder.
    786         </t>
    787         <figure>
    788           <artwork><![CDATA[
    789   <iq from='juliet@example.com/t3hr0zny'
    790     id='hu2s61f4'
    791     to='romeo@example.net/v3rsch1kk3l1jk'
    792     type='result'/>
    793         ]]></artwork>
    794         </figure>
    795         <t>The gateway transforms the Jingle session-initiate action
    796           into a SIP INVITE.
    797         </t>
    798         <figure>
    799           <artwork><![CDATA[
    800   INVITE sip:romeo@example.net SIP/2.0
    801   Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9
    802   Max-Forwards: 70
    803   From: Juliet Capulet <sip:juliet@example.com>;tag=t3hr0zny
    804   To: Romeo Montague <sip:romeo@example.net>
    805   Call-ID: 3848276298220188511@example.com
    806   CSeq: 1 INVITE
    807   Contact: <sip:juliet@client.example.com;transport=tcp>
    808   Content-Type: application/sdp
    809   Content-Length: 184
    810 
    811   v=0
    812   o=alice 2890844526 2890844526 IN IP4 client.example.com
    813   s=-
    814   c=IN IP4 192.0.2.101
    815   t=0 0
    816   m=audio 49172 RTP/AVP 18 96 97
    817   a=rtpmap:96 sppex/16000
    818   a=rtpmap:97 speex/8000
    819   a=rtpmap:18 G729
     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
    820563        ]]></artwork>
    821564        </figure>
    822565        <t>The responder returns a SIP 180 Ringing message.</t>
    823566        <figure>
    824           <artwork><![CDATA[
    825   SIP/2.0 180 Ringing
    826   Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9;\
    827        received=192.0.2.101
    828   From: Juliet Capulet <sip:juliet@example.com>;tag=t3hr0zny
    829   To: Romeo Montague <sip:romeo@example.net>;tag=v3rsch1kk3l1jk
    830   Call-ID: 3848276298220188511@example.com
    831   CSeq: 1 INVITE
    832   Contact: <sip:romeo@client.example.net;transport=tcp>
    833   Content-Length: 0
    834         ]]></artwork>
    835         </figure>
    836         <t>The gateway transforms the ringing message into XMPP
    837           syntax.
    838         </t>
    839         <figure>
    840           <artwork><![CDATA[
    841   <iq from='romeo@montague.net/v3rsch1kk3l1jk'
    842     id='ol3ba71g'
    843     to='juliet@example.com/t3hr0zny'
    844     type='set'>
    845   <jingle xmlns='urn:xmpp:jingle:1'
    846           action='session-info'
    847           initiator='juliet@example.com/t3hr0zny'
    848           sid='a73sjjvkla37jfea'>
    849     <ringing xmlns='urn:xmpp:jingle:apps:rtp:info:1'/>
    850   </jingle>
    851   </iq>
    852         ]]></artwork>
    853         </figure>
    854         <t>The initiator returns an IQ-result acknowledging receipt of
    855           the ringing message, which is used only by the gateway and
    856           not transformed into SIP syntax.
    857         </t>
    858         <figure>
    859           <artwork><![CDATA[
    860   <iq from='juliet@example.com/t3hr0zny'
    861     id='ol3ba71g'
    862     to='romeo@example.net/v3rsch1kk3l1jk'
    863     type='result'/>
    864         ]]></artwork>
    865         </figure>
    866         <t>The responder sends a SIP 200 OK to the initiator.</t>
    867         <figure>
    868           <artwork><![CDATA[
    869   SIP/2.0 200 OK
    870   Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9;\
    871        received=192.0.2.101
    872   From: Juliet Capulet <sip:juliet@example.com>;tag=t3hr0zny
    873   To: Romeo Montague <sip:romeo@example.net>;tag=v3rsch1kk3l1jk
    874   Call-ID: 3848276298220188511@example.com
    875   CSeq: 1 INVITE
    876   Contact: <sip:romeo@client.example.net;transport=tcp>
    877   Content-Type: application/sdp
    878   Content-Length: 147
    879 
    880   v=0
    881   o=romeo 2890844527 2890844527 IN IP4 client.example.net
    882   s=-
    883   c=IN IP4 192.0.2.201
    884   t=0 0
    885   m=audio 3456 RTP/AVP 97
    886   a=rtpmap:97 speex/8000
    887         ]]></artwork>
    888         </figure>
    889         <t>The gateway transforms the 200 OK into a Jingle
    890           session-accept action.
    891         </t>
    892         <figure>
    893           <artwork><![CDATA[
    894   <iq from='romeo@example.net/v3rsch1kk3l1jk'
    895     id='pd1bf839'
    896     to='juliet@example.com/t3hr0zny'
    897     type='set'>
    898   <jingle xmlns='urn:xmpp:jingle:1'
    899           action='session-accept'
    900           initiator='juliet@example.com/t3hr0zny'
    901           responder='romeo@example.net/v3rsch1kk3l1jk'
    902           sid='a73sjjvkla37jfea'>
    903     <content creator='initiator'
    904              media='audio'
    905              name='this-is-the-audio-content'>
    906       <description xmlns='urn:xmpp:jingle:app:rtp:1'>
    907         <payload-type id='97' name='speex' clockrate='8000'/>
    908       </description>
    909       <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
    910         <candidate id='9eg13am7' ip='192.0.2.101'
    911                    port='49172' generation='0'/>
    912       </transport>
    913     </content>
    914   </jingle>
    915   </iq>
    916         ]]></artwork>
    917         </figure>
    918         <t>If the payload types and transport candidate can be
    919           successfully used by both parties, then the initiator
    920           acknowledges the session-accept action.
    921         </t>
    922         <figure>
    923           <artwork><![CDATA[
    924   <iq from='romeo@example.net/v3rsch1kk3l1jk'
    925     id='pd1bf839'
    926     to='juliet@example.com/t3hr0zny'
    927     type='result'/>
    928         ]]></artwork>
    929         </figure>
    930         <t>The parties now begin to exchange media. In this case they
    931           would exchange audio using the Speex codec at a clockrate of
    932           8000 since that is the highest-priority codec for the
    933           responder (as determined by the XML order of the &lt;payloadtype/&gt;
    934           children).
    935         </t>
    936         <t>The parties can continue the session as long as desired.
    937         </t>
    938         <t>Eventually, one of the parties (in this case the responder)
    939           terminates the session.
    940         </t>
    941         <figure>
    942           <artwork><![CDATA[
    943   BYE sip:juliet@client.example.com SIP/2.0
    944   Via: SIP/2.0/TCP client.example.net:5060;branch=z9hG4bKnashds7
    945   Max-Forwards: 70
    946   From: Romeo Montague <sip:romeo@example.net>;tag=8321234356
    947   To: Juliet Capulet <sip:juliet@example.com>;tag=9fxced76sl
    948   Call-ID: 3848276298220188511@example.com
    949   CSeq: 1 BYE
    950   Content-Length: 0
     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
    951683        ]]></artwork>
    952684        </figure>
    953685        <t>The gateway transforms the SIP BYE into XMPP syntax.</t>
    954686        <figure>
    955           <artwork><![CDATA[
    956 <iq from='romeo@example.net/v3rsch1kk3l1jk'
    957     id='rv301b47'
    958     to='juliet@example.com/t3hr0zny'
    959     type='set'>
    960   <jingle xmlns='urn:xmpp:jingle:1'
    961           action='session-terminate'
    962           initiator='juliet@example.com/t3hr0zny'
    963           sid='a73sjjvkla37jfea'/>
    964     <reason>
    965       <success/>
    966     </reason>
    967 </iq>
    968         ]]></artwork>
    969         </figure>
    970         <t>The initiator returns an IQ-result acknowledging receipt of
    971           the session termination, which is used only by the gateway
    972           and not transformed into SIP syntax.
    973         </t>
    974         <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>
    975707          <artwork><![CDATA[
    976708  <iq from='romeo@example.net/v3rsch1kk3l1jk'
     
    988720
    989721    <section title='Security Considerations' anchor="sec">
    990       <t>Detailed security considerations for session management are
    991         given for SIP in <xref target='RFC3261'/>
    992         and for XMPP in <xref target='XEP-0166'/>
    993         (see also <xref target='RFC6120'/>).
    994         The security considerations provided in
    995         <xref target='I-D.ietf-stox-core'/> also apply.
    996       </t>
     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>
    997723    </section>
    998724
     
    1021747          <abstract>
    1022748            <t>As a foundation for the definition of
    1023               application-specific, bi-directional protocol mappings
     749              application-specific, bidirectional protocol mappings
    1024750              between the Session Initiation Protocol (SIP) and the
    1025751              Extensible Messaging and Presence Protocol (XMPP), this
     
    12791005      &rfc3959;
    12801006      &rfc3960;
     1007      &rfc4585;
     1008      &rfc5124;
    12811009      &rfc5888;
     1010      &rfc7081;
    12821011
    12831012<reference anchor="XEP-0234">
     
    13221051
    13231052    <section title="Acknowledgements" anchor="acks">
    1324       <t>Thanks to Philipp Hancke for his detailed feedback.</t>
     1053      <t>Thanks to Dave Crocker, Philipp Hancke, Paul Kyzivat, and Jonathan Lennox for their feedback.</t>
    13251054      <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>
    13261055      <t>Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier versions of this document.</t>
Note: See TracChangeset for help on using the changeset viewer.