Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8055 Ericsson
Category: Standards Track Y. Jiang
ISSN: 2070-1721 China Mobile
January 2017
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8055 Ericsson
Category: Standards Track Y. Jiang
ISSN: 2070-1721 China Mobile
January 2017
Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm
会话启动协议（SIP）通过标头字段参数指示接收的域
Abstract
摘要
This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network.
本规范通过标题字段参数“received realm”定义了新的会话发起协议（SIP），该参数允许充当传输网络入口点的SIP实体通过使用与相邻网络关联的网络领域值来指示从哪个相邻上游网络接收SIP请求。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8055.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8055.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use Case: Transit Network Application Services . . . . . 3
1.3. Use Case: Transit Network Routing . . . . . . . . . . . . 4
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Via 'received-realm' Header Field Parameter . . . . . . . . . 5
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Operator Identifier . . . . . . . . . . . . . . . . . . . 5
5.3. JWS Header . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. JWS Payload . . . . . . . . . . . . . . . . . . . . . . . 6
5.5. JWS Serialization . . . . . . . . . . . . . . . . . . . . 7
5.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.6.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
5.6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 8
5.7. Example: SIP Via Header Field . . . . . . . . . . . . . . 8
6. User Agent and Proxy Behavior . . . . . . . . . . . . . . . . 8
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Behavior of a SIP Entity Acting as a Network Entry Point 8
6.3. Behavior of a SIP Entity Consuming the 'received-realm'
Value . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Example: SIP INVITE Request and Response . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. 'received-realm' Via Header Field Parameter . . . . . . . 10
8.2. JSON Web Token Claims Registration . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use Case: Transit Network Application Services . . . . . 3
1.3. Use Case: Transit Network Routing . . . . . . . . . . . . 4
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Via 'received-realm' Header Field Parameter . . . . . . . . . 5
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Operator Identifier . . . . . . . . . . . . . . . . . . . 5
5.3. JWS Header . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. JWS Payload . . . . . . . . . . . . . . . . . . . . . . . 6
5.5. JWS Serialization . . . . . . . . . . . . . . . . . . . . 7
5.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.6.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
5.6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 8
5.7. Example: SIP Via Header Field . . . . . . . . . . . . . . 8
6. User Agent and Proxy Behavior . . . . . . . . . . . . . . . . 8
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Behavior of a SIP Entity Acting as a Network Entry Point 8
6.3. Behavior of a SIP Entity Consuming the 'received-realm'
Value . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Example: SIP INVITE Request and Response . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. 'received-realm' Via Header Field Parameter . . . . . . . 10
8.2. JSON Web Token Claims Registration . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
When Session Initiation Protocol (SIP) [RFC3261] sessions are established between networks belonging to different operators or between interconnected networks belonging to the same operator (or enterprise), the SIP requests associated with the session might traverse transit networks.
当在属于不同运营商的网络之间或在属于同一运营商（或企业）的互连网络之间建立会话发起协议（SIP）[RFC3261]会话时，与会话相关联的SIP请求可能会穿越传输网络。
Such transit networks might provide different kinds of services. In order to provide such services, a transit network often needs to know to which operator (or enterprise) the adjacent upstream network from which the SIP session initiation request is received belongs.
这种公交网络可能提供不同种类的服务。为了提供这样的服务，传输网络通常需要知道从其接收SIP会话发起请求的相邻上游网络属于哪个运营商（或企业）。
This specification defines a new SIP Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network.
本规范定义了一个新的SIP Via报头字段参数“received realm”，该参数允许充当中转网络入口点的SIP实体通过使用与相邻网络关联的网络领域值来指示从哪个相邻上游网络接收SIP请求。
NOTE: As the adjacent network can be an enterprise network, an Inter Operator Identifier (IOI) cannot be used to identify the network because IOIs are not defined for enterprise networks.
注意：由于相邻网络可以是企业网络，因此不能使用操作员间标识符（IOI）来标识网络，因为IOI没有为企业网络定义。
The following sections describe use cases where the information is needed.
以下部分描述了需要这些信息的用例。
The Third Generation Partnership Project (3GPP) TS 23.228 [TS.3GPP.23.228] specifies how an IP Multimedia Subsystem (IMS) network can be used to provide transit functionality. An operator can use its IMS network to provide transit functionality, e.g., to non-IMS customers, to enterprise networks, and to other network operators.
第三代合作伙伴计划（3GPP）TS 23.228[TS.3GPP.23.228]规定了如何使用IP多媒体子系统（IMS）网络来提供传输功能。运营商可以使用其IMS网络向非IMS客户、企业网络和其他网络运营商提供传输功能。
The transit network operator can provide application services to the networks for which it is providing transit functionality. Transit application services are typically not provided on a per user basis, as the transit network does not have access to the user profiles of the networks for which the application services are provided. Instead, the application services are provided per served network.
公交网络运营商可以向其提供公交功能的网络提供应用服务。公交应用服务通常不以每个用户为基础提供，因为公交网络无法访问为其提供应用服务的网络的用户配置文件。相反，应用程序服务是按服务网络提供的。
When a SIP entity that provides application services (e.g., an Application Server) within a transit network receives a SIP request, in order to apply the correct services, it needs to know the adjacent upstream network from which the SIP request is received.
当在传输网络内提供应用服务（例如，应用服务器）的SIP实体接收到SIP请求时，为了应用正确的服务，它需要知道接收到SIP请求的相邻上游网络。
A transit network operator normally interconnects to many different operators, including other transit network operators, and provides transit routing of SIP requests received from one operator network towards the destination. The destination can be within an operator network to which the transit network operator has a direct interconnect or within an operator network that only can be reached via one or more interconnected transit operators.
公交网络运营商通常与许多不同的运营商互连，包括其他公交网络运营商，并提供从一个运营商网络接收到的SIP请求到目的地的中转路由。目的地可以位于公交网络运营商直接互连的运营商网络内，也可以位于只能通过一个或多个互连公交运营商到达的运营商网络内。
For each customer (i.e., interconnected network operator) for which the transit network operator routes SIP requests towards the requested destination, a set of transit routing policies are defined. These policies are used to determine how a SIP request shall be routed towards the requested destination to meet the agreement the transit network operator has with its customer.
对于公交网络运营商将SIP请求路由到请求目的地的每个客户（即互联网络运营商），定义了一组公交路由策略。这些策略用于确定SIP请求应如何路由到请求的目的地，以满足公交网络运营商与其客户达成的协议。
When a SIP entity that performs the transit routing functionality receives a SIP request, in order to apply the correct set of transit routing policies, it needs to know from which of its customers (i.e., adjacent upstream network) the SIP request is received.
当执行传输路由功能的SIP实体接收到SIP请求时，为了应用正确的传输路由策略集，它需要知道从哪个客户（即相邻的上游网络）接收到SIP请求。
The mechanism defined in this specification MUST only be used by SIP entities that are able to verify from which adjacent upstream network a SIP request is received.
本规范中定义的机制只能由能够验证从哪个相邻上游网络接收SIP请求的SIP实体使用。
The mechanism for verifying from which adjacent upstream network a SIP request is received is outside the scope of this specification. Such a mechanism might be based on, for instance, receiving the SIP request on an authenticated Virtual Private Network (VPN), on a specific IP address, or on a specific network access.
用于验证从哪个相邻上游网络接收SIP请求的机制不在本规范的范围内。例如，这种机制可以基于在经过认证的虚拟专用网络（VPN）、特定IP地址或特定网络接入上接收SIP请求。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
SIP entity: A SIP User Agent (UA), or SIP proxy, as defined in RFC 3261.
SIP实体：如RFC3261中所定义的SIP用户代理（UA）或SIP代理。
Adjacent upstream SIP network: The adjacent SIP network in the direction from which a SIP request is received.
相邻上游SIP网络：接收SIP请求的方向上的相邻SIP网络。
Network entry point: A SIP entity on the border of the network, which receives SIP requests from adjacent upstream networks.
网络入口点：网络边界上的SIP实体，接收来自相邻上游网络的SIP请求。
Inter Operator Identifier (IOI): A globally unique identifier to correlate billing information generated within the IP Multimedia Subsystem (IMS).
运营商间标识符（IOI）：一个全局唯一标识符，用于关联IP多媒体子系统（IMS）内生成的计费信息。
JWS: A JSON Web Signature, as defined in [RFC7515].
JWS:JSON Web签名，如[RFC7515]中所定义。
The Via 'received-realm' header field parameter value is represented as a combination of an operator identifier whose value represents the adjacent network and a serialized JSON Web Signature (JWS) [RFC7515]. The JWS Payload consists of the operator identifier and other SIP information element values.
Via“received realm”头字段参数值表示为操作员标识符（其值表示相邻网络）和序列化JSON Web签名（JWS）[RFC7515]的组合。JWS有效负载由操作员标识符和其他SIP信息元素值组成。
The procedures for encoding the JWS and calculating the signature are defined in [RFC7515]. As the JWS Payload information is found in other SIP information elements, the JWS Payload is detached from the serialized JWS conveyed in the header field parameter, as described in Appendix F of [RFC7515]. The operator identifier and the serialized JWS are separated using a colon character.
编码JWS和计算签名的过程在[RFC7515]中定义。由于在其他SIP信息元素中可以找到JWS有效负载信息，因此JWS有效负载与标头字段参数中传输的序列化JWS分离，如[RFC7515]的附录F所述。运算符标识符和序列化的JWS使用冒号字符分隔。
The operator identifier is a token value that represents the adjacent operator. The scope of the value is only within the network that inserts the value.
运算符标识符是表示相邻运算符的令牌值。值的范围仅在插入值的网络内。
The operator identifier value is case insensitive.
运算符标识符值不区分大小写。
The following header parameters MUST be included in the JWS.
JWS中必须包含以下标头参数。
o The "typ" parameter MUST have a "JWT" value.
o “typ”参数必须具有“JWT”值。
o The "alg" parameter MUST have the value of the algorithm used to calculate the JWS.
o “alg”参数必须具有用于计算JWS的算法的值。
NOTE: Operators need to agree on the set of supported algorithms for calculating the JWT signature.
注：操作员需要就计算JWT签名所支持的算法集达成一致。
NOTE: The "alg" parameter values for specific algorithms are listed in the IANA JSON Web Signature and Encryption Algorithms sub-registry of the JSON Object Signing and Encryption (JOSE) registry. Operators need to use algorithms for which an associated "alg" parameter value has been registered. The procedures for defining new values are defined in [RFC7518].
注：特定算法的“alg”参数值列在JSON对象签名和加密（JOE）注册表的IANA JSON Web签名和加密算法子注册表中。操作员需要使用已注册相关“alg”参数值的算法。[RFC7518]中定义了定义新值的步骤。
Example:
例子：
{
"typ":"JWT",
"alg":"HS256"
}
{
"typ":"JWT",
"alg":"HS256"
}
The following claims MUST be included in the JWS Payload:
JWS有效载荷中必须包含以下声明：
o The "sip_from_tag" claim has the value of the From 'tag' header field parameter of the SIP message.
o “sip_from_tag”声明具有sip消息的from“tag”头字段参数的值。
o The "sip_date" claim has the value of the Date header field in the SIP message, encoded in JSON NumericDate format [RFC7519].
o “sip_date”声明具有sip消息中日期头字段的值，该字段以JSON NumericDate格式[RFC7519]编码。
o The "sip_callid" claim has the value of the Call-ID header field in the SIP message.
o “sip_callid”声明具有sip消息中Call ID header字段的值。
o The "sip_cseq_num" claim has the numeric value of the CSeq header field in the SIP message.
o “sip_cseq_num”声明具有sip消息中cseq头字段的数值。
o The "sip_via_branch" claim has the value of the Via branch header field parameter of the Via header field, in the SIP message, to which the 'received-realm' header field parameter is attached.
o “sip_via_branch”声明具有sip消息中via header字段的via branch header字段参数的值，其中附加了“received realm”header字段参数。
o The "sip_via_opid" claim has the value of the operator identifier part of the Via 'received-realm' header field parameter of the Via header field, in the SIP message, to which the 'received-realm' header field parameter is attached.
o The "sip_via_opid" claim has the value of the operator identifier part of the Via 'received-realm' header field parameter of the Via header field, in the SIP message, to which the 'received-realm' header field parameter is attached.translate error, please retry
Example:
例子：
{
"sip_from_tag":"1928301774",
"sip_date":1472815523,
"sip_callid":"a84b4c76e66710@pc33.atlanta.com",
"sip_cseq_num":"314159",
"sip_via_branch":"z9hG4bK776asdhds",
"sip_via_opid":"myoperator"
}
{
"sip_from_tag":"1928301774",
"sip_date":1472815523,
"sip_callid":"a84b4c76e66710@pc33.atlanta.com",
"sip_cseq_num":"314159",
"sip_via_branch":"z9hG4bK776asdhds",
"sip_via_opid":"myoperator"
}
As the JWS Payload is not carried in the 'received-realm' parameter, in order to make sure that the sender and the receiver construct the JWS Payload object in the same way, the JSON representation of the JWS Payload object MUST be computed as follows:
由于JWS有效负载未包含在“received realm”参数中，为了确保发送方和接收方以相同的方式构造JWS有效负载对象，JWS有效负载对象的JSON表示形式必须计算如下：
o All claims MUST be encoded using lowercase characters.
o 所有声明必须使用小写字符编码。
o The claims MUST be in the same order as listed in Section 5.4.
o 索赔的顺序必须与第5.4节中列出的顺序相同。
o All claims except "sip_date" MUST be encoded as StringOrURI JSON string value [RFC7519].
o 除“sip_date”之外的所有声明都必须编码为StringOrURI JSON字符串值[RFC7519]。
o The "sip_date" claim MUST be encoded as a JSON NumericDate value [RFC7519].
o “sip_date”声明必须编码为JSON NumericDate值[RFC7519]。
o The JWS Payload MUST follow the rules for the construction of the thumbprint of a JSON Web Key (JWK) as defined in Section 3, Step 1 only, of [RFC7638].
o JWS负载必须遵循[RFC7638]第3节第1步中定义的JSON Web密钥（JWK）指纹构造规则。
Example:
例子：
{"sip_from_tag":"1928301774","sip_date":1472815523,
"sip_callid":"a84b4c76e66710@pc33.atlanta.com",
"sip_cseq_num":"314159","sip_via_branch":"z9hG4bK776asdhds",
"sip_via_opid":"myoperator"}
{"sip_from_tag":"1928301774","sip_date":1472815523,
"sip_callid":"a84b4c76e66710@pc33.atlanta.com",
"sip_cseq_num":"314159","sip_via_branch":"z9hG4bK776asdhds",
"sip_via_opid":"myoperator"}
NOTE: Line breaks are for display purposes only.
注意：换行符仅用于显示目的。
This section describes the syntax extensions to the ABNF syntax defined in [RFC3261] by defining a new Via header field parameter, 'received-realm'. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. "EQUAL", "LDQUOT", "RDQUOT", and "ALPHA" are defined in [RFC3261]. "DIGIT" is defined in [RFC5234].
本节通过定义新的Via标头字段参数“received realm”，描述[RFC3261]中定义的ABNF语法的语法扩展。本规范中定义的ABNF符合RFC 5234[RFC5234]。[RFC3261]中定义了“相等”、“LDQUOT”、“RDQUOT”和“ALPHA”。“数字”在[RFC5234]中定义。
via-params =/ received-realm
received-realm = "received-realm" EQUAL LDQUOT op-id COLON jws RDQUOT
op-id = token
jws = header ".." signature
header = 1*base64-char
signature = 1*base64-char
base64-char = ALPHA / DIGIT / "/" / "+"
via-params =/ received-realm
received-realm = "received-realm" EQUAL LDQUOT op-id COLON jws RDQUOT
op-id = token
jws = header ".." signature
header = 1*base64-char
signature = 1*base64-char
base64-char = ALPHA / DIGIT / "/" / "+"
EQUAL, COLON, token, LDQUOT, RDQUOT, ALPHA, and DIGIT are as defined in [RFC3261].
相等、冒号、标记、LDQUOT、RDQUOT、ALPHA和数字如[RFC3261]中所定义。
NOTE: The two adjacent dots in the 'jws' part are due to the detached payload being replaced by an empty string [RFC7515].
注：“jws”部分中的两个相邻点是由于分离的有效负载被空字符串替换[RFC7515]。
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776;
received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1N..
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776;
received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1N..
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
NOTE: Line breaks are for display purposes only.
注意：换行符仅用于显示目的。
This section describes how a SIP entity, acting as an entry point to a network, uses the 'received-realm' Via header field parameter.
本节描述作为网络入口点的SIP实体如何通过header字段参数使用“received realm”。
When a SIP entity acting as a network entry point forwards a SIP request or initiates a SIP request on its own (e.g., a Public Switched Telephone Network (PSTN) gateway), the SIP entity adds a Via header field to the SIP request, according to the procedures in RFC 3261 [RFC3261]. In addition, if the SIP entity is able to assert the
当充当网络入口点的SIP实体转发SIP请求或自行发起SIP请求（例如，公共交换电话网络（PSTN）网关）时，SIP实体根据RFC 3261[RFC3261]中的过程向SIP请求添加Via报头字段。此外，如果SIP实体能够断言
adjacent upstream network and if the SIP entity is aware of a network realm value defined for that network, the SIP entity can add a 'received-realm' Via header field parameter conveying the network realm value as the operator identifier (Section 5.2) part of the header field parameter, to the Via header field added to the SIP request.
相邻的上游网络，并且如果SIP实体知道为该网络定义的网络领域值，则SIP实体可以通过标头字段参数将“接收领域”添加到添加到SIP请求的Via标头字段中，该参数传递网络领域值作为标头字段参数的操作员标识符（第5.2节）部分。
In addition, the SIP entity MUST also calculate a JWS (Section 5.4) and add the calculated JWS Header and JWS Signature as the 'jws' part of the Via header field parameter.
此外，SIP实体还必须计算JWS（第5.4节），并将计算出的JWS标头和JWS签名添加为Via标头字段参数的“JWS”部分。
When a SIP entity receives a Via 'received-realm' header field parameter and intends to perform actions based on the header field parameter value, it MUST first recalculate the JWS and check whether the result matches the JWS received. If there is not a match, the SIP entity MUST discard the received 'received-realm' header field parameter. The SIP entity MAY also take additional actions (e.g., rejecting the SIP request) based on local policy.
当SIP实体接收到Via“received realm”头字段参数并打算基于头字段参数值执行操作时，它必须首先重新计算JWS，并检查结果是否与接收到的JWS匹配。如果不匹配，SIP实体必须放弃接收到的“received realm”头字段参数。SIP实体还可以基于本地策略采取附加动作（例如，拒绝SIP请求）。
This section shows an example of a SIP INVITE request and the associated response, which contains a Via header field (inserted into the request and removed from the response by the T_EP SIP proxy) with a 'received-realm' header field parameter.
本节显示SIP INVITE请求和相关响应的示例，其中包含带有“received realm”头字段参数的Via头字段（插入到请求中并由T_EP SIP代理从响应中删除）。
Operator 1 T_EP T_AS
操作员1 T_EP T_AS
- INVITE ------> Via: SIP/2.0/UDP IP_UA -- INVITE ----------------------------> Via: SIP/2.0/UDP IP_TEP;branch=z9hG4bK776; received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJh bGciOiJIUzI1N..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW 1gFWFOEjXk" Via: SIP/2.0/UDP IP_UA; received=IP_UA
- INVITE------->Via:SIP/2.0/UDP IP_-UA——INVITE----------------->Via:SIP/2.0/UDP IP_-TEP；分支=z9hG4bK776；接收到的realm=“myoperator:eyj0exaioijkv1qila0kijh bGciOiJIUzI1N..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW 1gFWFOEjXk”通过：SIP/2.0/UDP IP_UA；已接收=IP_UA
<- 200 OK ----------------------------
Via: SIP/2.0/UDP IP_TEP;branch=z9hG4bK776;
received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJh
bGciOiJIUzI1N..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW
1gFWFOEjXk"
Via: SIP/2.0/UDP IP_UA; received=IP_UA
<- 200 OK ----------------------------
Via: SIP/2.0/UDP IP_TEP;branch=z9hG4bK776;
received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJh
bGciOiJIUzI1N..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW
1gFWFOEjXk"
Via: SIP/2.0/UDP IP_UA; received=IP_UA
<- 200 OK------
Via: SIP/2.0/UDP IP_UA; received=IP_UA
<- 200 OK------
Via: SIP/2.0/UDP IP_UA; received=IP_UA
This specification defines a new Via header field parameter called 'received-realm' in the "Header Field Parameters and Parameter Values" sub-registry created by [RFC3968]. The syntax is defined in Section 5.6. The required information is:
本规范在[RFC3968]创建的“header field Parameters and parameter Values”子注册表中定义了一个名为“received realm”的新Via header field参数。第5.6节对语法进行了定义。所需资料如下：
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Via received-realm No RFC 8055
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Via received-realm No RFC 8055
This specification defines new JSON Web Token claims in the "JSON Web Token Claims" sub-registry created by [RFC7519].
本规范在[RFC7519]创建的“JSON Web令牌声明”子注册表中定义了新的JSON Web令牌声明。
Claim Name: sip_from_tag Claim Description: SIP From tag header field parameter value Change Controller: IESG Reference: RFC 8055, RFC 3261
索赔名称：sip_from_标签索赔描述：sip from标签标题字段参数值更改控制器：IESG参考：RFC 8055，RFC 3261
Claim Name: sip_date Claim Description: SIP Date header field value Change Controller: IESG Reference: RFC 8055, RFC 3261
索赔名称：sip_日期索赔描述：sip日期头字段值更改控制器：IESG参考：RFC 8055，RFC 3261
Claim Name: sip_callid Claim Description: SIP Call-Id header field value Change Controller: IESG Reference: RFC 8055, RFC 3261
索赔名称：sip_callid索赔描述：sip Call Id标头字段值更改控制器：IESG参考：RFC 8055，RFC 3261
Claim Name: sip_cseq_num Claim Description: SIP CSeq numeric header field parameter value Change Controller: IESG Reference: RFC 8055, RFC 3261
索赔名称：sip_cseq_num索赔描述：sip cseq数字标题字段参数值更改控制器：IESG参考：RFC 8055，RFC 3261
Claim Name: sip_via_branch Claim Description: SIP Via branch header field parameter value Change Controller: IESG Reference: RFC 8055, RFC 3261
索赔名称：sip_via_分支索赔描述：sip via branch header字段参数值更改控制器：IESG参考：RFC 8055，RFC 3261
As the 'received-realm' Via header field parameter can be used to trigger applications, it is important to ensure that the parameter has not been added to the SIP message by an unauthorized SIP entity.
由于“received realm”Via header字段参数可用于触发应用程序，因此确保未经授权的SIP实体未将该参数添加到SIP消息中非常重要。
The 'received-realm' Via header field parameter is inserted, signed, verified, and consumed within an operator network. The operator MUST discard parameters received from another network, and the parameter MUST only be inserted by SIP entities that are able to verify from which adjacent upstream network a SIP request is received.
通过报头字段参数插入、签名、验证并在运营商网络中使用“received realm”。运营商必须丢弃从另一个网络接收的参数，并且该参数只能由能够验证从哪个相邻上游网络接收SIP请求的SIP实体插入。
The operator also needs to take great care in ensuring that the key used to calculate the JWS Signature value is only known by the network entities signing and adding the JWS Signature to the 'received-realm' Via header field parameter of a SIP message and to network entities verifying and consuming the parameter value.
运营商还需要非常小心地确保用于计算JWS签名值的密钥仅由网络实体通过SIP消息的头字段参数签名并将JWS签名添加到“已接收领域”以及验证和使用参数值的网络实体知道。
The operator MUST use a key management policy that protects against unauthorized access to the stored keys within nodes where the keys associated with the JWS Signature are stored and that protects against cryptoanalysis attacks using captured data sent on the wire.
运营商必须使用密钥管理策略，以防止未经授权访问存储有JWS签名的密钥的节点内存储的密钥，并使用在线路上发送的捕获数据防止密码分析攻击。
A SIP entity MUST NOT use the adjacent network information if there is a mismatch between the JWS Signature received in the SIP header field and the JWS Signature calculated by the receiving entity.
如果在SIP头字段中接收的JWS签名与接收实体计算的JWS签名不匹配，则SIP实体不得使用相邻网络信息。
Generic security considerations for JWS are defined in [RFC7515].
[RFC7515]中定义了JWS的一般安全注意事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC7515]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<http://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <http://www.rfc-editor.org/info/rfc7519>.
[RFC7519]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络令牌（JWT）”，RFC 7519，DOI 10.17487/RFC7519，2015年5月<http://www.rfc-editor.org/info/rfc7519>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <http://www.rfc-editor.org/info/rfc7638>.
[RFC7638]Jones，M.和N.Sakimura，“JSON网络密钥（JWK）指纹”，RFC 7638，DOI 10.17487/RFC7638，2015年9月<http://www.rfc-editor.org/info/rfc7638>.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, <http://www.rfc-editor.org/info/rfc3968>.
[RFC3968]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理局（IANA）头字段参数注册表”，BCP 98，RFC 3968，DOI 10.17487/RFC3968，2004年12月<http://www.rfc-editor.org/info/rfc3968>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.
[RFC7518]Jones，M.，“JSON网络算法（JWA）”，RFC 7518，DOI 10.17487/RFC7518，2015年5月<http://www.rfc-editor.org/info/rfc7518>.
[TS.3GPP.23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 14.1.0, September 2016, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
[TS.3GPP.23.228]3GPP，“IP多媒体子系统（IMS）；第2阶段”，3GPP TS 23.228 14.1.012016年9月<http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
Acknowledgements
致谢
Thanks to Adam Roach and Richard Barnes for providing comments and feedback on the document. Francis Dupoint performed the Gen-ART review.
感谢亚当·罗奇和理查德·巴恩斯对该文件的评论和反馈。弗朗西斯·杜邦（Francis Dupoint）完成了《当代艺术评论》（Gen ART review）。
Authors' Addresses
作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
Email: christer.holmberg@ericsson.com
Email: christer.holmberg@ericsson.com
Yi Jiang China Mobile No.32 Xuanwumen West Street Beijing Xicheng District 100053 China
中国移动北京市西城区宣武门西街32号一江100053
Email: jiangyi@chinamobile.com
Email: jiangyi@chinamobile.com