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

需积分: 10 151 浏览量更新于2024-07-09 收藏 189KB PDF 举报

MSRP-rfc4975.pdf是关于5G消息中的一个关键组成部分——消息会话转发协议（Message Session Relay Protocol，MSRP）。这一标准由Network Working Group B. Campbell等人在2007年9月提出，属于Internet Standards Track级别，旨在规范互联网环境中一系列相关即时消息的传输。5G消息（富媒体消息）和实时通信系统（RCS）的背景下，MSRP允许在会话设置（通过诸如Session Initiation Protocol（SIP）等会话创建协议）期间，将消息视为媒体流进行处理。文档详细阐述了MSRP的主要特性和技术细节： 1. **介绍**：文档首先介绍了MSRP的目的，即提供一种可靠的、基于互联网的协议，支持消息的有序发送和接收，尤其适用于需要连续发送的多媒体消息场景。 2. **约定与适用性**：文档遵循了标准的网络通信约定，并明确指出MSRP适用于任何支持SIP或其他类似会话管理协议的环境，旨在增强实时通信功能。 3. **协议概述**：MSRP构建在UDP之上，提供了一种基于数据包的传输机制，通过数据包的分片和重组来处理长消息。它强调了消息的有序传递和错误恢复机制。 4. **关键概念**： - **MSRP帧和消息拆分**：MSRP消息被划分为多个可选的分块（message chunks），每个分块独立发送，接收方可以根据序号重新组装。这提高了消息的可靠性和灵活性。 - **会话管理**：MSRP与会话建立过程紧密结合，确保消息在整个会话期间保持一致性，支持多个参与者之间的交互。 - **可靠性与重传**：MSRP采用确认机制来保证消息的到达，如果某个分块丢失，会自动触发重传，提高消息的完整性。 5. **安全性与隐私**：虽然标准本身不包含安全措施，但建议在实际应用中结合其他安全协议，如TLS/SSL，以保护消息内容免受未经授权的访问。 MSRP的标准化和广泛部署对于5G网络和富媒体通信服务至关重要，它使得应用程序能够实现高效的、可靠的多媒体消息传递，为用户提供无缝的实时交流体验。随着5G技术的发展，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页未读，继续阅读

sz_acrd

粉丝: 0

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

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

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

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

中国汽车保值率研究报告-君迪&58汽车&优信-2020.3-35页.pdf

2022零售行业年度策略：消费品掘金三战法，相信逻辑，回归消费品盈利能力本源-2022.2.pdf

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

Wish上面的细节.pdf

亚马逊购物的用户体验分析.pdf

2022中国汽车保值率研究报告.pdf

SIP服务器调查报告[归类].pdf

最新资源