DesignXMPP im

Version 14 (Adrian Georgescu, 09/14/2013 04:11 am)

1 3 Adrian Georgescu
h1. SIP-XMPP Instant Messaging (IM)
2 1 Tijmen de Mes
3 1 Tijmen de Mes
In XMPP there are several types of messages which lead to different semantics when exchanging XMPP _message stanzas_ between 2 endpoints. This section focuses only on message types that allow 2 endpoints to send instant messages to each other.
4 1 Tijmen de Mes
5 11 Adrian Georgescu
h2. XMPP IM types
6 1 Tijmen de Mes
7 4 Adrian Georgescu
In XMPP there are three ways of doing Instant Messaging:
8 4 Adrian Georgescu
9 3 Adrian Georgescu
* Normal: the default message type. A reply is not expected from the recipient. This is further referred as 'Single Message' mode. 
10 3 Adrian Georgescu
* Chat: This message type implies both parties have engaged a conversation. This is further referred as 'Chat Session' mode.
11 1 Tijmen de Mes
12 3 Adrian Georgescu
The first one is session-less and the latter is session based.
13 3 Adrian Georgescu
14 1 Tijmen de Mes
* Headline: An endpoint receiving this type of message should never reply, since it's meant to be used by servers or other entities to deliver announcements.
15 1 Tijmen de Mes
16 11 Adrian Georgescu
h2. SIP IM types
17 1 Tijmen de Mes
18 4 Adrian Georgescu
In SIP there are two ways of doing Instant Messaging:
19 1 Tijmen de Mes
20 3 Adrian Georgescu
* SIP MESSAGE (RFC 3428). This is further referred as 'Single Message' mode. 
21 3 Adrian Georgescu
* MSRP sessions (RFC 4975). This is further referred as 'Chat Session' mode.
22 1 Tijmen de Mes
23 1 Tijmen de Mes
The first one is session-less and the latter is session based.
24 1 Tijmen de Mes
25 3 Adrian Georgescu
h2. Single Message Translation
26 1 Tijmen de Mes
27 3 Adrian Georgescu
The mechanism described here follow the currently available specifications for SIP-XMPP interoperability:
28 3 Adrian Georgescu
29 1 Tijmen de Mes
* http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-im-01.html
30 1 Tijmen de Mes
31 1 Tijmen de Mes
XMPP single messages are mapped directly to SIP MESSAGE requests and _vice versa_.
32 1 Tijmen de Mes
33 1 Tijmen de Mes
!{ 700px, center}xmppgw_im_normal.png!
34 1 Tijmen de Mes
35 1 Tijmen de Mes
36 1 Tijmen de Mes
h3. Overview
37 1 Tijmen de Mes
38 1 Tijmen de Mes
39 1 Tijmen de Mes
The mechanism for translating XMPP normal message stanzas and SIP MESSAGE requests is straightforward, they map one to one as stated in http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-im-01.html. However, since SIP is used mainly with UDP as a transport, if a  XMPP stanza is bigger than 1500 bytes it will be chunked into smaller pieces to avoid ethernet fragmentation related issues.
40 1 Tijmen de Mes
41 1 Tijmen de Mes
Since SIP MESSAGE is a non INVITE transaction, it has to be replied immediately, because there is no way to avoid retransmissions. This means that the SIP-XMPP gateway will reply on the SIP side before knowing if the message was actually delivered to the XMPP side. In order to express this a "202 Accepted" reply will be sent to the SIP request instead of a "200 OK".
42 1 Tijmen de Mes
43 1 Tijmen de Mes
On the other hand, when an XMPP stanza is translated into a SIP MESSAGE request the SIP-XMPP gateway is able to report back the result (in case of error) by using a message stanza of type _error_. This is possible because of the asynchronous nature of stanza processing in the XMPP protocol.
44 1 Tijmen de Mes
45 1 Tijmen de Mes
46 1 Tijmen de Mes
h3. Error reporting
47 1 Tijmen de Mes
48 1 Tijmen de Mes
49 1 Tijmen de Mes
No error reporting mechanism can be used at the SIP level to notify about SIP MESSAGE delivery success or failure, since the request has to be replied to immediately (because it's a non INVITE transaction).
50 1 Tijmen de Mes
51 3 Adrian Georgescu
h2. Chat Session Translation
52 1 Tijmen de Mes
53 3 Adrian Georgescu
The mechanism described here follow the currently available specifications for SIP-XMPP interoperability:
54 3 Adrian Georgescu
* http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-chat-03.html
55 1 Tijmen de Mes
56 6 Adrian Georgescu
In XMPP there are two different types of _chat sessions_:
57 1 Tijmen de Mes
58 5 Adrian Georgescu
* Formal sessions: those negotiated with "XEP-0155":http://xmpp.org/extensions/xep-0155.html
59 1 Tijmen de Mes
* Informal sessions: any exchange of message stanzas of type chat
60 1 Tijmen de Mes
61 1 Tijmen de Mes
Formal sessions map directly to SIP sessions but since support for that XEP doesn't seem to be widely deployed it will not be implemented.
62 1 Tijmen de Mes
63 1 Tijmen de Mes
Informal sessions can be mapped to SIP sessions with MSRP media or to SIP MESSAGE requests. Both mechanisms will be implemented and selecting which one to use will be decided with a configuration option.
64 1 Tijmen de Mes
65 1 Tijmen de Mes
*The use of SIP MESSAGE is highly discouraged* due to the following reasons:
66 1 Tijmen de Mes
67 14 Adrian Georgescu
* There is no possibility to correlate several messages together as belonging to a conversation
68 1 Tijmen de Mes
* The most used transport in SIP is UDP, which is unreliable, thus making delivery of SIP MESSAGE requests unreliable
69 1 Tijmen de Mes
* Lack of an end to end delivery confirmation mechanism
70 1 Tijmen de Mes
* Message order is not guaranteed if an unreliable transport like UDP is used
71 1 Tijmen de Mes
* Messages could get duplicated due to retransmissions if an unreliable transport is used
72 1 Tijmen de Mes
* The majority of deployed endpoints lack support for CPIM, which is required for conferencing scenarios
73 14 Adrian Georgescu
* The message can be truncated by NAT routers and intermediate SIP server elements
74 1 Tijmen de Mes
75 8 Adrian Georgescu
h3. Session Model
76 1 Tijmen de Mes
77 1 Tijmen de Mes
In SIP a _session_ is started by creating a dialog with the INVITE method and it's ended by terminating the dialog with a BYE request. In XMPP there is no universal mechanism to indicate that a chat session has started or ended. Because of this, the SIP-XMPP gateway will try its best to correlate the state on the SIP side with the one on the XMPP side.
78 1 Tijmen de Mes
79 1 Tijmen de Mes
There are different mechanisms by which the start and end of an XMPP chat session can be stated, but unfortunately none of them seem to be implemented in the most widely used XMPP clients, so relaying on them would lead to trouble.
80 1 Tijmen de Mes
81 6 Adrian Georgescu
* _"XEP-0155":http://xmpp.org/extensions/xep-0155.html: Stanza Session Negotiation_. This XEP has been in draft form since 2008 and even if implementation is encouraged none of the widely used XMPP clients implements it.
82 9 Adrian Georgescu
* _"XEP-0201":http://xmpp.org/extensions/xep-0201.html: Best Practices for Message Threads_. This XEP is more recent and some many clients implement it. Unfortunately, the concept of a "chat session" according to this XEP doesn't match the one on SIP because message threads last far longer, they can be resumed even after being offline for a while.
83 9 Adrian Georgescu
* _"XEP-0085":http://xmpp.org/extensions/xep-0085.html: Chat State Notifications_. This XEP defines a set of states in which use can be while on a chat session. Many clients implement it and it can be used to signal composing indication on the SIP side and also to decide when a session should be ended on the SIP side (the _gone_ state).
84 1 Tijmen de Mes
85 1 Tijmen de Mes
Since no reliable way has been found to map SIP sessions to XMPP chat sessions and vice versa, the SIP-XMPP gateway will try to use all the available information to act as accurately as possible.
86 1 Tijmen de Mes
87 6 Adrian Georgescu
h4. Addressing
88 1 Tijmen de Mes
89 6 Adrian Georgescu
The first thing that needs to be solved is addressing: XMPP JIDs have a resource, which uniquely identifies a given XMPP client instance, for example @saul@ag-projects.com/foobar@. A similar mechanism needs to be implemented on the SIP side so that individual devices and thus session endpoints are properly matched. This is solved by using _GRUU_ ("RFC 5627":http://tools.ietf.org/html/rfc5627). With GRUU each device will have a unique identifier, like the XMPP JID resource. For example, these could be the 2 endpoints of a given session: user1 @sip:saul@ag-projects.com;gr=89y89y4hr489j98jf4@ <--> user2 @ag@ag-projects.com/foobar@.
90 1 Tijmen de Mes
91 1 Tijmen de Mes
If a SIP endpoint doesn't have a GRUU support a single fixed identifier will be assigned. This fixed value MUST never change while the application is running. The lack of support of GRUU imposes a limitation, though: only a single concurrent session can be carried out with the same destination XMPP JID, because otherwise it would be impossible to match the destination of the incoming XMPP stanzas (the recipient would always be the same).
92 1 Tijmen de Mes
93 1 Tijmen de Mes
94 6 Adrian Georgescu
h4. Starting a session (SIP)
95 1 Tijmen de Mes
96 1 Tijmen de Mes
In order to start a session from the SIP side, an INVITE will be used, as usual. When building the request URI, the caller may specify the callee instance he wants to talk to by sing the GRUU semantics, that is: @sip:user@gmail.com;gr=foobar@ would be translated to @user@gmail.com/foobar@.
97 1 Tijmen de Mes
98 1 Tijmen de Mes
If there is no session established between the caller and the callee the SIP-XMPP gateway will accept the session and will start translating SIP chat messages to XMPP chat message stanzas. If there is already an ongoing session between the two given endpoints, the SIP-XMPP gateway will reject the session with 488 code.
99 1 Tijmen de Mes
100 1 Tijmen de Mes
Note that if the SIP request URI doesn't contain the resource identifier (gr parameter) the translated JID is a _bare_ JID (a JID with no resource specified) so the real recipient is unknown until a response is received from any XMPP client with that JID.
101 1 Tijmen de Mes
102 1 Tijmen de Mes
103 6 Adrian Georgescu
h4. Starting a session (XMPP)
104 1 Tijmen de Mes
105 1 Tijmen de Mes
106 1 Tijmen de Mes
As aforementioned, XMPP doesn't have a mechanism to indicate the start of a chat session, so the XMPP client will just send a message stanza. If there is no session whose endpoints map those specified in the stanza a new outbound SIP session will be created.
107 1 Tijmen de Mes
108 1 Tijmen de Mes
The outbound SIP request will always have a GRUU in the From header, as a result of the translation from a full JID.
109 1 Tijmen de Mes
110 1 Tijmen de Mes
Note that if the recipient JID is a bare JID the real recipient is unknown until a reply is received on the SIP side (the request may fork and the session will be bound to the endpoint that answers).
111 1 Tijmen de Mes
112 1 Tijmen de Mes
113 6 Adrian Georgescu
h4. Ending a session (SIP)
114 1 Tijmen de Mes
115 1 Tijmen de Mes
116 1 Tijmen de Mes
If a SIP endpoint sends a BYE request to the SIP-XMPP gateway, the SIP session will be terminated and a body-less chat message stanza will be sent to the XMPP endpoint with the _gone_ chat state (XEP-0085).
117 1 Tijmen de Mes
118 1 Tijmen de Mes
119 6 Adrian Georgescu
h4. Ending a session (XMPP)
120 1 Tijmen de Mes
121 1 Tijmen de Mes
122 1 Tijmen de Mes
If a XMPP endpoint sends a chat message stanza with the _gone_ chat state the SIP-XMPP gateway will terminate the session on the SIP side by sending a BYE request. Since not all XMPP clients send the _gone_ chat state the SIP-XMPP gateway will keep a timer which will terminate the session on the SIP side if no chat messages were exchanged in that amount of time. The default value (it's configurable) is 10 minutes, as recommended by XEP-0085.
123 1 Tijmen de Mes
124 1 Tijmen de Mes
h3. XMPP chat session <-> SIP MESSAGE
125 1 Tijmen de Mes
126 1 Tijmen de Mes
127 1 Tijmen de Mes
!{ 700px, center}xmppgw_im_chat_sipmessage.png!
128 1 Tijmen de Mes
129 1 Tijmen de Mes
130 1 Tijmen de Mes
h4. Error reporting
131 1 Tijmen de Mes
132 1 Tijmen de Mes
133 1 Tijmen de Mes
No error reporting mechanism can be used at the SIP level to notify about SIP MESSAGE delivery success or failure, since the request has to be replied to immediately (because it's a non INVITE transaction).
134 1 Tijmen de Mes
135 13 Adrian Georgescu
h3. SIP/MSRP <-> XMPP chat
136 1 Tijmen de Mes
137 13 Adrian Georgescu
!{ 700px, center}xmppgw_im_chat_msrp.png!
138 1 Tijmen de Mes
139 13 Adrian Georgescu
h3. XMPP chat <-> SIP/MSRP
140 1 Tijmen de Mes
141 1 Tijmen de Mes
142 1 Tijmen de Mes
!{ 700px, center}xmppgw_im_chat_msrp2.png!
143 1 Tijmen de Mes
144 1 Tijmen de Mes
h4. Error reporting
145 1 Tijmen de Mes
146 1 Tijmen de Mes
147 10 Adrian Georgescu
None of the XMPP - SIP interoperability specs mention how error reporting should be done for chat messages. Since XMPP supports receipts ("XEP-0184":http://xmpp.org/extensions/xep-0184.html) they are correlated with the MSRP REPORT requests by the SIP-XMPP gateway in order to have message delivery assurance on both SIP and XMPP.