GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3603

Network Working Group W. Marshall, Ed. Request for Comments: 3603 AT&T Category: Informational F. Andreasen, Ed.

                                                                 Cisco
                                                          October 2003
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 (C) The Internet Society (2003).  All Rights Reserved.

Abstract

 In order to deploy a 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 customer-specific information and expectations about the
 parties involved in the call.  This document describes private
 extensions to the Session Initiation Protocol (SIP) (RFC3261) 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 . . . . . . . . . . . . . . . . . . .  3
 2.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  3
 3.  Trust Boundary. . . . . . . . . . . . . . . . . . . . . . . .  5
 4.  Conventions used in this document . . . . . . . . . . . . . .  6

Marshall & Andreasen Informational [Page 1] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 5.  P-DCS-TRACE-PARTY-ID. . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Syntax. . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Procedures at an Untrusted User Agent Client (UAC). . .  7
     5.3.  Procedures at a Trusted User Agent Client (UAC) . . . .  7
     5.4.  Procedures at an Untrusted User Agent Server (UAS). . .  7
     5.5.  Procedures at a Trusted User Agent Server (UAS) . . . .  7
     5.6.  Procedures at Proxy . . . . . . . . . . . . . . . . . .  8
           5.6.1.  Procedures at Originating Proxy . . . . . . . .  8
           5.6.2.  Procedures at Terminating Proxy . . . . . . . .  8
 6.  P-DCS-OSPS. . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Syntax. . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.2.  Procedures at an Untrusted User Agent Client (UAC). . .  9
     6.3.  Procedures at a Trusted User Agent Client (UAC) . . . . 10
     6.4.  Procedures at an Untrusted User Agent Server (UAS). . . 10
     6.5.  Procedures at a Trusted User Agent Server (UAS) . . . . 11
     6.6.  Procedures at Proxy . . . . . . . . . . . . . . . . . . 11
 7.  P-DCS-BILLING-INFO. . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.2.  Procedures at an Untrusted User Agent Client (UAC). . . 14
     7.3.  Procedures at a Trusted User Agent Client (UAC) . . . . 14
     7.4.  Procedures at an Untrusted User Agent Server (UAS). . . 15
     7.5.  Procedures at a Trusted User Agent Server (UAS) . . . . 15
     7.6.  Procedures at Proxy . . . . . . . . . . . . . . . . . . 16
           7.6.1.  Procedures at Originating Proxy . . . . . . . . 16
           7.6.2.  Procedures at Terminating Proxy . . . . . . . . 17
           7.6.3.  Procedures at Tandem Proxy. . . . . . . . . . . 18
 8.  P-DCS-LAES and P-DCS-REDIRECT . . . . . . . . . . . . . . . . 18
     8.1.  Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.2.  Procedures at an Untrusted User Agent Client (UAC). . . 20
     8.3.  Procedures at a Trusted User Agent Client (UAC) . . . . 20
     8.4.  Procedures at an Untrusted User Agent Server (UAS). . . 21
     8.5.  Procedures at a Trusted User Agent Server (UAS) . . . . 21
     8.6.  Procedures at Proxy . . . . . . . . . . . . . . . . . . 21
           8.6.1.  Procedures at Originating Proxy . . . . . . . . 22
           8.6.2.  Procedures at Terminating Proxy . . . . . . . . 23
 9.  Security Considerations . . . . . . . . . . . . . . . . . . . 24
 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
 11. Intellectual Property Rights Notice . . . . . . . . . . . . . 25
 12. References  . . . . . . . . . . . . . . . . . . . . . . . . . 25
     12.1. Normative References. . . . . . . . . . . . . . . . . . 25
     12.2. Informative References. . . . . . . . . . . . . . . . . 26
 13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 26
 14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
 15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28

Marshall & Andreasen Informational [Page 2] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

1. Applicability Statement

 The SIP 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 [6].  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 [6] is
 strongly encouraged in those domains as well.
 Although RFC 2119 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 [2] 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 DCS architecture described in [6]
 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.

Marshall & Andreasen Informational [Page 3] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 DCS Proxies, as defined in [6], 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 [6] 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.  It is the intent that the extensions would only appear on
 trusted network segments, should be inserted upon entering a trusted
 network region, and removed before leaving trusted network segments.
 Significant amounts of information is 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
 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.

Marshall & Andreasen Informational [Page 4] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 The addition of a SIP General Header Field allows for the capture of
 billing information and billing identification for the duration of
 the call.
 It is the intent that the billing extensions would 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 support for 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 [6] 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.

Marshall & Andreasen Informational [Page 5] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

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, RFC 2119 [1].
 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 [10].
 To initiate a customer-originated-trace from an untrusted 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 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.

Marshall & Andreasen Informational [Page 6] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

5.1. Syntax

 The ABNF description of this header is (some terms used in this ABNF
 are defined in [2]):
    P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON
                                   name-addr
 This document adds the following entry to Table 2 of [2]:
    Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG
    ------------         ----- -----  ---  ---  ---  ---  ---  ---
    P-DCS-Trace-Party-ID   R     dr    -    -    -    o    -    -
                                      SUB  NOT  REF  INF  UPD  PRA
                                      ---  ---  ---  ---  ---  ---
                                       -    -    -    -    -    -
 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.

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 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.

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 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

Marshall & Andreasen Informational [Page 7] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 the caller identity 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.

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 a
 non-trusted endpoint.
 The terminating proxy is a proxy that sends the INVITE request to a
 non-trusted 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 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).

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 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

Marshall & Andreasen Informational [Page 8] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 (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 field, which may
 be set to a value indicating when a special type of call processing
 is requested.  We define three values in this header, 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 [2]):
    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 [2]:
    Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG
    ------------         ----- -----  ---  ---  ---  ---  ---  ---
    P-DCS-OSPS             R     dr    -    -    -    o    -    -
                                      SUB  NOT  REF  INF  UPD  PRA
                                      ---  ---  ---  ---  ---  ---
                                       -    -    -    -    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.

Marshall & Andreasen Informational [Page 9] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

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

 This header is typically only inserted by a Media Gateway Controller
 [6] 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 or response 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 pre-existing dialog established
 with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a
 pre-existing 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 pre-existing dialog
 established by a UAC to an operator or PSAP, or (2) an UPDATE request
 within a pre-existing 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, and the
 existing call was not established with the OSPS-Tag, it MUST reject
 the request with a 403-Forbidden error code.
 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, it MUST reject the request with a 403-Forbidden
 response code.
 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 code.
 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.

Marshall & Andreasen Informational [Page 10] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 If an INVITE with OSPS-Tag of "BLV" is accepted (e.g., meeting all
 QoS pre-conditions, etc.), the UAS MUST send an audio stream on this
 connection to the address and port given in the 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 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

Marshall & Andreasen Informational [Page 11] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 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.
 It is the intent that the billing extensions would only appear on
 trusted network segments, and MAY be inserted by a proxy or trusted
 UA in INVITE 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 User Agents.  It is never sent to, nor sent by,
 an untrusted UA.

Marshall & Andreasen Informational [Page 12] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

7.1. Syntax

 The DCS-Billing-Info header is defined by the following ABNF (some
 terms used in this ABNF are defined in [2]):
 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 /
                           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
 This document adds the following entry to Table 2 of [2]:
 Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG
 ------------         ----- -----  ---  ---  ---  ---  ---  ---
 P-DCS-Billing-Info         admr    -    -    -    o    -    -
                                   SUB  NOT  REF  INF  UPD  PRA
                                   ---  ---  ---  ---  ---  ---
                                    -    -    -    -    -    -
 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 User Agents.
 The Billing-Correlation-ID is specified in [9] 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

Marshall & Andreasen Informational [Page 13] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 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 [9] 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-Location-Routing-URI are each
 defined as URLs; they should all contain tel: URLs with E.164
 formatted addresses.  These fields are further defined in [9] 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).

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

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

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
 message sent to the terminating proxy, 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.

Marshall & Andreasen Informational [Page 14] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 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, 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 from the 3xx-
 Redirect response.  If the UAC is acting as a B2BUA, instead of
 generating a new INVITE it MAY generate a private-URL and place 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.
 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
 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 a 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.

Marshall & Andreasen Informational [Page 15] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

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 request
 from a non-trusted endpoint.
 The terminating proxy is a proxy that sends the INVITE request to a
 non-trusted 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 a non-trusted 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 INVITE request from an untrusted
 endpoint, and sends the INVITE request to a non-trusted 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 message sent to the terminating proxy, 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 a LNP query, it MUST include the Routing Number and
 Location Routing Number 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.

Marshall & Andreasen Informational [Page 16] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 If the response to the initial INVITE is a 3xx-Redirect, received
 prior to a 18x, the originating proxy generates a new initial INVITE
 request to the destination specified in the Contact: header, as per
 standard SIP.  If an originating proxy receives a 3xx-Redirect
 response to an initial INVITE prior to a 18x 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 18x, 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 indicate 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
 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 a 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.

Marshall & Andreasen Informational [Page 17] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 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 indicate 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 a 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 [5], the IETF supports documentation of
 lawful intercept technology if it is necessary to develop it.  The
 following section provides such documentation.  The RFC 2119
 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 may also contain an additional address and port for
 delivery of call content.  Security key information is included to
 enable pairs of Delivery Functions to securely exchange surveillance
 information.  This header is only used between proxies and trusted
 User Agents.
 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 User Agents.
 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

Marshall & Andreasen Informational [Page 18] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 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 [2]
 and [3]):
    P-DCS-LAES        = "P-DCS-LAES" HCOLON Laes-sig
                        *(SEMI Laes-param)
    Laes-sig          = hostport
    Laes-param        = Laes-content / Laes-key / generic-param
    Laes-content      = "content" EQUAL hostport
    Laes-key          = "key" EQUAL token
    P-DCS-Redirect    = "P-DCS-Redirect" HCOLON Called-ID
                        *(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 [2]:
    Header field         where proxy  ACK  BYE  CAN  INV  OPT  REG
    ------------         ----- -----  ---  ---  ---  ---  ---  ---
    P-DCS-LAES                  adr    -    -    -    o    -    -
    P-DCS-Redirect              adr    -    -    -    o    -    -
                                      SUB  NOT  REF  INF  UPD  PRA
                                      ---  ---  ---  ---  ---  ---
                                       -    -    -    -    -    -
                                       -    -    -    -    -    -
 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-key is a string generated by the proxy
 that is used by the Delivery Function to securely transfer
 information between them [8].

Marshall & Andreasen Informational [Page 19] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 The P-DCS-Redirect header contains redirection information.  The
 redir-uri-param indicates the original destination requested by the
 user (e.g., dialed number), the Redirector indicates the new
 destination, and the Redir-count indicates the number of redirections
 that have occurred.

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, includes this
 information in the Authorization for Quality of Service [7] or
 signals this information to the device performing the intercept
 (e.g., a Media Gateway).
 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 MUST include this information in
 the Authorization for Quality of Service, or MUST signal this
 information to the device performing the intercept (e.g., a Media
 Gateway).
 If a 3xx-Redirect response is received to the initial INVITE request,
 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 new destination number, 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 P-DCS-LAES header 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 SHOULD
 include a random string for use as a security key between the
 Delivery Functions.

Marshall & Andreasen Informational [Page 20] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 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 includes
 this information in the authorization for Quality of Service [7].
 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 non-100
 response requesting the originating proxy to perform the
 surveillance.  The P-DCS-LAES header 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 SHOULD
 include a random string for use as a security key between the
 Delivery Functions.
 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 received the INVITE request from a
 non-trusted endpoint.
 The terminating proxy is a proxy that sends the INVITE request to a
 non-trusted endpoint.

Marshall & Andreasen Informational [Page 21] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 For purposes of mid-call changes, such as call transfers, the proxy
 that receives the request from a non-trusted 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 INVITE request from an untrusted
 endpoint, and sends the INVITE request to a non-trusted 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,
 includes this information in the Authorization for Quality of Service
 [7] or signals this information to the device performing the
 intercept (e.g., a Media Gateway).
 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 MUST include this
 information in the Authorization for Quality of Service, or MUST
 signal this information to the device performing the intercept (e.g.,
 a Media Gateway).
 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 header with the surveillance information.
 If a 3xx-Redirect response is received to the initial INVITE request
 prior to a 18x, 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

Marshall & Andreasen Informational [Page 22] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 P-DCS-Redirect header containing the original dialed number, the new
 destination number, and the number of redirections that have
 occurred.
 If a 3xx-Redirect response is received to the initial INVITE request
 after a 18x, 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 [4] 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.  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, and (3) a random string for use as a security key
 between the Delivery Functions.
 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 includes this information in the authorization for
 Quality of Service [7].
 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.

Marshall & Andreasen Informational [Page 23] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 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 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 SHOULD include a random string for use as a
 security key between the Delivery Functions.
 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 [4] 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 information from the attached header.

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 is REQUIRED.  A minimum mandatory-to-implement IPsec
 configuration for the DCS architecture is given by [8].  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.

Marshall & Andreasen Informational [Page 24] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

10. IANA Considerations

 This document defines a number of SIP extension headers, which have
 been included in the registry of SIP headers defined in [2].
 Registration information for new headers is as follows:
 Header Field Name:   P-DCS-Trace-Party-ID
      RFC Number:     3603
      Compact Form:   none
 Header Field Name:   P-DCS-OSPS
      RFC Number:     3603
      Compact Form:   none
 Header Field Name:   P-DCS-Billing-Info
      RFC Number:     3603
      Compact Form:   none
 Header Field Name:   P-DCS-LAES
      RFC Number:     3603
      Compact Form:   none
 Header Field Name:   P-DCS-Redirect
      RFC Number:     3603
      Compact Form:   none

11. Intellectual Property Rights Notice

 The IETF has been notified of intellectual property rights claimed in
 regard to some or all of the specification contained in this
 document.  For more information consult the online list of claimed
 rights.

12. References

12.1. Normative References

 [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [2]  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.
 [3]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, November 1997.

Marshall & Andreasen Informational [Page 25] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

 [4]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
      Method", RFC 3515, April 2003.
 [5]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.

12.2. Informative References

 [6]  DCS Group, "Architectural Considerations for Providing Carrier
      Class Telephony Services Utilizing SIP-based Distributed Call
      Control Mechanisms", Work in Progress.
 [7]  PacketCable Dynamic Quality of Service Specification, pkt-sp-
      dqos-i07-030815, August 2003.
 [8]  PacketCable Security Specification, pkt-sp-sec-i09-030728, July
      2003.
 [9]  PacketCable Event Message Specification, pkt-sp-em-i07-030815,
      August 2003.
 [10] 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.

13. Acknowledgements

 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, 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; and Lucent Cable
 Communications.
 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; 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

Marshall & Andreasen Informational [Page 26] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

    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.

14. Editors' Addresses

 Bill Marshall
 AT&T
 Florham Park, NJ  07932
 EMail: wtm@research.att.com
 Flemming Andreasen
 Cisco
 Edison, NJ
 EMail: fandreas@cisco.com

Marshall & Andreasen Informational [Page 27] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003

15. Full Copyright Statement

 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assignees.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Marshall & Andreasen Informational [Page 28]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3603.txt · Last modified: 2003/10/09 21:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki