Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 7549 J. Holm
Category: Standards Track Ericsson
ISSN: 2070-1721 R. Jesske
Deutsche Telekom
M. Dolly
AT&T
May 2015
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 7549 J. Holm
Category: Standards Track Ericsson
ISSN: 2070-1721 R. Jesske
Deutsche Telekom
M. Dolly
AT&T
May 2015
3GPP SIP URI Inter-Operator Traffic Leg Parameter
3GPP SIP URI操作员间业务分支参数
Abstract
摘要
In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a Back-to-Back User Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg.
在3GPP网络中，主叫用户和被叫用户之间的信令路径可以被划分为段，称为业务分支。每个业务分支可以跨越属于不同运营商的网络，并且将具有其自身的特征，这些特征可以不同于同一呼叫中的其他业务分支。例如，在修改SIP对话框标识符的背对背用户代理（B2BUA）位于该流量分支内的情况下，该流量分支可与多个SIP对话框相关联。
This document defines a new SIP URI parameter, 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).
本文档定义了一个新的SIPURI参数“iotl”（运营商间业务分支的缩写）。该参数可在SIP URI中使用，以指示与地址关联的实体或负责地址主机部分的实体表示特定业务段（或多个业务段）的结束。
The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible.
本文档中定义的SIP URI“iotl”参数在3GPP网络中有已知用途。也可以在其他网络中使用。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc7549.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7549.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Traffic Leg Examples . . . . . . . . . . . . . . . . . . . . 6
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Originating Roaming Call . . . . . . . . . . . . . . . . 6
4.3. Terminating Roaming Call . . . . . . . . . . . . . . . . 7
4.4. Call from Originating Home to Terminating Home . . . . . 7
5. 'iotl' SIP URI Parameter . . . . . . . . . . . . . . . . . . 7
5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 8
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. homea-homeb . . . . . . . . . . . . . . . . . . . . . 8
5.2.3. homeb-visitedb . . . . . . . . . . . . . . . . . . . 8
5.2.4. visiteda-homea . . . . . . . . . . . . . . . . . . . 9
5.2.5. homea-visiteda . . . . . . . . . . . . . . . . . . . 9
5.2.6. visiteda-homeb . . . . . . . . . . . . . . . . . . . 9
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 12
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2. The UE Registers via P-CSCF . . . . . . . . . . . . . . . 12
A.3. Originating IMS Call . . . . . . . . . . . . . . . . . . 14
A.4. Terminating IMS Call . . . . . . . . . . . . . . . . . . 15
A.5. Call between Originating Home and Terminating Home
Network . . . . . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Traffic Leg Examples . . . . . . . . . . . . . . . . . . . . 6
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Originating Roaming Call . . . . . . . . . . . . . . . . 6
4.3. Terminating Roaming Call . . . . . . . . . . . . . . . . 7
4.4. Call from Originating Home to Terminating Home . . . . . 7
5. 'iotl' SIP URI Parameter . . . . . . . . . . . . . . . . . . 7
5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 8
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. homea-homeb . . . . . . . . . . . . . . . . . . . . . 8
5.2.3. homeb-visitedb . . . . . . . . . . . . . . . . . . . 8
5.2.4. visiteda-homea . . . . . . . . . . . . . . . . . . . 9
5.2.5. homea-visiteda . . . . . . . . . . . . . . . . . . . 9
5.2.6. visiteda-homeb . . . . . . . . . . . . . . . . . . . 9
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 12
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2. The UE Registers via P-CSCF . . . . . . . . . . . . . . . 12
A.3. Originating IMS Call . . . . . . . . . . . . . . . . . . 14
A.4. Terminating IMS Call . . . . . . . . . . . . . . . . . . 15
A.5. Call between Originating Home and Terminating Home
Network . . . . . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
In a 3GPP network, an end-user device can be attached (e.g., using a radio access network) to its own operator network (home network) [TS.3GPP.24.229] or to another operator's network (visited network) [TS.3GPP.24.229]. In the latter case, the user is referred to as a roaming user.
在3GPP网络中，最终用户设备可以连接（例如，使用无线电接入网络）到其自己的运营商网络（家庭网络）[TS.3GPP.24.229]或另一运营商网络（访问网络）[TS.3GPP.24.229]。在后一种情况下，该用户被称为漫游用户。
3GPP operator networks are often not connected directly to each other. Instead, there might be intermediate networks, referred to as 3GPP transit networks, between them. Such transit networks act on the SIP level or the IP level.
3GPP运营商网络通常不直接相互连接。相反，它们之间可能存在中间网络，称为3GPP传输网络。这种传输网络作用于SIP级别或IP级别。
In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a B2BUA [RFC3261] that modifies the SIP dialog identifier is located within the traffic leg.
在3GPP网络中，主叫用户和被叫用户之间的信令路径可以被划分为段，称为业务分支。每个业务分支可以跨越属于不同运营商的网络，并且将具有其自身的特征，这些特征可以不同于同一呼叫中的其他业务分支。例如，在修改SIP对话标识符的B2BUA[RFC3261]位于该通信分支内的情况下，该通信分支可与多个SIP对话相关联。
The traffic leg information can be used by intermediary entities to make policy decisions related to, e.g., media anchoring, signaling policy, insertion of media functions (e.g., transcoder), and charging.
中间实体可以使用业务段信息来做出与例如媒体锚定、信令策略、媒体功能的插入（例如转码器）和计费相关的策略决策。
The figure below shows two users (Alice and Bob) and the different type of networks that the signaling might traverse. The signaling path can be divided into multiple traffic legs, and the type of traffic legs depends on how the signaling is routed.
下图显示了两个用户（Alice和Bob）以及信令可能穿越的不同类型的网络。信令路径可分为多个业务分支，业务分支的类型取决于信令的路由方式。
Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob
Home + + + + + Home
+ ++++++++++++++++++ + +
+ + +
+ + +
+ +++++++++++++++++++++++ +
+ + + +
Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob
Visited Visited
Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob
Home + + + + + Home
+ ++++++++++++++++++ + +
+ + +
+ + +
+ +++++++++++++++++++++++ +
+ + + +
Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob
Visited Visited
ORIG HNW = Originating 3GPP Home Network TERM HNW = Terminating 3GPP Home Network ORIG VNW = Originating 3GPP Visited Network TERM VNW = Terminating 3GPP Visited Network TRANSIT NW = 3GPP Transit Network
ORIG HNW=始发3GPP家庭网络术语HNW=终止3GPP家庭网络ORIG VNW=始发3GPP访问网络术语VNW=终止3GPP访问网络传输NW=3GPP传输网络
Figure 1: 3GPP Operator Network Roaming Roles
图1:3GPP运营商网络漫游角色
In Figure 1, Alice is a user initiating communication with Bob. Also, consider the following information:
在图1中，Alice是启动与Bob通信的用户。此外，考虑以下信息：
Alice is attached to an originating network, which is either the home network of Alice or a visited network (in case Alice is roaming). In both cases, any originating service is provided by the home network of Alice.
Alice连接到发起网络，该网络是Alice的家庭网络或访问网络（如果Alice正在漫游）。在这两种情况下，任何原始服务都由Alice的家庭网络提供。
Bob is attached to a terminating network, which is either the home network of Bob or a visited network (in case Bob is roaming). In both cases, any terminating service is provided by the home network of Bob.
Bob连接到一个终端网络，该网络是Bob的家庭网络或访问的网络（如果Bob正在漫游）。在这两种情况下，任何终止服务都由Bob的家庭网络提供。
A transit network providing transit functions (e.g., translation of free phone numbers) may be included between the originating and terminating networks and between visited and home networks.
提供中转功能（例如，免费电话号码的翻译）的中转网络可包括在始发网络和终止网络之间以及到访网络和家庭网络之间。
This document defines a new SIP URI parameter [RFC3261], 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).
本文档定义了一个新的SIP URI参数[RFC3261]，“iotl”（运营商间业务分支的缩写）。该参数可在SIP URI中使用，以指示与地址关联的实体或负责地址主机部分的实体表示特定业务段（或多个业务段）的结束。
This document defines the following 'iotl' parameter values:
本文件定义了以下“iotl”参数值：
o homea-homeb
o homeahomeb
o homeb-visitedb
o 家庭访问
o visiteda-homea
o 参观家
o homea-visiteda
o 参观之家
o visiteda-homeb
o 参观家庭旅馆
SIP entities that do not support the SIP URI 'iotl' parameter will simply ignore it, if received, as defined in [RFC3261].
根据[RFC3261]中的定义，不支持SIP URI“iotl”参数的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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible.
本文档中定义的SIP URI“iotl”参数在3GPP网络中有已知用途。也可以在其他网络中使用。
This section describes examples of different types of traffic legs in 3GPP networks.
本节描述3GPP网络中不同类型业务分支的示例。
In this case, Alice is located in a visited network. When Alice sends the initial SIP INVITE request for a call, one traffic leg (referred to as the 'visiteda-homea' traffic leg) represents the signaling path between the User Agent (UA) of Alice and the home Serving Call Session Control Function (S-CSCF) [TS.3GPP.24.229] of Alice.
在这种情况下，Alice位于已访问的网络中。当Alice发送呼叫的初始SIP INVITE请求时，一个业务段（称为“visiteda homea”业务段）表示Alice的用户代理（UA）和Alice的家庭服务呼叫会话控制功能（S-CSCF）[TS.3GPP.24.229]之间的信令路径。
In this case, Bob is located in a visited network. When the home S-CSCF of Bob forwards the initial SIP INVITE request for a call towards Bob, one traffic leg (referred to as the 'homeb-visitedb' traffic leg) represents the signaling path between the home S-CSCF of Bob and the UA of Bob.
在这种情况下，Bob位于已访问的网络中。当Bob的归属S-CSCF将呼叫的初始SIP INVITE请求转发给Bob时，一个业务分支（称为“homeb visitedb”业务分支）表示Bob的归属S-CSCF和Bob的UA之间的信令路径。
In this case, the home S-CSCF of Alice forwards the initial SIP INVITE request towards the home S-CSCF of Bob. The signaling path between the S-CSCFs represents one traffic leg (referred to as the 'homea-homeb' traffic leg).
在这种情况下，Alice的家庭S-CSCF将初始SIP INVITE请求转发给Bob的家庭S-CSCF。S-cscf之间的信令路径表示一个业务分支（称为“homea-homeb”业务分支）。
As specified in [RFC3261], when a SIP entity inserts a SIP URI in an initial request for a dialog, or in a stand-alone request, the SIP URI will be used to route the request to another SIP entity, addressed by the SIP URI, or to a SIP entity responsible for the host part of the SIP URI (e.g., a SIP registrar). If such an entity represents the end of one or more traffic legs, the SIP entity inserting the SIP URI can add a SIP URI 'iotl' parameter to the SIP URI to indicate the type(s) of traffic leg. Each parameter value indicates a type of traffic leg.
如[RFC3261]中所述，当SIP实体在对话的初始请求或独立请求中插入SIP URI时，SIP URI将用于将请求路由到由SIP URI寻址的另一SIP实体，或路由到负责SIP URI主机部分的SIP实体（例如，SIP注册器）。如果这样的实体表示一个或多个业务分支的结束，则插入SIP URI的SIP实体可以向SIP URI添加SIP URI“iotl”参数，以指示业务分支的类型。每个参数值表示一种交通支路类型。
For routing of an initial SIP request for a dialog, or a stand-alone SIP request, a SIP entity can add the 'iotl' parameter to (a) the SIP URI of the Request-URI [RFC3261] or (b) the SIP URI of a Route header field [RFC3261] of the SIP request. SIP entities can add the 'iotl' parameter to the SIP URI of a Path header field [RFC3327] or a Service-Route header field [RFC3608] in order for the parameter to later occur in a Route header field.
对于对话的初始SIP请求或独立SIP请求的路由，SIP实体可以将“iotl”参数添加到（a）请求URI的SIP URI[RFC3261]或（b）SIP请求的路由头字段[RFC3261]的SIP URI。SIP实体可以将“iotl”参数添加到路径头字段[RFC3327]或服务路由头字段[RFC3608]的SIP URI中，以便该参数稍后出现在路由头字段中。
When a SIP entity receives an initial request for a dialog or a stand-alone request, which contains one or more SIP URI 'iotl' parameters, it identifies the type of traffic leg in the following way:
当SIP实体接收到包含一个或多个SIP URI“iotl”参数的对话或独立请求的初始请求时，它会以以下方式标识流量分支的类型：
o if the SIP request contains a single Route header field containing a SIP URI with an 'iotl' parameter, that parameter identifies the type of traffic leg;
o 如果SIP请求包含单个路由头字段，该字段包含具有“iotl”参数的SIP URI，则该参数标识业务分支的类型；
o if the SIP request contains multiple Route header fields containing a SIP URI with an 'iotl' parameter, the 'iotl' parameter associated with the SIP URI of the topmost Route header field (or, if the SIP URI of the topmost Route header field does not contain an 'iotl' parameter, the SIP URI of the Route header field closest to the topmost) identifies the type of traffic leg; or
o 如果SIP请求包含多个路由头字段，其中包含具有“iotl”参数的SIP URI，则与最顶端路由头字段的SIP URI关联的“iotl”参数（或者，如果最顶端路由头字段的SIP URI不包含“iotl”参数，则与最顶端路由头字段最接近的SIP URI）确定交通支路的类型；或
o if a SIP request contains an 'iotl' parameter only in the Request-URI SIP URI, the 'iotl' parameter identifies the type of traffic leg.
o 如果SIP请求仅在请求URI SIP URI中包含“iotl”参数，“iotl”参数标识流量分支的类型。
During SIP registration [RFC3261], entities can add the 'iotl' parameter to the SIP URI of a Path or Service-Route header field if the entity is aware that the SIP URI will be used to indicate the end of a specific traffic leg for initial requests for dialogs or stand-alone requests sent on the registration path.
在SIP注册[RFC3261]过程中，如果实体知道SIP URI将用于指示特定通信段的结束，以用于初始请求对话框或注册路径上发送的独立请求，则实体可以将“iotl”参数添加到路径或服务路由头字段的SIP URI中。
As defined in [RFC3261], a SIP proxy must not modify or remove URI parameters from SIP URIs associated with other entities. This also applies to the 'iotl' parameter.
如[RFC3261]中所定义，SIP代理不得修改或删除与其他实体关联的SIP URI中的URI参数。这也适用于“iotl”参数。
This section describes the SIP URI 'iotl' parameter values defined in this specification.
本节介绍本规范中定义的SIP URI“iotl”参数值。
Note that, when a request is routed between different networks, the request might traverse one or more IBCFs (Interconnection Border Control Functions) acting as network border entities.
请注意，当请求在不同网络之间路由时，该请求可能会遍历作为网络边界实体的一个或多个IBCFs（互连边界控制功能）。
This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the home network (originating) of the calling user and the home network (terminating) of the called user.
该值指示负责与参数相关联的SIP URI的主机部分的SIP实体表示主叫用户的归属网络（发起）和被叫用户的归属网络（终止）之间的业务分支的结束。
In 3GPP, this traffic leg is between two S-CSCFs.
在3GPP中，该业务段位于两个S-cscf之间。
This value indicates that the SIP entity addressed by the SIP URI associated with the parameter represents the end of a traffic leg between the home network (terminating) of the called user and the visited network (terminating) in which the called user is located.
该值指示由与参数相关联的SIP URI寻址的SIP实体表示被叫用户的家庭网络（终止）和被叫用户所在的到访网络（终止）之间的业务分支的结束。
In 3GPP, this traffic leg is between the home S-CSCF and the User Equipment (UE) of the called user or between the Service Centralization and Continuity Application Server (SCC AS) in the home network of the called user and Access Transfer Control Function (ATCF) in the visited network of the called user.
在3GPP中，该业务分支在归属S-CSCF和被叫用户的用户设备（UE）之间，或者在被叫用户的归属网络中的服务集中和连续性应用服务器（SCC AS）和被叫用户的到访网络中的访问转移控制功能（ATCF）之间。
This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the visited network (originating) in which the calling user is located and the home network (originating) of the calling user.
该值指示负责与参数相关联的SIP URI的主机部分的SIP实体表示主叫用户所在的到访网络（发起）和主叫用户的家庭网络（发起）之间的业务段的结束。
In 3GPP, this traffic leg is between the UE and the home S-CSCF of the calling user or between the Proxy Call Session Control Function (P-CSCF) in the visited network, serving the calling user and the home S-CSCF of the calling user.
在3GPP中，该业务分支位于UE和主叫用户的归属S-CSCF之间，或者位于为主叫用户和主叫用户的归属S-CSCF服务的到访网络中的代理呼叫会话控制功能（P-CSCF）之间。
This value indicates that the SIP entity addressed by the SIP URI associated with the parameter represents the end of a traffic leg between the home network (originating) and the visited network (originating) in which the calling user is located.
该值指示由与参数相关联的SIP URI寻址的SIP实体表示主叫用户所在的归属网络（发起）和到访网络（发起）之间的业务分支的结束。
In 3GPP, this traffic leg is between the home S-CSCF of the calling user and the Transit and Roaming Function (TRF) [TS.3GPP.24.229] serving the calling user and exists in scenarios where the home S-CSCF of the calling user forwards a request back to the visited network where the UE of the calling user is located. An example of this is when the Roaming Architecture for Voice over IMS with Local Breakout (RAVEL) [TS.3GPP.24.229] feature is enabled.
在3GPP中，该业务分支位于主叫用户的归属S-CSCF和服务于主叫用户的中转和漫游功能（TRF）[TS.3GPP.24.229]之间，并且存在于主叫用户的归属S-CSCF将请求转发回主叫用户的UE所在的到访网络的场景中。这方面的一个例子是，具有本地中断（RAVEL）[TS.3GPP.24.229]功能的IMS语音漫游体系结构启用时。
This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the visited network (originating) of the calling user and the home network (terminating) of the called user.
该值指示负责与参数相关联的SIP URI的主机部分的SIP实体表示主叫用户的访问网络（发起）和被叫用户的家庭网络（终止）之间的业务分支的结束。
In 3GPP, this traffic leg is between the TRF [TS.3GPP.24.229] serving the calling user and the home S-CSCF of the called user and exists in scenarios where a request is forwarded from the visited network where the calling user is located directly to the home S-CSCF of the called user. An example of this is when the RAVEL [TS.3GPP.24.229] feature is enabled.
在3GPP中，该业务段位于服务于呼叫用户的TRF[TS.3GPP.24.229]和被叫用户的家庭S-CSCF之间，并且存在于请求从呼叫用户直接位于被叫用户的到访网络转发到家庭S-CSCF的场景中。这方面的一个例子是RAVEL[TS.3GPP.24.229]功能启用时。
This section defines the ABNF for the 'iotl' SIP URI parameter. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234].
本节定义“iotl”SIP URI参数的ABNF。本规范中定义的ABNF符合RFC 5234[RFC5234]。
This specification does not create an IANA registry for 'iotl' parameter values. A registry should be considered if new parameter values are defined in the future.
本规范不为“iotl”参数值创建IANA注册表。如果将来定义了新的参数值，则应考虑使用注册表。
The ABNF [RFC5234] grammar for this SIP URI parameter is:
此SIP URI参数的ABNF[RFC5234]语法为：
uri-parameter =/ iotl-param
iotl-param = iotl-tag "=" iotl-value ["." iotl-value]
iotl-tag = "iotl"
iotl-value = "homea-homeb" / "homeb-visitedb" / "visiteda-homea"
/ "homea-visiteda" / "visiteda-homeb" / other-iotl
other-iotl = 1*iotl-char
iotl-char = alphanum / "-"
;; alphanum defined in RFC 3261
uri-parameter =/ iotl-param
iotl-param = iotl-tag "=" iotl-value ["." iotl-value]
iotl-tag = "iotl"
iotl-value = "homea-homeb" / "homeb-visitedb" / "visiteda-homea"
/ "homea-visiteda" / "visiteda-homeb" / other-iotl
other-iotl = 1*iotl-char
iotl-char = alphanum / "-"
;; alphanum defined in RFC 3261
The information in the 'iotl' parameter is used for making policy decisions. Such policies can be related to charging and triggering of services. In order to prevent abuse, which could cause user billing or service failure, the parameter SHOULD only be used for making policy decisions based on the role by nodes within the same trust domain [RFC3325], and network boundary entities MUST NOT forward information received from untrusted entities. In addition, an agreement MUST exist between the operators for usage of the roaming role information.
“iotl”参数中的信息用于决策。此类策略可能与服务的收费和触发有关。为了防止可能导致用户计费或服务失败的滥用，该参数应仅用于根据同一信任域内节点的角色做出策略决策[RFC3325]，并且网络边界实体不得转发从不受信任实体接收的信息。此外，运营商之间必须存在使用漫游角色信息的协议。
General security considerations for SIP are defined in [RFC3261]
[RFC3261]中定义了SIP的一般安全注意事项
Per this specification, IANA has added one new value to the "SIP/SIPS URI Parameters" registry as defined in [RFC3969].
根据本规范，IANA向[RFC3969]中定义的“SIP/SIPS URI参数”注册表添加了一个新值。
Parameter Name Predefined Values Reference
____________________________________________
iotl Yes RFC 7549
Parameter Name Predefined Values Reference
____________________________________________
iotl Yes RFC 7549
[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>.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, <http://www.rfc-editor.org/info/rfc3327>.
[RFC3327]Willis，D.和B.Hoeneisen，“用于注册非相邻联系人的会话启动协议（SIP）扩展头字段”，RFC 3327，DOI 10.17487/RFC3327，2002年12月<http://www.rfc-editor.org/info/rfc3327>.
[RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, DOI 10.17487/RFC3608, October 2003, <http://www.rfc-editor.org/info/rfc3608>.
[RFC3608]Willis，D.和B.Hoeneisen，“注册期间服务路由发现的会话启动协议（SIP）扩展头字段”，RFC 3608，DOI 10.17487/RFC3608，2003年10月<http://www.rfc-editor.org/info/rfc3608>.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, <http://www.rfc-editor.org/info/rfc3969>.
[RFC3969]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，DOI 10.17487/RFC3969，2004年12月<http://www.rfc-editor.org/info/rfc3969>.
[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>.
[TS.3GPP.24.229] 3GPP, "Vocabulary for 3GPP Specifications", 3GPP TS 24.229 12.6.0, September 2014.
[TS.3GPP.24.229]3GPP，“3GPP规范词汇”，3GPP TS 24.229 12.6.012014年9月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <http://www.rfc-editor.org/info/rfc3325>.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的专用扩展”，RFC 3325，DOI 10.17487/RFC3325，2002年11月<http://www.rfc-editor.org/info/rfc3325>.
This section contains example call flows based on 3GPP usage of the SIP URI 'iotl' parameter.
本节包含基于3GPP使用SIP URI“iotl”参数的呼叫流示例。
The Visited Proxy (P-CSCF) adds the 'iotl' value 'homeb-visitedb' to the Path header field of the REGISTER request to be used for terminating routing towards Alice. The Home Proxy (S-CSCF) adds the 'iotl' value 'visiteda-homea' to the Service-Route header field to be used for originating initial/stand-alone requests from Alice.
受访代理（P-CSCF）将“iotl”值“homeb visitedb”添加到注册请求的路径头字段中，以用于终止到Alice的路由。主代理（S-CSCF）将“iotl”值“visiteda homea”添加到服务路由头字段中，用于从Alice发起初始/独立请求。
Visited Proxy Visited Proxy Home Proxy Home Proxy
Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF
| | | | |
| REGISTER F1 | | | |
|--------------->| REGISTER F2 | | |
| |--------------->| REGISTER F3 | |
| | |--------------->| REGISTER F4 |
| | | |--------------->|
| | | | |
| | | | 200 (OK) F5 |
| | | |<---------------|
| | | 200 (OK) F6 | |
| | |<---------------| |
| | 200 (OK) F7 | | |
| |<---------------| | |
| 200 (OK) F8 | | | |
|<---------------| | | |
Visited Proxy Visited Proxy Home Proxy Home Proxy
Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF
| | | | |
| REGISTER F1 | | | |
|--------------->| REGISTER F2 | | |
| |--------------->| REGISTER F3 | |
| | |--------------->| REGISTER F4 |
| | | |--------------->|
| | | | |
| | | | 200 (OK) F5 |
| | | |<---------------|
| | | 200 (OK) F6 | |
| | |<---------------| |
| | 200 (OK) F7 | | |
| |<---------------| | |
| 200 (OK) F8 | | | |
|<---------------| | | |
F1 REGISTER Alice -> P-CSCF
REGISTER sip:registrar.home1.net SIP/2.0
F1 REGISTER Alice -> P-CSCF
REGISTER sip:registrar.home1.net SIP/2.0
F2 REGISTER P-CSCF -> IBCF-V
REGISTER sip:registrar.home1.net SIP/2.0
Path: <p-cscf URI;iotl=homeb-visitedb>
F2 REGISTER P-CSCF -> IBCF-V
REGISTER sip:registrar.home1.net SIP/2.0
Path: <p-cscf URI;iotl=homeb-visitedb>
F3 REGISTER IBCF-V -> IBCF-H
REGISTER sip:registrar.home1.net SIP/2.0
Path: <p-cscf URI;iotl=homeb-visitedb>
F3 REGISTER IBCF-V -> IBCF-H
REGISTER sip:registrar.home1.net SIP/2.0
Path: <p-cscf URI;iotl=homeb-visitedb>
F4 REGISTER IBCF-H -> S-CSCF
REGISTER sip:registrar.home1.net SIP/2.0
Path: <p-cscf URI;iotl=homeb-visitedb>
F4 REGISTER IBCF-H -> S-CSCF
REGISTER sip:registrar.home1.net SIP/2.0
Path: <p-cscf URI;iotl=homeb-visitedb>
F5 200 OK S-CSCF -> IBCF-H
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
F5 200 OK S-CSCF -> IBCF-H
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
F6 200 OK IBCF-H -> IBCF-V
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
F6 200 OK IBCF-H -> IBCF-V
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
F7 200 OK IBCF-V -> P-CSCF
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
F7 200 OK IBCF-V -> P-CSCF
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
F8 200 OK P-CSCF -> Alice
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
F8 200 OK P-CSCF -> Alice
200 OK
Path: <p-cscf URI;iotl=homeb-visitedb>
Service-Route: <s-cscf URI;iotl=visiteda-homea>
Figure 2: The UE Registers via P-CSCF
图2:UE通过P-CSCF注册
In the originating INVITE request from Alice, the 'iotl' value 'visiteda-homea', received in the Service-Route header field during registration, is added to the Route header field representing the Home Proxy (S-CSCF) to indicate the traffic leg type between the Visited Proxy (P-CSCF) and the Home Proxy (S-CSCF).
在来自Alice的原始INVITE请求中，注册期间在服务路由报头字段中接收的“iotl”值“visiteda homea”被添加到表示归属代理（S-CSCF）的路由报头字段中，以指示访问代理（P-CSCF）和归属代理（S-CSCF）之间的业务分支类型。
Visited Proxy Visited Proxy Home Proxy Home Proxy
Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| INVITE F3 | |
| | |--------------->| INVITE F4 |
| | | |--------------->|
| | | | |
| | | | 180 F5 |
| | | 180 F6 |<---------------|
| | 180 F7 |<---------------| |
| 180 F8 |<---------------| | |
|<---------------| | | |
| | | | |
Visited Proxy Visited Proxy Home Proxy Home Proxy
Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| INVITE F3 | |
| | |--------------->| INVITE F4 |
| | | |--------------->|
| | | | |
| | | | 180 F5 |
| | | 180 F6 |<---------------|
| | 180 F7 |<---------------| |
| 180 F8 |<---------------| | |
|<---------------| | | |
| | | | |
F1 INVITE Alice -> P-CSCF
INVITE sip:Bob@homeb.net SIP/2.0
Route: <p-cscf URI>,<s-cscf URI;iotl=visiteda-homea>
F1 INVITE Alice -> P-CSCF
INVITE sip:Bob@homeb.net SIP/2.0
Route: <p-cscf URI>,<s-cscf URI;iotl=visiteda-homea>
F2 INVITE P-CSCF -> IBCF-V
INVITE sip:Bob@homeb.net SIP/2.0
Route: <ibcf-v URI>,<s-cscf URI;iotl=visiteda-homea>
F2 INVITE P-CSCF -> IBCF-V
INVITE sip:Bob@homeb.net SIP/2.0
Route: <ibcf-v URI>,<s-cscf URI;iotl=visiteda-homea>
F3 INVITE IBCF-V -> IBCF-H
INVITE sip:Bob@homeb.net SIP/2.0
Route: <ibcf-h URI>,<s-cscf URI;iotl=visiteda-homea>
F3 INVITE IBCF-V -> IBCF-H
INVITE sip:Bob@homeb.net SIP/2.0
Route: <ibcf-h URI>,<s-cscf URI;iotl=visiteda-homea>
F4 INVITE IBCF-H -> S-CSCF
INVITE sip:Bob@homeb.net SIP/2.0
Route: <s-cscf URI;iotl=visiteda-homea>
F4 INVITE IBCF-H -> S-CSCF
INVITE sip:Bob@homeb.net SIP/2.0
Route: <s-cscf URI;iotl=visiteda-homea>
Figure 3: Originating IP Multimedia Subsystem (IMS) Call
图3：发起IP多媒体子系统（IMS）呼叫
In the terminating INVITE request towards Alice, the 'iotl' value 'homeb-visitedb' provided to the Home Proxy (S-CSCF) during registration is added to the Route header field representing the Visited Proxy (P-CSCF) to indicate the traffic leg type between the Home Proxy (S-CSCF) and the Visited Proxy (P-CSCF).
在针对Alice的终止INVITE请求中，在注册期间提供给归属代理（S-CSCF）的“iotl”值“homeb visitedb”被添加到表示访问代理（P-CSCF）的路由头字段中，以指示归属代理（S-CSCF）和访问代理（P-CSCF）之间的业务分支类型。
Home Proxy Home Proxy Visited Proxy Visited Proxy
S-CSCF . . . . IBCF-H . . . . . IBCF-V . . . . . P-CSCF . . . . . Bob
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| INVITE F3 | |
| | |--------------->| INVITE F4 |
| | | |--------------->|
| | | | |
| | | | 180 F5 |
| | | 180 F6 |<---------------|
| | 180 F7 |<---------------| |
| 180 F8 |<---------------| | |
|<---------------| | | |
| | | | |
Home Proxy Home Proxy Visited Proxy Visited Proxy
S-CSCF . . . . IBCF-H . . . . . IBCF-V . . . . . P-CSCF . . . . . Bob
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| INVITE F3 | |
| | |--------------->| INVITE F4 |
| | | |--------------->|
| | | | |
| | | | 180 F5 |
| | | 180 F6 |<---------------|
| | 180 F7 |<---------------| |
| 180 F8 |<---------------| | |
|<---------------| | | |
| | | | |
F1 INVITE S-CSCF -> IBCF-H
INVITE sip:Bob@visitedb.net SIP/2.0
Route: <ibcf-h URI>,<p-cscf-v URI;iotl=homeb-visitedb
F1 INVITE S-CSCF -> IBCF-H
INVITE sip:Bob@visitedb.net SIP/2.0
Route: <ibcf-h URI>,<p-cscf-v URI;iotl=homeb-visitedb
F2 INVITE IBCF-H -> IBCF-V
INVITE sip:Bob@visitedb.net SIP/2.0
Route: <ibcf-v URI>,<p-cscf-v URI;iotl=homeb-visitedb
F2 INVITE IBCF-H -> IBCF-V
INVITE sip:Bob@visitedb.net SIP/2.0
Route: <ibcf-v URI>,<p-cscf-v URI;iotl=homeb-visitedb
F3 INVITE IBCF-V -> P-CSCF
INVITE sip:Bob@visitedb.net SIP/2.0
Route: <p-cscf-v URI;iotl=homeb-visitedb
F3 INVITE IBCF-V -> P-CSCF
INVITE sip:Bob@visitedb.net SIP/2.0
Route: <p-cscf-v URI;iotl=homeb-visitedb
F4 INVITE P-CSCF -> Bob
INVITE sip:Bob@visitedb.net SIP/2.0
F4 INVITE P-CSCF -> Bob
INVITE sip:Bob@visitedb.net SIP/2.0
Figure 4: Terminating IMS Call
图4：终止IMS呼叫
The S-CSCF of the originating home network adds the 'iotl' value 'homea-homeb' in the Request-URI of the INVITE, sent towards the S-CSCF of the terminating network to indicate the traffic leg type between the S-CSCFs.
发起归属网络的S-CSCF在向终止网络的S-CSCF发送的INVITE的请求URI中添加“iotl”值“homea homeb”，以指示S-CSCF之间的业务分支类型。
Home-A Proxy Home-A Proxy Home-B Proxy Home-B Proxy Home-B Proxy
S-CSCF-A . . . . IBCF-A . . . . .IBCF-B . . . . .I-CSCF-B . . .S-CSCF-B
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| INVITE F3 | |
| | |--------------->| INVITE F4 |
| | | |--------------->|
| | | | |
| | | | 180 F5 |
| | | 180 F6 |<---------------|
| | 180 F7 |<---------------| |
| 180 F8 |<---------------| | |
|<---------------| | | |
| | | | |
Home-A Proxy Home-A Proxy Home-B Proxy Home-B Proxy Home-B Proxy
S-CSCF-A . . . . IBCF-A . . . . .IBCF-B . . . . .I-CSCF-B . . .S-CSCF-B
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| INVITE F3 | |
| | |--------------->| INVITE F4 |
| | | |--------------->|
| | | | |
| | | | 180 F5 |
| | | 180 F6 |<---------------|
| | 180 F7 |<---------------| |
| 180 F8 |<---------------| | |
|<---------------| | | |
| | | | |
F1 INVITE S-CSCF-A -> IBCF-A
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
F1 INVITE S-CSCF-A -> IBCF-A
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
F2 INVITE IBCF-a -> IBCF-B
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
F2 INVITE IBCF-a -> IBCF-B
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
F3 INVITE IBCF-B -> I-CSCF-B
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
F3 INVITE IBCF-B -> I-CSCF-B
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
F4 INVITE I-CSCF-B -> S-CSCF-B
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
F4 INVITE I-CSCF-B -> S-CSCF-B
INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0
Figure 5: Call between Originating Home and Terminating Home Network
图5：发起家庭网络和终止家庭网络之间的呼叫
Acknowledgements
致谢
The authors wish to thank everyone in the 3GPP community that gave comments on the initial version of this document and contributed with comments and suggestions during the work. A special thanks to Paul Kyziwat, Dale Worley, and Michael Hammer. Robert Sparks performed the Gen-ART review of the document.
作者希望感谢3GPP社区中对本文档的初始版本提出意见并在工作期间提出意见和建议的所有人。特别感谢Paul Kyziwat、Dale Worley和Michael Hammer。Robert Sparks对该文件进行了Gen ART审查。
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
Jan Holm Ericsson Kistavagen 25 Stockholm16480 Sweden
Jan Holm Ericsson Kistavagen 25 Stockholm 16480瑞典
EMail: jan.holm@ericsson.com
EMail: jan.holm@ericsson.com
Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany
罗兰·杰西克德国电信海因里希·赫兹大街3-7号达姆施塔特64307德国
Phone: +4961515812766
EMail: r.jesske@telekom.de
Phone: +4961515812766
EMail: r.jesske@telekom.de
Martin Dolly AT&T 718 Clairmore Ave Lanoka Harbor 08734 United States
美国拉诺卡港克莱尔莫尔大道718号马丁·多利电话电报公司08734
EMail: md3135@att.com
EMail: md3135@att.com