XMPP-Interop

Version 7 (Saúl Ibarra Corretgé, 07/09/2012 12:50 pm)

1 1 Saúl Ibarra Corretgé
h1. SIP - XMPP interoperability issues
2 1 Saúl Ibarra Corretgé
3 4 Saúl Ibarra Corretgé
h2. Core (draft-saintandre-sip-xmpp-core)
4 1 Saúl Ibarra Corretgé
5 6 Saúl Ibarra Corretgé
h3. Address Mapping
6 4 Saúl Ibarra Corretgé
7 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).
8 1 Saúl Ibarra Corretgé
9 1 Saúl Ibarra Corretgé
These two concepts map one-to-one:
10 1 Saúl Ibarra Corretgé
11 2 Saúl Ibarra Corretgé
    sip:alice@example.com;gr=hfje390 <--> xmpp:alice@example.com/hfje390
12 1 Saúl Ibarra Corretgé
13 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:
14 1 Saúl Ibarra Corretgé
15 1 Saúl Ibarra Corretgé
*  Take resource part and encode it in utf-8
16 1 Saúl Ibarra Corretgé
*  Hex-encode the result
17 1 Saúl Ibarra Corretgé
18 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.
19 1 Saúl Ibarra Corretgé
20 5 Saúl Ibarra Corretgé
h3. Architectural Assumptions
21 1 Saúl Ibarra Corretgé
22 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.
23 1 Saúl Ibarra Corretgé
24 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.
25 1 Saúl Ibarra Corretgé
26 4 Saúl Ibarra Corretgé
h2. Chat sessions (draft-saintandre-sip-xmpp-chat)
27 4 Saúl Ibarra Corretgé
28 4 Saúl Ibarra Corretgé
h3. Chat message reception acknowledgment
29 4 Saúl Ibarra Corretgé
30 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.
31 1 Saúl Ibarra Corretgé
32 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:
33 3 Saúl Ibarra Corretgé
34 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".
35 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.
36 1 Saúl Ibarra Corretgé
37 1 Saúl Ibarra Corretgé
Since the trend in SIP is to push the intelligence to the endpoints option 2 seems more reasonable.
38 1 Saúl Ibarra Corretgé
39 1 Saúl Ibarra Corretgé
40 4 Saúl Ibarra Corretgé
h2. Presence (draft-saintandre-sip-xmpp-presence)
41 4 Saúl Ibarra Corretgé
42 4 Saúl Ibarra Corretgé
h3. SIP PIDF - XMPP stanza translation
43 4 Saúl Ibarra Corretgé
44 1 Saúl Ibarra Corretgé
There are a number of issues when translating a XMPP stanza to a SIP PIDF:
45 1 Saúl Ibarra Corretgé
46 1 Saúl Ibarra Corretgé
* Availability state: 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:
47 1 Saúl Ibarra Corretgé
48 1 Saúl Ibarra Corretgé
<pre>
49 1 Saúl Ibarra Corretgé
    <tuple id="id1234">
50 1 Saúl Ibarra Corretgé
        <status>
51 1 Saúl Ibarra Corretgé
            <basic>open</basic>
52 1 Saúl Ibarra Corretgé
            <extended>away</extended>
53 1 Saúl Ibarra Corretgé
        </status>
54 1 Saúl Ibarra Corretgé
    </tuple>
55 1 Saúl Ibarra Corretgé
</pre>
56 1 Saúl Ibarra Corretgé
57 1 Saúl Ibarra Corretgé
58 1 Saúl Ibarra Corretgé
(note the 'extended' element)
59 1 Saúl Ibarra Corretgé
60 1 Saúl Ibarra Corretgé
* XMPP resource and PIDF tuple ID: 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:
61 1 Saúl Ibarra Corretgé
62 1 Saúl Ibarra Corretgé
    tuple id = "ID-" + encoded_resource
63 1 Saúl Ibarra Corretgé
64 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.
65 4 Saúl Ibarra Corretgé
66 4 Saúl Ibarra Corretgé
h2. Conferencing (draft-saintandre-sip-xmpp-groupchat)
67 4 Saúl Ibarra Corretgé
68 1 Saúl Ibarra Corretgé
h3. Content-Type translation
69 7 Saúl Ibarra Corretgé
70 7 Saúl Ibarra Corretgé
TODO
71 7 Saúl Ibarra Corretgé
72 7 Saúl Ibarra Corretgé
h3. Delivering Conference Information to Participants
73 4 Saúl Ibarra Corretgé
74 4 Saúl Ibarra Corretgé
TODO