SIP Working Group W. Marshall Internet Draft K. Ramakrishnan Document: <draft-dcsgroup-sip-proxy-proxy-02.txt> AT&T Category: Informational E. Miller G. Russell CableLabs B. Beser M. Mannette K. Steinbrenner 3Com D. Oran F. Andreasen Cisco J. Pickens Com21 P. Lalwaney Nokia J. Fellows Motorola D. Evans Secure Cable Solutions K. Kelly NetSpeak June, 2000 SIP proxy-to-proxy extensions for supporting DCS Status of this Memo This document is an Internet-Draft and is in full compliance with all provisions of Section 10 of RFC2026[1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." DCS Group Category Informational - Expiration 12/31/2000 1 SIP Proxy-to-Proxy Extensions June 2000 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as <draft- dcsgroup-sip-proxy-proxy-02.txt>, and expires December 31, 2000. Please send comments to the authors. 1. Abstract In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes extensions to the Session Initiation Protocol (RFC2543) for supporting the exchange of customer information and billing information between trusted entities in the architecture described in <draft-dcsgroup- sip-arch-02.txt>. 2. 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 RFC-2119 [2]. 3. Introduction In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys billing information and expectations about the parties involved in the call. There are many billing models used in deriving revenue from telephony services today. Charging for telephony services is tightly coupled to the use of network resources. It is outside the scope of this document to discuss the details of these numerous and varying methods. A key motivating principle of the DCS architecture described in [3] 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 DCS Group Category Informational - Expiration 12/31/00 2 SIP Proxy-to-Proxy Extensions June 2000 and authorized before receiving access to network resources and billable enhanced services. DCS-Proxies, as defined in [3], have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path. Edge routers provide the policy enforcement mechanism and also capture and report 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. For these reasons, it is appropriate to consider defining SIP header extensions to allow DCS Proxies to exchange information during call setup. It is the intent that the extensions would only appear on trusted network segments, should be inserted upon entering a trusted network region, and removed before leaving trusted network segments. Rules for inserting and removing headers exchanged only between proxies are for further study. Significant amounts of information is retrieved by an originating 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. Call-ID 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. DCS Group Category Informational - Expiration 12/31/00 3 SIP Proxy-to-Proxy Extensions June 2000 The addition of two SIP General Header Fields allows for the capture of billing information and billing identification for the duration of the call. Alternative techniques such as multi-part attachments will not coexist with encrypted messages. It is the intent that the billing extensions would only appear on trusted network segments, and MAY be inserted by a DCS Proxy in INVITE requests entering a trusted network segment, and removed before leaving trusted network segments. 4. Trust Boundary The DCS architecture 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 media servers operated by third-party service providers. Certain subscriber-specific information, such as billing and accounting information, stays within the trust boundary. Other subscriber-specific information, such as endpoint identity, may be presented to untrusted endpoints or may be withheld based on subscriber profiles. The User Agent (UA) may be either within the trust boundary or outside the trust boundary, depending on exactly what function is being performed and exactly how it is being performed. Accordingly, the procedures followed by a User Agent are different depending on whether the UA is within the trust boundary or outside the trust boundary. The following sections giving procedures for User Agents therefore are subdivided into trusted user agents and untrusted user agents. A trusted user agent is, in almost all cases, equivalent to the combination of an untrusted user agent and a proxy. 5. Requires and Supported Option Tag "DCS" UACs which support the extensions defined here include a Supported header in all requests, except ACK, with the option tag "DCS". Proxies on the signaling path may have their own requirements for the extensions defined in this document. If the Supported header in the request lists the option tag "DCS", a proxy can be certain the UAC understands them. If, however, the Supported header was absent, or was present but didn't include the tag "DCS", the proxy MAY reject the request with a 421, and indicate in the Require header that the feature "DCS" is needed. As an alternative, the proxy MAY forward the request, but MUST NOT add any extensions defined in this DCS Group Category Informational - Expiration 12/31/00 4 SIP Proxy-to-Proxy Extensions June 2000 document. This will allow the call to proceed without the extensions. If a proxy wishes to ensure that the UAS understands the extensions described in this document, it MAY add a Requires header to the request with the option tag "DCS". If a proxy wishes to ensure that other proxies understand the extensions described in this document, it MAY add a Proxy-Requires header to the request with the option tag "DCS". If a proxy receives a request with a Proxy-Requires header with the option tag "DCS", but does not support the extensions described in this document, it MUST reject the request with a 421. If the UAS receives a request with a Requires header with the option tag "DCS", but does not support the extensions described in this document, it MUST reject the request with a 421. If a proxy or UAS receives a request with a Supported header with the option tag "DCS", and uses the extensions described in this document in the response, it MUST include a Require header in the response indicating that the feature "DCS" was applied to the response. 6. 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 independent of caller-id, and operates 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. To initiate a customer-originated-trace from an untrusted UAC, an additional header is defined for the INVITE request sent from the untrusted UAC to its proxy. This header is called Dcs-Trace-Party- ID, and does not appear in any other request or response. The proxy receiving a properly formed INVITE request with this header performs the service-provider-specific functions of recording and reporting the caller identity for law enforcement action. The proxy then completes 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. 6.1 Syntax The BNF description of this header is: Dcs-Trace-Party-ID = "Dcs-Trace-Party-ID" ":" "<" addr-spec ">" DCS Group Category Informational - Expiration 12/31/00 5 SIP Proxy-to-Proxy Extensions June 2000 Addr-spec contains a URL that identifies the remote endpoint. Addr- spec typically contains a tel: URL giving the identity of the remote endpoint, or a DCS-URL with a private-param when privacy was requested by the remote endpoint. This URL SHOULD be the value received in the Remote-Party-ID header of the harassing call. 6.2 Procedures at an Untrusted User Agent Client (UAC) The UAC MUST insert a Dcs-Trace-Party-ID header into the initial INVITE message for a customer-originated-trace request. The UAC MUST use a Request-URI with username of "call-trace" and host identifying the provisioned proxy for the untrusted UA. 6.3 Procedures at a Trusted User Agent Client (UAC) A trusted UAC performs the customer-originated-trace in a manner similar to the originating proxy, described below. A trusted UAC MUST NOT include this header in any request. 6.4 Procedures at an Untrusted User Agent Server (UAS) This header MUST NOT appear in any response sent by a UAS. 6.5 Procedures at a Trusted User Agent Server (UAS) This header MUST NOT appear in any request sent by a UAS. 6.6 Procedures at Proxy Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint. The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint. A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to an untrusted endpoint, performs both sets of procedures. 6.6.1 Procedures at Originating Proxy If the Dcs-Trace-Party-ID header is present in the initial INVITE request from the UAC, and the Request-URI of the INVITE has username of "call-trace" and host of the originating proxy, the originating proxy MUST perform the service-provider-specific functions of recording and reporting the caller identity for law enforcement action. The proxy then MUST direct the call to either an announcement server or to the service-provider's business office to collect further information about the complaint. DCS Group Category Informational - Expiration 12/31/00 6 SIP Proxy-to-Proxy Extensions June 2000 The originating proxy MUST remove the Dcs-Trace-Party-ID header from the INVITE before sending the request to another proxy or UAS. 6.6.2 Procedures at Terminating Proxy This header MUST NOT appear in any request or response sent by a proxy. 7. DCS-GATE The Dcs-Gate header extension is used only on requests and responses between proxies. It never is sent to, nor sent by, an untrusted UAC/UAS. The proxy-proxy signaling establishes a synchronization path that may be required by the PacketCable Dynamic Quality of Service (D- QoS) specification to coordinate the release of resources of the call. As per the D-QoS specification, the CMTS monitors the packet flow, and generates a Gate-Close message in response to either an explicit close request from the MTA/RGW, or when an equipment or facility failure causes the connection to be broken. This Gate-Close message is directed either to the local CMS/Agent, or to the remote CMS/Agent, or to the CMTS serving the remote MTA, depending on the capabilities of the endpoints. When a CMS/Agent receives such a Gate-Close message, it considers it identical to a call termination request. The Dcs-Gate header is used between proxies, and conveys the location of the remote gate, identity of the gate, and the security key to be used in gate coordination messages. 7.1 Syntax The BNF description of the Dcs-Gate header is as follows: Dcs-Gate = "Dcs-Gate" ":" hostport "/" Gate-ID [ ";" Gate-Key ";" Gate-CipherSuite] [Gate-strength-token] Gate-ID = 1*alphanum Gate-Key = 1*alphanum Gate-CipherSuite = token Gate-strength-token = "required" | "optional" Hostport gives the IP address or FQDN of the CMTS/EdgeRouter that enforces the QoS, or the endpoint system that simulates the gate coordination exchange on behalf of an edge router. Gate-ID is a token used at the system named in the Hostport parameter to identify the particular session. For DCS systems, it is a 32-bit quantity encoded as an 8-character string of digits 0-9 and letters a-f. DCS Group Category Informational - Expiration 12/31/00 7 SIP Proxy-to-Proxy Extensions June 2000 Gate-Key is a character string that provides keying information to the system named in the hostport parameter. The method of deriving the actual keys for the gate coordination messages, and the security procedures, are beyond the scope of this document. Gate-CipherSuite is a character string that gives the type of encryption algorithm that will be used to secure the gate coordination messages. Gate-Strength-Token specifies whether the gate coordination is required or optional for the current session. Its use is described in the following sections. 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) A UAC located within the trust boundary of the service provider performs the functions given in section 7.6.1. 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) A UAS located within the trust boundary of the service provider performs the functions given in section 7.6.2. 7.6 Procedures at Proxy The Dcs-Gate header MUST NOT appear in any message other than the initial INVITE request, or in the first non-100 response to that request. The proxy MUST remove the Dcs-Gate header in any request or response sent to an untrusted endpoint. Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint. The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint. A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to a non-trusted endpoint, does not generate a Dcs-Gate header. DCS Group Category Informational - Expiration 12/31/00 8 SIP Proxy-to-Proxy Extensions June 2000 A proxy that is neither an originating proxy nor a terminating proxy has no function in coordinating the commitment of resources. 7.6.1 Procedures at Originating Proxy The originating proxy MUST insert a Dcs-Gate header in the initial INVITE message for a new call. The originating proxy MUST identify the system that will perform gate coordination (either the proxy itself, or the CMTS controlling the media flow to the endpoint), and the identification token used at that system to identify the call. It MUST insert the IP address or FQDN of that system in the hostport parameter of the Dcs-Gate header, and the identification token as the Gate-ID. The originating proxy MUST pick a security key and cipher suite for the gate coordination message exchange, and insert these values in the Dcs-Gate header. If the system that will perform gate coordination is a CMTS, the strength token MUST be given as required. If the system that will perform gate coordination is the proxy itself, the strength token MAY be given as optional, or omitted. 7.6.2 Procedures at Terminating Proxy The terminating proxy MUST identify the system that will perform gate coordination (either the proxy itself, or the CMTS controlling the media flow to the endpoint), and the identification token used at that system to identify the call. Gate coordination will be required for this call if (1) the strength token in the Dcs-Gate header in the initial INVITE indicates 'required', or (2) the system that will perform gate coordination at the destination is a CMTS. If gate coordination is required for this call, the terminating proxy MUST include a Dcs-Gate header in the first non-100 response to the initial INVITE request. It MUST insert the IP address or FQDN of the system that will perform gate coordination in the hostport parameter of the Dcs-Gate header, and the identification token as the Gate-ID. If gate coordination is not required for this call, the terminating proxy SHOULD NOT include a Dcs-Gate header in the first non-100 response to the initial INVITE request. 8. DCS-ALSO and DCS-REPLACES This section describes a set of extensions to SIP which allow for various call control services. Example services include blind transfer, transfer with consultation, and ad-hoc conferencing. For the various services described here, we overview the requirements for the service, and specify the protocol functions needed to DCS Group Category Informational - Expiration 12/31/00 9 SIP Proxy-to-Proxy Extensions June 2000 support it. We then define a basic set of SIP primitives that can be used to construct these services, and others. This section describes extensions to SIP for providing call control services. Call control services relate to participant management. These services are all built on the basic blocks of adding and removing users from a call. Examples include transfer (the simultaneous removal and addition of a member from a call), multi- party calling, call bridging, and ad-hoc bridged conferences. Our aim is to provide a general set of tools, which can be used to construct, at a minimum, a core set of services, but be potentially useful as building blocks for future services. To accomplish this goal, we begin by overviewing the requirements for each of the core services, then outline the basic primitives that we have concluded are needed. The following subsection formally defines these primitives through new headers and UA behavior. In the blind transfer service, two parties are in an existing call. One party (the transferring party) wishes to terminate the call with the other party (the transferred party), and at the same time transfer them to another party (the transferred-to party). Transfer with consultation is similar to blind transfer. However, the transferring party first contacts the transferred-to party to approve the transfer through multimedia communication. Pending approval, the transferring party then simultaneosly disconnects from the transferred-to and transferred parties, and connects the transferred and transferred-to parties. The transferring and transferred parties stay connected if, for some reason, the transfer fails. In three-way-calling service, a user A has a call in progress with B, and a separate call in progress with C. These calls are unrelated, with different Call-ID's. From this double call scenario, the conference out of consultation service allows the calls to be merged, resulting in a single, bridged conference. Two additional headers are defined to provide these services, Dcs- Also and Dcs-Replaces. Various combinations of these with other existing headers are used to provide the call control services listed above, and can be used to provide a number of other services beyond those listed. The Dcs-Also extension advises the recipient to issue INVITE requests to the URLs listed. The Dcs-Replaces extension advises the recipient to issue a BYE request to an existing call leg. When combined, the Dcs-Also function is performed prior to the Dcs- Replaces function. Consider a call from party A to party B. Party B wishes to blind transfer the call to party C. B sends an INVITE A, Also: C, Replaces: B. Party A calls C, then issues a BYE to B, completing the transfer. DCS Group Category Informational - Expiration 12/31/00 10 SIP Proxy-to-Proxy Extensions June 2000 Transfer with consultation proceeds similarly. Party B establishes a second connection to party C, for consultation. When ready to transfer, B sends an INVITE A, Also: C, Replaces: B. Additional headers in the Also: C are used to identify the particular call leg between B and C that is to be redirected. Three-way-calling, or ad-hoc conferencing, involves a bridge service in DCS. Two prior calls exist, from party A to party B, and from party A to party C; party A wishes to join them in an ad-hoc conference. A sends an INVITE bridge-service, Also: B, C. Additional headers in the Also: B identify the particular call leg between A and B that is to be replaced, and additional headers in the Also: C identify the particular call leg between A and C. Throughout the following descriptions, INVITE(Also) refers to an INVITE message that contains a Dcs-Also header; INVITE(Replace) refers to an INVITE message that contains a Dcs-Replaces header, and INVITE(Also,Replace) refers to an INVITE message that contains both. 8.1 Syntax Dcs-Also = "Dcs-Also" ":" DCS-URL *[ "," DCS-URL] Dcs-Replaces = "Dcs-Replaces" ":" SIP-URL *[ "," SIP-URL] An example of a simple Dcs-Also header, as used in the blind transfer service, is: INVITE sip:555-1111@dp.provider Dcs-Also: sip:555-3333@dp.provider Dcs-Replaces: sip:555-2222@dp.provider This alters an existing call from 555-1111 to 555-2222, transferring the original caller (555-1111) to the new destination 555-3333. An example of a more complex Dcs-Also header, as used in the three- way-calling service, is: INVITE sip:bridge@dp.provider Dcs-Also: sip:555-2222@dp-b.provider ? Call-ID=call-from-555-1111-to-555-2222 & Dcs-Replaces=sip:555-1111@dp-o.provider This causes the bridge service to initiate a call to 555-2222, with the new call having the same Call-ID as the original one from 555- 1111, and replacing 555-1111. 8.2 Procedures at initiator Dcs-Also and Dcs-Replaces provide tools by which many call control services may be built. For purposes of this specification, only three are specified at the initiator: blind transfer, consultative DCS Group Category Informational - Expiration 12/31/00 11 SIP Proxy-to-Proxy Extensions June 2000 transfer, and ad-hoc conferencing. The procedures necessary to support these are specified at the recipient. A mid-call change is sent by the initiator (UAI) which may be either the UAS or UAC for the active call. The destination of the mid-call change is the recipient (UAR). 8.2.1 Blind Transfer To initiate a blind transfer, there MUST be an existing call from UAI to UAR. The identity of the desired transfer destination is given here as URL-T. The desired end result is a call from UAR to T. This is shown in Figure 1. From the starting state (left diagram) UAI sends an INVITE(also,replace) to UAR, who initiates an INVITE to T (middle diagram), then UAR terminates the call with UAI (rightmost diagram). UAI <--> UAR UAI <--> UAR UAI UAR ^ ^ | | v v T T T Figure 1: Call Transfer (Blind) To initiate a blind transfer, the UAI MUST send an INVITE to UAR, with call-leg identification matching the existing call between UAI and UAR, that contains both a Dcs-Also header and a Dcs-Replaces header. The INVITE request MUST NOT contain an SDP. The Dcs-Also header MUST contain URL-T. The Dcs-URL MAY contain headers for Dcs-Billing-ID, Dcs-Billing-Info, and Dcs-State. For this service, additional header parameters Call-ID and Dcs-Replaces MUST NOT be attached to the Dcs-Also header. An originating UAC within the trust boundary of the service provider MUST include billing arrangements for the new call(s) to be made by the recipient, as a result of this message. The UAC MUST include Dcs-Billing-ID and Dcs-Billing-Info additional headers appended to the Dcs-Also header to provide this information. See section 10 for information about the billing headers. The originating UAC MUST check for an outstanding lawfully authorized surveillance order for the initiating subscriber. If found, the UAC MUST include a Dcs- LAES header in the INVITE. The Dcs-Laes header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, MAY include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content, and MUST include a random string for use as a security key between the Delivery Functions. Other additional header parameters SHOULD NOT be attached to the Dcs-Also header. DCS Group Category Informational - Expiration 12/31/00 12 SIP Proxy-to-Proxy Extensions June 2000 The Dcs-Replaces header MUST contain a copy of the From or To header (whichever refers to UAI) from the existing UAI-UAR call: copy of From header if the UAI is the UAC and copy of To if the UAI is the UAS. Additional header parameters MUST NOT be attached to the Dcs- Replaces header. The response to the INVITE is a non-200 value if the UAR was unwilling or unable to execute the request. A 200-OK response to the INVITE indicates a successful initiation of the blind transfer; any error response leaves the original call intact. A BYE message from UAR indicates successful completion of the blind transfer. 8.2.2 Consultative Transfer To initiate a consultative transfer, there MUST be a call active from UAI to UAR, and a call active from UAI to the transfer destination, called here UAT. The Call-ID for the existing call from UAI to UAR is denoted UAI-UAR. This is shown in Figure 2. From the starting state (left diagram) UAI sends an INVITE(also,replace) to UAT, who initiates an INVITE(replace) to UAR (next diagram), UAR terminates the call with UAI (next diagram), and UAT terminates the call with UAI (final diagram). UAI <-> UAR UAI <-> UAR UAI UAR UAI UAR \ \ ^ \ ^ ^ \ \ | \ | | \ \ v \ v v UAT UAT UAT UAT Figure 2: Call Transfer (Consultative) To initiate a consultative transfer, the UAI MUST send an INVITE to UAT, with call-leg identification matching the existing call between UAI and UAT, that contains both a Dcs-Also header and a Dcs-Replaces header. The INVITE request MUST NOT contain an SDP. The Dcs-Also header MUST contain the URL of UAR, and MUST have attached a Call-ID header with value UAI-UAR, and a Dcs-Replaces header giving the From or To header (whichever refers to UAI) for the existing call from UAI to UAR. An untrusted UAC MUST attach the collection of Dcs-State headers for the call from UAI to UAR. An originating UAC within the trust boundary of the service provider MUST include billing arrangements for the new call(s) to be made by the recipient, as a result of this message. The UAC MUST include Dcs-Billing-ID and Dcs-Billing-Info additional headers appended to DCS Group Category Informational - Expiration 12/31/00 13 SIP Proxy-to-Proxy Extensions June 2000 the Dcs-Also header to provide this information. See section 10 for information about the billing headers. The originating UAC MUST check for an outstanding lawfully authorized surveillance order for the initiating subscriber. If found, the UAC MUST include a Dcs- LAES header in the INVITE. The Dcs-Laes header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, MAY include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content, and MUST include a random string for use as a security key between the Delivery Functions. Additional header parameters SHOULD NOT be attached to the Dcs-Also header. The Dcs-Replaces header MUST contain the value of the From or To header (whichever refers to UAI) from the existing call between UAI and UAT. Additional header parameter MUST NOT be attached to the Dcs-Replaces header. The response to the INVITE is a non-200 value if UAT was unwilling or unable to execute the request. A 200-OK response to the INVITE indicates a successful initiation of the transfer; any error response leaves the original call intact. BYE messages from UAR and from UAT indicate successful completion of the consultative transfer. 8.2.3 Ad-hoc Conference To initiate an ad-hoc conference, there MUST be a two (or more) calls active from UAI, destinations denoted here by A and B. The Call-ID for the existing calls are denoted UAI-A and UAI-B. From the starting conditions (left diagram) UAI sends an INVITE(also) to a bridge (middle diagram), who sends INVITE(replace)s to A and B, A and B terminate their call with UAI (right diagram). /----A /----A A ---\ | | | UAI BRIDGE UAI <-> BRIDGE UAI <-> BRIDGE | | | \----B \----B B ---/ Figure 3: Ad-hoc Conferencing To initiate an ad-hoc conference, the UAI MUST send an INVITE to a bridge server that contains at least two Dcs-Also headers. Each Dcs-Also header MUST contains the URL of one of the existing endpoints. This INVITE MUST contain an SDP message body, describing the media flow between the bridge and UAI. The first Dcs-Also header MUST contain the URL of URL-A, and MUST have attached a Call-ID header with value UAI-A, and a Dcs-Replaces DCS Group Category Informational - Expiration 12/31/00 14 SIP Proxy-to-Proxy Extensions June 2000 header giving the From or To header (whichever refers to UAI) for the existing call from UAI to A. An untrusted UAC MUST attach the collection of Dcs-State headers for the call from UAI to A. An originating UAC within the trust boundary of the service provider MUST include billing arrangements for the new call(s) to be made by the recipient, as a result of this message. The UAC MUST include Dcs-Billing-ID and Dcs-Billing-Info additional headers appended to the Dcs-Also header to provide this information. See section 10 for information about the billing headers. The originating UAC MUST check for an outstanding lawfully authorized surveillance order for the initiating subscriber. If found, the UAC MUST include a Dcs- LAES header in the INVITE. The Dcs-Laes header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, MAY include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content, and MUST include a random string for use as a security key between the Delivery Functions. Additional header parameters SHOULD NOT be attached to the Dcs-Also header. The second Dcs-Also header MUST contain similar information for the call from UAI to B. Call establishment procedes normally for the new call between UAI and bridge, including resource pre-conditions, ringing, etc. At the point when the normal call sends a 200-OK response, the bridge processes the Dcs-Also headers. The response to the INVITE is a non-200 value if the bridge failed to establish a call leg with UAI, or if the bridge was unwilling or unable to execute the request. A 200-OK response to the INVITE indicates a successful initiation of an ad-hoc conference. Receipt of BYEs for the existing calls from UAI to A and UAI to B indicates a successful completion of the ad- hoc conference setup. An error response to the INVITE indicates a failure to establish the bridge. A 200-OK response to the INVITE, with one or more (but not all) BYE messages, indicates a failure of one or more parties to be transferred to the bridge; those calls are still active from UAI. 8.3 Additional Procedures at a Trusted Initiator If both Dcs-Also and Dcs-Replaces headers are present, the UAI MUST verify that the initiating endpoint is authorized to perform this function. This typically means the initiator subscribed to either Call Transfer or Three-way-calling service. The UAI MUST include billing arrangements for the new call(s) to be made by the recipient, as a result of this message. The UAI MUST DCS Group Category Informational - Expiration 12/31/00 15 SIP Proxy-to-Proxy Extensions June 2000 include Dcs-Billing-ID and Dcs-Billing-Info additional headers appended to the Dcs-Also header to provide this information. See section 10 for information about the billing headers. The billing information for the first portion of the new call is the same as the existing call; the UAI MUST add a Dcs-Billing-Info header that provides billing information for the portion of the new call from the initiator to the specified destination, with the account number of the initiator. The UAI MUST check for an outstanding lawfully authorized surveillance order for the initiating subscriber. If found, the UAI MUST include a Dcs-LAES header in the INVITE. The Dcs-Laes header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, MAY include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content, and MUST include a random string for use as a security key between the Delivery Functions. 8.4 Procedures at an Untrusted Recipient When a UAI sends an INVITE to the UAR containing a Dcs-Also header, it implies that the UAI wishes the UAR, in addition to the normal processing of the INVITE request, to send an INVITE to those parties listed in the Dcs-Also headers. If the INVITE message contains a Dcs-Replaces: header, it implies that the UAI wishes the UAR, following the normal processing of the INVITE request and Dcs-Also headers (if present), to send a BYE message for the call leg identified by the Dcs-Replaces header value. The UAR, upon receiving an INVITE request, MUST first establish the new call, if the call-leg identification does not match an existing call at the UAR. This phase completes when the UAR would normally send the 200-OK to the INVITE request. Second, the UAR MUST check the Dcs-Also headers for any condition that would prevent the initiation of the sessions requested (such as syntax errors). The UAR MUST check the Dcs-Replaces headers to verify the existance of an active call-leg with a matching Call-ID (either a Call-ID attached to the Dcs-Replaces header, or the Call- ID of the INVITE message itself) and a participant (either the From or To) matching the SIP-URL in the Dcs-Replaces header. A UAR that is not capable of performing local bridging of media streams SHOULD reject an INVITE that would result in two or more call legs with the same Call-ID upon completion. If these checks are successful, UAR responds to the INVITE with a 200-OK final response. Third, the UAR MUST process any Dcs-Also headers present in the INVITE request. To do so, the UAR initiates an INVITE request with the Request-URI the value of the DCS-URL in the Dcs-Also header. Any additional headers attached to the Dcs-Also header MUST override the normal headers that would be included in this request. For DCS Group Category Informational - Expiration 12/31/00 16 SIP Proxy-to-Proxy Extensions June 2000 example, a Call-ID header attached to the Dcs-Also means the UAR MUST use that value, and only that value, for the Call-ID header in the initiated INVITE. Headers that would not normally be included in the INVITE request, but which appear attached to the Dcs-Also, MUST be included in the INVITE request. Where multiple Dcs-Also headers are present, each MUST generate a separate INVITE request. This phase completes on receipt of a 200-OK from all of the initiated INVITEs. Finally, the UAR MUST process any Dcs-Replaces headers present in the INVITE request. UAR sends a BYE request to the matching active call-leg identified earlier. This phase completes on receipt of a 200-OK from all the initiated BYEs. 8.5 Procedures at a Trusted Recipient Procedures at a trusted recipient are identical to those described in 8.4. 8.6 Procedures at Proxy Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint. The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint. 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. A proxy that is neither an originating proxy nor a terminating proxy has no function in manipulating existing calls. 8.6.1 Procedures at Originating Proxy If both Dcs-Also and Dcs-Replaces headers are present, the originating proxy MUST verify that the initiating endpoint has is authorized to perform this function. This typically means the initiator subscribed to either Call Transfer or Three-way-calling service. The url-parameter "private" MAY appear in the Dcs-Also headers. When identified by the hostname of the URL, the proxy MUST decode/decrypt the username, and replace the URL with a new DCS-URL. If the replacement DCS-URL contains a private-param, it MUST identify a different hostname than the current proxy. If the proxy is unable to decode/decrypt the username, it MUST reject the call attempt with an appropriate 4xx error code. DCS Group Category Informational - Expiration 12/31/00 17 SIP Proxy-to-Proxy Extensions June 2000 The originating proxy MUST include billing arrangements for the new call(s) to be made by the recipient, as a result of this message. The proxy MUST include Dcs-Billing-ID and Dcs-Billing-Info additional headers appended to the Dcs-Also header to provide this information. See section 10 for information about the billing headers. If a Dcs-State header is attached to the Dcs-Also, it MUST be used in calculating the billing information for the new calls. Otherwise, the Dcs-State header in the INVITE message MUST be used for calculating billing information. The Dcs-State header provides the billing information for the first portion of the new call; the originating proxy MUST add a Dcs-Billing-Info header that provides billing information for the portion of the new call from the initiator to the specified destination, with the account number of the initiator. The originating proxy MUST check for an outstanding lawfully authorized surveillance order for the initiating subscriber. If found, the proxy MUST include a Dcs-LAES header in the INVITE. The Dcs-Laes header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, MAY include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content, and MUST include a random string for use as a security key between the Delivery Functions. All Dcs-State headers MUST be removed from the Dcs-Also header. 8.6.2 Procedures at Terminating Proxy The terminating proxy MUST form a private-param for the recipient endpoint, and include this private-param in the Dcs-Also header in the INVITE message passed to the endpoint. This private-param SHOULD contain the following information: 1) the destination URL, 2) the value of Dcs-Billing-ID, 3) the sequence of Dcs-Billing-Info values, which indicate the complex charging arrangement for the new call, 4) an expiration time very shortly in the future, to limit the ability of the recipient to re-use this private-param for multiple calls, and 5) the electronic surveillance information, if present. Any remaining headers MUST be carried in the Dcs-Also header, using the SIP syntax for optional headers attached to a SIP-URL. 9. DCS-OSPS Some calls have special call processing requirements that may not be satisfied by normal user agent call processing. For example, when a user is engaged in a call and another call arrives, such a call might be rejected with a busy indication. However, some PSTN operator services require special call processing. In particular, the Busy line verification (BLV) and Emergency interrupt (EI) services initiated by an operator from an Operator Services Position System (OSPS) on the PSTN network have such a need. DCS Group Category Informational - Expiration 12/31/00 18 SIP Proxy-to-Proxy Extensions June 2000 In order to inform the SIP user agent that special treatment should be given to a call, we use a new OSPS header field, which may be set to a value indicating when a special type of call processing is requested. We define two values in this header, namely "BLV" for busy line verification and "EI" for emergency interrupt. 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. When such a request is received, the user agent may look at the Remote-Party-ID, and decide only to honor the request if "rpi-type" is "operator" and Remote-Party-ID was authenticated by the user agent's proxy. 9.1 Syntax Dcs-OSPS = "Dcs-OSPS" ":" OSPS-Tag OSPS-Tag = "BLV" | "EI" | token The OSPS-Tag value of "token" is defined for extensibility, and is reserved for future use. 9.2 Procedures at an Untrusted User Agent Client (UAC) The Dcs-OSPS header MUST NOT be sent in a request from an untrusted UAC. 9.3 Procedures at a Trusted User Agent Client (UAC) This header is typically only inserted by a Media-Gateway-Controller that is controlling a Media Gateway with special MF trunk connections to a PSTN OSPS system. This trunk group is usually referred to as a BLV-trunk group, and employs special signaling procedures that prevent inadvertant use. Calls originating at the PSTN OSPS system are sent over this trunk group, and result in an INVITE request with the OSPS header. This header MAY be sent in an INVITE request, and MUST NOT appear in any message other than an INVITE request. OSPS-Tag value "BLV" MUST NOT appear in any INVITE other than an initial INVITE request establishing a new session. OSPS-Tag value "EI" MUST NOT appear in any INVITE request other than a subsequent INVITE within a pre-existing session established with the OSPS-Tag value of "BLV". 9.4 Procedures at an Untrusted User Agent Server (UAS) If the UAS receives an INVITE request with an OSPS-Tag, call-leg identification that matches an existing call, and the existing call was not established with the OSPS-Tag, it MUST reject the request with a 409-Conflict error code. If the UAS receives an INVITE request with an OSPS-Tag value of "EI", with call-leg identification DCS Group Category Informational - Expiration 12/31/00 19 SIP Proxy-to-Proxy Extensions June 2000 that does not match an existing call, it MUST reject the request with a 409-Conflict error 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 error code. Otherwise, the UAS MUST verify the Dcs-Remote-Party-ID header contains a rpi- type token with value "operator." If the call is not from a service- provider-certified operator, it SHOULD be rejected with a 401- Unauthorized error 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 error code to an INVITE with a BLV OSPS-Tag. The UAS SHOULD NOT alert the user of the incomming call attempt if the BLV OSPS-Tag is present in the INVITE. If an INVITE with OSPS-Tag of "BLV" is accepted (meeting all QoS pre-conditions, etc.), the UAS MUST send an audio stream on this conection 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 active call. 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. 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 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. 9.5 Procedures at a Trusted User Agent Server (UAS) The procedures at a trusted UAS are identical to those described in 9.4. 9.6 Procedures at Proxy There is no special processing of this header at proxies. 10. DCS-BILLING-ID and DCS-BILLING-INFO In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys 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 DCS Group Category Informational - Expiration 12/31/00 20 SIP Proxy-to-Proxy Extensions June 2000 this document to discuss the details of these numerous and varying methods. A key motivating principle of the DCS architecture 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. Proxies have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path. Edge routers provide the policy enforcement mechanism and also capture and report 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 these reasons, it is appropriate to consider defining SIP header extensions to allow proxies to exchange information during call setup. It is the intent that the extensions would only appear on trusted network segments, should be inserted upon entering a trusted network region, and removed before leaving trusted network segments. Rules for inserting and removing headers exchanged only between proxies are for further study. Significant amounts of information is retrieved by an originating 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. Call-ID 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 DCS Group Category Informational - Expiration 12/31/00 21 SIP Proxy-to-Proxy Extensions June 2000 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 two SIP General Header Fields allows for the capture of billing information and billing identification for the duration of the call. Alternative techniques such as multi-part attachments will not coexist with encrypted messages. It is the intent that the billing extensions would only appear on trusted network segments, and MAY be inserted by a proxy in INVITE requests entering a trusted network segment, and removed before leaving trusted network segments.The Dcs-Billing-ID and Dcs-Billing- Info header extensions are used only on requests and responses between proxies. They are never sent to, nor sent by, an untrusted UAC/UAS. 10.1 Syntax The Dcs-Billing-ID and Dcs-Billing-Info headers are defined by the following BNF. Dcs-Billing-ID = "Dcs-Billing-ID" ":" Billing-Correlation-ID Dcs-Billing-Info = "Dcs-Billing-Info" ":" [hostport] "<" Acct-Data ">" Acct-Data = 1*unreserved | (1*unreserved "," Acct-Data) Acct-Entry = Acct-Charge-Number "/" Acct-Calling-Number "/" Acct-Called-Number ["/" Acct-Routing-Number "/" Acct-Loc-Routing-Number] Acct-Charge-Number = 1*unreserved Acct-Calling-Number = 1*unreserved Acct-Called-Number = 1*unreserved Acct-Routing-Number = 1*unreserved Acct-Loc-Routing-Number = 1*unreserved Billing-Correlation-ID = 1*unreserved The Dcs-billing-ID 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. Dcs-billing-id is chosen to be globally unique within the system for a window of several months. This header is only used between proxies. The Billing-Correlation-ID is specified in other PacketCable documents as a 16-byte binary structure, containing 4 bytes of NNTP timestamp, 8 bytes of MAC address of the network element that generated the ID, and 4 bytes of monotonically increasing sequence DCS Group Category Informational - Expiration 12/31/00 22 SIP Proxy-to-Proxy Extensions June 2000 number at that network element. This MUST be encoded in the Dcs- Billing-ID header as a 32-byte hex string. The Dcs-billing-info extension identifies a subscriber account number of the payer, and other information necessary for accurate billing of the service. The hostport, if present, specifies a record keeping server for event messages relating to this call. If not present, the default record keeping server for each network element is sent the event messages. Acct-data contains the information needed by the Gate Controller to give to the CMTS for generation of event message records. Acct- Charge-Number, Acct-Calling-Number, Acct-Called-Number, Acct- Routing-Number, and Acct-Location-Routing-Number are each defined as 20-byte E.164 formatted addresses. 10.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. 10.3 Procedures at a Trusted User Agent Client (UAC) The UAC MUST generate the Billing-Correlation-ID for the call, and insert the Dcs-Billing-ID header into the initial INVITE message sent to the terminating proxy. 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 INVITE generated by the UAC MUST contain the Dcs-Billing-Info headers from the 3xx- Redirect response. An originating proxy that includes a Dcs-Also header in an initial INVITE request MUST include a Dcs-Billing-Info header in the Dcs- Also's URL. This Dcs-Billing-Info header MUST include the accounting information of the initiator. A UAC that sends a mid-call INVITE request including a Dcs-Also header MUST include a Dcs-Billing-ID header and one or more Dcs- Billing-Info headers attached to the Dcs-Also. The Dcs-Billing-Info headers MUST include the complete set of Dcs-Billing-Info headers associated with the current call, and MUST include one additional Dcs-Billing-Info header (for the segment from the initiator) with accounting information of the initiator. 10.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. DCS Group Category Informational - Expiration 12/31/00 23 SIP Proxy-to-Proxy Extensions June 2000 10.5 Procedures at a Trusted User Agent Server (UAS) The UAS MAY include a Dcs-Billing-Info header in the first non-100 response to an initial INVITE message 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 Dcs-Billing-Info header MUST be determined by service provider policy provisioned in the UAS. The UAS MUST add Dcs-Billing-Info headers to a 3xx-redirect response to an initial INVITE. All Dcs-Billing-Info headers present in the initial INVITE MUST be copied to the 3xx-redirect response. In addition, the UAS MUST add an additional Dcs-Billing-Info header, for the segment from the destination to the forwarded-to destination, giving the accounting information for the call forwarder. 10.6 Procedures at Proxy Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint. The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint. For purposes of mid-call changes, such as call transfers, the proxy that receives the request from a non-trusted endpoint is considered the initiating proxy; the proxy that sends the request to a non- trusted endpoint is considered the recipient proxy. Procedures for the initiating proxy are included below with those for originating proxies, while procedures for the recipient proxy are included with those for terminating proxies. A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to a non-trusted endpoint, does not generate Dcs-Billing-ID nor Dcs-Billing-Info headers. A proxy that is neither an originating proxy nor a terminating proxy has no function in manipulating existing calls. 10.6.1 Procedures at Originating Proxy The originating proxy MUST generate the Billing-Correlation-ID for the call, and insert the Dcs-Billing-ID header into the initial INVITE message sent to the terminating proxy. If the Request-URI contains a private-param, and the decoded username contains billing information, the originating proxy MUST generate a Dcs-Billing-Info header with that decrypted information. Otherwise, the originating proxy MUST determine the accounting DCS Group Category Informational - Expiration 12/31/00 24 SIP Proxy-to-Proxy Extensions June 2000 information for the call originator, and insert a Dcs-Billing-Info header including that information. If the response to the initial INVITE is a 3xx-Redirect, received prior to a 18x-Ringing, 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-Ringing response, the INVITE generated by the proxy MUST contain the Dcs- Billing-Info headers from the 3xx-Redirect response. If the response to the initial INVITE is a 3xx-Redirect, received after a 18x-Ringing, 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 the sequence of Dcs-Billing-Info values, which indicate the complex 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-param for multiple calls. An originating proxy that includes a Dcs-Also header in an initial INVITE request MUST include a Dcs-Billing-Info header in the Dcs- Also's URL. This Dcs-Billing-Info header MUST include the accounting information of the initiator. An initiating proxy that sends a mid-call INVITE request including a Dcs-Also header MUST include a Dcs-Billing-ID header and one or more Dcs-Billing-Info headers in the Dcs-Also's URL. The Dcs-Billing- Info headers MUST include the complete set of Dcs-Billing-Info headers associated with the current call, and MUST include one additional Dcs-Billing-Info header (for the segment from the initiator) with accounting information of the initiator. 10.6.2 Procedures at Terminating Proxy The terminating proxy MUST NOT send the Dcs-Billing-ID nor the Dcs- Billing-Info headers to a non-trusted destination. The terminating proxy MAY include a Dcs-Billing-Info header in the first non-100 response to an initial INVITE message 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 Dcs-Billing-Info header MUST be determined by service provider policy provisioned in the terminating proxy. The terminating proxy MUST add Dcs-Billing-Info headers to a 3xx- redirect response to an initial INVITE. All Dcs-Billing-Info headers present in the initial INVITE MUST be copied to the 3xx- redirect response. In addition, the terminating proxy MUST add an additional Dcs-Billing-Info header, for the segment from the destination to the forwarded-to destination, giving the accounting information for the call forwarder. DCS Group Category Informational - Expiration 12/31/00 25 SIP Proxy-to-Proxy Extensions June 2000 A proxy receiving a mid-call INVITE request that includes a Dcs-Also header generates a private URL and places it in the Dcs-Also header sent to the endpoint. This private URL MUST contain the value of Dcs-Billing-ID, the sequence of Dcs-Billing-Info values, which indicate the complex 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-param for multiple calls. 11. DCS-LAES and DCS-REDIRECT The 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 retlated 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. The 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. 11.1 Syntax The format of the Dcs-Laes header is given by the following BNF. Dcs-LAES = "Dcs-LAES" ":" Laes-sig ["," Laes-content] ";" Laes-key Laes-sig = hostport Laes-content = hostport Laes-key = token Dcs-Redirect = "Dcs-Redirect" ":" Called-id Redirector Num-redir Called-id = "<" SIP-URL ">" Redirector = "<" SIP-URL ">" Num-redir = 1*DIGIT 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. 11.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. 11.3 Procedures at a Trusted User Agent Client (UAC) DCS Group Category Informational - Expiration 12/31/00 26 SIP Proxy-to-Proxy Extensions June 2000 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 or signals this information to the device performing the intercept (e.g. a Media Gateway). If the Dcs-LAES header is present in the 183-Session-Progress response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), the UAC MUST include this information in the Authorization for Quality of Service, or MUST signal this information to the device performing the intercept (e.g. a Media Gateway). If a 3xx-Redirect response is received to the initial INVITE request, and if a Dcs-LAES header is present in the 3xx response, the UAC MUST include that header unchanged in the reissued INVITE. The UAC MUST also include a Dcs-Redirect header containing the original dialed number, the new destination number, and the number of redirections that have occurred. A UAC that includes a Dcs-Also header in an INVITE request, when the originating subscriber has an outstanding lawfully authorized surveillance order, MUST include a Dcs-Laes header attached to the Dcs-Also. The Dcs-LAES header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, MUST 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 MUST include a random string for use as a security key between the Delivery Functions. 11.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. 11.5 Procedures at a Trusted User Agent Server (UAS) The UAS checks for an outstanding lawfully authorized surveillance order for the terminating subscriber. If present, the UAS includes this information in the authorization for Quality of Service. If the terminating equipment is unable to perform the required surveillance (e.g. if the destination is a voicemail server), the UAS MUST include a Dcs-LAES header in the 183-Session-Progress response requesting the originating proxy to perform the surveillance. The Dcs-LAES header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, MUST 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 MUST include a DCS Group Category Informational - Expiration 12/31/00 27 SIP Proxy-to-Proxy Extensions June 2000 random string for use as a security key between the Delivery Functions. If the response to the initial INVITE request is a 3xx-Redirect response, and there is an outstanding lawfully authorized surveillance order for the terminating subscriber, the UAS MUST include a Dcs-Laes header in the 3xx-Redirect response, with contents as described above. 11.6 Procedures at Proxy Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint. The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint. For purposes of mid-call changes, such as call transfers, the proxy that receives the request from a non-trusted endpoint is considered the initiating proxy; the proxy that sends the request to a non- trusted endpoint is considered the recipient proxy. Procedures for the initiating proxy are included below with those for originating proxies, while procedures for the recipient proxy are included with those for terminating proxies. A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to a non-trusted endpoint, does not generate Dcs-Laes nor Dcs-Redirect headers. A proxy that is neither an originating proxy nor a terminating proxy has no function in manipulating existing calls. 11.6.1 Procedures at Originating Proxy The originating proxy checks for an outstanding lawfully authorized surveillance order for the originating subscriber, and, if present, includes this information in the Authorization for Quality of Service or signals this information to the device performing the intercept (e.g. a Media Gateway). If the Dcs-LAES header is present in the 183-Session-Progress response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), the originating proxy MUST include this information in the Authorization for Quality of Service, or MUST signal this information to the device performing the intercept (e.g. a Media Gateway). If the Request-URI in an initial INVITE request contains the private-param user parameter, the originating proxy MUST decrypt the username information to find the real destination for the call, and DCS Group Category Informational - Expiration 12/31/00 28 SIP Proxy-to-Proxy Extensions June 2000 other special processing information. If electronic surveillance information is contained in the decrypted username, the originating proxy MUST generate a Dcs-LAES header with the surveillance information. If a 3xx-Redirect response is received to the initial INVITE request prior to a 18x-Ringing, and if a Dcs-LAES header is present in the 3xx response, the originating proxy MUST include that header unchanged in the reissued INVITE. The originating proxy MUST also include a Dcs-Redirect header containing the original dialed number, the new destination number, and the number of redirections that have occurred. If a 3xx-Redirect response is received to the initial INVITE request after a 18x-Ringing, 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 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 includes a Dcs-Also header in an initial INVITE request, when the originating subscriber has an outstanding lawfully authorized surveillance order, MUST include a Dcs-Laes header in the Dcs-Also's URL. The Dcs-LAES header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, MUST 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 MUST include a random string for use as a security key between the Delivery Functions. An initiating proxy that sends a mid-call INVITE request including a Dcs-Also header, when the initiating subscriber has an outstanding lawfully authorized surveillance order, MUST include a Dcs-Laes header in the Dcs-Also's URL. The Dcs-Laes header MUST include the information listed above. 11.6.2 Procedures at Terminating Proxy The terminating proxy checks for an outstanding lawfully authorized surveillance order for the terminating subscriber. If present, the terminating proxy includes this information in the authorization for Quality of Service. The terminating proxy MUST NOT send the Dcs-Laes and Dcs-Redirect headers to an untrusted endpoint. If the terminating equipment is unable to perform the required surveillance (e.g. if the destination is a voicemail server), the terminating proxy MUST include a Dcs-LAES header in the 183-Session- Progress response requesting the originating proxy to perform the DCS Group Category Informational - Expiration 12/31/00 29 SIP Proxy-to-Proxy Extensions June 2000 surveillance. The Dcs-LAES header MUST include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, MUST 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 MUST include a random string for use as a security key between the Delivery Functions. If the response to the initial INVITE request is a 3xx-Redirect response, and there is an outstanding lawfully authorized surveillance order for the terminating subscriber, the terminating proxy MUST include a Dcs-Laes header in the 3xx-Redirect response, with contents as described above. A proxy receiving a mid-call INVITE request that includes a Dcs-Also header with a Dcs-laes header attached MUST generate a private URL and place it in the Dcs-Also header sent to the endpoint. This private URL MUST contain the Dcs-Laes information from the attached header. 12. Security Considerations Billing information is often considered sensitive and private information to the customers. It is therefore necessary that the Proxies take precautions to protect this information from eavesdropping and interception. Use of IPSec between Proxies is recommended. 13. Notice Regarding Intellectual Property Rights AT&T may seek patent or other intellectual property protection for some or all of the technologies disclosed in the document. If any standards arising from this disclosure are or become protected by one or more patents assigned to AT&T, AT&T intends to disclose those patents and license them on reasonable and non-discriminatory terms. Future revisions of this draft may contain additional information regarding specific intellectual property protection sought or received. 3COM may seek patent or other intellectual property protection for some or all of the technologies disclosed in the document. If any standards arising from this disclosure are or become protected by one or more patents assigned to 3COM, 3COM intends to disclose those patents and license them on reasonable and non-discriminatory terms. Future revisions of this draft may contain additional information regarding specific intellectual property protection sought or received. 14. References DCS Group Category Informational - Expiration 12/31/00 30 SIP Proxy-to-Proxy Extensions June 2000 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 DCS Group, "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", draft-dcsgroup-sip-arch-02.txt, June 2000. 4 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 15. Acknowledgements The Distributed Call Signaling work in the PacketCable project is the work of a large number of people, representing many different companies. The authors would like to recognize and thank the following for their assistance: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable Communications. 16. Author's Addresses Bill Marshall AT&T Florham Park, NJ 07932 Email: wtm@research.att.com K. K. Ramakrishnan AT&T Florham Park, NJ 07932 Email: kkrama@research.att.com Ed Miller CableLabs Louisville, CO 80027 Email: E.Miller@Cablelabs.com Glenn Russell CableLabs DCS Group Category Informational - Expiration 12/31/00 31 SIP Proxy-to-Proxy Extensions June 2000 Louisville, CO 80027 Email: G.Russell@Cablelabs.com Burcak Beser 3Com Rolling Meadows, IL 60008 Email: Burcak_Beser@3com.com Mike Mannette 3Com Rolling Meadows, IL 60008 Email: Michael_Mannette@3com.com Kurt Steinbrenner 3Com Rolling Meadows, IL 60008 Email: Kurt_Steinbrenner@3com.com Dave Oran Cisco Acton, MA 01720 Email: oran@cisco.com Flemming Andreasen Cisco Edison, NJ Email: fandreas@cisco.com John Pickens Com21 San Jose, CA Email: jpickens@com21.com Poornima Lalwaney Nokia San Diego, CA 92121 Email: poornima.lalwaney@nokia.com Jon Fellows Motorola San Diego, CA 92121 Email: jfellows@gi.com Doc Evans Secure Cable Solutions Westminster, CO 30120 Email: drevans@securecable.com Keith Kelly NetSpeak Boca Raton, FL 33587 Email: keith@netspeak.com DCS Group Category Informational - Expiration 12/31/00 32 SIP Proxy-to-Proxy Extensions June 2000 DCS Group Category Informational - Expiration 12/31/00 33 SIP Proxy-to-Proxy Extensions June 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expiration Date This memo is filed as <draft-dcsgroup-sip-proxy- proxy-02.txt>, and expires December 31, 2000. DCS Group Category Informational - Expiration 12/31/00 34