XMPP-Interop

Version 16 (Saúl Ibarra Corretgé, 07/09/2012 01:05 pm)

1 1 Saúl Ibarra Corretgé
h1. SIP - XMPP interoperability issues
2 1 Saúl Ibarra Corretgé
3 11 Adrian Georgescu
h2. Core
4 11 Adrian Georgescu
5 15 Adrian Georgescu
The discussed items are referenced in "draft-saintandre-sip-xmpp-core":http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core
6 1 Saúl Ibarra Corretgé
7 6 Saúl Ibarra Corretgé
h3. Address Mapping
8 4 Saúl Ibarra Corretgé
9 9 Adrian Georgescu
We suggest that on the SIP side GRUU (RFC 5627) is a required component for implementing such a gateway. The reason is outlined below.
10 9 Adrian Georgescu
11 1 Saúl Ibarra Corretgé
In XMPP a given user (bare JID) may be logged in with several devices and each will be identified with the resource part, forming the Full JID. In SIP this was not possible, but now there is a way to achieve the same: GRUU (RFC 5627). With GRUU a given SIP device can be addressed as follows: sip:alice@example.com;gr=hfje390 (the 'gr' parameter indicates the instance id).
12 1 Saúl Ibarra Corretgé
13 1 Saúl Ibarra Corretgé
These two concepts map one-to-one:
14 1 Saúl Ibarra Corretgé
15 2 Saúl Ibarra Corretgé
    sip:alice@example.com;gr=hfje390 <--> xmpp:alice@example.com/hfje390
16 1 Saúl Ibarra Corretgé
17 1 Saúl Ibarra Corretgé
However, XMPP allows Unicode to be used as the resource, but in SIP URIs need to be ASCII, so here is a proposed translation procedure:
18 1 Saúl Ibarra Corretgé
19 1 Saúl Ibarra Corretgé
*  Take resource part and encode it in utf-8
20 1 Saúl Ibarra Corretgé
*  Hex-encode the result
21 1 Saúl Ibarra Corretgé
22 1 Saúl Ibarra Corretgé
NOTE: The reason for proposing another translation mechanism than the one defined in (draft-saintandre-sip-xmpp-core-01) is related to presence, the section related to presence contains a more thorough exaplanation on this.
23 1 Saúl Ibarra Corretgé
24 5 Saúl Ibarra Corretgé
h3. Architectural Assumptions
25 1 Saúl Ibarra Corretgé
26 5 Saúl Ibarra Corretgé
The XMPP-SIP draft ("draft-saintandre-sip-xmpp-core-01":http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-01#section-2) suggests that subdomains are used to indicate if a translation gateway needs to be used (x2s.domain and s2x.domain). In practice, users already have their address books full of URIs, so needing a specific subdomain for indicating that a protocol translation is needed requires user knowledge about the system, which is confusing and leads to zero adoption.
27 1 Saúl Ibarra Corretgé
28 1 Saúl Ibarra Corretgé
Instead, servers should be smart enough to decide if a request needs to be translated to a different protocol or not. This is application specific behavior, so it could be implemented by using a static list of domains, DNS lookups or by any other means.
29 1 Saúl Ibarra Corretgé
30 14 Adrian Georgescu
h2. Chat sessions
31 1 Saúl Ibarra Corretgé
32 14 Adrian Georgescu
The discussed items are referenced in "draft-saintandre-sip-xmpp-chat":http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat
33 14 Adrian Georgescu
34 4 Saúl Ibarra Corretgé
h3. Chat message reception acknowledgment
35 4 Saúl Ibarra Corretgé
36 1 Saúl Ibarra Corretgé
XEP-0184 defines a way to indicate the remote party that an acknowledgement receipt is desired for the current chat message. MSRP has a similar mechanism by using the REPORT chunk type, so they should probably be correlated in order to increase the communication reliability.
37 1 Saúl Ibarra Corretgé
38 1 Saúl Ibarra Corretgé
However, XEP-0184 suggests that endpoints supporting that XEP may choose not to send the receipt, and there are other reasons why the acknowledgement could be lost. How should the gateway act on the SIP side? A timer set to a reasonable value (and what is a 'reasonable' value?) should probably be used in order to decide if a message is considered as delivered or not. This could be implemented in two ways:
39 3 Saúl Ibarra Corretgé
40 3 Saúl Ibarra Corretgé
# The gateway server sends a REPORT chunk after the timer fires, with a new response code, which would basically indicate "I don't know".
41 1 Saúl Ibarra Corretgé
# The gateway server would not send a REPORT chunk and the SIP endpoint would need to implement the timer and after it fires alert the user somehow by telling him that it's not clear if the remote endpoint got the message.
42 1 Saúl Ibarra Corretgé
43 1 Saúl Ibarra Corretgé
Since the trend in SIP is to push the intelligence to the endpoints option 2 seems more reasonable.
44 1 Saúl Ibarra Corretgé
45 4 Saúl Ibarra Corretgé
h2. Presence (draft-saintandre-sip-xmpp-presence)
46 4 Saúl Ibarra Corretgé
47 4 Saúl Ibarra Corretgé
h3. SIP PIDF - XMPP stanza translation
48 4 Saúl Ibarra Corretgé
49 1 Saúl Ibarra Corretgé
There are a number of issues when translating a XMPP stanza to a SIP PIDF:
50 1 Saúl Ibarra Corretgé
51 10 Adrian Georgescu
h4. Availability state
52 1 Saúl Ibarra Corretgé
53 10 Adrian Georgescu
It is suggested that the availability state is mapped to the Person element in PIDF. However, there can only be a single Person element per SIP user. In PIDF each device would add a Tuple element, so adding the availability information at that level would maintain the per-device semantics. In SIPSIMPLE SDK (core of SylkServer) we implemented a extension for PIDF which maps XMPP availability states to PIDF in a generic way. Example:
54 10 Adrian Georgescu
55 1 Saúl Ibarra Corretgé
<pre>
56 1 Saúl Ibarra Corretgé
    <tuple id="id1234">
57 1 Saúl Ibarra Corretgé
        <status>
58 1 Saúl Ibarra Corretgé
            <basic>open</basic>
59 1 Saúl Ibarra Corretgé
            <extended>away</extended>
60 1 Saúl Ibarra Corretgé
        </status>
61 1 Saúl Ibarra Corretgé
    </tuple>
62 1 Saúl Ibarra Corretgé
</pre>
63 1 Saúl Ibarra Corretgé
64 1 Saúl Ibarra Corretgé
65 1 Saúl Ibarra Corretgé
(note the 'extended' element)
66 1 Saúl Ibarra Corretgé
67 10 Adrian Georgescu
h4. XMPP resource and PIDF tuple ID
68 10 Adrian Georgescu
69 10 Adrian Georgescu
The schema for PIDF defines the tuple ID as xs:ID, which has some constraints in the characters it accepts. Thus, a direct mapping between the JID resource and the the tuple ID is not possible. The proposed solution:
70 1 Saúl Ibarra Corretgé
71 8 Saúl Ibarra Corretgé
<pre>
72 1 Saúl Ibarra Corretgé
    tuple id = "ID-" + encoded_resource
73 8 Saúl Ibarra Corretgé
</pre>
74 1 Saúl Ibarra Corretgé
75 1 Saúl Ibarra Corretgé
The encoded_resource is the result of encoding the JID resource by following the rules stated in section 1 and prepending "ID-". xs:ID elements can't start with a number, so prepending "ID-" guarantees that the document would validate the schema. This principle can also be followed by SIP endpoints since the GRUU id is a UUID, so it's also not guaranteed to begin with a letter.
76 4 Saúl Ibarra Corretgé
77 4 Saúl Ibarra Corretgé
h2. Conferencing (draft-saintandre-sip-xmpp-groupchat)
78 4 Saúl Ibarra Corretgé
79 1 Saúl Ibarra Corretgé
h3. Content-Type translation
80 7 Saúl Ibarra Corretgé
81 13 Saúl Ibarra Corretgé
In XMPP clients may exchange messages in plaintext and also in HTML. When HTML is being used the plaintext version is also present in the stanza, unlike MSRP, where the is a single content type (unless multipart is being used). If an MSRP endpoint sends HTML content is not obvious how the plaintext version should be generated. In order to make interoperability easier multipart could be used or some sort of HTML to plaintext translation.
82 7 Saúl Ibarra Corretgé
83 7 Saúl Ibarra Corretgé
h3. Delivering Conference Information to Participants
84 4 Saúl Ibarra Corretgé
85 16 Saúl Ibarra Corretgé
SIP uses RFC4575 to deliver information to participants in a conference room. "XEP-0298":http://xmpp.org/extensions/xep-0298.html defines a way to also use RFC4575 in Jingle conferences, thus making interoperability really easy. This should probably be the preferred way of delivering participants information in Jingle, at least when used in a mixed environment with SIP.