idnits 2.17.1 draft-andreasen-sipping-rfc3603bis-03.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 1372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1396. 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. 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 (June 2007) is 6160 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING F. Andreasen 3 Internet-Draft Cisco 4 Intended status: Standards Track B. McKibben 5 Expires: December 3, 2007 CableLabs 6 B. Marshall 7 AT&T 8 June 2007 10 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for 11 Supporting the PacketCable Distributed Call Signaling Architecture 12 draft-andreasen-sipping-rfc3603bis-03 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 December 3, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 In order to deploy a residential telephone service at very large 46 scale across different domains, it is necessary for trusted elements 47 owned by different service providers to exchange trusted information 48 that conveys customer-specific information and expectations about the 49 parties involved in the call. This document describes private 50 extensions to the Session Initiation Protocol (SIP) [RFC3261] for 51 supporting the exchange of customer information and billing 52 information between trusted entities in the PacketCable Distributed 53 Call Signaling Architecture. These extensions provide mechanisms for 54 access network coordination to prevent theft of service, customer 55 originated trace of harassing calls, support for operator services 56 and emergency services, and support for various other regulatory 57 issues. The use of the extensions is only applicable within closed 58 administrative domains, or among federations of administrative 59 domains with previously agreed-upon policies where coordination of 60 charging and other functions is required. 62 Table of Contents 64 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4. Conventions used in this document . . . . . . . . . . . . . . 9 68 5. P-DCS-TRACE-PARTY-ID . . . . . . . . . . . . . . . . . . . . . 10 69 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.2. Procedures at an Untrusted User Agent Client (UAC) . . . . 11 71 5.3. Procedures at a Trusted User Agent Client (UAC) . . . . . 11 72 5.4. Procedures at an Untrusted User Agent Server (UAS) . . . . 12 73 5.5. Procedures at a Trusted User Agent Server (UAS) . . . . . 12 74 5.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . . 12 75 5.6.1. Procedures at Originating Proxy . . . . . . . . . . . 12 76 5.6.2. Procedures at Terminating Proxy . . . . . . . . . . . 12 77 6. P-DCS-OSPS . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.2. Procedures at an Untrusted User Agent Client (UAC) . . . . 14 80 6.3. Procedures at a Trusted User Agent Client (UAC) . . . . . 14 81 6.4. Procedures at an Untrusted User Agent Server (UAS) . . . . 14 82 6.5. Procedures at a Trusted User Agent Server (UAS) . . . . . 15 83 6.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . . 15 84 7. P-DCS-BILLING-INFO . . . . . . . . . . . . . . . . . . . . . . 16 85 7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 7.2. Procedures at an Untrusted User Agent Client (UAC) . . . . 19 87 7.3. Procedures at a Trusted User Agent Client (UAC) . . . . . 20 88 7.4. Procedures at an Untrusted User Agent Server (UAS) . . . . 20 89 7.5. Procedures at a Trusted User Agent Server (UAS) . . . . . 20 90 7.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . . 21 91 7.6.1. Procedures at Originating Proxy . . . . . . . . . . . 21 92 7.6.2. Procedures at Terminating Proxy . . . . . . . . . . . 22 93 7.6.3. Procedures at Tandem Proxy . . . . . . . . . . . . . . 23 94 8. P-DCS-LAES and P-DCS-REDIRECT . . . . . . . . . . . . . . . . 24 95 8.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 8.2. Procedures at an Untrusted User Agent Client (UAC) . . . . 26 97 8.3. Procedures at a Trusted User Agent Client (UAC) . . . . . 26 98 8.4. Procedures at an Untrusted User Agent Server (UAS) . . . . 27 99 8.5. Procedures at a Trusted User Agent Server (UAS) . . . . . 27 100 8.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . . 27 101 8.6.1. Procedures at Originating Proxy . . . . . . . . . . . 28 102 8.6.2. Procedures at Terminating Proxy . . . . . . . . . . . 29 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 105 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 33 106 11.1. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 33 107 11.2. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 33 108 11.3. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 33 109 11.4. Changes in -00 since RFC 3603 . . . . . . . . . . . . . . 33 111 12. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 112 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 113 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 114 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36 115 14.2. Informative References . . . . . . . . . . . . . . . . . . 36 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 117 Intellectual Property and Copyright Statements . . . . . . . . . . 38 119 1. Applicability Statement 121 The SIP extensions described in this document make certain 122 assumptions regarding network topology, linkage between SIP and lower 123 layers, and the availability of transitive trust. These assumptions 124 are generally not applicable in the Internet as a whole. The use of 125 these headers is only applicable within closed administrative 126 domains, or among federations of administrative domains with 127 previously agreed-upon policies where coordination of charging and 128 other functions is required, as in for example the architecture 129 presented in [DCSARCH]. Use outside such a domain could result in 130 the leakage of potentially sensitive or private information. User 131 consent to the privacy implications of the policies in [DCSARCH] is 132 strongly encouraged in those domains as well. 134 Although [RFC2119] language is used in this document, the scope of 135 the normative language is only for the area of applicability of the 136 document and, like the technology, it does not apply to the general 137 Internet. 139 2. Introduction 141 In order to deploy a SIP-based [RFC3261] residential telephone 142 service at very large scale across different domains, it is necessary 143 for trusted elements owned by different service providers to exchange 144 trusted information that conveys billing information and expectations 145 about the parties involved in the call. 147 There are many billing models used in deriving revenue from telephony 148 services today. Charging for telephony services is tightly coupled 149 to the use of network resources. It is outside the scope of this 150 document to discuss the details of these numerous and varying 151 methods. 153 A key motivating principle of the DCS architecture described in 154 [DCSARCH] is the need for network service providers to be able to 155 control and monitor network resources; revenue may be derived from 156 the usage of these resources as well as from the delivery of enhanced 157 services such as telephony. Furthermore, the DCS architecture 158 recognizes the need for coordination between call signaling and 159 resource management. This coordination ensures that users are 160 authenticated and authorized before receiving access to network 161 resources and billable enhanced services. 163 DCS Proxies, as defined in [DCSARCH], have access to subscriber 164 information and act as policy decision points and trusted 165 intermediaries along the call signaling path. Edge routers provide 166 the network connectivity and resource policy enforcement mechanism 167 and also capture and report network connectivity and resource usage 168 information. Edge routers need to be given billing information that 169 can be logged with Record Keeping or Billing servers. The DCS Proxy, 170 as a central point of coordination between call signaling and 171 resource management, can provide this information based on the 172 authenticated identity of the calling and called parties. Since 173 there is a trust relationship among DCS Proxies, they can be relied 174 upon to exchange trusted billing information pertaining to the 175 parties involved in a call. See [DCSARCH] for a description of the 176 trust boundary and trusted versus untrusted entities. 178 For these reasons, it is appropriate to consider defining SIP header 179 extensions to allow DCS Proxies to exchange information during call 180 setup. It is the intent that the extensions would only appear on 181 trusted network segments, should be inserted upon entering a trusted 182 network region, and removed before leaving trusted network segments. 184 Significant amounts of information are retrieved by an originating 185 DCS Proxy in its handling of a connection setup request from a user 186 agent. Such information includes location information about the 187 subscriber (essential for emergency services calls), billing 188 information, and station information (e.g., coin operated phone). In 189 addition, while translating the destination number, information such 190 as the local-number-portability office code is obtained and will be 191 needed by all other proxies handling this call. 193 For Usage Accounting records, it is necessary to have an identifier 194 that can be associated with all the event records produced for the 195 call. The SIP Call-ID header field cannot be used as such an 196 identifier since it is selected by the originating user agent, and 197 may not be unique among all past calls as well as current calls. 198 Further, since this identifier is to be used by the service provider, 199 it should be chosen in a manner and in a format that meets the 200 service provider's needs. 202 Billing information may not necessarily be unique for each user 203 (consider the case of calls from an office all billed to the same 204 account). Billing information may not necessarily be identical for 205 all calls made by a single user (consider prepaid calls, credit card 206 calls, collect calls, etc). It is therefore necessary to carry 207 billing information separate from the calling and called party 208 identification. Furthermore, some billing models call for split- 209 charging where multiple entities are billed for portions of the call. 211 The addition of a SIP General Header Field allows for the capture of 212 billing information and billing identification for the duration of 213 the call. 215 It is the intent that the billing extensions would only appear on 216 trusted network segments, and MAY be inserted by a DCS Proxy in 217 INVITE and REFER requests and INVITE responses in a trusted network 218 segment, and removed before leaving trusted network segments. 220 In addition to support for billing, current residential telephone 221 service includes the need for customer originated trace (of harassing 222 or obscene calls), for operator services such as busy line 223 verification and emergency interrupt (initiated by an operator from 224 an Operator Services Position System (OSPS)), for emergency services 225 such as 9-1-1 calls to a Public Service Access Point (PSAP) and the 226 subsequent call handling, and support for Electronic Surveillance and 227 Law Enforcement access as required by applicable legislation and 228 court orders. In all of these cases, additional information about 229 the call and about the subscribers involved in the call needs to be 230 exchanged between the proxies. 232 3. Trust Boundary 234 The DCS architecture [DCSARCH] defines a trust boundary around the 235 various systems and servers that are owned, operated by, and/or 236 controlled by the service provider. These trusted systems include 237 the proxies and various servers such as bridge servers, voicemail 238 servers, announcement servers, etc. Outside of the trust boundary 239 lie the customer premises equipment, and various application and 240 media servers operated by third-party service providers. 242 Certain subscriber-specific information, such as billing and 243 accounting information, stays within the trust boundary. Other 244 subscriber-specific information, such as endpoint identity, may be 245 presented to untrusted endpoints or may be withheld based on 246 subscriber profiles. 248 The User Agent (UA) may be either within the trust boundary or 249 outside the trust boundary, depending on exactly what function is 250 being performed and exactly how it is being performed. Accordingly, 251 the procedures followed by a User Agent are different depending on 252 whether the UA is within the trust boundary or outside the trust 253 boundary. 255 The following sections giving procedures for User Agents therefore 256 are subdivided into trusted user agents and untrusted user agents. 258 4. Conventions used in this document 260 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 261 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 262 document are to be interpreted as described in BCP 14, [RFC2119]. 264 The term "private-URL" used in this document refers to a SIP URI that 265 is generated by a proxy, contains a "hostport" that identifies the 266 proxy, and contains a "userinfo" string that is generated by the 267 proxy. The "userinfo" typically contains (or points to) information 268 that is not to be disclosed outside the trusted domain of the 269 proxies, such as billing account numbers, electronic surveillance 270 indication, electronic surveillance parameters, and call redirection 271 information. Consequently, the information is either stored locally 272 by the proxy, or encrypted with a private key known only to the proxy 273 and encoded in a character string in the "userinfo" portion of the 274 URL. A checksum is included in the "userinfo" data to detect 275 tampering. The mechanism by which a proxy recognizes a "userinfo" as 276 a private-URL and decodes and recovers the original information is 277 local to the proxy and is not subject to standardization. Some 278 possible implementations include an initial magic cookie (e.g., 279 z9hG4Bk followed by the pointer/information), or use of a reserved 280 "user" name (e.g., "private") with the optional "password" containing 281 the pointer/information. 283 5. P-DCS-TRACE-PARTY-ID 285 In the telephone network, calling identity information is used to 286 support regulatory requirements such as the Customer Originated Trace 287 service, which provide the called party with the ability to report 288 obscene or harassing phone calls to law enforcement. This service is 289 provided independently of caller-id, and works even if the caller 290 requested anonymity. The calling party is here identified as the 291 station originating the call. In order for this service to be 292 dependable, the called party must be able to trust that the calling 293 identity information being presented is valid. One way to achieve 294 this is described in [RFC3325]. 296 To initiate a customer-originated-trace from an untrusted UAC, an 297 additional header is defined for the INVITE request. This header is 298 called P-DCS-Trace-Party-ID, and does not appear in any other request 299 or response. The entity addressed by the Request-URI performs the 300 service-provider-specific functions of recording and reporting the 301 caller identity in the P-DCS-Trace-Party-ID for law enforcement 302 action. It then forwards the call to either an announcement server 303 or to the service-provider's business office to collect further 304 information about the complaint. A trusted UAC does not use this 305 header, as it initiates this action locally. 307 5.1. Syntax 309 The ABNF description of this header is (some terms used in this ABNF 310 are defined in [RFC3261]): 312 P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr 314 The ABNF production for name-addr in [RFC3261] includes uri- 315 parameters, which allows for additional parameters to be defined 316 (other-param). We here define the following other-param parameters 317 to be used with P-DCS-Trace-Party-ID: 319 trace-param = callid-param 320 / remote-param ; defined in [RFC4538] 321 / local-param ; defined in [RFC4538] 322 / timestamp-param 323 callid-param = "call-id" EQUAL callid ; callid from [RFC3261] 324 timestamp-param = "timestamp" EQUAL 1*DIGIT ["." 1*DIGIT] 326 This document adds the following entry to Table 2 of [RFC3261]: 328 Header field where proxy ACK BYE CAN INV OPT REG 329 ------------ ----- ----- --- --- --- --- --- --- 330 P-DCS-Trace-Party-ID R dr - - - o - - 331 SUB NOT REF INF UPD PRA 332 --- --- --- --- --- --- 333 - - - - - - 335 The addr-spec contained in name-addr contains a URL that identifies 336 the remote endpoint. Addr-spec typically contains a tel: URL or SIP 337 URI giving the identity of the remote endpoint, as provided in the 338 signaling messages that established the session to be traced. 340 The callid-param contains contains the identifier of the call to be 341 traced. It is defined in section 12 of [RFC3261]. 343 The remote-param and local-param contain the remote and local tags of 344 the call to be traced as defined in [RFC4538]. 346 The timestamp-param contains the value of the time the UA determines 347 it received the session initiation request of the call requested to 348 be traced. 350 5.2. Procedures at an Untrusted User Agent Client (UAC) 352 The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial 353 INVITE message for a customer-originated-trace request. The UAC MUST 354 use a SIP URI in the Request-URI with userinfo set to "call-trace" 355 and hostport identifying the call tracing entity for the untrusted 356 UA. The UAC MUST insert the callid-param, remote param, local param 357 and timestamp if known to the UAC. 359 5.3. Procedures at a Trusted User Agent Client (UAC) 361 A trusted UAC performs the customer-originated-trace in a manner 362 similar to the trusted UAS, described below. A trusted UAC MUST NOT 363 include this header in any request. 365 5.4. Procedures at an Untrusted User Agent Server (UAS) 367 This header MUST NOT appear in any response sent by a UAS. 369 5.5. Procedures at a Trusted User Agent Server (UAS) 371 If the P-DCS-Trace-Party-ID header is present in the initial INVITE 372 request from a UAC, and the Request-URI of the INVITE has userinfo 373 set to "call-trace" and hostport set to the UAS, the UAS MUST perform 374 the service-provider-specific functions of recording and reporting 375 the caller identity for law enforcement action. The UAS then MUST 376 redirect the call, via a 3xx response, to either an announcement 377 server or to the service-provider's business office to collect 378 further information about the complaint. 380 This header MUST NOT appear in any response sent by a UAS. 382 5.6. Procedures at Proxy 384 Two sets of proxy procedures are defined: (1) the procedures at an 385 originating proxy, and (2) the procedures at a terminating proxy. 386 The originating proxy is a proxy that received the INVITE request 387 from a non-trusted endpoint. 389 The terminating proxy is a proxy that sends the INVITE request to a 390 non-trusted endpoint. 392 A proxy that both receives the INVITE request from an untrusted 393 endpoint, and sends the INVITE request to an untrusted endpoint, 394 performs both sets of procedures. 396 5.6.1. Procedures at Originating Proxy 398 If the P-DCS-Trace-Party-ID header is present in the initial INVITE 399 request from the UAC, and the Request-URI of the INVITE has userinfo 400 other than "call-trace" and hostport set to other than a potentially 401 provisioned call tracing entity, then the Proxy MAY reject the 402 request, or MAY remove the P-DCS-Trace-Party-ID header from the 403 request. If the header is present in a valid request, and contains a 404 private-URL that identifies the Proxy in the hostport, then the 405 Originating Proxy SHOULD replace the private-URL with its original 406 contents (i.e., the verified identity of the caller of the session 407 that is being traced). 409 5.6.2. Procedures at Terminating Proxy 411 This header MUST NOT appear in any request or response sent by a 412 terminating proxy to an untrusted endpoint. 414 6. P-DCS-OSPS 416 Some calls have special call processing requirements that may not be 417 satisfied by normal user agent call processing. For example, when a 418 user is engaged in a call and another call arrives, such a call might 419 be rejected with a busy indication. However, some PSTN operator 420 services require special call processing. In particular, the Busy 421 Line Verification (BLV) and Emergency Interrupt (EI) services 422 initiated by an operator from an Operator Services Position System 423 (OSPS) on the PSTN network have such a need. Similarly, emergency 424 calls to a 9-1-1 Public Service Access Point (PSAP) may result in 425 trunk signaling causing operator ringback using a howling tone or 426 sustained ring on the originating line (country-specific variations 427 may exist). 429 In order to inform the SIP user agent that special treatment should 430 be given to a call, we use a new P-DCS-OSPS header field, which may 431 be set to a value indicating when a special type of call processing 432 is requested. We define three values in this header, namely "BLV" 433 for busy line verification, "EI" for emergency interrupt, and "RING" 434 for operator ringback (e.g., howling/sustained tone ring in the US). 436 If the user agent decides to honor such a request, the response of 437 the user agent to an INVITE with either "BLV" or "EI" will not be a 438 busy indication. Since "EI" and "RING" only occur on established 439 dialogs, they may also appear in UPDATE requests. 441 6.1. Syntax 443 The ABNF description of the P-DCS-OSPS header is as follows (some 444 terms used in this ABNF are defined in [RFC3261]): 446 P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag 447 OSPS-Tag = "BLV" / "EI" / "RING" / token 449 This document adds the following entry to Table 2 of [RFC3261]: 451 Header field where proxy ACK BYE CAN INV OPT REG 452 ------------ ----- ----- --- --- --- --- --- --- 453 P-DCS-OSPS R dr - - - o - - 454 SUB NOT REF INF UPD PRA 455 --- --- --- --- --- --- 456 - - - - o - 458 The OSPS-Tag value of "token" is defined for extensibility, and is 459 reserved for future use. 461 6.2. Procedures at an Untrusted User Agent Client (UAC) 463 The P-DCS-OSPS header MUST NOT be sent in a request from an untrusted 464 UAC. 466 6.3. Procedures at a Trusted User Agent Client (UAC) 468 This header is typically only inserted by a Media Gateway Controller 469 [DCSARCH] that is controlling a Media Gateway with special trunks to 470 a PSTN OSPS system or PSAP. This trunk group is usually referred to 471 as a BLV-trunk group and employs special signaling procedures that 472 prevent inadvertent use. Calls originating at the PSTN OSPS system 473 are sent over this trunk group, and result in an INVITE request with 474 the P- DCS-OSPS header. 476 This header MAY be sent in an INVITE request, and MUST NOT appear in 477 any message other than those listed below. 479 OSPS-Tag value "BLV" MUST NOT appear in any request or response other 480 than an initial INVITE request establishing a new dialog. 482 OSPS-Tag value "EI" MUST NOT appear in any request or response other 483 than (1) a subsequent INVITE within a pre-existing dialog established 484 with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a 485 pre-existing dialog established with the OSPS-Tag value of "BLV". 487 OSPS-Tag value "RING" MUST NOT appear in any request or response 488 other than (1) a subsequent INVITE within a pre-existing dialog 489 established by a UAC to an operator or PSAP, or (2) an UPDATE request 490 within a pre-existing dialog established by a UAC to an operator or 491 PSAP. 493 6.4. Procedures at an Untrusted User Agent Server (UAS) 495 If the UAS receives an INVITE request with an OSPS-Tag of "BLV", 496 dialog identification that matches an existing dialog, and the 497 existing call was not established with the OSPS-Tag, it MUST reject 498 the request with a 403-Forbidden error code. 500 If the UAS receives an INVITE/UPDATE request with an OSPS-Tag value 501 of "EI" or "RING", with dialog identification that does not match an 502 existing dialog, it MUST reject the request with a 403-Forbidden 503 response code. 505 If the UAS receives an INVITE that contains an OSPS-Tag value of 506 "BLV" and is not willing to cooperate in offering this service, it 507 MUST reject the request with a 403-Forbidden response code. 509 The UAS SHOULD NOT reject an INVITE with a BLV OSPS-Tag due to a busy 510 condition. The UAS MUST NOT respond with a 3xx-Redirect response 511 code to an INVITE with a BLV OSPS-Tag. The UAS SHOULD NOT alert the 512 user of the incoming call attempt if the BLV OSPS-Tag is present in 513 the INVITE. 515 If an INVITE with OSPS-Tag of "BLV" is accepted (e.g., meeting all 516 QoS pre-conditions, etc.), the UAS MUST send an audio stream on this 517 connection to the address and port given in the SDP of the INVITE. 518 The UAS MAY perform a mixing operation between the two ends of an 519 existing active call and send the resulting media stream to the 520 address and port indicated. Alternatively, the UAS MAY send a copy 521 of the local voice stream, and (if no activity on the local voice 522 stream) send a copy of the received voice stream of an existing call. 523 If the state of the UAS is idle, the UAS SHOULD send a stream of 524 silence packets to OSPS. If the state of the UAS is ringing or 525 ringback, the UAS SHOULD send a ringback stream to OSPS. 527 If an INVITE/UPDATE with OSPS-Tag of "EI" is accepted, the UAS MUST 528 enable communication between the UAC and the local user. The UAS MAY 529 put any existing call on hold, or initiate an ad-hoc conference. 531 If an INVITE/UPDATE with OSPS-Tag of "RING" is accepted, the UAS MUST 532 perform operator ringback in accordance with local procedures, e.g., 533 generate a 3-second howling tone or a sustained ring, depending on 534 the state of the user equipment. 536 6.5. Procedures at a Trusted User Agent Server (UAS) 538 The procedures at a trusted UAS MUST be identical to those described 539 in 6.4. 541 6.6. Procedures at Proxy 543 In the DCS architecture, the OSPS is considered a trusted UAC. If a 544 proxy receives a P-DCS-OSPS header in a request from an untrusted 545 source, it MUST either remove the header or reject the request with a 546 403-Forbidden response. 548 A proxy that implements a call-forwarding service MUST NOT respond to 549 an INVITE request with a 3xx response, if the request contained the 550 P-DCS-OSPS header. 552 7. P-DCS-BILLING-INFO 554 There are many billing models used in deriving revenue from telephony 555 services today. Charging for telephony services is tightly coupled 556 to the use of network resources. It is outside the scope of this 557 document to discuss the details of these numerous and varying 558 methods. 560 Proxies have access to subscriber information and act as policy 561 decision points and trusted intermediaries along the call signaling 562 path. Edge routers provide the network connection and resource 563 policy enforcement mechanism and also capture and report network 564 connection and resource usage information. Edge routers need to be 565 given billing information that can be logged with Record Keeping or 566 Billing servers. The proxy, as a central point of coordination 567 between call signaling and resource management, can provide this 568 information based on the authenticated identity of the calling and 569 called parties. Since there is a trust relationship among proxies, 570 they can be relied upon to exchange trusted billing information 571 pertaining to the parties involved in a call. 573 For Usage Accounting records, it is necessary to have an identifier 574 that can be associated with all the event records produced for the 575 call. The SIP Call-ID header field cannot be used as such an 576 identifier since it is selected by the originating user agent, and 577 may not be unique among all past calls as well as current calls. 578 Further, since this identifier is to be used by the service provider, 579 it should be chosen in a manner and in a format that meets the 580 service provider's needs. 582 Billing information may not necessarily be unique for each user 583 (consider the case of calls from an office all billed to the same 584 account). Billing information may not necessarily be identical for 585 all calls made by a single user (consider prepaid calls, credit card 586 calls, collect calls, etc). It is therefore necessary to carry 587 billing information separate from the calling and called party 588 identification. Furthermore, some billing models call for split- 589 charging where multiple entities are billed for portions of the call. 591 The addition of a SIP General Header Field allows for the capture of 592 billing information and billing identification for the duration of 593 the call. 595 It is the intent that the billing extensions would only appear on 596 trusted network segments, and MAY be inserted by a proxy or trusted 597 UA in INVITE requests in a trusted network segment, and removed 598 before leaving trusted network segments. The P-DCS-Billing-Info 599 header extension is used only on requests and responses between 600 proxies and trusted User Agents. It is never sent to, nor sent by, 601 an untrusted UA. 603 7.1. Syntax 605 The DCS-Billing-Info header is defined by the following ABNF (some 606 terms used in this ABNF are defined in [RFC3261]): 608 P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON 609 Billing-Correlation-ID "/" FEID 610 *(SEMI Billing-Info-param) 611 Billing-Correlation-ID = 1*48(HEXDIG) 612 FEID = 1*16(HEXDIG) "@" host 613 Billing-Info-param = RKS-Group-ID-param / Charge-param / 614 Calling-param / Called-param / 615 Routing-param / Loc-Routing-param / 616 JIP-param / generic-param 617 RKS-Group-ID-param = "rksgroup" EQUAL RKS-Group-ID 618 RKS-Group-ID = token 619 Charge-param = "charge" EQUAL Acct-Charge-URI 620 Acct-Charge-URI = LDQUOT addr-spec RDQUOT 621 Calling-param = "calling" EQUAL Acct-Calling-URI 622 Acct-Calling-URI = LDQUOT addr-spec RDQUOT 623 Called-param = "called" EQUAL Acct-Called-URI 624 Acct-Called-URI = LDQUOT addr-spec RDQUOT 625 Routing-param = "routing" EQUAL Acct-Routing-URI 626 Acct-Routing-URI = LDQUOT addr-spec RDQUOT 627 Loc-Routing-param = "locroute" EQUAL Acct-Loc-Routing-URI 628 Acct-Loc-Routing-URI = LDQUOT addr-spec RDQUOT 629 JIP-param = "jip" EQUAL jip 630 jip = LDQUOT 1*phonedigit-hex jip-context RDQUOT 631 jip-context = ";jip-context=" jip-descriptor 632 jip-descriptor = global-hex-digits 633 global-hex-digits = "+" 1*3 (phonedigit) *phonedigit-hex 634 phonedigit = DIGIT / [ visual-separator ] 635 phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] 636 visual-separator = "-" / "." / "(" / ")" 638 This document adds the following entry to Table 2 of [RFC3261]: 640 Header field where proxy ACK BYE CAN INV OPT REG 641 ------------ ----- ----- --- --- --- --- --- --- 642 P-DCS-Billing-Info admr - - - o - - 644 SUB NOT REF INF UPD PRA 645 --- --- --- --- --- --- 646 - - - - - - 648 The P-DCS-Billing-Info extension contains an identifier that can be 649 used by an event recorder to associate multiple usage records, 650 possibly from different sources, with a billable account. It further 651 contains the subscriber account information, and other information 652 necessary for accurate billing of the service. This header is only 653 used between proxies and trusted User Agents. 655 The Billing-Correlation-ID is specified in [PCEM] as a 24-byte binary 656 structure, containing 4 bytes of NTP timestamp, 8 bytes of the unique 657 identifier of the network element that generated the ID, 8 bytes 658 giving the time zone, and 4 bytes of monotonically increasing 659 sequence number at that network element. This identifier is chosen 660 to be globally unique within the system for a window of several 661 months. This MUST be encoded in the P-DCS-Billing-Info header as a 662 hexadecimal string of up to 48 characters. Leading zeroes MAY be 663 suppressed. 665 The Financial-Entity-ID (FEID) is specified in [PCEM] as an 8-byte 666 structure, containing the financial identifier for that domain, 667 followed by a domain name. FEID can be associated with a type of 668 service and could be assigned to multiple domains by the same 669 provider. A domain could contain multiple assigned FEIDs. This 8- 670 byte structure MUST be encoded in the P-DCS-Billing-Info header as a 671 hexadecimal string of up to 16 characters. Trailing zeroes MAY be 672 suppressed. "Host" contains the domain name. 674 The RKS-Group-ID specifies a record keeping server (or group of 675 cooperating servers) for event messages relating to this call. It is 676 used to control certain optimizations of procedures when multiple 677 event message streams are being sent to the same Record Keeping 678 Server. 680 Additional parameters contain the information needed for generation 681 of event message records. Acct-Charge-URI, Acct-Calling-URI, Acct- 682 Called-URI, Acct-Routing-URI, and Acct-Location-Routing-URI are each 683 defined as URLs; they should all contain tel: URLs with E.164 684 formatted addresses. These fields are further defined in [PCEM] 685 under the element identifiers "Charge_Number" (element ID 16), 686 "Calling_Party_Number" (element ID 4), "Called_Party_Number" (element 687 ID 5), "Routing Number" (element ID 25), and 688 "Location_Routing_Number" (element ID 22). 690 The JIP-param contains the calling jurisdiction information, or 691 numbering plan area, of the network in which the call originated. 692 The field is further defined in [PCEM] under the element identifier 693 "Jurisdiction_Information_Parameter" (element ID 82). 695 7.2. Procedures at an Untrusted User Agent Client (UAC) 697 This header is never sent to an untrusted UAC, and is never sent by 698 an untrusted UAC. 700 7.3. Procedures at a Trusted User Agent Client (UAC) 702 The UAC MUST generate the Billing-Correlation-ID for the call, and 703 insert it into the P-DCS-Billing-Info header in the initial INVITE 704 message sent to the terminating proxy, along with the charging 705 information for the call. The UAC MUST include its FEID, and the 706 RKS-Group-ID for the Record-Keeping-Server being used by the UAC. If 707 the UAC performed a Local Number Portability (LNP) query, it MUST 708 include the Routing Number and Location Routing Number returned by 709 the query. If available to the UAC, the UAC MUST include the JIP- 710 param. 712 If the response to the initial INVITE is a 3xx-Redirect, the UAC 713 generates a new initial INVITE request to the destination specified 714 in the Contact: header, as per standard SIP. If a UAC receives a 715 3xx-Redirect response to an initial INVITE, the new INVITE generated 716 by the UAC MUST contain the P-DCS-Billing-Info header from the 3xx- 717 Redirect response. If the UAC is acting as a B2BUA, instead of 718 generating a new INVITE it MAY generate a private-URL and place it in 719 the Contact header of a 3xx-Redirect response sent to the originating 720 endpoint. This private-URL MUST contain (or contain a pointer to) 721 the P-DCS-Billing-Info value, which indicates the charging 722 arrangement for the new call, and an expiration time very shortly in 723 the future, to limit the ability of the originator to re-use this 724 private-URL for multiple calls. 726 A UAC that includes a Refer-to header in a REFER request MUST include 727 a P-DCS-Billing-Info header in the Refer-to's URL. This P-DCS- 728 Billing-Info header MUST include the accounting information of the 729 initiator of the REFER. 731 7.4. Procedures at an Untrusted User Agent Server (UAS) 733 This header is never sent to an untrusted UAS, and is never sent by 734 an untrusted UAS. 736 7.5. Procedures at a Trusted User Agent Server (UAS) 738 The UAS MUST include a P-DCS-Billing-Info header in the first 739 reliable 1xx (except 100) or 2xx response to an initial INVITE 740 message. This P-DCS-Billing-Info header MUST include the Billing- 741 Correlation-ID generated by the UAS, the FEID of the UAS, and the 742 RKS-Group-ID of the Record-Keeping-Server being used by the UAS. The 743 UAS MAY change the values of Acct-Charge-URI if it wishes to override 744 the billing information that was present in the INVITE (e.g., for a 745 toll-free call). The decision to do this and the contents of the new 746 Acct-Charge-URI MUST be determined by service provider policy 747 provisioned in the UAS. If the UAS performed a LNP query, it MUST 748 include the Routing Number and Location Routing Number returned by 749 the query. 751 The UAS MUST add a P-DCS-Billing-Info header to a 3xx-redirect 752 response to an initial INVITE, giving the accounting information for 753 the call forwarder, for the call segment from the destination to the 754 forwarded-to destination. 756 7.6. Procedures at Proxy 758 Three sets of proxy procedures are defined: (1) the procedures at an 759 originating proxy, (2) the procedures at a terminating proxy, and (3) 760 the procedures at a tandem proxy. 762 The originating proxy is a proxy that received the INVITE request 763 from a non-trusted endpoint. 765 The terminating proxy is a proxy that sends the INVITE request to a 766 non-trusted endpoint. 768 A proxy that is neither an originating proxy, nor a terminating 769 proxy, is a tandem proxy. 771 For purposes of mid-call changes, such as call transfers, the proxy 772 that receives the request from a non-trusted endpoint is considered 773 the initiating proxy; the proxy that sends the request to a non- 774 trusted endpoint is considered the recipient proxy. Procedures for 775 the initiating proxy are included below with those for originating 776 proxies, while procedures for the recipient proxy are included with 777 those for terminating proxies. 779 A proxy that both receives the INVITE request from an untrusted 780 endpoint, and sends the INVITE request to a non-trusted endpoint, 781 performs both sets of procedures. 783 7.6.1. Procedures at Originating Proxy 785 The originating proxy MUST generate the Billing-Correlation-ID for 786 the call, and insert it into the P-DCS-Billing-Info header in the 787 initial INVITE message sent to the terminating proxy, along with the 788 charging information for the call. The originating proxy MUST 789 include its FEID, and the RKS-Group-ID for the Record-Keeping-Server 790 being used by the originating proxy. If the originating proxy 791 performed a LNP query, it MUST include the Routing Number and 792 Location Routing Number returned by the query. Any P-DCS-Billing- 793 Info header present from an untrusted UA MUST be removed. 795 If the Request-URI contains a private-URL, and the decoded username 796 contains billing information, the originating proxy MUST generate a 797 P-DCS-Billing-Info header with that decrypted information. 798 Otherwise, the originating proxy MUST determine the accounting 799 information for the call originator, and insert a P-DCS-Billing-Info 800 header including that information. 802 If the response to the initial INVITE is a 3xx-Redirect, received 803 prior to a 18x, the originating proxy generates a new initial INVITE 804 request to the destination specified in the Contact: header, as per 805 standard SIP. If an originating proxy receives a 3xx-Redirect 806 response to an initial INVITE prior to a 18x response, the INVITE 807 generated by the proxy MUST contain the P-DCS-Billing-Info header 808 from the 3xx-Redirect response. 810 If the response to the initial INVITE is a 3xx-Redirect, received 811 after a 18x, the originating proxy generates a private-URL and places 812 it in the Contact header of a 3xx-Redirect response sent to the 813 originating endpoint. This private-URL MUST contain (or contain a 814 pointer to) the P-DCS-Billing-Info value, which indicate the charging 815 arrangement for the new call, and an expiration time very shortly in 816 the future, to limit the ability of the originator to re-use this 817 private-URL for multiple calls. 819 An originating proxy that processes a REFER request from an untrusted 820 UA MUST include a P-DCS-Billing-Info header in the Refer-to's URL. 821 This P-DCS-Billing-Info header MUST include the accounting 822 information of the initiator. 824 7.6.2. Procedures at Terminating Proxy 826 The terminating proxy MUST NOT send the P-DCS-Billing-Info header to 827 an untrusted destination. 829 The terminating proxy MUST include a P-DCS-Billing-Info header in the 830 first reliable 1xx (except 100) or 2xx response to an initial INVITE 831 message. This P-DCS-Billing-Info header MUST include the Billing- 832 Correlation-ID generated by the terminating proxy, the FEID of the 833 terminating proxy, and the RKS-Group-ID of the Record-Keeping-Server 834 being used by the terminating proxy. The terminating proxy MAY 835 change the values of Acct-Charge-URI if it wishes to override the 836 billing information that was present in the INVITE (e.g., for a toll- 837 free call). The decision to do this and the contents of the 838 resulting P-DCS-Billing-Info header MUST be determined by service 839 provider policy provisioned in the terminating proxy. If the 840 terminating proxy performed a LNP query, it MUST include the Routing 841 Number and Location Routing Number returned by the query. 843 The terminating proxy MUST add P-DCS-Billing-Info headers to a 3xx- 844 redirect response to an initial INVITE, giving the accounting 845 information for the call forwarder, for the call segment from the 846 destination to the forwarded-to destination. 848 A proxy receiving a mid-call REFER request that includes a Refer-to 849 header generates a private-URL and places it in the Refer-to header 850 sent to the endpoint. This private-URL MUST contain the P-DCS- 851 Billing-Info value, which indicates the charging arrangement for the 852 new call, and an expiration time very shortly in the future, to limit 853 the ability of the endpoint to re-use this private-URL for multiple 854 calls. 856 7.6.3. Procedures at Tandem Proxy 858 If the tandem proxy performed a LNP query, it MUST insert the Routing 859 Number and Location Routing Number returned by the query into the P- 860 DCS-Billing-Info header in the first reliable 1xx/2xx/3xx (except 861 100) response. 863 8. P-DCS-LAES and P-DCS-REDIRECT 865 NOTE: According to RFC 2804 [RFC2804], the IETF supports 866 documentation of lawful intercept technology if it is necessary to 867 develop it. The following section provides such documentation. The 868 [RFC2119] language, as stated above, describes the requirements of 869 the specification only if implemented, and strictly within the 870 applicability domain described above. See RFC 2804 for description 871 of issues regarding privacy, security, and complexity in relation to 872 this technology. 874 The P-DCS-LAES extension contains the information needed to support 875 Lawfully Authorized Electronic Surveillance. This header contains 876 the address and port of an Electronic Surveillance Delivery Function 877 for delivery of a duplicate stream of event messages related to this 878 call. The header may also contain an additional address and port for 879 delivery of call content. Security key information is included to 880 enable pairs of Delivery Functions to securely exchange surveillance 881 information. This header is only used between proxies and trusted 882 User Agents. 884 The P-DCS-Redirect extension contains call identifying information 885 needed to support the requirements of Lawfully Authorized Electronic 886 Surveillance of redirected calls. This header is only used between 887 proxies and trusted User Agents. 889 Use of P-DCS-LAES and P-DCS-Redirect is controlled by a combination 890 of legislation, regulation, and court orders, which MUST be followed. 891 In certain cases inclusion of these headers will be mandated, and 892 therefore MUST be present in the requests and responses indicated. 893 In other cases inclusion of these headers will be forbidden, and 894 therefore MUST NOT be present in the request and responses indicated. 895 In the sub-sections that follow, use of "SHOULD" is intended to 896 capture these conflicting situations, e.g., a P-DCS-LAES header 897 SHOULD be included in an initial INVITE means either that it MUST be 898 included or that it MUST NOT be included, based on the applicable 899 court orders. 901 8.1. Syntax 903 The formats of the P-DCS-LAES and P-DCS-Redirect headers are given by 904 the following ABNF (some terms used in this ABNF are defined in 905 [RFC3261] and [RFC4234]): 907 P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig 908 *(SEMI Laes-param) 909 Laes-sig = hostport 910 Laes-param = Laes-content / Laes-cccid 911 Laes-bcid / generic-param 912 Laes-content = "content" EQUAL hostport 914 Laes-bcid = "bcid" EQUAL 1*48 (HEXDIG) 915 Laes-cccid = "cccid" EQUAL 1*8 (HEXDIG) 916 P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID 917 *(SEMI redir-params) 918 Called-ID = LDQUOT addr-spec RDQUOT 919 redir-params = redir-uri-param / redir-count-param / 920 generic-param 921 redir-uri-param = "redirector-uri" EQUAL Redirector 922 Redirector = LDQUOT addr-spec RDQUOT 923 redir-count-param = "count" EQUAL Redir-count 924 Redir-count = 1*DIGIT 926 This document adds the following entry to Table 2 of [RFC3261]: 927 Header field where proxy ACK BYE CAN INV OPT REG 928 ------------ ----- ----- --- --- --- --- --- --- 929 P-DCS-LAES adr - - - o - - 930 P-DCS-Redirect adr - - - o - - 932 SUB NOT REF INF UPD PRA 933 --- --- --- --- --- --- 934 - - - - - - 935 - - - - - - 937 The values of Laes-sig and Laes-content are addresses of the 938 Electronic Surveillance Delivery Function, and used as the 939 destination address for call-identifying information and call- 940 content, respectively. [PCSEC]. Laes-bcid contains a correlation ID 941 that is used to link a sequence of intercepted call processing events 942 related to a single call. Laes-cccid contains an identifier of the 943 intercepted call content. The Laes-bcid field MUST always be 944 present. The Laes-cccid field MUST be present when the Laes-content 945 field is present. 947 The P-DCS-Redirect header contains redirection information. The 948 redir-uri-param indicates the original destination requested by the 949 user (e.g., dialed number), the Redirector indicates the new 950 destination, and the Redir-count indicates the number of redirections 951 that have occurred. 953 8.2. Procedures at an Untrusted User Agent Client (UAC) 955 This header MUST NOT be sent to an untrusted UAC, and MUST NOT be 956 sent by an untrusted UAC. 958 8.3. Procedures at a Trusted User Agent Client (UAC) 960 The UAC checks for an outstanding lawfully authorized surveillance 961 order for the originating subscriber, and, if present, includes this 962 information in the Authorization for Quality of Service [PCDQOS] or 963 signals this information to the device performing the intercept 964 (e.g., a Media Gateway). 966 If the P-DCS-LAES header is present in the first reliable 1xx (except 967 100), 2xx or 3xx response (indicating surveillance is required on the 968 terminating subscriber, but that the terminating equipment is unable 969 to perform that function), the UAC MUST include this information in 970 the Authorization for Quality of Service, or MUST signal this 971 information to the device performing the intercept (e.g., a Media 972 Gateway). 974 If a 3xx-Redirect response is received to the initial INVITE request, 975 and if a P-DCS-LAES header is present in the 3xx response, the UAC 976 SHOULD include that header unchanged in the reissued INVITE. The UAC 977 SHOULD also include a P-DCS-Redirect header containing the original 978 dialed number, the new destination number, and the number of 979 redirections that have occurred. Although it is technically possible 980 for the originating equipment to perform this surveillance (or add to 981 its existing surveillance of the call), the design of the 982 surveillance system has the terminating equipment performing the 983 surveillance for all the intermediate forwardings. 985 A UAC that includes a Refer-to header in a REFER request, when the 986 originating subscriber has an outstanding lawfully authorized 987 surveillance order, SHOULD include a P-DCS-LAES header attached to 988 the Refer-to. The P-DCS-LAES header SHOULD include the Laes-bcid 989 parameter set to a value that uniquely identifies the call, SHOULD 990 include the address and port of the local Electronic Surveillance 991 Delivery Function for a copy of the call's event messages, SHOULD 992 include the address and port of the local Electronic Surveillance 993 Delivery Function for the copy of call content if call content is to 994 be intercepted, and SHOULD include the Laes-cccid parameter set to a 995 value that uniquely identifies the intercepted audio stream if call 996 content is to be intercepted. 998 The trusted UAC MUST NOT send the P-DCS-LAES and P-DCS-Redirect 999 headers to an untrusted entity. 1001 8.4. Procedures at an Untrusted User Agent Server (UAS) 1003 This header MUST NOT be sent to an untrusted UAS, and MUST NOT be 1004 sent by an untrusted UAS. 1006 8.5. Procedures at a Trusted User Agent Server (UAS) 1008 The UAS checks for an outstanding lawfully authorized surveillance 1009 order for the terminating subscriber, or presence of the P-DCS-LAES 1010 header in the INVITE request. If either is present, the UAS includes 1011 this information in the authorization for Quality of Service 1012 [PCDQOS]. 1014 If the terminating equipment is unable to perform the required 1015 surveillance (e.g., if the destination is a voicemail server), the 1016 UAS SHOULD include a P-DCS-LAES header in the first reliable non-100 1017 response requesting the originating proxy to perform the 1018 surveillance. The P-DCS-LAES header SHOULD include the Laes-bcid 1019 parameter to a value that uniquely identifies the call, SHOULD 1020 include the address and port of the local Electronic Surveillance 1021 Delivery Function for a copy of the call's event messages, SHOULD 1022 include the address and port of the local Electronic Surveillance 1023 Delivery Function for the copy of call content if call content is to 1024 be intercepted, and SHOULD include the Laes-cccid parameter set to a 1025 value that uniquely identifies the intercepted audio stream if call 1026 content is to be intercepted. 1028 If the response to the initial INVITE request is a 3xx-Redirect 1029 response, and there is an outstanding lawfully authorized 1030 surveillance order for the terminating subscriber, the UAS SHOULD 1031 include a P-DCS-LAES header in the 3xx-Redirect response, with 1032 contents as described above. 1034 The trusted UAS MUST NOT send the P-DCS-LAES and P-DCS-Redirect 1035 headers to an untrusted entity. 1037 8.6. Procedures at Proxy 1039 Two sets of proxy procedures are defined: (1) the procedures at an 1040 originating proxy, and (2) the procedures at a terminating proxy. 1041 The originating proxy is a proxy that received the INVITE request 1042 from a non-trusted endpoint. 1044 The terminating proxy is a proxy that sends the INVITE request to a 1045 non-trusted endpoint. 1047 For purposes of mid-call changes, such as call transfers, the proxy 1048 that receives the request from a non-trusted endpoint is considered 1049 the initiating proxy; the proxy that sends the request to a non- 1050 trusted endpoint is considered the recipient proxy. Procedures for 1051 the initiating proxy are included below with those for originating 1052 proxies, while procedures for the recipient proxy are included with 1053 those for terminating proxies. 1055 A proxy that both receives the INVITE request from an untrusted 1056 endpoint, and sends the INVITE request to a non-trusted endpoint, 1057 MUST NOT generate P-DCS-LAES nor P-DCS-Redirect headers. 1059 A proxy that is neither an originating proxy nor a terminating proxy 1060 SHOULD pass the P-DCS-Laes and P-DCS-Redirect headers in requests and 1061 responses. 1063 8.6.1. Procedures at Originating Proxy 1065 The Originating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect 1066 headers in requests or responses to or from an untrusted proxy or 1067 untrusted UA. 1069 The originating proxy checks for an outstanding lawfully authorized 1070 surveillance order for the originating subscriber, and, if present, 1071 includes this information in the Authorization for Quality of Service 1072 [PCDQOS] or signals this information to the device performing the 1073 intercept (e.g., a Media Gateway). 1075 If the P-DCS-LAES header is present in the first reliable 1xx (except 1076 100), 2xx or 3xx response (indicating surveillance is required on the 1077 terminating subscriber, but that the terminating equipment is unable 1078 to perform that function), the originating proxy MUST include this 1079 information in the Authorization for Quality of Service, or MUST 1080 signal this information to the device performing the intercept (e.g., 1081 a Media Gateway). 1083 If the Request-URI in an initial INVITE request contains a private- 1084 URL, the originating proxy MUST decrypt the userinfo information to 1085 find the real destination for the call, and other special processing 1086 information. If electronic surveillance information is contained in 1087 the decrypted userinfo, the originating proxy SHOULD generate a P- 1088 DCS-LAES header with the surveillance information. 1090 If a 3xx-Redirect response is received to the initial INVITE request 1091 prior to a 18x, and if a P-DCS-LAES header is present in the 3xx 1092 response, the originating proxy SHOULD include that header unchanged 1093 in the reissued INVITE. The originating proxy SHOULD also include a 1094 P-DCS-Redirect header containing the original dialed number, the new 1095 destination number, and the number of redirections that have 1096 occurred. 1098 If a 3xx-Redirect response is received to the initial INVITE request 1099 after a 18x, the originating proxy generates a private-URL and places 1100 it in the Contact header of a 3xx-Redirect response sent to the 1101 originating endpoint. If a P-DCS-LAES header is present in the 3xx 1102 response, this private-URL MUST contain (1) the electronic 1103 surveillance information from the 3xx-Redirect response, (2) the 1104 original destination number, (3) the identity of the redirecting 1105 party, and (4) the number of redirections of this call. 1107 An originating proxy that processes a REFER request [RFC3515] from an 1108 untrusted UA, when the originating subscriber has an outstanding 1109 lawfully authorized surveillance order, becomes a B2BUA for that 1110 request. It SHOULD reissue the request with a P-DCS-LAES header 1111 added to the Refer-to's URL. The P-DCS-LAES header SHOULD include 1112 (1) the Laes-bcid parameter set to a value that uniquely identifies 1113 the call, (2) the address and port of the local Electronic 1114 Surveillance Delivery Function for a copy of the call's event 1115 messages, (3) the address and port of the local Electronic 1116 Surveillance Delivery Function for the copy of call content if call 1117 content is to be intercepted, and (4) SHOULD include the Laes-cccid 1118 parameter set to a value that uniquely identifies the intercepted 1119 audio stream if call content is to be intercepted. 1121 An initiating proxy that sends a mid-call REFER request including a 1122 Refer-to header, when the initiating subscriber has an outstanding 1123 lawfully authorized surveillance order, SHOULD include a P-DCS-LAES 1124 header in the Refer-to's URL. 1126 The originating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect 1127 headers to an untrusted entity. 1129 8.6.2. Procedures at Terminating Proxy 1131 The Terminating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect 1132 headers in requests or responses to or from an untrusted proxy or UA. 1134 The terminating proxy checks for an outstanding lawfully authorized 1135 surveillance order for the terminating subscriber. If present, the 1136 terminating proxy includes this information in the authorization for 1137 Quality of Service [PCDQOS]. 1139 The terminating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect 1140 headers to an untrusted entity, either as headers in the request or 1141 response, or as headers attached to URIs in the request or response. 1143 If the terminating equipment is unable to perform the required 1144 surveillance (e.g., if the destination is a voicemail server), the 1145 terminating proxy SHOULD include a P-DCS-LAES header in the first 1146 reliable 1xx/2xx/3xx (except 100) response requesting the originating 1147 proxy to perform the surveillance. The P-DCS-LAES header SHOULD 1148 include the Laes-bcid parameter set to a value that uniquely 1149 identifies the call, SHOULD include the address and port of the local 1150 Electronic Surveillance Delivery Function for a copy of the call's 1151 event messages, SHOULD include the address and port of the local 1152 Electronic Surveillance Delivery Function for the copy of call 1153 content if call content is to be intercepted, and SHOULD include the 1154 Laes-cccid parameter set to a value that uniquely identifies the 1155 audio stream if call content is to be intercepted. 1157 If the response to the initial INVITE request is a 3xx-Redirect 1158 response, and there is an outstanding lawfully authorized 1159 surveillance order for the terminating subscriber, the terminating 1160 proxy SHOULD include a P-DCS-LAES header in the 3xx-Redirect 1161 response, with contents as described above. 1163 A proxy receiving a mid-call REFER request [RFC3515] that includes a 1164 Refer-to header with a P-DCS-LAES header attached becomes a B2BUA for 1165 this request. It MUST generate a private-URL and place it in the 1166 Refer-to header sent to the endpoint. This private-URL MUST contain 1167 the P-DCS-LAES information from the attached header. 1169 9. Security Considerations 1171 QoS gate coordination, billing information, and electronic 1172 surveillance information are all considered to be sensitive 1173 information that MUST be protected from eavesdropping and furthermore 1174 require integrity checking. It is therefore necessary that the 1175 trusted UAs and proxies take precautions to protect this information 1176 from eavesdropping and tampering. Use of IPsec or TLS between 1177 Proxies is REQUIRED. A minimum mandatory-to-implement IPsec 1178 configuration for the DCS architecture is given by [PCSEC]. Also 1179 REQUIRED is mutual authentication (1) between Proxies and (2) between 1180 trusted UAs and Proxies, both of which MAY be implemented with 1181 administratively pre-shared keys, or through consultation with 1182 another trusted third party. If IPsec is to be used, the 1183 specification of the security policies and procedures of the 1184 administrative domain where these headers are applicable (and all 1185 connections between administrative domains in the federation) MUST 1186 define an interoperable set of options. 1188 10. IANA Considerations 1190 This document defines a number of SIP extension headers, which have 1191 been included in the registry of SIP headers defined in [RFC3261]. 1192 Registration information for new headers is as follows: 1194 Header Field Name: P-DCS-Trace-Party-ID 1195 RFC Number: 3603 1196 Compact Form: none 1197 Header Field Name: P-DCS-OSPS 1198 RFC Number: 3603 1199 Compact Form: none 1200 Header Field Name: P-DCS-Billing-Info 1201 RFC Number: 3603 1202 Compact Form: none 1203 Header Field Name: P-DCS-LAES 1204 RFC Number: 3603 1205 Compact Form: none 1206 Header Field Name: P-DCS-Redirect 1207 RFC Number: 3603 1208 Compact Form: none 1210 11. Change Log 1212 11.1. Changes in -03 1214 o Correction is made to Callid, which was mispelled as Called in the 1215 trace party ID section. 1217 11.2. Changes in -02 1219 o Correction is made to the cccid parameter length within the P-DCS- 1220 LAES header 1222 o Text referring to key token is deleted 1224 11.3. Changes in -01 1226 o P-DCS-Trace-Party-ID header now mandates inclusion of parameters 1227 when available 1229 o P-DCS-Billing-Info header now mandates inclusion of JIP-param when 1230 available 1232 o P-DCS-LAES header now requires inclusion of the Laes-bcid 1233 parameter when used, and similarly the Laes-cccid parameter when 1234 call content is to be intercepted 1236 11.4. Changes in -00 since RFC 3603 1238 o The P-DCS-Trace-Party-ID header has been extended to include the 1239 trace-param parameter. 1241 o The P-DCS-Billing-Info header has been extended to include the 1242 Jip-param parameter in the Billing-Info-Param. 1244 o The P-DCS-LAES header has been extended to include the Laes-bcid 1245 and Laes-cccid parameters. The Laes-key parameter has been 1246 deprecated. 1248 o Added missing "SEMI" in P-DCS-REDIRECT header. 1250 12. To Do 1252 o Update method tables to include missing methods (PUBLISH and 1253 MESSAGE). 1255 o Update procedures for P-DCS-Billing-Info to cover the new Jip- 1256 param parameter. 1258 13. Acknowledgements 1260 The Distributed Call Signaling work in the PacketCable project is the 1261 work of a large number of people, representing many different 1262 companies. The authors would like to recognize and thank the 1263 following for their assistance: John Wheeler, Motorola; David 1264 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, Jay 1265 Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido 1266 Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi 1267 Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; 1268 Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- Hai 1269 Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable 1270 Communications. 1272 Previous versions further acknowledged, as co-authors, several people 1273 for providing the text of this document. They are: 1275 Bill Marshall (wtm@research.att.com) and K. K. Ramakrishnan 1276 (kkrama@research.att.com), AT&T; Ed Miller 1277 (edward.miller@terayon.com), Terayon; David Hancock (D.Hancock@ 1278 Cablelabs.com) and Glenn Russell (G.Russell@Cablelabs.com), 1279 CableLabs; Burcak Beser (burcak@juniper.net) Juniper Networks, Mike 1280 Mannette (Michael_Mannette@3com.com) and Kurt Steinbrenner 1281 (Kurt_Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com) and 1282 Flemming Andreasen (fandreas@cisco.com), Cisco Systems; John Pickens 1283 (jpickens@com21.com), Com21; Poornima Lalwaney 1284 (poornima.lalwaney@nokia.com), Nokia; Jon Fellows 1285 (jfellows@coppermountain.com), Copper Mountain Networks; Doc Evans 1286 (n7dr@arrisi.com) Arris, and Keith Kelly (keith@netspeak.com), 1287 NetSpeak. 1289 14. References 1291 14.1. Normative References 1293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1294 Requirement Levels", BCP 14, RFC 2119, March 1997. 1296 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1297 A., Peterson, J., Sparks, R., Handley, M., and E. 1298 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1299 June 2002. 1301 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1302 Method", RFC 3515, April 2003. 1304 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1305 Specifications: ABNF", RFC 4234, October 2005. 1307 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 1308 Identification in the Session Initiation Protocol (SIP)", 1309 RFC 4538, June 2006. 1311 14.2. Informative References 1313 [DCSARCH] Marshall, W., Osman, M., Andreasen, F., and D. Evans, 1314 "Architectural Considerations for Providing Carrier Class 1315 Telephony Services Utilizing SIP-based Distributed Call 1316 Control Mechanisms", Jan 2003. 1318 [PCDQOS] Cable Television Laboratories, Inc., "PacketCable 1.5 1319 Specifications, Dynamic Quality of Service", Aug 2005. 1321 [PCEM] Cable Television Laboratories, Inc., "PacketCable 1.5 1322 Specifications, Event Messages", Dec 2005. 1324 [PCSEC] Cable Television Laboratories, Inc., "PacketCable 1.5 1325 Specifications, Security", Jan 2005. 1327 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 1328 May 2000. 1330 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1331 Extensions to the Session Initiation Protocol (SIP) for 1332 Asserted Identity within Trusted Networks", RFC 3325, 1333 November 2002. 1335 Authors' Addresses 1337 Flemming Andreasen 1338 Cisco 1339 Edison, NJ 1340 USA 1342 Email: fandreas@cisco.com 1344 Bernie McKibben 1345 CableLabs 1346 Louisville, CO 1347 USA 1349 Email: B.McKibben@cablelabs.com 1351 Bill Marshall 1352 AT&T 1353 Florham Park, NJ 1354 USA 1356 Email: wtm@research.att.com 1358 Full Copyright Statement 1360 Copyright (C) The IETF Trust (2007). 1362 This document is subject to the rights, licenses and restrictions 1363 contained in BCP 78, and except as set forth therein, the authors 1364 retain all their rights. 1366 This document and the information contained herein are provided on an 1367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1369 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1370 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1371 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1374 Intellectual Property 1376 The IETF takes no position regarding the validity or scope of any 1377 Intellectual Property Rights or other rights that might be claimed to 1378 pertain to the implementation or use of the technology described in 1379 this document or the extent to which any license under such rights 1380 might or might not be available; nor does it represent that it has 1381 made any independent effort to identify any such rights. Information 1382 on the procedures with respect to rights in RFC documents can be 1383 found in BCP 78 and BCP 79. 1385 Copies of IPR disclosures made to the IETF Secretariat and any 1386 assurances of licenses to be made available, or the result of an 1387 attempt made to obtain a general license or permission for the use of 1388 such proprietary rights by implementers or users of this 1389 specification can be obtained from the IETF on-line IPR repository at 1390 http://www.ietf.org/ipr. 1392 The IETF invites any interested party to bring to its attention any 1393 copyrights, patents or patent applications, or other proprietary 1394 rights that may cover technology that may be required to implement 1395 this standard. Please address the information to the IETF at 1396 ietf-ipr@ietf.org. 1398 Acknowledgment 1400 Funding for the RFC Editor function is provided by the IETF 1401 Administrative Support Activity (IASA).