From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7549.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc7549.txt (limited to 'doc/rfc/rfc7549.txt') diff --git a/doc/rfc/rfc7549.txt b/doc/rfc/rfc7549.txt new file mode 100644 index 0000000..1d4796e --- /dev/null +++ b/doc/rfc/rfc7549.txt @@ -0,0 +1,955 @@ + + + + + + +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 + +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. + + 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). + + The SIP URI 'iotl' parameter defined in this document has known uses + in 3GPP networks. Usage in other networks is also possible. + +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. + + 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. + + + + + +Holmberg, et al. Standards Track [Page 1] + +RFC 7549 3GPP 'iotl' May 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 2] + +RFC 7549 3GPP 'iotl' May 2015 + + +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 + + + + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 3] + +RFC 7549 3GPP 'iotl' May 2015 + + +1. Introduction + + 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 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. + + 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. + + 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. + + + + + + + + + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 4] + +RFC 7549 3GPP 'iotl' May 2015 + + + 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 + + Figure 1: 3GPP Operator Network Roaming Roles + + In Figure 1, Alice is a user initiating communication with Bob. Also, + consider the following information: + + 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. + + 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. + + 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). + + + + + + + + + + +Holmberg, et al. Standards Track [Page 5] + +RFC 7549 3GPP 'iotl' May 2015 + + + This document defines the following 'iotl' parameter values: + + o homea-homeb + + o homeb-visitedb + + o visiteda-homea + + o homea-visiteda + + o visiteda-homeb + + SIP entities that do not support the SIP URI 'iotl' parameter will + simply ignore it, if received, as defined in [RFC3261]. + +2. Conventions + + 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]. + +3. Applicability + + The SIP URI 'iotl' parameter defined in this document has known uses + in 3GPP networks. Usage in other networks is also possible. + +4. Traffic Leg Examples + +4.1. General + + This section describes examples of different types of traffic legs in + 3GPP networks. + +4.2. Originating Roaming Call + + 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. + + + + + + + + + + +Holmberg, et al. Standards Track [Page 6] + +RFC 7549 3GPP 'iotl' May 2015 + + +4.3. Terminating Roaming Call + + 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. + +4.4. Call from Originating Home to Terminating Home + + 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). + +5. 'iotl' SIP URI Parameter + +5.1. Usage + + 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. + + 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. + + 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: + + 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; + + + + + + +Holmberg, et al. Standards Track [Page 7] + +RFC 7549 3GPP 'iotl' May 2015 + + + 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 if a SIP request contains an 'iotl' parameter only in the Request- + URI SIP URI, the 'iotl' parameter identifies the type of traffic + leg. + + 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. + + 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. + +5.2. Parameter Values + +5.2.1. General + + This section describes the SIP URI 'iotl' parameter values defined in + this specification. + + 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. + +5.2.2. homea-homeb + + 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. + + In 3GPP, this traffic leg is between two S-CSCFs. + +5.2.3. homeb-visitedb + + 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. + + + +Holmberg, et al. Standards Track [Page 8] + +RFC 7549 3GPP 'iotl' May 2015 + + + 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. + +5.2.4. visiteda-homea + + 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. + + 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. + +5.2.5. homea-visiteda + + 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. + + 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. + +5.2.6. visiteda-homeb + + 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. + + 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. + + + + +Holmberg, et al. Standards Track [Page 9] + +RFC 7549 3GPP 'iotl' May 2015 + + +6. Syntax + +6.1. General + + This section defines the ABNF for the 'iotl' SIP URI parameter. The + ABNF defined in this specification is conformant to 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. + +6.2. ABNF + + The ABNF [RFC5234] grammar for this SIP URI parameter is: + + 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 + +7. Security Considerations + + 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. + + General security considerations for SIP are defined in [RFC3261] + +8. IANA Considerations + + Per this specification, IANA has added one new value to the "SIP/SIPS + URI Parameters" registry as defined in [RFC3969]. + + Parameter Name Predefined Values Reference + ____________________________________________ + iotl Yes RFC 7549 + + + + +Holmberg, et al. Standards Track [Page 10] + +RFC 7549 3GPP 'iotl' May 2015 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [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, + . + + [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, + . + + [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, . + + [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, + . + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [TS.3GPP.24.229] + 3GPP, "Vocabulary for 3GPP Specifications", 3GPP TS 24.229 + 12.6.0, September 2014. + +9.2. Informative References + + [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, + . + + + + +Holmberg, et al. Standards Track [Page 11] + +RFC 7549 3GPP 'iotl' May 2015 + + +Appendix A. 3GPP Examples + +A.1. General + + This section contains example call flows based on 3GPP usage of the + SIP URI 'iotl' parameter. + +A.2. The UE Registers via P-CSCF + + 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. + + 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 + + F2 REGISTER P-CSCF -> IBCF-V + REGISTER sip:registrar.home1.net SIP/2.0 + Path: + + F3 REGISTER IBCF-V -> IBCF-H + REGISTER sip:registrar.home1.net SIP/2.0 + Path: + + F4 REGISTER IBCF-H -> S-CSCF + REGISTER sip:registrar.home1.net SIP/2.0 + Path: + + + +Holmberg, et al. Standards Track [Page 12] + +RFC 7549 3GPP 'iotl' May 2015 + + + F5 200 OK S-CSCF -> IBCF-H + 200 OK + Path: + Service-Route: + + F6 200 OK IBCF-H -> IBCF-V + 200 OK + Path: + Service-Route: + + F7 200 OK IBCF-V -> P-CSCF + 200 OK + Path: + Service-Route: + + F8 200 OK P-CSCF -> Alice + 200 OK + Path: + Service-Route: + + Figure 2: The UE Registers via P-CSCF + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 13] + +RFC 7549 3GPP 'iotl' May 2015 + + +A.3. Originating IMS Call + + 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). + + 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: , + + F2 INVITE P-CSCF -> IBCF-V + INVITE sip:Bob@homeb.net SIP/2.0 + Route: , + + F3 INVITE IBCF-V -> IBCF-H + INVITE sip:Bob@homeb.net SIP/2.0 + Route: , + + F4 INVITE IBCF-H -> S-CSCF + INVITE sip:Bob@homeb.net SIP/2.0 + Route: + + Figure 3: Originating IP Multimedia Subsystem (IMS) Call + + + + + + + + + +Holmberg, et al. Standards Track [Page 14] + +RFC 7549 3GPP 'iotl' May 2015 + + +A.4. Terminating IMS Call + + 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). + +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-V + INVITE sip:Bob@visitedb.net SIP/2.0 + Route: , P-CSCF + INVITE sip:Bob@visitedb.net SIP/2.0 + Route: Bob + INVITE sip:Bob@visitedb.net SIP/2.0 + + Figure 4: Terminating IMS Call + + + + + + + + + + +Holmberg, et al. Standards Track [Page 15] + +RFC 7549 3GPP 'iotl' May 2015 + + +A.5. Call between Originating Home and Terminating Home Network + + 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. + +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 + + 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 + + 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 + + + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 16] + +RFC 7549 3GPP 'iotl' May 2015 + + +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. + +Authors' Addresses + + Christer Holmberg + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + EMail: christer.holmberg@ericsson.com + + + Jan Holm + Ericsson + Kistavagen 25 + Stockholm16480 + Sweden + + EMail: jan.holm@ericsson.com + + + Roland Jesske + Deutsche Telekom + Heinrich-Hertz-Strasse 3-7 + Darmstadt 64307 + Germany + + Phone: +4961515812766 + EMail: r.jesske@telekom.de + + + Martin Dolly + AT&T + 718 Clairmore Ave + Lanoka Harbor 08734 + United States + + EMail: md3135@att.com + + + + + + +Holmberg, et al. Standards Track [Page 17] + -- cgit v1.2.3