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