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 hand off the message stanza to an XMPP-to-SIP gateway or connection manager that natively communicates with IM-aware SIP servers. The XMPP-to-SIP gateway is then responsible for translating the XMPP message stanza into a SIP MESSAGE request from the XMPP user to the SIP user: Example 2: XMPP User Sends Message (SIP Transformation) | MESSAGE sip:romeo@example.net SIP/2.0 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse | Max-Forwards: 70 | To: sip:romeo@example.net | From:;tag=12345 | Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA | CSeq: 1 MESSAGE | Content-Type: text/plain | Content-Length: 35 | | Art thou not Romeo, and a Montague?Saint-Andre, et al. Standards Track [Page 4] RFC 7572 SIP-XMPP Interworking: IM June 2015 The destination SIP server is responsible for delivering the message to the intended recipient, and the recipient is responsible for generating a response (e.g., 200 OK). Example 3: SIP User Agent Indicates Receipt of Message | SIP/2.0 200 OK | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse | From: sip:juliet@example.com;tag=12345 | To: sip:romeo@example.net;tag=vwxyz | Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA | CSeq: 1 MESSAGE | Content-Length: 0 As described in [RFC3428], a downstream proxy could fork a MESSAGE request, but it would return only one 200 OK to the gateway. Note: This document does not specify handling of the 200 OK by the XMPP-to-SIP gateway (e.g., to enable message acknowledgements). See [RFC7573] for a mapping of message acknowledgements in the context of one-to-one chat sessions. The mapping of XMPP syntax to SIP syntax MUST be as shown in the following table. Table 1: Message Syntax Mapping from XMPP to SIP +-----------------------------+--------------------------+ | XMPP Element or Attribute | SIP Header or Contents | +-----------------------------+--------------------------+ | | body of MESSAGE | | | Subject | | | Call-ID | | from | From (1) | | id | transaction identifier | | to | To or Request-URI | | type | (no mapping) (2) | | xml:lang | Content-Language | +-----------------------------+--------------------------+ 1. As shown in the foregoing example and described in [RFC7247], the XMPP-to-SIP gateway MUST map the bare JID ("localpart@domainpart") of the XMPP sender to the SIP From header and include the resourcepart of the "full JID" ("localpart@domainpart/resourcepart") as the Globally Routable User Agent URI (GRUU) portion [RFC5627] of the SIP URI.Saint-Andre, et al. Standards Track [Page 5] RFC 7572 SIP-XMPP Interworking: IM June 2015 2. Because there is no SIP header field that matches the meaning of the XMPP message 'type' values ("normal", "chat", "groupchat", "headline", "error"), no general mapping is possible here.5. SIP to XMPP As described in [RFC3428], a single instant message is a SIP MESSAGE request sent from a SIP user agent to an intended recipient who is most generally referenced by an Instant Messaging (IM) URI [RFC3861] of the form but who might be referenced by a SIP or SIPS URI of the form or. When a SIP user Romeo with a SIP URI of wants to send an instant message to Juliet, he interacts with his SIP user agent, which generates a SIP MESSAGE request. The syntax of the MESSAGE request is defined in [RFC3428]. The following is an example of such a request: Example 4: SIP User Sends Message | MESSAGE sip:juliet@example.com SIP/2.0 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677 | Max-Forwards: 70 | To: sip:juliet@example.com | From: sip:romeo@example.net;tag=vwxyz | Call-ID: 9E97FB43-85F4-4A00-8751-1124FD4C7B2E | CSeq: 1 MESSAGE | Content-Type: text/plain | Content-Length: 44 | | Neither, fair saint, if either thee dislike. Section 5 of [RFC3428] stipulates that a SIP user agent presented with an im: URI should resolve it to a sip: or sips: URI. Therefore, we assume that the Request-URI of a request received by an IM-capable SIP-to-XMPP gateway will contain a sip: or sips: URI. Upon receiving the MESSAGE, the SIP 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 MESSAGE to an associated SIP-to-XMPP gateway or connection manager that natively communicates with XMPP servers. The SIP-to-XMPP gateway is then responsible for translating the request into an XMPP message stanza from the SIP user to the XMPP user and returning a SIP 200 OK message to the sender:Saint-Andre, et al. Standards Track [Page 6] RFC 7572 SIP-XMPP Interworking: IM June 2015 Example 5: SIP User Sends Message (XMPP Transformation) | | Neither, fair saint, if either thee dislike. | Note that the stanza-handling rules specified in [RFC6121] allow the receiving XMPP server to deliver a message stanza whose 'to' address is a bare JID ("localpart@domainpart") to multiple connected devices. This is similar to the "forking" of messages in SIP. The mapping of SIP syntax to XMPP syntax MUST be as shown in the following table. Table 2: Message Syntax Mapping from SIP to XMPP +--------------------------+-----------------------------+ | SIP Header or Contents | XMPP Element or Attribute | +--------------------------+-----------------------------+ | Call-ID | | | Content-Language | xml:lang | | CSeq | (no mapping) | | From | from (1) | | Subject | | | Request-URI or To | to | | body of MESSAGE | | | transaction identifier | id | +--------------------------+-----------------------------+ 1. As shown in the foregoing example and described in [RFC7247], if the IM-capable SIP-to-XMPP gateway has information about the GRUU [RFC5627] of the particular endpoint that sent the SIP message, then it MUST map the sender's address to a full JID ("localpart@domainpart/resourcepart") in the 'from' attribute of the XMPP stanza and include the GRUU as the resourcepart. When transforming SIP pager-mode messages, an IM-capable SIP-to-XMPP gateway MUST specify no XMPP 'type' attribute or, equivalently, a 'type' attribute whose value is "normal" [RFC6121]. See Section 7 of this document about the handling of SIP message bodies that contain content types other than plain text.Saint-Andre, et al. Standards Track [Page 7] RFC 7572 SIP-XMPP Interworking: IM June 20156. Message Size [RFC3428] specifies that (outside of a media session) the size of a MESSAGE request is not allowed to exceed 1300 bytes. Although, in practice, XMPP instant messages do not often exceed that size, neither [RFC6120] nor [RFC6121] sets an upper limit on the size of XMPP stanzas. However, XMPP server deployments usually do limit the size of stanzas in order to help prevent denial-of-service attacks, and [RFC6120] states that if a server sets a maximum stanza size, then the limit is not allowed to be less than 10,000 bytes. Because of this mismatch, an XMPP-to-SIP gateway SHOULD return a stanza error if an XMPP user attempts to send an XMPP message stanza that would result in a SIP MESSAGE greater than 1300 bytes. Although such a gateway might decide to "upgrade" from page mode to session mode using the Message Session Relay Protocol (MSRP) -- thus treating the instant message as part of a chat session as described in [RFC7573] -- such behavior is application-specific and this document provides no guidelines for how to complete such an upgrade.7. Content Types SIP requests of type "MESSAGE" are allowed to contain essentially any content type. The recommended procedures for SIP-to-XMPP gateways to use in handling these content types are as follows. An IM-aware SIP-to-XMPP gateway MUST process SIP messages that contain message bodies of type "text/plain" and MUST encapsulate such message bodies as the XML character data of the XMPP element. An IM-aware SIP-to-XMPP gateway SHOULD process SIP messages that contain message bodies of type "text/html"; if so, a gateway MUST transform the "text/html" content into XHTML content that conforms to the XHTML-IM Integration Set specified in [XEP-0071]. Although an IM-aware SIP-to-XMPP gateway MAY process SIP messages that contain message bodies of types other than "text/plain" and "text/html", the handling of such content types is a matter of implementation.Saint-Andre, et al. Standards Track [Page 8] RFC 7572 SIP-XMPP Interworking: IM June 20158. Internationalization Considerations Both XMPP and SIP support the UTF-8 encoding [RFC3629] of Unicode characters [UNICODE] within messages, along with tagging of the language for a particular message (in XMPP via the 'xml:lang' attribute and in SIP via the Content-Language header). Gateways MUST map these language tagging mechanisms if they are present in the original message. Several examples follow, using the "XML Notation" [RFC3987] for Unicode characters outside the ASCII range. Example 6: SIP User Sends Message | MESSAGE sip:juliet@example.com SIP/2.0 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677 | Max-Forwards: 70 | To: sip:juliet@example.com | From: sip:romeo@example.net;tag=vwxyz | Call-ID: 5A37A65D-304B-470A-B718-3F3E6770ACAF | CSeq: 1 MESSAGE | Content-Type: text/plain | Content-Length: 45 | Content-Language: cs | | Nic z ob쎩ho, m쎡 d쒛vo spanil쎡, | nenavid쎭얡-li jedno nebo druh쎩. Example 7: SIP User Sends Message (XMPP Transformation) | | | Nic z ob쎩ho, m쎡 d쒛vo spanil쎡, | nenavid쎭얡-li jedno nebo druh쎩. |
[8]ページ先頭