Internet DRAFT - draft-holmberg-dispatch-iotl
draft-holmberg-dispatch-iotl
Network Working Group C. Holmberg
Internet-Draft J. Holm
Intended status: Standards Track Ericsson
Expires: August 23, 2015 R. Jesske
Deutsche Telekom
M. Dolly
ATT
February 19, 2015
3rd-Generation Partnership Project (3GPP) SIP URI Inter Operator Traffic
Leg parameter
draft-holmberg-dispatch-iotl-06.txt
Abstract
In 3rd-Generation Partnership Project (3GPP) networks, the signalling
path between a calling user and a called user can be partioned 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 which modifies the SIP dialog
identifier is located within the traffic leg.
This document defines a new SIP URI parameter, 'iotl'. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Holmberg, et al. Expires August 23, 2015 [Page 1]
Internet-Draft 3GPP IOTL February 2015
This Internet-Draft will expire on August 23, 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Traffic leg examples . . . . . . . . . . . . . . . . . . . . 5
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Originating roaming call . . . . . . . . . . . . . . . . 5
3.3. Terminating roaming call . . . . . . . . . . . . . . . . 5
3.4. Originating home to terminating home call . . . . . . . . 5
4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. iotl SIP URI parameter . . . . . . . . . . . . . . . . . . . 6
5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 7
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.2. homea-homeb . . . . . . . . . . . . . . . . . . . . . 7
5.2.3. homeb-visitedb . . . . . . . . . . . . . . . . . . . 7
5.2.4. visiteda-homea . . . . . . . . . . . . . . . . . . . 7
5.2.5. homea-visiteda . . . . . . . . . . . . . . . . . . . 8
5.2.6. visiteda-homeb . . . . . . . . . . . . . . . . . . . 8
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 13
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
Holmberg, et al. Expires August 23, 2015 [Page 2]
Internet-Draft 3GPP IOTL February 2015
A.2. The UE registers via P-CSCF . . . . . . . . . . . . . . . 13
A.3. Originating IMS call . . . . . . . . . . . . . . . . . . 14
A.4. Terminating IMS call . . . . . . . . . . . . . . . . . . 15
A.5. Call between originating home and terminating home
network . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
In a 3rd-Generation Partnership Project (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 network act on SIP
level or on IP level.
In 3GPP networks, the signalling path between a calling user and a
called user can be partioned 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) [RFC3261] which 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, signalling
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 signalling
path can be divided into multiple traffic legs, and the type of
traffic legs depends on how the signalling is routed.
Holmberg, et al. Expires August 23, 2015 [Page 3]
Internet-Draft 3GPP IOTL February 2015
Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob
Home + + + + + Home
+ ++++++++++++++++++ + +
+ + +
+ + +
+ +++++++++++++++++++++++ +
+ + + +
Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob
Visited Visited
Figure 1: 3GPP operator network roaming roles
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
In Figure 1 Alice is a user initiating communication with Bob, and:
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 of 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).
This document defines the following 'iotl' parameter values:
Holmberg, et al. Expires August 23, 2015 [Page 4]
Internet-Draft 3GPP IOTL February 2015
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. Applicability
The SIP URI 'iotl' parameter defined in this document has known uses
in 3GPP networks. Usage in other networks is also possible.
3. Traffic leg examples
3.1. General
This section describes examples of different types of traffic legs in
3GPP networks.
3.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
signalling path between the UA of Alice and the home S-CSCF [3GPP TS
24.229] of Alice.
3.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 signalling path between the home S-CSCF
of Bob and the UA of Bob.
3.4. Originating home to terminating home call
In this case, the home S-CSCF of Alice forwards the initial SIP
INVITE request towards the home S-CSCF of Bob. The signalling path
between the S-CSCFs represents one traffic leg (referred to as the
'homea-homeb' traffic leg).
Holmberg, et al. Expires August 23, 2015 [Page 5]
Internet-Draft 3GPP IOTL February 2015
4. 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].
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 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 a SIP request, a SIP entity can add the 'iotl'
parameter to the SIP URI of the Request-URI [RFC3261], or to the SIP
URI of a Route header field [RFC3261], of an initial request for a
dialog, or of an stand-alone 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;
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.
Holmberg, et al. Expires August 23, 2015 [Page 6]
Internet-Draft 3GPP IOTL February 2015
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 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.
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.
In 3GPP, this traffic leg is between the home S-CSCF and the 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.
Holmberg, et al. Expires August 23, 2015 [Page 7]
Internet-Draft 3GPP IOTL February 2015
In 3GPP, this traffic leg is between the UE and the home S-CSCF of
the calling user, or between the 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) [3GPP TS 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) [3GPP TS 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 Transit and Roaming Function
(TRF) [3GPP TS 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 Roaming Architecture for Voice over IMS with Local
breakout (RAVEL) [3GPP TS 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.
Holmberg, et al. Expires August 23, 2015 [Page 8]
Internet-Draft 3GPP IOTL February 2015
6.2. ABNF
The ABNF [RFC5234] grammar for the role 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,
there MUST exist an agreement between the operators for usage of the
roaming role information.
General security considerations for SIP are defined in [RFC3261]
8. IANA Considerations
[RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this
document.] This specification adds one new value to the IANA
registration in the "SIP/SIPS URI Parameters" registry as defined in
[RFC3969].
Parameter Name Predefined Values Reference
____________________________________________
iotl Yes [This RFC]
9. Acknowledgments
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 suggestion during the work. A special thanks to
Paul Kyziwat, Dale Worley and Michael Hammer. Robert Sparks
performed the Gen-ARTreview of the draft.
Holmberg, et al. Expires August 23, 2015 [Page 9]
Internet-Draft 3GPP IOTL February 2015
10. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
draft-holmberg-dispatch-iotl-04
o Change based on IESG review from Stephen Farrell:
o - Editorial changes.
draft-holmberg-dispatch-iotl-04
o Change based on IESG review from Spencer Dawkins:
o - List of defined iotl parameter values listed in the
Introduction.
o - ABNF editorial fix.
o Change based on IESG review from Barry Leiba:
o - Only use lowercase when writing the iotl parameter values.
o Change based on IESG review from Alissa Cooper:
o - Sentence about usage in non-3GPP networks removed from the
Introduction.
o - Editorial correction in the Security Considerations.
o Change based on IESG review from Benoit Claise:
o - 'iotl' parameter name abbreviation extented in the Introduction.
o Change based on IESG review from Kathleen Moriarty:
o - Reference to RFC 3261 added to the Security Considerations.
o Change based on IESG review from Stephen Farrell:
o - Additional text and explanation added to the Security
Considerations.
draft-holmberg-dispatch-iotl-03
o Change based on Gen-ART review from Robert Sparks:
Holmberg, et al. Expires August 23, 2015 [Page 10]
Internet-Draft 3GPP IOTL February 2015
o - Removed text saying that the mechanism is scoped for 3GPP
networks only.
o - Clarify that entities that do not support the parameter will
ignore it.
o - Clarify that the draft does not create an IANA registry for
parameter values.
o - Remove sentence regarding directionality.
o - Reference to RFC 3327 added.
o - Reference to RFC 3608 added.
o - 'dialogue' -> 'dialog'.
o Change based on Ops-ART review from Nevil Brownlee:
o - Reference to RFC 3261 added to 'B2BUA'.
o - Reference to 3GPP TS 24.229 added for 'S-CSCF'.
draft-holmberg-dispatch-iotl-02
o Change based on comments from Richard Barnes:
o - 3GPP scope text modified.
o - Reference to 3GPP TS 24.229 added.
o - Reference to RFC 3325 added, and incorporated into the Security
Considerations.
o - 'iotl' selection procedure made into a bullet list.
draft-holmberg-dispatch-iotl-01
o Scope the SIP URI 'iotl' parameter to 3GPP, based on decision at
IETF#90:
o - Document name changed.
o - Clarified that usage of the parameter is only defined within
3GPP networks.
draft-holmberg-dispatch-iotl-00
Holmberg, et al. Expires August 23, 2015 [Page 11]
Internet-Draft 3GPP IOTL February 2015
o Added text on how to identify the traffic leg type when SIP-URIs
of multiple Route header fields and/or the Request-URI contain an
'iotl' parameter.
o Clarify that a traffic leg might span over multiple SIP dialogs.
o Added text saying that entities supporting the 'iotl' parameter
must not remove a parameter from a request, if the parameter is
associated with a SIP URI belonging to another entity.
o Modified ABNF, in order to allow multiple iotl values for a single
URI.
o In IANA section, changed indication that predefined values exist.
o Example call flows added.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 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,
June 2002.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002.
[RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Service Route Discovery
During Registration", RFC 3608, 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, December 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[TS.3GPP.24.229]
3GPP, "Vocabulary for 3GPP Specifications", 3GPP TS 24.229
12.6.0, September 2014.
Holmberg, et al. Expires August 23, 2015 [Page 12]
Internet-Draft 3GPP IOTL February 2015
11.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,
November 2002.
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: <p-cscf URI;iotl=homeb-visitedb>
Holmberg, et al. Expires August 23, 2015 [Page 13]
Internet-Draft 3GPP IOTL February 2015
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>
Figure 2: The UE registers via P-CSCF
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.
Holmberg, et al. Expires August 23, 2015 [Page 14]
Internet-Draft 3GPP IOTL February 2015
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>
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>
Figure 3: Originating IMS call
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.
Holmberg, et al. Expires August 23, 2015 [Page 15]
Internet-Draft 3GPP IOTL February 2015
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.0
Figure 4: Terminating IMS call
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.
Holmberg, et al. Expires August 23, 2015 [Page 16]
Internet-Draft 3GPP IOTL February 2015
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
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg, et al. Expires August 23, 2015 [Page 17]
Internet-Draft 3GPP IOTL February 2015
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
ATT
718 Clairmore Ave
Lanoka Harbor 08734
USA
Email: md3135@att.com
Holmberg, et al. Expires August 23, 2015 [Page 18]
