TOC 
Network Working GroupP. Saint-Andre
Internet-DraftXMPP Standards Foundation
Intended status: InformationalNovember 28, 2007
Expires: May 31, 2008 


Interworking between the Session Initiation Protocol (SIP) and the Jingle Extensions to the Extensible Messaging and Presence Protocol (XMPP)
draft-saintandre-jingle-sip-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 May 31, 2008.

Copyright Notice

Copyright © The IETF Trust (2007).

Abstract

This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of multimedia 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
    1.1.  Architectural Assumptions
    1.2.  Terminology
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




 TOC 

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 multimedia 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 multimedia 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. Consistent with existing specifications for mapping between XMPP and SIP for basic messaging and presence [XMPP‑SIMPLE] (Saint-Andre, P., “Basic Messaging and Presence Interworking between the Extensible Messaging and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE),” August 2007.) as well as text chat sessions [XMPP‑MSRP] (Saint-Andre, P., Gavita, E., Hossain, N., and S. Loreto, “Interworking between the Extensible Messaging and Presence Protocol (XMPP) and the Message Session Relay Protocol (MSRP),” November 2007.), this document describes a bi-directional protocol mapping for use by gateways that enable the exchange of multimedia signalling messages between systems that implement the XMPP Jingle extensions and those that implement SIP.



 TOC 

1.1.  Architectural Assumptions

Protocol translation between Jingle and SIP could occur in a number of different entities, depending on the architecture of presence and messaging deployments. For example, protocol translation could occur within a multi-protocol server, within a multi-protocol client, or within a gateway that acts as a dedicated protocol translator.

This document assumes that the protocol translation will occur within a gateway. (This assumption not meant to discourage protocol translation within multi-protocol clients or servers; instead, this assumption is followed mainly to clarify the discussion and examples so that the protocol translation principles can be more easily understood and can be applied by client and server implementors with appropriate modifications to the examples and terminology.) Specifically, we assume that the protocol translation will occur within an "Jingle-to-SIP gateway" that translates Jingle syntax and semantics on behalf of an XMPP service when communicating with SIP services and/or within a "SIP-to-Jingle gateway" that translates SIP syntax and semantics when communicating with XMPP services.

We further assume that protocol translation will occur within a gateway in the source domain, so that information generated by the user of an XMPP service will be translated by a gateway within the trust domain of that XMPP service, and information generated by the user of a SIMPLE service will be translated by a gateway within the trust domain of that SIP service.

An architectural diagram for a typical gateway deployment is shown below, where the entities have the following significance and the "#" character is used to show the boundary of a trust domain:

#####################################################################
#                               #                                   #
#         +-- s2j.example.net---#------------- example.com          #
#         |                     #               |     |             #
#  example.net -----------------#--- j2s.example.com  |             #
#       |                       #                     |             #
#       |                       #                     |             #
#  romeo@example.net            #               juliet@example.com  #
#                               #                                   #
#####################################################################


 TOC 

1.2.  Terminology

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].



 TOC 

2.  Jingle to SIP



 TOC 

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:



 TOC 

2.2.  Syntax Mappings



 TOC 

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/orchard'
    id='jingle1'
    to='juliet@example.com/balcony'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle'
          action='session-initiate'
          initiator='romeo@example.net/orchard'
          responder='juliet@example.com/balcony'
          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]        |
+-------------------+-----------------+


 TOC 

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.).



 TOC 

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.).



 TOC 

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.



 TOC 

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.).



 TOC 

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.



 TOC 

2.3.1.  Basic Voice Chat

The protocol flow for a basic voice chat between a Jingle user and a SIP user through a gateway is illustrated in the following diagram.

Juliet   ...Jingle...   Gateway    ...SIP...     Romeo
  |                        |                       |
  | session-initiate       |                       |
  |----------------------->| INVITE                |
  | IQ-result (ack)        |---------------------->|
  |<-----------------------| 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                |
  |                        |---------------------->|
  |                        |                       |


 TOC 

3.  SIP to Jingle

To follow.



 TOC 

4.  Security Considerations

To follow.



 TOC 

5.  References



 TOC 

5.1. Normative References

[ICE] Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[JINGLE] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, “Jingle,” XSF XEP 0166, June 2007.
[JINGLE-AUDIO] Ludwig, S., Saint-Andre, P., Egan, S., and R. McQueen, “Jingle Audio via RTP,” XSF XEP 0167, November 2007.
[JINGLE-ICE] Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., and S. Egan, “Jingle ICE-UDP Transport Method,” XSF XEP 0176, November 2007.
[JINGLE-UDP] Beda, J., Saint-Andre, P., Ludwig, S., Hildebrand, J., and S. Egan, “Jingle Raw UDP Transport,” XSF XEP 0177, November 2007.
[JINGLE-VIDEO] Saint-Andre, P. and M. Chen, “Jingle Video via RTP,” XSF XEP 0180, November 2007.
[RTP-AVP] Schulzrinne, H. and S. Casner, “RTP Profile for Audio and Video Conferences with Minimal Control,” STD 65, RFC 3551, July 2003 (TXT, PS, PDF).
[SDP] Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” RFC 4566, July 2006.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002.
[TERMS] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997.
[XMPP] Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” RFC 3920, October 2004.


 TOC 

5.2. Informative References

[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML).
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” STD 64, RFC 3550, July 2003 (TXT, PS, PDF).
[TCP] Postel, J., “Transmission Control Protocol,” STD 7, RFC 793, September 1981.
[UDP] Postel, J., “User Datagram Protocol,” STD 6, RFC 768, August 1980.
[XMPP-MSRP] Saint-Andre, P., Gavita, E., Hossain, N., and S. Loreto, “Interworking between the Extensible Messaging and Presence Protocol (XMPP) and the Message Session Relay Protocol (MSRP),” draft-saintandre-xmpp-msrp-00 (work in progress), November 2007.
[XMPP-SIMPLE] Saint-Andre, P., “Basic Messaging and Presence Interworking between the Extensible Messaging and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE),” draft-saintandre-xmpp-simple-10 (work in progress), August 2007.


 TOC 

Author's Address

  Peter Saint-Andre
  XMPP Standards Foundation
  P.O. Box 1641
  Denver, CO 80201
  USA
Email:  stpeter@jabber.org
URI:  https://stpeter.im/


 TOC 

Full Copyright Statement

Intellectual Property

Acknowledgment