[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                    S. Veikkolainen
Internet-Draft                                                M. Isomaki
Intended status: Standards Track                                   Nokia
Expires: January 11, 2010                                  July 10, 2009


  Guidelines and Protocol Extensions for Combining SIP Based Real-time
 Media Sessions With XMPP Based Instant Messaging and Presence Service.
                 draft-veikkolainen-sip-voip-xmpp-im-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 January 11, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This memo defines guidelines and protocol extensions for combining
   Session Initiation Protocol (SIP) based real-time media sessions with



Veikkolainen & Isomaki  Expires January 11, 2010                [Page 1]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


   Extensible Messaging and Presence Protocol (XMPP) based instant
   messaging and presence services in a seamless manner.  This is
   accomplished by integration and protocol extension support in the
   endpoints, without requiring any changes in the SIP or XMPP server
   infrastructure.  It is even possible that SIP and XMPP services are
   offered by different service providers.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  Deployment scenarios and use cases . . . . . . . . . . . . . .  4
     3.1.  Deployment scenarios . . . . . . . . . . . . . . . . . . .  4
     3.2.  Use cases  . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Overview of operation  . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Endpoints engaged in XMPP conversation adding a SIP
           session  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Endpoints engaged in a SIP session adding an XMPP IM
           conversation . . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  Using XMPP presence for publishing and obtaining SIP
           contact address, media capabilities and availability . . .  9
   6.  Protocol extensions  . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Extensions to XMPP message stanza  . . . . . . . . . . . .  9
       6.1.1.  The <sip-contact> element  . . . . . . . . . . . . . .  9
       6.1.2.  The <sip-correlation> element  . . . . . . . . . . . . 10
     6.2.  Extensions to XMPP presence stanza . . . . . . . . . . . . 11
     6.3.  Extensions to SIP headers  . . . . . . . . . . . . . . . . 11
       6.3.1.  SIP XMPP-Thread header . . . . . . . . . . . . . . . . 11
       6.3.2.  SIP XMPP-Contact header  . . . . . . . . . . . . . . . 12
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Endpoint engaged in an IM session adds a voice/video
           component to the conversation  . . . . . . . . . . . . . . 14
     7.2.  Endpoint engaged in a SIP session adds an XMPP IM
           conversation . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     11.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21








Veikkolainen & Isomaki  Expires January 11, 2010                [Page 2]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


1.  Introduction

   Currently most standards-based Voice over IP (VoIP) deployments use
   Session Initiation Protocol (SIP).  In addition to providing basic
   voice service SIP has an extensive support for more advanced
   telephony features including interworking with the traditional Public
   Switched Telephone Network (PSTN).  SIP is also gaining popularity in
   the field of video communication.

   At the same time, the Extensible Messaging and Presence Protocol
   (XMPP) is enjoying widespread usage in instant messaging and presence
   services.  An interesting scenario arises when a SIP based voice and
   video service is combined together with an XMPP based instant
   messaging and presence service.

   This memo describes how SIP based real-time sessions and XMPP based
   IM and presence can be offered using existing server implementations.
   This memo also presents a set of requirements and protocol extensions
   for SIP User Agent and XMPP client implementations in order to offer
   a seamless usage experience when using SIP based VoIP with XMPP based
   instant messaging and presence.

   Combining SIP based real-time services with XMPP based presence and
   IM service can be accomplished in the endpoints; no support is needed
   in the service infrastructure.  It is even possible to achieve
   seamless integration when SIP and XMPP services are offered by
   different service providers.

   The main issues that need to be addressed when offering such combined
   services are identities and addressing.  SIP and XMPP both use a
   similar addressing scheme (based on "user@domain" structure) to
   identify users and endpoints but there are some subtle differences as
   well.  We do not assume any algorithmic correlation or translation
   between SIP and XMPP Universal Resource Identifiers (URI), even when
   they identify the same user or endpoint.  New protocol mechanisms are
   needed to tie together communication contexts that are based on the
   two protocols.

   We do not discuss how protocol translation through a gateway could be
   performed between the protocols; this is the subject of other work,
   see for example [I-D.saintandre-sip-xmpp-core].

   We focus on one-to-one communication only.  Multiparty use cases such
   as combining SIP voice conference with XMPP IM group chat are beyond
   the scope.

   The document structure is as follows: Section 2 presents the document
   conventions and definitions, Section 3 presents deployment scenarios



Veikkolainen & Isomaki  Expires January 11, 2010                [Page 3]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


   and use cases, Section 4 lists the requirements, Section 5 provides
   an overview of the protocol operation, Section 6 provides the
   definitions, and examples are presented in Section 7.


2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant
   implementations.

   The following definitions are used in this memo:

      Integrated endpoint is an implementation that combines the
      functionality of SIP User Agent and XMPP client and can offer its
      user a seamless user experience in the sense that a single UI and
      contact information can be user for voice and video communication
      using the SIP protocol as well as instant messaging and presence
      sharing using XMPP.  We assume an integrated endpoint is able to
      support SIP and XMPP protocol extensions defined in this memo.

      Separated endpoint refers to independent SIP User Agent and XMPP
      client implementations that are not aware of each other if they
      are used by the same user.  The users use SIP UA for voice and
      video, while using XMPP client for IM and presence.  It is assumed
      that a separated endpoint does not support any SIP or XMPP
      protocol extensions defined in this memo.


3.  Deployment scenarios and use cases

   This section presents the assumptions we make about SIP and XMPP
   deployments with respect to endpoints and server infrastructure.  We
   also enumerate the actual use cases that the combined service must
   accommodate for.

3.1.  Deployment scenarios

   We assume that the server infrastructures for SIP and XMPP are
   totally separated, thus no exchange of information is expected
   between these.  We do not even assume that SIP and XMPP services are
   offered by the same service provider.  This means that the user
   identities can belong to two different domains.  However, if the same
   service provider offers both SIP and XMPP service, it is recommended
   that the URIs sip:user@domain and xmpp:user@domain correspond to the
   same user.



Veikkolainen & Isomaki  Expires January 11, 2010                [Page 4]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


   We assume that the user initially only knows the contact address of
   the other user in one protocol space.  The contact address for the
   other protocol must be learned through this.

   We consider only cases where two integrated endpoints interact.  When
   an integrated endpoint communicates with a separated endpoint, normal
   SIP and XMPP procedures apply and no extensions defined in this memo
   are used.

3.2.  Use cases

   o  Two users who both use an integrated endpoint start an (XMPP) IM
      conversation.  After the exchange of initial messages, their UIs
      show that the other party is capable of (SIP) voice and/or video
      in addition to IM.  Either user can at any point add voice and/or
      video component to the conversation in such a way that it ends up
      in the same endpoint and conversation context where the IM
      exchange is already taking place.  (Note that for this use case
      the conversation initiator initially only needs to know the other
      user's XMPP user id.)

   o  Two users who both use an integrated endpoint start a (SIP) voice
      and/or video call.  As the call is established, their UIs show
      that the other party is capable for (XMPP) IM.  Either user can at
      any point add an IM component to the conversation in such a way
      that it ends up in the same endpoint and conversation context
      where the voice and/or video call is already taking place.  (Note
      that for this use case the caller initially only needs to know the
      other user's SIP user id.)

         It is possible to vary the two cases above so that one of the
         users initiates a "multimedia call" to the other one, i.e.  SIP
         voice and/or video and XMPP IM are all active from the start.
         Technically this happens according to the two-phased approach
         above, and it invisible from the end-user.

   o  A user of an integrated endpoint is able to publish her SIP voice
      and video related presence status as part of her XMPP presence.
      The status includes information such as user's SIP contact address
      (for the integrated endpoint), media capability and availability
      and whether the user is currently on the phone.  Another user of
      an integrated endpoint can see the presence status (assuming she
      is authorized for that) and based on that initiate calls.  For
      instance watcher's UI can now for certain show that the user on
      her roster is capable of receiving multimedia calls.  (Note that
      the watcher initially only needs to know the other user's XMPP
      user id.)




Veikkolainen & Isomaki  Expires January 11, 2010                [Page 5]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


      OPEN ISSUE: Is there a use case for discovering other user's XMPP
      identity based on her SIP identity without needing to establish a
      media session.  SIP OPTIONS would be one possibility for that (as
      we do not assume SIP presence support).


4.  Requirements

   This section presents the protocol requirements.

   REQ-1:  It must be possible for the sender of an XMPP message to
           include its SIP contact information within the message.  The
           contact information must allow the recipient to establish the
           SIP session such that the session is routed to the same
           endpoint which is hosting the XMPP conversation.  As
           including the same information in every message would create
           some overhead, it is desirable to be able to convey the
           contact only once per IM conversation/thread.

   REQ-2:  It must be possible for the caller to convey in the SIP
           session initiation information which allows the callee to
           correlate the session with an ongoing XMPP conversation.

   REQ-3:  It must be possible for the SIP User Agent Client and User
           Agent Server that establish a real-time media session to
           exchange their XMPP contact information so that either
           endpoint can at any time send XMPP messages to the other
           endpoint.

   REQ-4:  It must be possible for the sender to convey in the XMPP
           message information which allows the recipient to correlate
           the message with an ongoing SIP session.

   REQ-5:  It must be possible to include SIP real-time media related
           contact and status in XMPP presence information.  The
           information must contain at least SIP contact address to
           identify a user or a user agent instance, media capabilities
           and general availability status

      OPEN ISSUE: Should we define requirements related to error or
      corner cases here.  For instance what happens to communication
      attempts after the other party has closed the conversation
      context, e.g. a correlated XMPP message that is sent after the
      related SIP session is terminated.  Or a SIP INVITE that appears
      two days after the XMPP IM conversation was ended.

      NOTE: There is also an implicit requirement that we must take
      Session Border Controllers into account when defining how SIP User



Veikkolainen & Isomaki  Expires January 11, 2010                [Page 6]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


      Agents are able to identify an existing session between them in a
      common manner.


5.  Overview of operation

   Both SIP and XMPP allow registration of multiple endpoints using the
   same identifier, either a SIP AOR or XMPP Jabber ID (JID).  When two
   endpoints are engaged in an IM conversation, for example, and wish to
   add a voice component to the communication, it has to be ensured that
   the resulting SIP dialog is targeted to the same endpoint that is
   running the IM conversation.  Fortunately, both XMPP and SIP provide
   a mechanism for this.

   [I-D.ietf-sip-gruu] defines mechanisms for a SIP UA to obtain and use
   a Globally Routable User Agent (UA) URI, or GRUU.  A GRUU will route
   a call to a specific UA instance.  Unfortunately, not all SIP
   registrars support the optional GRUU mechanism.  In that case the SIP
   UA has not other option but to use its AOR in place of GRUU.

   In XMPP, a "full JID" consists of a name, domain and a resource
   identifier in the form of <name@domain/resource>.  The resource
   identifier can be used to identify a specific endpoint.

5.1.  Endpoints engaged in XMPP conversation adding a SIP session



                        Bob                    Alice
                         |                       |
                         |    IM session         |
                         |<=====================>|
                         |                       |
                         | (F1) INVITE           |
                         |---------------------->|
                         |                       |
                         | (F2) 200OK            |
                         |<----------------------|
                         |                       |
                         | (F3) ACK              |
                         |---------------------->|
                         |                       |
                         |  RTP media            |
                         |<=====================>|
                         |                       |


   This case starts by one endpoint (Bob) sending a message stanza to



Veikkolainen & Isomaki  Expires January 11, 2010                [Page 7]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


   another (Alice).  Bob includes a <thread> element in the message and
   chooses a unique value for it.  In his first message Bob also
   includes his SIP URI in <sip-contact> element, defined in
   Section 6.1.  If Bob has been able to obtain a GRUU from his
   registrar, he populates the <sip-contact> with that.  Otherwise a
   mere AOR is used.  When Alice receives Bob's SIP URI Alice stores it
   associated with the current <thread>.  When responding to Bob's
   messages Alice also includes a <thread> element and her SIP URI (GRUU
   or AOR) in <sip-contact>.  Upon receiving Alice's first message Bob
   stores Alice's SIP URI associated with the current <thread>.  In
   addition to containing a SIP URI, <sip-contact> also conveys the
   information whether an endpoint supports audio or video or both
   medias.  So, based on exchanged <sip-contact> elements, both
   endpoints now know each others SIP URIs and media capabilities.

   The same <thread> value is used in all further messages by both
   endpoints to keep track of the conversation.  As long as the <thread>
   value is unchanged, the <sip-contact> element need not be repeated,
   unless either endpoint's SIP GRUU changes for some reason.

   When either party wants to extend the IM conversation by adding SIP
   voice or video session, they address a SIP INVITE to the SIP URI
   learned in <sip-contact>.  If the <sip-contact> element contained a
   GRUU, it ensures that the INVITE will be routed to the correct
   endpoint.  The caller populates an XMPP-Thread header, defined in
   Section 6.3.1, in the INVITE with the value of <thread>.  The callee
   is thus able to correlate the SIP session to the IM conversation.
   The callee replays XMPP-Thread in responses to INVITE to indicate
   that the correlation was successful.

5.2.  Endpoints engaged in a SIP session adding an XMPP IM conversation

   In this case two endpoints first have a SIP voice or video session.
   They exchange their full JIDs within the session establishment: the
   caller (Bob) adds XMPP-Contact header, defined in Section 6.3.2, in
   INVITE populating it with his full JID.  XMPP-Contact also includes
   an opaque end-to-end identifier for the session common to both
   endpoints.  The callee (Alice) stores this information as part of the
   session state.  In 200 OK response to INVITE Alice includes similar
   XMPP-Contact header with her full JID, and replays the end-to-end
   session identifier.  Bob stores this information as part of his
   session state.  Both endpoints now know each others full JIDs and
   have a common reference to the session.

      OPEN ISSUE: Instead of defining XMPP-specific session identifier
      we could use SIP call-id as is.  However, there is a concern that
      call-id may be changed by SBCs en route is thus might not be a
      useful as a common reference for both User Agents.



Veikkolainen & Isomaki  Expires January 11, 2010                [Page 8]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


      [I-D.kaplan-sip-session-id] defines a Session-ID header that
      potentially could also be used.

   When either endpoint wants to send XMPP messages to each other, they
   address them to the full JID learned from XMPP-Contact header.  This
   ensures that the messages reach the correct endpoint.  In the very
   first message the sender also includes <sip-correlation> element,
   defined in Section 6.1, with the session identifier value learned
   from XMPP-Contact.  The recipient uses the value to correlate the
   message with the SIP session and echoes it back the first message it
   sends to indicate that the correlation was successful.

5.3.  Using XMPP presence for publishing and obtaining SIP contact
      address, media capabilities and availability

   SIP related presence information is encoded in XMPP presence schema
   as an extension.  It includes endpoints SIP URI (preferably GRUU but
   can be also AOR), media capabilities (audio, video), and availability
   (open, closed, busy).  Based on this information XMPP Presence
   watcher is able to initiate SIP voice and video sessions.


6.  Protocol extensions

   In this section we define protocol extensions to meet the
   requirements stated in the previous section.

6.1.  Extensions to XMPP message stanza

   The child elements of the message stanza can be extended with
   elements from other namespaces.  For the purposes of carrying a SIP
   identifier in the message stanza, we define two new elements, the
   <sip-contact> element and <sip-correlation> element.

6.1.1.  The <sip-contact> element

   The <sip-contact> element, qualified by urn:xmpp:sip-contact
   namespace, has one mandatory attribute, "target", which defines the
   target's SIP URI.  The format of the "target" attribute is an
   absoluteURI defined in [RFC3261].

   When an endpoint initiates an XMPP IM conversation, and wants to
   offer a possibility to later add a SIP real-time media session, it
   MUST include a <sip-contact> element as a child element in the first
   the <message> stanza it sends, and MUST add a <thread> element and
   populate its value according to [RFC3921].  The endpoint MUST include
   in the "target" attribute of the <sip-contact> element the SIP URI it
   wishes to be contacted at.  If the endpoint is aware of its GRUU, it



Veikkolainen & Isomaki  Expires January 11, 2010                [Page 9]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


   SHOULD use that as the value in the target attribute; otherwise it
   MAY use its AOR.

   The endpoint receiving an XMPP <message> stanza that includes
   <thread> and <sip-contact> elements MUST copy the <thread> element
   value to the first <message> stanza it sends back, as defined in
   [RFC3921], and MUST include a <sip-contact> element and set the
   "target" attribute value to the SIP URI it wishes to be contacted at.

   An endpoint MUST add its audio and video capabilities defined in
   [RFC3840] to the contact address in the "target" attribute, and MUST
   understand those capabilities if received from the other endpoint.
   An endpoint MAY add other media capabilities.

   When an endpoint receives a <sip-contact> element in a <message>
   stanza, it MUST store the value of the target attribute, and use it
   as the SIP URI in an INVITE request if the user of the endpoint would
   like to add a SIP session to the IM conversation context

   For example, a <sip-contact> element carrying a SIP Globally Routable
   Unique URI (GRUU) would be

     <sip-contact target='&#x55;sip:alice@example.com;
        gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
        audio;video&#x57'>

6.1.2.  The <sip-correlation> element

   In order to indicate that an XMPP IM conversation is related to an
   existing SIP session, we define a new element in the message stanza
   called <sip-correlation>.  The <sip-correlation>, qualified by the
   urn:xmpp:sip-correlation namespace, has one mandatory attribute,
   "value".

   The endpoint sending the <message> stanza MUST set the "value"
   attribute to the value of the correlation-value parameter of the SIP
   XMPP-Contact header, defined in Section 6.3.2.  The XMPP-Contact
   header is exchanged during the setup of the SIP session.

   An endpoint receiving a <message> stanza which includes a <sip-
   correlation> element MUST first compare the "from" attribute value of
   the <message> stanza to the XMPP JID in the contact-value of the
   XMPP-Contact header of its active SIP sessions.  If a matching SIP
   session is found, the endpoint then MUST compare the "value"
   attribute of the <sip-correlation> element to the correlation-value
   of the XMPP-Contact header of that SIP session.  If the "value"
   attribute matches to correlation-value of an XMPP-Contact header, the
   <message> stanza is correlated to that SIP session.  If the user



Veikkolainen & Isomaki  Expires January 11, 2010               [Page 10]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


   replies to the message, the values of the <thread> element and the
   "value" attribute of the <sip-correlation> element in the first reply
   MUST be the same as in the original message.  This indicates that the
   correlation was successful.  The correlation is valid as long as the
   messages are exchanged with the same <thread> value.

   As an example, consider a case where a SIP session was set up, and
   during that time one of the endpoints included a XMPP-Contact header
   with the correlation-value parameter set to the value 'xyz123'.  Now,
   when the same endpoint wishes to add an XMPP IM session, it would add
   a <sip-correlation> element in the message stanza carrying the same
   value in the "value" attribute:

      <sip-correlation value='xyz123'/>

      OPEN ISSUE: XML Schemas to be provided

6.2.  Extensions to XMPP presence stanza

   The XMPP presence stanza defined in [RFC3921] can be extended with
   any properly-namespaced child element.  We define a new optional
   element called <contact> which, qualified by the urn:xmpp:contact
   namespace, MAY appear as a child element in the presence stanza.

   The contact element SHOULD be set to the SIP address (GRUU or AOR)
   the endpoint wishes to be contacted at for further communication.

   Exact syntax and XML Schema of the correlation element is TBD.

6.3.  Extensions to SIP headers

6.3.1.  SIP XMPP-Thread header

   In order to indicate that the SIP dialog is related to an existing
   XMPP messaging session, we define a new SIP header, called XMPP-
   Thread.  The XMPP-Thread contains information that can be used by the
   terminating endpoint to correlate the SIP session establishment to an
   existing XMPP conversation.

   The endpoint sending a SIP INVITE request MUST include an XMPP-Thread
   header, and set its value to the value of the <thread> element used
   in the XMPP IM conversation.

   The endpoint receiving a SIP INVITE which includes an XMPP-Thread
   header acts as follows:






Veikkolainen & Isomaki  Expires January 11, 2010               [Page 11]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


   o  it first compares the Contact header value with all SIP GRUUs from
      <sip-contact> elements in active XMPP IM conversations, and unless
      a match is found,

   o  compares P-Asserted-Identity header value with all other SIP URIs
      from <sip-contact> elements in active XMPP IM conversations

   o  if a single match is found, the receiving endpoint MUST compare
      the value of the XMPP-Thread element to the <thread> element
      values of existing XMPP IM conversations the endpoint has active,
      and

   o  if the value matches, the SIP INVITE is correlated to the IM
      conversation.  The endpoint MUST copy the XMPP-Thread header to
      any of the 2xx series responses.

   Figure 1 defines support of XMPP-Contact header in SIP requests and
   responses, and extends Table 2 of [RFC3261].  MESSAGE, SUBCRIBE and
   NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined in
   [RFC3428], [RFC3265], [RFC3515], [RFC2976], [RFC3311], [RFC3262], and
   [RFC3903], respectively.

       Header field    where   proxy   ACK  BYE  CAN  INV  OPT  REG  MSG
       ------------    -----   -----   ---  ---  ---  ---  ---  ---  ---
       XMPP-Thread       R              -    -    -    o    -    -    -
       XMPP-Thread      2xx             -    -    -    o    -    -    -

                                       SUB  NOT  REF  INF  UPD  PRA  PUB
                                       ---  ---  ---  ---  ---  ---  ---
       XMPP-Thread       R              -    -    -    -    -    -    -
       XMPP-Thread      2xx             -    -    -    -    -    -    -

                   Figure 1: XMPP-Thread header support

   The syntax of the XMPP-Thread using augmented Backur-Naur Form (ABNF)
   [RFC5234] is defined as follows:

   XMPP-Thread         = "XMPP-Thread" HCOLON thread-value
   thread-value        = token
                         ;defined in RFC3261

6.3.2.  SIP XMPP-Contact header

   The XMPP-Contact header is used to carry the XMPP JID and an opaque
   token that can be used for correlation purposes.

   When an endpoint initiates a SIP session, and wants to offer the
   possibility to later add an XMPP IM conversation, it MUST include an



Veikkolainen & Isomaki  Expires January 11, 2010               [Page 12]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


   XMPP-Contact header in the initial SIP request.  The contact-value of
   the XMPP-Contact header MUST be set to the full XMPP JID the endpoint
   wishes to be contacted at, and the correlation-value SHOULD be set to
   the value of the Call-ID of the SIP session.  If the Call-ID cannot
   be used, the endpoint MUST select the correlation-value such that it
   fulfills the same uniqueness requirements defined for Call-ID in
   Section 8.1.1.4 of [RFC3261].

   An endpoint sending a 2xx series response to an INVITE that contains
   XMPP-Contact header MUST include a XMPP-Contact header in the
   response, MUST set the contact-value of the header to the full XMPP
   JID the endpoint wishes to be contacted at, and MUST copy the
   correlation-value from the INVITE to the 2xx response.

   The endpoint receiving a SIP request or response with an XMPP-Contact
   header, MUST store the value of the correlation-value as part of the
   session state in order to be able to later correlate an XMPP IM
   conversation with the SIP session.

   Figure 2 defines support of XMPP-Contact header in SIP requests and
   responses, and extends Table 2 of [RFC3261].  MESSAGE, SUBCRIBE and
   NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined in
   [RFC3428], [RFC3265], [RFC3515], [RFC2976], [RFC3311], [RFC3262], and
   [RFC3903], respectively.

       Header field    where   proxy   ACK  BYE  CAN  INV  OPT  REG  MSG
       ------------    -----   -----   ---  ---  ---  ---  ---  ---  ---
       XMPP-Contact      R              -    -    -    o    -    -    -
       XMPP-Contact     2xx             -    -    -    o    -    -    -

                                       SUB  NOT  REF  INF  UPD  PRA  PUB
                                       ---  ---  ---  ---  ---  ---  ---
       XMPP-Contact      R              -    -    -    -    -    -    -
       XMPP-Contact     2xx             -    -    -    o    -    -    -

                Figure 2: XMPP-Contact header field support

   The syntax of the XMPP-Contact using augmented Backur-Naur Form
   (ABNF) [RFC5234] is defined as follows:

XMPP-Contact        = "XMPP-Contact" HCOLON contact-value SEMI correlation-value
contact-value       = token
                      ;defined in RFC3261
correlation-value   =token







Veikkolainen & Isomaki  Expires January 11, 2010               [Page 13]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


7.  Examples

7.1.  Endpoint engaged in an IM session adds a voice/video component to
      the conversation



                        Bob                    Alice
                         |                       |
                         | (F1) <message>        |
                         |---------------------->|
                         |                       |
                         | (F2) <message>        |
                         |<----------------------|
                         |                       |
                         | (F3) INVITE           |
                         |---------------------->|
                         |                       |
                         | (F4) 200OK            |
                         |<----------------------|
                         |                       |
                         | (F5) ACK              |
                         |---------------------->|
                         |                       |
                         |  RTP media            |
                         |<=====================>|
                         |                       |


              SIP voice session added to XMPP IM conversation

   Bob and Alice are engaged in an XMPP IM session, when Bob would like
   to add voice/video component to the discussion.

   When Bob and Alice exchange message stanzas, they also include the
   SIP address they would like to be contacted at.  In this example, Bob
   is aware of its GRUU, while Alice is merely aware of her SIP AOR.
   Both include the SIP identifier in a contact element in the message
   stanza.












Veikkolainen & Isomaki  Expires January 11, 2010               [Page 14]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


      <message
          to='alice@example.net'
          from='bob@domain.com/Home'
          type='chat'
          xml:lang='en'>
        <body>Hi!</body>
        <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>

        <sip-contact target='&#x55;sip:bob@domain.com;gr=urn:
                 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
                 audio;video&#x57;'
                 xmlns=urn:xmpp:sip-contact/>
      </message>


              (F1) Bob sends a message stanza to
                     Alice

   In the above message, Bob includes his GRUU, and also the media
   capabilities Bob is capable of handling (audio and video).

   Alice sends back a message stanza containing her SIP contact
   information.

    <message
        to='bob@domain.com/Home'
        from='alice@example.net/4FIL45729'
        type='chat'
        xml:lang='en'>
      <body>Hello there!</body>
      <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>

      <sip-contact target='&#x55;sip:alice@example.net&#x57;audio;video'
               xmlns=urn:xmpp:sip-contact/>
    </message>


              (F2) Alice sends a message stanza to
                    Bob

   Bob then decides to add SIP voice call to the existing XMPP
   conversation.  He picks up Alice's contact information that Alice
   sent to him in a message stanza, and issues a SIP INVITE request to
   that URI.  The XMPP-Thread carries the value of the <thread> element.









Veikkolainen & Isomaki  Expires January 11, 2010               [Page 15]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


         INVITE sip:alice@example.net SIP/2.0
         Via: SIP/2.0/UDP ua-991.domain.com;branch=apo92hgb2k100
         Max-Forwards: 70
         To: Alice <sip:alice@example.com>
         From: Bob <sip:bob@domain.com>;tag=18593756298
         Call-ID: a84b4c76e66710@ua-991.domain.com
         CSeq: 314159 INVITE
         XMPP-Thread:e0ffe42b28561960c6b12b944a092794b9683a38
         Contact: <sip:bob@domain.com;gr=urn:
                 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
                 audio;video>
         Content-Type: application/sdp
         Content-Length: 142

         (SDP not shown)


                (F3) Bob sends a SIP INVITE to
                     Alice

   Alice responds with 200 OK accepting the session invitation request.
   Alice also includes the XMPP-Thread element to indicate that she has
   received the thread and successfully correlated the session
   invitation to the XMPP conversation.


         SIP/2.0 200 OK
         Via: SIP/2.0/UDP p1.example.com
            ;branch=z9hG4bKnashds8;received=192.0.2.3
         Via: SIP/2.0/UDP p1.domain.com
            ;branch=z9hG4bKnashds8;received=192.0.2.2
         Via: SIP/2.0/UDP ua-991.domain.com
            ;branch=apo92hgb2k100;received=192.0.2.1
         Max-Forwards: 70
         To: Alice <sip:alice@example.com>;tag=c09hh1lsn
         From: Bob <sip:bob@domain.com>;tag=18593756298
         Call-ID: a84b4c76e66710@ua-991.domain.com
         CSeq: 314159 INVITE
         XMPP-Thread:e0ffe42b28561960c6b12b944a092794b9683a38
         Contact: <sip:alice@192.0.2.4>
         Content-Type: application/sdp
         Content-Length: 131

         (SDP not shown)


      (F4) Alice accepts the session and sends a 200OK
                     to Bob

   Bob then sends a ACK as per normal SIP procedures.



Veikkolainen & Isomaki  Expires January 11, 2010               [Page 16]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


7.2.  Endpoint engaged in a SIP session adds an XMPP IM conversation



                        Bob                    Alice
                         |                       |
                         |                       |
                         | (F1) INVITE           |
                         |---------------------->|
                         |                       |
                         | (F2) 200OK            |
                         |<----------------------|
                         |                       |
                         | (F3) ACK              |
                         |---------------------->|
                         |                       |
                         |  RTP media            |
                         |<=====================>|
                         |                       |
                         | (F4) <message>        |
                         |---------------------->|
                         |                       |
                         | (F5) <message>        |
                         |<----------------------|


         XMPP IM conversation added to SIP voice
                       session

   Bob invites Alice to a SIP session.  In the INVITE request, Bob
   includes the XMPP-Contact header including his XMPP JID.


         INVITE sip:alice@example.net SIP/2.0
         Via: SIP/2.0/UDP ua-991.domain.com;branch=apo92hgb2k100
         Max-Forwards: 70
         To: Alice <sip:alice@example.com>
         From: Bob <sip:bob@domain.com>;tag=18593756298
         Call-ID: a84b4c76e66710@ua-991.domain.com
         CSeq: 314159 INVITE
         XMPP-contact:<xmpp:bob@domain.com/home>
                      ;a84b4c76e66710@ua-991.domain.com
         Contact: <sip:bob@domain.com;gr=urn:
                 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
                 audio;video>
         Content-Type: application/sdp
         Content-Length: 142

         (SDP not shown)



Veikkolainen & Isomaki  Expires January 11, 2010               [Page 17]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


                (F1) Bob sends a SIP INVITE to
                     Alice



         SIP/2.0 200 OK
         Via: SIP/2.0/UDP p1.example.com
            ;branch=z9hG4bKnashds8;received=192.0.2.3
         Via: SIP/2.0/UDP p1.domain.com
            ;branch=z9hG4bKnashds8;received=192.0.2.2
         Via: SIP/2.0/UDP ua-991.domain.com
            ;branch=apo92hgb2k100;received=192.0.2.1
         Max-Forwards: 70
         To: Alice <sip:alice@example.com>;tag=c09hh1lsn
         From: Bob <sip:bob@domain.com>;tag=18593756298
         Call-ID: a84b4c76e66710@ua-991.domain.com
         CSeq: 314159 INVITE
         XMPP-Contact:<xmpp:alice@example.com/4FIL45729>
                     ;a84b4c76e66710@ua-991.domain.com
         Contact: <sip:alice@192.0.2.4>
         Content-Type: application/sdp
         Content-Length: 131

         (SDP not shown)


      (F2) Alice accepts the session and sends a 200OK
                     to Bob


      <message
          to='alice@example.net'
          from='bob@domain.com/Home'
          type='chat'
          xml:lang='en'>
        <body>Hi!</body>
        <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
        <sip-correlation value='a84b4c76e66710@ua-991.domain.com'>
       </message>


                 (F4) Bob sends a message to
                     Alice

   Alice sends back a message stanza copying the sip-correlation value
   indicating the the correlation was successful.








Veikkolainen & Isomaki  Expires January 11, 2010               [Page 18]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


      <message
          to='bob@domain.com/Home'
          from='alice@example.net'
          type='chat'
          xml:lang='en'>
        <body>Hello there!</body>
        <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
        <sip-correlation value='a84b4c76e66710@ua-991.domain.com'>
      </message>


              (F5) Alice sends a message stanza to
                    Bob


8.  IANA Considerations

   TBD


9.  Security Considerations

   The contact and correlation information is sensitive and we need to
   prevent connection hijacking and impersonation.  If the contact
   information that is sent over one protocol is forged, the identity
   verification mechanism in the other no longer help as an attacker is
   able to assert the false identity.


10.  Acknowledgments

   TBD


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2976]  Donovan, S., "The SIP INFO Method", RFC 2976,
              October 2000.

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




Veikkolainen & Isomaki  Expires January 11, 2010               [Page 19]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, June 2002.

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, October 2002.

   [RFC3428]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
              and D. Gurle, "Session Initiation Protocol (SIP) Extension
              for Instant Messaging", RFC 3428, December 2002.

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, April 2003.

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

   [RFC3903]  Niemi, A., "Session Initiation Protocol (SIP) Extension
              for Event State Publication", RFC 3903, October 2004.

   [RFC3920]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 3920, October 2004.

   [RFC3921]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence",
              RFC 3921, October 2004.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

11.2.  Informative References

   [I-D.ietf-sip-gruu]
              Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
              (SIP)", draft-ietf-sip-gruu-15 (work in progress),
              October 2007.

   [I-D.kaplan-sip-session-id]
              Kaplan, H., "A Session Identifier for the Session
              Initiation Protocol (SIP)", draft-kaplan-sip-session-id-02
              (work in progress), March 2009.

   [I-D.saintandre-sip-xmpp-core]



Veikkolainen & Isomaki  Expires January 11, 2010               [Page 20]


Internet-Draft     SIP media with XMPP IM and presence         July 2009


              Saint-Andre, P., Houri, A., and J. Hildebrand,
              "Interworking between the Session Initiation Protocol
              (SIP) and the  Extensible Messaging and Presence Protocol
              (XMPP): Core", draft-saintandre-sip-xmpp-core-01 (work in
              progress), March 2009.


Authors' Addresses

   Simo Veikkolainen
   Nokia
   P.O. Box 407
   NOKIA GROUP, FI  00045
   Finland

   Phone: +358 50 486 4463
   Email: simo.veikkolainen@nokia.com


   Markus Isomaki
   Nokia
   P.O. Box 100
   NOKIA GROUP, FI  00045
   Finland

   Phone: +358 50 522 5984
   Email: markus.isomaki@nokia.com
























Veikkolainen & Isomaki  Expires January 11, 2010               [Page 21]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/