Movatterモバイル変換
[0]ホーム
Art thou not Romeo, and a Montague? | Upon receiving such a message stanza, the XMPP server needs to determine the identity of the domainpart in the 'to' address, which it does by following the procedures explained in Section 5 of [RFC7247]. If the domain is a SIP domain, the XMPP server will handSaint-Andre & Loreto Standards Track [Page 5] RFC 7573 SIP-XMPP Interworking: Chat June 2015 off the message stanza to an XMPP-to-SIP gateway or connection manager that natively communicates with MSRP-aware SIP servers. The XMPP-to-SIP gateway at the XMPP server would then initiate an MSRP session with Romeo on Juliet's behalf (since there is no reliable way for the gateway to determine whether Romeo's client supports MSRP, if that is not the case then MSRP session initiation might result in an error). Example 2: Gateway Starts SIP Session on Behalf of Juliet (F3) | INVITE sip:romeo@example.net SIP/2.0 | To: | From: | Contact:;gr=yn0cl4bnw0yr3vym | Subject: Open chat with Juliet? | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 | CSeq: 1 INVITE | Content-Type: application/sdp | | c=IN IP4 x2s.example.com | m=message 7654 TCP/MSRP * | a=accept-types:text/plain | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp Here we assume that Romeo's client supports MSRP and that Romeo accepts the MSRP session request. Example 3: Romeo Accepts Session Request (F5) | SIP/2.0 200 OK | From: | To: | Contact:;gr=dr4hcr0st3lup4c | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 | CSeq: 1 INVITE | Content-Type: application/sdp | | c=IN IP4 s2x.example.net | m=message 12763 TCP/MSRP * | a=accept-types:text/plain | a=path:msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp The XMPP-to-SIP gateway then acknowledges the session acceptance on behalf of Juliet.Saint-Andre & Loreto Standards Track [Page 6] RFC 7573 SIP-XMPP Interworking: Chat June 2015 Example 4: Gateway Sends ACK to Romeo (F7) | ACK sip:juliet@example.com SIP/2.0 | To:;gr=dr4hcr0st3lup4c | From: | Contact:;gr=yn0cl4bnw0yr3vym | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 | CSeq: 2 ACK The XMPP-to-SIP gateway then transforms the original XMPP chat message into MSRP. Example 5: Gateway Maps XMPP Message to MSRP (F9) | MSRP a786hjs2 SEND | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp | To-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp | Message-ID: 54C6F4F1-A39C-47D6-8718-FA65B3D0414A | Byte-Range: 1-25/25 | Content-Type: text/plain | | Art thou not Romeo, and a Montague? | -------a786hjs2$ Romeo can then send a reply using his MSRP client. Example 6: Romeo Sends Reply (F10) | MSRP di2fs53v SEND | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp | From-Path: msrp://s2x.example.net:12763/kjhd37s2s20w2a;tcp | Message-ID: 6480C096-937A-46E7-BF9D-1353706B60AA | Byte-Range: 1-25/25 | Failure-Report: no | Content-Type: text/plain | | Neither, fair saint, if either thee dislike. | -------di2fs53v$ The SIP-to-XMPP gateway would then transform that message into appropriate XMPP syntax for routing to the intended recipient.Saint-Andre & Loreto Standards Track [Page 7] RFC 7573 SIP-XMPP Interworking: Chat June 2015 Example 7: Gateway Maps MSRP Message to XMPP (F11) | |29377446-0CBB-4296-8958-590D79094C50 | Neither, fair saint, if either thee dislike. | When the MSRP user wishes to end the chat session, the user's MSRP client sends a SIP BYE. Example 8: Romeo Terminates Chat Session (F13) | BYE juliet@example.com sip: SIP/2.0 | From:;tag=786 | To:;tag=087js | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 | CSeq: 3 BYE | Content-Length: 0 The BYE is then acknowledged by the XMPP-to-SIP gateway. Example 9: Gateway Acknowledges Termination (F15) | SIP/2.0 200 OK | From:;tag=786 | To:;tag=087js | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 | CSeq: 3 BYE | Content-Length: 0 Because there is no formal session on the XMPP side, there is no corresponding communication from the gateway to the XMPP user. However, it is reasonable for the gateway to send a "gone" chat state notification [XEP-0085], as described under Section 6.1. In addition, there is no explicit method defined in [RFC6121] for an XMPP user to formally terminate a chat session, so a gateway would need to listen for a "gone" chat state notification from the XMPP user or institute a timer that considers the XMPP informal chat session to be ended after some amount of time has elapsed ([XEP-0085] suggests generating a "gone" chat state if a user has not interacted with the chat session interface, system, or device for a relatively long period of time, e.g., 10 minutes).Saint-Andre & Loreto Standards Track [Page 8] RFC 7573 SIP-XMPP Interworking: Chat June 20155. MSRP to XMPP When an MSRP client sends messages through a gateway to an XMPP client, the order of events is as follows. SIP SIP MSRP-to-XMPP XMPP XMPP User Server Gateway Server User | | | | | | (F17) SIP | | | | | INVITE | | | | |**************>| | | | | | (F18) SIP | | | | | INVITE | | | | |**************>| | | | | (F19) SIP | | | | | 200 OK | | | | |<**************| | | | (F20) SIP | | | | | 200 OK | | | | |<**************| | | | | (F21) SIP ACK | | | | |**************>| | | | | | (F22) SIP ACK | | | | |**************>| | | | (F23) MSRP SEND | | | |******************************>| | | | | | (F24) XMPP | | | | | message | | | | |..............>| | | | | | (F25) XMPP | | | | | message | | | | |..............>| . . . . . . . . . . | | | | (F26) XMPP | | | | | message | | | | |<..............| | | | (F27) XMPP | | | | | message | | | | |<..............| | | (F28) MSRP SEND | | | |<******************************| | | . . . . . . . . . . | | | | | | | | | | | (F29) SIP BYE | | | | |**************>| | | |Saint-Andre & Loreto Standards Track [Page 9] RFC 7573 SIP-XMPP Interworking: Chat June 2015 | | (F30) SIP BYE | | | | |**************>| | | | | (F31) SIP | | | | | 200 OK | | | | |<**************| | | | (F32) SIP | | | | | 200 OK | | | | |<**************| | | | Figure 2: MSRP to XMPP Order of Events The mapping of SIP syntax to XMPP syntax MUST be as specified in [RFC7572]. The protocol flow begins when Romeo starts a chat session with Juliet. Example 10: Romeo Starts Chat Session (F17) | INVITE sip:juliet@example.com SIP/2.0 | From: | To: | Contact:;gr=dr4hcr0st3lup4c | Subject: Open chat with Romeo? | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F | CSeq: 1 INVITE | Content-Type: application/sdp | | c=IN IP4 s2x.example.net | m=message 7313 TCP/MSRP * | a=accept-types:text/plain | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp Upon receiving the INVITE, the SIP (MSRP) server needs to determine the identity of the domain portion of the Request-URI or To header, which it does by following the procedures explained in Section 5 of [RFC7247]. If the domain is an XMPP domain, the SIP server will hand off the INVITE to an associated MSRP-to-XMPP gateway or connection manager that natively communicates with XMPP servers.Saint-Andre & Loreto Standards Track [Page 10] RFC 7573 SIP-XMPP Interworking: Chat June 2015 Example 11: Gateway Accepts Session on Juliet's Behalf (F19) | SIP/2.0 200 OK | From:;gr=dr4hcr0st3lup4c | To: | Contact:;gr=yn0cl4bnw0yr3vym | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F | CSeq: 1 INVITE | Content-Type: application/sdp | | c=IN IP4 x2s.example.com | m=message 8763 TCP/MSRP * | a=accept-types:text/plain | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp Example 12: Romeo Sends ACK (F21) | ACK sip:juliet@example.com SIP/2.0 | To:;gr=yn0cl4bnw0yr3vym | From: | Contact:;gr=dr4hcr0st3lup4c | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F | CSeq: 2 ACK Example 13: Romeo Sends Message (F23) | MSRP ad49kswow SEND | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp | Message-ID: 676FDB92-7852-443A-8005-2A1B9FE44F4E | Byte-Range: 1-32/32 | Failure-Report: no | Content-Type: text/plain | | I take thee at thy word ... | -------ad49kswow$ Example 14: MSRP-to-XMPP Gateway Maps MSRP Message to XMPP (F24) | |F6989A8C-DE8A-4E21-8E07-F0898304796F | I take thee at thy word ... |Saint-Andre & Loreto Standards Track [Page 11] RFC 7573 SIP-XMPP Interworking: Chat June 2015 Example 15: Juliet Sends Reply (F26) | |29377446-0CBB-4296-8958-590D79094C50 | What man art thou ...? | Example 16: Gateway Maps XMPP Message to MSRP (F28) | MSRP ms53b7z9 SEND | To-Path: msrp://s2x.example.net:7313/jshA7weztas;tcp | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp | Message-ID: 17EBA17B-94C0-463B-AD84-DE405C4C9D41 | Byte-Range: 1-25/25 | Failure-Report: no | Content-Type: text/plain | | What man art thou ...? | -------ms53b7z9$ Example 17: Romeo Terminates Chat Session (F29) | BYE juliet@example.com sip: SIP/2.0 | To:;gr=yn0cl4bnw0yr3vym | From: | Contact:;gr=dr4hcr0st3lup4c | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F | CSeq: 3 BYE | Content-Length: 0 Example 18: Gateway Acknowledges Termination of Session on Behalf of Juliet (F31) | SIP/2.0 200 OK | To:;gr=yn0cl4bnw0yr3vym | From: | Contact:;gr=dr4hcr0st3lup4c | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F | CSeq: 3 BYESaint-Andre & Loreto Standards Track [Page 12] RFC 7573 SIP-XMPP Interworking: Chat June 20156. Composing Events Both XMPP and MSRP enable a client to receive notifications when a person's conversation partner is composing an instant message within the context of a chat session. For XMPP, the Chat State Notifications specification [XEP-0085] defines five states: active, inactive, gone, composing, and paused. Some of these states are related to the act of message composition (composing, paused), whereas others are related to the sender's involvement with the chat session (active, inactive, gone). Note that the "gone" chat state is not to be confused with the stanza error condition defined in [RFC6120]. For MSRP (and, in general, for so-called SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) systems), the Indication of Message Composition for Instant Messaging specification [RFC3994] defines two states: idle and active. Here the idle state indicates that the sender is not actively composing a message, and the active state indicates that the sender is indeed actively composing a message (the sending client simply toggles between the two states). Because XEP-0085 states can represent information that is not captured in RFC 3994, gateways can either (a) map only the composing- related states or (b) map all the XEP-0085 states. The following mappings are suggested. Table 3: Mapping of SIP/SIMPLE isComposing Events to XMPP Chat states +-------------------+--------------------+ | isComposing Event | Chat State | +-------------------+--------------------+ | active | composing | | idle | active | +-------------------+--------------------+ Table 4: Mapping of XMPP Chat States to SIP/SIMPLE isComposing Events +-------------------+--------------------+ | Chat State | isComposing Event | +-------------------+--------------------+ | active | idle | | inactive | idle | | gone | none (Section 6.1)| | composing | active | | paused | idle | +-------------------+--------------------+Saint-Andre & Loreto Standards Track [Page 13] RFC 7573 SIP-XMPP Interworking: Chat June 2015 The XMPP Chat State Notifications specification [XEP-0085] allows the sending of "standalone notifications" outside the context of a message, theoretically even before any messages are exchanged; although a gateway could thus send an notification to the XMPP user when the SIP user accepts or initiates a chat session (i.e., after F6 in Section 4 or after F22 in Section 5), this usage might be unexpected by XMPP clients as a way to signal the beginning of an informal chat session.6.1. Use of the Gone Chat State Although there is no direct mapping for the "gone" chat state to an isComposing event, receipt of the "gone" state at an XMPP-to-MSRP gateway can serve as a trigger for terminating the formal chat session within MSRP, i.e., for sending a SIP BYE for the session from the XMPP-to-MSRP gateway to the SIP user. The following examples illustrate this indirect mapping (which would arise if, for example, the XMPP user were to send a "gone" chat state notification after step F12 in Figure 1 or step F28 in Figure 2; in either of these cases, the session would be terminated by the XMPP user instead of by the SIP user, as currently shown in Figures 1 and 2). Example 19: Juliet Sends Gone Chat State | |29377446-0CBB-4296-8958-590D79094C50 | | Example 20: XMPP-to-MSRP Gateway Maps Gone Chat State to SIP BYE | BYE romeo@example.net sip: SIP/2.0 | From:;tag=786 | To:;tag=087js | Call-ID: 29377446-0CBB-4296-8958-590D79094C50 | CSeq: 3 BYE | Content-Length: 0 Similarly, receipt of a SIP BYE message at an MSRP-to-XMPP gateway can serve as a trigger for sending a "gone" chat state notification to the XMPP user. The following examples illustrate this indirect mapping (which would occur after step F14 in Figure 1 or step F30 in Figure 2).Saint-Andre & Loreto Standards Track [Page 14] RFC 7573 SIP-XMPP Interworking: Chat June 2015 Example 21: Romeo Terminates Chat Session | BYE juliet@example.com sip: SIP/2.0 | To:;gr=yn0cl4bnw0yr3vym | From: | Contact:;gr=dr4hcr0st3lup4c | Call-ID: F6989A8C-DE8A-4E21-8E07-F0898304796F | CSeq: 3 BYE | Content-Length: 0 Example 22: MSRP-to-XMPP Gateway Generates Gone Chat State | |F6989A8C-DE8A-4E21-8E07-F0898304796F | | To enable these uses, gateways that support chat state notifications MUST support the "gone" state (which is merely recommended, not required, by [XEP-0085]). It is also reasonable for gateways to implement timers that automatically trigger a "gone" chat state if the XMPP user has not sent a message within the "session" for a given amount of time ([XEP-0085] suggests generating a "gone" chat state if a user has not interacted with the chat session interface, system, or device for a relatively long period of time, e.g., 10 minutes).7. Delivery Reports Both XMPP and MSRP enable a client to receive notifications when a message has been received by the intended recipient. For XMPP, the Message Receipts specification [XEP-0184] defines a method and XML namespace for requesting and returning indications that a message has been received by a client controlled by the intended recipient. For MSRP, a native reporting feature is included, in the form of REPORT chunks (see Sections 7.1.2 and 7.1.3 of [RFC4975]). An XMPP Message Receipts element of is to be mapped to an MSRP Success-Report header field with a value of "yes", and an XMPP Message ReceiptsSaint-Andre & Loreto Standards Track [Page 15] RFC 7573 SIP-XMPP Interworking: Chat June 2015 element of is to be mapped to an MSRP REPORT request. A Success-Report header field with a value of "yes" in an MSRP SEND request is to be mapped to an XMPP Message Receipts element of, and an MSRP REPORT request is to be mapped to an XMPP message containing only a Message Receipts element of. Because the XMPP Message Receipts specification does not support failure reports, there is no mapping for the MSRP Failure-Report header field and gateways SHOULD set that header field to "no". Examples follow. First, the XMPP user sends a message containing a request for delivery notification. Example 23: Juliet Sends XMPP Message with Receipt Request | |29377446-0CBB-4296-8958-590D79094C50 | What man art thou ...?
[8]ページ先頭