idnits 2.17.1 draft-dcsgroup-sipping-proxy-proxy-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (March 2, 2003) is 7720 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '6' on line 448 looks like a reference -- Missing reference section? '1' on line 257 looks like a reference -- Missing reference section? '10' on line 290 looks like a reference -- Missing reference section? '2' on line 1167 looks like a reference -- Missing reference section? '9' on line 661 looks like a reference -- Missing reference section? '5' on line 842 looks like a reference -- Missing reference section? '3' on line 883 looks like a reference -- Missing reference section? '8' on line 921 looks like a reference -- Missing reference section? '7' on line 1113 looks like a reference -- Missing reference section? '4' on line 1141 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group W. Marshall, Editor 2 Internet Draft AT&T 3 Document: 4 Category: Informational F. Andreasen, Editor 5 Cisco 7 March 2, 2003 9 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions 10 for Supporting the PacketCable Distributed Call Signaling 11 Architecture 13 Status of this Memo 15 This document is an Internet-Draft and is in full compliance with 16 all provisions of Section 10 of RFC 2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 In order to deploy a residential telephone service at very large 36 scale across different domains, it is necessary for trusted elements 37 owned by different service providers to exchange trusted information 38 that conveys customer-specific information and expectations about 39 the parties involved in the call. This document describes private 40 extensions to the Session Initiation Protocol (RFC3261) for 41 supporting the exchange of customer information and billing 42 information between trusted entities in the PacketCable Distributed 43 Call Signaling Architecture. These extensions provide mechanisms for 44 access network coordination to prevent theft of service, customer 45 originated trace of harassing calls, support for operator services 46 and emergency services, and support for various other regulatory 47 issues. The use of the extensions is only applicable within closed 48 administrative domains, or among federations of administrative 49 domains with previously agreed-upon policies where coordination of 50 charging and other functions is required. 52 DCS Group Category Informational - Expiration 9/1/2003 1 53 Table of Contents 55 Status of this Memo................................................1 56 Abstract...........................................................1 57 Table of Contents..................................................2 58 1. Applicability Statement.........................................3 59 2. Introduction....................................................3 60 3. Trust Boundary..................................................5 61 4. Conventions used in this document...............................5 62 5. P-DCS-TRACE-PARTY-ID............................................6 63 5.1 Syntax.........................................................6 64 5.2 Procedures at an Untrusted User Agent Client (UAC).............7 65 5.3 Procedures at a Trusted User Agent Client (UAC)................7 66 5.4 Procedures at an Untrusted User Agent Server (UAS).............7 67 5.5 Procedures at a Trusted User Agent Server (UAS)................7 68 5.6 Procedures at Proxy............................................7 69 5.6.1 Procedures at Originating Proxy..............................7 70 5.6.2 Procedures at Terminating Proxy..............................8 71 6. P-DCS-OSPS......................................................8 72 6.1 Syntax.........................................................8 73 6.2 Procedures at an Untrusted User Agent Client (UAC).............9 74 6.3 Procedures at a Trusted User Agent Client (UAC)................9 75 6.4 Procedures at an Untrusted User Agent Server (UAS).............9 76 6.5 Procedures at a Trusted User Agent Server (UAS)...............10 77 6.6 Procedures at Proxy...........................................10 78 7. P-DCS-BILLING-INFO.............................................10 79 7.1 Syntax........................................................11 80 7.2 Procedures at an Untrusted User Agent Client (UAC)............13 81 7.3 Procedures at a Trusted User Agent Client (UAC)...............13 82 7.4 Procedures at an Untrusted User Agent Server (UAS)............14 83 7.5 Procedures at a Trusted User Agent Server (UAS)...............14 84 7.6 Procedures at Proxy...........................................14 85 7.6.1 Procedures at Originating Proxy.............................15 86 7.6.2 Procedures at Terminating Proxy.............................15 87 7.6.3 Procedures at Tandem Proxy..................................16 88 8. P-DCS-LAES and P-DCS-REDIRECT..................................16 89 8.1 Syntax........................................................17 90 8.2 Procedures at an Untrusted User Agent Client (UAC)............18 91 8.3 Procedures at a Trusted User Agent Client (UAC)...............18 92 8.4 Procedures at an Untrusted User Agent Server (UAS)............19 93 8.5 Procedures at a Trusted User Agent Server (UAS)...............19 94 8.6 Procedures at Proxy...........................................19 95 8.6.1 Procedures at Originating Proxy.............................20 96 8.6.2 Procedures at Terminating Proxy.............................21 97 9. Security Considerations........................................22 98 10. IANA Considerations...........................................22 99 11. Notice Regarding Intellectual Property Rights.................23 100 12. Normative References..........................................23 101 13. Informative References........................................23 102 14. Acknowledgements..............................................23 103 15. Editor's Addresses............................................24 104 Full Copyright Statement..........................................25 105 Acknowledgement...................................................25 107 DCS Group Category Informational - Expiration 9/1/03 2 108 1. Applicability Statement 110 The SIP extensions described in this document make certain 111 assumptions regarding network topology, linkage between SIP and 112 lower layers, and the availability of transitive trust. These 113 assumptions are generally not applicable in the Internet as a whole. 114 The use of these headers is only applicable within closed 115 administrative domains, or among federations of administrative 116 domains with previously agreed-upon policies where coordination of 117 charging and other functions is required, as in for example the 118 architecture presented in [6]. Use outside such a domain could 119 result in the leakage of potentially sensitive or private 120 information. User consent to the privacy implications of the 121 policies in [6] is strongly encouraged in those domains as well. 123 Although RFC-2119 language is used in this document, the scope of 124 the normative language is only for the area of applicability of the 125 document and, like the technology, it does not apply to the general 126 Internet. 128 2. Introduction 130 In order to deploy a SIP[2]-based residential telephone service at 131 very large scale across different domains, it is necessary for 132 trusted elements owned by different service providers to exchange 133 trusted information that conveys billing information and 134 expectations about the parties involved in the call. 136 There are many billing models used in deriving revenue from 137 telephony services today. Charging for telephony services is tightly 138 coupled to the use of network resources. It is outside the scope of 139 this document to discuss the details of these numerous and varying 140 methods. 142 A key motivating principle of the DCS architecture described in [6] 143 is the need for network service providers to be able to control and 144 monitor network resources; revenue may be derived from the usage of 145 these resources as well as from the delivery of enhanced services 146 such as telephony. Furthermore, the DCS architecture recognizes the 147 need for coordination between call signaling and resource 148 management. This coordination ensures that users are authenticated 149 and authorized before receiving access to network resources and 150 billable enhanced services. 152 DCS Proxies, as defined in [6], have access to subscriber 153 information and act as policy decision points and trusted 154 intermediaries along the call signaling path. Edge routers provide 155 the network connectivity and resource policy enforcement mechanism 156 and also capture and report network connectivity and resource usage 157 information. Edge routers need to be given billing information that 158 can be logged with Record Keeping or Billing servers. The DCS 159 Proxy, as a central point of coordination between call signaling and 161 DCS Group Category Informational - Expiration 9/1/03 3 162 resource management, can provide this information based on the 163 authenticated identity of the calling and called parties. Since 164 there is a trust relationship among DCS Proxies, they can be relied 165 upon to exchange trusted billing information pertaining to the 166 parties involved in a call. See [6] for a description of the trust 167 boundary and trusted versus untrusted entities. 169 For these reasons, it is appropriate to consider defining SIP header 170 extensions to allow DCS Proxies to exchange information during call 171 setup. It is the intent that the extensions would only appear on 172 trusted network segments, should be inserted upon entering a trusted 173 network region, and removed before leaving trusted network segments. 175 Significant amounts of information is retrieved by an originating 176 DCS Proxy in its handling of a connection setup request from a user 177 agent. Such information includes location information about the 178 subscriber (essential for emergency services calls), billing 179 information, and station information (e.g. coin operated phone). In 180 addition, while translating the destination number, information such 181 as the local-number-portability office code is obtained and will be 182 needed by all other proxies handling this call. 184 For Usage Accounting records, it is necessary to have an identifier 185 that can be associated with all the event records produced for the 186 call. The SIP Call-ID header field cannot be used as such an 187 identifier since it is selected by the originating user agent, and 188 may not be unique among all past calls as well as current calls. 189 Further, since this identifier is to be used by the service 190 provider, it should be chosen in a manner and in a format that meets 191 the service provider's needs. 193 Billing information may not necessarily be unique for each user 194 (consider the case of calls from an office all billed to the same 195 account). Billing information may not necessarily be identical for 196 all calls made by a single user (consider prepaid calls, credit card 197 calls, collect calls, etc). It is therefore necessary to carry 198 billing information separate from the calling and called party 199 identification. Furthermore, some billing models call for split- 200 charging where multiple entities are billed for portions of the 201 call. 203 The addition of a SIP General Header Field allows for the capture of 204 billing information and billing identification for the duration of 205 the call. 207 It is the intent that the billing extensions would only appear on 208 trusted network segments, and MAY be inserted by a DCS Proxy in 209 INVITE and REFER requests and INVITE responses in a trusted network 210 segment, and removed before leaving trusted network segments. 212 In addition to support for billing, current residential telephone 213 service includes the need for customer originated trace (of 214 harassing or obscene calls), for operator services such as busy line 216 DCS Group Category Informational - Expiration 9/1/03 4 217 verification and emergency interrupt (initiated by an operator from 218 an Operator Services Position System (OSPS)), for emergency services 219 such as 9-1-1 calls to a Public Service Access Point (PSAP) and the 220 subsequent call handling, and support for Electronic Surveillance 221 and Law Enforcement access as required by applicable legislation and 222 court orders. In all of these cases, additional information about 223 the call and about the subscribers involved in the call needs to be 224 exchanged between the proxies. 226 3. Trust Boundary 228 The DCS architecture [6] defines a trust boundary around the various 229 systems and servers that are owned, operated by, and/or controlled 230 by the service provider. These trusted systems include the proxies 231 and various servers such as bridge servers, voicemail servers, 232 announcement servers, etc. Outside of the trust boundary lie the 233 customer premises equipment, and various application and media 234 servers operated by third-party service providers. 236 Certain subscriber-specific information, such as billing and 237 accounting information, stays within the trust boundary. Other 238 subscriber-specific information, such as endpoint identity, may be 239 presented to untrusted endpoints or may be withheld based on 240 subscriber profiles. 242 The User Agent (UA) may be either within the trust boundary or 243 outside the trust boundary, depending on exactly what function is 244 being performed and exactly how it is being performed. 245 Accordingly, the procedures followed by a User Agent are different 246 depending on whether the UA is within the trust boundary or outside 247 the trust boundary. 249 The following sections giving procedures for User Agents therefore 250 are subdivided into trusted user agents and untrusted user agents. 252 4. Conventions used in this document 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 256 this document are to be interpreted as described in RFC-2119 [1]. 258 The term "private-URL" used in this document refers to a SIP URI 259 that is generated by a proxy, contains a "hostport" that identifies 260 the proxy, and contains a "userinfo" string that is generated by the 261 proxy. The "userinfo" typically contains (or points to) information 262 that is not to be disclosed outside the trusted domain of the 263 proxies, such as billing account numbers, electronic surveillance 264 indication, electronic surveillance parameters, and call redirection 265 information. Consequently, the information is either stored locally 266 by the proxy, or encrypted with a private key known only to the 267 proxy and encoded in a character string in the "userinfo" portion of 268 the URL. A checksum is included in the "userinfo" data to detect 270 DCS Group Category Informational - Expiration 9/1/03 5 271 tampering. The mechanism by which a proxy recognizes a "userinfo" 272 as a private-URL and decodes and recovers the original information 273 is local to the proxy and is not subject to standardization. Some 274 possible implementations include an initial magic cookie (e.g. 275 z9hG4Bk followed by the pointer/information), or use of a reserved 276 "user" name (e.g. "private") with the optional "password" containing 277 the pointer/information. 279 5. P-DCS-TRACE-PARTY-ID 281 In the telephone network, calling identity information is used to 282 support regulatory requirements such as the Customer Originated 283 Trace service, which provide the called party with the ability to 284 report obscene or harassing phone calls to law enforcement. This 285 service is provided independently of caller-id, and works even if 286 the caller requested anonymity. The calling party is here 287 identified as the station originating the call. In order for this 288 service to be dependable, the called party must be able to trust 289 that the calling identity information being presented is valid. One 290 way to achieve this is described in [10]. 292 To initiate a customer-originated-trace from an untrusted UAC, an 293 additional header is defined for the INVITE request. This header is 294 called P-DCS-Trace-Party-ID, and does not appear in any other 295 request or response. The entity addressed by the Request-URI 296 performs the service-provider-specific functions of recording and 297 reporting the caller identity in the P-DCS-Trace-Party-ID for law 298 enforcement action. It then forwards the call to either an 299 announcement server or to the service-provider's business office to 300 collect further information about the complaint. A trusted UAC does 301 not use this header, as it initiates this action locally. 303 5.1 Syntax 305 The ABNF description of this header is (some terms used in this ABNF 306 are defined in [2]): 308 P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON 309 name-addr 311 This document adds the following entry to Table 2 of [2]: 313 Header field where proxy ACK BYE CAN INV OPT REG 314 ------------ ----- ----- --- --- --- --- --- --- 315 P-DCS-Trace-Party-ID R dr - - - o - - 317 SUB NOT REF INF UPD PRA 318 --- --- --- --- --- --- 319 - - - - - - 321 DCS Group Category Informational - Expiration 9/1/03 6 322 The addr-spec contained in name-addr contains a URL that identifies 323 the remote endpoint. Addr-spec typically contains a tel: URL or SIP 324 URI giving the identity of the remote endpoint, as provided in the 325 signaling messages that established the session to be traced. 327 5.2 Procedures at an Untrusted User Agent Client (UAC) 329 The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial 330 INVITE message for a customer-originated-trace request. The UAC 331 MUST use a SIP URI in the Request-URI with userinfo set to "call- 332 trace" and hostport identifying the call tracing entity for the 333 untrusted UA. 335 5.3 Procedures at a Trusted User Agent Client (UAC) 337 A trusted UAC performs the customer-originated-trace in a manner 338 similar to the trusted UAS, described below. A trusted UAC MUST NOT 339 include this header in any request. 341 5.4 Procedures at an Untrusted User Agent Server (UAS) 343 This header MUST NOT appear in any response sent by a UAS. 345 5.5 Procedures at a Trusted User Agent Server (UAS) 347 If the P-DCS-Trace-Party-ID header is present in the initial INVITE 348 request from a UAC, and the Request-URI of the INVITE has userinfo 349 set to "call-trace" and hostport set to the UAS, the UAS MUST 350 perform the service-provider-specific functions of recording and 351 reporting the caller identity for law enforcement action. The UAS 352 then MUST redirect the call, via a 3xx response, to either an 353 announcement server or to the service-provider's business office to 354 collect further information about the complaint. 356 This header MUST NOT appear in any response sent by a UAS. 358 5.6 Procedures at Proxy 360 Two sets of proxy procedures are defined: (1) the procedures at an 361 originating proxy, and (2) the procedures at a terminating proxy. 362 The originating proxy is a proxy that received the INVITE request 363 from a non-trusted endpoint. 365 The terminating proxy is a proxy that sends the INVITE request to a 366 non-trusted endpoint. 368 A proxy that both receives the INVITE request from an untrusted 369 endpoint, and sends the INVITE request to an untrusted endpoint, 370 performs both sets of procedures. 372 5.6.1 Procedures at Originating Proxy 374 DCS Group Category Informational - Expiration 9/1/03 7 375 If the P-DCS-Trace-Party-ID header is present in the initial INVITE 376 request from the UAC, and the Request-URI of the INVITE has userinfo 377 other than "call-trace" and hostport set to other than a potentially 378 provisioned call tracing entity, then the Proxy MAY reject the 379 request, or MAY remove the P-DCS-Trace-Party-ID header from the 380 request. If the header is present in a valid request, and contains 381 a private-URL that identifies the Proxy in the hostport, then the 382 Originating Proxy SHOULD replace the private-URL with its original 383 contents (i.e. the verified identity of the caller of the session 384 that is being traced). 386 5.6.2 Procedures at Terminating Proxy 388 This header MUST NOT appear in any request or response sent by a 389 terminating proxy to an untrusted endpoint. 391 6. P-DCS-OSPS 393 Some calls have special call processing requirements that may not be 394 satisfied by normal user agent call processing. For example, when a 395 user is engaged in a call and another call arrives, such a call 396 might be rejected with a busy indication. However, some PSTN 397 operator services require special call processing. In particular, 398 the Busy Line Verification (BLV) and Emergency Interrupt (EI) 399 services initiated by an operator from an Operator Services Position 400 System (OSPS) on the PSTN network have such a need. Similarly, 401 emergency calls to a 9-1-1 Public Service Access Point (PSAP) may 402 result in trunk signaling causing operator ringback using a howling 403 tone or sustained ring on the originating line (country-specific 404 variations may exist). 406 In order to inform the SIP user agent that special treatment should 407 be given to a call, we use a new P-DCS-OSPS header field, which may 408 be set to a value indicating when a special type of call processing 409 is requested. We define three values in this header, namely "BLV" 410 for busy line verification, "EI" for emergency interrupt, and "RING" 411 for operator ringback (e.g., howling/sustained tone ring in the US). 413 If the user agent decides to honor such a request, the response of 414 the user agent to an INVITE with either "BLV" or "EI" will not be a 415 busy indication. Since "EI" and "RING" only occur on established 416 dialogs, they may also appear in UPDATE requests. 418 6.1 Syntax 420 The ABNF description of the P-DCS-OSPS header is as follows (some 421 terms used in this ABNF are defined in [2]): 423 P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag 424 OSPS-Tag = "BLV" / "EI" / "RING" / token 426 This document adds the following entry to Table 2 of [2]: 428 DCS Group Category Informational - Expiration 9/1/03 8 429 Header field where proxy ACK BYE CAN INV OPT REG 430 ------------ ----- ----- --- --- --- --- --- --- 431 P-DCS-OSPS R dr - - - o - - 433 SUB NOT REF INF UPD PRA 434 --- --- --- --- --- --- 435 - - - - o - 437 The OSPS-Tag value of "token" is defined for extensibility, and is 438 reserved for future use. 440 6.2 Procedures at an Untrusted User Agent Client (UAC) 442 The P-DCS-OSPS header MUST NOT be sent in a request from an 443 untrusted UAC. 445 6.3 Procedures at a Trusted User Agent Client (UAC) 447 This header is typically only inserted by a Media Gateway Controller 448 [6] that is controlling a Media Gateway with special trunks to a 449 PSTN OSPS system or PSAP. This trunk group is usually referred to 450 as a BLV-trunk group and employs special signaling procedures that 451 prevent inadvertent use. Calls originating at the PSTN OSPS system 452 are sent over this trunk group, and result in an INVITE request with 453 the P-DCS-OSPS header. 455 This header MAY be sent in an INVITE request, and MUST NOT appear in 456 any message other than those listed below. 458 OSPS-Tag value "BLV" MUST NOT appear in any request or response 459 other than an initial INVITE request establishing a new dialog. 461 OSPS-Tag value "EI" MUST NOT appear in any request or response other 462 than (1) a subsequent INVITE within a pre-existing dialog 463 established with the OSPS-Tag value of "BLV", or (2) an UPDATE 464 request within a pre-existing dialog established with the OSPS-Tag 465 value of "BLV". 467 OSPS-Tag value "RING" MUST NOT appear in any request or response 468 other than (1) a subsequent INVITE within a pre-existing dialog 469 established by a UAC to an operator or PSAP, or (2) an UPDATE 470 request within a pre-existing dialog established by a UAC to an 471 operator or PSAP. 473 6.4 Procedures at an Untrusted User Agent Server (UAS) 475 If the UAS receives an INVITE request with an OSPS-Tag of "BLV", 476 dialog identification that matches an existing dialog, and the 477 existing call was not established with the OSPS-Tag, it MUST reject 478 the request with a 403-Forbidden error code. 480 DCS Group Category Informational - Expiration 9/1/03 9 481 If the UAS receives an INVITE/UPDATE request with an OSPS-Tag value 482 of "EI" or "RING", with dialog identification that does not match an 483 existing dialog, it MUST reject the request with a 403-Forbidden 484 response code. 486 If the UAS receives an INVITE that contains an OSPS-Tag value of 487 "BLV" and is not willing to cooperate in offering this service, it 488 MUST reject the request with a 403-Forbidden response code. 490 The UAS SHOULD NOT reject an INVITE with a BLV OSPS-Tag due to a 491 busy condition. The UAS MUST NOT respond with a 3xx-Redirect 492 response code to an INVITE with a BLV OSPS-Tag. The UAS SHOULD NOT 493 alert the user of the incoming call attempt if the BLV OSPS-Tag is 494 present in the INVITE. 496 If an INVITE with OSPS-Tag of "BLV" is accepted (e.g., meeting all 497 QoS pre-conditions, etc.), the UAS MUST send an audio stream on this 498 connection to the address and port given in the SDP of the INVITE. 499 The UAS MAY perform a mixing operation between the two ends of an 500 existing active call and send the resulting media stream to the 501 address and port indicated. Alternatively, the UAS MAY send a copy 502 of the local voice stream, and (if no activity on the local voice 503 stream) send a copy of the received voice stream of an existing 504 call. If the state of the UAS is idle, the UAS SHOULD send a stream 505 of silence packets to OSPS. If the state of the UAS is ringing or 506 ringback, the UAS SHOULD send a ringback stream to OSPS. 508 If an INVITE/UPDATE with OSPS-Tag of "EI" is accepted, the UAS MUST 509 enable communication between the UAC and the local user. The UAS 510 MAY put any existing call on hold, or initiate an ad-hoc conference. 512 If an INVITE/UPDATE with OSPS-Tag of "RING" is accepted, the UAS 513 MUST perform operator ringback in accordance with local procedures, 514 e.g., generate a 3-second howling tone or a sustained ring, 515 depending on the state of the user equipment. 517 6.5 Procedures at a Trusted User Agent Server (UAS) 519 The procedures at a trusted UAS MUST be identical to those described 520 in 6.4. 522 6.6 Procedures at Proxy 524 In the DCS architecture, the OSPS is considered a trusted UAC. If a 525 proxy receives a P-DCS-OSPS header in a request from an untrusted 526 source, it MUST either remove the header or reject the request with 527 a 403-Forbidden response. 529 A proxy that implements a call-forwarding service MUST NOT respond 530 to an INVITE request with a 3xx response, if the request contained 531 the P-DCS-OSPS header. 533 7. P-DCS-BILLING-INFO 535 DCS Group Category Informational - Expiration 9/1/03 10 536 There are many billing models used in deriving revenue from 537 telephony services today. Charging for telephony services is tightly 538 coupled to the use of network resources. It is outside the scope of 539 this document to discuss the details of these numerous and varying 540 methods. 542 Proxies have access to subscriber information and act as policy 543 decision points and trusted intermediaries along the call signaling 544 path. Edge routers provide the network connection and resource 545 policy enforcement mechanism and also capture and report network 546 connection and resource usage information. Edge routers need to be 547 given billing information that can be logged with Record Keeping or 548 Billing servers. The proxy, as a central point of coordination 549 between call signaling and resource management, can provide this 550 information based on the authenticated identity of the calling and 551 called parties. Since there is a trust relationship among proxies, 552 they can be relied upon to exchange trusted billing information 553 pertaining to the parties involved in a call. 555 For Usage Accounting records, it is necessary to have an identifier 556 that can be associated with all the event records produced for the 557 call. The SIP Call-ID header field cannot be used as such an 558 identifier since it is selected by the originating user agent, and 559 may not be unique among all past calls as well as current calls. 560 Further, since this identifier is to be used by the service 561 provider, it should be chosen in a manner and in a format that meets 562 the service provider's needs. 564 Billing information may not necessarily be unique for each user 565 (consider the case of calls from an office all billed to the same 566 account). Billing information may not necessarily be identical for 567 all calls made by a single user (consider prepaid calls, credit card 568 calls, collect calls, etc). It is therefore necessary to carry 569 billing information separate from the calling and called party 570 identification. Furthermore, some billing models call for split- 571 charging where multiple entities are billed for portions of the 572 call. 574 The addition of a SIP General Header Field allows for the capture of 575 billing information and billing identification for the duration of 576 the call. 578 It is the intent that the billing extensions would only appear on 579 trusted network segments, and MAY be inserted by a proxy or trusted 580 UA in INVITE requests in a trusted network segment, and removed 581 before leaving trusted network segments. The P-DCS-Billing-Info 582 header extension is used only on requests and responses between 583 proxies and trusted User Agents. It is never sent to, nor sent by, 584 an untrusted UA. 586 7.1 Syntax 588 DCS Group Category Informational - Expiration 9/1/03 11 589 The DCS-Billing-Info header is defined by the following ABNF (some 590 terms used in this ABNF are defined in [2]): 592 P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON 593 Billing-Correlation-ID "/" FEID 594 *(SEMI Billing-Info-param) 595 Billing-Correlation-ID = 1*48(HEXDIG) 596 FEID = 1*16(HEXDIG) "@" host 597 Billing-Info-param = RKS-Group-ID-param / Charge-param / 598 Calling-param / Called-param / 599 Routing-param / Loc-Routing-param / 600 generic-param 601 RKS-Group-ID-param = "rksgroup" EQUAL RKS-Group-ID 602 RKS-Group-ID = token 603 Charge-param = "charge" EQUAL Acct-Charge-URI 604 Acct-Charge-URI = LDQUOT addr-spec RDQUOT 605 Calling-param = "calling" EQUAL Acct-Calling-URI 606 Acct-Calling-URI = LDQUOT addr-spec RDQUOT 607 Called-param = "called" EQUAL Acct-Called-URI 608 Acct-Called-URI = LDQUOT addr-spec RDQUOT 609 Routing-param = "routing" EQUAL Acct-Routing-URI 610 Acct-Routing-URI = LDQUOT addr-spec RDQUOT 611 Loc-Routing-param = "locroute" EQUAL Acct-Loc-Routing-URI 612 Acct-Loc-Routing-URI = LDQUOT addr-spec RDQUOT 614 This document adds the following entry to Table 2 of [2]: 616 Header field where proxy ACK BYE CAN INV OPT REG 617 ------------ ----- ----- --- --- --- --- --- --- 618 P-DCS-Billing-Info admr - - - o - - 620 SUB NOT REF INF UPD PRA 621 --- --- --- --- --- --- 622 - - - - - - 624 The P-DCS-Billing-Info extension contains an identifier that can be 625 used by an event recorder to associate multiple usage records, 626 possibly from different sources, with a billable account. It further 627 contains the subscriber account information, and other information 628 necessary for accurate billing of the service. This header is only 629 used between proxies and trusted User Agents. 631 The Billing-Correlation-ID is specified in [9] as a 24-byte binary 632 structure, containing 4 bytes of NTP timestamp, 8 bytes of the 633 unique identifier of the network element that generated the ID, 8 634 bytes giving the time zone, and 4 bytes of monotonically increasing 635 sequence number at that network element. This identifier is chosen 636 to be globally unique within the system for a window of several 637 months. This MUST be encoded in the P-DCS-Billing-Info header as a 638 hexadecimal string of up to 48 characters. Leading zeroes MAY be 639 suppressed. 641 DCS Group Category Informational - Expiration 9/1/03 12 642 The Financial-Entity-ID (FEID) is specified in [9] as an 8-byte 643 structure, containing the financial identifier for that domain, 644 followed by a domain name. FEID can be associated with a type of 645 service and could be assigned to multiple domains by the same 646 provider. A domain could contain multiple assigned FEIDs. This 8- 647 byte structure MUST be encoded in the P-DCS-Billing-Info header as a 648 hexadecimal string of up to 16 characters. Trailing zeroes MAY be 649 suppressed. "Host" contains the domain name. 651 The RKS-Group-ID specifies a record keeping server (or group of 652 cooperating servers) for event messages relating to this call. It 653 is used to control certain optimizations of procedures when multiple 654 event message streams are being sent to the same Record Keeping 655 Server. 657 Additional parameters contain the information needed for generation 658 of event message records. Acct-Charge-URI, Acct-Calling-URI, Acct- 659 Called-URI, Acct-Routing-URI, and Acct-Location-Routing-URI are each 660 defined as URLs; they should all contain tel: URLs with E.164 661 formatted addresses. These fields are further defined in [9] under 662 the element identifiers "Charge_Number" (element ID 16), 663 "Calling_Party_Number" (element ID 4), "Called_Party_Number" 664 (element ID 5), "Routing Number" (element ID 25), and 665 "Location_Routing_Number" (element ID 22). 667 7.2 Procedures at an Untrusted User Agent Client (UAC) 669 This header is never sent to an untrusted UAC, and is never sent by 670 an untrusted UAC. 672 7.3 Procedures at a Trusted User Agent Client (UAC) 674 The UAC MUST generate the Billing-Correlation-ID for the call, and 675 insert it into the P-DCS-Billing-Info header in the initial INVITE 676 message sent to the terminating proxy, along with the charging 677 information for the call. The UAC MUST include its FEID, and the 678 RKS-Group-ID for the Record-Keeping-Server being used by the UAC. 679 If the UAC performed a Local Number Portability (LNP) query, it MUST 680 include the Routing Number and Location Routing Number returned by 681 the query. 683 If the response to the initial INVITE is a 3xx-Redirect, the UAC 684 generates a new initial INVITE request to the destination specified 685 in the Contact: header, as per standard SIP. If a UAC receives a 686 3xx-Redirect response to an initial INVITE, the new INVITE generated 687 by the UAC MUST contain the P-DCS-Billing-Info header from the 3xx- 688 Redirect response. If the UAC is acting as a B2BUA, instead of 689 generating a new INVITE it MAY generate a private-URL and place it 690 in the Contact header of a 3xx-Redirect response sent to the 691 originating endpoint. This private-URL MUST contain (or contain a 692 pointer to) the P-DCS-Billing-Info value, which indicates the 693 charging arrangement for the new call, and an expiration time very 695 DCS Group Category Informational - Expiration 9/1/03 13 696 shortly in the future, to limit the ability of the originator to re- 697 use this private-URL for multiple calls. 699 A UAC that includes a Refer-to header in a REFER request MUST 700 include a P-DCS-Billing-Info header in the Refer-to's URL. This P- 701 DCS-Billing-Info header MUST include the accounting information of 702 the initiator of the REFER. 704 7.4 Procedures at an Untrusted User Agent Server (UAS) 706 This header is never sent to an untrusted UAS, and is never sent by 707 an untrusted UAS. 709 7.5 Procedures at a Trusted User Agent Server (UAS) 711 The UAS MUST include a P-DCS-Billing-Info header in the first 712 reliable 1xx (except 100) or 2xx response to an initial INVITE 713 message. This P-DCS-Billing-Info header MUST include the Billing- 714 Correlation-ID generated by the UAS, the FEID of the UAS, and the 715 RKS-Group-ID of the Record-Keeping-Server being used by the UAS. 716 The UAS MAY change the values of Acct-Charge-URI if it wishes to 717 override the billing information that was present in the INVITE 718 (e.g. for a toll-free call). The decision to do this and the 719 contents of the new Acct-Charge-URI MUST be determined by service 720 provider policy provisioned in the UAS. If the UAS performed a LNP 721 query, it MUST include the Routing Number and Location Routing 722 Number returned by the query. 724 The UAS MUST add a P-DCS-Billing-Info header to a 3xx-redirect 725 response to an initial INVITE, giving the accounting information for 726 the call forwarder, for the call segment from the destination to the 727 forwarded-to destination. 729 7.6 Procedures at Proxy 731 Three sets of proxy procedures are defined: (1) the procedures at an 732 originating proxy, (2) the procedures at a terminating proxy, and 733 (3) the procedures at a tandem proxy. 735 The originating proxy is a proxy that received the INVITE request 736 from a non-trusted endpoint. 738 The terminating proxy is a proxy that sends the INVITE request to a 739 non-trusted endpoint. 741 A proxy that is neither an originating proxy, nor a terminating 742 proxy, is a tandem proxy. 744 For purposes of mid-call changes, such as call transfers, the proxy 745 that receives the request from a non-trusted endpoint is considered 746 the initiating proxy; the proxy that sends the request to a non- 747 trusted endpoint is considered the recipient proxy. Procedures for 748 the initiating proxy are included below with those for originating 750 DCS Group Category Informational - Expiration 9/1/03 14 751 proxies, while procedures for the recipient proxy are included with 752 those for terminating proxies. 754 A proxy that both receives the INVITE request from an untrusted 755 endpoint, and sends the INVITE request to a non-trusted endpoint, 756 performs both sets of procedures. 758 7.6.1 Procedures at Originating Proxy 760 The originating proxy MUST generate the Billing-Correlation-ID for 761 the call, and insert it into the P-DCS-Billing-Info header in the 762 initial INVITE message sent to the terminating proxy, along with the 763 charging information for the call. The originating proxy MUST 764 include its FEID, and the RKS-Group-ID for the Record-Keeping-Server 765 being used by the originating proxy. If the originating proxy 766 performed a LNP query, it MUST include the Routing Number and 767 Location Routing Number returned by the query. Any P-DCS-Billing- 768 Info header present from an untrusted UA MUST be removed. 770 If the Request-URI contains a private-URL, and the decoded username 771 contains billing information, the originating proxy MUST generate a 772 P-DCS-Billing-Info header with that decrypted information. 773 Otherwise, the originating proxy MUST determine the accounting 774 information for the call originator, and insert a P-DCS-Billing-Info 775 header including that information. 777 If the response to the initial INVITE is a 3xx-Redirect, received 778 prior to a 18x, the originating proxy generates a new initial INVITE 779 request to the destination specified in the Contact: header, as per 780 standard SIP. If an originating proxy receives a 3xx-Redirect 781 response to an initial INVITE prior to a 18x response, the INVITE 782 generated by the proxy MUST contain the P-DCS-Billing-Info header 783 from the 3xx-Redirect response. 785 If the response to the initial INVITE is a 3xx-Redirect, received 786 after a 18x, the originating proxy generates a private-URL and 787 places it in the Contact header of a 3xx-Redirect response sent to 788 the originating endpoint. This private-URL MUST contain (or contain 789 a pointer to) the P-DCS-Billing-Info value, which indicate the 790 charging arrangement for the new call, and an expiration time very 791 shortly in the future, to limit the ability of the originator to re- 792 use this private-URL for multiple calls. 794 An originating proxy that processes a REFER request from an 795 untrusted UA MUST include a P-DCS-Billing-Info header in the Refer- 796 to's URL. This P-DCS-Billing-Info header MUST include the 797 accounting information of the initiator. 799 7.6.2 Procedures at Terminating Proxy 801 The terminating proxy MUST NOT send the P-DCS-Billing-Info header to 802 an untrusted destination. 804 DCS Group Category Informational - Expiration 9/1/03 15 805 The terminating proxy MUST include a P-DCS-Billing-Info header in 806 the first reliable 1xx (except 100) or 2xx response to an initial 807 INVITE message. This P-DCS-Billing-Info header MUST include the 808 Billing-Correlation-ID generated by the terminating proxy, the FEID 809 of the terminating proxy, and the RKS-Group-ID of the Record- 810 Keeping-Server being used by the terminating proxy. The terminating 811 proxy MAY change the values of Acct-Charge-URI if it wishes to 812 override the billing information that was present in the INVITE 813 (e.g. for a toll-free call). The decision to do this and the 814 contents of the resulting P-DCS-Billing-Info header MUST be 815 determined by service provider policy provisioned in the terminating 816 proxy. If the terminating proxy performed a LNP query, it MUST 817 include the Routing Number and Location Routing Number returned by 818 the query. 820 The terminating proxy MUST add P-DCS-Billing-Info headers to a 3xx- 821 redirect response to an initial INVITE, giving the accounting 822 information for the call forwarder, for the call segment from the 823 destination to the forwarded-to destination. 825 A proxy receiving a mid-call REFER request that includes a Refer-to 826 header generates a private-URL and places it in the Refer-to header 827 sent to the endpoint. This private-URL MUST contain the P-DCS- 828 Billing-Info value, which indicate the charging arrangement for the 829 new call, and an expiration time very shortly in the future, to 830 limit the ability of the endpoint to re-use this private-URL for 831 multiple calls. 833 7.6.3 Procedures at Tandem Proxy 835 If the tandem proxy performed a LNP query, it MUST insert the 836 Routing Number and Location Routing Number returned by the query 837 into the P-DCS-Billing-Info header in the first reliable 1xx/2xx/3xx 838 (except 100) response. 840 8. P-DCS-LAES and P-DCS-REDIRECT 842 NOTE: According to RFC-2804[5], the IETF supports documentation of 843 lawful intercept technology if it is necessary to develop it. The 844 following section provides such documentation. The RFC-2119 845 language, as stated above, describes the requirements of the 846 specification only if implemented, and strictly within the 847 applicability domain described above. See RFC-2804 for description 848 of issues regarding privacy, security, and complexity in relation to 849 this technology. 851 The P-DCS-LAES extension contains the information needed to support 852 Lawfully Authorized Electronic Surveillance. This header contains 853 the address and port of an Electronic Surveillance Delivery Function 854 for delivery of a duplicate stream of event messages related to this 855 call. The header may also contain an additional address and port 856 for delivery of call content. Security key information is included 857 to enable pairs of Delivery Functions to securely exchange 859 DCS Group Category Informational - Expiration 9/1/03 16 860 surveillance information. This header is only used between proxies 861 and trusted User Agents. 863 The P-DCS-Redirect extension contains call identifying information 864 needed to support the requirements of Lawfully Authorized Electronic 865 Surveillance of redirected calls. This header is only used between 866 proxies and trusted User Agents. 868 Use of P-DCS-LAES and P-DCS-Redirect is controlled by a combination 869 of legislation, regulation, and court orders, which MUST be 870 followed. In certain cases inclusion of these headers will be 871 mandated, and therefore MUST be present in the requests and 872 responses indicated. In other cases inclusion of these headers will 873 be forbidden, and therefore MUST NOT be present in the request and 874 responses indicated. In the sub-sections that follow, use of 875 "SHOULD" is intended to capture these conflicting situations, e.g. a 876 P-DCS-LAES header SHOULD be included in an initial INVITE means 877 either that it MUST be included or that it MUST NOT be included, 878 based on the applicable court orders. 880 8.1 Syntax 882 The format of the P-DCS-LAES header is given by the following ABNF 883 (some terms used in this ABNF are defined in [2] and [3]): 885 P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig 886 *(SEMI Laes-param) 887 Laes-sig = hostport 888 Laes-param = Laes-content / Laes-key / generic-param 889 Laes-content = "content" EQUAL hostport 890 Laes-key = "key" EQUAL token 892 P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID 893 *(redir-params) 894 Called-ID = LDQUOT addr-spec RDQUOT 895 redir-params = redir-uri-param / redir-count-param / 896 generic-param 897 redir-uri-param = "redirector-uri" EQUAL Redirector 898 Redirector = LDQUOT addr-spec RDQUOT 899 redir-count-param = "count" EQUAL Redir-count 900 Redir-count = 1*DIGIT 902 This document adds the following entry to Table 2 of [2]: 904 Header field where proxy ACK BYE CAN INV OPT REG 905 ------------ ----- ----- --- --- --- --- --- --- 906 P-DCS-LAES adr - - - o - - 907 P-DCS-Redirect adr - - - o - - 909 SUB NOT REF INF UPD PRA 910 --- --- --- --- --- --- 911 - - - - - - 913 DCS Group Category Informational - Expiration 9/1/03 17 914 - - - - - - 916 The values of Laes-sig and Laes-content are addresses of the 917 Electronic Surveillance Delivery Function, and used as the 918 destination address for call-identifying information and call- 919 content, respectively. Laes-key is a string generated by the proxy 920 that is used by the Delivery Function to securely transfer 921 information between them [8]. 923 The P-DCS-Redirect header contains redirection information. The 924 redir-uri-param indicates the original destination requested by the 925 user (e.g. dialed number), the Redirector indicates the new 926 destination, and the Redir-count indicates the number of 927 redirections that have occurred. 929 8.2 Procedures at an Untrusted User Agent Client (UAC) 931 This header MUST NOT be sent to an untrusted UAC, and MUST NOT be 932 sent by an untrusted UAC. 934 8.3 Procedures at a Trusted User Agent Client (UAC) 936 The UAC checks for an outstanding lawfully authorized surveillance 937 order for the originating subscriber, and, if present, includes this 938 information in the Authorization for Quality of Service [7] or 939 signals this information to the device performing the intercept 940 (e.g. a Media Gateway). 942 If the P-DCS-LAES header is present in the first reliable 1xx 943 (except 100), 2xx or 3xx response (indicating surveillance is 944 required on the terminating subscriber, but that the terminating 945 equipment is unable to perform that function), the UAC MUST include 946 this information in the Authorization for Quality of Service, or 947 MUST signal this information to the device performing the intercept 948 (e.g. a Media Gateway). 950 If a 3xx-Redirect response is received to the initial INVITE 951 request, and if a P-DCS-LAES header is present in the 3xx response, 952 the UAC SHOULD include that header unchanged in the reissued INVITE. 953 The UAC SHOULD also include a P-DCS-Redirect header containing the 954 original dialed number, the new destination number, and the number 955 of redirections that have occurred. Although it is technically 956 possible for the originating equipment to perform this surveillance 957 (or add to its existing surveillance of the call), the design of the 958 surveillance system has the terminating equipment performing the 959 surveillance for all the intermediate forwardings. 961 A UAC that includes a Refer-to header in a REFER request, when the 962 originating subscriber has an outstanding lawfully authorized 963 surveillance order, SHOULD include a P-DCS-LAES header attached to 964 the Refer-to. The P-DCS-LAES header SHOULD include the address and 965 port of the local Electronic Surveillance Delivery Function for a 966 copy of the call's event messages, SHOULD include the address and 968 DCS Group Category Informational - Expiration 9/1/03 18 969 port of the local Electronic Surveillance Delivery Function for the 970 copy of call content if call content is to be intercepted, and 971 SHOULD include a random string for use as a security key between the 972 Delivery Functions. 974 The trusted UAC MUST NOT send the P-DCS-LAES and P-DCS-Redirect 975 headers to an untrusted entity. 977 8.4 Procedures at an Untrusted User Agent Server (UAS) 979 This header MUST NOT be sent to an untrusted UAS, and MUST NOT be 980 sent by an untrusted UAS. 982 8.5 Procedures at a Trusted User Agent Server (UAS) 984 The UAS checks for an outstanding lawfully authorized surveillance 985 order for the terminating subscriber, or presence of the P-DCS-LAES 986 header in the INVITE request. If either is present, the UAS 987 includes this information in the authorization for Quality of 988 Service[7]. 990 If the terminating equipment is unable to perform the required 991 surveillance (e.g. if the destination is a voicemail server), the 992 UAS SHOULD include a P-DCS-LAES header in the first reliable non-100 993 response requesting the originating proxy to perform the 994 surveillance. The P-DCS-LAES header SHOULD include the address and 995 port of the local Electronic Surveillance Delivery Function for a 996 copy of the call's event messages, SHOULD include the address and 997 port of the local Electronic Surveillance Delivery Function for the 998 copy of call content if call content is to be intercepted, and 999 SHOULD include a random string for use as a security key between the 1000 Delivery Functions. 1002 If the response to the initial INVITE request is a 3xx-Redirect 1003 response, and there is an outstanding lawfully authorized 1004 surveillance order for the terminating subscriber, the UAS SHOULD 1005 include a P-DCS-LAES header in the 3xx-Redirect response, with 1006 contents as described above. 1008 The trusted UAS MUST NOT send the P-DCS-LAES and P-DCS-Redirect 1009 headers to an untrusted entity. 1011 8.6 Procedures at Proxy 1013 Two sets of proxy procedures are defined: (1) the procedures at an 1014 originating proxy, and (2) the procedures at a terminating proxy. 1015 The originating proxy is a proxy that received the INVITE request 1016 from a non-trusted endpoint. 1018 The terminating proxy is a proxy that sends the INVITE request to a 1019 non-trusted endpoint. 1021 DCS Group Category Informational - Expiration 9/1/03 19 1022 For purposes of mid-call changes, such as call transfers, the proxy 1023 that receives the request from a non-trusted endpoint is considered 1024 the initiating proxy; the proxy that sends the request to a non- 1025 trusted endpoint is considered the recipient proxy. Procedures for 1026 the initiating proxy are included below with those for originating 1027 proxies, while procedures for the recipient proxy are included with 1028 those for terminating proxies. 1030 A proxy that both receives the INVITE request from an untrusted 1031 endpoint, and sends the INVITE request to a non-trusted endpoint, 1032 MUST NOT generate P-DCS-LAES nor P-DCS-Redirect headers. 1034 A proxy that is neither an originating proxy nor a terminating proxy 1035 SHOULD pass the P-DCS-Laes and P-DCS-Redirect headers in requests 1036 and responses. 1038 8.6.1 Procedures at Originating Proxy 1040 The Originating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect 1041 headers in requests or responses to or from an untrusted proxy or 1042 untrusted UA. 1044 The originating proxy checks for an outstanding lawfully authorized 1045 surveillance order for the originating subscriber, and, if present, 1046 includes this information in the Authorization for Quality of 1047 Service[7] or signals this information to the device performing the 1048 intercept (e.g. a Media Gateway). 1050 If the P-DCS-LAES header is present in the first reliable 1xx 1051 (except 100), 2xx or 3xx response (indicating surveillance is 1052 required on the terminating subscriber, but that the terminating 1053 equipment is unable to perform that function), the originating proxy 1054 MUST include this information in the Authorization for Quality of 1055 Service, or MUST signal this information to the device performing 1056 the intercept (e.g. a Media Gateway). 1058 If the Request-URI in an initial INVITE request contains a private- 1059 URL, the originating proxy MUST decrypt the userinfo information to 1060 find the real destination for the call, and other special processing 1061 information. If electronic surveillance information is contained in 1062 the decrypted userinfo, the originating proxy SHOULD generate a P- 1063 DCS-LAES header with the surveillance information. 1065 If a 3xx-Redirect response is received to the initial INVITE request 1066 prior to a 18x, and if a P-DCS-LAES header is present in the 3xx 1067 response, the originating proxy SHOULD include that header unchanged 1068 in the reissued INVITE. The originating proxy SHOULD also include a 1069 P-DCS-Redirect header containing the original dialed number, the new 1070 destination number, and the number of redirections that have 1071 occurred. 1073 If a 3xx-Redirect response is received to the initial INVITE request 1074 after a 18x, the originating proxy generates a private-URL and 1076 DCS Group Category Informational - Expiration 9/1/03 20 1077 places it in the Contact header of a 3xx-Redirect response sent to 1078 the originating endpoint. If a P-DCS-LAES header is present in the 1079 3xx response, this private-URL MUST contain (1) the electronic 1080 surveillance information from the 3xx-Redirect response, (2) the 1081 original destination number, (3) the identity of the redirecting 1082 party, and (4) the number of redirections of this call. 1084 An originating proxy that processes a REFER request [4] from an 1085 untrusted UA, when the originating subscriber has an outstanding 1086 lawfully authorized surveillance order, becomes a B2BUA for that 1087 request. It SHOULD reissue the request with a P-DCS-LAES header 1088 added to the Refer-to's URL. The P-DCS-LAES header SHOULD include 1089 (1) the address and port of the local Electronic Surveillance 1090 Delivery Function for a copy of the call's event messages, (2) the 1091 address and port of the local Electronic Surveillance Delivery 1092 Function for the copy of call content if call content is to be 1093 intercepted, and (3) a random string for use as a security key 1094 between the Delivery Functions. 1096 An initiating proxy that sends a mid-call REFER request including a 1097 Refer-to header, when the initiating subscriber has an outstanding 1098 lawfully authorized surveillance order, SHOULD include a P-DCS-LAES 1099 header in the Refer-to's URL. 1101 The originating proxy MUST NOT send the P-DCS-LAES and P-DCS- 1102 Redirect headers to an untrusted entity. 1104 8.6.2 Procedures at Terminating Proxy 1106 The Terminating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect 1107 headers in requests or responses to or from an untrusted proxy or 1108 UA. 1110 The terminating proxy checks for an outstanding lawfully authorized 1111 surveillance order for the terminating subscriber. If present, the 1112 terminating proxy includes this information in the authorization for 1113 Quality of Service[7]. 1115 The terminating proxy MUST NOT send the P-DCS-LAES and P-DCS- 1116 Redirect headers to an untrusted entity, either as headers in the 1117 request or response, or as headers attached to URIs in the request 1118 or response. 1120 If the terminating equipment is unable to perform the required 1121 surveillance (e.g. if the destination is a voicemail server), the 1122 terminating proxy SHOULD include a P-DCS-LAES header in the first 1123 reliable 1xx/2xx/3xx (except 100) response requesting the 1124 originating proxy to perform the surveillance. The P-DCS-LAES 1125 header SHOULD include the address and port of the local Electronic 1126 Surveillance Delivery Function for a copy of the call's event 1127 messages, SHOULD include the address and port of the local 1128 Electronic Surveillance Delivery Function for the copy of call 1129 content if call content is to be intercepted, and SHOULD include a 1131 DCS Group Category Informational - Expiration 9/1/03 21 1132 random string for use as a security key between the Delivery 1133 Functions. 1135 If the response to the initial INVITE request is a 3xx-Redirect 1136 response, and there is an outstanding lawfully authorized 1137 surveillance order for the terminating subscriber, the terminating 1138 proxy SHOULD include a P-DCS-LAES header in the 3xx-Redirect 1139 response, with contents as described above. 1141 A proxy receiving a mid-call REFER request [4] that includes a 1142 Refer-to header with a P-DCS-LAES header attached becomes a B2BUA 1143 for this request. It MUST generate a private-URL and place it in 1144 the Refer-to header sent to the endpoint. This private-URL MUST 1145 contain the P-DCS-LAES information from the attached header. 1147 9. Security Considerations 1149 QoS gate coordination, billing information, and electronic 1150 surveillance information are all considered to be sensitive 1151 information that MUST be protected from eavesdropping and 1152 furthermore require integrity checking. It is therefore necessary 1153 that the trusted UAs and proxies take precautions to protect this 1154 information from eavesdropping and tampering. Use of IPSec or TLS 1155 between Proxies is REQUIRED. Also REQUIRED is mutual authentication 1156 (1) between Proxies and (2) between trusted UAs and Proxies, both of 1157 which MAY be implemented with administratively pre-shared keys, or 1158 through consultation with another trusted third party. If IPSec is 1159 to be used, the specification of the security policies and 1160 procedures of the administrative domain where these headers are 1161 applicable (and all connections between administrative domains in 1162 the federation) MUST define an interoperable set of options. 1164 10. IANA Considerations 1166 This document defines a number of SIP extension headers, which 1167 should be included in the registry of SIP headers defined in [2]. 1168 Registration information for new headers is as follows: 1170 Header Field Name: P-DCS-Trace-Party-ID 1171 RFC Number: XXXX [number of this document] 1172 Compact Form: none 1174 Header Field Name: P-DCS-OSPS 1175 RFC Number: XXXX [number of this document] 1176 Compact Form: none 1178 Header Field Name: P-DCS-Billing-Info 1179 RFC Number: XXXX [number of this document] 1180 Compact Form: none 1182 Header Field Name: P-DCS-LAES 1183 RFC Number: XXXX [number of this document] 1184 Compact Form: none 1186 DCS Group Category Informational - Expiration 9/1/03 22 1187 Header Field Name: P-DCS-Redirect 1188 RFC Number: XXXX [number of this document] 1189 Compact Form: none 1191 11. Notice Regarding Intellectual Property Rights 1193 The IETF has been notified of intellectual property rights claimed 1194 in regard to some or all of the specification contained in this 1195 document. For more information consult the online list of claimed 1196 rights. 1198 12. Normative References 1200 1. Bradner, S., "Key words for use in RFCs to Indicate Requirement 1201 Levels", BCP 14, RFC 2119, March 1997 1203 2. Rosenberg, J, et al, "The Session Initiation Protocol", RFC 3261, 1204 June 2002. 1206 3. Crocker, D., and Overell P., "Augmented BNF for Syntax 1207 Specifications: ABNF", RFC 2234, November 1997. 1209 4. Sparks, R., "The SIP REFER Method", RFC pending. 1211 5. IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. 1213 13. Informative References 1215 6. DCS Group, "Architectural Considerations for Providing Carrier 1216 Class Telephony Services Utilizing SIP-based Distributed Call 1217 Control Mechanisms", draft-dcsgroup-sipping-arch-01.txt, January 1218 2003. 1220 7. PacketCable Dynamic Quality of Service Specification, pkt-sp- 1221 dqos-i05-021127. November, 2002. 1223 8. PacketCable Security Specification, pkt-sp-sec-i07-021127. 1224 November, 2002. 1226 9. PacketCable Event Message Specification, pkt-sp-em-i05-021127. 1227 November, 2002. 1229 10. Jennings, C., Peterson, J., and Watson, M., Private Extensions 1230 to the Session Initiation Protocol (SIP) for Asserted Identity 1231 within Trusted Networks, RFC3325, November 2002. 1233 14. Acknowledgements 1235 The Distributed Call Signaling work in the PacketCable project is 1236 the work of a large number of people, representing many different 1238 DCS Group Category Informational - Expiration 9/1/03 23 1239 companies. The authors would like to recognize and thank the 1240 following for their assistance: John Wheeler, Motorola; David 1241 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 1242 Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 1243 Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 1244 Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 1245 Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- 1246 Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 1247 Cable Communications. 1249 Previous versions further acknowledged, as co-authors, several 1250 people for providing the text of this document. They are: Bill 1251 Marshall (wtm@research.att.com) and K. K. Ramakrishnan 1252 (kkrama@research.att.com), AT&T; Ed Miller 1253 (edward.miller@terayon.com), Terayon; Glenn Russell 1254 (G.Russell@Cablelabs.com), CableLabs; Burcak Beser 1255 (burcak@juniper.net) Juniper Networks, Mike Mannette 1256 (Michael_Mannette@3com.com) and Kurt Steinbrenner 1257 (Kurt_Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com) and 1258 Flemming Andreasen (fandreas@cisco.com), Cisco Systems; John Pickens 1259 (jpickens@com21.com), Com21; Poornima Lalwaney 1260 (poornima.lalwaney@nokia.com), Nokia; Jon Fellows 1261 (jfellows@coppermountain.com), Copper Mountain Networks; Doc Evans 1262 (n7dr@arrisi.com) Arris, and Keith Kelly (keith@netspeak.com), 1263 NetSpeak. 1265 15. Editor's Addresses 1267 Bill Marshall 1268 AT&T 1269 Florham Park, NJ 07932 1270 Email: wtm@research.att.com 1272 Flemming Andreasen 1273 Cisco 1274 Edison, NJ 1275 Email: fandreas@cisco.com 1277 DCS Group Category Informational - Expiration 9/1/03 24 1278 Full Copyright Statement 1280 "Copyright (C) The Internet Society (2003). All Rights Reserved. 1281 This document and translations of it may be copied and furnished to 1282 others, and derivative works that comment on or otherwise explain it 1283 or assist in its implementation may be prepared, copied, published 1284 and distributed, in whole or in part, without restriction of any 1285 kind, provided that the above copyright notice and this paragraph 1286 are included on all such copies and derivative works. However, this 1287 document itself may not be modified in any way, such as by removing 1288 the copyright notice or references to the Internet Society or other 1289 Internet organizations, except as needed for the purpose of 1290 developing Internet standards in which case the procedures for 1291 copyrights defined in the Internet Standards process must be 1292 followed, or as required to translate it into languages other than 1293 English. The limited permissions granted above are perpetual and 1294 will not be revoked by the Internet Society or its successors or 1295 assigns. This document and the information contained herein is 1296 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1297 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1298 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1299 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1300 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1302 This memo is filed as , 1303 and expires September 1, 2003. 1305 Acknowledgement 1307 Funding for the RFC Editor function is currently provided by the 1308 Internet Society. 1310 DCS Group Category Informational - Expiration 9/1/03 25