iptel C. Sivachelvan Internet-Draft Cisco Systems, Inc. Intended status: Informational September 6, 2006 Expires: March 10, 2007 The Call Type tel URI Parameter for Session Initiation Protocol (SIP) draft-sivachelvan-iptel-call-type-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 10, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a standardized mechanism to convey the "Call Type" parameter in tel Uniform Resource Identifiers (URIs). A new extension to the tel URI is defined for this purpose. Call Type is a form of classification of a dialed number in a telephony call; it classifies the call as a Local-Call, Toll-Call, International-Call, etc. A definition of each Call Type addressed in this specification is provided in Section 2. Sivachelvan Expires March 10, 2007 [Page 1] Internet-Draft Tel Call Type Parameter September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 5. Parameter Definition . . . . . . . . . . . . . . . . . . . . . 7 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Sivachelvan Expires March 10, 2007 [Page 2] Internet-Draft Tel Call Type Parameter September 2006 1. Introduction This specification defines a tel URI parameter for carrying Call Type information between VoIP network elements within a service provider's administrative domain. In the PSTN, the originating switch types the call as a Local-Call, Toll-Call, Inter-Lata Call, etc., for billing, call screening and routing purposes. In a VoIP network, these functions are performed by different VoIP network elements (such as Softswitches/Outbound Proxies, Application Servers, MGCs, etc.). Hence, the Call Type may be determined as necessary at any of the hops in the signaling path; this requires that the necessary configuration (dial plan) information be provisioned at each network element that requires the Call Type information. Some Call Types are derived from the called number and caller's message rate center (or locale), while others are derived solely from the called number itself. The data used to derive the Call Type information varies country by country, therefore, the provisioning data required to derive the Call Type information is considered outside the scope of this specification. Traditionally, the Call Type information of a dialed number is derived from the dial plan provisioned at the outbound proxy, originating switch or B2BUA, or at the network element to which the called user is homed. Some of the examples and definitions of terms defined in this specification may be USA centric; however, an attempt is made to define the Call Types in a generic manner. 2. 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 RFC 2119. [1] 3. Definitions The terms defined in this section include various Call Types and related terms: Call Type: Call Type is a form of characterization of a called number of a telephony call. See below for details. Sivachelvan Expires March 10, 2007 [Page 3] Internet-Draft Tel Call Type Parameter September 2006 Carrier-Operator-Call: A call is identified as a "Carrier-Operator- Call" when a user dials a specific code ("00" - in the US) to reach a carrier operator. Directory-Assistance-Call: A call is identified as a "Directory- Assistance-Call" when a user dials a service code (telephony number) to reach the directory assistance service. In the US, "(1)+ 411" or "1+555+1212" code is used to reach the directory assistance service, which provides customer listing information (telephone number, address information, etc.). Emergency-Call: A Call is identified as an "Emergency Call" when a user has dialed a specific code to reach the emergency operator. Information-Service-Call: A call is identified as an "Information- Service-Call" when a user dials a service code to reach information services such as time, weather, traffic report, etc. Inter-LATA-Call: A call is identified as an "Inter-LATA" call, when a call originates in one Local Access and Transport Area (LATA) and terminates in another LATA. This Call Type applies to the USA only. Sometimes it is referred to as a "long distance call." International-Call: A call is identified as an "International-Call" when a call is made from one country to another country, provided that either or both of the calling and called numbers are not part of the "World Zone 1" (North America and the Caribbean). International-World-Zone1-Call: A call is identified as an "International-World-Zone1-Call" when a call is made from one country to another country within the "World Zone 1"(North America and the Caribbean). Local-Call: A call is identified as a "local-call" when the called number is in the same local serving area (or charging zone) as the calling user. Operator-Assist-International-Call: A call is identified as an "Operator-Assist-International-Call" when a user dials a specific code ("01 + International" - in the USA) plus the international number. Operator-Assist-National-Call: A call is identified as a "Operator- Assist-National-Call" when a user dials a specific code ( "0 + National number" - in the USA) plus the national number. Sivachelvan Expires March 10, 2007 [Page 4] Internet-Draft Tel Call Type Parameter September 2006 Operator-Call: A call is identified as an "Operator-Call" when a user dials a specific code ('0' - in the USA) to reach a local operator. PCS-Call: A call is identified as a "PCS-Call" when a user has dialed a code for accessing PCS (Personal Communication Service). In the USA, NPA 500 is a special numbering resource established by the INC for PCS [INC-95-0407-009]. Premium-Rate-call: A call is identified as a "Premium-Rate-Call" when a user diales a premium telephone number for accessing certain services for which the charges are higher than for a normal toll or Inter-LATA call. In the USA, the "Premium-Rate" telephony number is of the format 1.900.xxx.xxxx. It is also referred to as a "900 call." Relay-Service-Call: A call is identified as a "Relay-Service-Call" when a user has dialed a service code (telephone number) to reach the telecommunication relay service. In the USA, 711 code is used to reach the relay service which provides the ability for an individual who has hearing or speech disability to engage in a communication with a hearing individual. Repair-Service-Call: A call is identified as a "Repair-Service- Call" when a user has dialed a service code (telephony number) to reach the service provider's repair service center. In the USA 611 code is used to reach the repair service. Toll-Call: A call is identified as a "Toll-Call" when the called number is outside of the calling user's local serving area (charging zone). 4. Problem Statement In a VoIP network, the functions of a typical PSTN switch are decomposed into various VoIP network elements (such as a Proxy/B2BUA, AS, MGC, etc.) based on the roles they play in the call establishment process. As such, certain call-related information, such as Call Type, must be derived in each of the network element in the signaling path for billing and call screening purposes. The Call Type also plays an important role in the call routing process for calls that are destined for the PSTN. A typical reference model is shown Figure 1. Sivachelvan Expires March 10, 2007 [Page 5] Internet-Draft Tel Call Type Parameter September 2006 +-------+ | | | AS | | | +-------+ ^ | | | SIP| |SIP | | | V +-------+ +--------+ +-------+ | | SIP | | | | |Proxy/ |------------------->| MGC |------------->| PSTN | |B2BUA | | | | | | | +--------+ +-------+ +-------+ / / / / SIP \__/ / /\ / / \ / KEY: / \ AS - Application Server / UA \ B2BUA - Back-to-Back-User-Agent +------+ MGC - Media Gateway Controller SIP UA UA - User Agent Figure1: A Typical Reference Model In the above scenario, the outbound proxy ( or B2BUA) may derive the Call Type of a telephone call, for Call Detail Recording (CDR) purposes. Then it proxies the INVITE request to the Application Server (AS) for service/feature invocations. Some services, such as call barring or Class of Service Restriction, may require the Call Type information for screening the call. Hence the AS also needs to derive the Call Type information for call screening purposes. After the AS has finished with its role, it proxies the INVITE request back to the outbound proxy for subsequent handling of the call. It then proxies the INVITE request to the MGC. Here we assume that the call is destined for the PSTN. The MGC then derives the call type to select the appropriate outbound route (or Trunk Group) towards the PSTN interconnect. Sivachelvan Expires March 10, 2007 [Page 6] Internet-Draft Tel Call Type Parameter September 2006 In the above scenario, the Call Type information may be derived at three network elements. To do this, a considerable amount of dial plan information must be provisioned at each of these network elements. In order to alleviate this provisioning burden at each hop in the call path, this specification provides a mechanism to transmit the Call Type information from one element to another. Currently, there is no standardized means for transporting the Call Type information between VoIP network elements. This leads to provisioning overhead. The exact provisioning data that is required for deriving the Call Type information is outside the scope of this specification; this is primarily because the dial plan (configuration) data varies from country to country, and in some cases, it may vary from service provider to service provider. 5. Parameter Definition The Call Type shall be represented as a tel URI parameter because it is an attribute of the called party number. The ABNF RFC 2234 [2] syntax is defined as follows: call-type = ct-tag EQUAL ct-value ct-tag = "ct" call-type-value = "carrier-opr"/"dir-assist"/"emergency"/ "info-svc"/"inter-lata"/"international"/ "international-world-zone1"/"local"/ "opr-assist-international"/ "opr-assist-national"/"opr"/"pcs"/ "premium"/"relay"/"repair"/"toll"/ token An example of the syntax of the Call Type parameter is given below: INVITE tel:+1-214-469-0000; ct=local The normative procedures of Section 19.1.6 of RFC 3261 [3] can be used to derive an equivalent sip URI from a tel URI. 6. Usage The Call Type is used to characterize the dialed number of a telephone call, hence when used in the context of SIP signaling, it Sivachelvan Expires March 10, 2007 [Page 7] Internet-Draft Tel Call Type Parameter September 2006 is carried in the Request-URI of a SIP message. It can appear only once, if present. It is anticipated that this parameter will be primarily used by the Softswitches (or Call Agents), SIP proxies, Application servers and PSTN GWs for billing, call screening and call routing purposes. As such, it SHALL be first derived by an outbound proxy, B2BUA or a Softswitch which receives the SIP INVITE request from a UA. Various SIP intermediary network elements SHOULD consult the Call Type information for performing call screening and/or making routing decisions. Therefore, inclusion of this parameter in the INVITE message towards a downstream element is a local policy based on the trust realtionship, and MAY be controlled via the provisioning mechanism. The consumers of this parameter MUST discard this parameter, if the INVITE request was received from an untrusted source. When an intermediary rewrites the Request-URI due to redirection services, it MUST discard the received Call Type parameter and MAY elect to derive the Call Type parameter using the redirected to number. Intermediaries that do not support or recognize this parameter MAY elect to forward it to the downstream node according to the policy for handing unrecognized parameters. 7. Security Consideration The Call Type parameter is carried in the Request-URI, and this information is intended to be used within a given service provider's administrative domain. Maliciously modifying the Call Type Parameter by the intermediaries or "the man in the middle" could result in incorrect call screening, billing and/or call routing. Although this specification imparts additional information to the Request-URI, the class of attacks and possible protection mechanism are the same as that specified for baseline SIP systems in RFC 3261 [3]. Transport Layer Security (TLS) SHOULD be used to provide integrity protection, thereby mitigating these attacks. 8. IANA Considerations This specification requires no action by IANA. Sivachelvan Expires March 10, 2007 [Page 8] Internet-Draft Tel Call Type Parameter September 2006 9. Acknowledgements The author would like to thank Dave Auerbach, Sankar Manepalli, Sean Riley, Paul Kyzivat, Randy Ethier, Yiu Lee (Comcast) and Vijey Jenhal (Comcast) for their comments. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] 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. 10.2. Informative References Author's Address Chelliah Sivachelvan Cisco Systems, Inc. 2200 East President George Bush HWY Richardson, TX 75006 USA Email: chelliah@cisco.com Sivachelvan Expires March 10, 2007 [Page 9] Internet-Draft Tel Call Type Parameter September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Sivachelvan Expires March 10, 2007 [Page 10]