MSRP协议详解：RFC4975标准与应用

3星 · 超过75%的资源需积分: 50 87 浏览量更新于2024-07-23 收藏 90KB PDF 举报

MSRP（Message Session Relay Protocol）协议规范RFC 4975由网络工作小组的B. Campbell、R. Mahy、C. Jennings等人共同编撰，于2007年9月发布。这份文档旨在为互联网社区提供一个标准的通信协议，用于在会话上下文中传输一系列相关的即时消息，例如通过诸如会话发起协议（SIP）等会话创建协议进行设置的媒体流。 1. **介绍**：MSRP的设计目的是增强即时通讯的效率和功能，特别关注于那些需要连续或相关的消息传输场景。它将消息会话视为与其他媒体流一样的资源，允许在多个参与方之间建立可靠且有序的消息传递路径。 2. **标准与适用性**：该规范适用于任何需要高效处理即时消息的网络环境，特别是那些依赖于会话控制协议的地方。RFC 4975处于Internet Standards Track级别，意味着它是一个正在发展中并且公开讨论的标准，建议所有网络服务提供商和技术开发者参考以保持同步。 3. **协议概述**：MSRP基于UDP协议，并采用可靠的数据包传输机制。它利用了分段和重组技术（Message Chunking），允许消息被拆分成可管理的块进行传输，即使在网络不稳定时也能确保消息的完整性和顺序。 4. **关键概念**： - **MSRP帧和消息分段**：MSRP消息以特定格式封装，包括头部信息和数据部分。帧结构清晰，便于解析和处理。消息被分割成可独立传输的块，每个块都带有标识符和序列号，以便接收端正确组合成原始消息。 - **会话管理**：MSRP支持多对多和一对一的消息传递模式，通过会话标识符（Session ID）管理不同会话中的消息流，确保消息路由到正确的接收者。 - **可靠性**：MSRP通过重传机制和确认应答来保证消息的可靠传输，即使在网络拥塞或丢包的情况下也能维持消息的一致性。 - **安全性**：虽然RFC 4975并未详述安全措施，但实际应用中可能需要配合SSL/TLS等加密技术以保护通信内容。 RFC 4975 MSRP协议规范为实时消息传输提供了标准化的解决方案，其核心在于高效地组织和传输相关消息，确保在各种网络环境下都能实现可靠、有序的通信。对于任何涉及即时通讯平台开发、网络服务部署或协议优化的工程师来说，深入理解和掌握MSRP协议是至关重要的。

RFC 4975 MSRP September 2007

5.3. MSRP Transaction and Report Model

A sender sends MSRP requests to a receiver. The receiver MUST

quickly accept or reject the request. If the receiver initially

accepted the request, it still may then do things that take

significant time to succeed or fail. For example, if the receiver is

an MSRP to Extensible Messaging and Presence Protocol (XMPP) [30]

gateway, it may forward the message over XMPP. The XMPP side may

later indicate that the request did not work. At this point, the

MSRP receiver may need to indicate that the request did not succeed.

There are two important concepts here: first, the hop-by-hop delivery

of the request may succeed or fail; second, the end result of the

request may or may not be successfully processed. The first type of

status is referred to as "transaction status" and may be returned in

response to a request. The second type of status is referred to as

"delivery status" and may be returned in a REPORT transaction.

The original sender of a request can indicate if they wish to receive

reports for requests that fail, and can independently indicate if

they wish to receive reports for requests that succeed. A receiver

only sends a success REPORT if it knows that the request was

successfully delivered, and the sender requested a success report. A

receiver only sends a failure REPORT if the request failed to be

delivered and the sender requested failure reports.

This document describes the behavior of MSRP endpoints. MSRP

relays will introduce additional conditions that indicate a

failure REPORT should be sent, such as the failure to receive a

positive response from the next hop.

Two header fields control the sender’s desire to receive reports.

The Success-Report header field can have a value of "yes" or "no" and

the Failure-Report header field can have a value of "yes", "no", or

"partial".

The combinations of reporting are needed to meet the various

scenarios of currently deployed IM systems. Success-Report might be

"no" in many public systems to reduce load, but might be "yes" in

certain enterprise systems, such as systems used for securities

trading. A Failure-Report value of "no" is useful for sending system

messages such as "the system is going down in 5 minutes" without

causing a response explosion to the sender. A Failure-Report of

"yes" is used by many systems that wish to notify the user if the

message failed. A Failure-Report of "partial" is a way to report

errors other than timeouts. Timeout error reporting requires the

sending hop to run a timer and the receiving hop to send an

Campbell, et al. Standards Track [Page 11]

RFC 4975 MSRP September 2007

acknowledgment to stop the timer. Some systems don’t want the

overhead of doing this. "Partial" allows them to choose not to do

so, but still allows error responses to be sent in many cases.

The term "partial" denotes that the hop-by-hop acknowledgment

mechanism that would be required with a Failure-Report value of

"yes" is not invoked. Thus, each device uses only "part" of the

set of error detection tools available to them. This allows a

compromise between no reporting of failures at all, and reporting

every possible failure. For example, with "partial", a sending

device does not have to keep transaction state around waiting for

a positive acknowledgment. But it still allows devices to report

other types of errors. The receiving device could still report a

policy violation such as an unacceptable content-type, or an ICMP

error trying to connect to a downstream device.

5.4. MSRP Connection Model

When an MSRP endpoint wishes to send a request to a peer identified

by an MSRP URI, it first needs a transport connection, with the

appropriate security properties, to the host specified in the URI.

If the sender already has such a connection, that is, one associated

with the same host, port, and URI scheme, then it SHOULD reuse that

connection.

When a new MSRP session is created, the initiating endpoint MUST act

as the "active" endpoint, meaning that it is responsible for opening

the transport connection to the answerer, if a new connection is

required. However, this requirement MAY be weakened if standardized

mechanisms for negotiating the connection direction become available

and are implemented by both parties to the connection.

Likewise, the active endpoint MUST immediately issue a SEND request.

This initial SEND request MAY have a body if the sender has content

to send, or it MAY have no body at all.

The first SEND request serves to bind a connection to an MSRP

session from the perspective of the passive endpoint. If the

connection is not authenticated with TLS, and the active endpoint

did not send an immediate request, the passive endpoint would have

no way to determine who had connected, and would not be able to

safely send any requests towards the active party until after the

active party sends its first request.

When an element needs to form a new connection, it looks at the URI

to decide on the type of connection (TLS, TCP, etc.) then connects to

the host indicated by the URI, following the URI resolution rules in

Section 6.2. Connections using the "msrps" scheme MUST use TLS. The

Campbell, et al. Standards Track [Page 12]

RFC 4975 MSRP September 2007

SubjectAltName in the received certificate MUST match the hostname

part of the URI and the certificate MUST be valid according to RFC

3280 [16], including having a date that is valid and being signed by

an acceptable certification authority. At this point, the device

that initiated the connection can assume that this connection is with

the correct host.

The rules on certificate name matching and CA signing MAY be relaxed

when using TLS peer-to-peer. In this case, a mechanism to ensure

that the peer used a correct certificate MUST be used. See Section

14.4 for details.

If the connection used mutual TLS authentication, and the TLS client

presented a valid certificate, then the element accepting the

connection can verify the identity of the connecting device by

comparing the hostname part of the target URI in the SDP provided by

the peer device against the SubjectAltName in the client certificate.

When mutual TLS authentication is not used, the listening device MUST

wait until it receives a request on the connection, at which time it

infers the identity of the connecting device from the associated

session description.

When the first request arrives, its To-Path header field should

contain a URI that the listening element provided in the SDP for a

session. The element that accepted the connection looks up the URI

in the received request, and determines which session it matches. If

a match exists, the node MUST assume that the host that formed the

connection is the host to which this URI was given. If no match

exists, the node MUST reject the request with a 481 response. The

node MUST also check to make sure the session is not already in use

on another connection. If the session is already in use, it MUST

reject the request with a 506 response.

If it were legal to have multiple connections associated with the

same session, a security problem would exist. If the initial SEND

request is not protected, an eavesdropper might learn the URI, and

use it to insert messages into the session via a different

connection.

If a connection fails for any reason, then an MSRP endpoint MUST

consider any sessions associated with the connection as also having

failed. When either endpoint notices such a failure, it MAY attempt

to re-create any such sessions. If it chooses to do so, it MUST use

a new SDP exchange, for example, in a SIP re-INVITE. If a

replacement session is successfully created, endpoints MAY attempt to

resend any content for which delivery on the original session could

not be confirmed. If it does this, the Message-ID values for the

Campbell, et al. Standards Track [Page 13]

剩余62页未读，继续阅读

zmh826596143

粉丝: 0
资源: 1

MSRP协议详解：RFC4975标准与应用

深入解析MSRP协议与Java源码学习指南

MSRP协议解析：设计与实现方法

MSRP 4975：5G消息中的文件传输协议详解

MSRP_协议的分析、设计与实现.pdf

Protocol(MSRP).rar_Java编程_Java_

RCS 5.1协议

直控零售协议（DOC格式）

WebSocket实现实时SIP和MSRP通信

MSRP协议是如何保证消息传输的可靠性和顺序性的，它采用了哪些技术手段？

MSRP在IMS网络中的统一IM解决方案与应用前景

最新资源