RFC 7549
3GPP SIP URI Inter-Operator Traffic Leg Parameter
RFC 7549: 3GPP SIP URI Inter-Operator Traffic Leg Parameter 🎀
Okay bestie, let's get into this one 💖 RFC 7549 is titled 3GPP SIP URI Inter-Operator Traffic Leg Parameter. It was published by the Internet Engineering Task Force (IETF) in May 2015. The authors are C. Holmberg (Ericsson), J. Holm (Ericsson), R. Jesske (Deutsche Telekom), and M. Dolly (AT&T) 🫶 It's a Standards Track document with ISSN 2070-1721, which means it's official spec energy 👑 The header doesn't list anything it obsoletes or updates, so there's nothing to track there ✨
Abstract ✨
Okay so in 3GPP networks, the signaling path between a calling user and a called user can get chopped up into segments called traffic legs 🦋 Each traffic leg can cross networks run by different operators, and each one can have its own characteristics that are different from the other legs in the same call. A traffic leg might also be tied to multiple SIP dialogs. That happens when a Back-to-Back User Agent (B2BUA) that changes the SIP dialog identifier sits inside the traffic leg 🌸
This document defines a new SIP URI parameter, iotl (short for Inter-Operator Traffic Leg) 💅 You can put it in a SIP URI to show that the entity behind the address, or the entity in charge of the host part of the address, is the end of a specific traffic leg (or several traffic legs). Iconic 😭
The iotl SIP URI parameter in this document has known uses in 3GPP networks. It can also be used in other networks ✨
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 gone through public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.
For the current status of this document, any errata, and how to send feedback on it, check out 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.
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 read these documents carefully, because they explain 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 they are provided without warranty as described in the Simplified BSD License 🙈
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 . . . . . . . . . . . . . . . . . . . . . . . 171. Introduction 🦋
Okay so in a 3GPP network, an end-user device can connect (for example, through a radio access network) to its own operator's network, which is the home network [TS.3GPP.24.229]. It can also connect to another operator's network, which is the visited network [TS.3GPP.24.229]. When that happens, the user is called a roaming user 🌍
3GPP operator networks often aren't directly connected to each other. Instead, there might be intermediate networks between them, called 3GPP transit networks. These transit networks act at the SIP level or the IP level 💅
Like we said in the Abstract, the signaling path between a calling user and a called user can be split into segments called traffic legs. Each traffic leg can span networks owned by different operators, and it can have its own characteristics that differ from the other legs in the same call. A traffic leg might also be linked to multiple SIP dialogs, for example when a B2BUA [RFC3261] that changes the SIP dialog identifier sits inside the traffic leg 🫶
Intermediary entities can use traffic leg information to make policy decisions about things like media anchoring, signaling policy, inserting media functions (for example, a transcoder), and charging 👑
Here's a figure showing two users, Alice and Bob, and the different types of networks the signaling might go through. The signaling path can be split into several traffic legs, and the kind of traffic leg depends on how the signaling is routed 🎀
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 RolesIn Figure 1, Alice is the user starting the communication with Bob. Keep these details in mind too 🧚
Alice is attached to an originating network. That's either Alice's home network or a visited network (if Alice is roaming). Either way, any originating service is provided by Alice's home network 💖
Bob is attached to a terminating network. That's either Bob's home network or a visited network (if Bob is roaming). Either way, any terminating service is provided by Bob's home network 🌸
A transit network that provides transit functions (for example, translating 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 (short for Inter-Operator Traffic Leg). You can use it in a SIP URI to show that the entity behind the address, or the entity in charge of the host part of the address, is the end of a specific traffic leg (or several traffic legs) 🦋
This document defines the following iotl parameter values:
homea-homebhomeb-visitedbvisiteda-homeahomea-visitedavisiteda-homeb
SIP entities that don't support the SIP URI iotl parameter will simply ignore it if they receive it, 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 in this document has known uses in 3GPP networks. It can also be used in other networks 🌈
4. Traffic Leg Examples 🧚
4.1. General 💖
This section walks through examples of the different types of traffic legs in 3GPP networks 🫶
4.2. Originating Roaming Call 🦋
Here Alice is located in a visited network. When Alice sends the initial SIP INVITE request for a call, one traffic leg (called the 'visiteda-homea' traffic leg) represents the signaling path between Alice's User Agent (UA) and her home Serving Call Session Control Function (S-CSCF) [TS.3GPP.24.229] 🌸
4.3. Terminating Roaming Call 👑
Here Bob is located in a visited network. When Bob's home S-CSCF forwards the initial SIP INVITE request for a call towards Bob, one traffic leg (called the 'homeb-visitedb' traffic leg) represents the signaling path between Bob's home S-CSCF and Bob's UA 💅
4.4. Call from Originating Home to Terminating Home 🍓
Here Alice's home S-CSCF forwards the initial SIP INVITE request towards Bob's home S-CSCF. The signaling path between the two S-CSCFs represents one traffic leg (called the 'homea-homeb' traffic leg) 🎀
5. 'iotl' SIP URI Parameter ✨
5.1. Usage 💖
Okay bestie, so per [RFC3261] 💅, when a SIP entity slaps a SIP URI into an initial request for a dialog or a stand-alone request, that URI is what routes the request onward. It goes to another SIP entity addressed by the SIP URI, or to whichever entity handles the host part of it (like a SIP registrar 🧚). If that entity is the end of one or more traffic legs, the SIP entity that inserted the URI can add an iotl parameter to it to say what type(s) of traffic leg it is. Each parameter value names one type of traffic leg 🦋.
So for routing an initial SIP request for a dialog, or a stand-alone SIP request, a SIP entity can add the iotl parameter to either (a) the SIP URI of the Request-URI [RFC3261] or (b) the SIP URI of a Route header field [RFC3261] of that request. SIP entities can also add the iotl parameter to the SIP URI of a Path header field [RFC3327] or a Service-Route header field [RFC3608], so the parameter can show up later in a Route header field 🌸.
When a SIP entity gets an initial request for a dialog or a stand-alone request that has one or more SIP URI iotl parameters, it figures out the traffic leg type like this:
- if the SIP request has a single Route header field containing a SIP URI with an
iotlparameter, that parameter tells you the type of traffic leg 🎀; - if the SIP request has multiple Route header fields containing a SIP URI with an
iotlparameter, then theiotlparameter on the SIP URI of the topmost Route header field is the one that counts (or, if the topmost one has noiotlparameter, it's the SIP URI of the Route header field closest to the topmost). That parameter identifies the type of traffic leg 👑; or - if a SIP request has an
iotlparameter only in the Request-URI SIP URI, then that 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, but only if they know that the SIP URI will be used to mark 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 🦋.
Heads up: when a request gets routed between different networks, it might go through one or more IBCFs (Interconnection Border Control Functions) acting as network border entities 🚧.
5.2.2. homea-homeb
This value means that a SIP entity responsible for the host part of the SIP URI with this parameter is 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 means that the SIP entity addressed by the SIP URI with this parameter is the end of a traffic leg between the home network (terminating) of the called user and the visited network (terminating) where the called user is currently located 🧳.
In 3GPP, this traffic leg is either 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 called user's home network and the Access Transfer Control Function (ATCF) in the called user's visited network 📡.
5.2.4. visiteda-homea
This value means that a SIP entity responsible for the host part of the SIP URI with this parameter is the end of a traffic leg between the visited network (originating) where the calling user is located and the home network (originating) of the calling user 🍓.
In 3GPP, this traffic leg is either 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 means that the SIP entity addressed by the SIP URI with this parameter is the end of a traffic leg between the home network (originating) and the visited network (originating) where 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. It exists in scenarios where the home S-CSCF of the calling user forwards a request back to the visited network where the calling user's UE 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 means that a SIP entity responsible for the host part of the SIP URI with this parameter is 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. It 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 🎀.
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 32617. Security Considerations 🚨
Okay, this part is serious bestie 😭. The information in the iotl parameter is used for making policy decisions, and those policies can be tied to charging and triggering of services. 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. On top of that, 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 75499. 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,<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>.[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>.[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>.[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>.[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>.[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,<http://www.rfc-editor.org/info/rfc3325>.
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 ProxyOkay bestie, let's get into the examples 🦋
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 | | | |
|<---------------| | | |Figure 2: The UE Registers via P-CSCF
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>
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>
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>
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>A.3. Originating IMS Call ✨
Here's the vibe: when Alice sends her outgoing INVITE, the iotl value visiteda-homea (which she got back in the Service-Route header field during registration) gets tacked onto the Route header field for the Home Proxy (S-CSCF). That tells everyone the traffic leg type between the Visited Proxy (P-CSCF) and the Home Proxy (S-CSCF). Main character energy 💅
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 |<---------------| | |
|<---------------| | | |
| | | | |Figure 3: Originating IP Multimedia Subsystem (IMS) Call
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>
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>A.4. Terminating IMS Call 💜
Now the incoming side! For the terminating INVITE heading towards Alice, the iotl value homeb-visitedb (the one the S-CSCF got during registration) goes onto the Route header field for the Visited Proxy (P-CSCF). It shows the traffic leg type between the Home Proxy (S-CSCF) and the Visited Proxy (P-CSCF). It's giving organised 🎀
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
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
F4 INVITE P-CSCF -> Bob
INVITE sip:Bob@visitedb.net SIP/2.0Figure 4: Terminating IMS Call
A.5. Call between Originating Home and Terminating Home Network 🌈
Last but not least, the S-CSCF of the originating home network puts the iotl value homea-homeb into the Request-URI of the INVITE it sends to the S-CSCF of the terminating network. That flags the traffic leg type between the two S-CSCFs. Iconic 👑
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.0Figure 5: Call between Originating Home and Terminating Home Network
Acknowledgements
The authors wanna thank everyone in the 3GPP community who gave comments on the first version of this doc and chipped in with ideas and suggestions along the way 🫶 A super special thank you to Paul Kyziwat, Dale Worley, and Michael Hammer. Robert Sparks did 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📦 where this page comes from
- ietf: rfc7549 2015-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms