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