idnits 2.17.1 draft-haluska-dispatch-charge-number-needed-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 16, 2010) is 5177 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-york-sipping-p-charge-info-07 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH J. Haluska 3 Internet-Draft Telcordia 4 Intended status: Informational February 16, 2010 5 Expires: August 20, 2010 7 The Need to Convey Charge Number in SIP 8 draft-haluska-dispatch-charge-number-needed-00 10 Abstract 12 This draft documents a need for the ability to signal a Charge Number 13 using SIP, and identifies one deployed though not yet standard 14 mechanism which addresses this need. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 20, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 This draft documents a need for the ability to signal a Charge Number 70 using SIP, and identifies one deployed though not yet standardized 71 mechanism which addresses this need. 73 2. Problem Statement 75 In the current PSTN in North America, a Charge Number is signaled 76 with call originations. The Charge Number identifies the customer or 77 account with which the caller is associated. In many cases it is the 78 same as the Calling Party Number, while in others it is different - 79 e.g. the main number for a business which has many individual calling 80 numbers. This might be needed for usage collection, but it also 81 could influence call processing, especially when a particular type of 82 service applies for any caller associated with a particular charge 83 number. 85 Services currently implemented in the PSTN including Operator 86 Services and Directory Assistance make use of Charge Number in 87 processing a call. Such services are migrating to SIP based 88 platforms, and the need to know the Charge Number still exists. For 89 example, branding may be based on the value of the Charge Number. 91 There is currently no IETF standardized mechanism to convey the 92 Charge Number in SIP. 94 Current SIP-ISUP interworking standards do not specify a SIP mapping 95 for the Charge Number parameter. Thus, when interworking from ISUP 96 to SIP, Charge Number is carried in an encapsulated ISUP message in a 97 MIME body. The P-Charge-Info header, if standardized, would be 98 useful in this role. 100 For SIP originated calls, there is no currently standardized way to 101 carry this information. The P-Charge-Info header, if standardized, 102 would be useful in this role. 104 [I-D.draft-york-sipping-p-charge-info-07] proposes a "P-Charge-Info" 105 SIP header for carrying charge information for a call. It is 106 intended to facilitate carrying information equivalent to Charge 107 Number for SIP originated calls. It is also intended to support PSTN 108 interworking by carrying the ISUP Charge Number value. 110 3. Conclusion 112 Operator Services and Directory Assistance, which are migrating to 113 SIP based platforms, have a continuing need to convey the Charge 114 Number associated with a caller. There is currently no standardized 115 mechanism defined for conveying this information in SIP; such a 116 mechanism is needed in order to provide these services. The 117 mechanism defined in [I-D.draft-york-sipping-p-charge-info-07] fills 118 this need. 120 4. IANA Considerations 122 This memo includes no request to IANA. 124 5. Security Considerations 126 Disclosure of Charge Number information to unauthorized parties could 127 reveal information about the caller's usage patterns. It could also 128 allow for the potential use of the Charge Number value by others 129 either to interfere with billing, or to access unauthorized services. 130 Thus, the Charge Number should not be disclosed to unauthorized 131 parties, should not be accepted from unauthorized parties, and should 132 not be modified by unauthorized parties. 134 6. References 136 6.1. Normative References 138 6.2. Informative References 140 [I-D.draft-york-sipping-p-charge-info-07] 141 York, D., "P-Charge-Info - A Private Header (P-Header) 142 Extension to the Session Initiation Protocol (SIP)". 144 Appendix A. Acknowledgements 146 The author would like to thank Dan York, Martin Dolly, Gary Munson, 147 and the members of the Operator Services Technical Forum. 149 Author's Address 151 John Haluska 152 Telcordia 153 331 Newman Springs Road 154 Red Bank, NJ 07701 155 USA 157 Phone: 158 Email: jhaluska@telcordia.com