Movatterモバイル変換
[0]ホーム
| body of the SEND request | +-----------------------------+-----------------------------+5.5.1. Send a Message to All Occupants When Juliet wants to sends a message to all other occupants in the room, she sends a message of type "groupchat" to the itself (in our example,). The following examples show an exchange of a public message. Example 12: Juliet Sends Message to All Occupants (F16) | | Who knows where Romeo is? |Saint-Andre, et al. Standards Track [Page 19] RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 Upon receiving such a message, the XMPP-to-MSRP gateway translates it into an MSRP SEND message. Example 13: Gateway Maps XMPP Message to MSRP (F17) | MSRP a786hjs2 SEND | To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp | From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp | Message-ID: 87652491 | Byte-Range: 1-*/* | Content-Type: message/cpim | | To: | From: "Juliet" | DateTime: 2008-10-15T15:02:31-03:00 | Content-Type: text/plain | | Who knows where Romeo is? | -------a786hjs2$ Upon receiving the SEND request, if the request either contains a Failure-Report header field value of "yes" or does not contain a Failure-Report header at all, the MSRP switch immediately generates and sends a response. Example 14: MSRP Switch Returns 200 OK (F18) | MSRP d93kswow 200 OK | To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp | From-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp | -------d93kswow$ Since an XMPP MUC room could be moderated and an XMPP user cannot be sure whether her message has been accepted without receiving it back from the server, [XEP-0045] states that the sender needs to receive a reflected copy of the message it sent. So, in this scenario, the XMPP-to-MSRP gateway has to reflect the message back to the sender. This procedure only applies to XMPP endpoints. Example 15: Gateway Reflects Message to XMPP User (F19) | | Who knows where Romeo is? |Saint-Andre, et al. Standards Track [Page 20] RFC 7702 SIP-XMPP Interworking: Groupchat December 20155.5.2. Send a Private Message Since each occupant has a unique JID, Juliet can send a "private message" to a selected occupant through the service by sending a message to the user's occupant JID. The XMPP message type ought to be "chat" (and is not allowed to be "groupchat"). The following examples show an exchange of a private message. Example 16: Juliet Sends Private Message (F20) | | O Romeo, Romeo! wherefore art thou Romeo? | Upon receiving such a message, the XMPP-to-MSRP gateway translates it into an MSRP SEND message. Example 17: Gateway Maps Private Message from XMPP to MSRP (F21) | MSRP a786hjs2 SEND | To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp | From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp | Message-ID: 87652491 | Byte-Range: 1-*/* | Content-Type: message/cpim | | To:;gr=Romeo | From:;gr=yn0cl4bnw0yr3vym | DateTime: 2008-10-15T15:02:31-03:00 | Content-Type: text/plain | | O Romeo, Romeo! wherefore art thou Romeo? | -------a786hjs2$ After acknowledging the message by sending an MSRP 200 OK message (step F22, not shown), the MSRP switch is responsible for sending the message to the intended recipient. When doing so, it modifies the From header to the sender's address within the chat room.Saint-Andre, et al. Standards Track [Page 21] RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 Example 18: Switch Sends Private Message to SIP User | MSRP a786hjs2 SEND | To-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp | From-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp | Message-ID: 87652491 | Byte-Range: 1-*/* | Content-Type: message/cpim | | To: | From:;gr=JuliC | DateTime: 2008-10-15T15:02:31-03:00 | Content-Type: text/plain | | O Romeo, Romeo! wherefore art thou Romeo? | -------a786hjs2$ Note: If an XMPP-to-MSRP gateway has support for private messaging, it MUST advertise that fact by adding a "private-messages" value to the a=chatroom SDP attribute it sends to the conference focus, as specified in [RFC7701]. | a=chatroom:nickname private-messages5.6. Change Nickname The XMPP user might want to change her nickname. She can do so by sending an updated presence stanza to the room, containing a new nickname. Example 19: Juliet Changes Her Nickname (F23) | So far we have assumed that the requested nickname did not conflict with any existing nicknames. The following text describes the handling of a nickname conflict. The MSRP switch analyzes the existing allocation of nicknames, and detects that the nickname proposal is already provided to another participant. In this case, the MSRP switch answers with a 425 response.Saint-Andre, et al. Standards Track [Page 22] RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 Example 20: MSRP Switch Does Not Accept Nickname Proposal (F25) | MSRP a786hjs2 425 Nickname usage failed | To-Path: msrp://x2m.example.com:7654/jshA7weztas;tcp | From-Path: msrp://chat.example.org:12763/kjhd37s2s20w2a;tcp | -------a786hjs2 Upon receiving such a response, the XMPP-to-MSRP gateway translates it into an XMPP presence stanza of type "error", specifying a error condition (which implies that the XMPP client will then need to choose another nickname and repeat the process of joining). Example 21: Conflict Error for Nickname (F26) | | | | | | Alternatively, the gateway might generate a new nickname request on behalf of the XMPP user, thus shielding the XMPP client from handling the conflict error.5.7. Invite Another User to a Room In XMPP, there are two methods for inviting another user to a room: direct invitations [XEP-0249] (sent directly from the user's real JID outside the room to the invitee's real JID) and mediated invitations (sent through the room from the user's occupant JID to the invitee's JID). In this document, we cover mediated invitations only. For example, if Juliet decides to invite Benvolio to the room, she sends a message stanza with an invite and Benvolio's JID (which could be his real JID or an occupant JID in another room).Saint-Andre, et al. Standards Track [Page 23] RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 Example 22: Juliet Invites Benvolio to the Room (F27) | | | | | The XMPP-to-SIP gateway then sends a SIP REFER request to the conference focus indicating who needs to be invited in the Refer-To header, as per Section 5.5 of [RFC4579]. Example 23: SIP Mapping of Invite (F28) | REFER sip:montague@chat.example.org SIP/2.0 | To: | From: "Juliet";tag=786 | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 | CSeq: 5 REFER | Contact:;gr=yn0cl4bnw0yr3vym | Accept: message/sipfrag | Refer-To: | Supported: replaces | Content-Length: 0 The conference focus then acknowledges the SIP REFER request with a 200 OK response (step F29, not shown). The progress of the invitation will be tracked by the received NOTIFY requests as per [RFC3515]. Example 24: Progress Notification for Invitation (F30) | NOTIFY sip:juliet@example.com SIP/2.0 | To:;tag=786 | From:;tag=087js | Call-ID: BC466C1C-E01D-4FD1-B766-9AD174BAF2E7 | CSeq: 6 NOTIFY | Max-Forwards: 70 | Event: refer | Subscription-State: active;expires=60 | Contact:;isfocus | Content-Type: message/sipfrag;version=2.0 | Content-Length: ...Saint-Andre, et al. Standards Track [Page 24] RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 Note: Implementers might want to be aware that several recently published specifications modify the way in which REFER requests handle SIP notifications (see [RFC7647] and [RFC7614]).5.8. Exit Room If Juliet decides to exit the chat room, her client sends a directed presence stanza of type "unavailable" to the occupant JID she is currently using in the room (here). Example 25: Juliet Exits Room (F31) | Upon receiving such a stanza, the XMPP-to-SIP gateway terminates the SIP session by sending a SIP BYE to the conference focus and the conference focus responds with a SIP 200 OK (steps F32 and F33, not shown). Juliet can include a custom exit message in the presence stanza of type "unavailable", in which case it is broadcast to other participants using the methods described above. Example 26: Juliet Exits the Chat Room (F31) | |O, look! methinks I see my cousin's ghost |6. MSRP Multi-party Messaging Session to XMPP MUC This section describes how to map a Multi-party Instant Message (IM) MSRP session to an XMPP MUC session. As before, the following diagram outlines the overall protocol flow of a sample session, which includes some optional exchanges (such as sending messages, changing nickname, and inviting another user).Saint-Andre, et al. Standards Track [Page 25] RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 SIP SIP MSRP XMPP User Proxy Switch Server | + S2X GW + M2X GW +X2S GW | | | +X2M GW | | | | | (F35) SIP | | | | INVITE | | | |****************>| | | | (F36) SIP | | | | 200 OK | | | |<****************| | | | (F37) SIP ACK | | | |****************>| | | | (F38) SIP | | | | SUBSCRIBE | | | | Event: | | | | conference | | | |****************>| | | | (F39) SIP | | | | 200 OK | | | |<****************| | | | | (F40) XMPP presence: enter room | | |..................................>| | | (F41) XMPP presence | | |<..................................| | (F42) SIP | | | | NOTIFY | | | |<****************| | | | (F43) SIP | | | | 200 OK | | | |****************>| | | . . . . . . . . | (F44) MSRP SEND | | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | | | | (F45) XMPP | | | | groupchat | | | | message | | | |................>| | | | (F46) XMPP | | | | groupchat | | | | message | | | |<................| | (F47) MSRP 200 OK | | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | . . . .Saint-Andre, et al. Standards Track [Page 26] RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 . . . . | (F48) MSRP SEND | | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | | (F49) MSRP 200 OK | | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | | | | (F50) XMPP | | | | message | | | |................>| . . . . . . . . | (F51) MSRP NICKNAME | | |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| | | | | (F52) XMPP | | | | presence | | | |................>| | | | (F53) XMPP | | | | presence | | | | error | | | |<................| | (F54) MSRP 425 Error | | |<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| | . . . . . . . . | (F55) SIP REFER | | | |****************>| | | | (F56) SIP | | | | 200 OK | | | |<****************| | | | (F57) SIP | | | | NOTIFY | | | |<****************| | | | | (F58) XMPP message invite | | |..................................>| . . . . . . . . | (F59) SIP BYE | | | |****************>| | | | | (F60) XMPP presence unavailable | | |..................................>| | | (F61) XMPP presence unavailable | | |<..................................| | (F62) SIP | | | | 200 OK | | | |<****************| | | | | | |Saint-Andre, et al. Standards Track [Page 27] RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 If the XMPP presence stanza is received before the SIP SUBSCRIBE dialog is established for the conference event, then the server SHOULD cache the participant list until the subscription is established and delivered in a SIP NOTIFY request.6.1. Enter Room When the SIP user ("Romeo") wants to join a groupchat room ("capulet"), he first has to start the SIP session by sending out a SIP INVITE request containing an offered session description that includes an MSRP media line accompanied by mandatory 'path' and 'chatroom' attributes. Here we assume that Romeo's user agent has been configured to be aware of an MSRP switch (chat.example.org) it can use. The MSRP media line is also accompanied by an 'accept- types' attribute specifying support for a Message/CPIM [RFC3862] top- level wrapper for the MSRP message. Example 27: SIP User Starts Session (F35) | INVITE sip:capulet@rooms.example.com SIP/2.0 | From: "Romeo";tag=43524545 | To: | Contact:;gr=dr4hcr0st3lup4c | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 1 INVITE | Content-Type: application/sdp | Content-Length: ... | | c=IN IP4 s2x.example.org | m=message 7313 TCP/MSRP * | a=accept-types:message/cpim text/plain text/html | a=accept-wrapped-types:text/plain text/html | a=path:msrp://chat.example.org:7313/ansp71weztas;tcp | a=chatroom:nickname private-messages Upon receiving the INVITE, the SIP proxy needs to determine the identity of the domain portion of the Request-URI or To header, which it does by following the procedures discussed in [RFC7247]. Here we assume that the SIP proxy has determined that the domain is serviced by an XMPP server, that it contains or has available to it a SIP-to- XMPP gateway or connection manager (which enables it to speak natively to XMPP servers), and that it hands off the message to the gateway. Implementations MAY wait until the nickname is set with an MSRP NICKNAME chunk before joining the XMPP MUC or MAY choose a temporary nickname (such as the SIP From header display name) and use it to join the room. Here we assume the latter.Saint-Andre, et al. Standards Track [Page 28] RFC 7702 SIP-XMPP Interworking: Groupchat December 2015 Example 28: SIP-to-XMPP Gateway ACKs Session (F36) | SIP/2.0 200 OK | From: "Romeo";tag=43524545 | To:;tag=a3343df32 | Contact:;isfocus | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 1 INVITE | Content-Type: application/sdp | | m=message 8763 TCP/MSRP * | a=accept-types:message/cpim text/plain text/html | a=accept-wrapped-types:text/plain text/html | a=path:msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp | a=chatroom:nickname private-messages The SIP/MSRP user agent subscribes to a conference event package at the destination groupchat service. Example 29: Gateway Subscribes to the Conference (F38) | SUBSCRIBE sip:capulet@rooms.example.com SIP/2.0 | To:;tag=a3343df32 | From: "Romeo";tag=43524545 | Contact:;gr=dr4hcr0st3lup4c | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 2 SUBSCRIBE | Event: conference | Expires: 600 | Accept: application/conference-info+xml | Allow-Events: conference | Content-Length: 0 After the conference subscription request is acknowledged, the SIP- to-XMPP gateway sends presence from Romeo to the MUC chat room. Example 30: Romeo Enters XMPP Chat Room (F40) | | |Saint-Andre, et al. Standards Track [Page 29] RFC 7702 SIP-XMPP Interworking: Groupchat December 20156.2. Presence Broadcast If the MUC service is able to add the SIP/MSRP user to the room, it sends presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in an element. Example 31: XMPP Service Sends Presence from Existing Occupants to New Occupant (F41) | | |
[8]ページ先頭