diff options
Diffstat (limited to 'doc/rfc/rfc5503.txt')
| -rw-r--r-- | doc/rfc/rfc5503.txt | 1907 |
1 files changed, 1907 insertions, 0 deletions
diff --git a/doc/rfc/rfc5503.txt b/doc/rfc/rfc5503.txt new file mode 100644 index 0000000..5b87c83 --- /dev/null +++ b/doc/rfc/rfc5503.txt @@ -0,0 +1,1907 @@ + + + + + + +Network Working Group F. Andreasen +Request for Comments: 5503 Cisco +Obsoletes: 3603 B. McKibben +Category: Informational CableLabs + B. Marshall + AT&T + March 2009 + + +Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for + Supporting the PacketCable Distributed Call Signaling Architecture + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + +Andreasen, et al. Informational [Page 1] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +Abstract + + In order to deploy a residential telephone service at a very large + scale across different domains, it is necessary for trusted elements + owned by different service providers to exchange trusted information + that conveys customer-specific information and expectations about the + parties involved in the call. This document describes private + extensions to the Session Initiation Protocol, RFC 3261, for + supporting the exchange of customer information and billing + information between trusted entities in the PacketCable Distributed + Call Signaling Architecture. These extensions provide mechanisms for + access network coordination to prevent theft of service, customer + originated trace of harassing calls, support for operator services + and emergency services, and support for various other regulatory + issues. The use of the extensions is only applicable within closed + administrative domains, or among federations of administrative + domains with previously agreed-upon policies where coordination of + charging and other functions is required. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Andreasen, et al. Informational [Page 2] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +Table of Contents + + 1. Applicability Statement .........................................4 + 2. Introduction ....................................................4 + 3. Trust Boundary ..................................................6 + 4. Conventions Used in This Document ...............................7 + 5. P-DCS-TRACE-PARTY-ID ............................................7 + 5.1. Syntax .....................................................8 + 5.2. Procedures at an Untrusted User Agent Client (UAC) .........9 + 5.3. Procedures at a Trusted User Agent Client (UAC) ............9 + 5.4. Procedures at an Untrusted User Agent Server (UAS) .........9 + 5.5. Procedures at a Trusted User Agent Server (UAS) ............9 + 5.6. Procedures at Proxy .......................................10 + 5.6.1. Procedures at Originating Proxy ....................10 + 5.6.2. Procedures at Terminating Proxy ....................11 + 6. P-DCS-OSPS .....................................................11 + 6.1. Syntax ....................................................11 + 6.2. Procedures at an Untrusted User Agent Client (UAC) ........12 + 6.3. Procedures at a Trusted User Agent Client (UAC) ...........12 + 6.4. Procedures at an Untrusted User Agent Server (UAS) ........13 + 6.5. Procedures at a Trusted User Agent Server (UAS) ...........13 + 6.6. Procedures at Proxy .......................................14 + 7. P-DCS-BILLING-INFO .............................................14 + 7.1. Syntax ....................................................16 + 7.2. Procedures at an Untrusted User Agent Client (UAC) ........18 + 7.3. Procedures at a Trusted User Agent Client (UAC) ...........18 + 7.4. Procedures at an Untrusted User Agent Server (UAS) ........18 + 7.5. Procedures at a Trusted User Agent Server (UAS) ...........18 + 7.6. Procedures at Proxy .......................................19 + 7.6.1. Procedures at Originating Proxy ....................19 + 7.6.2. Procedures at Terminating Proxy ....................20 + 7.6.3. Procedures at Tandem Proxy .........................21 + 8. P-DCS-LAES and P-DCS-Redirect ..................................21 + 8.1. Syntax ....................................................23 + 8.2. Procedures at an Untrusted User Agent Client (UAC) ........24 + 8.3. Procedures at a Trusted User Agent Client (UAC) ...........24 + 8.4. Procedures at an Untrusted User Agent Server (UAS) ........25 + 8.5. Procedures at a Trusted User Agent Server (UAS) ...........25 + 8.6. Procedures at Proxy .......................................26 + 8.6.1. Procedures at Originating Proxy ....................26 + 8.6.2. Procedures at Terminating Proxy ....................28 + 9. Security Considerations ........................................29 + 10. IANA Considerations ...........................................29 + 11. Changes since RFC 3603 ........................................31 + 12. Acknowledgments ...............................................32 + 13. References ....................................................32 + 13.1. Normative References .....................................32 + 13.2. Informative References ...................................33 + + + +Andreasen, et al. Informational [Page 3] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +1. Applicability Statement + + The Session Initiation Protocol (SIP) [RFC3261] extensions described + in this document make certain assumptions regarding network topology, + linkage between SIP and lower layers, and the availability of + transitive trust. These assumptions are generally not applicable in + the Internet as a whole. The use of these headers is only applicable + within closed administrative domains, or among federations of + administrative domains with previously agreed-upon policies where + coordination of charging and other functions is required, as in, for + example, the architecture presented in [DCSARCH]. Use outside such a + domain could result in the leakage of potentially sensitive or + private information. User consent to the privacy implications of the + policies in [DCSARCH] is strongly encouraged in those domains as + well. + + Although [RFC2119] language is used in this document, the scope of + the normative language is only for the area of applicability of the + document and, like the technology, it does not apply to the general + Internet. + +2. Introduction + + In order to deploy a SIP based residential telephone service at very + large scale across different domains, it is necessary for trusted + elements owned by different service providers to exchange trusted + information that conveys billing information and expectations about + the parties involved in the call. + + There are many billing models used in deriving revenue from telephony + services today. Charging for telephony services is tightly coupled + to the use of network resources. It is outside the scope of this + document to discuss the details of these numerous and varying + methods. + + A key motivating principle of the Distributed Call Signaling (DCS) + architecture described in [DCSARCH] is the need for network service + providers to be able to control and monitor network resources; + revenue may be derived from the usage of these resources as well as + from the delivery of enhanced services such as telephony. + Furthermore, the DCS architecture recognizes the need for + coordination between call signaling and resource management. This + coordination ensures that users are authenticated and authorized + before receiving access to network resources and billable enhanced + services. + + + + + + +Andreasen, et al. Informational [Page 4] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + DCS Proxies, as defined in [DCSARCH], have access to subscriber + information and act as policy decision points and trusted + intermediaries along the call signaling path. Edge routers provide + the network connectivity and resource policy enforcement mechanism + and also capture and report network connectivity and resource usage + information. Edge routers need to be given billing information that + can be logged with Record-Keeping or Billing servers. The DCS Proxy, + as a central point of coordination between call signaling and + resource management, can provide this information based on the + authenticated identity of the calling and called parties. Since + there is a trust relationship among DCS Proxies, they can be relied + upon to exchange trusted billing information pertaining to the + parties involved in a call. See [DCSARCH] for a description of the + trust boundary and trusted versus untrusted entities. + + For these reasons, it is appropriate to consider defining SIP header + extensions to allow DCS Proxies to exchange information during call + setup. The extensions only appear on trusted network segments, are + inserted upon entering a trusted network region, and are removed + before leaving trusted network segments. + + Significant amounts of information are retrieved by an originating + DCS Proxy in its handling of a connection setup request from a user + agent. Such information includes location information about the + subscriber (essential for emergency services calls), billing + information, and station information (e.g., coin-operated phone). In + addition, while translating the destination number, information such + as the local-number-portability office code is obtained and will be + needed by all other proxies handling this call. + + For Usage Accounting records, it is necessary to have an identifier + that can be associated with all the event records produced for the + call. The SIP Call-ID header field cannot be used as such an + identifier since it is selected by the originating user agent, and it + may not be unique among all past calls as well as current calls. + Further, since this identifier is to be used by the service provider, + it should be chosen in a manner and in a format that meets the + service provider's needs. + + Billing information may not necessarily be unique for each user + (consider the case of calls from an office all billed to the same + account). Billing information may not necessarily be identical for + all calls made by a single user (consider prepaid calls, credit card + calls, collect calls, etc). It is therefore necessary to carry + billing information separate from the calling and called party + identification. Furthermore, some billing models call for split- + charging where multiple entities are billed for portions of the call. + + + + +Andreasen, et al. Informational [Page 5] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + The addition of a SIP General Header Field allows for the capture of + billing information and billing identification for the duration of + the call. + + The billing extensions only appear on trusted network segments and + MAY be inserted by a DCS Proxy in INVITE and REFER requests and + INVITE responses in a trusted network segment, and removed before + leaving trusted network segments. + + In addition to support for billing, current residential telephone + service includes the need for customer-originated trace (of harassing + or obscene calls), for operator services such as busy line + verification and emergency interrupt (initiated by an operator from + an Operator Services Position System (OSPS)), for emergency services + such as 9-1-1 calls to a Public Service Access Point (PSAP) and the + subsequent call handling, and for support of Electronic Surveillance + and Law Enforcement access as required by applicable legislation and + court orders. In all of these cases, additional information about + the call and about the subscribers involved in the call needs to be + exchanged between the proxies. + +3. Trust Boundary + + The DCS architecture [DCSARCH] defines a trust boundary around the + various systems and servers that are owned, operated by, and/or + controlled by the service provider. These trusted systems include + the proxies and various servers such as bridge servers, voicemail + servers, announcement servers, etc. Outside of the trust boundary + lie the customer premises equipment and various application and media + servers operated by third-party service providers. + + Certain subscriber-specific information, such as billing and + accounting information, stays within the trust boundary. Other + subscriber-specific information, such as endpoint identity, may be + presented to untrusted endpoints or may be withheld based on + subscriber profiles. + + The User Agent (UA) may be either within the trust boundary or + outside the trust boundary, depending on exactly what function is + being performed and exactly how it is being performed. Accordingly, + the procedures followed by a user agent are different depending on + whether the UA is within the trust boundary or outside the trust + boundary. + + + + + + + + +Andreasen, et al. Informational [Page 6] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + The following sections giving procedures for user agents therefore + are subdivided into trusted user agents and untrusted user agents. + Since UAs may support client and server functions, the UA sections + include procedures for the User Agent Client (UAC) and User Agent + Server (UAS). + +4. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, [RFC2119]. + + The term "private-URL" used in this document refers to a SIP URI that + is generated by a proxy, contains a "hostport" that identifies the + proxy, and contains a "userinfo" string that is generated by the + proxy. The userinfo typically contains (or points to) information + that is not to be disclosed outside the trusted domain of the + proxies, such as billing account numbers, electronic surveillance + indication, electronic surveillance parameters, and call redirection + information. Consequently, the information is either stored locally + by the proxy, or encrypted with a private key known only to the proxy + and encoded in a character string in the userinfo portion of the URL. + A checksum is included in the userinfo data to detect tampering. The + mechanism by which a proxy recognizes a userinfo as a private-URL and + decodes and recovers the original information is local to the proxy + and is not subject to standardization. Some possible implementations + include an initial magic cookie (e.g., z9hG4Bk followed by the + pointer/information), or use of a reserved "user" name (e.g., + "private") with the optional "password" containing the pointer/ + information. + +5. P-DCS-TRACE-PARTY-ID + + In the telephone network, calling identity information is used to + support regulatory requirements such as the Customer Originated Trace + service, which provide the called party with the ability to report + obscene or harassing phone calls to law enforcement. This service is + provided independently of caller-id, and works even if the caller + requested anonymity. The calling party is here identified as the + station originating the call. In order for this service to be + dependable, the called party must be able to trust that the calling + identity information being presented is valid. One way to achieve + this is described in [RFC3325]. + + To initiate a customer-originated-trace from an untrusted User Agent + Client (UAC), an additional header is defined for the INVITE request. + This header is called P-DCS-Trace-Party-ID, and does not appear in + any other request or response. The untrusted UAC also includes the + + + +Andreasen, et al. Informational [Page 7] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + Target-Dialog header field, defined in [RFC4538], in the INVITE + request in order to explicitly identify the call to be traced. The + entity addressed by the Request-URI performs the service-provider- + specific functions of recording and reporting the caller identity in + the P-DCS-Trace-Party-ID for law enforcement action. It then + forwards the call to either an announcement server or to the service + provider's business office to collect further information about the + complaint. A trusted UAC does not use this header, as it initiates + this action locally. + +5.1. Syntax + + The ABNF description of this header is (some terms used in this ABNF + are defined in [RFC3261]): + + P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr + *1(SEMI timestamp-param) *(SEMI trace-param) + timestamp-param = "timestamp=" 1*DIGIT ["." 1*DIGIT] + trace-param = generic-param ; defined in RFC 3261 + + This document adds the following entry to Table 2 of [RFC3261]: + + Header field where proxy ACK BYE CAN INV OPT REG PUB + ------------ ----- ----- --- --- --- --- --- --- --- + P-DCS-Trace-Party-ID R dmr - - - o - - - + SUB NOT REF INF UPD PRA MSG + --- --- --- --- --- --- --- + - - - - - - - + + The addr-spec contained in name-addr contains a URL that identifies + the remote endpoint. Addr-spec typically contains a tel URL or SIP + URI giving the identity of the remote endpoint, as provided in the + signaling messages that established the session to be traced. + + The timestamp-param contains the value of the time the UA determines + it received the session initiation request of the call requested to + be traced. The timestamp-param is populated using the Network Time + Protocol timestamp format defined in RFC 1305 [RFC1305] and used by + the Simple Network Time Protocol [RFC4330]. The timestamp SHOULD be + encoded in UTF-8 Format per [RFC3629]. The trace-param is a generic + parameter for future extensions. + + An example of the P-DCS-Trace-Party-ID header is shown as follows: + + P-DCS-Trace-Party-ID: <sip:+12345678912@domain.com;user=phone>; + timestamp=3434688831.2327 + + + + + +Andreasen, et al. Informational [Page 8] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +5.2. Procedures at an Untrusted User Agent Client (UAC) + + The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial + INVITE message for a customer-originated-trace request. The trace + request from the Untrusted User Agent Client is able to be initiated + during the dialog or after the release of the dialog or call that is + requested to be traced. The UAC MUST use a SIP URI in the Request- + URI with userinfo set to "call-trace" and hostport identifying the + call tracing entity for the untrusted UA. The [RFC3603] version of + the P-DCS-Trace-Party-ID did not include the timestamp-param + parameter; however, the syntax is backwards compatible with + [RFC3603]. A UAC compliant to this updated specification MUST insert + the timestamp and the Target-Dialog header field defined in [RFC4538] + if known to the UAC. + + In case of an anonymous malicious call, where the remote party is not + known to the Untrusted UAC, the Untrusted UAC SHOULD indicate the + user as anonymous in the P-DCS-Trace-Party-ID, for example, as + follows: sip:anonymous@anonymous.invalid. + +5.3. Procedures at a Trusted User Agent Client (UAC) + + A trusted UAC performs the customer-originated-trace in a manner + similar to the trusted User Agent Server (UAS), described below. A + trusted UAC MUST NOT include this header in any request. + +5.4. Procedures at an Untrusted User Agent Server (UAS) + + This header MUST NOT appear in any response sent by a UAS. + +5.5. Procedures at a Trusted User Agent Server (UAS) + + If the P-DCS-Trace-Party-ID header is present in the initial INVITE + request from a UAC, and the Request-URI of the INVITE has userinfo + set to "call-trace" and hostport set to the UAS, the UAS MUST perform + the service-provider-specific functions of recording and reporting + the caller identity and associated trace parameters (if any) from the + Target-Dialog header field for law enforcement action. The UAS then + MUST redirect the call, via a 3xx response, to either an announcement + server or to the service provider's business office to collect + further information about the complaint. + + This header MUST NOT appear in any response sent by a UAS. + + If the P-DCS-Trace-Party-ID header is not present in the initial + INVITE request from a UAC, and the Request-URI of the INVITE has + userinfo set to "call-trace" the UAS MUST reject the request. + + + + +Andreasen, et al. Informational [Page 9] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +5.6. Procedures at Proxy + + Two sets of proxy procedures are defined: (1) the procedures at an + originating proxy, and (2) the procedures at a terminating proxy. + The originating proxy is a proxy that received the INVITE request + from an untrusted endpoint. + + The terminating proxy is a proxy that sends the INVITE request to an + untrusted endpoint. + + A proxy that both receives the INVITE request from an untrusted + endpoint, and sends the INVITE request to an untrusted endpoint, + performs both sets of procedures. + +5.6.1. Procedures at Originating Proxy + + If the P-DCS-Trace-Party-ID header is present in the initial INVITE + request from the UAC, and the Request-URI of the INVITE has userinfo + other than "call-trace" and hostport set to other than a potentially + provisioned call tracing entity, then the proxy MAY reject the + request, or it MAY remove the P-DCS-Trace-Party-ID header from the + request. If the header is present in a valid request, and contains a + private-URL that identifies the proxy in the hostport, then the + originating proxy SHOULD replace the private-URL with its original + contents (i.e., the verified identity of the caller of the session + that is being traced and trace parameters from the Target-Dialog + header fields defined in [RFC4538]). + + The proxy records the caller URL and target dialog IDs on sessions + directed toward the untrusted UAC if provisioned to do so by the + network operator. If the is P-DCS-Trace-Party-ID header is present + in a valid request, and contains an anonymous caller indication in + the name-addr parameter, the originating proxy MUST replace the + anonymous URL with the verified identity of the caller of the session + that is being traced if available and recorded by the proxy. + Otherwise, the proxy does not replace the anonymous URL. + + If the origination proxy is provisioned to store URLs and target + dialog IDs for incoming calls, and if the proxy detects that the URL + and target dialog ID in a trace request does not match a recorded + incoming dialog request, then the proxy MUST reject the trace call + request. + + The origination proxy does not add the P-DCS-Trace-Party-ID header + from a request that does not already contain the header. + + + + + + +Andreasen, et al. Informational [Page 10] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +5.6.2. Procedures at Terminating Proxy + + This header MUST NOT appear in any request or response sent by a + terminating proxy to an untrusted endpoint. + +6. P-DCS-OSPS + + Some calls have special call processing requirements that may not be + satisfied by normal user agent call processing. For example, when a + user is engaged in a call and another call arrives, such a call might + be rejected with a busy indication. However, some Public Switched + Telephone Network (PSTN) operator services require special call + processing. In particular, the Busy Line Verification (BLV) and + Emergency Interrupt (EI) services initiated by an operator from an + Operator Services Position System (OSPS) on the PSTN network have + such a need. Similarly, emergency calls to a 9-1-1 Public Service + Access Point (PSAP) may result in trunk signaling causing operator + ringback using a howling tone or sustained ring on the originating + line (country-specific variations may exist). + + In order to inform the SIP user agent that special treatment should + be given to a call, we use a new P-DCS-OSPS header, with a field that + may be set to a value indicating when a special type of call + processing is requested. We define three values in this header + field, namely "BLV" for busy line verification, "EI" for emergency + interrupt, and "RING" for operator ringback (e.g., howling/sustained + tone ring in the US). + + If the user agent decides to honor such a request, the response of + the user agent to an INVITE with either "BLV" or "EI" will not be a + busy indication. Since "EI" and "RING" only occur on established + dialogs, they may also appear in UPDATE requests. + +6.1. Syntax + + The ABNF description of the P-DCS-OSPS header is as follows (some + terms used in this ABNF are defined in [RFC3261]): + + P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag + OSPS-Tag = "BLV" / "EI" / "RING" / token + + + + + + + + + + + +Andreasen, et al. Informational [Page 11] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + This document adds the following entry to Table 2 of [RFC3261]: + + Header field where proxy ACK BYE CAN INV OPT REG PUB + ------------ ----- ----- --- --- --- --- --- --- --- + P-DCS-OSPS R dr - - - o - - - + SUB NOT REF INF UPD PRA MSG + --- --- --- --- --- --- --- + - - - - o - - + + The OSPS-Tag value of "token" is defined for extensibility, and is + reserved for future use. + +6.2. Procedures at an Untrusted User Agent Client (UAC) + + The P-DCS-OSPS header MUST NOT be sent in a request from an untrusted + UAC. + +6.3. Procedures at a Trusted User Agent Client (UAC) + + This header is typically only inserted by a Media Gateway Controller + [DCSARCH] that is controlling a Media Gateway with special trunks to + a PSTN OSPS system or PSAP. This trunk group is usually referred to + as a BLV-trunk group and employs special signaling procedures that + prevent inadvertent use. Calls originating at the PSTN OSPS system + are sent over this trunk group, and result in an INVITE request with + the P-DCS-OSPS header. + + This header MAY be sent in an INVITE request, and MUST NOT appear in + any message other than those listed below. + + OSPS-Tag value "BLV" MUST NOT appear in any request other than an + initial INVITE request establishing a new dialog. + + OSPS-Tag value "EI" MUST NOT appear in any request or response other + than (1) a subsequent INVITE within a preexisting dialog established + with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a + preexisting dialog established with the OSPS-Tag value of "BLV". + + OSPS-Tag value "RING" MUST NOT appear in any request or response + other than (1) a subsequent INVITE within a preexisting dialog + established by a UAC to an operator or PSAP, or (2) an UPDATE request + within a preexisting dialog established by a UAC to an operator or + PSAP. + + + + + + + + +Andreasen, et al. Informational [Page 12] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +6.4. Procedures at an Untrusted User Agent Server (UAS) + + If the UAS receives an INVITE request with an OSPS-Tag of "BLV", + dialog identification that matches an existing dialog, it MUST reject + the request with a 403 (Forbidden) response. + + If the UAS receives an INVITE/UPDATE request with an OSPS-Tag value + of "EI" or "RING", with dialog identification that does not match an + existing dialog that was established with the OSPS-Tag value of + "BLV", it MUST reject the request with a 403 (Forbidden) response. + + If the UAS receives an INVITE that contains an OSPS-Tag value of + "BLV" and is not willing to cooperate in offering this service, it + MUST reject the request with a 403 (Forbidden) response. + + The UAS SHOULD NOT reject an INVITE with a "BLV" OSPS-Tag due to a + busy condition. The UAS MUST NOT respond with a 3xx-Redirect + response code to an INVITE with a "BLV" OSPS-Tag. The UAS SHOULD NOT + alert the user of the incoming call attempt if the "BLV" OSPS-Tag is + present in the INVITE. + + If an INVITE with OSPS-Tag of "BLV" is accepted (e.g., meeting all + quality-of-service (QoS) pre-conditions, etc.), the UAS MUST send an + audio stream on this connection to the address and port given in the + Session Description Protocol (SDP) of the INVITE. The UAS MAY + perform a mixing operation between the two ends of an existing active + call and send the resulting media stream to the address and port + indicated. Alternatively, the UAS MAY send a copy of the local voice + stream, and (if there is no activity on the local voice stream) send + a copy of the received voice stream of an existing call. If the + state of the UAS is idle, the UAS SHOULD send a stream of silence + packets to OSPS. If the state of the UAS is ringing or ringback, the + UAS SHOULD send a ringback stream to OSPS. + + If an INVITE/UPDATE with OSPS-Tag of "EI" is accepted, the UAS MUST + enable communication between the UAC and the local user. The UAS MAY + put any existing call on hold, or initiate an ad hoc conference. + + If an INVITE/UPDATE with OSPS-Tag of "RING" is accepted, the UAS MUST + perform operator ringback in accordance with local procedures, e.g., + generate a 3-second howling tone or a sustained ring, depending on + the state of the user equipment. + +6.5. Procedures at a Trusted User Agent Server (UAS) + + The procedures at a trusted UAS MUST be identical to those described + in 6.4. + + + + +Andreasen, et al. Informational [Page 13] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +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 + + + + + +Andreasen, et al. Informational [Page 14] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + billing information separate from the calling and called party + identification. Furthermore, some billing models call for + split-charging where multiple entities are billed for portions of the + call. + + The addition of a SIP General Header Field allows for the capture of + billing information and billing identification for the duration of + the call. + + The billing extensions only appear on trusted network segments, and + MAY be inserted by a proxy or trusted UA in INVITE and SUBSCRIBE + requests in a trusted network segment, and removed before leaving + trusted network segments. The P-DCS-Billing-Info header extension is + used only on requests and responses between proxies and trusted UAs. + It is never sent to an untrusted UA. It is expected that untrusted + UAs do not send this header. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Andreasen, et al. Informational [Page 15] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +7.1. Syntax + + The DCS-Billing-Info header is defined by the following ABNF (some + terms used in this ABNF are defined in [RFC3261]): + + P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON + Billing-Correlation-ID "/" FEID + *(SEMI Billing-Info-param) + Billing-Correlation-ID = 1*48(HEXDIG) + FEID = 1*16(HEXDIG) "@" host + Billing-Info-param = RKS-Group-ID-param / Charge-param / + Calling-param / Called-param / + Routing-param / Loc-Routing-param / + JIP-param / generic-param + RKS-Group-ID-param = "rksgroup" EQUAL RKS-Group-ID + RKS-Group-ID = token + Charge-param = "charge" EQUAL Acct-Charge-URI + Acct-Charge-URI = LDQUOT addr-spec RDQUOT + Calling-param = "calling" EQUAL Acct-Calling-URI + Acct-Calling-URI = LDQUOT addr-spec RDQUOT + Called-param = "called" EQUAL Acct-Called-URI + Acct-Called-URI = LDQUOT addr-spec RDQUOT + Routing-param = "routing" EQUAL Acct-Routing-URI + Acct-Routing-URI = LDQUOT addr-spec RDQUOT + Loc-Routing-param = "locroute" EQUAL Acct-Loc-Routing-URI + Acct-Loc-Routing-URI = LDQUOT addr-spec RDQUOT + JIP-param = "jip" EQUAL jip + jip = LDQUOT 1*phonedigit-hex jip-context RDQUOT + jip-context = ";jip-context=" jip-descriptor + jip-descriptor = global-hex-digits + global-hex-digits = "+" 1*3(phonedigit) *phonedigit-hex + phonedigit = DIGIT / [ visual-separator ] + phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] + visual-separator = "-" / "." / "(" / ")" + + This document adds the following entry to Table 2 of [RFC3261]: + + Header field where proxy ACK BYE CAN INV OPT REG PUB + ------------ ----- ----- --- --- --- --- --- --- --- + P-DCS-Billing-Info admr - - - o - - - + + SUB NOT REF INF UPD PRA MSG + --- --- --- --- --- --- --- + - - - - - - - + + + + + + + +Andreasen, et al. Informational [Page 16] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + The P-DCS-Billing-Info extension contains an identifier that can be + used by an event recorder to associate multiple usage records, + possibly from different sources, with a billable account. It further + contains the subscriber account information, and other information + necessary for accurate billing of the service. This header is only + used between proxies and trusted UAs. + + The Billing-Correlation-ID, BCID, is specified in [PCEM] as a 24-byte + binary structure, containing 4 bytes of NTP timestamp, 8 bytes of the + unique identifier of the network element that generated the ID, 8 + bytes giving the time zone, and 4 bytes of monotonically increasing + sequence number at that network element. This identifier is chosen + to be globally unique within the system for a window of several + months. This MUST be encoded in the P-DCS-Billing-Info header as a + hexadecimal string of up to 48 characters. Leading zeroes MAY be + suppressed. + + The Financial-Entity-ID (FEID) is specified in [PCEM] as an 8-byte + structure, containing the financial identifier for that domain, + followed by a domain name. FEID can be associated with a type of + service and could be assigned to multiple domains by the same + provider. A domain could contain multiple assigned FEIDs. This + 8-byte structure MUST be encoded in the P-DCS-Billing-Info header as + a hexadecimal string of up to 16 characters. Trailing zeroes MAY be + suppressed. "Host" contains the domain name. + + The RKS-Group-ID specifies a Record-Keeping server (or group of + cooperating servers) for event messages relating to this call. It is + used to control certain optimizations of procedures when multiple + event message streams are being sent to the same Record-Keeping + server. + + Additional parameters contain the information needed for generation + of event message records. Acct-Charge-URI, Acct-Calling-URI, Acct- + Called-URI, Acct-Routing-URI, and Acct-Loc-Routing-URI are each + defined as URLs; they should all contain tel URLs with E.164 + formatted addresses. These fields are further defined in [PCEM] + under the element identifiers "Charge_Number" (element ID 16), + "Calling_Party_Number" (element ID 4), "Called_Party_Number" (element + ID 5), "Routing Number" (element ID 25), and + "Location_Routing_Number" (element ID 22). + + The JIP-param contains the calling jurisdiction information, or + numbering plan area, of the network in which the call originated. + The field is further defined in [PCEM] under the element identifier + "Jurisdiction_Information_Parameter" (element ID 82). An older + [RFC3603] compliant implementation may not use the JIP-param. + + + + +Andreasen, et al. Informational [Page 17] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +7.2. Procedures at an Untrusted User Agent Client (UAC) + + This header is never sent to an untrusted UA. It is expected that + untrusted UAs do not send this header. + +7.3. Procedures at a Trusted User Agent Client (UAC) + + The UAC MUST generate the Billing-Correlation-ID for the call, and + insert it into the P-DCS-Billing-Info header in the initial INVITE or + SUBSCRIBE message sent to the terminating entity, along with the + charging information for the call. The UAC MUST include its FEID, + and the RKS-Group-ID for the Record-Keeping server being used by the + UAC. If the UAC performed a Local Number Portability (LNP) query, it + MUST include the Routing Number and Location Routing Number returned + by the query. If available to the UAC, the UAC MUST include the JIP- + param. + + If the response to the initial INVITE is a 3xx-Redirect, the UAC + generates a new initial INVITE request to the destination specified + in the Contact header field, as per standard SIP. If a UAC receives + a 3xx-Redirect response to an initial INVITE, the new INVITE + generated by the UAC MUST contain the P-DCS-Billing-Info header field + values from the 3xx-Redirect response. If the UAC is acting as a + back-to-back user agent (B2BUA), instead of generating a new INVITE + it MAY generate a private-URL and place it in the Contact header + field of a 3xx-Redirect response sent to the originating endpoint. + This private-URL MUST contain (or contain a pointer to) the P-DCS- + Billing-Info value, which indicates the charging arrangement for the + new call, and an expiration time very shortly in the future, to limit + the ability of the originator to re-use this private-URL for multiple + calls. + + A UAC that includes a Refer-To header in a REFER request MUST include + a P-DCS-Billing-Info header in the Refer-To's URL. This P-DCS- + Billing-Info header MUST include the accounting information of the + initiator of the REFER. + +7.4. Procedures at an Untrusted User Agent Server (UAS) + + This header is never sent to an untrusted UAS, and is never sent by + an untrusted UAS. + +7.5. Procedures at a Trusted User Agent Server (UAS) + + The UAS MUST include a P-DCS-Billing-Info header in the first + reliable 1xx (except 100) or 2xx response to an initial INVITE or + SUBSCRIBE message. This P-DCS-Billing-Info header MUST include the + Billing-Correlation-ID generated by the UAS, the FEID of the UAS, and + + + +Andreasen, et al. Informational [Page 18] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + the RKS-Group-ID of the Record-Keeping server being used by the UAS. + The UAS MAY change the values of Acct-Charge-URI if it wishes to + override the billing information that was present in the INVITE + (e.g., for a toll-free call). The decision to do this and the + contents of the new Acct-Charge-URI MUST be determined by service + provider policy provisioned in the UAS. If the UAS performed an LNP + query, it MUST include the Routing Number and Location Routing Number + returned by the query. + + The UAS MUST add a P-DCS-Billing-Info header to a 3xx-Redirect + response to an initial INVITE, giving the accounting information for + the call forwarder, for the call segment from the destination to the + forwarded-to destination. + +7.6. Procedures at Proxy + + Three sets of proxy procedures are defined: (1) the procedures at an + originating proxy, (2) the procedures at a terminating proxy, and (3) + the procedures at a tandem proxy. + + The originating proxy is a proxy that received the INVITE or + SUBSCRIBE request from an untrusted endpoint. + + The terminating proxy is a proxy that sends the INVITE or SUBSCRIBE + request to an untrusted endpoint. + + A proxy that is neither an originating proxy nor a terminating proxy + is a tandem proxy. + + For purposes of mid-call changes, such as call transfers, the proxy + that receives the request from an untrusted endpoint is considered + the initiating proxy; the proxy that sends the request to a non- + trusted endpoint is considered the recipient proxy. Procedures for + the initiating proxy are included below with those for originating + proxies, while procedures for the recipient proxy are included with + those for terminating proxies. + + A proxy that both receives the request from an untrusted endpoint, + and sends the request to an untrusted endpoint, performs both sets of + procedures. + +7.6.1. Procedures at Originating Proxy + + The originating proxy MUST generate the Billing-Correlation-ID for + the call, and insert it into the P-DCS-Billing-Info header in the + initial INVITE or SUBSCRIBE message sent to the terminating entity, + along with the charging information for the call. The originating + proxy MUST include its FEID and the RKS-Group-ID for the + + + +Andreasen, et al. Informational [Page 19] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + Record-Keeping server being used by the originating proxy. If the + originating proxy performed an LNP query, it MUST include the Routing + Number, Location Routing Number, and JIP-param returned by the query. + Any P-DCS-Billing-Info header present from an untrusted UA MUST be + removed. + + If the Request-URI contains a private-URL, and the decoded username + contains billing information, the originating proxy MUST generate a + P-DCS-Billing-Info header with that decrypted information. + Otherwise, the originating proxy MUST determine the accounting + information for the call originator and insert a P-DCS-Billing-Info + header including that information. + + If the response to the initial INVITE is a 3xx-Redirect, received + prior to a non-100 provisional response, the originating proxy + generates a new initial INVITE request to the destination specified + in the Contact header field, as per standard SIP. If an originating + proxy receives a 3xx-Redirect response to an initial INVITE prior to + a non-100 provisional response, the INVITE generated by the proxy + MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect + response. + + If the response to the initial INVITE is a 3xx-Redirect, received + after a non-100 provisional response, the originating proxy generates + a private-URL and places it in the Contact header of a 3xx-Redirect + response sent to the originating endpoint. This private-URL MUST + contain (or contain a pointer to) the P-DCS-Billing-Info value, which + indicates the charging arrangement for the new call, and an + expiration time very shortly in the future, to limit the ability of + the originator to re-use this private-URL for multiple calls. + + An originating proxy that processes a REFER request from an untrusted + UA MUST include a P-DCS-Billing-Info header in the Refer-To's URL. + This P-DCS-Billing-Info header MUST include the accounting + information of the initiator. + +7.6.2. Procedures at Terminating Proxy + + The terminating proxy MUST NOT send the P-DCS-Billing-Info header to + an untrusted destination. + + The terminating proxy MUST include a P-DCS-Billing-Info header in the + first reliable 1xx (except 100) or 2xx response to an initial INVITE + or SUBSCRIBE message. This P-DCS-Billing-Info header MUST include + the Billing-Correlation-ID generated by the terminating proxy, the + FEID of the terminating proxy, and the RKS-Group-ID of the Record- + Keeping server being used by the terminating proxy. The terminating + proxy MAY change the values of Acct-Charge-URI if it wishes to + + + +Andreasen, et al. Informational [Page 20] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + override the billing information that was present in the INVITE + (e.g., for a toll-free call). The decision to do this and the + contents of the resulting P-DCS-Billing-Info header MUST be + determined by service provider policy provisioned in the terminating + proxy. If the terminating proxy performed an LNP query, it MUST + include the Routing Number and Location Routing Number returned by + the query. + + The terminating proxy MUST add P-DCS-Billing-Info headers to a 3xx- + Redirect response to an initial INVITE, giving the accounting + information for the call forwarder, for the call segment from the + destination to the forwarded-to destination. + + A proxy receiving a mid-call REFER request that includes a Refer-To + header generates a private-URL and places it in the Refer-To header + sent to the endpoint. This private-URL MUST contain the P-DCS- + Billing-Info value, which indicates the charging arrangement for the + new call, and an expiration time very shortly in the future, to limit + the ability of the endpoint to re-use this private-URL for multiple + calls. + +7.6.3. Procedures at Tandem Proxy + + If the tandem proxy performed an LNP query, it MUST insert the + Routing Number and Location Routing Number returned by the query into + the P-DCS-Billing-Info header in the first reliable 1xx/2xx/3xx + (except 100) response. + +8. P-DCS-LAES and P-DCS-Redirect + + NOTE: According to RFC 2804 [RFC2804], the IETF supports + documentation of lawful intercept technology if it is necessary to + develop it. The following section provides such documentation. The + [RFC2119] language, as stated above, describes the requirements of + the specification only if implemented, and strictly within the + applicability domain described above. See RFC 2804 for description + of issues regarding privacy, security, and complexity in relation to + this technology. + + The P-DCS-LAES extension contains the information needed to support + Lawfully Authorized Electronic Surveillance. This header contains + the address and port of an Electronic Surveillance Delivery Function + for delivery of a duplicate stream of event messages related to this + call. The header fields MAY also contain the associated BCID for the + event stream as well as additional address and port for delivery of + call content and associated cccid. The BCID is used to correlate a + series of events associated with a single call or session. The cccid + is used to identify an intercepted call content to an intercepted + + + +Andreasen, et al. Informational [Page 21] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + call. The P-DCS-LAES header is only used between proxies and trusted + UAs. The P-DCS-LAES header defined here is not backwards compatible + with that defined in [RFC3603], which is deprecated by the document. + This version of the P-DCS-LAES header adds a cccid parameter to + support the intercept of content, and deletes security key + information. This version does not mandate the use of the BCID. + + The P-DCS-Redirect extension contains call identifying information + needed to support the requirements of Lawfully Authorized Electronic + Surveillance of redirected calls. This header is only used between + proxies and trusted UAs. + + Note that there is overlap in function between the P-DCS-Redirect + header and the History-Info header specified in RFC 4244. The + original P-DCS-Redirect came to existence in RFC 3603 before the + History-Info. Therefore, the P-DCS-Redirect header is continued here + for backwards compatibility with existing implementations. + + Use of P-DCS-LAES and P-DCS-Redirect is controlled by a combination + of legislation, regulation, and court orders, which MUST be followed. + In certain cases, inclusion of these headers will be mandated, and + therefore MUST be present in the requests and responses indicated. + In other cases, inclusion of these headers will be forbidden, and + therefore MUST NOT be present in the request and responses indicated. + In the sub-sections that follow, use of "SHOULD" is intended to + capture these conflicting situations, e.g., a P-DCS-LAES header + SHOULD be included in an initial INVITE means either that it MUST be + included or that it MUST NOT be included, based on the applicable + court orders. + + + + + + + + + + + + + + + + + + + + + + +Andreasen, et al. Informational [Page 22] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +8.1. Syntax + + The formats of the P-DCS-LAES and P-DCS-Redirect headers are given by + the following ABNF (some terms used in this ABNF are defined in + [RFC3261] and [RFC5234]): + + P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig + *(SEMI Laes-param) + Laes-sig = hostport + Laes-param = Laes-content / Laes-cccid + Laes-bcid / generic-param + Laes-content = "content" EQUAL hostport + + Laes-bcid = "bcid" EQUAL 1*48(HEXDIG) + Laes-cccid = "cccid" EQUAL 1*8(HEXDIG) + + P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID + *(SEMI redir-params) + Called-ID = LDQUOT addr-spec RDQUOT + redir-params = redir-uri-param / redir-count-param / + generic-param + redir-uri-param = "redirector-uri" EQUAL Redirector + Redirector = LDQUOT addr-spec RDQUOT + redir-count-param = "count" EQUAL Redir-count + Redir-count = 1*DIGIT + + This document adds the following entry to Table 2 of [RFC3261]: + + Header field where proxy ACK BYE CAN INV OPT REG PUB + ------------ ----- ----- --- --- --- --- --- --- --- + P-DCS-LAES adr - - - o - - - + P-DCS-Redirect adr - - - o - - - + + SUB NOT REF INF UPD PRA MSG + --- --- --- --- --- --- --- + - - - - - - - + - - - - - - - + + The values of Laes-sig and Laes-content are addresses of the + Electronic Surveillance Delivery Function, and used as the + destination address for call-identifying information and call- + content, respectively. Laes-bcid contains a correlation ID that is + used to link a sequence of intercepted call processing events related + to a single call. Laes-cccid contains an identifier of the + intercepted call content. The Laes-bcid field MAY be present. The + BCID is included per network operator configuration to support events + reported as defined in [PCEM]. The Laes-cccid field MAY be present + when the Laes-content field is present. The Laes-cccid is included + + + +Andreasen, et al. Informational [Page 23] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + per network operator configuration for networks where entities + receiving the intercepted contents may act a media relay functions to + other surveillance functions that are the source of the content + surveillance request. The design of multiple surveillance entities + that receive call content is beyond the scope of this document. + + The P-DCS-Redirect header contains redirection information. The + Called-ID indicates the original destination requested by the user + (e.g., number dialed originally), the redir-uri-param indicates the + entity performing the redirection, and the Redir-count indicates the + number of redirections that have occurred. For example, if A calls + B, who forwards to C, who forwards to D, then, when C forwards to D, + the Called-ID will be A, redir-uri-param will be C, and count will be + 2. + +8.2. Procedures at an Untrusted User Agent Client (UAC) + + This header MUST NOT be sent to an untrusted UAC, and MUST NOT be + sent by an untrusted UAC. + +8.3. Procedures at a Trusted User Agent Client (UAC) + + The UAC checks for an outstanding lawfully authorized surveillance + order for the originating subscriber, and, if present, MAY include + this information in the Authorization for Quality of Service [PCDQOS] + or MAY signal this information to the device performing the intercept + (e.g., a Media Gateway). Otherwise, intercept access points are + instructed to perform call content and/or call data intercept by + mechanisms that are outside the scope of this document. + + If the P-DCS-LAES header is present in the first reliable 1xx (except + 100), 2xx, or 3xx response (indicating surveillance is required on + the terminating subscriber, but that the terminating equipment is + unable to perform that function), the UAC MAY include this + information in the Authorization for Quality of Service, or MAY + signal this information to the device performing the intercept (e.g., + a Media Gateway). Otherwise, intercept access points are instructed + to perform call content and/or call data intercept by mechanisms that + are outside the scope of this document. + + If a 3xx-Redirect response to the initial INVITE request is received, + and if a P-DCS-LAES header is present in the 3xx response, the UAC + SHOULD include that header unchanged in the reissued INVITE. The UAC + SHOULD also include a P-DCS-Redirect header containing the original + dialed number, the most recent redirecting party, and the number of + redirections that have occurred. Although it is technically possible + for the originating equipment to perform this surveillance (or add to + its existing surveillance of the call), the design of the + + + +Andreasen, et al. Informational [Page 24] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + surveillance system has the terminating equipment performing the + surveillance for all the intermediate forwardings. + + A UAC that includes a Refer-To header in a REFER request, when the + originating subscriber has an outstanding lawfully authorized + surveillance order, SHOULD include a P-DCS-LAES header attached to + the Refer-To. The UAC MAY also include a P-DCS-Redirect header. The + P-DCS-LAES header MAY include the Laes-bcid parameter set to a value + that uniquely identifies the call, SHOULD include the address and + port of the local Electronic Surveillance Delivery Function for a + copy of the call's event messages, SHOULD include the address and + port of the local Electronic Surveillance Delivery Function for the + copy of call content if call content is to be intercepted, and MAY + include the Laes-cccid parameter set to a value that uniquely + identifies the intercepted audio stream if call content is to be + intercepted. + + The trusted UAC MUST NOT send the P-DCS-LAES and P-DCS-Redirect + headers to an untrusted entity. + +8.4. Procedures at an Untrusted User Agent Server (UAS) + + This header MUST NOT be sent to an untrusted UAS, and MUST NOT be + sent by an untrusted UAS. + +8.5. Procedures at a Trusted User Agent Server (UAS) + + The UAS checks for an outstanding lawfully authorized surveillance + order for the terminating subscriber, or presence of the P-DCS-LAES + header in the INVITE request. If either is present, the UAS MAY + include this information in the authorization for Quality of Service + [PCDQOS]. Otherwise, intercept access points are instructed to + perform call content and/or call data intercept by mechanisms that + are outside the scope of this document. + + If the terminating equipment is unable to perform the required + surveillance (e.g., if the destination is a voicemail server), the + UAS SHOULD include a P-DCS-LAES header in the first reliable 1xx + (except 100), 2xx, or 3xx response requesting the originating proxy + to perform the surveillance. The P-DCS-LAES header MAY include the + Laes-bcid parameter with a value that uniquely identifies the call, + SHOULD include the address and port of the local Electronic + Surveillance Delivery Function for a copy of the call's event + messages, SHOULD include the address and port of the local Electronic + Surveillance Delivery Function for the copy of call content if call + + + + + + +Andreasen, et al. Informational [Page 25] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + content is to be intercepted, and MAY include the Laes-cccid + parameter set to a value that uniquely identifies the intercepted + audio stream if call content is to be intercepted. + + If the response to the initial INVITE request is a 3xx-Redirect + response, and there is an outstanding lawfully authorized + surveillance order for the terminating subscriber, the UAS SHOULD + include a P-DCS-LAES header in the 3xx-Redirect response, with + contents as described above. + + The trusted UAS MUST NOT send the P-DCS-LAES and P-DCS-Redirect + headers to an untrusted entity. + +8.6. Procedures at Proxy + + Two sets of proxy procedures are defined: (1) the procedures at an + originating proxy, and (2) the procedures at a terminating proxy. + The originating proxy is a proxy that receives the INVITE request + from an untrusted endpoint. + + The terminating proxy is a proxy that sends the INVITE request to an + untrusted endpoint. + + For purposes of mid-call changes, such as call transfers, the proxy + that receives the request from an untrusted endpoint is considered + the initiating proxy; the proxy that sends the request to an + untrusted endpoint is considered the recipient proxy. Procedures for + the initiating proxy are included below with those for originating + proxies, while procedures for the recipient proxy are included with + those for terminating proxies. + + A proxy that both receives the INVITE request from an untrusted + endpoint, and sends the INVITE request to an untrusted endpoint, MUST + NOT generate P-DCS-LAES nor P-DCS-Redirect headers. + + A proxy that is neither an originating proxy nor a terminating proxy + SHOULD pass the P-DCS-Laes and P-DCS-Redirect headers in requests and + responses. + +8.6.1. Procedures at Originating Proxy + + The originating proxy MUST remove any P-DCS-LAES and P-DCS-Redirect + headers in requests or responses to or from an untrusted proxy or + untrusted UA. + + The originating proxy checks for an outstanding lawfully authorized + surveillance order for the originating subscriber, and, if present, + MAY include this information in the Authorization for Quality of + + + +Andreasen, et al. Informational [Page 26] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + Service [PCDQOS] or MAY signal this information to the device + performing the intercept (e.g., a Media Gateway). Otherwise, + intercept access points are instructed to perform call content and/or + call data intercept by mechanisms that are outside the scope of this + document. + + If the P-DCS-LAES header is present in the first reliable 1xx (except + 100), 2xx, or 3xx response (indicating surveillance is required on + the terminating subscriber, but that the terminating equipment is + unable to perform that function), the originating proxy MAY include + this information in the Authorization for Quality of Service, or MAY + signal this information to the device performing the intercept (e.g., + a Media Gateway). Otherwise, intercept access points are instructed + to perform call content and/or call data intercept by mechanisms that + are outside the scope of this document. + + If the Request-URI in an initial INVITE request contains a private- + URL, the originating proxy MUST decrypt the userinfo information to + find the real destination for the call, and other special processing + information. If electronic surveillance information is contained in + the decrypted userinfo, the originating proxy SHOULD generate a P- + DCS-LAES and (if necessary) a P-DCS-REDIRECT header with the + surveillance information. + + If a 3xx-Redirect response to the initial INVITE request is received + prior to a non-100 provisional response, and if a P-DCS-LAES header + is present in the 3xx response, the originating proxy SHOULD include + that header unchanged in the reissued INVITE. The originating proxy + SHOULD also include a P-DCS-Redirect header containing the original + dialed number, the most recent redirecting party, and the number of + redirections that have occurred. + + If a 3xx-Redirect response to the initial INVITE request is received + after a non-100 provisional response, the originating proxy generates + a private-URL and places it in the Contact header of a 3xx-Redirect + response sent to the originating endpoint. If a P-DCS-LAES header is + present in the 3xx response, this private-URL MUST contain (1) the + electronic surveillance information from the 3xx-Redirect response, + (2) the original destination number, (3) the identity of the + redirecting party, and (4) the number of redirections of this call. + + An originating proxy that processes a REFER request [RFC3515] from an + untrusted UA, when the originating subscriber has an outstanding + lawfully authorized surveillance order, becomes a B2BUA for that + request. It SHOULD reissue the request with a P-DCS-LAES header + added to the Refer-To's URL. It MAY also include a P-DCS-Redirect + header. The P-DCS-LAES header SHOULD include (1) the address and + port of the local Electronic Surveillance Delivery Function for a + + + +Andreasen, et al. Informational [Page 27] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + copy of the call's event messages, (2) the address and port of the + local Electronic Surveillance Delivery Function for the copy of call + content if call content is to be intercepted. The P-DCS-LAES header + MAY include (1) the Laes-bcid parameter set to a value that uniquely + identifies the call, and (2) the Laes-cccid parameter set to a value + that uniquely identifies the intercepted audio stream if call content + is to be intercepted. + + An initiating proxy that sends a mid-call REFER request including a + Refer-To header, when the initiating subscriber has an outstanding + lawfully authorized surveillance order, SHOULD include a P-DCS-LAES + header in the Refer-To's URL. + + The originating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect + headers to an untrusted entity. + +8.6.2. Procedures at Terminating Proxy + + The terminating proxy MUST remove any P-DCS-LAES and P-DCS-Redirect + headers in requests or responses to or from an untrusted proxy or UA. + + The terminating proxy checks for an outstanding lawfully authorized + surveillance order for the terminating subscriber. If present, the + terminating proxy MAY include this information in the authorization + for Quality of Service [PCDQOS]. Otherwise, intercept access points + are instructed to perform call content and/or call data intercept by + mechanisms that are outside the scope of this document. + + The terminating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect + headers to an untrusted entity, either as headers in the request or + response, or as headers attached to URIs in the request or response. + + If the terminating equipment is unable to perform the required + surveillance (e.g., if the destination is a voicemail server), the + terminating proxy SHOULD include a P-DCS-LAES header in the first + reliable 1xx/2xx/3xx (except 100) response requesting the originating + proxy to perform the surveillance. The P-DCS-LAES header MAY include + the Laes-bcid parameter set to a value that uniquely identifies the + call, SHOULD include the address and port of the local Electronic + Surveillance Delivery Function for a copy of the call's event + messages, SHOULD include the address and port of the local Electronic + Surveillance Delivery Function for the copy of call content if call + content is to be intercepted, and MAY include the Laes-cccid + parameter set to a value that uniquely identifies the audio stream if + call content is to be intercepted. + + + + + + +Andreasen, et al. Informational [Page 28] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + If the response to the initial INVITE request is a 3xx-Redirect + response, and there is an outstanding lawfully authorized + surveillance order for the terminating subscriber, the terminating + proxy SHOULD include a P-DCS-LAES header in the 3xx-Redirect + response, with contents as described above. + + A proxy receiving a mid-call REFER request [RFC3515] that includes a + Refer-To header with a P-DCS-LAES header attached becomes a B2BUA for + this request. It MUST generate a private-URL and place it in the + Refer-To header sent to the endpoint. This private-URL MUST contain + the P-DCS-LAES and P-DCS-Redirect information from the attached + header fields. + +9. Security Considerations + + QoS gate coordination, billing information, and electronic + surveillance information are all considered to be sensitive + information that MUST be protected from eavesdropping and furthermore + require integrity checking. It is therefore necessary that the + trusted UAs and proxies take precautions to protect this information + from eavesdropping and tampering. Use of IPsec or TLS between + proxies and trusted UAs is REQUIRED. A minimum mandatory-to- + implement IPsec configuration for the DCS architecture is given by + [PCSEC]. Also REQUIRED is mutual authentication (1) between Proxies + and (2) between trusted UAs and Proxies, both of which MAY be + implemented with administratively pre-shared keys, or through + consultation with another trusted third party. If IPsec is to be + used, the specification of the security policies and procedures of + the administrative domain where these headers are applicable (and all + connections between administrative domains in the federation) MUST + define an interoperable set of options. + +10. IANA Considerations + + The following changes to the Session Initiation Protocol (SIP) + Parameters registry have been made by IANA. + + The Header Fields registry has been updated as follows: + + Header Name compact Reference + ----------------- ------- --------- + P-DCS-Trace-Party-ID [RFC5503] + P-DCS-OSPS [RFC5503] + P-DCS-Billing-Info [RFC5503] + P-DCS-LAES [RFC5503] + P-DCS-Redirect [RFC5503] + + + + + +Andreasen, et al. Informational [Page 29] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + The following entries in the Header Field Parameters and Parameter + Values registry have been updated: + + Header Field Parameter Name Values + Reference + ---------------------------- --------------------------- ---------- + + P-DCS-Billing-Info called No + [RFC5503] + P-DCS-Billing-Info calling No + [RFC5503] + P-DCS-Billing-Info charge No + [RFC5503] + P-DCS-Billing-Info locroute No + [RFC5503] + P-DCS-Billing-Info rksgroup No + [RFC5503] + P-DCS-Billing-Info routing No + [RFC3603] + P-DCS-LAES content No + [RFC5503] + P-DCS-Redirect count No + [RFC5503] + P-DCS-Redirect redirector-uri No + [RFC5503] + + The following entry in the Header Field Parameters and Parameter + Values registry has been marked "OBSOLETED": + + Header Field Parameter Name Values + Reference + ---------------------------- --------------------------- ---------- + P-DCS-LAES key (OBSOLETED) No + [RFC3603][RFC5503] + + + + + + + + + + + + + + + + + +Andreasen, et al. Informational [Page 30] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + The following entries in the Header Field Parameters and Parameter + Values registry have been created: + + Header Field Parameter Name Values + Reference + ---------------------------- --------------------------- ---------- + P-DCS-Billing-Info jip No + [RFC5503] + P-DCS-LAES bcid No + [RFC5503] + P-DCS-LAES cccid No + [RFC5503] + P-DCS-Trace-Party-ID timestamp No + [RFC5503] + +11. Changes since RFC 3603 + + o A timestamp parameter is added to the P-DCS-Trace-Party-ID header + when available. Procedures on the use of the Target-Dialog header + used together with the P-DCS-Trace-Party-ID are added. + + o The JIP parameter is added to the P-DCS-Billing-Info header when + available. + + o The BCID billing correlation identifier and cccid (call content + channel identifier) are added to the P-DCS-LAES header. + + o P-DCS-Billing-Info header is applied to the SUBSCRIBE method. + + o P-DCS-REDIRECT header is applied to the REFER method. + + o The use of QoS authorization to establish content intercept is + made optional in order not to preclude alternative content + intercept provisioning mechanisms. + + o PUBLISH and MESSAGE methods are added to the SIP method + applicability matrices throughout. + + o Correction is made to Table 2 to add m=modify. + + o IANA considerations are updated. + + o Corrections are made to timestamp format, and references are + updated. + + + + + + + +Andreasen, et al. Informational [Page 31] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +12. Acknowledgments + + The Distributed Call Signaling work in the PacketCable project is the + work of a large number of people, representing many different + companies. The authors would like to recognize and thank the + following for their assistance: John Wheeler, Motorola; David + Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, Jay + Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido + Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi + Khazai, Brian Lindsay. Nortel; John Chapman, Bill Guckel, Michael + Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, + Tung-Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; Lucent + Cable Communications; and Miguel Garcia, Ericsson. + + Previous versions further acknowledged, as co-authors, several people + for providing the text of this document. They are: + + Bill Marshall (wtm@research.att.com) and K. K. Ramakrishnan + (kkrama@research.att.com), AT&T; Ed Miller + (edward.miller@terayon.com), Terayon; David Hancock (D.Hancock@ + Cablelabs.com) and Glenn Russell (G.Russell@Cablelabs.com), + CableLabs; Burcak Beser (burcak@juniper.net) Juniper Networks; Mike + Mannette (Michael_Mannette@3com.com) and Kurt Steinbrenner + (Kurt_Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com) and + Flemming Andreasen (fandreas@cisco.com), Cisco Systems; John Pickens + (jpickens@com21.com), Com21; Poornima Lalwaney + (poornima.lalwaney@nokia.com), Nokia; Jon Fellows + (jfellows@coppermountain.com), Copper Mountain Networks; Doc Evans + (n7dr@arrisi.com) Arris, and Keith Kelly (keith@netspeak.com), + NetSpeak. + +13. References + +13.1. Normative References + + [RFC1305] Mills, D., "Network Time Protocol (Version 3) + Specification, Implementation", RFC 1305, March 1992. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer + Method", RFC 3515, April 2003. + + + +Andreasen, et al. Informational [Page 32] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 + for IPv4, IPv6 and OSI", RFC 4330, January 2006. + + [RFC4538] Rosenberg, J., "Request Authorization through Dialog + Identification in the Session Initiation Protocol (SIP)", + RFC 4538, June 2006. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + +13.2. Informative References + + [DCSARCH] Marshall, W., Osman, M., Andreasen, F., and D. Evans, + "Architectural Considerations for Providing Carrier Class + Telephony Services Utilizing SIP-based Distributed Call + Control Mechanisms", January 2003. + + [PCDQOS] Cable Television Laboratories, Inc., "PacketCable 1.5 + Specifications, Dynamic Quality of Service", August 2005. + + [PCEM] Cable Television Laboratories, Inc., "PacketCable 1.5 + Specifications, Event Messages", December 2005. + + [PCSEC] Cable Television Laboratories, Inc., "PacketCable 1.5 + Specifications, Security", January 2005. + + [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, + May 2000. + + [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private + Extensions to the Session Initiation Protocol (SIP) for + Asserted Identity within Trusted Networks", RFC 3325, + November 2002. + + [RFC3603] Marshall, W. and F. Andreasen, "Private Session Initiation + Protocol (SIP) Proxy-to-Proxy Extensions for Supporting + the PacketCable Distributed Call Signaling Architecture", + RFC 3603, October 2003. + + + + + + + + + + +Andreasen, et al. Informational [Page 33] + +RFC 5503 SIP Proxy-to-Proxy Extensions March 2009 + + +Authors' Addresses + + Flemming Andreasen + Cisco + Edison, NJ + USA + + EMail: fandreas@cisco.com + + + Bernie McKibben + CableLabs + Louisville, CO + USA + + EMail: B.McKibben@cablelabs.com + + + Bill Marshall + AT&T + Florham Park, NJ + USA + + EMail: wtm@research.att.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Andreasen, et al. Informational [Page 34] + |