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