XMPP-Interop
Version 4 (Saúl Ibarra Corretgé, 07/09/2012 12:44 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 | 4 | Saúl Ibarra Corretgé | h3. Addressing |
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 | 1 | Saúl Ibarra Corretgé | |
21 | 4 | Saúl Ibarra Corretgé | h3. Transparent gateways |
22 | 1 | Saúl Ibarra Corretgé | |
23 | 1 | Saúl Ibarra Corretgé | The XMPP-SIP draft (draft-saintandre-sip-xmpp-core-01) 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. |
24 | 1 | Saúl Ibarra Corretgé | |
25 | 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. |
26 | 1 | Saúl Ibarra Corretgé | |
27 | 1 | Saúl Ibarra Corretgé | |
28 | 4 | Saúl Ibarra Corretgé | h2. Chat sessions (draft-saintandre-sip-xmpp-chat) |
29 | 4 | Saúl Ibarra Corretgé | |
30 | 4 | Saúl Ibarra Corretgé | h3. Chat message reception acknowledgment |
31 | 4 | Saúl Ibarra Corretgé | |
32 | 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. |
33 | 1 | Saúl Ibarra Corretgé | |
34 | 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: |
35 | 3 | Saúl Ibarra Corretgé | |
36 | 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". |
37 | 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. |
38 | 1 | Saúl Ibarra Corretgé | |
39 | 1 | Saúl Ibarra Corretgé | Since the trend in SIP is to push the intelligence to the endpoints option 2 seems more reasonable. |
40 | 1 | Saúl Ibarra Corretgé | |
41 | 1 | Saúl Ibarra Corretgé | |
42 | 4 | Saúl Ibarra Corretgé | h2. Presence (draft-saintandre-sip-xmpp-presence) |
43 | 4 | Saúl Ibarra Corretgé | |
44 | 4 | Saúl Ibarra Corretgé | h3. SIP PIDF - XMPP stanza translation |
45 | 4 | Saúl Ibarra Corretgé | |
46 | 1 | Saúl Ibarra Corretgé | There are a number of issues when translating a XMPP stanza to a SIP PIDF: |
47 | 1 | Saúl Ibarra Corretgé | |
48 | 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: |
49 | 1 | Saúl Ibarra Corretgé | |
50 | 1 | Saúl Ibarra Corretgé | <pre> |
51 | 1 | Saúl Ibarra Corretgé | <tuple id="id1234"> |
52 | 1 | Saúl Ibarra Corretgé | <status> |
53 | 1 | Saúl Ibarra Corretgé | <basic>open</basic> |
54 | 1 | Saúl Ibarra Corretgé | <extended>away</extended> |
55 | 1 | Saúl Ibarra Corretgé | </status> |
56 | 1 | Saúl Ibarra Corretgé | </tuple> |
57 | 1 | Saúl Ibarra Corretgé | </pre> |
58 | 1 | Saúl Ibarra Corretgé | |
59 | 1 | Saúl Ibarra Corretgé | |
60 | 1 | Saúl Ibarra Corretgé | (note the 'extended' element) |
61 | 1 | Saúl Ibarra Corretgé | |
62 | 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: |
63 | 1 | Saúl Ibarra Corretgé | |
64 | 1 | Saúl Ibarra Corretgé | tuple id = "ID-" + encoded_resource |
65 | 1 | Saúl Ibarra Corretgé | |
66 | 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. |
67 | 4 | Saúl Ibarra Corretgé | |
68 | 4 | Saúl Ibarra Corretgé | |
69 | 4 | Saúl Ibarra Corretgé | h2. Conferencing (draft-saintandre-sip-xmpp-groupchat) |
70 | 4 | Saúl Ibarra Corretgé | |
71 | 4 | Saúl Ibarra Corretgé | h3. Content-Type translation |
72 | 4 | Saúl Ibarra Corretgé | |
73 | 4 | Saúl Ibarra Corretgé | TODO |