Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions
draft-saintandre-sip-xmpp-media-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 7, 2008.

Abstract

This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP) and those that implement the Session Initiation Protocol (SIP).

Table of Contents

1.  Introduction
2.  Jingle to SIP
    2.1.  Overview
    2.2.  Syntax Mappings
    2.3.  Sample Scenarios
3.  SIP to Jingle
4.  Security Considerations
5.  References
    5.1.  Normative References
    5.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

The Session Initiation Protocol [SIP] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) is a widely-deployed technology for the management of media sessions (such as voice calls) over the Internet. SIP itself provides a signalling channel (typically via the User Datagram Protocol [UDP] (Postel, J., “User Datagram Protocol,” August 1980.)), 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] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.).

The Extensible Messaging and Presence Protocol [XMPP] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) also provides a signalling channel, typically via the Transmission Control Protocol [TCP] (Postel, J., “Transmission Control Protocol,” September 1981.). Given the significant differences between XMPP and SIP, it is difficult to combine the two technologies in a single user agent. Therefore, developers wishing to add media session capabilities to XMPP clients have defined an XMPP-specific negotiation protocol called Jingle [JINGLE] (Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, “Jingle,” June 2007.).

However, Jingle has been designed to easily map to SIP for communication through gateways or other transformation mechanisms. Therefore, consistent with existing specifications for mapping between SIP and XMPP (see [SIP‑XMPP] (Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core,” January 2008.) and other specifications in that "series"), this document describes a bi-directional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement SIP and those that implement the XMPP Jingle extensions.

Note: The capitalized 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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [TERMS].

2.  Jingle to SIP

2.1.  Overview

As mentioned, Jingle was designed in part to enable straightforward protocol mapping between XMPP and SIP. However, given the significantly different technology assumptions underlying XMPP and SIP, Jingle is naturally different from SIP in several important respects:

• Base SIP messages and headers use a plaintext format similar in some ways to the Hypertext Transport Protocol [HTTP] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), whereas Jingle messages are pure XML. Mappings between SIP headers and Jingle message syntax are provided below.
• The SIP payloads defining session semantics use the Session Description Protocol [SDP] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.), whereas the equivalent Jingle payloads are defined as XML child elements of the Jingle <content/> element. However, the Jingle specifications defining such child elements specify mappings to SDP for all Jingle syntax, making the mapping relatively straightforward.
• The SIP signalling channel is 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.

2.2.  Syntax Mappings

2.2.1.  Generic Jingle Syntax

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 <jingle/> element and its <content/> child. The following example illustrates this structure, where the XMPP stanza is a request to initiate an audio session using RTP over a raw UDP transport.

<iq from='romeo@example.net/v3rsch1kk3l1jk'
    id='jingle1'
    to='juliet@example.com/t3hr0zny'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle'
          action='session-initiate'
          initiator='romeo@example.net/v3rsch1kk3l1jk'
          responder='juliet@example.com/t3hr0zny'
          sid='a73sjjvkla37jfea'>
    <content creator='initiator'
             name='this-is-the-audio-content'
             profile='RTP/AVP'
             senders='both'>
      <description xmlns='urn:xmpp:jingle:app:audio-rtp'>
        <payload-type id='96' name='speex' clockrate='16000'/>
        <payload-type id='97' name='speex' clockrate='8000'/>
        <payload-type id='18' name='G729'/>
        <payload-type channels='2'
                      clockrate='16000'
                      id='103'
                      name='L16'/>
        <payload-type id='98' name='x-ISAC' clockrate='8000'/>
      </description>
      <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
        <candidate ip='10.1.1.104' port='13540' generation='0'/>
      </transport>
    </content>
  </jingle>
</iq>

In the foregoing example, the syntax and semantics of the <jingle/> and <content/> elements are defined in [JINGLE] (Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, “Jingle,” June 2007.), the syntax and semantics of the <description/> element are defined in [JINGLE‑AUDIO] (Ludwig, S., Saint-Andre, P., Egan, S., and R. McQueen, “Jingle Audio via RTP,” November 2007.), and the syntax and semantics of the <transport/> element are defined in [JINGLE‑UDP] (Beda, J., Saint-Andre, P., Ludwig, S., Hildebrand, J., and S. Egan, “Jingle Raw UDP Transport,” November 2007.). Other <description/> elements are defined in specifications for the appropriate application types (see for example [JINGLE‑VIDEO] (Saint-Andre, P. and M. Chen, “Jingle Video via RTP,” November 2007.)) and other <transport/> elements are defined in the specifications for appropriate transport methods (see for example [JINGLE‑ICE] (Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., and S. Egan, “Jingle ICE-UDP Transport Method,” November 2007.), which defines an XMPP profile of [ICE] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.)).

At the core Jingle layer, the following mappings are defined.

+--------------------------------+--------------------------------+
|           Jingle               |             SIP                |
+--------------------------------+--------------------------------+
| <jingle/> 'action'             | [ see next table ]             |
+--------------------------------+--------------------------------+
| <jingle/> 'initiator'          | [ no mapping ]                 |
+--------------------------------+--------------------------------+
| <jingle/> 'responder'          | [ no mapping ]                 |
+--------------------------------+--------------------------------+
| <jingle/> 'sid'                | local-part of Call-ID          |
+--------------------------------+--------------------------------+
| local-part of 'initiator'      | <username> in SDP o= line      |
+--------------------------------+--------------------------------+
| <content/> 'creator'           | [ no mapping ]                 |
+--------------------------------+--------------------------------+
| <content/> 'name'              | [ no mapping ]                 |
+--------------------------------+--------------------------------+
| <content/> 'profile'           | <proto> in SDP m= line         |
+--------------------------------+--------------------------------+
| <content/> 'senders' value of  | a= line of sendrecv, recvonly, |
| both, initiator, or responder  | or sendonly                    |
+--------------------------------+--------------------------------+

The 'action' attribute of the <jingle/> element has nine allowable values. In general they should be mapped as shown in the following table, with some exceptions as described herein.

+-------------------+-----------------+
| Jingle Action     | SIP Method      |
+-------------------+-----------------+
| content-accept    | INVITE response |
|                   | (1xx)           |
+-------------------+-----------------+
| content-add       | INVITE request  |
+-------------------+-----------------+
| content-modify    | INVITE request  |
+-------------------+-----------------+
| content-remove    | INVITE request  |
+-------------------+-----------------+
| session-accept    | INVITE response |
|                   | (1xx or 2xx)    |
+-------------------+-----------------+
| session-info      | [varies]        |
+-------------------+-----------------+
| session-initiate  | INVITE request  |
+-------------------+-----------------+
| session-terminate | BYE             |
+-------------------+-----------------+
| transport-info    | [varies]        |
+-------------------+-----------------+

2.2.2.  Audio Application Format

A Jingle application format for audio exchange via RTP is specified in [JINGLE‑AUDIO] (Ludwig, S., Saint-Andre, P., Egan, S., and R. McQueen, “Jingle Audio via RTP,” November 2007.). This application format effectively maps to the "RTP/AVP" profile specified in [RTP‑AVP] (Schulzrinne, H. and S. Casner, “RTP Profile for Audio and Video Conferences with Minimal Control,” July 2003.), where the media type is "audio" and the specific mappings to SDP syntax are provided in [JINGLE‑AUDIO] (Ludwig, S., Saint-Andre, P., Egan, S., and R. McQueen, “Jingle Audio via RTP,” November 2007.).

2.2.3.  Video Application Format

A Jingle application format for video exchange via RTP is specified in [JINGLE‑VIDEO] (Saint-Andre, P. and M. Chen, “Jingle Video via RTP,” November 2007.). This application format effectively maps to the "RTP/AVP" profile specified in [RTP‑AVP] (Schulzrinne, H. and S. Casner, “RTP Profile for Audio and Video Conferences with Minimal Control,” July 2003.), where the media type is "audio" and the specific mappings to SDP syntax are provided in [JINGLE‑VIDEO] (Saint-Andre, P. and M. Chen, “Jingle Video via RTP,” November 2007.).

2.2.4.  Raw UDP Transport Method

A basic Jingle transport method for exchanging media over UDP is specified in [JINGLE‑UDP] (Beda, J., Saint-Andre, P., Ludwig, S., Hildebrand, J., and S. Egan, “Jingle Raw UDP Transport,” November 2007.). This transport method involves the negotiation of an IP address and port only, and does not provide NAT traversal. 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.

2.2.5.  ICE-UDP Transport Method

A more advanced Jingle transport method for exchanging media over UDP is specified in [JINGLE‑ICE] (Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., and S. Egan, “Jingle ICE-UDP Transport Method,” November 2007.). Under ideal conditions this transport method provides NAT traversal by following the Interactive Connectivity Exchange methodology specified in [ICE] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.). The relevant SDP mappings are provided in [JINGLE‑ICE] (Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., and S. Egan, “Jingle ICE-UDP Transport Method,” November 2007.).

2.3.  Sample Scenarios

The following sections provide sample scenarios (or "call flows") that illustrate the principles of interworking from Jingle to SIP. These scenarios are not exhaustive.

2.3.1.  Basic Voice Chat

The protocol flow for a basic voice chat for which an XMPP user (juliet@example.com) is the iniator and a SIP user (romeo@example.net) is the responder. The voice chat is consummated through a gateway. To simplify the example, the transport method negotiated is "raw user datagram protocol" as specified in [JINGLE‑UDP] (Beda, J., Saint-Andre, P., Ludwig, S., Hildebrand, J., and S. Egan, “Jingle Raw UDP Transport,” November 2007.).

INITIATOR  ...XMPP...   GATEWAY   ...SIP...    RESPONDER
  |                        |                       |
  | session-initiate       |                       |
  |----------------------->|                       |
  | IQ-result (ack)        |                       |
  |<-----------------------|                       |
  |                        | INVITE                |
  |                        |---------------------->|
  |                        | 180 Ringing           |
  |                        |<----------------------|
  | session-info (ringing) |                       |
  |<-----------------------|                       |
  | IQ-result (ack)        |                       |
  |----------------------->|                       |
  |                        | 200 OK                |
  |                        |<----------------------|
  | session-accept         |                       |
  |<-----------------------|                       |
  | IQ-result (ack)        |                       |
  |----------------------->|                       |
  |                        | ACK                   |
  |                        |---------------------->|
  |                   MEDIA SESSION                |
  |<==============================================>|
  |                        | BYE                   |
  |                        |<----------------------|
  | session-terminate      |                       |
  |<-----------------------|                       |
  | IQ-result (ack)        |                       |
  |----------------------->|                       |
  |                        | 200 OK                |
  |                        |---------------------->|
  |                        |                       |

The packet flow is as follows.

First the XMPP user sends a Jingle session-initiation request to the SIP user.

<iq from='juliet@example.com/t3hr0zny'
    id='jingle1'
    from='romeo@example.net/v3rsch1kk3l1jk'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle'
          action='session-initiate'
          initiator='juliet@example.com/t3hr0zny'
          sid='a73sjjvkla37jfea'>
    <content creator='initiator'
             name='this-is-the-audio-content'
             profile='RTP/AVP'>
      <description xmlns='urn:xmpp:jingle:app:audio-rtp'>
        <payload-type id='96' name='speex' clockrate='16000'/>
        <payload-type id='97' name='speex' clockrate='8000'/>
        <payload-type id='18' name='G729'/>
      </description>
      <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
        <candidate ip='192.0.2.101' port='49172' generation='0'/>
      </transport>
    </content>
  </jingle>
</iq>

The gateway returns an XMPP IQ-result to the initiator on behalf of the responder.

<iq from='juliet@example.com/t3hr0zny'
    id='accept1'
    to='romeo@example.net/v3rsch1kk3l1jk'
    type='result'/>

The gateway transforms the Jingle session-initiate action into a SIP INVITE.

INVITE sip:romeo@example.net SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Juliet Capulet <sip:juliet@example.com>;tag=t3hr0zny
To: Romeo Montague <sip:romeo@example.net>
Call-ID: 3848276298220188511@example.com
CSeq: 1 INVITE
Contact: <sip:juliet@client.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 184

v=0
o=alice 2890844526 2890844526 IN IP4 client.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:96 SPEEX/16000
a=rtpmap:97 SPEEX/8000
a=rtpmap:18 G729

The responder returns a SIP 180 Ringing message.

SIP/2.0 180 Ringing
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9
 ;received=192.0.2.101
From: Juliet Capulet <sip:juliet@example.com>;tag=t3hr0zny
To: Romeo Montague <sip:romeo@example.net>;tag=v3rsch1kk3l1jk
Call-ID: 3848276298220188511@example.com
CSeq: 1 INVITE
Contact: <sip:romeo@client.example.net;transport=tcp>
Content-Length: 0

The gateway transforms the ringing message into XMPP syntax.

<iq from='romeo@montague.net/v3rsch1kk3l1jk'
    id='ringing1'
    to='juliet@example.com/t3hr0zny'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle'
          action='session-info'
          initiator='juliet@example.com/t3hr0zny'
          sid='a73sjjvkla37jfea'>
    <ringing xmlns='urn:xmpp:jingle:app:audio-rtp-info'/>
  </jingle>
</iq>

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.

<iq from='juliet@example.com/t3hr0zny'
    id='ringing1'
    to='romeo@example.net/v3rsch1kk3l1jk'
    type='result'/>

The responder sends a SIP 200 OK to the initiator.

SIP/2.0 200 OK
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9
 ;received=192.0.2.101
From: Juliet Capulet <sip:juliet@example.com>;tag=t3hr0zny
To: Romeo Montague <sip:romeo@example.net>;tag=v3rsch1kk3l1jk
Call-ID: 3848276298220188511@example.com
CSeq: 1 INVITE
Contact: <sip:romeo@client.example.net;transport=tcp>
Content-Type: application/sdp
Content-Length: 147

v=0
o=romeo 2890844527 2890844527 IN IP4 client.example.net
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:97 SPEEX/8000
a=rtpmap:18 G729/8000

The gateway transforms the 200 OK into a Jingle session-accept action.

<iq from='romeo@example.net/v3rsch1kk3l1jk'
    id='accept1'
    to='juliet@example.com/t3hr0zny'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle'
          action='session-accept'
          initiator='juliet@example.com/t3hr0zny'
          responder='romeo@example.net/v3rsch1kk3l1jk'
          sid='a73sjjvkla37jfea'>
    <content creator='initiator'
             name='this-is-the-audio-content'
             profile='RTP/AVP'>
      <description xmlns='urn:xmpp:jingle:app:audio-rtp'>
        <payload-type id='97' name='speex' clockrate='8000'/>
        <payload-type id='18' name='G729'/>
        <payload-type id='0' name='PCMU' clockrate='8000'/>
      </description>
      <transport xmlns='urn:xmpp:jingle:transport:raw-udp'>
        <candidate ip='192.0.2.101' port='49172' generation='0'/>
      </transport>
    </content>
  </jingle>
</iq>

If the payload types and transport candidate can be successfully used by both parties, then the initiator acknowledges the session-accept action.

<iq from='romeo@example.net/v3rsch1kk3l1jk'
    id='accept1'
    to='juliet@example.com/t3hr0zny'
    type='result'/>

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 <payloadtype/> children).

The parties may continue the session as long as desired.

Eventually, one of the parties (in this case the responder) terminates the session.

BYE sip:juliet@client.example.com SIP/2.0
Via: SIP/2.0/TCP client.example.net:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Romeo Montague <sip:romeo@example.net>;tag=8321234356
To: Juliet Capulet <sip:juliet@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@example.com
CSeq: 1 BYE
Content-Length: 0

The gateway transforms the SIP BYE into XMPP syntax.

<iq from='romeo@example.net/v3rsch1kk3l1jk'
    id='term1'
    to='juliet@example.com/t3hr0zny'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle'
          action='session-terminate'
          initiator='juliet@example.com/t3hr0zny'
          reasoncode='no-error'
          sid='a73sjjvkla37jfea'/>
</iq>

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.

<iq from='romeo@example.net/v3rsch1kk3l1jk'
    id='term1'
    to='juliet@example.com/t3hr0zny'
    type='result'/>

3.  SIP to Jingle

To follow.

4.  Security Considerations

Detailed security considerations for session management are given for SIP in [SIP] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) and for XMPP in [JINGLE] (Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, “Jingle,” June 2007.) (see also [XMPP] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.)).

5.  References

5.1. Normative References

5.2. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.