DesignXMPP im

Version 27 (Adrian Georgescu, 04/29/2012 08:52 am)

1 26
h1. SIP-XMPP Instant Messaging
2 2
3 1
4 1
5 1
6 26
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.
7 26
8 26
9 26
h3. XMPP IM types
10 26
11 26
12 26
* Normal: the default message type. A reply is not expected from the recipient.
13 26
* Chat: This message type implies both parties have engaged a conversation.
14 26
* 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 26
16 18 Adrian Georgescu
In SIP there are currently 2 ways of doing Instant Messaging:
17 1
18 1
19 26
h3. SIP IM types
20 1
21 26
22 26
* SIP MESSAGE (RFC 3428)
23 26
* MSRP (RFC 4975)
24 26
25 1
The first one is session-less and the latter is session based.
26 1
27 1
The mechanisms described here follow the currently available specifications for SIP-XMPP interoperability:
28 2
29 26
* http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-im-01.html
30 26
* http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-chat-03.html
31 1
32 2
33 26
h2. SIP-XMPP single message
34 1
35 1
36 26
XMPP single messages are mapped directly to SIP MESSAGE requests and _vice versa_.
37 3
38 26
!{ 700px, center}xmppgw_im_normal.png!
39 26
40 26
41 26
h3. Overview
42 26
43 26
44 1
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.
45 1
46 1
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".
47 1
48 26
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.
49 1
50 11
51 26
h3. Error reporting
52 26
53 26
54 1
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).
55 1
56 1
57 1
58 26
h2. SIP-XMPP chat session
59 11
60 1
61 26
In XMPP there are 2 different types of _chat sessions_:
62 26
63 26
* Formal sessions: those negotiated with XEP-0155
64 26
* Informal sessions: any exchange of message stanzas of type chat
65 26
66 1
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.
67 1
68 1
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.
69 17
70 26
*The use of SIP MESSAGE is highly discouraged* due to the following reasons:
71 16
72 26
* The most used transport in SIP is UDP, which is unreliable, thus making SIP MESSAGE requests unreliable
73 26
* Lack of an end to end delivery confirmation mechanism
74 26
* Message order is not guaranteed if an unreliable transport is used
75 26
* Messages could get duplicated due to retransmissions if an unreliable transport is used
76 26
* The majority of deployed endpoints lack support for CPIM, which is required for conferencing scenarios
77 11
78 1
79 26
h3. Defining an XMPP chat session
80 1
81 26
h4. Problem analysis
82 26
83 26
84 26
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.
85 26
86 1
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.
87 1
88 26
* _XEP-0155: 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.
89 26
* _XEP-0201: 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.
90 26
* _XEP-0085: 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).
91 1
92 26
h4. Proposed solution
93 26
94 26
95 1
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.
96 1
97 1
98 26
h5. Addressing
99 1
100 26
101 26
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). 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@.
102 26
103 1
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).
104 1
105 1
106 26
h5. Starting a session (SIP)
107 1
108 26
109 26
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@.
110 26
111 5
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.
112 5
113 26
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.
114 1
115 5
116 26
h5. Starting a session (XMPP)
117 26
118 26
119 11
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.
120 6
121 1
The outbound SIP request will always have a GRUU in the From header, as a result of the translation from a full JID.
122 6
123 6
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).
124 6
125 6
126 26
h5. Ending a session (SIP)
127 11
128 1
129 26
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).
130 1
131 1
132 26
h5. Ending a session (XMPP)
133 8
134 8
135 26
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.
136 1
137 26
138 26
139 26
h3. XMPP chat session <-> SIP MESSAGE
140 26
141 26
142 26
!{ 700px, center}xmppgw_im_chat_sipmessage.png!
143 26
144 26
145 26
h4. Error reporting
146 26
147 26
148 11
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).
149 11
150 11
151 26
h3. XMPP chat session <-> MSRP
152 10
153 10
154 26
!{ 700px, center}xmppgw_im_chat_msrp.png!
155 26
156 26
!{ 700px, center}xmppgw_im_chat_msrp2.png!
157 26
158 26
159 26
h4. Error reporting
160 26
161 1
162 1
None of the XMPP - SIP interoperability specs mention how error reporting should be done for chat messages. Since XMPP supports receipts (XEP-0184) 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.