HomeDocsIETF standardsRFCRFC 5500 — 5599
Text version
Network Working Group
Request for Comments: 5503
Obsoletes: 3603
Category: Informational
F. Andreasen
Cisco
B. McKibben
CableLabs
B. Marshall
AT&T
March 2009

Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for

Supporting the PacketCable Distributed Call Signaling Architecture

Status of This Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Abstract

In order to deploy a residential telephone service at a very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol, RFC 3261, for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.

Table of Contents

   1. Applicability Statement .........................................4
   2. Introduction ....................................................4
   3. Trust Boundary ..................................................6
   4. Conventions Used in This Document ...............................7
   5. P-DCS-TRACE-PARTY-ID ............................................7
      5.1. Syntax .....................................................8
      5.2. Procedures at an Untrusted User Agent Client (UAC) .........9
      5.3. Procedures at a Trusted User Agent Client (UAC) ............9
      5.4. Procedures at an Untrusted User Agent Server (UAS) .........9
      5.5. Procedures at a Trusted User Agent Server (UAS) ............9
      5.6. Procedures at Proxy .......................................10
           5.6.1. Procedures at Originating Proxy ....................10
           5.6.2. Procedures at Terminating Proxy ....................11
   6. P-DCS-OSPS .....................................................11
      6.1. Syntax ....................................................11
      6.2. Procedures at an Untrusted User Agent Client (UAC) ........12
      6.3. Procedures at a Trusted User Agent Client (UAC) ...........12
      6.4. Procedures at an Untrusted User Agent Server (UAS) ........13
      6.5. Procedures at a Trusted User Agent Server (UAS) ...........13
      6.6. Procedures at Proxy .......................................14
   7. P-DCS-BILLING-INFO .............................................14
      7.1. Syntax ....................................................16
      7.2. Procedures at an Untrusted User Agent Client (UAC) ........18
      7.3. Procedures at a Trusted User Agent Client (UAC) ...........18
      7.4. Procedures at an Untrusted User Agent Server (UAS) ........18
      7.5. Procedures at a Trusted User Agent Server (UAS) ...........18
      7.6. Procedures at Proxy .......................................19
           7.6.1. Procedures at Originating Proxy ....................19
           7.6.2. Procedures at Terminating Proxy ....................20
           7.6.3. Procedures at Tandem Proxy .........................21
   8. P-DCS-LAES and P-DCS-Redirect ..................................21
      8.1. Syntax ....................................................23
      8.2. Procedures at an Untrusted User Agent Client (UAC) ........24
      8.3. Procedures at a Trusted User Agent Client (UAC) ...........24
      8.4. Procedures at an Untrusted User Agent Server (UAS) ........25
      8.5. Procedures at a Trusted User Agent Server (UAS) ...........25
      8.6. Procedures at Proxy .......................................26
           8.6.1. Procedures at Originating Proxy ....................26
           8.6.2. Procedures at Terminating Proxy ....................28
   9. Security Considerations ........................................29
   10. IANA Considerations ...........................................29
   11. Changes since RFC 3603 ........................................31
   12. Acknowledgments ...............................................32
   13. References ....................................................32
      13.1. Normative References .....................................32
      13.2. Informative References ...................................33

1. Applicability Statement

The Session Initiation Protocol (SIP) [RFC3261] extensions described in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions are generally not applicable in the Internet as a whole. The use of these headers is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required, as in, for example, the architecture presented in [DCSARCH]. Use outside such a domain could result in the leakage of potentially sensitive or private information. User consent to the privacy implications of the policies in [DCSARCH] is strongly encouraged in those domains as well.

Although [RFC2119] language is used in this document, the scope of the normative language is only for the area of applicability of the document and, like the technology, it does not apply to the general Internet.

2. Introduction

In order to deploy a SIP based residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys billing information and expectations about the parties involved in the call.

There are many billing models used in deriving revenue from telephony services today. Charging for telephony services is tightly coupled to the use of network resources. It is outside the scope of this document to discuss the details of these numerous and varying methods.

A key motivating principle of the Distributed Call Signaling (DCS) architecture described in [DCSARCH] is the need for network service providers to be able to control and monitor network resources; revenue may be derived from the usage of these resources as well as from the delivery of enhanced services such as telephony. Furthermore, the DCS architecture recognizes the need for coordination between call signaling and resource management. This coordination ensures that users are authenticated and authorized before receiving access to network resources and billable enhanced services.

DCS Proxies, as defined in [DCSARCH], have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path. Edge routers provide the network connectivity and resource policy enforcement mechanism and also capture and report network connectivity and resource usage information. Edge routers need to be given billing information that can be logged with Record-Keeping or Billing servers. The DCS Proxy, as a central point of coordination between call signaling and resource management, can provide this information based on the authenticated identity of the calling and called parties. Since there is a trust relationship among DCS Proxies, they can be relied upon to exchange trusted billing information pertaining to the parties involved in a call. See [DCSARCH] for a description of the trust boundary and trusted versus untrusted entities.

For these reasons, it is appropriate to consider defining SIP header extensions to allow DCS Proxies to exchange information during call setup. The extensions only appear on trusted network segments, are inserted upon entering a trusted network region, and are removed before leaving trusted network segments.

Significant amounts of information are retrieved by an originating DCS Proxy in its handling of a connection setup request from a user agent. Such information includes location information about the subscriber (essential for emergency services calls), billing information, and station information (e.g., coin-operated phone). In addition, while translating the destination number, information such as the local-number-portability office code is obtained and will be needed by all other proxies handling this call.

For Usage Accounting records, it is necessary to have an identifier that can be associated with all the event records produced for the call. The SIP Call-ID header field cannot be used as such an identifier since it is selected by the originating user agent, and it may not be unique among all past calls as well as current calls. Further, since this identifier is to be used by the service provider, it should be chosen in a manner and in a format that meets the service provider's needs.

Billing information may not necessarily be unique for each user (consider the case of calls from an office all billed to the same account). Billing information may not necessarily be identical for all calls made by a single user (consider prepaid calls, credit card calls, collect calls, etc). It is therefore necessary to carry billing information separate from the calling and called party identification. Furthermore, some billing models call for split- charging where multiple entities are billed for portions of the call.

The addition of a SIP General Header Field allows for the capture of billing information and billing identification for the duration of the call.

The billing extensions only appear on trusted network segments and MAY be inserted by a DCS Proxy in INVITE and REFER requests and INVITE responses in a trusted network segment, and removed before leaving trusted network segments.

In addition to support for billing, current residential telephone service includes the need for customer-originated trace (of harassing or obscene calls), for operator services such as busy line verification and emergency interrupt (initiated by an operator from an Operator Services Position System (OSPS)), for emergency services such as 9-1-1 calls to a Public Service Access Point (PSAP) and the subsequent call handling, and for support of Electronic Surveillance and Law Enforcement access as required by applicable legislation and court orders. In all of these cases, additional information about the call and about the subscribers involved in the call needs to be exchanged between the proxies.

3. Trust Boundary

The DCS architecture [DCSARCH] defines a trust boundary around the various systems and servers that are owned, operated by, and/or controlled by the service provider. These trusted systems include the proxies and various servers such as bridge servers, voicemail servers, announcement servers, etc. Outside of the trust boundary lie the customer premises equipment and various application and media servers operated by third-party service providers.

Certain subscriber-specific information, such as billing and accounting information, stays within the trust boundary. Other subscriber-specific information, such as endpoint identity, may be presented to untrusted endpoints or may be withheld based on subscriber profiles.

The User Agent (UA) may be either within the trust boundary or outside the trust boundary, depending on exactly what function is being performed and exactly how it is being performed. Accordingly, the procedures followed by a user agent are different depending on whether the UA is within the trust boundary or outside the trust boundary.

The following sections giving procedures for user agents therefore are subdivided into trusted user agents and untrusted user agents. Since UAs may support client and server functions, the UA sections include procedures for the User Agent Client (UAC) and User Agent Server (UAS).

4. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].

The term "private-URL" used in this document refers to a SIP URI that is generated by a proxy, contains a "hostport" that identifies the proxy, and contains a "userinfo" string that is generated by the proxy. The userinfo typically contains (or points to) information that is not to be disclosed outside the trusted domain of the proxies, such as billing account numbers, electronic surveillance indication, electronic surveillance parameters, and call redirection information. Consequently, the information is either stored locally by the proxy, or encrypted with a private key known only to the proxy and encoded in a character string in the userinfo portion of the URL. A checksum is included in the userinfo data to detect tampering. The mechanism by which a proxy recognizes a userinfo as a private-URL and decodes and recovers the original information is local to the proxy and is not subject to standardization. Some possible implementations include an initial magic cookie (e.g., z9hG4Bk followed by the pointer/information), or use of a reserved "user" name (e.g., "private") with the optional "password" containing the pointer/ information.

5. P-DCS-TRACE-PARTY-ID

In the telephone network, calling identity information is used to support regulatory requirements such as the Customer Originated Trace service, which provide the called party with the ability to report obscene or harassing phone calls to law enforcement. This service is provided independently of caller-id, and works even if the caller requested anonymity. The calling party is here identified as the station originating the call. In order for this service to be dependable, the called party must be able to trust that the calling identity information being presented is valid. One way to achieve this is described in [RFC3325].

To initiate a customer-originated-trace from an untrusted User Agent Client (UAC), an additional header is defined for the INVITE request. This header is called P-DCS-Trace-Party-ID, and does not appear in any other request or response. The untrusted UAC also includes the

Target-Dialog header field, defined in [RFC4538], in the INVITE request in order to explicitly identify the call to be traced. The entity addressed by the Request-URI performs the service-provider- specific functions of recording and reporting the caller identity in the P-DCS-Trace-Party-ID for law enforcement action. It then forwards the call to either an announcement server or to the service provider's business office to collect further information about the complaint. A trusted UAC does not use this header, as it initiates this action locally.

5.1. Syntax

The ABNF description of this header is (some terms used in this ABNF are defined in [RFC3261]): 

   P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr
                           *1(SEMI timestamp-param) *(SEMI trace-param)
   timestamp-param      = "timestamp=" 1*DIGIT ["." 1*DIGIT]
   trace-param          = generic-param ; defined in RFC 3261

This document adds the following entry to Table 2 of [RFC3261]: 

   Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG  PUB
   ------------         ----- -----  ---  ---  ---  ---  ---  ---  ---
   P-DCS-Trace-Party-ID   R    dmr    -    -    -    o    -    -    -
   
                                     SUB  NOT  REF  INF  UPD  PRA  MSG
                                     ---  ---  ---  ---  ---  ---  ---
                                      -    -    -    -    -    -    -

The addr-spec contained in name-addr contains a URL that identifies the remote endpoint. Addr-spec typically contains a tel URL or SIP URI giving the identity of the remote endpoint, as provided in the signaling messages that established the session to be traced.

The timestamp-param contains the value of the time the UA determines it received the session initiation request of the call requested to be traced. The timestamp-param is populated using the Network Time Protocol timestamp format defined in RFC 1305 [RFC1305] and used by the Simple Network Time Protocol [RFC4330]. The timestamp SHOULD be encoded in UTF-8 Format per [RFC3629]. The trace-param is a generic parameter for future extensions.

An example of the P-DCS-Trace-Party-ID header is shown as follows: 

   P-DCS-Trace-Party-ID: <sip:+12345678912@domain.com;user=phone>;
   timestamp=3434688831.2327

5.2. Procedures at an Untrusted User Agent Client (UAC)

The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial INVITE message for a customer-originated-trace request. The trace request from the Untrusted User Agent Client is able to be initiated during the dialog or after the release of the dialog or call that is requested to be traced. The UAC MUST use a SIP URI in the Request- URI with userinfo set to "call-trace" and hostport identifying the call tracing entity for the untrusted UA. The [RFC3603] version of the P-DCS-Trace-Party-ID did not include the timestamp-param parameter; however, the syntax is backwards compatible with [RFC3603]. A UAC compliant to this updated specification MUST insert the timestamp and the Target-Dialog header field defined in [RFC4538] if known to the UAC.

In case of an anonymous malicious call, where the remote party is not known to the Untrusted UAC, the Untrusted UAC SHOULD indicate the user as anonymous in the P-DCS-Trace-Party-ID, for example, as follows: sip:anonymous@anonymous.invalid.

5.3. Procedures at a Trusted User Agent Client (UAC)

A trusted UAC performs the customer-originated-trace in a manner similar to the trusted User Agent Server (UAS), described below. A trusted UAC MUST NOT include this header in any request.

5.4. Procedures at an Untrusted User Agent Server (UAS)

This header MUST NOT appear in any response sent by a UAS.

5.5. Procedures at a Trusted User Agent Server (UAS)

If the P-DCS-Trace-Party-ID header is present in the initial INVITE request from a UAC, and the Request-URI of the INVITE has userinfo set to "call-trace" and hostport set to the UAS, the UAS MUST perform the service-provider-specific functions of recording and reporting the caller identity and associated trace parameters (if any) from the Target-Dialog header field for law enforcement action. The UAS then MUST redirect the call, via a 3xx response, to either an announcement server or to the service provider's business office to collect further information about the complaint.

This header MUST NOT appear in any response sent by a UAS.

If the P-DCS-Trace-Party-ID header is not present in the initial INVITE request from a UAC, and the Request-URI of the INVITE has userinfo set to "call-trace" the UAS MUST reject the request.

5.6. Procedures at Proxy

Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from an untrusted endpoint.

The terminating proxy is a proxy that sends the INVITE request to an untrusted endpoint.

A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to an untrusted endpoint, performs both sets of procedures.

5.6.1. Procedures at Originating Proxy

If the P-DCS-Trace-Party-ID header is present in the initial INVITE request from the UAC, and the Request-URI of the INVITE has userinfo other than "call-trace" and hostport set to other than a potentially provisioned call tracing entity, then the proxy MAY reject the request, or it MAY remove the P-DCS-Trace-Party-ID header from the request. If the header is present in a valid request, and contains a private-URL that identifies the proxy in the hostport, then the originating proxy SHOULD replace the private-URL with its original contents (i.e., the verified identity of the caller of the session that is being traced and trace parameters from the Target-Dialog header fields defined in [RFC4538]).

The proxy records the caller URL and target dialog IDs on sessions directed toward the untrusted UAC if provisioned to do so by the network operator. If the is P-DCS-Trace-Party-ID header is present in a valid request, and contains an anonymous caller indication in the name-addr parameter, the originating proxy MUST replace the anonymous URL with the verified identity of the caller of the session that is being traced if available and recorded by the proxy. Otherwise, the proxy does not replace the anonymous URL.

If the origination proxy is provisioned to store URLs and target dialog IDs for incoming calls, and if the proxy detects that the URL and target dialog ID in a trace request does not match a recorded incoming dialog request, then the proxy MUST reject the trace call request.

The origination proxy does not add the P-DCS-Trace-Party-ID header from a request that does not already contain the header.

5.6.2. Procedures at Terminating Proxy

This header MUST NOT appear in any request or response sent by a terminating proxy to an untrusted endpoint.

6. P-DCS-OSPS

Some calls have special call processing requirements that may not be satisfied by normal user agent call processing. For example, when a user is engaged in a call and another call arrives, such a call might be rejected with a busy indication. However, some Public Switched Telephone Network (PSTN) operator services require special call processing. In particular, the Busy Line Verification (BLV) and Emergency Interrupt (EI) services initiated by an operator from an Operator Services Position System (OSPS) on the PSTN network have such a need. Similarly, emergency calls to a 9-1-1 Public Service Access Point (PSAP) may result in trunk signaling causing operator ringback using a howling tone or sustained ring on the originating line (country-specific variations may exist).

In order to inform the SIP user agent that special treatment should be given to a call, we use a new P-DCS-OSPS header, with a field that may be set to a value indicating when a special type of call processing is requested. We define three values in this header field, namely "BLV" for busy line verification, "EI" for emergency interrupt, and "RING" for operator ringback (e.g., howling/sustained tone ring in the US).

If the user agent decides to honor such a request, the response of the user agent to an INVITE with either "BLV" or "EI" will not be a busy indication. Since "EI" and "RING" only occur on established dialogs, they may also appear in UPDATE requests.

6.1. Syntax

The ABNF description of the P-DCS-OSPS header is as follows (some terms used in this ABNF are defined in [RFC3261]): 

      P-DCS-OSPS      = "P-DCS-OSPS" HCOLON OSPS-Tag
      OSPS-Tag        = "BLV" / "EI" / "RING" / token

This document adds the following entry to Table 2 of [RFC3261]: 

     Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG  PUB
     ------------         ----- -----  ---  ---  ---  ---  ---  ---  ---
     P-DCS-OSPS             R     dr    -    -    -    o    -    -    -
                                       SUB  NOT  REF  INF  UPD  PRA  MSG
                                       ---  ---  ---  ---  ---  ---  ---
                                        -    -    -    -    o    -    -

The OSPS-Tag value of "token" is defined for extensibility, and is reserved for future use.

6.2. Procedures at an Untrusted User Agent Client (UAC)

The P-DCS-OSPS header MUST NOT be sent in a request from an untrusted UAC.

6.3. Procedures at a Trusted User Agent Client (UAC)

This header is typically only inserted by a Media Gateway Controller [DCSARCH] that is controlling a Media Gateway with special trunks to a PSTN OSPS system or PSAP. This trunk group is usually referred to as a BLV-trunk group and employs special signaling procedures that prevent inadvertent use. Calls originating at the PSTN OSPS system are sent over this trunk group, and result in an INVITE request with the P-DCS-OSPS header.

This header MAY be sent in an INVITE request, and MUST NOT appear in any message other than those listed below.

OSPS-Tag value "BLV" MUST NOT appear in any request other than an initial INVITE request establishing a new dialog.

OSPS-Tag value "EI" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a preexisting dialog established with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a preexisting dialog established with the OSPS-Tag value of "BLV".

OSPS-Tag value "RING" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a preexisting dialog established by a UAC to an operator or PSAP, or (2) an UPDATE request within a preexisting dialog established by a UAC to an operator or PSAP.

6.4. Procedures at an Untrusted User Agent Server (UAS)

If the UAS receives an INVITE request with an OSPS-Tag of "BLV", dialog identification that matches an existing dialog, it MUST reject the request with a 403 (Forbidden) response.

If the UAS receives an INVITE/UPDATE request with an OSPS-Tag value of "EI" or "RING", with dialog identification that does not match an existing dialog that was established with the OSPS-Tag value of "BLV", it MUST reject the request with a 403 (Forbidden) response.

If the UAS receives an INVITE that contains an OSPS-Tag value of "BLV" and is not willing to cooperate in offering this service, it MUST reject the request with a 403 (Forbidden) response.

The UAS SHOULD NOT reject an INVITE with a "BLV" OSPS-Tag due to a busy condition. The UAS MUST NOT respond with a 3xx-Redirect response code to an INVITE with a "BLV" OSPS-Tag. The UAS SHOULD NOT alert the user of the incoming call attempt if the "BLV" OSPS-Tag is present in the INVITE.

If an INVITE with OSPS-Tag of "BLV" is accepted (e.g., meeting all quality-of-service (QoS) pre-conditions, etc.), the UAS MUST send an audio stream on this connection to the address and port given in the Session Description Protocol (SDP) of the INVITE. The UAS MAY perform a mixing operation between the two ends of an existing active call and send the resulting media stream to the address and port indicated. Alternatively, the UAS MAY send a copy of the local voice stream, and (if there is no activity on the local voice stream) send a copy of the received voice stream of an existing call. If the state of the UAS is idle, the UAS SHOULD send a stream of silence packets to OSPS. If the state of the UAS is ringing or ringback, the UAS SHOULD send a ringback stream to OSPS.

If an INVITE/UPDATE with OSPS-Tag of "EI" is accepted, the UAS MUST enable communication between the UAC and the local user. The UAS MAY put any existing call on hold, or initiate an ad hoc conference.

If an INVITE/UPDATE with OSPS-Tag of "RING" is accepted, the UAS MUST perform operator ringback in accordance with local procedures, e.g., generate a 3-second howling tone or a sustained ring, depending on the state of the user equipment.

6.5. Procedures at a Trusted User Agent Server (UAS)

The procedures at a trusted UAS MUST be identical to those described in 6.4.

6.6. Procedures at Proxy

In the DCS architecture, the OSPS is considered a trusted UAC. If a proxy receives a P-DCS-OSPS header in a request from an untrusted source, it MUST either remove the header or reject the request with a 403 (Forbidden) response.

A proxy that implements a call-forwarding service MUST NOT respond to an INVITE request with a 3xx response, if the request contained the P-DCS-OSPS header.

7. P-DCS-BILLING-INFO

There are many billing models used in deriving revenue from telephony services today. Charging for telephony services is tightly coupled to the use of network resources. It is outside the scope of this document to discuss the details of these numerous and varying methods.

Proxies have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path. Edge routers provide the network connection and resource policy enforcement mechanism and also capture and report network connection and resource usage information. Edge routers need to be given billing information that can be logged with Record-Keeping or Billing servers. The proxy, as a central point of coordination between call signaling and resource management, can provide this information based on the authenticated identity of the calling and called parties. Since there is a trust relationship among proxies, they can be relied upon to exchange trusted billing information pertaining to the parties involved in a call.

For Usage Accounting records, it is necessary to have an identifier that can be associated with all the event records produced for the call. The SIP Call-ID header field cannot be used as such an identifier since it is selected by the originating user agent, and may not be unique among all past calls as well as current calls. Further, since this identifier is to be used by the service provider, it should be chosen in a manner and in a format that meets the service provider's needs.

Billing information may not necessarily be unique for each user (consider the case of calls from an office all billed to the same account). Billing information may not necessarily be identical for all calls made by a single user (consider prepaid calls, credit card calls, collect calls, etc). It is therefore necessary to carry billing information separate from the calling and called party identification. Furthermore, some billing models call for split-charging where multiple entities are billed for portions of the call.

The addition of a SIP General Header Field allows for the capture of billing information and billing identification for the duration of the call.

The billing extensions only appear on trusted network segments, and MAY be inserted by a proxy or trusted UA in INVITE and SUBSCRIBE requests in a trusted network segment, and removed before leaving trusted network segments. The P-DCS-Billing-Info header extension is used only on requests and responses between proxies and trusted UAs. It is never sent to an untrusted UA. It is expected that untrusted UAs do not send this header.

7.1. Syntax

The DCS-Billing-Info header is defined by the following ABNF (some terms used in this ABNF are defined in [RFC3261]): 

   P-DCS-Billing-Info      = "P-DCS-Billing-Info" HCOLON
                              Billing-Correlation-ID "/" FEID
                              *(SEMI Billing-Info-param)
   Billing-Correlation-ID  = 1*48(HEXDIG)
   FEID                    = 1*16(HEXDIG) "@" host
   Billing-Info-param      = RKS-Group-ID-param / Charge-param /
                             Calling-param / Called-param /
                             Routing-param / Loc-Routing-param /
                             JIP-param / generic-param
   RKS-Group-ID-param      = "rksgroup" EQUAL RKS-Group-ID
   RKS-Group-ID            = token
   Charge-param            = "charge" EQUAL Acct-Charge-URI
   Acct-Charge-URI         = LDQUOT addr-spec RDQUOT
   Calling-param           = "calling" EQUAL Acct-Calling-URI
   Acct-Calling-URI        = LDQUOT addr-spec RDQUOT
   Called-param            = "called" EQUAL Acct-Called-URI
   Acct-Called-URI         = LDQUOT addr-spec RDQUOT
   Routing-param           = "routing" EQUAL Acct-Routing-URI
   Acct-Routing-URI        = LDQUOT addr-spec RDQUOT
   Loc-Routing-param       = "locroute" EQUAL Acct-Loc-Routing-URI
   Acct-Loc-Routing-URI    = LDQUOT addr-spec RDQUOT
   JIP-param               = "jip" EQUAL jip
   jip                     = LDQUOT 1*phonedigit-hex jip-context RDQUOT
   jip-context             = ";jip-context=" jip-descriptor
   jip-descriptor          = global-hex-digits
   global-hex-digits       = "+" 1*3(phonedigit) *phonedigit-hex
   phonedigit              = DIGIT / [ visual-separator ]
   phonedigit-hex          = HEXDIG / "*" / "#" / [ visual-separator ]
   visual-separator        = "-" / "." / "(" / ")"

This document adds the following entry to Table 2 of [RFC3261]: 

   Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG  PUB
   ------------         ----- -----  ---  ---  ---  ---  ---  ---  ---
   P-DCS-Billing-Info         admr    -    -    -    o    -    -    -
   
                                     SUB  NOT  REF  INF  UPD  PRA  MSG
                                     ---  ---  ---  ---  ---  ---  ---
                                      -    -    -    -    -    -    -

The P-DCS-Billing-Info extension contains an identifier that can be used by an event recorder to associate multiple usage records, possibly from different sources, with a billable account. It further contains the subscriber account information, and other information necessary for accurate billing of the service. This header is only used between proxies and trusted UAs.

The Billing-Correlation-ID, BCID, is specified in [PCEM] as a 24-byte binary structure, containing 4 bytes of NTP timestamp, 8 bytes of the unique identifier of the network element that generated the ID, 8 bytes giving the time zone, and 4 bytes of monotonically increasing sequence number at that network element. This identifier is chosen to be globally unique within the system for a window of several months. This MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 48 characters. Leading zeroes MAY be suppressed.

The Financial-Entity-ID (FEID) is specified in [PCEM] as an 8-byte structure, containing the financial identifier for that domain, followed by a domain name. FEID can be associated with a type of service and could be assigned to multiple domains by the same provider. A domain could contain multiple assigned FEIDs. This 8-byte structure MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 16 characters. Trailing zeroes MAY be suppressed. "Host" contains the domain name.

The RKS-Group-ID specifies a Record-Keeping server (or group of cooperating servers) for event messages relating to this call. It is used to control certain optimizations of procedures when multiple event message streams are being sent to the same Record-Keeping server.

Additional parameters contain the information needed for generation of event message records. Acct-Charge-URI, Acct-Calling-URI, Acct- Called-URI, Acct-Routing-URI, and Acct-Loc-Routing-URI are each defined as URLs; they should all contain tel URLs with E.164 formatted addresses. These fields are further defined in [PCEM] under the element identifiers "Charge_Number" (element ID 16), "Calling_Party_Number" (element ID 4), "Called_Party_Number" (element ID 5), "Routing Number" (element ID 25), and "Location_Routing_Number" (element ID 22).

The JIP-param contains the calling jurisdiction information, or numbering plan area, of the network in which the call originated. The field is further defined in [PCEM] under the element identifier "Jurisdiction_Information_Parameter" (element ID 82). An older [RFC3603] compliant implementation may not use the JIP-param.

7.2. Procedures at an Untrusted User Agent Client (UAC)

This header is never sent to an untrusted UA. It is expected that untrusted UAs do not send this header.

7.3. Procedures at a Trusted User Agent Client (UAC)

The UAC MUST generate the Billing-Correlation-ID for the call, and insert it into the P-DCS-Billing-Info header in the initial INVITE or SUBSCRIBE message sent to the terminating entity, along with the charging information for the call. The UAC MUST include its FEID, and the RKS-Group-ID for the Record-Keeping server being used by the UAC. If the UAC performed a Local Number Portability (LNP) query, it MUST include the Routing Number and Location Routing Number returned by the query. If available to the UAC, the UAC MUST include the JIP- param.

If the response to the initial INVITE is a 3xx-Redirect, the UAC generates a new initial INVITE request to the destination specified in the Contact header field, as per standard SIP. If a UAC receives a 3xx-Redirect response to an initial INVITE, the new INVITE generated by the UAC MUST contain the P-DCS-Billing-Info header field values from the 3xx-Redirect response. If the UAC is acting as a back-to-back user agent (B2BUA), instead of generating a new INVITE it MAY generate a private-URL and place it in the Contact header field of a 3xx-Redirect response sent to the originating endpoint. This private-URL MUST contain (or contain a pointer to) the P-DCS- Billing-Info value, which indicates the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the originator to re-use this private-URL for multiple calls.

A UAC that includes a Refer-To header in a REFER request MUST include a P-DCS-Billing-Info header in the Refer-To's URL. This P-DCS- Billing-Info header MUST include the accounting information of the initiator of the REFER.

7.4. Procedures at an Untrusted User Agent Server (UAS)

This header is never sent to an untrusted UAS, and is never sent by an untrusted UAS.

7.5. Procedures at a Trusted User Agent Server (UAS)

The UAS MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE or SUBSCRIBE message. This P-DCS-Billing-Info header MUST include the Billing-Correlation-ID generated by the UAS, the FEID of the UAS, and the RKS-Group-ID of the Record-Keeping server being used by the UAS. The UAS MAY change the values of Acct-Charge-URI if it wishes to override the billing information that was present in the INVITE (e.g., for a toll-free call). The decision to do this and the contents of the new Acct-Charge-URI MUST be determined by service provider policy provisioned in the UAS. If the UAS performed an LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.

The UAS MUST add a P-DCS-Billing-Info header to a 3xx-Redirect response to an initial INVITE, giving the accounting information for the call forwarder, for the call segment from the destination to the forwarded-to destination.

7.6. Procedures at Proxy

Three sets of proxy procedures are defined: (1) the procedures at an originating proxy, (2) the procedures at a terminating proxy, and (3) the procedures at a tandem proxy.

The originating proxy is a proxy that received the INVITE or SUBSCRIBE request from an untrusted endpoint.

The terminating proxy is a proxy that sends the INVITE or SUBSCRIBE request to an untrusted endpoint.

A proxy that is neither an originating proxy nor a terminating proxy is a tandem proxy.

For purposes of mid-call changes, such as call transfers, the proxy that receives the request from an untrusted endpoint is considered the initiating proxy; the proxy that sends the request to a non- trusted endpoint is considered the recipient proxy. Procedures for the initiating proxy are included below with those for originating proxies, while procedures for the recipient proxy are included with those for terminating proxies.

A proxy that both receives the request from an untrusted endpoint, and sends the request to an untrusted endpoint, performs both sets of procedures.

7.6.1. Procedures at Originating Proxy

The originating proxy MUST generate the Billing-Correlation-ID for the call, and insert it into the P-DCS-Billing-Info header in the initial INVITE or SUBSCRIBE message sent to the terminating entity, along with the charging information for the call. The originating proxy MUST include its FEID and the RKS-Group-ID for the

Record-Keeping server being used by the originating proxy. If the originating proxy performed an LNP query, it MUST include the Routing Number, Location Routing Number, and JIP-param returned by the query. Any P-DCS-Billing-Info header present from an untrusted UA MUST be removed.

If the Request-URI contains a private-URL, and the decoded username contains billing information, the originating proxy MUST generate a P-DCS-Billing-Info header with that decrypted information. Otherwise, the originating proxy MUST determine the accounting information for the call originator and insert a P-DCS-Billing-Info header including that information.

If the response to the initial INVITE is a 3xx-Redirect, received prior to a non-100 provisional response, the originating proxy generates a new initial INVITE request to the destination specified in the Contact header field, as per standard SIP. If an originating proxy receives a 3xx-Redirect response to an initial INVITE prior to a non-100 provisional response, the INVITE generated by the proxy MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect response.

If the response to the initial INVITE is a 3xx-Redirect, received after a non-100 provisional response, the originating proxy generates a private-URL and places it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. This private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which indicates the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the originator to re-use this private-URL for multiple calls.

An originating proxy that processes a REFER request from an untrusted UA MUST include a P-DCS-Billing-Info header in the Refer-To's URL. This P-DCS-Billing-Info header MUST include the accounting information of the initiator.

7.6.2. Procedures at Terminating Proxy

The terminating proxy MUST NOT send the P-DCS-Billing-Info header to an untrusted destination.

The terminating proxy MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE or SUBSCRIBE message. This P-DCS-Billing-Info header MUST include the Billing-Correlation-ID generated by the terminating proxy, the FEID of the terminating proxy, and the RKS-Group-ID of the Record- Keeping server being used by the terminating proxy. The terminating proxy MAY change the values of Acct-Charge-URI if it wishes to override the billing information that was present in the INVITE (e.g., for a toll-free call). The decision to do this and the contents of the resulting P-DCS-Billing-Info header MUST be determined by service provider policy provisioned in the terminating proxy. If the terminating proxy performed an LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.

The terminating proxy MUST add P-DCS-Billing-Info headers to a 3xx- Redirect response to an initial INVITE, giving the accounting information for the call forwarder, for the call segment from the destination to the forwarded-to destination.

A proxy receiving a mid-call REFER request that includes a Refer-To header generates a private-URL and places it in the Refer-To header sent to the endpoint. This private-URL MUST contain the P-DCS- Billing-Info value, which indicates the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the endpoint to re-use this private-URL for multiple calls.

7.6.3. Procedures at Tandem Proxy

If the tandem proxy performed an LNP query, it MUST insert the Routing Number and Location Routing Number returned by the query into the P-DCS-Billing-Info header in the first reliable 1xx/2xx/3xx (except 100) response.

8. P-DCS-LAES and P-DCS-Redirect

NOTE: According to RFC 2804 [RFC2804], the IETF supports documentation of lawful intercept technology if it is necessary to develop it. The following section provides such documentation. The [RFC2119] language, as stated above, describes the requirements of the specification only if implemented, and strictly within the applicability domain described above. See RFC 2804 for description of issues regarding privacy, security, and complexity in relation to this technology.

The P-DCS-LAES extension contains the information needed to support Lawfully Authorized Electronic Surveillance. This header contains the address and port of an Electronic Surveillance Delivery Function for delivery of a duplicate stream of event messages related to this call. The header fields MAY also contain the associated BCID for the event stream as well as additional address and port for delivery of call content and associated cccid. The BCID is used to correlate a series of events associated with a single call or session. The cccid is used to identify an intercepted call content to an intercepted call. The P-DCS-LAES header is only used between proxies and trusted UAs. The P-DCS-LAES header defined here is not backwards compatible with that defined in [RFC3603], which is deprecated by the document. This version of the P-DCS-LAES header adds a cccid parameter to support the intercept of content, and deletes security key information. This version does not mandate the use of the BCID.

The P-DCS-Redirect extension contains call identifying information needed to support the requirements of Lawfully Authorized Electronic Surveillance of redirected calls. This header is only used between proxies and trusted UAs.

Note that there is overlap in function between the P-DCS-Redirect header and the History-Info header specified in RFC 4244. The original P-DCS-Redirect came to existence in RFC 3603 before the History-Info. Therefore, the P-DCS-Redirect header is continued here for backwards compatibility with existing implementations.

Use of P-DCS-LAES and P-DCS-Redirect is controlled by a combination of legislation, regulation, and court orders, which MUST be followed. In certain cases, inclusion of these headers will be mandated, and therefore MUST be present in the requests and responses indicated. In other cases, inclusion of these headers will be forbidden, and therefore MUST NOT be present in the request and responses indicated. In the sub-sections that follow, use of "SHOULD" is intended to capture these conflicting situations, e.g., a P-DCS-LAES header SHOULD be included in an initial INVITE means either that it MUST be included or that it MUST NOT be included, based on the applicable court orders.

8.1. Syntax

The formats of the P-DCS-LAES and P-DCS-Redirect headers are given by the following ABNF (some terms used in this ABNF are defined in [RFC3261] and [RFC5234]): 

      P-DCS-LAES        = "P-DCS-LAES" HCOLON Laes-sig
                           *(SEMI Laes-param)
      Laes-sig          = hostport
      Laes-param        = Laes-content / Laes-cccid
                          Laes-bcid / generic-param
      Laes-content      = "content" EQUAL hostport
      
      Laes-bcid         = "bcid" EQUAL 1*48(HEXDIG)
      Laes-cccid        = "cccid" EQUAL 1*8(HEXDIG)
      
      P-DCS-Redirect    = "P-DCS-Redirect" HCOLON Called-ID
                          *(SEMI redir-params)
      Called-ID         = LDQUOT addr-spec RDQUOT
      redir-params      = redir-uri-param / redir-count-param /
                          generic-param
      redir-uri-param   = "redirector-uri" EQUAL Redirector
      Redirector        = LDQUOT addr-spec RDQUOT
      redir-count-param = "count" EQUAL Redir-count
      Redir-count       = 1*DIGIT

This document adds the following entry to Table 2 of [RFC3261]: 

     Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG  PUB
     ------------         ----- -----  ---  ---  ---  ---  ---  ---  ---
     P-DCS-LAES                  adr    -    -    -    o    -    -    -
     P-DCS-Redirect              adr    -    -    -    o    -    -    -
     
                                       SUB  NOT  REF  INF  UPD  PRA  MSG
                                       ---  ---  ---  ---  ---  ---  ---
                                        -    -    -    -    -    -    -
                                        -    -    -    -    -    -    -

The values of Laes-sig and Laes-content are addresses of the Electronic Surveillance Delivery Function, and used as the destination address for call-identifying information and call- content, respectively. Laes-bcid contains a correlation ID that is used to link a sequence of intercepted call processing events related to a single call. Laes-cccid contains an identifier of the intercepted call content. The Laes-bcid field MAY be present. The BCID is included per network operator configuration to support events reported as defined in [PCEM]. The Laes-cccid field MAY be present when the Laes-content field is present. The Laes-cccid is included per network operator configuration for networks where entities receiving the intercepted contents may act a media relay functions to other surveillance functions that are the source of the content surveillance request. The design of multiple surveillance entities that receive call content is beyond the scope of this document.

The P-DCS-Redirect header contains redirection information. The Called-ID indicates the original destination requested by the user (e.g., number dialed originally), the redir-uri-param indicates the entity performing the redirection, and the Redir-count indicates the number of redirections that have occurred. For example, if A calls B, who forwards to C, who forwards to D, then, when C forwards to D, the Called-ID will be A, redir-uri-param will be C, and count will be 2.

8.2. Procedures at an Untrusted User Agent Client (UAC)

This header MUST NOT be sent to an untrusted UAC, and MUST NOT be sent by an untrusted UAC.

8.3. Procedures at a Trusted User Agent Client (UAC)

The UAC checks for an outstanding lawfully authorized surveillance order for the originating subscriber, and, if present, MAY include this information in the Authorization for Quality of Service [PCDQOS] or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.

If the P-DCS-LAES header is present in the first reliable 1xx (except 100), 2xx, or 3xx response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), the UAC MAY include this information in the Authorization for Quality of Service, or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.

If a 3xx-Redirect response to the initial INVITE request is received, and if a P-DCS-LAES header is present in the 3xx response, the UAC SHOULD include that header unchanged in the reissued INVITE. The UAC SHOULD also include a P-DCS-Redirect header containing the original dialed number, the most recent redirecting party, and the number of redirections that have occurred. Although it is technically possible for the originating equipment to perform this surveillance (or add to its existing surveillance of the call), the design of the surveillance system has the terminating equipment performing the surveillance for all the intermediate forwardings.

A UAC that includes a Refer-To header in a REFER request, when the originating subscriber has an outstanding lawfully authorized surveillance order, SHOULD include a P-DCS-LAES header attached to the Refer-To. The UAC MAY also include a P-DCS-Redirect header. The P-DCS-LAES header MAY include the Laes-bcid parameter set to a value that uniquely identifies the call, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and MAY include the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is to be intercepted.

The trusted UAC MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.

8.4. Procedures at an Untrusted User Agent Server (UAS)

This header MUST NOT be sent to an untrusted UAS, and MUST NOT be sent by an untrusted UAS.

8.5. Procedures at a Trusted User Agent Server (UAS)

The UAS checks for an outstanding lawfully authorized surveillance order for the terminating subscriber, or presence of the P-DCS-LAES header in the INVITE request. If either is present, the UAS MAY include this information in the authorization for Quality of Service [PCDQOS]. Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.

If the terminating equipment is unable to perform the required surveillance (e.g., if the destination is a voicemail server), the UAS SHOULD include a P-DCS-LAES header in the first reliable 1xx (except 100), 2xx, or 3xx response requesting the originating proxy to perform the surveillance. The P-DCS-LAES header MAY include the Laes-bcid parameter with a value that uniquely identifies the call, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and MAY include the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is to be intercepted.

If the response to the initial INVITE request is a 3xx-Redirect response, and there is an outstanding lawfully authorized surveillance order for the terminating subscriber, the UAS SHOULD include a P-DCS-LAES header in the 3xx-Redirect response, with contents as described above.

The trusted UAS MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.

8.6. Procedures at Proxy

Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that receives the INVITE request from an untrusted endpoint.

The terminating proxy is a proxy that sends the INVITE request to an untrusted endpoint.

For purposes of mid-call changes, such as call transfers, the proxy that receives the request from an untrusted endpoint is considered the initiating proxy; the proxy that sends the request to an untrusted endpoint is considered the recipient proxy. Procedures for the initiating proxy are included below with those for originating proxies, while procedures for the recipient proxy are included with those for terminating proxies.

A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to an untrusted endpoint, MUST NOT generate P-DCS-LAES nor P-DCS-Redirect headers.

A proxy that is neither an originating proxy nor a terminating proxy SHOULD pass the P-DCS-Laes and P-DCS-Redirect headers in requests and responses.

8.6.1. Procedures at Originating Proxy

The originating proxy MUST remove any P-DCS-LAES and P-DCS-Redirect headers in requests or responses to or from an untrusted proxy or untrusted UA.

The originating proxy checks for an outstanding lawfully authorized surveillance order for the originating subscriber, and, if present, MAY include this information in the Authorization for Quality of

Service [PCDQOS] or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.

If the P-DCS-LAES header is present in the first reliable 1xx (except 100), 2xx, or 3xx response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), the originating proxy MAY include this information in the Authorization for Quality of Service, or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.

If the Request-URI in an initial INVITE request contains a private- URL, the originating proxy MUST decrypt the userinfo information to find the real destination for the call, and other special processing information. If electronic surveillance information is contained in the decrypted userinfo, the originating proxy SHOULD generate a P- DCS-LAES and (if necessary) a P-DCS-REDIRECT header with the surveillance information.

If a 3xx-Redirect response to the initial INVITE request is received prior to a non-100 provisional response, and if a P-DCS-LAES header is present in the 3xx response, the originating proxy SHOULD include that header unchanged in the reissued INVITE. The originating proxy SHOULD also include a P-DCS-Redirect header containing the original dialed number, the most recent redirecting party, and the number of redirections that have occurred.

If a 3xx-Redirect response to the initial INVITE request is received after a non-100 provisional response, the originating proxy generates a private-URL and places it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. If a P-DCS-LAES header is present in the 3xx response, this private-URL MUST contain (1) the electronic surveillance information from the 3xx-Redirect response, (2) the original destination number, (3) the identity of the redirecting party, and (4) the number of redirections of this call.

An originating proxy that processes a REFER request [RFC3515] from an untrusted UA, when the originating subscriber has an outstanding lawfully authorized surveillance order, becomes a B2BUA for that request. It SHOULD reissue the request with a P-DCS-LAES header added to the Refer-To's URL. It MAY also include a P-DCS-Redirect header. The P-DCS-LAES header SHOULD include (1) the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, (2) the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted. The P-DCS-LAES header MAY include (1) the Laes-bcid parameter set to a value that uniquely identifies the call, and (2) the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is to be intercepted.

An initiating proxy that sends a mid-call REFER request including a Refer-To header, when the initiating subscriber has an outstanding lawfully authorized surveillance order, SHOULD include a P-DCS-LAES header in the Refer-To's URL.

The originating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.

8.6.2. Procedures at Terminating Proxy

The terminating proxy MUST remove any P-DCS-LAES and P-DCS-Redirect headers in requests or responses to or from an untrusted proxy or UA.

The terminating proxy checks for an outstanding lawfully authorized surveillance order for the terminating subscriber. If present, the terminating proxy MAY include this information in the authorization for Quality of Service [PCDQOS]. Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.

The terminating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity, either as headers in the request or response, or as headers attached to URIs in the request or response.

If the terminating equipment is unable to perform the required surveillance (e.g., if the destination is a voicemail server), the terminating proxy SHOULD include a P-DCS-LAES header in the first reliable 1xx/2xx/3xx (except 100) response requesting the originating proxy to perform the surveillance. The P-DCS-LAES header MAY include the Laes-bcid parameter set to a value that uniquely identifies the call, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and MAY include the Laes-cccid parameter set to a value that uniquely identifies the audio stream if call content is to be intercepted.

If the response to the initial INVITE request is a 3xx-Redirect response, and there is an outstanding lawfully authorized surveillance order for the terminating subscriber, the terminating proxy SHOULD include a P-DCS-LAES header in the 3xx-Redirect response, with contents as described above.

A proxy receiving a mid-call REFER request [RFC3515] that includes a Refer-To header with a P-DCS-LAES header attached becomes a B2BUA for this request. It MUST generate a private-URL and place it in the Refer-To header sent to the endpoint. This private-URL MUST contain the P-DCS-LAES and P-DCS-Redirect information from the attached header fields.

9. Security Considerations

QoS gate coordination, billing information, and electronic surveillance information are all considered to be sensitive information that MUST be protected from eavesdropping and furthermore require integrity checking. It is therefore necessary that the trusted UAs and proxies take precautions to protect this information from eavesdropping and tampering. Use of IPsec or TLS between proxies and trusted UAs is REQUIRED. A minimum mandatory-to- implement IPsec configuration for the DCS architecture is given by [PCSEC]. Also REQUIRED is mutual authentication (1) between Proxies and (2) between trusted UAs and Proxies, both of which MAY be implemented with administratively pre-shared keys, or through consultation with another trusted third party. If IPsec is to be used, the specification of the security policies and procedures of the administrative domain where these headers are applicable (and all connections between administrative domains in the federation) MUST define an interoperable set of options.

10. IANA Considerations

The following changes to the Session Initiation Protocol (SIP) Parameters registry have been made by IANA.

The Header Fields registry has been updated as follows: 

     Header Name        compact    Reference
     -----------------  -------    ---------
     P-DCS-Trace-Party-ID          [RFC5503]
     P-DCS-OSPS                    [RFC5503]
     P-DCS-Billing-Info            [RFC5503]
     P-DCS-LAES                    [RFC5503]
     P-DCS-Redirect                [RFC5503]

The following entries in the Header Field Parameters and Parameter Values registry have been updated: 

   Header Field                  Parameter Name               Values
   Reference
   ----------------------------  ---------------------------  ----------
   
   P-DCS-Billing-Info            called                       No
   [RFC5503]
   P-DCS-Billing-Info            calling                      No
   [RFC5503]
   P-DCS-Billing-Info            charge                       No
   [RFC5503]
   P-DCS-Billing-Info            locroute                     No
   [RFC5503]
   P-DCS-Billing-Info            rksgroup                     No
   [RFC5503]
   P-DCS-Billing-Info            routing                      No
   [RFC3603]
   P-DCS-LAES                    content                      No
   [RFC5503]
   P-DCS-Redirect                count                        No
   [RFC5503]
   P-DCS-Redirect                redirector-uri               No
   [RFC5503]

The following entry in the Header Field Parameters and Parameter Values registry has been marked "OBSOLETED": 

   Header Field                  Parameter Name               Values
   Reference
   ----------------------------  ---------------------------  ----------
   P-DCS-LAES                    key (OBSOLETED)              No
   [RFC3603][RFC5503]

The following entries in the Header Field Parameters and Parameter Values registry have been created: 

   Header Field                  Parameter Name               Values
   Reference
   ----------------------------  ---------------------------  ----------
   P-DCS-Billing-Info            jip                          No
   [RFC5503]
   P-DCS-LAES                    bcid                         No
   [RFC5503]
   P-DCS-LAES                    cccid                        No
   [RFC5503]
   P-DCS-Trace-Party-ID          timestamp                    No
   [RFC5503]

11. Changes since RFC 3603

  • A timestamp parameter is added to the P-DCS-Trace-Party-ID header when available. Procedures on the use of the Target-Dialog header used together with the P-DCS-Trace-Party-ID are added.
  • The JIP parameter is added to the P-DCS-Billing-Info header when available.
  • The BCID billing correlation identifier and cccid (call content channel identifier) are added to the P-DCS-LAES header.
  • P-DCS-Billing-Info header is applied to the SUBSCRIBE method.
  • P-DCS-REDIRECT header is applied to the REFER method.
  • The use of QoS authorization to establish content intercept is made optional in order not to preclude alternative content intercept provisioning mechanisms.
  • PUBLISH and MESSAGE methods are added to the SIP method applicability matrices throughout.
  • Correction is made to Table 2 to add m=modify.
  • IANA considerations are updated.
  • Corrections are made to timestamp format, and references are updated.

12. Acknowledgments

The Distributed Call Signaling work in the PacketCable project is the work of a large number of people, representing many different companies. The authors would like to recognize and thank the following for their assistance: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Brian Lindsay. Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; Lucent Cable Communications; and Miguel Garcia, Ericsson.

Previous versions further acknowledged, as co-authors, several people for providing the text of this document. They are: 

   Bill Marshall (wtm@research.att.com) and K. K. Ramakrishnan
   (kkrama@research.att.com), AT&T; Ed Miller
   (edward.miller@terayon.com), Terayon; David Hancock (D.Hancock@
   Cablelabs.com) and Glenn Russell (G.Russell@Cablelabs.com),
   CableLabs; Burcak Beser (burcak@juniper.net) Juniper Networks; Mike
   Mannette (Michael_Mannette@3com.com) and Kurt Steinbrenner
   (Kurt_Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com) and
   Flemming Andreasen (fandreas@cisco.com), Cisco Systems; John Pickens
   (jpickens@com21.com), Com21; Poornima Lalwaney
   (poornima.lalwaney@nokia.com), Nokia; Jon Fellows
   (jfellows@coppermountain.com), Copper Mountain Networks; Doc Evans
   (n7dr@arrisi.com) Arris, and Keith Kelly (keith@netspeak.com),
   NetSpeak.

13. References

13.1. Normative References

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.
   
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
   
   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.
   
   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, April 2003.
   
   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.
   
   [RFC4330]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
              for IPv4, IPv6 and OSI", RFC 4330, January 2006.
   
   [RFC4538]  Rosenberg, J., "Request Authorization through Dialog
              Identification in the Session Initiation Protocol (SIP)",
              RFC 4538, June 2006.
   
   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

13.2. Informative References

   [DCSARCH]  Marshall, W., Osman, M., Andreasen, F., and D. Evans,
              "Architectural Considerations for Providing Carrier Class
              Telephony Services Utilizing SIP-based Distributed Call
              Control Mechanisms", January 2003.
   
   [PCDQOS]   Cable Television Laboratories, Inc., "PacketCable 1.5
              Specifications, Dynamic Quality of Service", August 2005.
   
   [PCEM]     Cable Television Laboratories, Inc., "PacketCable 1.5
              Specifications, Event Messages", December 2005.
   
   [PCSEC]    Cable Television Laboratories, Inc., "PacketCable 1.5
              Specifications, Security", January 2005.
   
   [RFC2804]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
              May 2000.
   
   [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
              Extensions to the Session Initiation Protocol (SIP) for
              Asserted Identity within Trusted Networks", RFC 3325,
              November 2002.
   
   [RFC3603]  Marshall, W. and F. Andreasen, "Private Session Initiation
              Protocol (SIP) Proxy-to-Proxy Extensions for Supporting
              the PacketCable Distributed Call Signaling Architecture",
              RFC 3603, October 2003.

Authors' Addresses

Flemming Andreasen
Cisco
Edison, NJ
USA

EMail: 

          fandreas@cisco.com

Bernie McKibben
CableLabs
Louisville, CO
USA 

   EMail: B.McKibben@cablelabs.com

Bill Marshall
AT&T
Florham Park, NJ
USA 

   EMail: wtm@research.att.com