Network Working Group C. Holmberg
Internet-Draft J. Holm
Intended status: Standards Track Ericsson
Expires: October 27, 2014 R. Jesske
Deutsche Telekom
M. Dolly
ATT
April 25, 2014
SIP URI Inter Operator Traffic Leg parameter
draft-holmberg-dispatch-iotl-00.txt
Abstract
In telecommunication networks, the signalling path between a calling
user and a called user can be divided into smaller parts, 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. The
directionality in traffic legs relates to a SIP request creating a
dialogue and stand-alone SIP request.
This document defines a new SIP URI parameter, 'iotl', which 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.
The 'iotl' parameter is defined in order to fulfil requirements from
the 3rd-Generation Partnership Project (3GPP), but it can also be
used in other network environments.
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."
This Internet-Draft will expire on October 27, 2014.
Holmberg, et al. Expires October 27, 2014 [Page 1]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter April 2014
Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Originating roaming call . . . . . . . . . . . . . . . . 4
2.3. Terminating roaming call . . . . . . . . . . . . . . . . 4
2.4. Originating home to terminating home call . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. iotl SIP URI parameter . . . . . . . . . . . . . . . . . . . 5
4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 5
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. homeA-homeB . . . . . . . . . . . . . . . . . . . . . 6
4.2.3. homeB-visitedB . . . . . . . . . . . . . . . . . . . 6
4.2.4. visitedA-homeA . . . . . . . . . . . . . . . . . . . 6
4.2.5. homeA-visitedA . . . . . . . . . . . . . . . . . . . 6
4.2.6. visitedA-homeB . . . . . . . . . . . . . . . . . . . 7
5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In a telecommunication network, an end user can be attached (e.g.
using a radio access network) to its own operator network (home
Holmberg, et al. Expires October 27, 2014 [Page 2]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter April 2014
network), or to another operator's network (visited network). In the
latter case the user is referred to as a roaming user.
Telecommunication operator networks are often not connected directly
to each other. Instead, there might be intermediate networks,
referred to as transit networks, between them. A transit network
might act on a SIP level or on IP level.
In telecommunication networks, the signalling path between a calling
user and a called user can be divided into smaller parts, 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. The
directionality in traffic legs relates to a SIP request creating a
dialogue and stand-alone SIP request.
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.
Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob
Home + + + + + Home
+ ++++++++++++++++++ + +
+ + +
+ + +
+ +++++++++++++++++++++++ +
+ + + +
Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob
Visited Visited
Figure 1: Telecommunication operator network roaming roles
ORIG HNW = Originating Home Network
TERM HNW = Terminating Home Network
ORIG VNW = Originating Visited Network
TERM VNW = Terminating Visited Network
In Figure 1 Alice is a user initiating communication with Bob, and:
Holmberg, et al. Expires October 27, 2014 [Page 3]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter April 2014
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',
which 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.
The 'iotl' parameter is defined in order to fulfil requirements from
the 3rd-Generation Partnership Project (3GPP), but it can also be
used in other network environments.
2. Use-cases
2.1. General
This section describes examples of different types of traffic legs in
3GPP networks.
2.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 of Alice.
2.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.
Holmberg, et al. Expires October 27, 2014 [Page 4]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter April 2014
2.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).
3. 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].
4. iotl SIP URI parameter
4.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 a traffic leg, the SIP entity inserting the SIP
URI can add a SIP URI 'iotl' parameter to the SIP URI, to indicate
the 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.
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.
This document does not specify the usage of the 'iotl' parameter
within a SIP URI of a Record-Route header field [RFC3261].
4.2. Parameter Values
4.2.1. General
This section describes the SIP URI 'iotl' parameter values defined in
this specification.
Holmberg, et al. Expires October 27, 2014 [Page 5]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter April 2014
4.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.
4.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.
4.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 P-CSCF in the visited network,
serving the calling user, and the home S-CSCF of the calling user.
4.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.
Holmberg, et al. Expires October 27, 2014 [Page 6]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter April 2014
4.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 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.
5. Syntax
5.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].
5.2. ABNF
The ABNF [RFC5234] grammar for the role SIP URI parameter is:
uri-parameter = transport-param / user-param / method-param / ttl-param
/ maddr-param / lr-param / iotl-param / other-param
iotl-param = iotl-tag "=" iotl-value
iotl-tag = "iotl"
iotl-value = "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA"
/ "homeA-visitedA" /" visitedA-homeB" / gen-value
6. Security Considerations
There SHOULD exis a trust relationship between the networks that
provide the roaming role and the networks that use the information
for making policy decisions based on the role. In addition, there
MUST exist an agreement between the operators for usage of the
roaming role information.
7. 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
Holmberg, et al. Expires October 27, 2014 [Page 7]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter April 2014
registration in the "SIP/SIPS URI Parameters" registry as defined in
[RFC3969].
Parameter Name Predefined Values Reference
____________________________________________
iotl NO [This RFC]
8. Acknowledgments
The authors wish to thank everyone in the 3GPP community that gave
comments on the initial version of this document.
9. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
10. 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.
[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.
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg, et al. Expires October 27, 2014 [Page 8]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter April 2014
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 October 27, 2014 [Page 9]