idnits 2.17.1 draft-york-sipping-p-charge-info-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 17, 2011) is 4695 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 399 -- Looks like a reference, but probably isn't: '3' on line 399 -- Obsolete informational reference (is this intentional?): RFC 3455 (Obsoleted by RFC 7315) -- Obsolete informational reference (is this intentional?): RFC 3603 (Obsoleted by RFC 5503) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING D. York 3 Internet-Draft Voxeo 4 Intended status: Informational T. Asveren 5 Expires: December 19, 2011 Sonus 6 June 17, 2011 8 P-Charge-Info - A Private Header (P-Header) Extension to the Session 9 Initiation Protocol (SIP) 10 draft-york-sipping-p-charge-info-11 12 Abstract 14 This document describes 'P-Charge-Info', a private Session Initiation 15 Protocol (SIP) header (P-header) used to convey billing information 16 about the party to be charged. This P-Header is currently in 17 production usage by a number of equipment vendors and carriers and 18 this document is submitted to request the registration of this header 19 with IANA. This P-Header may also be used in some situations to 20 carry the ISUP Charge Number parameter for PSTN interconnection. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 19, 2011. 39 Copyright Notice 41 Copyright (c) 2011 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 Simplified BSD License. 54 Table of Contents 56 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 58 3. Purpose of this Document . . . . . . . . . . . . . . . . . . . 4 59 4. Examples of the Problem . . . . . . . . . . . . . . . . . . . 4 60 4.1. Use Case - Billing Identifier . . . . . . . . . . . . . . 4 61 4.2. Use Case - ISUP Charge Number . . . . . . . . . . . . . . 4 62 4.3. Use Case - Distributed Enterprise . . . . . . . . . . . . 4 63 4.4. Use Case - Hosted Telephony Provider . . . . . . . . . . . 5 64 5. Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. P-Charging-Vector . . . . . . . . . . . . . . . . . . . . 6 66 5.2. P-DCS-Billing-Info . . . . . . . . . . . . . . . . . . . . 6 67 5.3. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 7 68 6. The P-Charge-Info Header . . . . . . . . . . . . . . . . . . . 7 69 6.1. Applicability Statement for the P-Charge-Info header . . . 7 70 6.2. Usage of the P-Charge-Info header . . . . . . . . . . . . 7 71 6.2.1. Procedures at the UA . . . . . . . . . . . . . . . . . 8 72 6.2.2. Procedures at the Proxy . . . . . . . . . . . . . . . 8 73 6.3. Example of Usage . . . . . . . . . . . . . . . . . . . . . 8 74 6.4. Optional Parameters . . . . . . . . . . . . . . . . . . . 9 75 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 9.1. Trust Relationship . . . . . . . . . . . . . . . . . . . . 10 79 9.2. Untrusted Peers . . . . . . . . . . . . . . . . . . . . . 10 80 9.2.1. Ingress from Untrusted Peers . . . . . . . . . . . . . 10 81 9.2.2. Egress to Untrusted Peers . . . . . . . . . . . . . . 11 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 83 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 12. Appendix A: NPI Parameter Values . . . . . . . . . . . . . . . 13 85 13. Appendix B: NOA Parameter Values . . . . . . . . . . . . . . . 13 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 14.1. Normative References . . . . . . . . . . . . . . . . . . . 14 88 14.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Overview 93 In certain network configurations, it is desirable to decouple the 94 identity of the caller (what is normally thought of as "Caller ID") 95 from the identity/number used for billing purposes. This document 96 describes the current usage of 'P-Charge-Info', a private SIP header, 97 to provide simple billing information and requests the registration 98 of this header with IANA as required by section 4.2 of RFC 5727 99 [RFC5727]. 101 In a typical configuration, the identity of the caller, commonly 102 referred to as "Caller ID" by end users, is derived from one of the 103 following SIP headers: 105 o P-Asserted-Identity 107 o From (in the absence of P-Asserted-Identity) 109 (NOTE: Some service providers today also use the "Remote-Party-ID" 110 header but this was replaced by P-Asserted-Identity in RFC 3325.) 112 This identity/number is typically presented to the receiving UA where 113 it is usually displayed for the end user. It is also typically used 114 for billing purposes by the network entities involved in carrying the 115 session. 117 However, in some network configurations the "Caller ID" presented to 118 the receiving UA may be different from the number desired to be used 119 for billing purposes. 121 For example, the "Caller ID" may not reflect the actual reality of 122 the underlying network in terms of costs incurred on the PSTN. This 123 may result in excessive charging of one carrier by another based on 124 the erroneous assumption that the call was originating from a 125 different point on the PSTN. 127 Another example would be where a gateway to the Public Switched 128 Telephone Network (PSTN) receives the ISUP "Charge Number" in the 129 PSTN signaling which designates the number to be billed. The gateway 130 needs to pass this information along to a SIP entity associated with 131 billing. 133 In both these examples, there exists a need for a way to pass an 134 additional billing identifier that can be used between network 135 entities in order to correctly bill for services. At least one 136 equipment provider, Sonus Networks, and several carriers have been 137 using the "P-Charge-Info" header for the last 5 years as a simple 138 mechanism to exchange this billing identifier. 140 2. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119. 146 3. Purpose of this Document 148 This document has been prepared to comply with section 4 of RFC 5727 149 [RFC5727] to register this header with IANA. This document was 150 originally prepared to comply with sections 4.1 and 4.2 of the now 151 obsoleted RFC 3427. It is noted that RFC 5727 specifically 152 deprecates new usage of "P-" headers, but P-Charge-Info has been in 153 deployment for several years now. Given this, the authors request 154 that P-Charge-Info be admitted as a "grandfathered case" per section 155 4 of RFC 5727. 157 4. Examples of the Problem 159 4.1. Use Case - Billing Identifier 161 The simplest use case for P-Charge-Info could be an enterprise 162 environment where each SIP endpoint has a direct number that is 163 passed by the enterprise SIP proxy across to a SIP proxy at a SIP 164 Service Provider who provides PSTN connectivity. Rather than cause 165 the SIP Service Provider to have to track each individual direct 166 number for billing purposes, the enterprise SIP proxy could send in 167 the P-Charge-Info header a single billing identifier that the SIP 168 Service Provider uses for billing purposes. 170 4.2. Use Case - ISUP Charge Number 172 A second use case is one in which a PSTN gateway receives PSTN 173 signaling that includes an ISUP Charge Number parameter and the PSTN 174 gateway needs to send that ISUP Charge Number via SIP to other 175 servers. In this instance, the PSTN gateway will insert the ISUP 176 Charge Number into the P-Charge-Info SIP header. 178 4.3. Use Case - Distributed Enterprise 180 A third and common use case is a large enterprise with a widely 181 distributed SIP network to designate the specific point at which PSTN 182 interconnection occurs. Consider an enterprise with a work force and 183 offices distributed over a wide geographic area and linked by a 184 common internal network over which voice traffic is sent. Users 185 across the network may be able to contact each other directly via SIP 186 sessions, but there may only be a relatively few points in the 187 network where interconnection occurs to the PSTN. Consider this 188 case: 190 o A branch office in Massachusetts has a series of IP phones that 191 are connected via SIP to systems in the main office in Colorado 192 and from there via SIP connections to the PSTN through a SIP 193 service provider. 195 o The phones in the Massachusetts office have each been assigned a 196 direct, local phone number in the US area code of 617. 198 o This local 617 phone number is presented to callers on the PSTN as 199 the "Caller ID" based on its inclusion in the From and/or 200 P-Asserted-Identity SIP headers. 202 o This local 617 phone number may also be used by the SIP service 203 provider as the billing identifier and the call will be charged to 204 the enterprise according to the relevant rates. 206 o However, the call actually connected to the PSTN via the SIP 207 connection in the Colorado office where the USA area code is 303. 209 Rather than use the direct numbers of each SIP endpoint for 210 generating the billing information, the enterprise might choose to 211 instead pass the SIP URI of the PSTN interconnection point in the 212 P-Charge-Info header, either for simplicity or potentially to obtain 213 better rates from the SIP service provider. 215 4.4. Use Case - Hosted Telephony Provider 217 Similar to the third use case of a large enterprise, a hosted 218 telephony provider or hosted voice application provider may have a 219 large SIP network with customers distributed over a very large 220 geographic area using local market PSTN numbers but with only a very 221 few actual PSTN interconnection points. 223 As with the branch office earlier, the customer may have all local 224 phone numbers yet outgoing calls are actually being routed across a 225 SIP network and out specific PSTN gateways or across specific SIP 226 connections to SIP service providers. The hosted provider may want 227 to pass a billing identifier to its SIP service providers again 228 either for the purpose of simplicity in billing or to obtain better 229 rates from the SIP service providers. 231 5. Alternatives 233 5.1. P-Charging-Vector 235 P-Charging-Vector is defined in section 4.6 of RFC 3455 [RFC3455] and 236 used by the 3GPP to carry information related to the charging of a 237 session. There are, however, some differences in the semantics 238 associated with P-Charging-Vector and P-Charge-Info. P-Charging- 239 Vector is mainly used to carry information for correlation of 240 multiple charging records generated for a single session. On the 241 other hand, P-Charge-Info is used to convey information about the 242 party to be billed for a call. Furthermore, P-Charging-Vector has a 243 mandatory icid-value parameter which is a globally unique value to 244 identify the session for which the charging information is generated. 245 Such a globally-unique identifier is not necessary when carrying 246 information about the user to be billed when it is attached to the 247 corresponding session-related signaling. 249 5.2. P-DCS-Billing-Info 251 P-DCS-Billing-Info is defined in section 7 of RFC 3603 [RFC3603] and 252 used for passing billing information between trusted entities in the 253 PacketCable Distributed Call Signaling Architecture. For many 254 billing situations, particularly the very large-scale residential 255 telephone networks for which this header is designed, P-DCS-Billing- 256 Info is an excellent solution. However, this ability to address a 257 range of situations adds complexity. According to RFC 3603, each use 258 of the P-DCS-Billing-Info header MUST include in the header the 259 following: 261 o Billing-Correlation-ID, a globally unique identifier 263 o Financial-Entity-ID 265 o RKS-Group-ID (record keeping server 267 and may include a variety of additional parameters. 269 While this may work well in many billing scenarios, there are other 270 billing scenarios that do not at all need this level of complexity. 271 In those simpler scenarios all that is needed is simply a number to 272 use for billing. P-Charge-Info provides this simple solution for 273 simple billing scenarios. 275 Additionally, section 7.3 of RFC 3603 mandates that a UA MUST create 276 a Billing-Correlation-ID and insert this into the P-DCS-Billing-Info 277 header (along with the other required information) sent in the 278 initial SIP INVITE. This again makes sense for the residential 279 telephone service environment for which this header is designed. In 280 contrast, P-Charge-Info is designed to be used among proxies and not 281 to be used at all by normal user agents. (P-Charge-Info may, though, 282 by used by user agents associated with PSTN gateways.) 284 5.3. P-Asserted-Identity 286 Early reviewers of this document asked why the "P-Asserted-Identity" 287 header documented in RFC 3325 [RFC3325] could not be used. As 288 mentioned in the use case example above, P-Asserted-Identity is used 289 to indicate the identity of the calling party. However, in this 290 instance, the requirement is to provide an additional identity of the 291 SIP-to-PSTN interconnect point. 293 It would be typical to find both P-Asserted-Identity and P-Charge- 294 Info used in a SIP exchange. P-Asserted-Identity would be used to 295 provide the caller identity which would be displayed to the end user 296 as "Caller ID" while P-Charge-Info would provide the billing 297 identifier used for the billing associated with the call. 299 6. The P-Charge-Info Header 301 6.1. Applicability Statement for the P-Charge-Info header 303 The P-Charge-Info header is applicable within a single private 304 administrative domain or between different administrative domains 305 where there is a trust relationship between the domains. 307 6.2. Usage of the P-Charge-Info header 309 The P-Charge-Info header is used to convey information about the 310 identity of the party to be charged. The P-Charge-Info header is 311 typically inserted by one of the following: 313 o the SIP proxy on the originating network; 315 o a PSTN gateway acting as a SIP UA; or 317 o an application server generating billing information. 319 P-Charge-Info is to be consumed by the SIP entity that provides 320 billing services for a session. This could be an entity generating 321 billing records or an entity interacting with another enitity 322 generating billing records. Upon receipt of an INVITE request with 323 P-Charge-Info header, such an entity SHOULD use the value present in 324 the P-Charge-Info as indicating the party responsible for the charges 325 associated with the session. 327 6.2.1. Procedures at the UA 329 The P-Charge-Info header may be inserted by PSTN gateways or 330 application servers acting as a SIP UA, either through local policy 331 or as a result of information received via PSTN signaling, e.g. the 332 Charge Number parameter in an ISUP IAM message. 334 The P-Charge-Info header is not used/interpreted by a regular UA and 335 should not normally be seen by such a UA. If the header is 336 transmitted to such a UA, the UA SHOULD ignore the header. 338 A PSTN gateway or application server acting as a UA MAY use the 339 content of the P-Charge-Info header present in an INVITE request it 340 received for billing related procedures, e.g. in a billing record or 341 during interaction with another entity generating billing records, as 342 the identity of the party to be charged for the session. A PSTN 343 gateway or application server acting as a UA MAY use the content of 344 the P-Charge-Info header to populate information about the identity 345 of the party to charge in another type of signaling, e.g. ISUP. 347 6.2.2. Procedures at the Proxy 349 A SIP proxy that supports this extension and receives a request, 350 typically a SIP INVITE, without the P-Charge-Info header MAY insert a 351 P-Charge-Info header. The contents of the inserted header may be 352 decided based on local policy or by querying an external entity to 353 determine the identity of the party to be charged. 355 A proxy MAY use the content of the P-Charge-Info header present in an 356 INVITE request it received for billing related procedures, e.g. in a 357 billing record or during interaction with another entity generating 358 billing records. 360 A SIP proxy that does not support this extension will pass any 361 received P-Charge-Info header unmodified in compliance with RFC 3261. 363 A proxy supporting this extension SHOULD remove the P-Charge-Info 364 header before sending a request to a UA that is not acting as a PSTN 365 gateway or appropriate application server. 367 6.3. Example of Usage 369 The content of the P-Charge-Info header is typically simply a SIP URI 370 used as a billing indicator. As such, an example would be as simple 371 as: 373 P-Charge-Info: 374 Any other applicable SIP URI could be used. 376 6.4. Optional Parameters 378 P-Charge-Info optionally includes the additional parameters of the 379 "Numbering Plan Indicator" and "Nature of Address". These are used 380 when the ISUP Charge Number value needs to be passed as part of 381 P-Charge-Info. For instance, this might be required in a SIP message 382 for scenarios where SIP is used to connect two PSTN segments and 383 needs to pass charging information between them. 385 An example of the usage of the optional parameters is: 387 P-Charge-Info: 389 Values passed in the "npi" and "noa" parameters are expressed as 390 decimal numbers and possible values are defined in Appendix A and 391 Appendix B. 393 7. Formal Syntax 395 The Private Header specified in this document is described in both 396 prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234. 397 Further, several BNF definitions are inherited from SIP and are not 398 repeated here. Implementors need to be familiar with the notation 399 and contents of SIP [1] and RFC 2234 [3] to understand this document. 401 The syntax of the P-Charge-Info header is described as follows: 403 P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec) 404 ; name-addr and addr-spec are specified in RFC 3261 405 charge-param = npi-param / noa-param / generic-param 406 npi-param = ";npi" EQUAL npi-value 407 ; generic-param is specifed in RFC 3261 408 npi-value = gen-value 409 noa-param = ";noa" EQUAL noa-value 410 noa-value = gen-value 412 The SIP URI is the billing indicator that is passed between the 413 parties. 415 charge-param is used as a userinfo parameter in P-Charge-Info. 417 The two optional parameters for PSTN interoperability are mentioned 418 in the previous section and are: 420 o npi = "Numbering Plan Indicator" 422 o noa = "Nature of Address" 424 The "npi-value" is constrained to the possible values listed in 425 Appendix A. 427 Possible values for the "noa-value" are listed in Appendix B. 429 8. IANA Considerations 431 This document defines a private SIP extension header field (beginning 432 with the prefixe "P-"). 434 The extension is registered as a private extension field: 436 RFC Number: RFCXXXX [Note to IANA: Please fill in with the RFC number 437 of this specification. 439 Header Field Name: P-Charge-Info 441 Compact Form: none 443 9. Security Considerations 445 9.1. Trust Relationship 447 Given that the information contained in the P-Charge-Info header will 448 be used for billing purposes the proxies and other SIP entities that 449 share this information MUST have a trust relationship. 451 If an untrusted entity were inserted between the trusted entities, it 452 could potentially interfere with the billing records for the call. 453 If the SIP connections are not made over a private WAN, a mechanism 454 for securing the confidentiality and integrity of the SIP connection 455 should be used to protect the information. One such mechanism could 456 be TLS-encryption of the SIP signaling stream. 458 9.2. Untrusted Peers 460 9.2.1. Ingress from Untrusted Peers 462 If the P-Charge-Info header was accepted by a SIP entity from an 463 untrusted peer, there is the potential for fraud if the untrusted 464 entity sent incorrect information, either inadvertently or 465 maliciously. 467 Therefore a SIP entity MUST remove and ignore the P-Charge-Info 468 header when it is received from an untrusted entity. 470 9.2.2. Egress to Untrusted Peers 472 If the P-Charge-Info header was sent by a SIP entity to an untrusted 473 peer, there is the potential exposure of network information that is 474 internal to a trust domain. For instance, the untrusted entity may 475 learn the identities of public SIP proxies used within the trust 476 domain which could then potentially be directly attacked. 478 Therefore a SIP entity MUST remove the P-Charge-Info header when it 479 is sent to an untrusted entity. 481 10. Acknowledgements 483 The authors thank the following people for their comments, criticism, 484 suggestions and assistance with ABNF notation: Keith Drage, Miguel 485 Garcia, Christer Holmberg, Paul Kyzivat, Jonathan Rosenberg, Juha 486 Heinanen, Sumit Garg and Tom Taylor. The authors thank Glen Wang for 487 helping clarify the NPI parameter values with the reference to ANSI 488 T1.113. 490 The authors want to specificially thank John Haluska for a great 491 range of comments and specific information related to interworking 492 with the ISUP Charge Number. 494 11. Changes 496 NOTE TO RFC EDITOR - Please remove this "Changes" section prior to 497 publication. Thank you. 499 Revision -11 represents a fairly significant revision responding to a 500 solid review by Paul Kyzivat and providing additional explanation. A 501 major shift was the move to using decimal values for the npi-value 502 parameter versus the text values of previous drafts. Changes 503 include: 505 o ABNF definition updated to indicate that npi is now a number vs 506 text. 508 o The "npi" and "noa" acronyms were expanded and stated near the 509 formal syntax definition. 511 o New section created explicitly mentioning the optional parameters. 513 o Example of optional parameters updated to have npi use a number vs 514 text. 516 o Appendix B added to give examples of NOA parameter. 518 o Overview text updated to indicate that P-Charge-Info was been in 519 use now for over 5 years (given that the draft has been in 520 development for 3 years). 522 o Several small fixes for readability. 524 Revision -10 included the following modifications: 526 o Formal ABNF definition updated. 528 o In formal syntax, semicolons added to npi-param and noa-param 529 definitions. 531 o npi-param changed to a 'gen-value' to use digits vs text. Values 532 npi-param are shown in Appendix A. 534 o Corrected example to show proper use of parameters. 536 o Updated references to RFC 3427 and RFC 3968 to reference RFC 5727. 538 Revision -09 included the following modifications: 540 o Re-submitted with only a date change. Discussions are ongoing to 541 finalize this draft and submit it for expert review. 543 Revision -08 included the following modifications: 545 o The ABNF for the "npi-value" was modified to conform to the 546 sequence of possible values stated in ANSI T1.113. 548 o An Appendix A was created listing the values from ANSI T1.113. 550 Revision -07 was updated to the "trust200902" IPR statement and added 551 references to RFC 3968. At this point all comments have been 552 incorporated and publication will be requested. 554 Revision -06 had only a minor correction to the second usage example. 555 The IPR statement was also updated to comply with RFC 5378. 557 Revision -05 included the following modifications: 559 o The usage of P-Charge-Info for carrying the ISUP Charge Number 560 parameter was formally incorporated into the draft. Previous 561 revisions had mentioned it as a possible use case but had not 562 really explicitly included it. 564 o The examples/use cases section was expanded to include further 565 examples of where P-Charge-Info may be used. 567 o The original use case which discussed inter/intra-state billing 568 practices was changed as the geographical references were clouding 569 the more fundamental issue. 571 o The "UNKNOWN" value was added to the ABNF for the "npi-value" 572 parameter as that was identified as missing but required for ISUP 573 interworking. 575 o The optional "Nature of Address" parameter was added to support 576 interworking with the ISUP Charge Number. 578 Revision -04 corrected a major error in the example where the 579 parameter was placed inside the angle brackets. The P-DCS-Billing- 580 Info header was also added as an alternative and a few minor edits 581 were made. 583 12. Appendix A: NPI Parameter Values 585 To better understand the possible values for the optional NPI 586 parameter, ANSI T1.113 states that the 'numbering plan indicator' may 587 contain the following values: 589 000 unknown (no interpretation) 590 001 ISDN (Telephony) numbering plan (Recommendation E-164) 591 010 spare (no interpretation) 592 011 reserved (CCITT Data numbering plan) 593 100 reserved (CCITT Telex numbering plan) 594 101 Private numbering plan 595 110 spare (no interpretation) 596 111 spare (no interpretation) 598 Note that the values shown here are in binary notation per ANSI 599 T1.113, but when the values are passed in the NPI parameter of 600 P-Charge-Info they are represented in decimal notation. 602 13. Appendix B: NOA Parameter Values 604 To better understand the possible values for the optional NOA 605 parameter, ITU-T Q.763 states that the 'nature of address indicator' 606 may contain the following values: 608 0 0 0 0 0 0 0 spare 609 0 0 0 0 0 0 1 subscriber number (national use) 610 0 0 0 0 0 1 0 unknown (national use) 611 0 0 0 0 0 1 1 national (significant) number (national use) 612 0 0 0 0 1 0 0 international number 614 0 0 0 0 1 1 0 615 to 616 1 1 0 1 1 1 1 spare 618 1 1 1 0 0 0 0 619 to 620 1 1 1 1 1 1 0 reserved for national use 622 1 1 1 1 1 1 1 spare 624 Note that the values shown in the table here are in binary notation 625 per ITU-T Q.763. However, when the values are passed in the NOA 626 parameter of P-Charge-Info they are represented in decimal notation. 628 As examples of values in the "reserved for national use" block, the 629 following values have been defined by ANSI for North American use: 631 113 subscriber number, operator requested 632 114 national number, operator requested 633 115 international number, operator requested 634 116 no number present, operator requested 635 117 950+ call from local exchange carrier public station, 636 hotel/motel, or non-exchange access end office 637 118 test line test code 639 14. References 641 14.1. Normative References 643 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 644 for the Session Initiation Protocol (SIP) and the Real- 645 time Applications and Infrastructure Area", BCP 67, 646 RFC 5727, March 2010. 648 14.2. Informative References 650 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 651 Extensions to the Session Initiation Protocol (SIP) for 652 Asserted Identity within Trusted Networks", RFC 3325, 653 November 2002. 655 [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private 656 Header (P-Header) Extensions to the Session Initiation 657 Protocol (SIP) for the 3rd-Generation Partnership Project 658 (3GPP)", RFC 3455, January 2003. 660 [RFC3603] Marshall, W. and F. Andreasen, "Private Session Initiation 661 Protocol (SIP) Proxy-to-Proxy Extensions for Supporting 662 the PacketCable Distributed Call Signaling Architecture", 663 RFC 3603, October 2003. 665 Authors' Addresses 667 Dan York 668 Voxeo Corporation 669 Keene, NH 670 USA 672 Phone: +1-407-455-5859 673 Email: dyork@voxeo.com 674 URI: http://www.voxeo.com/ 676 Tolga Asveren 677 Sonus Networks 678 3 Paragon Way 679 Freehold, NJ 07728 680 USA 682 Email: tasveren@sonusnet.com