idnits 2.17.1 draft-york-p-charge-info-07.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 date (April 19, 2018) is 2198 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. York 3 Internet-Draft Individual 4 Intended status: Informational T. Asveren 5 Expires: October 21, 2018 Ribbon Communications 6 April 19, 2018 8 P-Charge-Info - A Private Header Field (P-Header) Extension to the 9 Session Initiation Protocol (SIP) 10 draft-york-p-charge-info-07 12 Abstract 14 This text documents the current usage of P-Charge-Info, an existing 15 private Session Initiation Protocol (SIP) header field (P-Header) 16 used to convey billing information about the party to be charged. 17 This P-Header is currently used in production by several equipment 18 vendors and carriers and has been in usage since at least 2007. This 19 document is submitted to request the registration of this header 20 field with the Internet Assigned Numbers Authority (IANA). 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 October 21, 2018. 39 Copyright Notice 41 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Purpose of this Document . . . . . . . . . . . . . . . . . . 3 59 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Alternatives . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. P-Charging-Vector . . . . . . . . . . . . . . . . . . . . 4 62 5.2. P-DCS-Billing-Info . . . . . . . . . . . . . . . . . . . 4 63 5.3. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 5 64 6. The P-Charge-Info Header . . . . . . . . . . . . . . . . . . 6 65 6.1. Applicability Statement for the P-Charge-Info header 66 field . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6.2. Usage of the P-Charge-Info header field . . . . . . . . . 6 68 6.2.1. Procedures at the UA . . . . . . . . . . . . . . . . 6 69 6.2.2. Procedures at the Proxy . . . . . . . . . . . . . . . 7 70 6.3. Example of Usage . . . . . . . . . . . . . . . . . . . . 7 71 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 8 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9.1. Trust Relationship . . . . . . . . . . . . . . . . . . . 8 76 9.2. Untrusted Peers . . . . . . . . . . . . . . . . . . . . . 9 77 9.2.1. Ingress from Untrusted Peers . . . . . . . . . 9 78 9.2.2. Egress to Untrusted Peers . . . . . . . . . . 9 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 80 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 12.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Overview 88 In certain network configurations, several network entities have 89 found it useful to decouple the identity of the caller (what is 90 normally thought of as "Caller ID") from the identity/number used for 91 billing purposes. This document records the current usage of P- 92 Charge-Info, a private SIP header field, to provide simple billing 93 information and requests the registration of this header field with 94 IANA as required by Section 4 of [RFC5727]. 96 In a typical configuration, the identity of the caller, commonly 97 referred to as "Caller ID" by end users, is derived from one of the 98 following SIP header fields: 100 o P-Asserted-Identity 102 o From (in the absence of P-Asserted-Identity) 104 (NOTE: Some service providers have also used the Remote-Party-ID 105 header field but this was never standardized and was replaced by P- 106 Asserted-Identity in [RFC3325].) 108 This identity/number is typically presented to the receiving user 109 agent (UA) where it is usually displayed for the end user. It is 110 also typically used for billing purposes by the network entities 111 involved in carrying the session. 113 However, in some network configurations the "Caller ID" presented to 114 the receiving UA may be different from the number to be used for 115 billing purposes. 117 In this case, there exists a need for a way to pass an additional 118 billing identifier that can be used between network entities in order 119 to correctly bill for services. 121 Several carriers, application providers, and equipment providers have 122 been using the P-Charge-Info header field since at least 2007 as a 123 simple mechanism to exchange this billing identifier. 125 2. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. Purpose of this Document 135 This document has been prepared to document the existing deployed 136 usage of the P-Charge-Info header field and to comply with Section 4 137 of [RFC5727] to register this header field with IANA. It is noted 138 that RFC 5727 specifically deprecates new usage of "P-" header 139 fields, but P-Charge-Info has been in deployment since prior to 2007 140 and pre-dates RFC 5727. Given this, the authors request that P- 141 Charge-Info be admitted as a "grandfathered case" per Section 4 of 142 RFC 5727. 144 4. Use Cases 146 The simplest use case for P-Charge-Info is an enterprise environment 147 where each SIP endpoint has a direct number that is passed by the 148 enterprise SIP proxy across to a SIP proxy at a SIP service provider 149 who provides connectivity to the Public Switched Telephone Network 150 (PSTN). Rather than cause the SIP service provider to have to track 151 each individual direct number for billing purposes, the enterprise 152 SIP proxy sends in the P-Charge-Info header field a single billing 153 identifier that the SIP service provider uses for billing purposes. 155 As another example, a hosted telephony provider or hosted voice 156 application provider may have a large SIP network with customers 157 distributed over a very large geographic area using local market PSTN 158 numbers but with only a very few actual PSTN interconnection points. 160 The customers may all have local phone numbers yet outgoing calls are 161 actually routed across a SIP network and out specific PSTN gateways 162 or across specific SIP connections to other SIP service providers. 163 The hosted provider may want to pass a billing identifier to its SIP 164 service providers either for the purpose of simplicity in billing or 165 to obtain better rates from the SIP service providers. 167 5. Alternatives 169 5.1. P-Charging-Vector 171 P-Charging-Vector is defined in Section 4.6 of [RFC7315] and used by 172 the 3GPP to carry information related to the charging of a session. 173 There are, however, some differences in the semantics associated with 174 P-Charging-Vector and P-Charge-Info. P-Charging-Vector is mainly 175 used to carry information for correlation of multiple charging 176 records generated for a single session. On the other hand, P-Charge- 177 Info is used to convey information about the party to be billed for a 178 call. Furthermore, P-Charging-Vector has a mandatory icid-value 179 parameter that is a globally unique value to identify the session for 180 which the charging information is generated. Such a globally-unique 181 identifier is not necessary when carrying information about the user 182 to be billed when it is attached to the corresponding session-related 183 signaling. 185 5.2. P-DCS-Billing-Info 187 P-DCS-Billing-Info is defined in Section 7 of [RFC5503] and used for 188 passing billing information between trusted entities in the 189 PacketCable Distributed Call Signaling Architecture. For many 190 billing situations, particularly the very large-scale residential 191 telephone networks for which this header field is designed, P-DCS- 192 Billing-Info is an excellent solution. However, this ability to 193 address a range of situations adds complexity. According to RFC 194 5503, the following information is mandatory to include in each use 195 of the P-DCS-Billing-Info header field: 197 o Billing-Correlation-ID, a globally unique identifier 199 o Financial-Entity-ID 201 o RKS-Group-ID (record keeping server) 203 and may include a variety of additional parameters. 205 While this may work well in many billing scenarios, there are other 206 billing scenarios that do not need this level of complexity. In 207 those simpler scenarios all that is needed is simply a number to use 208 for billing. P-Charge-Info provides this simple solution for simple 209 billing scenarios. 211 Additionally, according to Section 7.3 of RFC 5503, it is mandatory 212 for a UA to create a Billing-Correlation-ID and insert this into the 213 P-DCS-Billing-Info header field (along with the other required 214 information) sent in the initial SIP INVITE. This again makes sense 215 for the residential telephone service environment for which this 216 header field is designed. In contrast, P-Charge-Info is designed to 217 be used among proxies and not to be used at all by normal user 218 agents. (P-Charge-Info may, though, be used by user agents 219 associated with PSTN gateways.) 221 5.3. P-Asserted-Identity 223 Early reviewers of this document asked why the P-Asserted-Identity 224 header field documented in [RFC3325] could not be used. As mentioned 225 in the use case example above, P-Asserted-Identity is used to 226 indicate the identity of the calling party. However, in this 227 instance, the requirement is to provide an additional identity of the 228 SIP-to-PSTN interconnect point. 230 It would be typical to find both P-Asserted-Identity and P-Charge- 231 Info used in a SIP exchange. P-Asserted-Identity would be used to 232 provide the caller identity which would be displayed to the end user 233 as "Caller ID" while P-Charge-Info would provide the billing 234 identifier used for the billing associated with the call. 236 6. The P-Charge-Info Header 238 6.1. Applicability Statement for the P-Charge-Info header field 240 The P-Charge-Info header field is applicable within a single private 241 administrative domain or between different administrative domains 242 where there is a trust relationship between the domains. 244 6.2. Usage of the P-Charge-Info header field 246 The P-Charge-Info header field is used to convey information about 247 the identity of the party to be charged. The P-Charge-Info header 248 field is typically inserted into a SIP request, usually an INVITE, by 249 one of the following: 251 o the SIP proxy on the originating network; 253 o a PSTN gateway acting as a SIP UA; or 255 o an application server generating billing information. 257 P-Charge-Info is to be used by the SIP entity that provides billing 258 services for a session. This could be an entity generating billing 259 records or an entity interacting with another enitity generating 260 billing records. Upon receipt of an INVITE request with the P- 261 Charge-Info header field, such an entity SHOULD use the value present 262 in P-Charge-Info as indicating the party responsible for the charges 263 associated with the session. 265 6.2.1. Procedures at the UA 267 The P-Charge-Info header field may be inserted by PSTN gateways or 268 application servers acting as a SIP UA. 270 The P-Charge-Info header field is ignored by an end-user UA and 271 should not normally be received by such a UA. It MUST NOT be sent to 272 such a UA and the UA SHOULD ignore it if it receives the header 273 field. Similarly, an end-user UA originating a SIP message SHOULD 274 NOT insert this header field. 276 A PSTN gateway or application server acting as a UA MAY use the 277 content of the P-Charge-Info header field present in an INVITE 278 request it received for billing related procedures, e.g. in a billing 279 record or during interaction with another entity generating billing 280 records, as the identity of the party to be charged for the session. 281 A PSTN gateway or application server acting as a UA MAY use the 282 content of the P-Charge-Info header field to populate information 283 about the identity of the party to charge in another type of 284 signaling, e.g. ISUP. 286 6.2.2. Procedures at the Proxy 288 A SIP proxy that supports this extension and receives a request, 289 typically a SIP INVITE, without the P-Charge-Info header field MAY 290 insert a P-Charge-Info header field. The contents of the inserted 291 header field may be decided based on local policy or by querying an 292 external entity to determine the identity of the party to be charged. 294 A proxy MAY use the content of the P-Charge-Info header field present 295 in an INVITE request it received for billing related procedures, e.g. 296 in a billing record or during interaction with another entity 297 generating billing records. 299 A SIP proxy that does not support this extension will pass any 300 received P-Charge-Info header field unmodified in compliance with RFC 301 3261. 303 A proxy supporting this extension SHOULD remove the P-Charge-Info 304 header field before sending a request to a UA that is not acting as a 305 PSTN gateway or appropriate application server. 307 6.3. Example of Usage 309 The content of the P-Charge-Info header field is typically just a SIP 310 URI used as a billing indicator. An example could be as simple as 311 one of: 313 P-Charge-Info: 315 P-Charge-Info: 317 P-Charge-Info: 319 P-Charge-Info: 321 Any other applicable SIP URI could be used. 323 7. Formal Syntax 325 This RFC contains the definition of one or more SIP header fields 326 that allow choosing between addr-spec and name-addr when constructing 327 header field values. As specified in [RFC8217], the "addr-spec" form 328 MUST NOT be used if its value would contain a comma, semicolon, or 329 question mark. 331 The Private Header Field specified in this document is described in 332 both prose and an augmented Backus-Naur Form (BNF) defined in 333 [RFC5234]. Further, several BNF definitions are inherited from SIP 334 and are not repeated here. Implementors need to be familiar with the 335 notation and contents of [RFC3261] and [RFC5234] to understand this 336 document. 338 The syntax of the P-Charge-Info header field is described as follows: 340 P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec) 341 ; name-addr and addr-spec are specified in RFC 3261 343 The SIP URI contained in the name-addr/addr-spec is the billing 344 indicator that is passed between the parties. 346 8. IANA Considerations 348 This specification registers a new proprietary SIP header field 349 according to the procedures defined in [RFC5727]. 351 8.1. Header Field 353 The header field described in Section 7 is registered in the "Header 354 Fields" sub-registry of the "Session Initiation Protocol (SIP) 355 Parameters" registry by adding a row with these values: 357 Header Field Name: P-Charge-Info 359 Compact Form: none 361 Reference: [TBD: This document] 363 9. Security Considerations 365 9.1. Trust Relationship 367 Given that the information contained in the P-Charge-Info header 368 field will be used for billing purposes, the proxies and other SIP 369 entities that share this information MUST have a trust relationship. 371 If an untrusted entity were inserted between the trusted entities, it 372 could potentially interfere with the billing records for the call. 373 If the SIP connections are not made over a private network, a 374 mechanism for securing the confidentiality and integrity of the SIP 375 connection SHOULD be used to protect the information. One such 376 mechanism could be TLS-encryption of the SIP signaling stream. 378 9.2. Untrusted Peers 380 9.2.1. Ingress from Untrusted Peers 382 If the P-Charge-Info header field was accepted by a SIP entity from 383 an untrusted peer, there is the potential for fraud if the untrusted 384 entity sent incorrect information, either inadvertently or 385 maliciously. 387 Therefore a SIP entity MUST remove and ignore the P-Charge-Info 388 header field when it is received from an untrusted entity. 390 9.2.2. Egress to Untrusted Peers 392 If the P-Charge-Info header field was sent by a SIP entity to an 393 untrusted peer, there is the potential exposure of network 394 information that is internal to a trust domain. For instance, the 395 untrusted entity may learn the identities of public SIP proxies used 396 within the trust domain which could then potentially be directly 397 attacked. 399 If an implementation does not strip P-Charge-Info from the message 400 where specified in this document, it introduces serious privacy 401 risks. Examples include revealing third-party billing relationships 402 that might be sensitive, as well as unmasking the identity of callers 403 who wish to remain anonymous. Depending on circumstances, the latter 404 case may result in unwanted harassment and even physical harm to the 405 calling party. 407 Therefore a SIP entity MUST remove the P-Charge-Info header field 408 when it is sent to an untrusted entity. 410 10. Acknowledgements 412 The authors thank the following people for their comments: Keith 413 Drage, Miguel Garcia, Sumit Garg, John Haluska, Juha Heinanen, 414 Christer Holmberg, Paul Kyzivat, Adam Roach, Jonathan Rosenberg, 415 Henning Schulzrinne, Tom Taylor and Glen Wang. 417 11. Changes 419 NOTE TO RFC EDITOR - Please remove this "Changes" section prior to 420 publication. Thank you. 422 Revision -07 incorporates significant feedback from Jean Mahoney 423 including: 425 o Updating references to obsolete RFCs; 426 o Updating IANA considerations section; 428 o Changing example phone numbers; and 430 o multiple editorial and proofreading updates. 432 Revision -06 fixes one nit and updates the Requirements Language to 433 comply with BCP 14 / RFC 8174. 435 Revision -05 fixed a few typos and had other editorial changes. 437 Revision -04 removes the PASSporT and RFC 8224/8225 references 438 (inserted in Revision -03), as it was decided to capture that usage 439 in a separate draft. 441 Revision -03 incorporates feedback from the expert review by Adam 442 Roach, including: 444 o changing all references to "header" to be "header field"; 446 o the addition of references to RFCs 8224 and 8225 related to STIR; 448 o a reference to RFC 8217 in the formal syntax; and 450 o multiple editorial and proofreading updates. 452 Revision -02 incorporates a range of feedback provided by Henning 453 Schulzrinne. 455 Revision -01 is a refresh as -00 expired. The affiliation of Tolga 456 Asveren was changed to Ribbon Communications. 458 Revision -00 strips out the NPI and NOA parameters to focus only on 459 the usage in a pure SIP-to-SIP environment. Multiple editing changes 460 were made for readability. 462 NAME CHANGE - The document is now "draft-york-p-charge-info" to 463 reflect the fact that the publishing route for the draft is being 464 determined. 466 Revision -06 updates the text for 2017 and changes Dan York's 467 affiliation to "Individual". 469 Revision -05 is a refresh as -04 expired. Several small tweaks were 470 also made to narrative text. 472 Revision -04 is purely a refresh as -03 expired. 474 Revision -03 is purely a refresh as -02 expired. 476 Revision -02 is purely a refresh as -01 expired. My hope is to move 477 this document forward soon to put closure on it. 479 Revision -01 is purely a refresh as -00 expired. Only a few minor 480 tweaks to this "Changes" section of the document. 482 Revision -00 is the initial release of "draft-york-dispatch-p-charge- 483 info" and is identical to "draft-york-sipping-p-charge-info-15" 484 except for changes to wording to reflect the change to the DISPATCH 485 working group. The "organization" name for Dan York was also changed 486 from blank to "DisTel Research" to remove the confusion that it 487 looked like he was also employed by Sonus Networks. 489 NAME CHANGE - The document is now "draft-york-dispatch-p-charge-info" 490 to reflect the fact that the SIPPING Working Group no longer exists. 492 Revision -15 simply fixes a wording error in the abstract in the 493 previous revision. This will also be the last version of 'draft- 494 york-sipping-p-charge-info'. The next version will be 'draft-york- 495 dispatch-p-charge-info'. 497 Revision -14 incorporates the following changes: 499 o Two examples were updated to include a "+1" at the beginning of 500 the SIP URI. 502 o An example was changed to use "example.net" to be compliant with 503 RFC 2606. 505 o Dan York's organization was updated to "Individual" (from empty) 506 to indicate that his involvement with this draft is purely as an 507 individual with no connection to his employer. 509 o The length of time the header has been used in the Introduction 510 was changed to 7 years, to reflect the first usage around 2005. 512 o A note was added to the abstract indicating that this is expected 513 to be the last version using the name 'draft-york-sipping-p- 514 charge-info'. 516 o Informative references were added to RFC 3261 and RFC 2234 to 517 address missing references in the text. 519 o Numerous other tweaks to the text for readability. 521 Revision -13 has no changes to content and was issued as -12 expired. 522 Discussions are under way coming out of IETF 83 on a plan to move 523 this draft forward. As the SIPPING working group no longer exists, 524 the draft name needs to change and there are a couple of other 525 required changes. 527 Revision -12 included the following modifications based on feedback 528 from John Haluska and Glen Wang: 530 o Modification of Appendix B to reflect ANSI T1.113 values. 532 Revision -11 represents a fairly significant revision responding to a 533 solid review by Paul Kyzivat and providing additional explanation. A 534 major shift was the move to using decimal values for the npi-value 535 parameter versus the text values of previous drafts. Changes 536 include: 538 o ABNF definition updated to indicate that npi is now a number vs 539 text. 541 o The "npi" and "noa" acronyms were expanded and stated near the 542 formal syntax definition. 544 o New section created explicitly mentioning the optional parameters. 546 o Example of optional parameters updated to have npi use a number vs 547 text. 549 o Appendix B added to give examples of NOA parameter. 551 o Overview text updated to indicate that P-Charge-Info was been in 552 use now for over 5 years (given that the draft has been in 553 development for 3 years). 555 o Several small fixes for readability. 557 Revision -10 included the following modifications: 559 o Formal ABNF definition updated. 561 o In formal syntax, semicolons added to npi-param and noa-param 562 definitions. 564 o npi-param changed to a 'gen-value' to use digits vs text. Values 565 npi-param are shown in Appendix A. 567 o Corrected example to show proper use of parameters. 569 o Updated references to RFC 3427 and RFC 3968 to reference RFC 5727. 571 Revision -09 included the following modifications: 573 o Re-submitted with only a date change. Discussions are ongoing to 574 finalize this draft and submit it for expert review. 576 Revision -08 included the following modifications: 578 o The ABNF for the "npi-value" was modified to conform to the 579 sequence of possible values stated in ANSI T1.113. 581 o An Appendix A was created listing the values from ANSI T1.113. 583 Revision -07 was updated to the "trust200902" IPR statement and added 584 references to RFC 3968. At this point all comments have been 585 incorporated and publication will be requested. 587 Revision -06 had only a minor correction to the second usage example. 588 The IPR statement was also updated to comply with RFC 5378. 590 Revision -05 included the following modifications: 592 o The usage of P-Charge-Info for carrying the ISUP Charge Number 593 parameter was formally incorporated into the draft. Previous 594 revisions had mentioned it as a possible use case but had not 595 really explicitly included it. 597 o The examples/use cases section was expanded to include further 598 examples of where P-Charge-Info may be used. 600 o The original use case which discussed inter/intra-state billing 601 practices was changed as the geographical references were clouding 602 the more fundamental issue. 604 o The "UNKNOWN" value was added to the ABNF for the "npi-value" 605 parameter as that was identified as missing but required for ISUP 606 interworking. 608 o The optional "Nature of Address" parameter was added to support 609 interworking with the ISUP Charge Number. 611 Revision -04 corrected a major error in the example where the 612 parameter was placed inside the angle brackets. The P-DCS-Billing- 613 Info header was also added as an alternative and a few minor edits 614 were made. 616 12. References 618 12.1. Normative References 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 622 RFC2119, March 1997, 623 . 625 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 626 for the Session Initiation Protocol (SIP) and the Real- 627 time Applications and Infrastructure Area", BCP 67, RFC 628 5727, March 2010. 630 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 631 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 632 May 2017, . 634 12.2. Informative References 636 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 637 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 638 RFC5234, January 2008, . 641 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 642 A., Peterson, J., Sparks, R., Handley, M., and E. 643 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 644 June 2002. 646 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 647 Extensions to the Session Initiation Protocol (SIP) for 648 Asserted Identity within Trusted Networks", RFC 3325, 649 November 2002. 651 [RFC5503] Andreasen, F., McKibben, B., and B. Marshall, "Private 652 Session Initiation Protocol (SIP) Proxy-to-Proxy 653 Extensions for Supporting the PacketCable Distributed Call 654 Signaling Architecture", RFC 5503, DOI 10.17487/RFC5503, 655 March 2009, . 657 [RFC7315] Jesske, R., Drage, K., and C. Holmberg, "Private Header 658 (P-Header) Extensions to the Session Initiation Protocol 659 (SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July 660 2014, . 662 [RFC8217] Sparks, R., "Clarifications for When to Use the name-addr 663 Production in SIP Messages", RFC 8217, DOI 10.17487/ 664 RFC8217, August 2017, . 667 Authors' Addresses 669 Dan York 670 Individual 671 Keene, NH 672 USA 674 Email: dyork@lodestar2.com 676 Tolga Asveren 677 Ribbon Communications 678 NJ 679 USA 681 Email: tasveren@rbbn.com