XMPP-Interop
Version 18 (Adrian Georgescu, 07/09/2012 01:08 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 | 17 | Adrian Georgescu | h2. Presence |
46 | 17 | Adrian Georgescu | |
47 | 17 | Adrian Georgescu | The discussed items are referenced in "draft-saintandre-sip-xmpp-presence":http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence |
48 | 4 | Saúl Ibarra Corretgé | |
49 | 4 | Saúl Ibarra Corretgé | h3. SIP PIDF - XMPP stanza translation |
50 | 4 | Saúl Ibarra Corretgé | |
51 | 1 | Saúl Ibarra Corretgé | There are a number of issues when translating a XMPP stanza to a SIP PIDF: |
52 | 1 | Saúl Ibarra Corretgé | |
53 | 10 | Adrian Georgescu | h4. Availability state |
54 | 1 | Saúl Ibarra Corretgé | |
55 | 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: |
56 | 10 | Adrian Georgescu | |
57 | 1 | Saúl Ibarra Corretgé | <pre> |
58 | 1 | Saúl Ibarra Corretgé | <tuple id="id1234"> |
59 | 1 | Saúl Ibarra Corretgé | <status> |
60 | 1 | Saúl Ibarra Corretgé | <basic>open</basic> |
61 | 1 | Saúl Ibarra Corretgé | <extended>away</extended> |
62 | 1 | Saúl Ibarra Corretgé | </status> |
63 | 1 | Saúl Ibarra Corretgé | </tuple> |
64 | 1 | Saúl Ibarra Corretgé | </pre> |
65 | 1 | Saúl Ibarra Corretgé | |
66 | 1 | Saúl Ibarra Corretgé | |
67 | 1 | Saúl Ibarra Corretgé | (note the 'extended' element) |
68 | 1 | Saúl Ibarra Corretgé | |
69 | 10 | Adrian Georgescu | h4. XMPP resource and PIDF tuple ID |
70 | 10 | Adrian Georgescu | |
71 | 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: |
72 | 1 | Saúl Ibarra Corretgé | |
73 | 8 | Saúl Ibarra Corretgé | <pre> |
74 | 1 | Saúl Ibarra Corretgé | tuple id = "ID-" + encoded_resource |
75 | 8 | Saúl Ibarra Corretgé | </pre> |
76 | 1 | Saúl Ibarra Corretgé | |
77 | 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. |
78 | 4 | Saúl Ibarra Corretgé | |
79 | 18 | Adrian Georgescu | h2. Conferencing |
80 | 18 | Adrian Georgescu | |
81 | 18 | Adrian Georgescu | The discussed items are referenced in "draft-saintandre-sip-xmpp-groupchat":http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat |
82 | 18 | Adrian Georgescu | |
83 | 4 | Saúl Ibarra Corretgé | |
84 | 1 | Saúl Ibarra Corretgé | h3. Content-Type translation |
85 | 7 | Saúl Ibarra Corretgé | |
86 | 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. |
87 | 7 | Saúl Ibarra Corretgé | |
88 | 7 | Saúl Ibarra Corretgé | h3. Delivering Conference Information to Participants |
89 | 4 | Saúl Ibarra Corretgé | |
90 | 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. |