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