doc: Add RFC documents

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]
+