Network Working Group R. Ejzak
Request for Comments: 5009 Alcatel-Lucent
Category: Informational September 2007
Network Working Group R. Ejzak
Request for Comments: 5009 Alcatel-Lucent
Category: Informational September 2007
Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media
会话启动协议（SIP）的专用头（P头）扩展，用于早期媒体的授权
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet-converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state.
本文档描述了欧洲电信标准协会（ETSI）电信和互联网融合服务及高级网络协议（TISPAN）使用的专用会话发起协议（SIP）报头字段（P报头）用于授权第三代合作伙伴项目（3GPP）IP多媒体子系统（IMS）中的早期媒体流。此标头字段在与其他SIP网络互连的任何SIP网络中都很有用，并且需要在早期对话状态下控制媒体流。
Table of Contents
目录
1. Introduction ....................................................2
2. Applicability Statement .........................................3
3. Conventions and Acronyms ........................................3
4. Background on Early Media Authorization .........................4
4.1. Backward Early Media .......................................5
4.2. Forward Early Media ........................................5
5. Applicability of RFC 3959 and RFC 3960 ..........................6
6. Overview of Operation ...........................................6
7. Limitations of the P-Early-Media Header Field ...................8
8. The P-Early-Media Header Field ..................................8
8.1. Procedures at the User Agent Client .......................10
8.2. Procedures at the User Agent Server .......................10
8.3. Procedures at the Proxy ...................................11
9. Formal Syntax ..................................................11
10. Security Considerations .......................................11
11. IANA Considerations ...........................................12
11.1. Registration of the "P-Early-Media" SIP Header Field .....12
12. Acknowledgements ..............................................12
13. References ....................................................12
13.1. Normative References .....................................12
13.2. Informative References ...................................13
1. Introduction ....................................................2
2. Applicability Statement .........................................3
3. Conventions and Acronyms ........................................3
4. Background on Early Media Authorization .........................4
4.1. Backward Early Media .......................................5
4.2. Forward Early Media ........................................5
5. Applicability of RFC 3959 and RFC 3960 ..........................6
6. Overview of Operation ...........................................6
7. Limitations of the P-Early-Media Header Field ...................8
8. The P-Early-Media Header Field ..................................8
8.1. Procedures at the User Agent Client .......................10
8.2. Procedures at the User Agent Server .......................10
8.3. Procedures at the Proxy ...................................11
9. Formal Syntax ..................................................11
10. Security Considerations .......................................11
11. IANA Considerations ...........................................12
11.1. Registration of the "P-Early-Media" SIP Header Field .....12
12. Acknowledgements ..............................................12
13. References ....................................................12
13.1. Normative References .....................................12
13.2. Informative References ...................................13
This document defines the use of the P-Early-Media header field for use within SIP [1] messages in certain SIP networks to authorize the cut-through of backward and/or forward early media when permitted by the early media policies of the networks involved. The P-Early-Media header field is intended for use in a SIP network, such as a 3GPP IMS [13][14] that has the following characteristics: its early media policy prohibits the exchange of early media between end users; it is interconnected with other SIP networks that have unknown, untrusted, or different policies regarding early media; and it has the capability to "gate" (enable/disable) the flow of early media to/from user equipment.
本文档定义了在某些SIP网络的SIP[1]消息中使用的P-Early-Media header字段的用途，以在相关网络的早期媒体策略允许的情况下授权后向和/或前向早期媒体的直通。P-Early-Media报头字段旨在用于SIP网络中，例如具有以下特征的3GPP IMS[13][14]：其早期媒体策略禁止在最终用户之间交换早期媒体；它与其他SIP网络互连，这些网络对于早期媒体具有未知、不可信或不同的策略；并且它能够“控制”（启用/禁用）早期媒体流向/来自用户设备的流量。
Within an isolated SIP network, it is possible to gate early media associated with all endpoints within the network to enforce a desired early media policy among network endpoints. However, when a SIP network is interconnected with other SIP networks, only the boundary node connected to the external network can determine which early media policy to apply to a session established between endpoints on different sides of the boundary. The P-Early-Media header field provides a means for this boundary node to communicate this early media policy decision to other nodes within the network.
在隔离的SIP网络中，可以对与网络内所有端点相关联的早期媒体进行选通，以在网络端点之间实施所需的早期媒体策略。然而，当SIP网络与其他SIP网络互连时，只有连接到外部网络的边界节点可以确定应用于在边界不同侧的端点之间建立的会话的早期媒体策略。P-Early-Media报头字段为该边界节点提供了将该早期媒体策略决策传达给网络内其他节点的方法。
The use of this extension is only applicable inside a "Trust Domain" as defined in RFC 3325 [6]. Nodes in such a Trust Domain are explicitly trusted by its users and end-systems to authorize early media requests only when allowed by early media policy within the Trust Domain.
此扩展的使用仅适用于RFC 3325[6]中定义的“信任域”。此类信任域中的节点受其用户和终端系统的明确信任，仅当信任域中的早期媒体策略允许时，才授权早期媒体请求。
This document does NOT offer a general early media authorization model suitable for inter-domain use or use in the Internet at large. Furthermore, since the early media requests are not cryptographically certified, they are subject to forgery, replay, and falsification in any architecture that does not meet the requirements of the Trust Domain.
本文档未提供适用于域间使用或在Internet上广泛使用的通用早期媒体授权模型。此外，由于早期媒体请求未经加密认证，因此在任何不符合信任域要求的体系结构中，它们都会受到伪造、重播和伪造的影响。
An early media request also lacks an indication of who specifically is making or modifying the request, and so it must be assumed that the Trust Domain is making the request. Therefore, the information is only meaningful when securely received from a node known to be a member of the Trust Domain.
早期的媒体请求也没有明确的指示谁在发出或修改请求，因此必须假设信任域正在发出请求。因此，只有从已知为信任域成员的节点安全地接收信息时，信息才有意义。
Although this extension can be used with parallel forking, it does not improve on the known problems with early media and parallel forking, as described in RFC 3960 [4], unless one can assume the use of symmetric RTP.
尽管此扩展可用于并行分叉，但它不能改善早期介质和并行分叉的已知问题，如RFC 3960[4]所述，除非可以假设使用对称RTP。
Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and can accept the limitations that result, to warrant publication of this mechanism. An example deployment would be a closed network that emulates a traditional circuit switched telephone network.
尽管存在这些限制，但仍有足够有用的专门部署满足上述假设，并且可以接受由此产生的限制，从而保证发布此机制。一个示例部署是模拟传统电路交换电话网络的封闭网络。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
The following acronyms are used in this document:
本文件中使用了以下首字母缩略词：
3GPP - the Third Generation Partnership Project ABNF - Augmented Backus-Naur Form [5] DTMF - Dual Tone Multi-Frequency ETSI - European Telecommunications Standards Institute IMS - Internet Protocol Multimedia Subsystem [13][14] MIME - Multipurpose Internet Mail Extensions NAT - Network Address Translation PSTN - Public Switched Telephone Network
3GPP-第三代合作伙伴项目ABNF-增强的巴科斯诺尔表[5]DTMF-双音多频ETSI-欧洲电信标准协会IMS-互联网协议多媒体子系统[13][14]MIME-多用途互联网邮件扩展NAT-网络地址转换PSTN-公共交换电话网
SDP - Session Description Protocol [7]
SIP - Session Initiation Protocol [1]
TISPAN - Telecommunications and Internet-converged Services and
Protocols for Advanced Networks
UA - User Agent [1]
UAC - User Agent Client [1]
UAS - User Agent Server [1]
SDP - Session Description Protocol [7]
SIP - Session Initiation Protocol [1]
TISPAN - Telecommunications and Internet-converged Services and
Protocols for Advanced Networks
UA - User Agent [1]
UAC - User Agent Client [1]
UAS - User Agent Server [1]
PSTN networks typically provide call progress information as backward early media from the terminating switch towards the calling party. PSTN networks also use forward early media from the calling party towards the terminating switch under some circumstances for applications, such as digit collection for secondary dialing. PSTN networks typically allow backward and/or forward early media since they are used for the purpose of progressing the call to the answer state and do not involve the exchange of data between endpoints.
PSTN网络通常提供呼叫进度信息，作为从终端交换机到主叫方的向后早期媒体。在某些情况下，PSTN网络还使用从主叫方到终端交换机的前向早期媒体进行应用，例如用于二次拨号的数字收集。PSTN网络通常允许向后和/或向前早期媒体，因为它们用于将呼叫推进到应答状态，并且不涉及端点之间的数据交换。
In a SIP network, backward early media flows from the User Agent Server (UAS) towards the User Agent Client (UAC). Forward early media flows from the UAC towards the UAS. SIP networks by default allow both forms of early media, which may carry user data, once the media path is established. Early media is typically desirable with a PSTN gateway as UAS, but not with SIP user equipment as UAS.
在SIP网络中，反向早期媒体从用户代理服务器（UAS）流向用户代理客户端（UAC）。从UAC向UAS转发早期媒体流。默认情况下，SIP网络允许两种形式的早期媒体，一旦媒体路径建立，这些媒体可能携带用户数据。早期媒体通常需要PSTN网关作为UAS，但不需要SIP用户设备作为UAS。
To prevent the exchange of user data within early media while allowing early media via PSTN gateways, a SIP network may have a policy to prohibit backward early media from SIP user equipment and to prohibit forward media towards SIP user equipment, either of which may contain user data. A SIP network containing both PSTN gateways and SIP end devices, for example, can maintain such an early media policy by gating "off" any early media with a SIP end device acting as UAS, gating "on" early media with a SIP end device acting as UAC, and gating "on" early media at each PSTN gateway.
为了在允许早期媒体经由PSTN网关的同时防止早期媒体内的用户数据交换，SIP网络可以具有禁止来自SIP用户设备的向后早期媒体和禁止朝向SIP用户设备的向前媒体的策略，其中任何一个都可以包含用户数据。例如，包含PSTN网关和SIP终端设备两者的SIP网络可以通过在SIP终端设备充当UAS的情况下选通“关闭”任何早期媒体、在SIP终端设备充当UAC的情况下选通“打开”早期媒体以及在每个PSTN网关处选通“打开”早期媒体来维护这样的早期媒体策略。
Unfortunately, a SIP network interconnected with another SIP network may have no means of assuring that the interconnected network is implementing a compatible early media policy, thus allowing the exchange of user data within early media under some circumstances. For example, if a network "A" allows all early media with user equipment as UAC and an interconnected network "B" allows all early media with user equipment as UAS, any session established between user equipment as UAC in "A" and user equipment as UAS in "B" will allow bidirectional user data exchange as early media. Other combinations of early media policies may also produce similar undesirable results.
不幸的是，与另一SIP网络互连的SIP网络可能无法确保互连网络正在实施兼容的早期媒体策略，从而在某些情况下允许在早期媒体内交换用户数据。例如，如果网络“a”允许用户设备作为UAC的所有早期媒体，而互联网络“B”允许用户设备作为UAS的所有早期媒体，则在“a”中作为UAC的用户设备和“B”中作为UAS的用户设备之间建立的任何会话将允许作为早期媒体的双向用户数据交换。早期媒体政策的其他组合也可能产生类似的不良结果。
The purpose of the extension is to allow a SIP network interconnected to other SIP networks with different early media policies to correctly identify and enable authorized early media according to its policies.
扩展的目的是允许使用不同的早期媒体策略互连到其他SIP网络的SIP网络根据其策略正确识别和启用授权的早期媒体。
Backward early media in the PSTN typically comprises call progress information, such as ringing feedback ("ringback"), or announcements regarding special handling such as forwarding. It may also include requests for further information, such as a credit card number to be entered as forward early media in the form of Dual Tone Multi-Frequency (DTMF) tones or speech. Backward early media of this type provides information to the calling party strictly for the purpose of progressing the call and involves no exchange of data between end users. The usual PSTN charging policy assumes that no data is exchanged between users until the call has been answered.
PSTN中的向后早期媒体通常包括呼叫进度信息，例如振铃反馈（“振铃”），或关于特殊处理（例如转发）的通知。它还可以包括对进一步信息的请求，例如以双音多频（DTMF）音调或语音的形式作为转发早期媒体输入的信用卡号。这种类型的后向早期媒体严格地为呼叫方提供信息，以便进行呼叫，并且不涉及最终用户之间的数据交换。通常的PSTN计费策略假定在呼叫应答之前，用户之间不交换数据。
A terminating SIP User Agent (UA) outside of the SIP network, on the other hand, may provide any user data in a backward early media stream. Thus, if the network implements the usual early media policy, the network equipment gating the backward early media flow for the originating UA must distinguish between authorized early media from a terminating SIP endpoint and unauthorized early media from another SIP device outside of the network. Given the assumption of a transitive trust relationship between SIP servers in the network, this can be accomplished by including some information in a backward SIP message that identifies the presence of authorized backward early media. Since it is necessary to verify that this indication comes from a trusted source, it is necessary for each server on the path back to the originating UA to be able to verify the trust relationship with the previous server and to remove such an indication when it cannot do so. A server on the boundary to an untrusted SIP network can assure that no indication of authorized backward early media passes from an external UAS to a UAC within the network. Thus, the use of a private header field that can be modified by SIP proxies is to be preferred over the use of a Multipurpose Internet Mail Extensions (MIME) attachment that cannot be modified in this way.
另一方面，SIP网络之外的终止SIP用户代理（UA）可以在向后的早期媒体流中提供任何用户数据。因此，如果网络实现通常的早期媒体策略，则为发起UA选通向后早期媒体流的网络设备必须区分来自终止SIP端点的授权早期媒体和来自网络外的另一SIP设备的未授权早期媒体。假设网络中的SIP服务器之间存在可传递的信任关系，这可以通过在反向SIP消息中包含一些信息来实现，该消息标识已授权的反向早期媒体的存在。由于有必要验证该指示是否来自受信任的来源，因此返回到发起UA的路径上的每台服务器都有必要能够验证与前一台服务器的信任关系，并在无法这样做时删除此类指示。不受信任SIP网络边界上的服务器可以确保没有授权后向早期媒体的指示从外部UAS传递到网络内的UAC。因此，与使用不能以这种方式修改的多用途Internet邮件扩展（MIME）附件相比，使用可由SIP代理修改的专用头字段更为可取。
Forward early media is less common than backward early media in the PSTN. It is typically used to collect secondary dialed digits, to collect credit card numbers, or to collect other DTMF or speech responses for the purpose of further directing the call. Forward early media in the PSTN is always directed toward a network server
在PSTN中，前向早期媒体不如后向早期媒体常见。它通常用于收集辅助拨号数字、收集信用卡号码或收集其他DTMF或语音响应，以便进一步引导呼叫。PSTN中的早期转发媒体始终指向网络服务器
for the purpose of progressing a call and involves no exchange of data between end users.
用于进行通话，不涉及最终用户之间的数据交换。
A terminating SIP UA outside of the SIP network, on the other hand, may receive any user data in a forward early media stream. Thus, if the network implements the usual early media policy, the network equipment gating the forward early media flow for the originating UA must distinguish between a terminating endpoint that is authorized to receive forward early media, and another SIP device outside of the network that is not authorized to receive forward early media containing user data. This authorization can be accomplished in the same manner as for backward early media by including some information in a backward SIP message that identifies that the terminating side is authorized to receive forward early media.
另一方面，SIP网络之外的终止SIP UA可以接收前向早期媒体流中的任何用户数据。因此，如果网络实现通常的早期媒体策略，则为发起UA选通前向早期媒体流的网络设备必须区分被授权接收前向早期媒体的终止端点，以及网络之外的未被授权接收包含用户数据的转发早期媒体的另一SIP设备。该授权可以通过在反向SIP消息中包括一些信息来实现，该信息标识终端侧被授权接收前向早期媒体，从而以与后向早期媒体相同的方式实现。
The private header extension defined in this document is applicable to the gateway model defined in RFC 3960 [4], since the PSTN gateway is the primary requestor of early media in an IMS. For the same reason, neither the application server model of RFC 3960, nor the early-session disposition type defined in RFC 3959 [3] is applicable.
本文档中定义的专用报头扩展适用于RFC 3960[4]中定义的网关模型，因为PSTN网关是IMS中早期媒体的主要请求者。出于同样的原因，RFC 3960的应用服务器模型和RFC 3959[3]中定义的早期会话处置类型都不适用。
The gateway model of RFC 3960 [4] allows for individual networks to create local policy with respect to the handling of early media, but does not address the case where a network is interconnected with other networks with unknown, untrusted, or different early media policies. Without the kind of information in the P-Early-Media header field, it is not possible for the network to determine whether cut-through of early media could lead to the transfer of data between end-users during session establishment.
RFC 3960[4]的网关模型允许单个网络创建有关早期媒体处理的本地策略，但不解决网络与具有未知、不受信任或不同早期媒体策略的其他网络互连的情况。如果没有P-Early-Media报头字段中的信息，网络就无法确定早期媒体的直通是否会导致会话建立期间最终用户之间的数据传输。
Thus, the private header extension in this document is a natural extension of the gateway model of RFC 3960 [4] that is applicable within a transitive trust domain.
因此，本文中的私有头扩展是RFC 3960[4]网关模型的自然扩展，适用于可传递信任域。
This document defines a new P-Early-Media header field for the purpose of requesting and authorizing requests for backward and/or forward early media. A UAC capable of recognizing the P-Early-Media header field may include the header field in an INVITE request. The P-Early-Media header field in an INVITE request contains the "supported" parameter.
本文档定义了一个新的P-Early-Media标头字段，用于请求和授权向后和/或向前早期介质的请求。能够识别P-Early-Media报头字段的UAC可以在INVITE请求中包括报头字段。INVITE请求中的P-Early-Media头字段包含“supported”参数。
As members of the Trust Domain, each proxy receiving an INVITE request must decide whether to insert or delete the P-Early-Media header field before forwarding.
作为信任域的成员，接收INVITE请求的每个代理必须在转发前决定是插入还是删除P-Early-Media标头字段。
A UAS receiving an INVITE request can use the presence of the P-Early-Media header field in the request to decide whether to request early media authorization in subsequent messages towards the UAC. After receiving an incoming INVITE request, the UAS requesting backward and/or forward early media will include the P-Early-Media header field in a message towards the UAC within the dialog, including direction parameter(s) that identify for each media line in the session whether the early media request is for backward media, forward media, both, or neither. The UAS can change its request for early media by including a modified P-Early-Media header field in a subsequent message towards the UAC within the dialog.
接收INVITE请求的UAS可以使用请求中是否存在P-Early-Media标头字段来决定是否在向UAC发送的后续消息中请求早期媒体授权。在接收到传入的INVITE请求后，请求向后和/或向前早期媒体的UAS将在对话框中向UAC发送的消息中包括P-early-media头字段，包括方向参数，用于标识会话中每个媒体行的早期媒体请求是向后媒体还是向前媒体，以及，或者两者都没有。UAS可以通过在对话框中向UAC发送的后续消息中包含修改后的P-early-media头字段来更改其对早期媒体的请求。
Each proxy in the network receiving the P-Early-Media header field in a message towards the UAC has the responsibility for assuring that the early media request comes from an authorized source. If a P-Early-Media header field arrives from either an untrusted source, a source not allowed to send backward early media, or a source not allowed to receive forward early media, then the proxy may remove the P-Early-Media header field or alter the direction parameter(s) of the P-Early-Media header field before forwarding the message, based on local policy.
在向UAC发送的消息中，网络中接收P-Early-Media header字段的每个代理都有责任确保早期媒体请求来自授权来源。如果P-Early-Media标头字段来自不受信任的源、不允许发送后向早期媒体的源或不允许接收前向早期媒体的源，则代理可以在转发消息之前删除P-Early-Media标头字段或更改P-Early-Media标头字段的方向参数，基于当地政策。
A proxy in the network not receiving the P-Early-Media header field in a message towards the UAC may insert one based on local policy.
网络中未接收到针对UAC的消息中的P-Early-Media报头字段的代理可以基于本地策略插入一个报头字段。
If the proxy also performs gating of early media, then it uses the parameter(s) of the P-Early-Media header field to decide whether to open or close the gates for backward and forward early media flow(s) between the UAs. The proxy performing gating of early media may also add a "gated" parameter to the P-Early-Media header field before forwarding the message so that other gating proxies in the path can choose to leave open their gates.
如果代理还执行早期媒体选通，则它使用P-early-media标头字段的参数来决定是否打开或关闭UAs之间向后和向前早期媒体流的选通。执行早期媒体选通的代理还可以在转发消息之前向P-early-media报头字段添加“选通”参数，以便路径中的其他选通代理可以选择保持其门打开。
If the UAC is a trusted server within the network (e.g., a PSTN gateway), then the UAC may use the parameter(s) of the P-Early-Media header field in messages received from the UAS to decide whether to perform early media gating or cut-through and to decide whether or not to render backward early media in preference to generating ringback based on the receipt of a 180 Ringing response.
如果UAC是网络内的受信任服务器（例如，PSTN网关），则UAC可以使用参数从UAS接收的消息中的P-Early-Media报头字段，以决定是否执行早期媒体选通或直通，并决定是否呈现向后的早期媒体，而不是基于收到的180振铃响应生成回铃。
If the UAC is associated with user equipment, then the network will have assigned a proxy the task of performing early media gating, so that the parameter(s) of the P-Early-Media header field received at such a UAC do not require that the UAC police the early media flow(s), but they do provide additional information that the UAC may use to render media.
如果UAC与用户设备相关联，则网络将为代理分配执行早期媒体选通的任务，以便在这样的UAC接收到的P-early-media报头字段的参数不要求UAC监控早期媒体流，但它们确实提供了UAC可能用于渲染媒体的附加信息。
The UAC and proxies in the network may also insert, delete, or modify the P-Early-Media header field in messages towards the UAS within the dialog according to local policy, but the interpretation of the header field when used in this way is a matter of local policy and not defined herein. The use of direction parameter(s) in this header field could be used to inform the UAS of the final early media authorization status.
UAC和网络中的代理也可以根据本地策略在对话框中向UAS发送的消息中插入、删除或修改P-Early-Media报头字段，但是以这种方式使用报头字段时的解释是本地策略的问题，本文中没有定义。在该标题字段中使用方向参数可用于通知UAS最终的早期媒体授权状态。
The P-Early-Media header field does not apply to any SDP with Content-Disposition: early-session [3].
P-Early-Media标头字段不适用于任何具有内容处置：Early session[3]的SDP。
When parallel forking occurs, there is no reliable way to correlate early media authorization in a dialog with the media from the corresponding endpoint unless one can assume the use of symmetric RTP, since the SDP messages do not identify the RTP source address of any media stream. When a UAC or proxy receives multiple early dialogs and cannot accurately identify the source of each media stream, it SHOULD use the most restrictive early media authorization it receives on any of the dialogs to decide the policy to apply towards all received media. When early media usage is desired for any reason and one cannot assume the use of symmetric RTP, it is advisable to disable parallel forking using callerprefs [9].
当发生并行分叉时，没有可靠的方法将对话中的早期媒体授权与来自相应端点的媒体相关联，除非可以假设使用对称RTP，因为SDP消息不标识任何媒体流的RTP源地址。当UAC或代理收到多个早期对话框且无法准确识别每个媒体流的来源时，它应使用在任何对话框上收到的最严格的早期媒体授权来决定对所有接收到的媒体应用的策略。如果出于任何原因需要提前使用媒体，并且不能假设使用对称RTP，建议使用CallerPref禁用并行分叉[9]。
Although the implementation of media gating is outside the scope of this extension, note that media gating must be implemented carefully in the presence of NATs and protocols that aid in NAT traversal. Media gating may also introduce a potential for media clipping that is similar to that created during parallel forking or any other feature that may disable early media, such as custom ringback.
尽管媒体选通的实现超出了此扩展的范围，但请注意，在存在NAT和有助于NAT遍历的协议的情况下，必须小心地实现媒体选通。媒体选通还可能引入媒体剪辑的可能性，该剪辑类似于并行分叉期间创建的剪辑或任何其他可能禁用早期媒体的功能，如自定义回铃。
The P-Early-Media header field with the "supported" parameter MAY be included in an INVITE request to indicate that the UAC or a proxy on the path recognizes the header field.
带有“supported”参数的P-Early-Media报头字段可以包含在INVITE请求中，以指示UAC或路径上的代理识别报头字段。
A network entity MAY request the authorization of early media or change a request for authorization of early media by including the P-Early-Media header field in any message allowed by Table 1 within the dialog towards the sender of the INVITE request. The P-Early-Media header field includes one or more direction parameters where each has one of the values: "sendrecv", "sendonly", "recvonly", or "inactive", following the convention used for Session Description Protocol (SDP) [7][8] stream directionality. Each parameter applies, in order, to the media lines in the corresponding SDP messages establishing session media. Unrecognized parameters SHALL be
网络实体可通过在针对INVITE请求发送方的对话框中的表1允许的任何消息中包含P-early-media头字段，请求早期媒体授权或更改早期媒体授权请求。P-Early-Media报头字段包括一个或多个方向参数，其中每个参数都有一个值：“sendrecv”、“sendonly”、“RecvoOnly”或“inactive”，遵循会话描述协议（SDP）[7][8]流方向性所使用的约定。每个参数依次应用于建立会话媒体的相应SDP消息中的媒体行。未识别的参数应为
silently discarded. Non-direction parameters are ignored for purposes of early media authorization. If there are more direction parameters than media lines, the excess SHALL be silently discarded. If there are fewer direction parameters than media lines, the value of the last direction parameter SHALL apply to all remaining media lines. A message directed towards the UAC containing a P-Early-Media header field with no recognized direction parameters SHALL NOT be interpreted as an early media authorization request.
默默地丢弃。出于早期介质授权的目的，将忽略非方向参数。如果方向参数多于介质线，则多余的参数应自动丢弃。如果方向参数少于介质线，则最后一个方向参数的值应适用于所有剩余的介质线。指向UAC的消息（包含P-Early-Media报头字段，且没有可识别的方向参数）不得解释为早期媒体授权请求。
The parameter value "sendrecv" indicates a request for authorization of early media associated with the corresponding media line, both from the UAS towards the UAC and from the UAC towards the UAS (both backward and forward early media). The value "sendonly" indicates a request for authorization of early media from the UAS towards the UAC (backward early media), and not in the other direction. The value "recvonly" indicates a request for authorization of early media from the UAC towards the UAS (forward early media), and not in the other direction. The value "inactive" indicates either a request that no early media associated with the corresponding media line be authorized, or a request for revocation of authorization of previously authorized early media.
参数值“sendrecv”表示从UAS向UAC和从UAC向UAS（向后和向前早期媒体）请求授权与相应媒体线路相关联的早期媒体。值“sendonly”表示从UAS向UAC（向后早期媒体）而不是向其他方向请求早期媒体授权。值“RecvoOnly”表示从UAC向UAS（前向早期媒体）而不是向其他方向请求早期媒体授权。值“inactive”表示不授权与相应媒体线路相关联的早期媒体的请求，或撤销先前授权的早期媒体的授权的请求。
The P-Early-Media header field in any message within a dialog towards the sender of the INVITE request MAY also include the non-direction parameter "gated" to indicate that a network entity on the path towards the UAS is already gating the early media, according to the direction parameter(s). When included in the P-Early-Media header field, the "gated" parameter SHALL come after all direction parameters in the parameter list.
在朝向INVITE请求的发送者的对话框中的任何消息中的P-Early-Media报头字段还可以包括非方向参数“gated”，以指示朝向UAS的路径上的网络实体已经根据方向参数对早期媒体进行了选通。当包含在P-Early-Media标题字段中时，“选通”参数应位于参数列表中所有方向参数之后。
When receiving a message directed toward the UAC without the P-Early-Media header field and no previous early media authorization request has been received within the dialog, the default early media authorization depends on local policy and may depend on whether the header field was included in the INVITE request. After an early media authorization request has been received within a dialog, and a subsequent message is received without the P-Early-Media header field, the previous early media authorization remains unchanged.
当在没有P-Early-Media header字段的情况下接收到指向UAC的消息，并且在对话框中没有收到以前的早期媒体授权请求时，默认的早期媒体授权取决于本地策略，并且可能取决于头字段是否包含在INVITE请求中。在对话框中接收到早期媒体授权请求，并且在没有P-early-media头字段的情况下接收到后续消息后，先前的早期媒体授权保持不变。
The P-Early-Media header field in any message within a dialog towards the UAS MAY be ignored or interpreted according to local policy.
针对UAS的对话框中任何消息中的P-Early-Media头字段可能会被忽略或根据本地策略进行解释。
The P-Early-Media header field does not interact with SDP offer/answer procedures in any way. Early media authorization is not influenced by the state of the SDP offer/answer procedures (including preconditions and directionality) and does not influence the state of the SDP offer/answer procedures. The P-Early-Media header field may or may not be present in messages containing SDP. The most recently
P-Early-Media标题字段不以任何方式与SDP提供/应答程序交互。早期媒体授权不受SDP提供/应答程序状态（包括先决条件和方向性）的影响，也不影响SDP提供/应答程序的状态。在包含SDP的消息中，P-Early-Media标头字段可能存在，也可能不存在。最近的
received early media authorization applies to the corresponding media line in the session established for the dialog until receipt of the 200 OK response to the INVITE request, at which point all media lines in the session are implicitly authorized. Early media flow in a particular direction requires that early media in that direction is authorized, that media flow in that direction is enabled by the SDP direction attribute for the stream, and that any applicable preconditions [11] are met. Early media authorization does not override the SDP direction attribute or preconditions state, and the SDP direction attribute does not override early media authorization.
接收到的早期媒体授权应用于为对话框建立的会话中的相应媒体线路，直到收到对INVITE请求的200 OK响应，此时会话中的所有媒体线路都被隐式授权。特定方向的早期媒体流要求该方向的早期媒体得到授权，该方向的媒体流通过流的SDP direction属性启用，并且满足任何适用的先决条件[11]。早期介质授权不会覆盖SDP方向属性或前提条件状态，SDP方向属性也不会覆盖早期介质授权。
Table 1 is an extension of Tables 2 and 3 in RFC 3261 [1] for the P-Early-Media header field. The column "PRA" is for the PRACK method [12]. The column "UPD" is for the UPDATE method [10].
表1是RFC 3261[1]中表2和表3对P-Early-Media标头字段的扩展。“PRA”列用于PRACK方法[12]。“UPD”列用于更新方法[10]。
Header field where proxy ACK BYE CAN INV OPT REG PRA UPD
________________________________________________________________
P-Early-Media R amr - - - o - - o o
P-Early-Media 18x amr - - - o - - - -
P-Early-Media 2xx amr - - - - - - o o
Header field where proxy ACK BYE CAN INV OPT REG PRA UPD
________________________________________________________________
P-Early-Media R amr - - - o - - o o
P-Early-Media 18x amr - - - o - - - -
P-Early-Media 2xx amr - - - - - - o o
Table 1: P-Early-Media Header Field
表1:P-Early-Media头字段
A User Agent Client MAY include the P-Early-Media header field with the "supported" parameter in an INVITE request to indicate that it recognizes the header field.
用户代理客户端可以在INVITE请求中包含带有“SUPPORED”参数的P-Early-Media头字段，以指示其识别头字段。
A User Agent Client receiving a P-Early-Media header field MAY use the parameter(s) of the header field to gate or cut-through early media, and to decide whether to render early media from the UAS to the UAC in preference to any locally generated ringback triggered by a 180 Ringing response. If a proxy is providing the early media gating function for the User Agent Client, then the gateway model of RFC 3960 [4] for rendering of early media is applicable. A User Agent Client without a proxy in the network performing early media gating that receives a P-Early-Media header field SHOULD perform gating or cut-through of early media according to the parameter(s) of the header field.
接收P-Early-Media报头字段的用户代理客户端可以使用报头字段的参数来选通或切断早期媒体，并决定是否优先于由180振铃响应触发的任何本地生成的回铃，将早期媒体从UAS呈现给UAC。如果代理为用户代理客户端提供早期媒体选通功能，则适用于呈现早期媒体的RFC 3960[4]网关模型。网络中没有代理的用户代理客户端执行早期媒体选通，接收P-early-media标头字段，应根据标头字段的参数执行早期媒体选通或剪切。
A User Agent Server that is requesting authorization to send or receive early media MAY insert a P-Early-Media header field with appropriate parameters(s) in any message allowed in table 1 towards the UAC within the dialog. A User Agent Server MAY request changes in early media authorization by inserting a P-Early-Media header
请求授权发送或接收早期媒体的用户代理服务器可以在表1中允许的任何消息中向对话框内的UAC插入带有适当参数的P-early-media头字段。用户代理服务器可以通过插入P-early-media头请求早期媒体授权的更改
field with appropriate parameter(s) in any subsequent message allowed in table 1 towards the UAC within the dialog.
在表1中允许的任何后续消息中，向对话框内的UAC发送带有适当参数的字段。
If the P-Early-Media header field is not present in the INVITE request, the User Agent Server MAY choose to suppress early media authorization requests and MAY choose to execute alternate early media procedures.
如果P-Early-Media报头字段不存在于INVITE请求中，则用户代理服务器可选择抑制早期媒体授权请求，并可选择执行备用早期媒体过程。
When forwarding an INVITE request, a proxy MAY add, retain, or delete the P-Early-Media header field, depending on local policy and the trust relationship with the sender and/or receiver of the request.
转发INVITE请求时，代理可以添加、保留或删除P-Early-Media头字段，具体取决于本地策略以及与请求的发送方和/或接收方的信任关系。
When forwarding a message allowed in Table 1 towards the UAC, a proxy MAY add, modify, or delete a P-Early-Media header field, depending on local policy and the trust relationship with the sender and/or receiver of the message. In addition, if the proxy controls the gating of early media for the User Agent Client, it SHOULD use the contents of the P-Early-Media header field to gate the early media, according to the definitions of the header field parameters defined in clause 8.
当向UAC转发表1中允许的消息时，代理可以添加、修改或删除P-Early-Media标头字段，具体取决于本地策略以及与消息发送方和/或接收方的信任关系。此外，如果代理控制用户代理客户端的早期媒体选通，则应根据第8条中定义的头字段参数的定义，使用P-early-media头字段的内容选通早期媒体。
The syntax of the P-Early-Media header field is described below in ABNF, according to RFC 4234 [5], as an extension to the ABNF for SIP in RFC 3261 [1]. Note that not all combinations of em-param elements are semantically valid.
根据RFC 4234[5]，P-Early-Media头字段的语法在ABNF中描述如下，作为RFC 3261[1]中针对SIP的ABNF的扩展。请注意，并非所有em param元素的组合在语义上都有效。
P-Early-Media = "P-Early-Media" HCOLON
[ em-param *(COMMA em-param) ]
em-param = "sendrecv" / "sendonly" / "recvonly"
/ "inactive" / "gated" / "supported" / token
P-Early-Media = "P-Early-Media" HCOLON
[ em-param *(COMMA em-param) ]
em-param = "sendrecv" / "sendonly" / "recvonly"
/ "inactive" / "gated" / "supported" / token
The use of this extension is only applicable inside a "Trust Domain", as defined in RFC 3325 [6]. This document does NOT offer a general early media authorization model suitable for inter-domain use or use in the Internet at large.
此扩展的使用仅适用于RFC 3325[6]中定义的“信任域”。本文档未提供适用于域间使用或在Internet上广泛使用的通用早期媒体授权模型。
There are no confidentiality concerns associated with the P-Early-Media header field. It is desirable to maintain the integrity of the direction parameters in the header field across each hop between servers to avoid the potential for unauthorized use of early media. It is assumed that the P-Early-Media header field is used within the context of the 3GPP IMS trust domain or a similar trust domain,
不存在与P-Early-Media头字段相关的保密问题。希望在服务器之间的每个跃点上保持报头字段中方向参数的完整性，以避免未经授权使用早期媒体的可能性。假设P-Early-Media报头字段在3GPP IMS信任域或类似信任域的上下文中使用，
consisting of a collection of SIP servers maintaining pair wise security associations.
由维护成对安全关联的SIP服务器集合组成。
Within the trust domain of a network it is only necessary to police the use of the P-Early-Media header field at the boundary to user equipment served by the network and at the boundary to peer networks. It is assumed that boundary servers in the trust domain of a network will have local policy for the treatment of the P-Early-Media header field as it is sent to or received from any possible server external to the network. Since boundary servers are free to modify or remove any P-Early-Media header field in SIP messages forwarded across the boundary, the integrity of the P-Early-Media header field can be verified to the extent that the connections to external servers are secured. The authenticity of the P-Early-Media header field can only be assured to the extent that the external servers are trusted to police the authenticity of the header field.
在网络的信任域内，只需在网络服务的用户设备边界和对等网络边界对P-Early-Media报头字段的使用进行监控。假设网络信任域中的边界服务器在向网络外部的任何可能服务器发送P-Early-Media报头字段或从网络外部的任何可能服务器接收P-Early-Media报头字段时，具有处理该字段的本地策略。由于边界服务器可以自由修改或删除跨边界转发的SIP消息中的任何P-Early-Media头字段，因此可以验证P-Early-Media头字段的完整性，以确保与外部服务器的连接安全。P-Early-Media报头字段的真实性只有在外部服务器被信任以监控报头字段的真实性的情况下才能得到保证。
Name of Header field: P-Early-Media
标题字段名称：P-Early-Media
Short form: none
简表：无
Registrant: Richard Ejzak ejzak@alcatel-lucent.com
注册人：Richard Ejzakejzak@alcatel-朗讯网
Normative description: Section 8 of this document
规范性说明：本文件第8节
The author would like to thank Miguel Garcia-Martin, Jan Holm, Sebastien Garcin, Akira Kurokawa, Erick Sasaki, James Calme, Greg Tevonian, Aki Niemi, Paul Kyzivat, Gonzalo Camarillo, Brett Tate, Jon Peterson, Alfred Hoenes, and David Black for their significant contributions made throughout the writing and reviewing of this document.
作者要感谢Miguel Garcia Martin、Jan Holm、Sebastien Garcin、Akira Kurokawa、Erick Sasaki、James Calme、Greg Tevonian、Aki Niemi、Paul Kyzivat、Gonzalo Camarillo、Brett Tate、Jon Peterson、Alfred Hoenes和David Black，感谢他们在本文件编写和审查过程中做出的重大贡献。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004.
[3] Camarillo，G.“会话启动协议（SIP）的早期会话处置类型”，RFC 3959，2004年12月。
[4] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[4] Camarillo，G.和H.Schulzrinne，“会话启动协议（SIP）中的早期媒体和铃声生成”，RFC 39602004年12月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[5] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[6] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[6] Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中用于断言身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[9] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[10] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[10] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[11] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[11] Camarillo，G.，Marshall，W.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[12] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[12] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[13] 3GPP "TS 23.228: IP Multimedia Subsystem (IMS); Stage 2 (Release 7)", 3GPP 23.228, March 2007, ftp://ftp.3gpp.org/specs/archive/23_series/23.228/.
[13] 3GPP“TS 23.228:IP多媒体子系统（IMS）；第2阶段（第7版）”，3GPP 23.228，2007年3月，ftp://ftp.3gpp.org/specs/archive/23_series/23.228/.
[14] 3GPP "TS 24.229: IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 7)", 3GPP 24.229, March 2007, ftp://ftp.3gpp.org/specs/archive/24_series/24.229/.
[14] 3GPP“TS 24.229：基于SIP和SDP的IP多媒体呼叫控制协议；第3阶段（第7版）”，3GPP 24.229，2007年3月，ftp://ftp.3gpp.org/specs/archive/24_series/24.229/.
ETSI documents can be downloaded from the ETSI Web server, "http://www.etsi.org/". Any 3GPP document can be downloaded from the 3GPP Web server, "http://www.3gpp.org/". See specifications.
ETSI文件可从ETSI Web服务器下载，”http://www.etsi.org/". 任何3GPP文档都可以从3GPP Web服务器下载，”http://www.3gpp.org/". 见规范。
Authors Address
作者地址
Richard Ejzak Alcatel-Lucent 1960 Lucent Lane Naperville, IL 60566 USA
Richard Ejzak Alcatel-Lucent 1960美国伊利诺伊州纳珀维尔朗讯巷60566
Phone: +1 630 979 7036
EMail: ejzak@alcatel-lucent.com
Phone: +1 630 979 7036
EMail: ejzak@alcatel-lucent.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.