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]