| TOC |
|
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 December 27, 2008.
This document defines a bi-directional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).
1.
Introduction
1.1.
Overview
1.2.
Scope
1.3.
Formal and Informal Sessions
1.4.
Gateway Heuristics
1.5.
Connection Maintenance
1.6.
Acknowledgements
1.7.
Discussion Venue
2.
XMPP Formal Chat Session to MSRP
2.1.
Initiating a Formal Session
2.2.
Accepting a Formal Session
2.3.
Exchanging Messages
2.4.
Terminating a Formal Session
2.5.
Cancelling the Negotiation
2.6.
Rejecting a Formal Session
3.
XMPP Informal Session to MSRP
4.
MSRP to XMPP Formal Session
4.1.
Initiating a Session
4.2.
Accepting a Session
4.3.
Completing the Transaction
4.4.
Exchanging Messages
4.5.
Terminating a Session
4.6.
Cancelling the Transaction
4.7.
Rejecting the Transaction
4.8.
Session Negotiation Fails
5.
MSRP to XMPP Informal Session
6.
Security Considerations
7.
References
7.1.
Normative References
7.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
| TOC |
Both 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.) and the Extensible Messaging and Presence Protocol [XMPP] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) can be used for the purpose of one-to-one text chat over the Internet. To ensure interworking between these technologies, it is important to define bi-directional protocol mappings.
The architectural assumptions underlying such protocol mappings are provided in [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.), including mapping of addresses and error conditions. Mappings for single instant messages (sometimes called "pager-mode" messaging) are provided in [SIP‑XMPP‑IM] (Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging,” January 2008.). This document specifies mappings for one-to-one text chat sessions (sometimes called "session-mode" messaging); in particular, this document specifies mappings between XMPP and the Message Session Relay Protocol [MSRP] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.). Mapping of multi-user text chat (sometimes called "groupchat") is out of scope for this document.
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].
| TOC |
Both XMPP and SIP/SIMPLE technologies enable end users to send "instant messages" to other end users. The term "instant message" usually refers to messages sent between two end-users for delivery in close to real time (rather than messages that are stored and forwarded to the intended recipient upon request). Generally, there are three kinds of instant messages:
This document covers only scenario #2 above for converting XMPP messages of type "chat" to and from their corresponding SIP INVITE and MSRP message types on the SIP/SIMPLE side.
As in [SIP‑XMPP‑IM] (Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging,” January 2008.) and related documents, the approach taken here is to directly map syntax and semantics from one protocol to another. The mapping described herein depends on the protocols defined in the following specifications:
| TOC |
The traditional model for a one-to-one chat "session" in XMPP is for a user to simply send a message of type "chat" to a contact, without any formal negotiation of session parameters; the contact would then reply to the message, and the sum total of such messages exchanged during a defined period of time can be considered a chat session. This informal approach to chat sessions in XMPP can be mapped both to SIP pager-mode messaging using the SIP MESSAGE method (as documented in [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 to an MSRP chat session. How a gateway chooses to map the XMPP chat session to the SIP side is a matter of the implementation, although guidelines are provided under Section 1.4 (Gateway Heuristics).
However, in XMPP it is also possible to formally request a chat session and negotiate its parameters (e.g., security, privacy, message logging) before beginning the session and exchanging messages. The protocol for doing so is defined in [SSN] (Paterson, I. and P. Saint-Andre, “Stanza Session Negotiation,” January 2008.). In this case, the XMPP chat session should be translated into an MSRP session.
This document covers the mapping of both informal and formally-negotiated XMPP chat sessions into MSRP sessions, and from MSRP sessions into XMPP informal and formal sessions.
| TOC |
When a gateway receives a chat message or chat session request intended for a recipient that is registered with the gateway itself or has an account on a local service, it SHOULD adhere to the following process in determining whether to (1) initiate a formal chat session with the recipient, (2) initiate an informal chat session with the recipient, or (3) return an error to the sender.
The methods by which a gateway determines support for various capabilities are protocol-specific. For XMPP a gateway SHOULD use the Service Discovery extension defined in [DISCO] (Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-Andre, “Service Discovery,” June 2008.) or, if it receives presence information from the XMPP endpoint, use the Entity Capabilities extension defined in [CAPS] (Hildebrand, J., Saint-Andre, P., Tronçon, R., and J. Konieczny, “Entity Capabilities,” February 2008.). For MSRP a gateway SHOULD use the Session Description Protocol defined in [SDP] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) in conjunction with a high-level protocol that provides a capability query, such as the SIP OPTIONS request defined 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.).
| TOC |
XMPP makes use of long-lived TCP connections. If mobility affecting Layer 3 causes a dropped connection, the connection must be re-established. If mobility preserves the IP address, the TCP connection will be dropped. Any TLS session and SASL associations must be re-established if the TCP connection is dropped. XMPP binds directly to TCP in the core specification, so the TCP session must remain open for the entire duration of the chat session. The XMPP Standards Foundation does define protocol extensions enabling transport of XMPP traffic over HTTP (refer to [BOSH] (Paterson, I., Smith, D., and P. Saint-Andre, “Bidirectional-streams Over Synchronous HTTP (BOSH),” February 2007.) and [BOSH‑XMPP] (Paterson, I., “XMPP Over BOSH,” June 2007.)), so that individual messages are carried using HTTP and are more robust in environments such as mobile networks, allowing for better recovery if a TCP session is broken.
SIMPLE is similar when using MSRP. The Message Session Relay Protocol [MSRP] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) is a protocol for transmitting instant messages (IM) in the context of a session. The protocol specification describes how the session can be negotiated and established with an offer or answer (see [OFFER] (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.)) using the Session Description Protocol [SDP] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.). In SIMPLE, this exchange is carried using SIP as the signaling protocol. After the TCP connection is established, if it fails for any reason, then an MSRP endpoint MAY choose to re-create such a session using a new SDP exchange in a SIP re-INVITE. SIMPLE also uses the MESSAGE request type for transporting instant messaging outside the context of a session. The MESSAGE request is sent inside the signaling path without establishing any dedicated connection.
| TOC |
Some text in this document was borrowed from [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 from [SSN] (Paterson, I. and P. Saint-Andre, “Stanza Session Negotiation,” January 2008.).
| TOC |
The authors welcome discussion and comments related to the topics presented in this document. The preferred forum is the <sip-xmpp@xmpp.org> mailing list, for which archives and subscription information are available at <http://mail.jabber.org/mailman/listinfo/sip-xmpp>.
| TOC |
This section describes how to map an XMPP "formal session" to an MSRP session.
The XMPP formal session is based on the protocol described in [SSN] (Paterson, I. and P. Saint-Andre, “Stanza Session Negotiation,” January 2008.), which enables the initiation, renegotiation, and termination of a formal chat session on the XMPP side. This approach maps to the semantic of the SIP INVITE and BYE methods.
XMPP User GW SIP User
| | |
|(F1) (XMPP) Stanza session request |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
|(F4) (XMPP) Stanza session acceptance |
|<-------------------------| |
| |(F5) (SIP) ACK |
| |------------------------->|
|(F6) (XMPP) Stanza session completion |
|------------------------->| |
|(F7) (XMPP) A chat message |
|------------------------->| |
| |(F8) (MSRP) SEND |
| |------------------------->|
| |(F9) (MSRP) A reply |
|(F10) (XMPP) A reply | |
|<-------------------------| |
| | |
. . .
. . .
. . .
| | |
|(F11) (XMPP) Stanza session termination |
|------------------------->| |
| |(F12) (SIP) BYE |
| |------------------------->|
| |(F13) (SIP) 200 OK |
| |<-------------------------|
|(F14) (XMPP) Termination acknowledgment |
|<-------------------------| |
| TOC |
When the XMPP user ("Juliet") wants to initiate a negotiated session with a SIP user ("Romeo"), she sends a <message/> stanza to Romeo containing a <feature/> child qualified by the 'http://jabber.org/protocol/feature-neg' namespace. The <message/> stanza must not contain a <body/> child (as specified in [XMPP‑IM] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.)), since that child element is used for human-readable text. The <message/> stanza type should be "normal". The stanza MUST contain a <thread/> element for tracking purposes (where the newly-generated ThreadID is unique to the proposed session). The encapsulated data form MUST contain a FORM_TYPE field whose type is "hidden" and whose value is "urn:xmpp:ssn"; it must also contain a boolean field named "accept".
The XMPP user may request a session with a specific resource of the contact. However in this document the resource identifier will be ignored and discarded for cross-system interworking.
Example: (F1) Juliet starts a formal session
<message from='juliet@example.com'
to='romeo@example.net'
type='normal'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='form'>
<title>Open chat with Juliet?</title>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:ssn</value>
</field>
<field label='Accept this session?'
type='boolean'
var='accept'>
<value>true</value>
<required/>
</field>
<field label='Primary written language of the chat'
type='list-single'
var='language'>
<value>en</value>
<option label='English'><value>en</value></option>
<option label='Italiano'><value>it</value></option>
</field>
<field label='XHTML formatting'
type='list-single'
var='http://jabber.org/protocol/xhtml-im'>
<value>may</value>
<option label='Allow XHTML formatting'>
<value>may</value>
</option>
<option label='Disallow XHTML formatting'>
<value>mustnot</value>
</option>
</field>
</x>
</feature>
</message>
Upon receiving such a session request, the XMPP server to which Juliet has authenticated attempts to deliver the request to a local user or attempts to route the request to the foreign domain that services the hostname in the 'to' attribute. Naturally, in this document we assume that the hostname in the 'to' attribute is an IM-aware SIP service hosted by a separate server.
As specified in [XMPP‑IM] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.), the XMPP server needs to determine the identity of the foreign domain, which it does by performing one or more [DNS‑SRV] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) lookups. For message stanzas, the order of lookups recommended by [XMPP‑IM] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.) is to first try the "_xmpp-server" service as specified in [XMPP] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) and to then try the "_im" service as specified in [IMP‑SRV] (Peterson, J., “Address Resolution for Instant Messaging and Presence,” August 2004.). Here we assume that the first lookup will fail but that the second lookup will succeed and return a resolution "_im._simple.example.net.", since we have already assumed that the example.net hostname is running a SIP instant messaging service. (Note: The XMPP server may have previously determined that the foreign domain is a SIMPLE server, in which case it would not need to perform the SRV lookups; the caching of such information is a matter of implementation and local service policy, and is therefore out of scope for this document.)
Once the XMPP server has determined that the foreign domain is serviced by a SIMPLE server, it must determine how to proceed. We here assume that the XMPP server contains or has available to it an XMPP-MSRP gateway. The XMPP server would then deliver the message stanza to the XMPP-MSRP gateway.
The XMPP-MSRP gateway is then responsible for translating the XMPP session into an MSRP session.
Example: (F2) Juliet starts a formal session (SIP transformation)
INVITE sip:romeo@example.net SIP/2.0 To: <sip:romeo@example.net> From: <sip:juliet@example.com>;tag=786 Subject: Open chat with Juliet? Call-ID: 711609sa Content-Type: application/sdp c=IN IP4 gw.example.net m=message 7654 TCP/MSRP * a=accept-types:text/plain a=lang:en a=lang:it a=path:msrp://gw.example.net:7654/jshA7weztas;tcp
There is no direct mapping for the MSRP URIs. In fact MSRP URIs identify a session of instant messages at a particular device; they are ephemeral and have no meaning outside the scope of that session. The authority component of the MSRP URI MUST contain the XMPP-MSRP gateway hostname or numeric IP address and an explicit port number.
Native XMPP messages as described in [XMPP‑IM] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.) supports text (i.e., UTF-8) only. However, there exists an XMPP extension for XHTML-formatted messges, as defined by the XHTML-IM integration set specified in [XHTML‑IM] (Saint-Andre, P., “XHTML-IM,” August 2007.). Unless the use of XHTML-formatted messages is supported by the endpoints or negotiated during session establishment, the "accept-types" attribute that follows an MSRP media line SHOULD indicate "text/plain" as the only media-type that is acceptable to the endpoint; if XHTML is supported or negotiated, the "accept-types" attribute MAY also indicate a media-type of "text/html". (Note: The XHTML-IM integration set supports only a subset of XHTML formatting; it is the responsibility of the gateway to map between full XHTML and XHTML-IM.)
As specified in [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.), the mapping of XMPP syntax elements to SIP and SDP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined.)
Table 1: Message syntax mapping from XMPP to SIP/SDP
+-----------------------------+-----------------------------+ | XMPP Element or Attribute | SIP Header or SDP Contents | +-----------------------------+-----------------------------+ | <thread/> | Call-ID | | from | From | | to | To | | <title/> | Subject | | xml:lang | a=lang:<language tag> | | - | a=accept-types:text/plain | +-----------------------------+-----------------------------+
| TOC |
Here we assume that the SIP user agent that receives the SIP invitation (containing an offered session description that includes a session of MSRP) accepts the invitation and includes an answer session description that acknowledges the choice of media.
Example: (F3) Romeo accepts the request
SIP/2.0 200 OK To: <sip:romeo@example.net>;tag=087js From: <sip:juliet@example.com>;tag=786 Call-ID: 711609sa Content-Type: application/sdp c=IN IP4 example.net m=message 12763 TCP/MSRP * a=accept-types:text/plain a=lang:it a=path:msrp://example.net:12763/kjhd37s2s20w2a;tcp
Upon receiving such a response, the SIMPLE server or associated MSRP-XMPP gateway SHOULD remember that this is a response to a SIP transaction related to an XMPP-MSRP translation, based on the SIP Call-ID (which is functionally equivalent to the XMPP <thread/>). The gateway is responsible for translating the response into an XMPP message stanza and routing it from the SIP user back to the XMPP user.
The MSRP-XMPP gateway MUST include in the response translation values for all the fields that the XMPP request indicated are required.
Example: (F4) Romeo accepts the request (XMPP translation)
<message from='romeo@example.net'
to='juliet@example.com'
type='normal'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>true</value></field>
<field var='language'><value>it</value></field>
</x>
</feature>
</message>
The gateway MUST also send a SIP ACK to the SIP user.
Example: (F5) Gateway sends ACK to Romeo's UA
ACK sip:romeo@example.net SIP/2.0 To: <sip:romeo@example.net>;tag=087js From: <sip:juliet@example.com>;tag=786 Call-ID: 711609sa
If Romeo accepted the session, Juliet MUST either complete or cancel the stanza session negotiation. The user's client SHOULD verify that the selected values of the fields are acceptable before completing the stanza session negotiation -- and confirming that the session is open -- by replying with the form 'type' attribute set to 'result'. The form MUST contain the FORM_TYPE field and the "accept" field set to "1" or "true".
Example: (F6) Juliet completes negotiation
<message from='juliet@example.com'
to='romeo@example.net'
type='normal'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>true</value></field>
</x>
</feature>
</message>
Upon receiving such a stanza completing the session negotiation, the XMPP server MUST NOT send any confirmation to the SIP side; instead, it MUST route the acceptance to the gateway.
The session is now open and the parties can proceed to exchanging messages.
| TOC |
Once the session is created, the endpoints can exchange an unbounded number of messages.
The XMPP 'id' attribute is not required in the protocol and there is no way to enforce its use for messages. It is RECOMMENDED to include it as a negotiable item in the SSN negotiation, via the "message-ids" field. However, it is possible that the 'id' will not be present within the <message/> stanza; in this case the XMPP-MSRP gateway MUST generate a new unique Message-ID.
If the XMPP user has not explicitly requested message receipts during the negotiation, it is RECOMMENDED that the gateway shall insert a Failure-Report header field value of "no" during the creation of a SEND request. The XMPP user can include a request for message receipts using the Message Receipts XMPP protocol extension [RECEIPTS] (Saint-Andre, P. and J. Hildebrand, “Message Receipts,” September 2007.); use of this extension can be negotiated via the "urn:xmpp:receipts" field during SSN negotiation.
The mapping of XMPP syntax elements to MSRP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined.)
Table 2: Message syntax mapping from XMPP Message to MSRP
+-----------------------------+-----------------------------+ | XMPP Element or Attribute | MSRP Header | +-----------------------------+-----------------------------+ | to | To-Path | | from | From-Path | | <body/> | body of the SEND request | | - | Content-Type: text/plain | | id | Message-ID | +-----------------------------+-----------------------------+
The following examples show an exchange of messages.
Example: (F7) Juliet sends an XMPP message
<message from='juliet@example.com'
to='romeo@example.net'
type='chat'>
<thread>711609sa</thread>
<body>Art thou not Romeo, and a Montague?</body>
</message>
Example: (F8) Gateway transforms XMPP message to MSRP
MSRP a786hjs2 SEND To-Path: msrp://example.net:12763/kjhd37s2s20w2a;tcp From-Path: msrp://gw.example.net:7654/jshA7weztas;tcp Message-ID: 87652491 Byte-Range: 1-25/25 Content-Type: text/plain Art thou not Romeo, and a Montague? -------a786hjs2$
Upon receiving the SEND request, if the request either contains a Failure-Report header field value of "yes" or does not contain a Failure-Report header at all, Romeo's client MUST immediately generate and send a response.
MSRP d93kswow 200 OK To-Path: msrp://gw.example.net:7654/jshA7weztas;tcp From-Path: msrp://example.net:12763/kjhd37s2s20w2a;tcp -------d93kswow$
Romeo can then send a reply using his MSRP user agent.
Example: (F9) Romeo sends a reply
MSRP a786hjs2 SEND To-Path: msrp://gw.example.net:7654/jshA7weztas;tcp From-Path: msrp://example.net:12763/kjhd37s2s20w2a;tcp Message-ID: 87652491 Byte-Range: 1-25/25 Content-Type: text/plain Neither, fair saint, if either thee dislike. -------a786hjs2$
The MSRP-XMPP gateway would then transform that message into appropriate XMPP syntax for routing to the intended recipient.
Example: (F10) Gateway transforms MSRP message to XMPP
<message from='romeo@example.net'
to='juliet@example.com'
type='chat'>
<thread>711609sa</thread>
<body>Neither, fair saint, if either thee dislike.</body>
</message>
Note: The size of the XML character data of an XMPP message is not limited by the protocol, but is sometimes limited in deployment. However messages sent using MSRP can be delivered in several SEND requests, so when the XMPP-MSRP gateway receives a message longer then 2048, it is STRONGLY RECOMMENDED it delivers this message using as few chunks (at least 2048 octets long) as possible.
| TOC |
If Juliet decides to terminate the negotiated chat session, her client sends a <message/> stanza to Romeo containing a data form of type "submit". The <message/> stanza MUST contain a <thread/> element with the same XML character data as the original initiation request. The data form containing a boolean field named "terminate" set to a value of "1" or "true".
Example: (F11) Juliet terminates the chat session
<message from='juliet@example.com'
to='romeo@example.net'
type='normal'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='terminate'>
<value>1</value>
</field>
</x>
</feature>
</message>
Upon receiving such stanza terminating the chat session, the gateway terminates the SIP session by sending a SIP BYE to tear down the MSRP session with Romeo's client. Romeo's SIP client then responds with a 200 OK.
Example: (F12) Juliet terminates the chat session (SIP translation)
BYE romeo@example.net sip: SIP/2.0 Max-Forwards: 70 From: <sip:juliet@example.com>;tag=786 To: <sip:romeo@example.net>;tag=087js Call-ID: 711609sa Cseq: 1 BYE Content-Length: 0
Example: (F13) Romeo acknowledges termination
SIP/2.0 200 OK From: <sip:juliet@example.com>;tag=786 To: <sip:romeo@example.net>;tag=087js Call-ID: 711609sa CSeq: 1 BYE Content-Length: 0
Upon receiving the 200 OK, the gateway acknowledges the termination of the chat session on the XMPP side by sending a <message/> containing a data form of type "result", and the value of the "terminate" field set to "1" or "true". The client must mirror the <thread/> value it received.
Example: (F14) Romeo acknowledges termination (XMPP translation)
<message from='romeo@example.net'
to='juliet@example.com'
type='normal'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='terminate'>
<value>1</value>
</field>
</x>
</feature>
</message>
| TOC |
If Romeo accepted the session but Juliet decides to cancel the stanza session negotiation, the flow is as follows.
XMPP User GW SIP User
| | |
|(F1) (XMPP) Stanza session request |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
|(F4) (XMPP) Stanza session acceptance |
|<-------------------------| |
| |(F5) (SIP) ACK |
| |------------------------->|
|(F6) (XMPP) Stanza session cancelling |
|------------------------->| |
| |(F7) (SIP) BYE |
| |------------------------->|
| |(F8) (SIP) 200 OK |
| |<-------------------------|
That is, Juliet's client shall reply with a data form containing the FORM_TYPE field and the "accept" field set to "0" or "false":
Example: (F6) User cancels stanza session negotiation
<message from='juliet@example.com'
to='romeo@example.net'
type='normal'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'>
<value>0</value>
</field>
</x>
</feature>
</message>
Upon receiving such stanza cancelling the session negotiation, the XMPP-MSRP gateway MUST send a SIP BYE. Once the XMPP-MSRP receives the 200 OK, the internal session data is removed and the session is officially cancelled also in the gateway.
| TOC |
A common scenario occurs when the SIP UA is currently unwilling or unable to accept a formal session, in which case the flow is as follows.
XMPP User GW SIP User
| | |
|(F1) (XMPP) Stanza session request |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 4xx/6xx |
| |<-------------------------|
|(F4) (XMPP) Stanza session decline |
|<-------------------------| |
Here the SIP UA declining an offer contained in an INVITE SHOULD return a 4xx or a 6xx response, such as 406 Not Acceptable or 603 Decline. Such a response SHOULD include a Warning header field value explaining why the offer was rejected.
Example: (F3) SIP user declines offer and specifies reason (SIP)
SIP/2.0 603 Decline From: <sip:juliet@example.com>;tag=786 To: <sip:romeo@example.net>;tag=087js Call-ID: 711609sa Warning: I'm busy! Content-Length: 0
Upon receiving the error response for the SIP INVITE, the XMPP-MSRP gateway shall send a "Session Reject" message back to the XMPP Client. This message contains a data form that MUST contain the FORM_TYPE field and the "accept" field set to "0" or "false". It is RECOMENDED that the form does not contain any other field even if the request indicated they are required. The client MAY include a reason in the <body/> child of the <message/> stanza. The content of the Warning header field present in the SIP response SHOULD be mapped to a "reason" field in the data form. If the Warning header is not present then the descriptive phrase of the SIP response can be used.
Example: (F4) SIP user declines offer and specifies reason (XMPP translation)
<message from='romeo@example.net'
to='juliet@example.com'
type='normal'>
<thread>711609sa</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'>
<value>0</value>
</field>
<field var='reason'>
<value>I'm busy!</value>
</field>
</x>
</feature>
</message>
| TOC |
In XMPP, the "informal session" approach is to simply send someone a <message/> of type "chat" without starting any session negotiation ahead of time (as described in [XMPP‑IM] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.)). The XMPP "informal session" approach maps very well into a SIP MESSAGE request, as described in [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.). However, the XMPP informal session approach can also be mapped to MSRP if the gateway maintains additional state.
The order of events is as follows.
XMPP User GW SIP User
| | |
|(F1) (XMPP) Chat message | |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
| |(F4) (SIP) ACK |
| |------------------------->|
| |(F5) (MSRP) SEND |
| |------------------------->|
| |(F6) (MSRP) A reply |
|(F7) (XMPP) A reply | |
|<-------------------------| |
| | |
. . .
. . .
. . .
| | |
| |(F8) (SIP) BYE |
| |<-------------------------|
| |(F9) (SIP) 200 OK |
| |------------------------->|
| | |
First the XMPP user would generate an XMPP chat message.
Example: (F1) Juliet sends an XMPP message
<message from='juliet@example.com'
to='romeo@example.net'
type='chat'>
<thread>711609sa</thread>
<body>Art thou not Romeo, and a Montague?</body>
</message>
The local gateway at the SIMPLE server would then determine if Romeo supports MSRP. If so, the gateway would initiate an MSRP session with Romeo on Juliet's behalf.
Example: (F2) Gateway starts a formal session on behalf of Juliet
INVITE sip:romeo@example.net SIP/2.0 To: <sip:romeo@example.net> From: <sip:juliet@example.com>;tag=786 Subject: Open chat with Juliet? Call-ID: 711609sa Content-Type: application/sdp c=IN IP4 gw.example.net m=message 7654 TCP/MSRP * a=accept-types:text/plain a=lang:en a=lang:it a=path:msrp://gw.example.net:7654/jshA7weztas;tcp
Here we assume that Romeo accepts the MSRP session request.
Example: (F3) Romeo accepts the request
SIP/2.0 200 OK To: <sip:romeo@example.net>;tag=087js From: <sip:juliet@example.com>;tag=786 Call-ID: 711609sa Content-Type: application/sdp c=IN IP4 example.net m=message 12763 TCP/MSRP * a=accept-types:text/plain a=lang:it a=path:msrp://example.net:12763/kjhd37s2s20w2a;tcp
The gateway then acks the session acceptance on behalf of Juliet.
Example: (F4) Gateway sends ACK to Romeo's UA
ACK sip:romeo@example.net SIP/2.0 To: <sip:romeo@example.net>;tag=087js From: <sip:juliet@example.com>;tag=786 Call-ID: 711609sa
The gateway then transforms the original XMPP chat message into MSRP.
Example: (F5) Gateway transforms XMPP message to MSRP
MSRP a786hjs2 SEND To-Path: msrp://example.net:12763/kjhd37s2s20w2a;tcp From-Path: msrp://gw.example.net:7654/jshA7weztas;tcp Message-ID: 87652491 Byte-Range: 1-25/25 Content-Type: text/plain Art thou not Romeo, and a Montague? -------a786hjs2$
Romeo can then send a reply using his MSRP user agent.
Example: (F6) Romeo sends a reply
MSRP a786hjs2 SEND To-Path: msrp://gw.example.net:7654/jshA7weztas;tcp From-Path: msrp://example.net:12763/kjhd37s2s20w2a;tcp Message-ID: 87652491 Byte-Range: 1-25/25 Content-Type: text/plain Neither, fair saint, if either thee dislike. -------a786hjs2$
The MSRP-XMPP gateway would then transform that message into appropriate XMPP syntax for routing to the intended recipient.
Example: (F7) Gateway transforms MSRP message to XMPP
<message from='romeo@example.net'
to='juliet@example.com'
type='chat'>
<thread>711609sa</thread>
<body>Neither, fair saint, if either thee dislike.</body>
</message>
When the MSRP user wishes to end the chat session, the user's MSRP client sends a SIP BYE.
Example: (F8) Romeo terminates the chat session
BYE juliet@example.com sip: SIP/2.0 Max-Forwards: 70 From: <sip:romeo@example.net>;tag=087js To: <sip:juliet@example.com>;tag=786 Call-ID: 711609sa Cseq: 1 BYE Content-Length: 0
The BYE is then acknowledged by the gateway.
Example: (F9) Gateway acknowledges termination
SIP/2.0 200 OK From: <sip:juliet@example.com>;tag=786 To: <sip:romeo@example.net>;tag=087js Call-ID: 711609sa CSeq: 1 BYE Content-Length: 0
| TOC |
Unlike the XMPP protocol, the MSRP protocol offers only one way to initiate a chat session, typically using the Session Description Protocol [SDP] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) via the SIP offer/answer mechanism (see [OFFER] (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.)).
The order of events is as follows.
SIP User GW XMPP User | | | |(F1)(SIP) INVITE | | |------------------------>| | | |(F2)(XMPP) Stanza session request | |------------------------->| | |(F3)(XMPP) Stanza session acceptance | |<-------------------------| |(F4)(SIP) 200 OK | | |<------------------------| | |(F5)(SIP) ACK | | |------------------------>| | | |(F6)(XMPP) Stanza session completion | |------------------------->| |(F7)(MSRP) SEND | | |------------------------>| | | |(F8)(XMPP) A chat message | | |------------------------->| | |(F9)(XMPP) A reply | | |<-------------------------| |(F10)(MSRP) SEND | | |<------------------------| | | | | . . . . . . . . . | | | |(F11)(SIP) BYE | | |------------------------>| | | |(F12)(XMPP) Stanza session termination | |------------------------->| | |(F13)(XMPP) Termination acknowledgment | |<-------------------------| |(F14)(SIP) 200 OK | | |<------------------------| |
| TOC |
When Romeo wants to start an MSRP message session with Juliet, he first has to start the SIP session by sending out a SIP INVITE request containing an offered session description that includes an MSRP media line accompanied by a mandatory "path" attribute and corresponding URIs. The MSRP media line is also accompanied by an "accept-types" attribute used to specify the only media-types acceptable for Romeo (i.e., text/plain and/or text/html).
Note: In addition to plain text messages, MSRP is able to carry arbitrary (binary) Multipurpose Internet Mail Extensions [MIME] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) compliant content, such as images or video clips. Disposition of media types other than text/plain and text/html is out of scope for this specification and is a matter of implementation.
Example: (F1) SIP user starts the session
INVITE sip:juliet@example.com SIP/2.0 To: <sip:juliet@example.com> From: <sip:romeo@example.net>;tag=576 Subject: Open chat with Romeo? Call-ID: 742507no Content-Type: application/sdp c=IN IP4 example.net m=message 7313 TCP/MSRP * a=accept-types:text/plain a=lang:en a=lang:it a=path:msrp://example.net:7313/ansp71weztas;tcp
Upon receiving the INVITE, the MSRP-XMPP gateway needs to determine the identity of the foreign domain, which it does by performing one or more DNS SRV lookups [DNS‑SRV] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.). The gateway SHOULD resolve the address present in the To header of the INVITE to an im URI, then follow the rules in [IMP‑SRV] (Peterson, J., “Address Resolution for Instant Messaging and Presence,” August 2004.) regarding the "_im" SRV service for the target domain contained in the To header. If SRV address resolution fails for the "_im" service, the gateway MAY attempt a lookup for the "_xmpp-server" service as specified in [XMPP] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) or MAY return an error to the sender (i.e. 502 Bad Gateway).
If SRV address resolution succeeds, the gateway is responsible for translating the request into an XMPP message stanza to initiate a negotiated session from the SIP user to the XMPP user.
Example: (F2) SIP user starts the session (XMPP transformation)
<message from='romeo@example.net'
to='juliet@example.com'
type='normal'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='form'>
<title>Open chat with Romeo?</title>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:ssn</value>
</field>
<field label='Accept this session?' type='form' var='accept'>
<value>true</value>
<required/>
</field>
<field label='Primary written language of the chat'
type='list-single'
var='language'>
<value>en</value>
<option label='English'><value>en</value></option>
<option label='Italiano'><value>it</value></option>
</field>
</x>
</feature>
</message>
The mapping of SIP and SDP syntax elements to XMPP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned in the foregoing table are undefined.)
Table 3: Message syntax mapping from SIP to XMPP
+-----------------------------+-----------------------------+ | SIP Header or SDP Contents | XMPP Element or Attribute | +-----------------------------+-----------------------------+ | Call-ID | <thread/> | | From | from | | To | to | | Subject | <title/> | | accept-types | - | | a=lang | xml:lang | | To | to | +-----------------------------+-----------------------------+
See previous note regarding negotiation and use of the XHTML-IM integration set for XHTML-formatted messages (i.e., the "text/html" accept-type).
| TOC |
If the request is accepted then Juliet's client MUST include all the fields that were marked as required in the request message.
In the example below, we assume that Juliet accepts the session and specifies that she prefers to speak Italian with Romeo.
Example: (F3) Juliet accepts session and specifies parameters
<message from='juliet@example.com'
to='romeo@example.net'
type='normal'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>true</value></field>
<field var='language'><value>it</value></field>
</x>
</feature>
</message>
Upon receiving such a response, the MSRP-XMPP gateway SHOULD remember that this is a response to a stanza related to an MSRP-XMPP translation, based on the SIP Call-ID. The gateway is responsible for translating the response into a SIP response and delivering it from the XMPP user back to the SIP user.
Example: (F4) Juliet accepts session (SIP translation)
SIP/2.0 200 OK To: <sip:juliet@example.com>;tag=534 From: <sip:romeo@example.net>;tag=576 Call-ID: 742507no Content-Type: application/sdp c=IN IP4 m2x.example.net m=message 8763 TCP/MSRP * a=accept-types:text/plain a=lang:it a=path:msrp://m2x.example.net:8763/lkjh37s2s20w2a;tcp
| TOC |
In this case, the 200 OK is routed back and is received by Romeo's UA. Finally, Romeo's client sends an acknowledgment message, ACK, to Juliet's client to confirm the reception of the final response (200 OK).
Example: (F5) Romeo sends ACK
ACK sip:juliet@example.com SIP/2.0 To: <sip:juliet@example.com>;tag=534 From: <sip:romeo@example.net>;tag=576 Call-ID: 742507no
Upon receiving the ACK, the MSRP-XMPP gateway SHOULD remember this is an acknowledgment to an XMPP formal session. The gateway is responsible for translating the acknowledgment into a confirmation stanza, without inserting other content (e.g. a <body/> element cannot be inserted).
Example: (F6) Romeo sends ACK (XMPP translation)
<message from='romeo@example.net'
to='juliet@example.com'
type='normal'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'>
<value>true</value>
</field>
</x>
</feature>
</message>
| TOC |
When Romeo wants to send a message, he creates an MSRP SEND request that contains the message.
Example: (F7) Romeo sends a message
MSRP ad49kswow SEND To-Path: msrp://m2x.example.net:8763/lkjh37s2s20w2a;tcp From-Path: msrp://example.net:7313/ansp71weztas;tcp Message-ID: 44921zaqwsx Byte-Range: 1-32/32 Failure-Report: no Content-Type: text/plain I take thee at thy word ... -------ad49kswow$
Upon receiving the MSRP SEND request, the MSRP-XMPP gateway SHOULD remember that the message is for an XMPP user. The gateway is responsible for translating the MSRP SEND request into an XMPP message stanza.
Example: (F8) Romeo sends a message (XMPP translation)
<message from='romeo@example.net'
to='juliet@example.com'
type='chat'>
<thread>742507no</thread>
<body>I take thee at thy word ...</body>
</message>
The mapping of MSRP syntax elements to XMPP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined.)
Table 4: Message syntax mapping from MSRP Message to XMPP
+-----------------------------+-----------------------------+ | MSRP Header | XMPP Element or Attribute | +-----------------------------+-----------------------------+ | To-Path | to | | From-Path | from | | body of the SEND request | <body/> | | Content-Type: text/plain | - | | Message-ID | id | +-----------------------------+-----------------------------+
Upon receiving the chat message, Juliet can send a reply.
Example: (F9) Juliet sends a reply
<message from='juliet@example.com'
to='romeo@example.net'
type='chat'>
<thread>711609sa</thread>
<body>What man art thou ...?</body>
</message>
Example: (F10) Gateway transforms XMPP message to MSRP
MSRP a786hjs2 SEND To-Path: msrp://example.net:12763/kjhd37s2s20w2a;tcp From-Path: msrp://gw.example.net:7654/jshA7weztas;tcp Message-ID: 87652491 Byte-Range: 1-25/25 Content-Type: text/plain What man art thou ...? -------a786hjs2$
| TOC |
When Romeo wants to terminate the session, he is required to send a SIP BYE request.
Example: (F11) Romeo terminates the session
BYE juliet@example.com sip: SIP/2.0 Max-Forwards: 70 From: <sip:romeo@example.net>;tag=576 To: <sip:juliet@example.com>;tag=534 Call-ID: 742507no Cseq: 1 BYE Content-Length: 0
Upon receiving the SIP BYE request, the gateway SHOULD translate the request to a <message/> stanza containing a data form of type "submit". The <message/> element MUST contain a <thread/> element with the same XML character data as the original initiation request. The data form containing a boolean field named "terminate" should be set to a value of "1" or "true".
Example: (F12) Romeo terminates the session (XMPP translation)
<message from='romeo@example.net'
to='juliet@example.com'
type='normal'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='terminate'>
<value>1</value>
</field>
</x>
</feature>
</message>
Juliet explicitly acknowledges the termination of the chat session on the XMPP side by sending a <message/> containing a data form of type "result", and the value of the "terminate" field set to "1" or "true". The client MUST mirror the <thread/> value it received.
Example: (F13) Juliet acknowledges the termination of the session
<message from='juliet@example.com'
to='romeo@example.net'
type='normal'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='terminate'>
<value>1</value>
</field>
</x>
</feature>
</message>
Upon receiving the acknowledgment message, the gateway SHOULD translate it to a SIP answer 200 OK.
Example: (F14) Juliet acknowledges the termination of the session (SIP translation)
SIP/2.0 200 OK From: <sip:romeo@example.net>;tag=576 To: <sip:juliet@example.com>;tag=534 Call-ID: 742507no CSeq: 1 BYE
| TOC |
SIP User GW XMPP User | | | |(F1)(SIP) INVITE | | |----------------------->| | | |(F2)(XMPP) Stanza session request | |------------------------->| |(F3)(SIP) CANCEL | | |----------------------->| | | |(F4)(XMPP) Stanza session termination | |------------------------->| | |(F5)(XMPP) Stanza acknowledgment | | session termination | |<-------------------------| |(F6)(SIP) 200 OK | | |<-----------------------| |
A common scenario occurs when the SIP user issues an invitation to set up a chat session with an XMPP user and immediately after the SIP invitation is sent, the SIP user decides to cancel it. The MSRP-XMPP gateway will receive the CANCEL request and using the Call-ID, To, From and CSeq (sequence number only) header field values as a guide, will issue an XMPP stanza session termination request to the XMPP user to cancel the XMPP formal session (assuming that it was already set up). Once the XMPP-MSRP gateway receives an ACK stanza message for the session termination, the XMPP-MSRP gateway will respond with a status of 200 (OK) back to the SIP user. It is important to note that if the SIP session transaction does not exist, the XMPP-MSRP gateway will return a status of 481 (Transaction Does Not Exist) back to the SIP User.
| TOC |
SIP User GW XMPP User
| | |
|(F1)(SIP) INVITE | |
|-------------------------->| |
| |(F2)(XMPP) Stanza session request
| |------------------------->|
| |(F3)(XMPP) Stanza session decline
| |<-------------------------|
|(F4)(SIP) 4xx/6xx | |
|<--------------------------| |
Another common scenario occurs when the XMPP UA is currently not willing or able to accept a formal session request. The XMPP UA SHOULD decline the invitation. The data form MUST contain the FORM_TYPE field and the "accept" field set to "0" or "false". It is RECOMMENDED that the form does not contain any other fields even if the request indicated they are required.
Example: (F3) User declines offer
<message from='juliet@example.com'
to='romeo@example.net'
type='normal'>
<thread>742507no</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>0</value></field>
</x>
</feature>
</message>
Upon receiving the declined response for the XMPP formal session request, the XMPP-MSRP gateway SHOULD return a 4xx or a 6xx SIP response back to the SIP client.
| TOC |
If the XMPP recipient of a formal session request does not support stanza session negotiation as specified in [SSN] (Paterson, I. and P. Saint-Andre, “Stanza Session Negotiation,” January 2008.), it will return an XMPP <service-unavailable/> stanza error. Upon receiving this error from the XMPP recipient, the XMPP-MSRP gateway SHOULD return a 501 SIP response back to the SIP sender.
| TOC |
When an MSRP client sends messages through a gateway to an XMPP client that does not support formal sessinos, the order of events is as follows.
SIP User GW XMPP User | | | |(F1)(SIP) INVITE | | |------------------------>| | |(F2)(SIP) 200 OK | | |<------------------------| | |(F3)(SIP) ACK | | |------------------------>| | |(F4)(MSRP) SEND | | |------------------------>| | | |(F5)(XMPP) A chat message | | |------------------------->| | |(F6)(XMPP) A reply | | |<-------------------------| | | | |(F7)(MSRP) SEND | | |<------------------------| | | | | . . . . . . . . . | | | |(F8)(SIP) BYE | | |------------------------>| | |(F9)(SIP) 200 OK | | |<------------------------| | | | |
Example: (F1) SIP user starts the session
INVITE sip:juliet@example.com SIP/2.0 To: <sip:juliet@example.com> From: <sip:romeo@example.net>;tag=576 Subject: Open chat with Romeo? Call-ID: 742507no Content-Type: application/sdp c=IN IP4 example.net m=message 7313 TCP/MSRP * a=accept-types:text/plain a=lang:en a=lang:it a=path:msrp://example.net:7313/ansp71weztas;tcp
Example: (F2) Gateway accepts session on Juliet's behalf
SIP/2.0 200 OK To: <sip:juliet@example.com>;tag=534 From: <sip:romeo@example.net>;tag=576 Call-ID: 742507no Content-Type: application/sdp c=IN IP4 m2x.example.net m=message 8763 TCP/MSRP * a=accept-types:text/plain a=lang:it a=path:msrp://m2x.example.net:8763/lkjh37s2s20w2a;tcp
Example: (F3) Romeo sends ACK
ACK sip:juliet@example.com SIP/2.0 To: <sip:juliet@example.com>;tag=534 From: <sip:romeo@example.net>;tag=576 Call-ID: 742507no
Example: (F4) Romeo sends a message
MSRP ad49kswow SEND To-Path: msrp://m2x.example.net:8763/lkjh37s2s20w2a;tcp From-Path: msrp://example.net:7313/ansp71weztas;tcp Message-ID: 44921zaqwsx Byte-Range: 1-32/32 Failure-Report: no Content-Type: text/plain I take thee at thy word ... -------ad49kswow$
Example: (F5) Romeo sends a message (XMPP translation)
<message from='romeo@example.net'
to='juliet@example.com'
type='chat'>
<thread>742507no</thread>
<body>I take thee at thy word ...</body>
</message>
Example: (F6) Juliet sends a reply
<message from='juliet@example.com'
to='romeo@example.net'
type='chat'>
<thread>711609sa</thread>
<body>What man art thou ...?</body>
</message>
Example: (F8) Gateway transforms XMPP message to MSRP
MSRP a786hjs2 SEND To-Path: msrp://example.net:12763/kjhd37s2s20w2a;tcp From-Path: msrp://gw.example.net:7654/jshA7weztas;tcp Message-ID: 87652491 Byte-Range: 1-25/25 Content-Type: text/plain What man art thou ...? -------a786hjs2$
Example: (F9) Romeo terminates the session
BYE juliet@example.com sip: SIP/2.0 Max-Forwards: 70 From: <sip:romeo@example.net>;tag=576 To: <sip:juliet@example.com>;tag=534 Call-ID: 742507no Cseq: 1 BYE Content-Length: 0
Example: (F10) Gateway acknowledges the termination of the session on behalf of XMPP user
SIP/2.0 200 OK From: <sip:romeo@example.net>;tag=576 To: <sip:juliet@example.com>;tag=534 Call-ID: 742507no CSeq: 1 BYE
| TOC |
To follow.
| TOC |
| TOC |
| TOC |
| TOC |
| Peter Saint-Andre | |
| XMPP Standards Foundation | |
| P.O. Box 1641 | |
| Denver, CO 80201 | |
| USA | |
| Email: | stpeter@jabber.org |
| URI: | https://stpeter.im/ |
| Eddy Gavita | |
| Ericsson | |
| Decarie Boulevard | |
| Town of Mount Royal, Quebec | |
| Canada | |
| Email: | eddy.gavita@ericsson.com |
| Nazin Hossain | |
| Ericsson | |
| Decarie Boulevard | |
| Town of Mount Royal, Quebec | |
| Canada | |
| Email: | Nazin.Hossain@ericsson.com |
| Salvatore Loreto | |
| Ericsson | |
| Hirsalantie 11 | |
| Jorvas 02420 | |
| Finland | |
| Email: | Salvatore.Loreto@ericsson.com |
| TOC |
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.
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.