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