One document matched: draft-jesske-dispatch-transit-ioi-00.txt
dispatch R. Jesske
Internet-Draft Deutsche Telekom
Intended status: Informational August 09, 2010
Expires: February 10, 2011
transit ioi extension for the P-Charging-Vector header in SIP (Session
Initiation Protocol)
draft-jesske-dispatch-transit-ioi-00
Abstract
This document adds the term transit-ioi to the P-Charging-Vector
Header to mark the transit network in interconnection cases.
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 February 10, 2011.
Copyright Notice
Copyright (c) 2010 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.
This document may contain material from IETF Documents or IETF
Jesske Expires February 10, 2011 [Page 1]
Internet-Draft Sevicerouteing August 2010
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overall Applicability Statement of the transit-ioi . . . . . . 4
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Syntax definition for transit-ioi . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Jesske Expires February 10, 2011 [Page 2]
Internet-Draft Sevicerouteing August 2010
1. Terminology
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].
This document uses terms from [RFC3966].
2. Abbreviations
IMS IP Multimedia Subsystem
ISDN Integrated Service Digital Network
ISUP Integrated Services Digital Network User Part
PSTN Public Switched Telephone Network
SIP Session Initiation Protocol
URI Uniform Resource Identifier
VoIP Voice over IP
3. Overview
In [RFC3455] The P-Charging-Vector Header is defined. This header is
used to correlate the charging records generated from diffrent
entitis on the path of the call. The normal 3GPP used case covered
by this header is a normal call that is originated and terminated
within the own network and where originating and an terminating
network is diffrent either in roaming cases or interconnection. So
the billing and charging matters are normally handled between maximum
two networks.
But there are also fixed line carries using the IMS for their
purposes. The IMS is the replacement for the PSTN/ISND networks from
these operators. The buissenes modells are more complex within a
multi operator environment. There are local operators that have not
the interconnectivity with all operators, therefore transitcarriers
are needed.
In such cases the billing/charging process is spread over 3 Carriers
and more carriers. For such scenarios the knowledge of the transit
carrier is needed and should be also stated within the P-Charging-
Vetor Header.
Jesske Expires February 10, 2011 [Page 3]
Internet-Draft Sevicerouteing August 2010
+-----------+ +-----------+ +-----------+
|originating| ------\ | transit | ------\ | term- |
| Operator | \| Operator | \| minating |
| | /| | /| Operator |
| | ------/ | | ------/ | |
+-----------+ +-----------+ +-----------+
4. Requirements
REQ-1:
A mechanism is needed to identify the transit carrier within the
Charging record.
5. Overall Applicability Statement of the transit-ioi
The IOI identifies both the originating and terminating networks
involved in a SIP dialog or transaction outside a dialog. There may
an IOI generated from each side of the dialog to identify the network
associated with each side. This document adds the transit ioi
identifier.
The transit-ioi is added from the egress SIP proxy, sending the
initial request containing a P-Charging-Vector Header.
As described in [RFC3455] the P-Charging-Vector header is applicable
within a single private administrative domain or between different
administrative domains where there is a trust relationship between
the domains. The P-Charging-Vector header is not included in a SIP
message sent to another network if there is no trust relationship.
6. Example
We present example in the context of the scenario presented in the
following network diagram:
Scenario UA1 --- P1 --- P2 --- P3--- UA2
This example shows the message sequence for an INVITE transaction
originating from UA1 eventually arriving at UA2. P1 is an outbound
proxy for UA1. In this case P1 also inserts charging information.
P1 then routes the call to P2 due to existing interconnection
possibilities. P2 routs the call to P3 and P3 terminates the call at
Jesske Expires February 10, 2011 [Page 4]
Internet-Draft Sevicerouteing August 2010
UA2. Message sequence for INVITE using P-Charging-Vector:
F1 Invite UA1 -> P1
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE Contact: sip:ua1@192.0
F2 Invite P1 -> P2
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP P1.home1.net:5060;branch=z9hG4bK34ghi7a
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE Contact: sip:ua1@192.0.2.4
P-Charging-Vector:
icid-value=1234bc9876e;
icid-generated-at=192.0.6.8;
orig-ioi=home1.net
F3 Invite P2 -> P3
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP P2.home1.net:5060;branch=z9hGhG4bK34gh
Via: SIP/2.0/UDP P1.home1.net:5060;branch=z9hG4bK34ghi7a
Jesske Expires February 10, 2011 [Page 5]
Internet-Draft Sevicerouteing August 2010
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE Contact: sip:ua1@192.0.2.4
P-Charging-Vector:
icid-value=1234bc9876e;
icid-generated-at=192.0.6.8;
orig-ioi=home1.net
transit-ioi=transit.xyz.net
7. Syntax definition for transit-ioi
The Syntax of the P-Charging-Vector header syntax as defined within
[RFC3455] shall be exteded with the transit-ioi value.
transit-ioi = "transit-ioi" EQUAL gen-value
The transit-ioi parameters represent, respectively, the transit
interoperator identifier. It is used to correlate charging records
between different operators. The transit ioi represents the network
responsible for the records in the transit part of the session or
standalone request.
8. Security Considerations
The same security considerations as described within RFC3455 apply.
9. IANA Considerations
Registration of "transit-ioi" parameter for SIP P-Charging-Vector
header.
Registry:
Jesske Expires February 10, 2011 [Page 6]
Internet-Draft Sevicerouteing August 2010
Predefined
Header Field Parameter Name Values Reference
------------------- --------------- ------- ----------
P-Charging-Vector transit-ioi No [this RFC]
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC3455] "Private Header (P-Header) Extensions to the Session
Initiation Protocol (SIP) for the 3rd-Generation
Partnership Project (3GPP)", January 2003.
[RFC3966] "The tel URI for Telephone Numbers", October 2006.
Author's Address
Roland Jesske
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt, 64307
Germany
Phone: +4961516282766
Email: r.jesske@telekom.de
Jesske Expires February 10, 2011 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 01:55:51 |