DesignXMPP conference » History » Version 13
Saúl Ibarra Corretgé, 01/29/2013 10:32 PM
1 | 2 | Adrian Georgescu | h1. SIP-XMPP Multiparty Chat |
---|---|---|---|
2 | 3 | Adrian Georgescu | |
3 | This is done by bridging MUC functionality from XMPP with MSRP-Switch functionality using SIP. |
||
4 | |||
5 | 4 | Adrian Georgescu | * SIP users can create ad-hoc conference rooms using SylkServer MSRP chat and invite users from both SIP and XMPP domains |
6 | 12 | Saúl Ibarra Corretgé | * XMPP users can create multiparty conferences using SylkServer MUC capability and invite users from both XMPP and SIP worlds |
7 | |||
8 | The XMPP gateway application in SylkServer implements mediated invitations, that is, invitations performed through the MUC room itself. This is analogous to how it's performed on the SIP side and how all of the tested XMPP clients operate. |
||
9 | 5 | Saúl Ibarra Corretgé | |
10 | h2. Joining a conference |
||
11 | |||
12 | A conference room will be created if it doesn't exist previously. For joining a conference, an XMPP endpoint will send a presence stanza with the URI of the room. SylkServer handles conferences as part of the conference application, so it will create a new SIP session which will join the conference.Usually the SIP INVITE will loop in the proxy and enter SylkServer again, but this time the executed application will be "conference". |
||
13 | |||
14 | 9 | Saúl Ibarra Corretgé | The XMPP gateway application will receive SIP NOTIFY requests with "RFC 4575":https://tools.ietf.org/html/rfc4575 payload specifying the participants in the room, and this will be translated into presence stanza elements. Likewise, all MSRP messages received on the SIP session will be translated into _groupchat_ message stanzas. |
15 | 5 | Saúl Ibarra Corretgé | |
16 | 10 | Saúl Ibarra Corretgé | !{ 700px, center}xmppgw_muc_x2s.png! |
17 | |||
18 | 5 | Saúl Ibarra Corretgé | h2. Inviting new participants |
19 | |||
20 | 13 | Saúl Ibarra Corretgé | SylkServer allows for XMPP users to invite SIP endpoints or vice versa. This is accomplished in the same fashion as joining a conference: it takes place in the _conference_ application, which is based on SIP. Here is the sequence of actions which are performed for inviting a SIP or XMPP endpoint to a conference room, from an XMPP endpoints standpoint: |
21 | 11 | Saúl Ibarra Corretgé | |
22 | # A message stanza with the _invite_ element pointing to the desired user |
||
23 | # SylkServer sends a out of dialog REFER request towards the conference room URI and indicates the use that needs to be invited in a Refer-To header |
||
24 | # When the REFER request arrives back at SylkServer, it will create an outgoing SIP session towards the URI in the Refer-To header, it also indicates that the session comes from a conference server by adding the _isfocus_ contact header parameter |
||
25 | # If the invited user was a SIP endpoint, it will accept the session and join the conference |
||
26 | # If the invited user was a XMPP endpoint, the SIP INVITE will enter SylkServer yet again, but this time it will be handled by the XMPP gateway application |
||
27 | # The XMPP gateway application detects the INVITE as an invitation to join a conference because it contains a Referred-By header and the _isfocus_ contact header parameter |
||
28 | # SylkServer sends a message stanza to the invited user indicating who invited him |