idnits 2.17.1 draft-andreasen-sipping-rfc3603bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1510. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3261]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC3603, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 4, 2008) is 5651 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCxxxx' is mentioned on line 1324, but not defined ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 4330 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 3603 (Obsoleted by RFC 5503) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING F. Andreasen 3 Internet-Draft Cisco 4 Obsoletes: 3603 (if approved) B. McKibben 5 Intended status: Informational CableLabs 6 Expires: May 8, 2009 B. Marshall 7 AT&T 8 November 4, 2008 10 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for 11 Supporting the PacketCable Distributed Call Signaling Architecture 12 draft-andreasen-sipping-rfc3603bis-06 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of 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 May 8, 2009. 39 Abstract 41 In order to deploy a residential telephone service at very large 42 scale across different domains, it is necessary for trusted elements 43 owned by different service providers to exchange trusted information 44 that conveys customer-specific information and expectations about the 45 parties involved in the call. This document describes private 46 extensions to the Session Initiation Protocol (SIP) [RFC3261] for 47 supporting the exchange of customer information and billing 48 information between trusted entities in the PacketCable Distributed 49 Call Signaling Architecture. These extensions provide mechanisms for 50 access network coordination to prevent theft of service, customer 51 originated trace of harassing calls, support for operator services 52 and emergency services, and support for various other regulatory 53 issues. The use of the extensions is only applicable within closed 54 administrative domains, or among federations of administrative 55 domains with previously agreed-upon policies where coordination of 56 charging and other functions is required. 58 Table of Contents 60 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4. Conventions used in this document . . . . . . . . . . . . . . 9 64 5. P-DCS-TRACE-PARTY-ID . . . . . . . . . . . . . . . . . . . . . 10 65 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.2. Procedures at an Untrusted User Agent Client (UAC) . . . . 11 67 5.3. Procedures at a Trusted User Agent Client (UAC) . . . . . 12 68 5.4. Procedures at an Untrusted User Agent Server (UAS) . . . . 12 69 5.5. Procedures at a Trusted User Agent Server (UAS) . . . . . 12 70 5.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . . 12 71 5.6.1. Procedures at Originating Proxy . . . . . . . . . . . 12 72 5.6.2. Procedures at Terminating Proxy . . . . . . . . . . . 13 73 6. P-DCS-OSPS . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 6.2. Procedures at an Untrusted User Agent Client (UAC) . . . . 15 76 6.3. Procedures at a Trusted User Agent Client (UAC) . . . . . 15 77 6.4. Procedures at an Untrusted User Agent Server (UAS) . . . . 15 78 6.5. Procedures at a Trusted User Agent Server (UAS) . . . . . 16 79 6.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . . 16 80 7. P-DCS-BILLING-INFO . . . . . . . . . . . . . . . . . . . . . . 17 81 7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 7.2. Procedures at an Untrusted User Agent Client (UAC) . . . . 20 83 7.3. Procedures at a Trusted User Agent Client (UAC) . . . . . 21 84 7.4. Procedures at an Untrusted User Agent Server (UAS) . . . . 21 85 7.5. Procedures at a Trusted User Agent Server (UAS) . . . . . 21 86 7.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . . 22 87 7.6.1. Procedures at Originating Proxy . . . . . . . . . . . 22 88 7.6.2. Procedures at Terminating Proxy . . . . . . . . . . . 23 89 7.6.3. Procedures at Tandem Proxy . . . . . . . . . . . . . . 24 90 8. P-DCS-LAES and P-DCS-Redirect . . . . . . . . . . . . . . . . 25 91 8.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 8.2. Procedures at an Untrusted User Agent Client (UAC) . . . . 27 93 8.3. Procedures at a Trusted User Agent Client (UAC) . . . . . 27 94 8.4. Procedures at an Untrusted User Agent Server (UAS) . . . . 28 95 8.5. Procedures at a Trusted User Agent Server (UAS) . . . . . 28 96 8.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . . 29 97 8.6.1. Procedures at Originating Proxy . . . . . . . . . . . 29 98 8.6.2. Procedures at Terminating Proxy . . . . . . . . . . . 31 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 101 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 36 102 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 104 13.1. Normative References . . . . . . . . . . . . . . . . . . . 38 105 13.2. Informative References . . . . . . . . . . . . . . . . . . 38 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 108 Intellectual Property and Copyright Statements . . . . . . . . . . 41 110 1. Applicability Statement 112 The SIP extensions described in this document make certain 113 assumptions regarding network topology, linkage between SIP and lower 114 layers, and the availability of transitive trust. These assumptions 115 are generally not applicable in the Internet as a whole. The use of 116 these headers is only applicable within closed administrative 117 domains, or among federations of administrative domains with 118 previously agreed-upon policies where coordination of charging and 119 other functions is required, as in for example the architecture 120 presented in [DCSARCH]. Use outside such a domain could result in 121 the leakage of potentially sensitive or private information. User 122 consent to the privacy implications of the policies in [DCSARCH] is 123 strongly encouraged in those domains as well. 125 Although [RFC2119] language is used in this document, the scope of 126 the normative language is only for the area of applicability of the 127 document and, like the technology, it does not apply to the general 128 Internet. 130 2. Introduction 132 In order to deploy a SIP-based [RFC3261] residential telephone 133 service at very large scale across different domains, it is necessary 134 for trusted elements owned by different service providers to exchange 135 trusted information that conveys billing information and expectations 136 about the parties involved in the call. 138 There are many billing models used in deriving revenue from telephony 139 services today. Charging for telephony services is tightly coupled 140 to the use of network resources. It is outside the scope of this 141 document to discuss the details of these numerous and varying 142 methods. 144 A key motivating principle of the DCS architecture described in 145 [DCSARCH] is the need for network service providers to be able to 146 control and monitor network resources; revenue may be derived from 147 the usage of these resources as well as from the delivery of enhanced 148 services such as telephony. Furthermore, the DCS architecture 149 recognizes the need for coordination between call signaling and 150 resource management. This coordination ensures that users are 151 authenticated and authorized before receiving access to network 152 resources and billable enhanced services. 154 DCS Proxies, as defined in [DCSARCH], have access to subscriber 155 information and act as policy decision points and trusted 156 intermediaries along the call signaling path. Edge routers provide 157 the network connectivity and resource policy enforcement mechanism 158 and also capture and report network connectivity and resource usage 159 information. Edge routers need to be given billing information that 160 can be logged with Record Keeping or Billing servers. The DCS Proxy, 161 as a central point of coordination between call signaling and 162 resource management, can provide this information based on the 163 authenticated identity of the calling and called parties. Since 164 there is a trust relationship among DCS Proxies, they can be relied 165 upon to exchange trusted billing information pertaining to the 166 parties involved in a call. See [DCSARCH] for a description of the 167 trust boundary and trusted versus untrusted entities. 169 For these reasons, it is appropriate to consider defining SIP header 170 extensions to allow DCS Proxies to exchange information during call 171 setup. It is the intent that the extensions would only appear on 172 trusted network segments, should be inserted upon entering a trusted 173 network region, and removed before leaving trusted network segments. 175 Significant amounts of information are retrieved by an originating 176 DCS Proxy in its handling of a connection setup request from a user 177 agent. Such information includes location information about the 178 subscriber (essential for emergency services calls), billing 179 information, and station information (e.g., coin operated phone). In 180 addition, while translating the destination number, information such 181 as the local-number-portability office code is obtained and will be 182 needed by all other proxies handling this call. 184 For Usage Accounting records, it is necessary to have an identifier 185 that can be associated with all the event records produced for the 186 call. The SIP Call-ID header field cannot be used as such an 187 identifier since it is selected by the originating user agent, and 188 may not be unique among all past calls as well as current calls. 189 Further, since this identifier is to be used by the service provider, 190 it should be chosen in a manner and in a format that meets the 191 service provider's needs. 193 Billing information may not necessarily be unique for each user 194 (consider the case of calls from an office all billed to the same 195 account). Billing information may not necessarily be identical for 196 all calls made by a single user (consider prepaid calls, credit card 197 calls, collect calls, etc). It is therefore necessary to carry 198 billing information separate from the calling and called party 199 identification. Furthermore, some billing models call for split- 200 charging where multiple entities are billed for portions of the call. 202 The addition of a SIP General Header Field allows for the capture of 203 billing information and billing identification for the duration of 204 the call. 206 It is the intent that the billing extensions would only appear on 207 trusted network segments, and MAY be inserted by a DCS Proxy in 208 INVITE and REFER requests and INVITE responses in a trusted network 209 segment, and removed before leaving trusted network segments. 211 In addition to support for billing, current residential telephone 212 service includes the need for customer originated trace (of harassing 213 or obscene calls), for operator services such as busy line 214 verification and emergency interrupt (initiated by an operator from 215 an Operator Services Position System (OSPS)), for emergency services 216 such as 9-1-1 calls to a Public Service Access Point (PSAP) and the 217 subsequent call handling, and support for Electronic Surveillance and 218 Law Enforcement access as required by applicable legislation and 219 court orders. In all of these cases, additional information about 220 the call and about the subscribers involved in the call needs to be 221 exchanged between the proxies. 223 3. Trust Boundary 225 The DCS architecture [DCSARCH] defines a trust boundary around the 226 various systems and servers that are owned, operated by, and/or 227 controlled by the service provider. These trusted systems include 228 the proxies and various servers such as bridge servers, voicemail 229 servers, announcement servers, etc. Outside of the trust boundary 230 lie the customer premises equipment, and various application and 231 media servers operated by third-party service providers. 233 Certain subscriber-specific information, such as billing and 234 accounting information, stays within the trust boundary. Other 235 subscriber-specific information, such as endpoint identity, may be 236 presented to untrusted endpoints or may be withheld based on 237 subscriber profiles. 239 The User Agent (UA) may be either within the trust boundary or 240 outside the trust boundary, depending on exactly what function is 241 being performed and exactly how it is being performed. Accordingly, 242 the procedures followed by a User Agent are different depending on 243 whether the UA is within the trust boundary or outside the trust 244 boundary. 246 The following sections giving procedures for User Agents therefore 247 are subdivided into trusted user agents and untrusted user agents. 249 4. Conventions used in this document 251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 253 document are to be interpreted as described in BCP 14, [RFC2119]. 255 The term "private-URL" used in this document refers to a SIP URI that 256 is generated by a proxy, contains a "hostport" that identifies the 257 proxy, and contains a "userinfo" string that is generated by the 258 proxy. The "userinfo" typically contains (or points to) information 259 that is not to be disclosed outside the trusted domain of the 260 proxies, such as billing account numbers, electronic surveillance 261 indication, electronic surveillance parameters, and call redirection 262 information. Consequently, the information is either stored locally 263 by the proxy, or encrypted with a private key known only to the proxy 264 and encoded in a character string in the "userinfo" portion of the 265 URL. A checksum is included in the "userinfo" data to detect 266 tampering. The mechanism by which a proxy recognizes a "userinfo" as 267 a private-URL and decodes and recovers the original information is 268 local to the proxy and is not subject to standardization. Some 269 possible implementations include an initial magic cookie (e.g., 270 z9hG4Bk followed by the pointer/information), or use of a reserved 271 "user" name (e.g., "private") with the optional "password" containing 272 the pointer/information. 274 5. P-DCS-TRACE-PARTY-ID 276 In the telephone network, calling identity information is used to 277 support regulatory requirements such as the Customer Originated Trace 278 service, which provide the called party with the ability to report 279 obscene or harassing phone calls to law enforcement. This service is 280 provided independently of caller-id, and works even if the caller 281 requested anonymity. The calling party is here identified as the 282 station originating the call. In order for this service to be 283 dependable, the called party must be able to trust that the calling 284 identity information being presented is valid. One way to achieve 285 this is described in [RFC3325]. 287 To initiate a customer-originated-trace from an untrusted UAC, an 288 additional header is defined for the INVITE request. This header is 289 called P-DCS-Trace-Party-ID, and does not appear in any other request 290 or response. The untrusted UAC also includes the Target-Dialog 291 header field defined in [RFC4538] in the INVITE request in order to 292 explicitly identify the call to be traced. The entity addressed by 293 the Request-URI performs the service-provider-specific functions of 294 recording and reporting the caller identity in the 295 P-DCS-Trace-Party-ID for law enforcement action. It then forwards 296 the call to either an announcement server or to the service- 297 provider's business office to collect further information about the 298 complaint. A trusted UAC does not use this header, as it initiates 299 this action locally. 301 5.1. Syntax 303 The ABNF description of this header is (some terms used in this ABNF 304 are defined in [RFC3261]): 306 P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr 308 The ABNF production for name-addr in [RFC3261] includes uri- 309 parameters, which allows for additional parameters to be defined 310 (other-param). We here define the following other-param parameters 311 to be used with P-DCS-Trace-Party-ID: 313 timestamp-param = "timestamp=" 1*DIGIT ["." 1*DIGIT] 315 This document adds the following entry to Table 2 of [RFC3261]: 317 Header field where proxy ACK BYE CAN INV OPT REG PUB 318 ------------ ----- ----- --- --- --- --- --- --- --- 319 P-DCS-Trace-Party-ID R dmr - - - o - - - 320 SUB NOT REF INF UPD PRA MSG 321 --- --- --- --- --- --- --- 322 - - - - - - - 324 The addr-spec contained in name-addr contains a URL that identifies 325 the remote endpoint. Addr-spec typically contains a tel URL or SIP 326 URI giving the identity of the remote endpoint, as provided in the 327 signaling messages that established the session to be traced. 329 The timestamp-param contains the value of the time the UA determines 330 it received the session initiation request of the call requested to 331 be traced. The timestamp-param is populated using the Network Time 332 Protocol timestamp format defined in RFC 1305 [RFC1305] and used by 333 the Simple Network Time Protocol [RFC4330]. The timestamp SHOULD be 334 encoded in UTF-8 Format per [RFC3629]. 336 An example of the P-DCS-Trace-Party-ID header is shown as follows: 338 P-DCS-Trace-Party-ID: sip:+12345678912@domain.com; user=phone; 339 timestamp=3434688831.2327 341 5.2. Procedures at an Untrusted User Agent Client (UAC) 343 The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial 344 INVITE message for a customer-originated-trace request. The trace 345 request from the Untrusted User Agent Client is able to be initiated 346 during the dialog or after the release of the dialog or call that is 347 requested to be traced. The UAC MUST use a SIP URI in the Request- 348 URI with userinfo set to "call-trace" and hostport identifying the 349 call tracing entity for the untrusted UA. The [RFC3603] version of 350 the P-DCS-Trace-Party-ID did not include the timestamp-param 351 parameter, however the syntax is backwards compatible with [RFC3603]. 352 A UAC compliant to this updated specification MUST insert the 353 timestamp and the Target-Dialog header field defined in [RFC4538] if 354 known to the UAC. 356 In case of an anonymous malicious call, where the remote party is not 357 known to the Untrusted UAC, the Untrusted UAC SHOULD indicate the 358 user as anonymous in the P-DCS-Trace-Party-ID, for example, as 359 follows: sip:anonymous@anonymous.invalid. 361 5.3. Procedures at a Trusted User Agent Client (UAC) 363 A trusted UAC performs the customer-originated-trace in a manner 364 similar to the trusted UAS, described below. A trusted UAC MUST NOT 365 include this header in any request. 367 5.4. Procedures at an Untrusted User Agent Server (UAS) 369 This header MUST NOT appear in any response sent by a UAS. 371 5.5. Procedures at a Trusted User Agent Server (UAS) 373 If the P-DCS-Trace-Party-ID header is present in the initial INVITE 374 request from a UAC, and the Request-URI of the INVITE has userinfo 375 set to "call-trace" and hostport set to the UAS, the UAS MUST perform 376 the service-provider-specific functions of recording and reporting 377 the caller identity and associated trace parameters (if any) from the 378 Target-Dialog header field for law enforcement action. The UAS then 379 MUST redirect the call, via a 3xx response, to either an announcement 380 server or to the service-provider's business office to collect 381 further information about the complaint. 383 This header MUST NOT appear in any response sent by a UAS. 385 If the P-DCS-Trace-Party-ID header is not present in the initial 386 INVITE request from a UAC, and the Request-URI of the INVITE has 387 userinfo set to "call-trace" the UAS MUST reject the request. 389 5.6. Procedures at Proxy 391 Two sets of proxy procedures are defined: (1) the procedures at an 392 originating proxy, and (2) the procedures at a terminating proxy. 393 The originating proxy is a proxy that received the INVITE request 394 from a non-trusted endpoint. 396 The terminating proxy is a proxy that sends the INVITE request to a 397 non-trusted endpoint. 399 A proxy that both receives the INVITE request from an untrusted 400 endpoint, and sends the INVITE request to an untrusted endpoint, 401 performs both sets of procedures. 403 5.6.1. Procedures at Originating Proxy 405 If the P-DCS-Trace-Party-ID header is present in the initial INVITE 406 request from the UAC, and the Request-URI of the INVITE has userinfo 407 other than "call-trace" and hostport set to other than a potentially 408 provisioned call tracing entity, then the Proxy MAY reject the 409 request, or MAY remove the P-DCS-Trace-Party-ID header from the 410 request. If the header is present in a valid request, and contains a 411 private-URL that identifies the Proxy in the hostport, then the 412 Originating Proxy SHOULD replace the private-URL with its original 413 contents (i.e., the verified identity of the caller of the session 414 that is being traced and trace parameters from the Target-Dialog 415 header fields defined in [RFC4538]). 417 The proxy records the caller URL and target dialog IDs on sessions 418 directed toward the untrusted UAC if provisioned to do so by the 419 network operator. If the is P-DCS-Trace-Party-ID header is present 420 in a valid request, and contains an anonymous caller indication in 421 the name-addr parameter, the Originating Proxy MUST replace the 422 anonymous URL with the verified identify of the caller of the session 423 that is being traced if available and recorded by the proxy. 424 Otherwise, the proxy does not replace the anonymous URL. 426 If the origination proxy is provisioned to store URLs and target 427 dialog IDs for incoming calls, and if the proxy detects that the URL 428 and Target Dialog in a trace request does not match a recorded 429 incoming dialog request, then the proxy MUST reject the trace call 430 request. 432 The origination proxy does not add the P-DCS-Trace-Party-ID header 433 from a request that does not already contain the header. 435 5.6.2. Procedures at Terminating Proxy 437 This header MUST NOT appear in any request or response sent by a 438 terminating proxy to an untrusted endpoint. 440 6. P-DCS-OSPS 442 Some calls have special call processing requirements that may not be 443 satisfied by normal user agent call processing. For example, when a 444 user is engaged in a call and another call arrives, such a call might 445 be rejected with a busy indication. However, some PSTN operator 446 services require special call processing. In particular, the Busy 447 Line Verification (BLV) and Emergency Interrupt (EI) services 448 initiated by an operator from an Operator Services Position System 449 (OSPS) on the PSTN network have such a need. Similarly, emergency 450 calls to a 9-1-1 Public Service Access Point (PSAP) may result in 451 trunk signaling causing operator ringback using a howling tone or 452 sustained ring on the originating line (country-specific variations 453 may exist). 455 In order to inform the SIP user agent that special treatment should 456 be given to a call, we use a new P-DCS-OSPS header, with a field 457 which may be set to a value indicating when a special type of call 458 processing is requested. We define three values in this header 459 field, namely "BLV" for busy line verification, "EI" for emergency 460 interrupt, and "RING" for operator ringback (e.g., howling/sustained 461 tone ring in the US). 463 If the user agent decides to honor such a request, the response of 464 the user agent to an INVITE with either "BLV" or "EI" will not be a 465 busy indication. Since "EI" and "RING" only occur on established 466 dialogs, they may also appear in UPDATE requests. 468 6.1. Syntax 470 The ABNF description of the P-DCS-OSPS header is as follows (some 471 terms used in this ABNF are defined in [RFC3261]): 473 P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag 474 OSPS-Tag = "BLV" / "EI" / "RING" / token 476 This document adds the following entry to Table 2 of [RFC3261]: 478 Header field where proxy ACK BYE CAN INV OPT REG PUB 479 ------------ ----- ----- --- --- --- --- --- --- --- 480 P-DCS-OSPS R dr - - - o - - - 481 SUB NOT REF INF UPD PRA MSG 482 --- --- --- --- --- --- --- 483 - - - - o - - 485 The OSPS-Tag value of "token" is defined for extensibility, and is 486 reserved for future use. 488 6.2. Procedures at an Untrusted User Agent Client (UAC) 490 The P-DCS-OSPS header MUST NOT be sent in a request from an untrusted 491 UAC. 493 6.3. Procedures at a Trusted User Agent Client (UAC) 495 This header is typically only inserted by a Media Gateway Controller 496 [DCSARCH] that is controlling a Media Gateway with special trunks to 497 a PSTN OSPS system or PSAP. This trunk group is usually referred to 498 as a BLV-trunk group and employs special signaling procedures that 499 prevent inadvertent use. Calls originating at the PSTN OSPS system 500 are sent over this trunk group, and result in an INVITE request with 501 the P-DCS-OSPS header. 503 This header MAY be sent in an INVITE request, and MUST NOT appear in 504 any message other than those listed below. 506 OSPS-Tag value "BLV" MUST NOT appear in any request other than an 507 initial INVITE request establishing a new dialog. 509 OSPS-Tag value "EI" MUST NOT appear in any request or response other 510 than (1) a subsequent INVITE within a pre-existing dialog established 511 with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a 512 pre-existing dialog established with the OSPS-Tag value of "BLV". 514 OSPS-Tag value "RING" MUST NOT appear in any request or response 515 other than (1) a subsequent INVITE within a pre-existing dialog 516 established by a UAC to an operator or PSAP, or (2) an UPDATE request 517 within a pre-existing dialog established by a UAC to an operator or 518 PSAP. 520 6.4. Procedures at an Untrusted User Agent Server (UAS) 522 If the UAS receives an INVITE request with an OSPS-Tag of "BLV", 523 dialog identification that matches an existing dialog, it MUST reject 524 the request with a 403-Forbidden error code. 526 If the UAS receives an INVITE/UPDATE request with an OSPS-Tag value 527 of "EI" or "RING", with dialog identification that does not match an 528 existing dialog which was established with the OSPS-Tag value of 529 "BLV", it MUST reject the request with a 403-Forbidden response code. 531 If the UAS receives an INVITE that contains an OSPS-Tag value of 532 "BLV" and is not willing to cooperate in offering this service, it 533 MUST reject the request with a 403-Forbidden response code. 535 The UAS SHOULD NOT reject an INVITE with a BLV OSPS-Tag due to a busy 536 condition. The UAS MUST NOT respond with a 3xx-Redirect response 537 code to an INVITE with a BLV OSPS-Tag. The UAS SHOULD NOT alert the 538 user of the incoming call attempt if the BLV OSPS-Tag is present in 539 the INVITE. 541 If an INVITE with OSPS-Tag of "BLV" is accepted (e.g., meeting all 542 QoS pre-conditions, etc.), the UAS MUST send an audio stream on this 543 connection to the address and port given in the SDP of the INVITE. 544 The UAS MAY perform a mixing operation between the two ends of an 545 existing active call and send the resulting media stream to the 546 address and port indicated. Alternatively, the UAS MAY send a copy 547 of the local voice stream, and (if no activity on the local voice 548 stream) send a copy of the received voice stream of an existing call. 549 If the state of the UAS is idle, the UAS SHOULD send a stream of 550 silence packets to OSPS. If the state of the UAS is ringing or 551 ringback, the UAS SHOULD send a ringback stream to OSPS. 553 If an INVITE/UPDATE with OSPS-Tag of "EI" is accepted, the UAS MUST 554 enable communication between the UAC and the local user. The UAS MAY 555 put any existing call on hold, or initiate an ad-hoc conference. 557 If an INVITE/UPDATE with OSPS-Tag of "RING" is accepted, the UAS MUST 558 perform operator ringback in accordance with local procedures, e.g., 559 generate a 3-second howling tone or a sustained ring, depending on 560 the state of the user equipment. 562 6.5. Procedures at a Trusted User Agent Server (UAS) 564 The procedures at a trusted UAS MUST be identical to those described 565 in 6.4. 567 6.6. Procedures at Proxy 569 In the DCS architecture, the OSPS is considered a trusted UAC. If a 570 proxy receives a P-DCS-OSPS header in a request from an untrusted 571 source, it MUST either remove the header or reject the request with a 572 403-Forbidden response. 574 A proxy that implements a call-forwarding service MUST NOT respond to 575 an INVITE request with a 3xx response, if the request contained the 576 P-DCS-OSPS header. 578 7. P-DCS-BILLING-INFO 580 There are many billing models used in deriving revenue from telephony 581 services today. Charging for telephony services is tightly coupled 582 to the use of network resources. It is outside the scope of this 583 document to discuss the details of these numerous and varying 584 methods. 586 Proxies have access to subscriber information and act as policy 587 decision points and trusted intermediaries along the call signaling 588 path. Edge routers provide the network connection and resource 589 policy enforcement mechanism and also capture and report network 590 connection and resource usage information. Edge routers need to be 591 given billing information that can be logged with Record Keeping or 592 Billing servers. The proxy, as a central point of coordination 593 between call signaling and resource management, can provide this 594 information based on the authenticated identity of the calling and 595 called parties. Since there is a trust relationship among proxies, 596 they can be relied upon to exchange trusted billing information 597 pertaining to the parties involved in a call. 599 For Usage Accounting records, it is necessary to have an identifier 600 that can be associated with all the event records produced for the 601 call. The SIP Call-ID header field cannot be used as such an 602 identifier since it is selected by the originating user agent, and 603 may not be unique among all past calls as well as current calls. 604 Further, since this identifier is to be used by the service provider, 605 it should be chosen in a manner and in a format that meets the 606 service provider's needs. 608 Billing information may not necessarily be unique for each user 609 (consider the case of calls from an office all billed to the same 610 account). Billing information may not necessarily be identical for 611 all calls made by a single user (consider prepaid calls, credit card 612 calls, collect calls, etc). It is therefore necessary to carry 613 billing information separate from the calling and called party 614 identification. Furthermore, some billing models call for split- 615 charging where multiple entities are billed for portions of the call. 617 The addition of a SIP General Header Field allows for the capture of 618 billing information and billing identification for the duration of 619 the call. 621 It is the intent that the billing extensions would only appear on 622 trusted network segments, and MAY be inserted by a proxy or trusted 623 UA in INVITE and SUBSCRIBE requests in a trusted network segment, and 624 removed before leaving trusted network segments. The P-DCS-Billing- 625 Info header extension is used only on requests and responses between 626 proxies and trusted User Agents. It is never sent to an untrusted 627 UA. It is expected that untrusted UAs do not send this header. 629 7.1. Syntax 631 The DCS-Billing-Info header is defined by the following ABNF (some 632 terms used in this ABNF are defined in [RFC3261]): 634 P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON 635 Billing-Correlation-ID "/" FEID 636 *(SEMI Billing-Info-param) 637 Billing-Correlation-ID = 1*48(HEXDIG) 638 FEID = 1*16(HEXDIG) "@" host 639 Billing-Info-param = RKS-Group-ID-param / Charge-param / 640 Calling-param / Called-param / 641 Routing-param / Loc-Routing-param / 642 JIP-param / generic-param 643 RKS-Group-ID-param = "rksgroup" EQUAL RKS-Group-ID 644 RKS-Group-ID = token 645 Charge-param = "charge" EQUAL Acct-Charge-URI 646 Acct-Charge-URI = LDQUOT addr-spec RDQUOT 647 Calling-param = "calling" EQUAL Acct-Calling-URI 648 Acct-Calling-URI = LDQUOT addr-spec RDQUOT 649 Called-param = "called" EQUAL Acct-Called-URI 650 Acct-Called-URI = LDQUOT addr-spec RDQUOT 651 Routing-param = "routing" EQUAL Acct-Routing-URI 652 Acct-Routing-URI = LDQUOT addr-spec RDQUOT 653 Loc-Routing-param = "locroute" EQUAL Acct-Loc-Routing-URI 654 Acct-Loc-Routing-URI = LDQUOT addr-spec RDQUOT 655 JIP-param = "jip" EQUAL jip 656 jip = LDQUOT 1*phonedigit-hex jip-context RDQUOT 657 jip-context = ";jip-context=" jip-descriptor 658 jip-descriptor = global-hex-digits 659 global-hex-digits = "+" 1*3(phonedigit) *phonedigit-hex 660 phonedigit = DIGIT / [ visual-separator ] 661 phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] 662 visual-separator = "-" / "." / "(" / ")" 664 This document adds the following entry to Table 2 of [RFC3261]: 666 Header field where proxy ACK BYE CAN INV OPT REG PUB 667 ------------ ----- ----- --- --- --- --- --- --- --- 668 P-DCS-Billing-Info admr - - - o - - - 670 SUB NOT REF INF UPD PRA MSG 671 --- --- --- --- --- --- --- 672 - - - - - - - 674 The P-DCS-Billing-Info extension contains an identifier that can be 675 used by an event recorder to associate multiple usage records, 676 possibly from different sources, with a billable account. It further 677 contains the subscriber account information, and other information 678 necessary for accurate billing of the service. This header is only 679 used between proxies and trusted User Agents. 681 The Billing-Correlation-ID, BCID, is specified in [PCEM] as a 24-byte 682 binary structure, containing 4 bytes of NTP timestamp, 8 bytes of the 683 unique identifier of the network element that generated the ID, 8 684 bytes giving the time zone, and 4 bytes of monotonically increasing 685 sequence number at that network element. This identifier is chosen 686 to be globally unique within the system for a window of several 687 months. This MUST be encoded in the P-DCS-Billing-Info header as a 688 hexadecimal string of up to 48 characters. Leading zeroes MAY be 689 suppressed. 691 The Financial-Entity-ID (FEID) is specified in [PCEM] as an 8-byte 692 structure, containing the financial identifier for that domain, 693 followed by a domain name. FEID can be associated with a type of 694 service and could be assigned to multiple domains by the same 695 provider. A domain could contain multiple assigned FEIDs. This 8- 696 byte structure MUST be encoded in the P-DCS-Billing-Info header as a 697 hexadecimal string of up to 16 characters. Trailing zeroes MAY be 698 suppressed. "Host" contains the domain name. 700 The RKS-Group-ID specifies a record keeping server (or group of 701 cooperating servers) for event messages relating to this call. It is 702 used to control certain optimizations of procedures when multiple 703 event message streams are being sent to the same Record Keeping 704 Server. 706 Additional parameters contain the information needed for generation 707 of event message records. Acct-Charge-URI, Acct-Calling-URI, Acct- 708 Called-URI, Acct-Routing-URI, and Acct-Loc-Routing-URI are each 709 defined as URLs; they should all contain tel URLs with E.164 710 formatted addresses. These fields are further defined in [PCEM] 711 under the element identifiers "Charge_Number" (element ID 16), 712 "Calling_Party_Number" (element ID 4), "Called_Party_Number" (element 713 ID 5), "Routing Number" (element ID 25), and 714 "Location_Routing_Number" (element ID 22). 716 The JIP-param contains the calling jurisdiction information, or 717 numbering plan area, of the network in which the call originated. 718 The field is further defined in [PCEM] under the element identifier 719 "Jurisdiction_Information_Parameter" (element ID 82). An older 720 [RFC3603] compliant implementation may not use the JIP-param. 722 7.2. Procedures at an Untrusted User Agent Client (UAC) 724 This header is never sent to an untrusted UA. It is expected that 725 untrusted UAs do not send this header. 727 7.3. Procedures at a Trusted User Agent Client (UAC) 729 The UAC MUST generate the Billing-Correlation-ID for the call, and 730 insert it into the P-DCS-Billing-Info header in the initial INVITE or 731 SUBSCRIBE message sent to the terminating entity, along with the 732 charging information for the call. The UAC MUST include its FEID, 733 and the RKS-Group-ID for the Record-Keeping-Server being used by the 734 UAC. If the UAC performed a Local Number Portability (LNP) query, it 735 MUST include the Routing Number and Location Routing Number returned 736 by the query. If available to the UAC, the UAC MUST include the JIP- 737 param. 739 If the response to the initial INVITE is a 3xx-Redirect, the UAC 740 generates a new initial INVITE request to the destination specified 741 in the Contact header field, as per standard SIP. If a UAC receives 742 a 3xx-Redirect response to an initial INVITE, the new INVITE 743 generated by the UAC MUST contain the P-DCS-Billing-Info header field 744 values from the 3xx- Redirect response. If the UAC is acting as a 745 B2BUA, instead of generating a new INVITE it MAY generate a private- 746 URL and place it in the Contact header field of a 3xx-Redirect 747 response sent to the originating endpoint. This private-URL MUST 748 contain (or contain a pointer to) the P-DCS-Billing-Info value, which 749 indicates the charging arrangement for the new call, and an 750 expiration time very shortly in the future, to limit the ability of 751 the originator to re-use this private-URL for multiple calls. 753 A UAC that includes a Refer-To header in a REFER request MUST include 754 a P-DCS-Billing-Info header in the Refer-To's URL. This P-DCS- 755 Billing-Info header MUST include the accounting information of the 756 initiator of the REFER. 758 7.4. Procedures at an Untrusted User Agent Server (UAS) 760 This header is never sent to an untrusted UAS, and is never sent by 761 an untrusted UAS. 763 7.5. Procedures at a Trusted User Agent Server (UAS) 765 The UAS MUST include a P-DCS-Billing-Info header in the first 766 reliable 1xx (except 100) or 2xx response to an initial INVITE or 767 SUBSCRIBE message. This P-DCS-Billing-Info header MUST include the 768 Billing- Correlation-ID generated by the UAS, the FEID of the UAS, 769 and the RKS-Group-ID of the Record-Keeping-Server being used by the 770 UAS. The UAS MAY change the values of Acct-Charge-URI if it wishes 771 to override the billing information that was present in the INVITE 772 (e.g., for a toll-free call). The decision to do this and the 773 contents of the new Acct-Charge-URI MUST be determined by service 774 provider policy provisioned in the UAS. If the UAS performed a LNP 775 query, it MUST include the Routing Number and Location Routing Number 776 returned by the query. 778 The UAS MUST add a P-DCS-Billing-Info header to a 3xx-redirect 779 response to an initial INVITE, giving the accounting information for 780 the call forwarder, for the call segment from the destination to the 781 forwarded-to destination. 783 7.6. Procedures at Proxy 785 Three sets of proxy procedures are defined: (1) the procedures at an 786 originating proxy, (2) the procedures at a terminating proxy, and (3) 787 the procedures at a tandem proxy. 789 The originating proxy is a proxy that received the INVITE or 790 SUBSCRIBE request from a non-trusted endpoint. 792 The terminating proxy is a proxy that sends the INVITE or SUBSCRIBE 793 request to a non-trusted endpoint. 795 A proxy that is neither an originating proxy, nor a terminating 796 proxy, is a tandem proxy. 798 For purposes of mid-call changes, such as call transfers, the proxy 799 that receives the request from a non-trusted endpoint is considered 800 the initiating proxy; the proxy that sends the request to a non- 801 trusted endpoint is considered the recipient proxy. Procedures for 802 the initiating proxy are included below with those for originating 803 proxies, while procedures for the recipient proxy are included with 804 those for terminating proxies. 806 A proxy that both receives the request from an untrusted endpoint, 807 and sends the request to a non-trusted endpoint, performs both sets 808 of procedures. 810 7.6.1. Procedures at Originating Proxy 812 The originating proxy MUST generate the Billing-Correlation-ID for 813 the call, and insert it into the P-DCS-Billing-Info header in the 814 initial INVITE or SUBSCRIBE message sent to the terminating entity, 815 along with the charging information for the call. The originating 816 proxy MUST include its FEID, and the RKS-Group-ID for the Record- 817 Keeping-Server being used by the originating proxy. If the 818 originating proxy performed a LNP query, it MUST include the Routing 819 Number, Location Routing Number and JIP-param returned by the query. 820 Any P-DCS-Billing-Info header present from an untrusted UA MUST be 821 removed. 823 If the Request-URI contains a private-URL, and the decoded username 824 contains billing information, the originating proxy MUST generate a 825 P-DCS-Billing-Info header with that decrypted information. 826 Otherwise, the originating proxy MUST determine the accounting 827 information for the call originator, and insert a P-DCS-Billing-Info 828 header including that information. 830 If the response to the initial INVITE is a 3xx-Redirect, received 831 prior to a non-100 provisional response, the originating proxy 832 generates a new initial INVITE request to the destination specified 833 in the Contact header field, as per standard SIP. If an originating 834 proxy receives a 3xx-Redirect response to an initial INVITE prior to 835 a non-100 provisional response, the INVITE generated by the proxy 836 MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect 837 response. 839 If the response to the initial INVITE is a 3xx-Redirect, received 840 after a non-100 provisional response, the originating proxy generates 841 a private-URL and places it in the Contact header of a 3xx-Redirect 842 response sent to the originating endpoint. This private-URL MUST 843 contain (or contain a pointer to) the P-DCS-Billing-Info value, which 844 indicate the charging arrangement for the new call, and an expiration 845 time very shortly in the future, to limit the ability of the 846 originator to re-use this private-URL for multiple calls. 848 An originating proxy that processes a REFER request from an untrusted 849 UA MUST include a P-DCS-Billing-Info header in the Refer-To's URL. 850 This P-DCS-Billing-Info header MUST include the accounting 851 information of the initiator. 853 7.6.2. Procedures at Terminating Proxy 855 The terminating proxy MUST NOT send the P-DCS-Billing-Info header to 856 an untrusted destination. 858 The terminating proxy MUST include a P-DCS-Billing-Info header in the 859 first reliable 1xx (except 100) or 2xx response to an initial INVITE 860 or SUBSCRIBE message. This P-DCS-Billing-Info header MUST include 861 the Billing-Correlation-ID generated by the terminating proxy, the 862 FEID of the terminating proxy, and the RKS-Group-ID of the Record- 863 Keeping-Server being used by the terminating proxy. The terminating 864 proxy MAY change the values of Acct-Charge-URI if it wishes to 865 override the billing information that was present in the INVITE 866 (e.g., for a toll-free call). The decision to do this and the 867 contents of the resulting P-DCS-Billing-Info header MUST be 868 determined by service provider policy provisioned in the terminating 869 proxy. If the terminating proxy performed a LNP query, it MUST 870 include the Routing Number and Location Routing Number returned by 871 the query. 873 The terminating proxy MUST add P-DCS-Billing-Info headers to a 3xx- 874 redirect response to an initial INVITE, giving the accounting 875 information for the call forwarder, for the call segment from the 876 destination to the forwarded-to destination. 878 A proxy receiving a mid-call REFER request that includes a Refer-To 879 header generates a private-URL and places it in the Refer-To header 880 sent to the endpoint. This private-URL MUST contain the P-DCS- 881 Billing-Info value, which indicates the charging arrangement for the 882 new call, and an expiration time very shortly in the future, to limit 883 the ability of the endpoint to re-use this private-URL for multiple 884 calls. 886 7.6.3. Procedures at Tandem Proxy 888 If the tandem proxy performed a LNP query, it MUST insert the Routing 889 Number and Location Routing Number returned by the query into the P- 890 DCS-Billing-Info header in the first reliable 1xx/2xx/3xx (except 891 100) response. 893 8. P-DCS-LAES and P-DCS-Redirect 895 NOTE: According to RFC 2804 [RFC2804], the IETF supports 896 documentation of lawful intercept technology if it is necessary to 897 develop it. The following section provides such documentation. The 898 [RFC2119] language, as stated above, describes the requirements of 899 the specification only if implemented, and strictly within the 900 applicability domain described above. See RFC 2804 for description 901 of issues regarding privacy, security, and complexity in relation to 902 this technology. 904 The P-DCS-LAES extension contains the information needed to support 905 Lawfully Authorized Electronic Surveillance. This header contains 906 the address and port of an Electronic Surveillance Delivery Function 907 for delivery of a duplicate stream of event messages related to this 908 call. The header fields MAY also contain the associated BCID for the 909 event stream as well as additional address and port for delivery of 910 call content and associated cccid. The BCID is used to correlate a 911 series of events associated with a single call or session. The cccid 912 is used to identify an intercepted call content to an intercepted 913 call. The P-DCS-LAES header is only used between proxies and trusted 914 User Agents. The P-DCS-LAES header defined here is not backwards 915 compatible with that defined in [RFC3603], which is deprecated by the 916 document. This version of the P-DCS-LAES header adds a ccc-id 917 parameter to support the intercept of content, and deletes security 918 key information. This version does not mandate the use of the BCID. 920 The P-DCS-Redirect extension contains call identifying information 921 needed to support the requirements of Lawfully Authorized Electronic 922 Surveillance of redirected calls. This header is only used between 923 proxies and trusted User Agents. 925 Note that there is overlap in function between the P-DCS-Redirect 926 header and the History-Info header specified in RFC 4244. The 927 original P-DCS-Redirect came to existence in RFC 3603 before the 928 History-Info. Therefore, the P-DCS-Redirect header is continued here 929 for backward compatibility with existing implementations. 931 Use of P-DCS-LAES and P-DCS-Redirect is controlled by a combination 932 of legislation, regulation, and court orders, which MUST be followed. 933 In certain cases inclusion of these headers will be mandated, and 934 therefore MUST be present in the requests and responses indicated. 935 In other cases inclusion of these headers will be forbidden, and 936 therefore MUST NOT be present in the request and responses indicated. 937 In the sub-sections that follow, use of "SHOULD" is intended to 938 capture these conflicting situations, e.g., a P-DCS-LAES header 939 SHOULD be included in an initial INVITE means either that it MUST be 940 included or that it MUST NOT be included, based on the applicable 941 court orders. 943 8.1. Syntax 945 The formats of the P-DCS-LAES and P-DCS-Redirect headers are given by 946 the following ABNF (some terms used in this ABNF are defined in 947 [RFC3261] and [RFC5234]): 949 P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig 950 *(SEMI Laes-param) 951 Laes-sig = hostport 952 Laes-param = Laes-content / Laes-cccid 953 Laes-bcid / generic-param 954 Laes-content = "content" EQUAL hostport 956 Laes-bcid = "bcid" EQUAL 1*48(HEXDIG) 957 Laes-cccid = "cccid" EQUAL 1*8(HEXDIG) 959 P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID 960 *(SEMI redir-params) 961 Called-ID = LDQUOT addr-spec RDQUOT 962 redir-params = redir-uri-param / redir-count-param / 963 generic-param 964 redir-uri-param = "redirector-uri" EQUAL Redirector 965 Redirector = LDQUOT addr-spec RDQUOT 966 redir-count-param = "count" EQUAL Redir-count 967 Redir-count = 1*DIGIT 969 This document adds the following entry to Table 2 of [RFC3261]: 970 Header field where proxy ACK BYE CAN INV OPT REG PUB 971 ------------ ----- ----- --- --- --- --- --- --- --- 972 P-DCS-LAES adr - - - o - - - 973 P-DCS-Redirect adr - - - o - - - 975 SUB NOT REF INF UPD PRA MSG 976 --- --- --- --- --- --- --- 977 - - - - - - - 978 - - - - - - - 980 The values of Laes-sig and Laes-content are addresses of the 981 Electronic Surveillance Delivery Function, and used as the 982 destination address for call-identifying information and call- 983 content, respectively. Laes-bcid contains a correlation ID that is 984 used to link a sequence of intercepted call processing events related 985 to a single call. Laes-cccid contains an identifier of the 986 intercepted call content. The Laes-bcid field MAY be present. The 987 BCID is included per network operator configuration to support events 988 reported as defined in [PCEM]. The Laes-cccid field MAY be present 989 when the Laes-content field is present. The Laes-cccid is included 990 per network operator configuration for networks where entities 991 receiving the intercepted contents may act a media relay functions to 992 other surveillance functions that are the source of the content 993 surveillance request. The design of multiple surveillance entities 994 that receive call content is beyond the scope of this document. 996 The P-DCS-Redirect header contains redirection information. The 997 Called-ID indicates the original destination requested by the user 998 (e.g., number dialed originally), the redir-uri-param indicates the 999 entity performing the redirection, and the Redir-count indicates the 1000 number of redirections that have occurred. For example, if A calls 1001 B, who forwards to C, who forwards to D, then, when C forwards to D, 1002 the Called-ID will be A, redir-uri-param will be C, and count will be 1003 2. 1005 8.2. Procedures at an Untrusted User Agent Client (UAC) 1007 This header MUST NOT be sent to an untrusted UAC, and MUST NOT be 1008 sent by an untrusted UAC. 1010 8.3. Procedures at a Trusted User Agent Client (UAC) 1012 The UAC checks for an outstanding lawfully authorized surveillance 1013 order for the originating subscriber, and, if present, MAY include 1014 this information in the Authorization for Quality of Service [PCDQOS] 1015 or MAY signal this information to the device performing the intercept 1016 (e.g., a Media Gateway). Otherwise, intercept access points are 1017 instructed to perform call content and/or call data intercept by 1018 mechanisms that are outside the scope of this document. 1020 If the P-DCS-LAES header is present in the first reliable 1xx (except 1021 100), 2xx or 3xx response (indicating surveillance is required on the 1022 terminating subscriber, but that the terminating equipment is unable 1023 to perform that function), the UAC MAY include this information in 1024 the Authorization for Quality of Service, or MAY signal this 1025 information to the device performing the intercept (e.g., a Media 1026 Gateway). Otherwise, intercept access points are instructed to 1027 perform call content and/or call data intercept by mechanisms that 1028 are outside the scope of this document. 1030 If a 3xx-Redirect response is received to the initial INVITE request, 1031 and if a P-DCS-LAES header is present in the 3xx response, the UAC 1032 SHOULD include that header unchanged in the reissued INVITE. The UAC 1033 SHOULD also include a P-DCS-Redirect header containing the original 1034 dialed number, the most recent redirecting party, and the number of 1035 redirections that have occurred. Although it is technically possible 1036 for the originating equipment to perform this surveillance (or add to 1037 its existing surveillance of the call), the design of the 1038 surveillance system has the terminating equipment performing the 1039 surveillance for all the intermediate forwardings. 1041 A UAC that includes a Refer-To header in a REFER request, when the 1042 originating subscriber has an outstanding lawfully authorized 1043 surveillance order, SHOULD include a P-DCS-LAES header attached to 1044 the Refer-To. The UAC may also include a P-DCS-Redirect header. The 1045 P-DCS-LAES header MAY include the Laes-bcid parameter set to a value 1046 that uniquely identifies the call, SHOULD include the address and 1047 port of the local Electronic Surveillance Delivery Function for a 1048 copy of the call's event messages, SHOULD include the address and 1049 port of the local Electronic Surveillance Delivery Function for the 1050 copy of call content if call content is to be intercepted, and MAY 1051 include the Laes-cccid parameter set to a value that uniquely 1052 identifies the intercepted audio stream if call content is to be 1053 intercepted. 1055 The trusted UAC MUST NOT send the P-DCS-LAES and P-DCS-Redirect 1056 headers to an untrusted entity. 1058 8.4. Procedures at an Untrusted User Agent Server (UAS) 1060 This header MUST NOT be sent to an untrusted UAS, and MUST NOT be 1061 sent by an untrusted UAS. 1063 8.5. Procedures at a Trusted User Agent Server (UAS) 1065 The UAS checks for an outstanding lawfully authorized surveillance 1066 order for the terminating subscriber, or presence of the P-DCS-LAES 1067 header in the INVITE request. If either is present, the UAS MAY 1068 include this information in the authorization for Quality of Service 1069 [PCDQOS].Otherwise, intercept access points are instructed to perform 1070 call content and/or call data intercept by mechanisms that are 1071 outside the scope of this document. 1073 If the terminating equipment is unable to perform the required 1074 surveillance (e.g., if the destination is a voicemail server), the 1075 UAS SHOULD include a P-DCS-LAES header in the first reliable 1xx 1076 (except 100), 2XX or 3XX response requesting the originating proxy to 1077 perform the surveillance. The P-DCS-LAES header MAY include the 1078 Laes-bcid parameter with a value that uniquely identifies the call, 1079 SHOULD include the address and port of the local Electronic 1080 Surveillance Delivery Function for a copy of the call's event 1081 messages, SHOULD include the address and port of the local Electronic 1082 Surveillance Delivery Function for the copy of call content if call 1083 content is to be intercepted, and MAY include the Laes-cccid 1084 parameter set to a value that uniquely identifies the intercepted 1085 audio stream if call content is to be intercepted. 1087 If the response to the initial INVITE request is a 3xx-Redirect 1088 response, and there is an outstanding lawfully authorized 1089 surveillance order for the terminating subscriber, the UAS SHOULD 1090 include a P-DCS-LAES header in the 3xx-Redirect response, with 1091 contents as described above. 1093 The trusted UAS MUST NOT send the P-DCS-LAES and P-DCS-Redirect 1094 headers to an untrusted entity. 1096 8.6. Procedures at Proxy 1098 Two sets of proxy procedures are defined: (1) the procedures at an 1099 originating proxy, and (2) the procedures at a terminating proxy. 1100 The originating proxy is a proxy that receives the INVITE request 1101 from a non-trusted endpoint. 1103 The terminating proxy is a proxy that sends the INVITE request to a 1104 non-trusted endpoint. 1106 For purposes of mid-call changes, such as call transfers, the proxy 1107 that receives the request from a non-trusted endpoint is considered 1108 the initiating proxy; the proxy that sends the request to a non- 1109 trusted endpoint is considered the recipient proxy. Procedures for 1110 the initiating proxy are included below with those for originating 1111 proxies, while procedures for the recipient proxy are included with 1112 those for terminating proxies. 1114 A proxy that both receives the INVITE request from an untrusted 1115 endpoint, and sends the INVITE request to a non-trusted endpoint, 1116 MUST NOT generate P-DCS-LAES nor P-DCS-Redirect headers. 1118 A proxy that is neither an originating proxy nor a terminating proxy 1119 SHOULD pass the P-DCS-Laes and P-DCS-Redirect headers in requests and 1120 responses. 1122 8.6.1. Procedures at Originating Proxy 1124 The Originating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect 1125 headers in requests or responses to or from an untrusted proxy or 1126 untrusted UA. 1128 The originating proxy checks for an outstanding lawfully authorized 1129 surveillance order for the originating subscriber, and, if present, 1130 MAY include this information in the Authorization for Quality of 1131 Service [PCDQOS] or MAY signal this information to the device 1132 performing the intercept (e.g., a Media Gateway). Otherwise, 1133 intercept access points are instructed to perform call content and/or 1134 call data intercept by mechanisms that are outside the scope of this 1135 document. 1137 If the P-DCS-LAES header is present in the first reliable 1xx (except 1138 100), 2xx or 3xx response (indicating surveillance is required on the 1139 terminating subscriber, but that the terminating equipment is unable 1140 to perform that function), the originating proxy MAY include this 1141 information in the Authorization for Quality of Service, or MAY 1142 signal this information to the device performing the intercept (e.g., 1143 a Media Gateway). Otherwise, intercept access points are instructed 1144 to perform call content and/or call data intercept by mechanisms that 1145 are outside the scope of this document. 1147 If the Request-URI in an initial INVITE request contains a private- 1148 URL, the originating proxy MUST decrypt the userinfo information to 1149 find the real destination for the call, and other special processing 1150 information. If electronic surveillance information is contained in 1151 the decrypted userinfo, the originating proxy SHOULD generate a P- 1152 DCS-LAES and (if necessary) a P-DCS-REDIRECT header with the 1153 surveillance information. 1155 If a 3xx-Redirect response is received to the initial INVITE request 1156 prior to a non-100 provisional response, and if a P-DCS-LAES header 1157 is present in the 3xx response, the originating proxy SHOULD include 1158 that header unchanged in the reissued INVITE. The originating proxy 1159 SHOULD also include a P-DCS-Redirect header containing the original 1160 dialed number, the most recent redirecting party, and the number of 1161 redirections that have occurred. 1163 If a 3xx-Redirect response is received to the initial INVITE request 1164 after a non-100 provisional response, the originating proxy generates 1165 a private-URL and places it in the Contact header of a 3xx-Redirect 1166 response sent to the originating endpoint. If a P-DCS-LAES header is 1167 present in the 3xx response, this private-URL MUST contain (1) the 1168 electronic surveillance information from the 3xx-Redirect response, 1169 (2) the original destination number, (3) the identity of the 1170 redirecting party, and (4) the number of redirections of this call. 1172 An originating proxy that processes a REFER request [RFC3515] from an 1173 untrusted UA, when the originating subscriber has an outstanding 1174 lawfully authorized surveillance order, becomes a B2BUA for that 1175 request. It SHOULD reissue the request with a P-DCS-LAES header 1176 added to the Refer-To's URL. It MAY also include a P-DCS-Redirect 1177 header. The P-DCS-LAES header SHOULD include (1) the address and 1178 port of the local Electronic Surveillance Delivery Function for a 1179 copy of the call's event messages, (2) the address and port of the 1180 local Electronic Surveillance Delivery Function for the copy of call 1181 content if call content is to be intercepted. The P-DCS-LAES header 1182 MAY include (1) the Laes-bcid parameter set to a value that uniquely 1183 identifies the call, and (2) the Laes-cccid parameter set to a value 1184 that uniquely identifies the intercepted audio stream if call content 1185 is to be intercepted. 1187 An initiating proxy that sends a mid-call REFER request including a 1188 Refer-to header, when the initiating subscriber has an outstanding 1189 lawfully authorized surveillance order, SHOULD include a P-DCS-LAES 1190 header in the Refer-To's URL. 1192 The originating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect 1193 headers to an untrusted entity. 1195 8.6.2. Procedures at Terminating Proxy 1197 The Terminating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect 1198 headers in requests or responses to or from an untrusted proxy or UA. 1200 The terminating proxy checks for an outstanding lawfully authorized 1201 surveillance order for the terminating subscriber. If present, the 1202 terminating proxy MAY include this information in the authorization 1203 for Quality of Service [PCDQOS]. Otherwise, intercept access points 1204 are instructed to perform call content and/or call data intercept by 1205 mechanisms that are outside the scope of this document. 1207 The terminating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect 1208 headers to an untrusted entity, either as headers in the request or 1209 response, or as headers attached to URIs in the request or response. 1211 If the terminating equipment is unable to perform the required 1212 surveillance (e.g., if the destination is a voicemail server), the 1213 terminating proxy SHOULD include a P-DCS-LAES header in the first 1214 reliable 1xx/2xx/3xx (except 100) response requesting the originating 1215 proxy to perform the surveillance. The P-DCS-LAES header MAY include 1216 the Laes-bcid parameter set to a value that uniquely identifies the 1217 call, SHOULD include the address and port of the local Electronic 1218 Surveillance Delivery Function for a copy of the call's event 1219 messages, SHOULD include the address and port of the local Electronic 1220 Surveillance Delivery Function for the copy of call content if call 1221 content is to be intercepted, and MAY include the Laes-cccid 1222 parameter set to a value that uniquely identifies the audio stream if 1223 call content is to be intercepted. 1225 If the response to the initial INVITE request is a 3xx-Redirect 1226 response, and there is an outstanding lawfully authorized 1227 surveillance order for the terminating subscriber, the terminating 1228 proxy SHOULD include a P-DCS-LAES header in the 3xx-Redirect 1229 response, with contents as described above. 1231 A proxy receiving a mid-call REFER request [RFC3515] that includes a 1232 Refer-To header with a P-DCS-LAES header attached becomes a B2BUA for 1233 this request. It MUST generate a private-URL and place it in the 1234 Refer-To header sent to the endpoint. This private-URL MUST contain 1235 the P-DCS-LAES and P-DCS-Redirect information from the attached 1236 header fields. 1238 9. Security Considerations 1240 QoS gate coordination, billing information, and electronic 1241 surveillance information are all considered to be sensitive 1242 information that MUST be protected from eavesdropping and furthermore 1243 require integrity checking. It is therefore necessary that the 1244 trusted UAs and proxies take precautions to protect this information 1245 from eavesdropping and tampering. Use of IPsec or TLS between 1246 Proxies and Trusted User Agents is REQUIRED. A minimum mandatory-to- 1247 implement IPsec configuration for the DCS architecture is given by 1248 [PCSEC]. Also REQUIRED is mutual authentication (1) between Proxies 1249 and (2) between trusted UAs and Proxies, both of which MAY be 1250 implemented with administratively pre-shared keys, or through 1251 consultation with another trusted third party. If IPsec is to be 1252 used, the specification of the security policies and procedures of 1253 the administrative domain where these headers are applicable (and all 1254 connections between administrative domains in the federation) MUST 1255 define an interoperable set of options. 1257 10. IANA Considerations 1259 The header field registry is updated as follows: 1261 Header Name compact Reference 1262 ----------------- ------- --------- 1263 P-DCS-Trace-Party-ID [RFCxxxx] 1264 P-DCS-OSPS [RFCxxxx] 1265 P-DCS-Billing-Info [RFCxxxx] 1266 P-DCS-LAES [RFCxxxx] 1267 P-DCS-Redirect [RFCxxxx] 1269 The following entries in the Header Field Parameters and Parameter 1270 Values registry are updated as follows: 1272 Header Field Parameter Name Values 1273 Reference 1274 ---------------------------- --------------------------- ---------- 1276 P-DCS-Billing-Info called No 1277 [RFCxxxx] 1278 P-DCS-Billing-Info calling No 1279 [RFCxxxx] 1280 P-DCS-Billing-Info charge No 1281 [RFCxxxx] 1282 P-DCS-Billing-Info locroute No 1283 [RFCxxxx] 1284 P-DCS-Billing-Info rksgroup No 1285 [RFCxxxx] 1286 P-DCS-LAES content No 1287 [RFCxxxx] 1288 P-DCS-Redirect count No 1289 [RFCxxxx] 1290 P-DCS-Redirect redirector-uri No 1291 [RFCxxxx] 1293 The following new entries in the Header Field Parameters and 1294 Parameter Values registry are removed as follows: 1296 Header Field Parameter Name Values 1297 Reference 1298 ---------------------------- --------------------------- ---------- 1300 P-DCS-Billing-Info routing No 1301 [RFC3603] 1302 P-DCS-LAES key No 1303 [RFC3603] 1305 The following new entries in the Header Field Parameters and 1306 Parameter Values registry are created as follows: 1308 Header Field Parameter Name Values 1309 Reference 1310 ---------------------------- --------------------------- ---------- 1312 P-DCS-Billing-Info jip No 1313 [RFCxxxx] 1314 P-DCS-LAES bcid No 1315 [RFCxxxx] 1316 P-DCS-LAES cccid No 1317 [RFCxxxx] 1319 The following new entries in the SIP/SIPS URI parameter registry are 1320 removed as follows: 1322 Parameter Name Predefined Values Reference 1323 -------------- ----------------- --------- 1324 timestamp No [RFCxxxx] 1326 Note to RFC editor: Replace RFCxxxx with the number of this RFC. 1328 11. Change Log 1330 o A timestamp parameter is added to the P-DCS-Trace-Party-ID header 1331 when available. Procedures on the use of the Target-Dialog header 1332 used together with the P-DCS-Trace-Party-ID are added. 1334 o The JIP parameter is added to the P-DCS-Billing-Infor header when 1335 available 1337 o The BCID billing correlation identifier and cccid call content 1338 channel identifier are addded to the P-DCS-LAES header. 1340 o P-DCS-Billing-Info header is applied to the SUBSCRIBE method. 1342 o P-DCS-REDIRECT header is applied to the REFER method. 1344 o The use of QoS authorization to establish content intercept is 1345 made optional in order not to preclude alternative content 1346 intercept provisioning mechanisms. 1348 o PUBLISH and MESSAGE methods are addded to the SIP method 1349 applicability matrices throughout. 1351 o Correction is made to table 2 to add m=modify. 1353 o IANA considerations are updated. 1355 o Corrections are made to timestamp format and references are 1356 updated. 1358 12. Acknowledgements 1360 The Distributed Call Signaling work in the PacketCable project is the 1361 work of a large number of people, representing many different 1362 companies. The authors would like to recognize and thank the 1363 following for their assistance: John Wheeler, Motorola; David 1364 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, Jay 1365 Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido 1366 Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi 1367 Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; 1368 Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- Hai 1369 Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable 1370 Communications. 1372 Previous versions further acknowledged, as co-authors, several people 1373 for providing the text of this document. They are: 1375 Bill Marshall (wtm@research.att.com) and K. K. Ramakrishnan 1376 (kkrama@research.att.com), AT&T; Ed Miller 1377 (edward.miller@terayon.com), Terayon; David Hancock (D.Hancock@ 1378 Cablelabs.com) and Glenn Russell (G.Russell@Cablelabs.com), 1379 CableLabs; Burcak Beser (burcak@juniper.net) Juniper Networks, Mike 1380 Mannette (Michael_Mannette@3com.com) and Kurt Steinbrenner 1381 (Kurt_Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com) and 1382 Flemming Andreasen (fandreas@cisco.com), Cisco Systems; John Pickens 1383 (jpickens@com21.com), Com21; Poornima Lalwaney 1384 (poornima.lalwaney@nokia.com), Nokia; Jon Fellows 1385 (jfellows@coppermountain.com), Copper Mountain Networks; Doc Evans 1386 (n7dr@arrisi.com) Arris, Keith Kelly (keith@netspeak.com), NetSpeak, 1387 and Brian Lindsay, Nortel Networks. 1389 13. References 1391 13.1. Normative References 1393 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1394 Specification, Implementation", RFC 1305, March 1992. 1396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1397 Requirement Levels", BCP 14, RFC 2119, March 1997. 1399 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1400 A., Peterson, J., Sparks, R., Handley, M., and E. 1401 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1402 June 2002. 1404 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1405 Method", RFC 3515, April 2003. 1407 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1408 10646", STD 63, RFC 3629, November 2003. 1410 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 1411 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 1413 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 1414 Identification in the Session Initiation Protocol (SIP)", 1415 RFC 4538, June 2006. 1417 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1418 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1420 13.2. Informative References 1422 [DCSARCH] Marshall, W., Osman, M., Andreasen, F., and D. Evans, 1423 "Architectural Considerations for Providing Carrier Class 1424 Telephony Services Utilizing SIP-based Distributed Call 1425 Control Mechanisms", Jan 2003. 1427 [PCDQOS] Cable Television Laboratories, Inc., "PacketCable 1.5 1428 Specifications, Dynamic Quality of Service", Aug 2005. 1430 [PCEM] Cable Television Laboratories, Inc., "PacketCable 1.5 1431 Specifications, Event Messages", Dec 2005. 1433 [PCSEC] Cable Television Laboratories, Inc., "PacketCable 1.5 1434 Specifications, Security", Jan 2005. 1436 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 1437 May 2000. 1439 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1440 Extensions to the Session Initiation Protocol (SIP) for 1441 Asserted Identity within Trusted Networks", RFC 3325, 1442 November 2002. 1444 [RFC3603] Marshall, W. and F. Andreasen, "Private Session Initiation 1445 Protocol (SIP) Proxy-to-Proxy Extensions for Supporting 1446 the PacketCable Distributed Call Signaling Architecture", 1447 RFC 3603, October 2003. 1449 Authors' Addresses 1451 Flemming Andreasen 1452 Cisco 1453 Edison, NJ 1454 USA 1456 Email: fandreas@cisco.com 1458 Bernie McKibben 1459 CableLabs 1460 Louisville, CO 1461 USA 1463 Email: B.McKibben@cablelabs.com 1465 Bill Marshall 1466 AT&T 1467 Florham Park, NJ 1468 USA 1470 Email: wtm@research.att.com 1472 Full Copyright Statement 1474 Copyright (C) The IETF Trust (2008). 1476 This document is subject to the rights, licenses and restrictions 1477 contained in BCP 78, and except as set forth therein, the authors 1478 retain all their rights. 1480 This document and the information contained herein are provided on an 1481 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1482 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1483 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1484 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1485 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1486 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1488 Intellectual Property 1490 The IETF takes no position regarding the validity or scope of any 1491 Intellectual Property Rights or other rights that might be claimed to 1492 pertain to the implementation or use of the technology described in 1493 this document or the extent to which any license under such rights 1494 might or might not be available; nor does it represent that it has 1495 made any independent effort to identify any such rights. Information 1496 on the procedures with respect to rights in RFC documents can be 1497 found in BCP 78 and BCP 79. 1499 Copies of IPR disclosures made to the IETF Secretariat and any 1500 assurances of licenses to be made available, or the result of an 1501 attempt made to obtain a general license or permission for the use of 1502 such proprietary rights by implementers or users of this 1503 specification can be obtained from the IETF on-line IPR repository at 1504 http://www.ietf.org/ipr. 1506 The IETF invites any interested party to bring to its attention any 1507 copyrights, patents or patent applications, or other proprietary 1508 rights that may cover technology that may be required to implement 1509 this standard. Please address the information to the IETF at 1510 ietf-ipr@ietf.org.