RFC3603 日本語訳
3603 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call SignalingArchitecture. W. Marshall, Ed., F. Andreasen, Ed.. October 2003. (Format: TXT=67509 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Marshall, Ed.
Request for Comments: 3603 AT&T
Category: Informational F. Andreasen, Ed.
Cisco
October 2003
Network Working Group W. Marshall, Ed. Request for Comments: 3603 AT&T Category: Informational F. Andreasen, Ed. Cisco October 2003
Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture
Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture
Status of this Memo
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.
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 Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Abstract
In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.
In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.
Table of Contents
Table of Contents
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Trust Boundary. . . . . . . . . . . . . . . . . . . . . . . . 5 4. Conventions used in this document . . . . . . . . . . . . . . 6
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Trust Boundary. . . . . . . . . . . . . . . . . . . . . . . . 5 4. Conventions used in this document . . . . . . . . . . . . . . 6
Marshall & Andreasen Informational [Page 1] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
Marshall & Andreasen Informational [Page 1] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
5. P-DCS-TRACE-PARTY-ID. . . . . . . . . . . . . . . . . . . . . 6
5.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Procedures at an Untrusted User Agent Client (UAC). . . 7
5.3. Procedures at a Trusted User Agent Client (UAC) . . . . 7
5.4. Procedures at an Untrusted User Agent Server (UAS). . . 7
5.5. Procedures at a Trusted User Agent Server (UAS) . . . . 7
5.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 8
5.6.1. Procedures at Originating Proxy . . . . . . . . 8
5.6.2. Procedures at Terminating Proxy . . . . . . . . 8
6. P-DCS-OSPS. . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Procedures at an Untrusted User Agent Client (UAC). . . 9
6.3. Procedures at a Trusted User Agent Client (UAC) . . . . 10
6.4. Procedures at an Untrusted User Agent Server (UAS). . . 10
6.5. Procedures at a Trusted User Agent Server (UAS) . . . . 11
6.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 11
7. P-DCS-BILLING-INFO. . . . . . . . . . . . . . . . . . . . . . 11
7.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Procedures at an Untrusted User Agent Client (UAC). . . 14
7.3. Procedures at a Trusted User Agent Client (UAC) . . . . 14
7.4. Procedures at an Untrusted User Agent Server (UAS). . . 15
7.5. Procedures at a Trusted User Agent Server (UAS) . . . . 15
7.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 16
7.6.1. Procedures at Originating Proxy . . . . . . . . 16
7.6.2. Procedures at Terminating Proxy . . . . . . . . 17
7.6.3. Procedures at Tandem Proxy. . . . . . . . . . . 18
8. P-DCS-LAES and P-DCS-REDIRECT . . . . . . . . . . . . . . . . 18
8.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Procedures at an Untrusted User Agent Client (UAC). . . 20
8.3. Procedures at a Trusted User Agent Client (UAC) . . . . 20
8.4. Procedures at an Untrusted User Agent Server (UAS). . . 21
8.5. Procedures at a Trusted User Agent Server (UAS) . . . . 21
8.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 21
8.6.1. Procedures at Originating Proxy . . . . . . . . 22
8.6.2. Procedures at Terminating Proxy . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Intellectual Property Rights Notice . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References. . . . . . . . . . . . . . . . . . 25
12.2. Informative References. . . . . . . . . . . . . . . . . 26
13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 26
14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28
5. P-DCS-TRACE-PARTY-ID. . . . . . . . . . . . . . . . . . . . . 6 5.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Procedures at an Untrusted User Agent Client (UAC). . . 7 5.3. Procedures at a Trusted User Agent Client (UAC) . . . . 7 5.4. Procedures at an Untrusted User Agent Server (UAS). . . 7 5.5. Procedures at a Trusted User Agent Server (UAS) . . . . 7 5.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 8 5.6.1. Procedures at Originating Proxy . . . . . . . . 8 5.6.2. Procedures at Terminating Proxy . . . . . . . . 8 6. P-DCS-OSPS. . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Procedures at an Untrusted User Agent Client (UAC). . . 9 6.3. Procedures at a Trusted User Agent Client (UAC) . . . . 10 6.4. Procedures at an Untrusted User Agent Server (UAS). . . 10 6.5. Procedures at a Trusted User Agent Server (UAS) . . . . 11 6.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 11 7. P-DCS-BILLING-INFO. . . . . . . . . . . . . . . . . . . . . . 11 7.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Procedures at an Untrusted User Agent Client (UAC). . . 14 7.3. Procedures at a Trusted User Agent Client (UAC) . . . . 14 7.4. Procedures at an Untrusted User Agent Server (UAS). . . 15 7.5. Procedures at a Trusted User Agent Server (UAS) . . . . 15 7.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 16 7.6.1. Procedures at Originating Proxy . . . . . . . . 16 7.6.2. Procedures at Terminating Proxy . . . . . . . . 17 7.6.3. Procedures at Tandem Proxy. . . . . . . . . . . 18 8. P-DCS-LAES and P-DCS-REDIRECT . . . . . . . . . . . . . . . . 18 8.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 19 8.2. Procedures at an Untrusted User Agent Client (UAC). . . 20 8.3. Procedures at a Trusted User Agent Client (UAC) . . . . 20 8.4. Procedures at an Untrusted User Agent Server (UAS). . . 21 8.5. Procedures at a Trusted User Agent Server (UAS) . . . . 21 8.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 21 8.6.1. Procedures at Originating Proxy . . . . . . . . 22 8.6.2. Procedures at Terminating Proxy . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. Intellectual Property Rights Notice . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12.1. Normative References. . . . . . . . . . . . . . . . . . 25 12.2. Informative References. . . . . . . . . . . . . . . . . 26 13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 26 14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27 15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28
Marshall & Andreasen Informational [Page 2] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
Marshall & Andreasen Informational [Page 2] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
1. Applicability Statement
1. Applicability Statement
The SIP extensions described in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions are generally not applicable in the Internet as a whole. The use of these headers is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required, as in for example the architecture presented in [6]. Use outside such a domain could result in the leakage of potentially sensitive or private information. User consent to the privacy implications of the policies in [6] is strongly encouraged in those domains as well.
The SIP extensions described in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions are generally not applicable in the Internet as a whole. The use of these headers is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required, as in for example the architecture presented in [6]. Use outside such a domain could result in the leakage of potentially sensitive or private information. User consent to the privacy implications of the policies in [6] is strongly encouraged in those domains as well.
Although RFC 2119 language is used in this document, the scope of the normative language is only for the area of applicability of the document and, like the technology, it does not apply to the general Internet.
Although RFC 2119 language is used in this document, the scope of the normative language is only for the area of applicability of the document and, like the technology, it does not apply to the general Internet.
2. Introduction
2. Introduction
In order to deploy a SIP-based [2] residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys billing information and expectations about the parties involved in the call.
In order to deploy a SIP-based [2] residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys billing information and expectations about the parties involved in the call.
There are many billing models used in deriving revenue from telephony services today. Charging for telephony services is tightly coupled to the use of network resources. It is outside the scope of this document to discuss the details of these numerous and varying methods.
There are many billing models used in deriving revenue from telephony services today. Charging for telephony services is tightly coupled to the use of network resources. It is outside the scope of this document to discuss the details of these numerous and varying methods.
A key motivating principle of the DCS architecture described in [6] is the need for network service providers to be able to control and monitor network resources; revenue may be derived from the usage of these resources as well as from the delivery of enhanced services such as telephony. Furthermore, the DCS architecture recognizes the need for coordination between call signaling and resource management. This coordination ensures that users are authenticated and authorized before receiving access to network resources and billable enhanced services.
A key motivating principle of the DCS architecture described in [6] is the need for network service providers to be able to control and monitor network resources; revenue may be derived from the usage of these resources as well as from the delivery of enhanced services such as telephony. Furthermore, the DCS architecture recognizes the need for coordination between call signaling and resource management. This coordination ensures that users are authenticated and authorized before receiving access to network resources and billable enhanced services.
Marshall & Andreasen Informational [Page 3] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
Marshall & Andreasen Informational [Page 3] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
DCS Proxies, as defined in [6], have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path. Edge routers provide the network connectivity and resource policy enforcement mechanism and also capture and report network connectivity and resource usage information. Edge routers need to be given billing information that can be logged with Record Keeping or Billing servers. The DCS Proxy, as a central point of coordination between call signaling and resource management, can provide this information based on the authenticated identity of the calling and called parties. Since there is a trust relationship among DCS Proxies, they can be relied upon to exchange trusted billing information pertaining to the parties involved in a call. See [6] for a description of the trust boundary and trusted versus untrusted entities.
DCS Proxies, as defined in [6], have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path. Edge routers provide the network connectivity and resource policy enforcement mechanism and also capture and report network connectivity and resource usage information. Edge routers need to be given billing information that can be logged with Record Keeping or Billing servers. The DCS Proxy, as a central point of coordination between call signaling and resource management, can provide this information based on the authenticated identity of the calling and called parties. Since there is a trust relationship among DCS Proxies, they can be relied upon to exchange trusted billing information pertaining to the parties involved in a call. See [6] for a description of the trust boundary and trusted versus untrusted entities.
For these reasons, it is appropriate to consider defining SIP header extensions to allow DCS Proxies to exchange information during call setup. It is the intent that the extensions would only appear on trusted network segments, should be inserted upon entering a trusted network region, and removed before leaving trusted network segments.
For these reasons, it is appropriate to consider defining SIP header extensions to allow DCS Proxies to exchange information during call setup. It is the intent that the extensions would only appear on trusted network segments, should be inserted upon entering a trusted network region, and removed before leaving trusted network segments.
Significant amounts of information is retrieved by an originating DCS Proxy in its handling of a connection setup request from a user agent. Such information includes location information about the subscriber (essential for emergency services calls), billing information, and station information (e.g., coin operated phone). In addition, while translating the destination number, information such as the local-number-portability office code is obtained and will be needed by all other proxies handling this call.
Significant amounts of information is retrieved by an originating DCS Proxy in its handling of a connection setup request from a user agent. Such information includes location information about the subscriber (essential for emergency services calls), billing information, and station information (e.g., coin operated phone). In addition, while translating the destination number, information such as the local-number-portability office code is obtained and will be needed by all other proxies handling this call.
For Usage Accounting records, it is necessary to have an identifier that can be associated with all the event records produced for the call. The SIP Call-ID header field cannot be used as such an identifier since it is selected by the originating user agent, and may not be unique among all past calls as well as current calls. Further, since this identifier is to be used by the service provider, it should be chosen in a manner and in a format that meets the service provider's needs.
For Usage Accounting records, it is necessary to have an identifier that can be associated with all the event records produced for the call. The SIP Call-ID header field cannot be used as such an identifier since it is selected by the originating user agent, and may not be unique among all past calls as well as current calls. Further, since this identifier is to be used by the service provider, it should be chosen in a manner and in a format that meets the service provider's needs.
Billing information may not necessarily be unique for each user (consider the case of calls from an office all billed to the same account). Billing information may not necessarily be identical for all calls made by a single user (consider prepaid calls, credit card calls, collect calls, etc). It is therefore necessary to carry billing information separate from the calling and called party identification. Furthermore, some billing models call for split- charging where multiple entities are billed for portions of the call.
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.
Marshall & Andreasen Informational [Page 4] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
Marshall & Andreasen Informational [Page 4] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
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 addition of a SIP General Header Field allows for the capture of billing information and billing identification for the duration of the call.
It is the intent that the billing extensions would only appear on trusted network segments, and MAY be inserted by a DCS Proxy in INVITE and REFER requests and INVITE responses in a trusted network segment, and removed before leaving trusted network segments.
It is the intent that the billing extensions would only appear on trusted network segments, and MAY be inserted by a DCS Proxy in INVITE and REFER requests and INVITE responses in a trusted network segment, and removed before leaving trusted network segments.
In addition to support for billing, current residential telephone service includes the need for customer originated trace (of harassing or obscene calls), for operator services such as busy line verification and emergency interrupt (initiated by an operator from an Operator Services Position System (OSPS)), for emergency services such as 9-1-1 calls to a Public Service Access Point (PSAP) and the subsequent call handling, and support for Electronic Surveillance and Law Enforcement access as required by applicable legislation and court orders. In all of these cases, additional information about the call and about the subscribers involved in the call needs to be exchanged between the proxies.
In addition to support for billing, current residential telephone service includes the need for customer originated trace (of harassing or obscene calls), for operator services such as busy line verification and emergency interrupt (initiated by an operator from an Operator Services Position System (OSPS)), for emergency services such as 9-1-1 calls to a Public Service Access Point (PSAP) and the subsequent call handling, and support for Electronic Surveillance and Law Enforcement access as required by applicable legislation and court orders. In all of these cases, additional information about the call and about the subscribers involved in the call needs to be exchanged between the proxies.
3. Trust Boundary
3. Trust Boundary
The DCS architecture [6] defines a trust boundary around the various systems and servers that are owned, operated by, and/or controlled by the service provider. These trusted systems include the proxies and various servers such as bridge servers, voicemail servers, announcement servers, etc. Outside of the trust boundary lie the customer premises equipment, and various application and media servers operated by third-party service providers.
The DCS architecture [6] defines a trust boundary around the various systems and servers that are owned, operated by, and/or controlled by the service provider. These trusted systems include the proxies and various servers such as bridge servers, voicemail servers, announcement servers, etc. Outside of the trust boundary lie the customer premises equipment, and various application and media servers operated by third-party service providers.
Certain subscriber-specific information, such as billing and accounting information, stays within the trust boundary. Other subscriber-specific information, such as endpoint identity, may be presented to untrusted endpoints or may be withheld based on subscriber profiles.
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 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.
The following sections giving procedures for User Agents therefore are subdivided into trusted user agents and untrusted user agents.
Marshall & Andreasen Informational [Page 5] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
Marshall & Andreasen Informational [Page 5] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
4. Conventions used in this document
4. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
The term "private-URL" used in this document refers to a SIP URI that is generated by a proxy, contains a "hostport" that identifies the proxy, and contains a "userinfo" string that is generated by the proxy. The "userinfo" typically contains (or points to) information that is not to be disclosed outside the trusted domain of the proxies, such as billing account numbers, electronic surveillance indication, electronic surveillance parameters, and call redirection information. Consequently, the information is either stored locally by the proxy, or encrypted with a private key known only to the proxy and encoded in a character string in the "userinfo" portion of the URL. A checksum is included in the "userinfo" data to detect tampering. The mechanism by which a proxy recognizes a "userinfo" as a private-URL and decodes and recovers the original information is local to the proxy and is not subject to standardization. Some possible implementations include an initial magic cookie (e.g., z9hG4Bk followed by the pointer/information), or use of a reserved "user" name (e.g., "private") with the optional "password" containing the pointer/information.
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
5. P-DCS-TRACE-PARTY-ID
In the telephone network, calling identity information is used to support regulatory requirements such as the Customer Originated Trace service, which provide the called party with the ability to report obscene or harassing phone calls to law enforcement. This service is provided independently of caller-id, and works even if the caller requested anonymity. The calling party is here identified as the station originating the call. In order for this service to be dependable, the called party must be able to trust that the calling identity information being presented is valid. One way to achieve this is described in [10].
In the telephone network, calling identity information is used to support regulatory requirements such as the Customer Originated Trace service, which provide the called party with the ability to report obscene or harassing phone calls to law enforcement. This service is provided independently of caller-id, and works even if the caller requested anonymity. The calling party is here identified as the station originating the call. In order for this service to be dependable, the called party must be able to trust that the calling identity information being presented is valid. One way to achieve this is described in [10].
To initiate a customer-originated-trace from an untrusted UAC, an additional header is defined for the INVITE request. This header is called P-DCS-Trace-Party-ID, and does not appear in any other request or response. The entity addressed by the Request-URI performs the service-provider-specific functions of recording and reporting the caller identity in the P-DCS-Trace-Party-ID for law enforcement action. It then forwards the call to either an announcement server or to the service-provider's business office to collect further information about the complaint. A trusted UAC does not use this header, as it initiates this action locally.
To initiate a customer-originated-trace from an untrusted UAC, an additional header is defined for the INVITE request. This header is called P-DCS-Trace-Party-ID, and does not appear in any other request or response. The entity addressed by the Request-URI performs the service-provider-specific functions of recording and reporting the caller identity in the P-DCS-Trace-Party-ID for law enforcement action. It then forwards the call to either an announcement server or to the service-provider's business office to collect further information about the complaint. A trusted UAC does not use this header, as it initiates this action locally.
Marshall & Andreasen Informational [Page 6] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
Marshall & Andreasen Informational [Page 6] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
5.1. Syntax
5.1. Syntax
The ABNF description of this header is (some terms used in this ABNF are defined in [2]):
The ABNF description of this header is (some terms used in this ABNF are defined in [2]):
P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON
name-addr
P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr
This document adds the following entry to Table 2 of [2]:
This document adds the following entry to Table 2 of [2]:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-Trace-Party-ID R dr - - - o - -
Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-DCS-Trace-Party-ID R dr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
SUB NOT REF INF UPD PRA --- --- --- --- --- --- - - - - - -
The addr-spec contained in name-addr contains a URL that identifies the remote endpoint. Addr-spec typically contains a tel: URL or SIP URI giving the identity of the remote endpoint, as provided in the signaling messages that established the session to be traced.
The addr-spec contained in name-addr contains a URL that identifies the remote endpoint. Addr-spec typically contains a tel: URL or SIP URI giving the identity of the remote endpoint, as provided in the signaling messages that established the session to be traced.
5.2. Procedures at an Untrusted User Agent Client (UAC)
5.2. Procedures at an Untrusted User Agent Client (UAC)
The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial INVITE message for a customer-originated-trace request. The UAC MUST use a SIP URI in the Request-URI with userinfo set to "call-trace" and hostport identifying the call tracing entity for the untrusted UA.
The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial INVITE message for a customer-originated-trace request. The UAC MUST use a SIP URI in the Request-URI with userinfo set to "call-trace" and hostport identifying the call tracing entity for the untrusted UA.
5.3. Procedures at a Trusted User Agent Client (UAC)
5.3. Procedures at a Trusted User Agent Client (UAC)
A trusted UAC performs the customer-originated-trace in a manner similar to the trusted UAS, described below. A trusted UAC MUST NOT include this header in any request.
A trusted UAC performs the customer-originated-trace in a manner similar to the trusted UAS, described below. A trusted UAC MUST NOT include this header in any request.
5.4. Procedures at an Untrusted User Agent Server (UAS)
5.4. Procedures at an Untrusted User Agent Server (UAS)
This header MUST NOT appear in any response sent by a UAS.
This header MUST NOT appear in any response sent by a UAS.
5.5. Procedures at a Trusted User Agent Server (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
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
Marshall & Andreasen Informational [Page 7] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
Marshall & Andreasen Informational [Page 7] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
the caller identity for law enforcement action. The UAS then MUST redirect the call, via a 3xx response, to either an announcement server or to the service-provider's business office to collect further information about the complaint.
the caller identity for law enforcement action. The UAS then MUST redirect the call, via a 3xx response, to either an announcement server or to the service-provider's business office to collect further information about the complaint.
This header MUST NOT appear in any response sent by a UAS.
This header MUST NOT appear in any response sent by a UAS.
5.6. Procedures at Proxy
5.6. Procedures at Proxy
Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.
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.
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.
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
5.6.1. Procedures at Originating Proxy
If the P-DCS-Trace-Party-ID header is present in the initial INVITE request from the UAC, and the Request-URI of the INVITE has userinfo other than "call-trace" and hostport set to other than a potentially provisioned call tracing entity, then the Proxy MAY reject the request, or MAY remove the P-DCS-Trace-Party-ID header from the request. If the header is present in a valid request, and contains a private-URL that identifies the Proxy in the hostport, then the Originating Proxy SHOULD replace the private-URL with its original contents (i.e., the verified identity of the caller of the session that is being traced).
If the P-DCS-Trace-Party-ID header is present in the initial INVITE request from the UAC, and the Request-URI of the INVITE has userinfo other than "call-trace" and hostport set to other than a potentially provisioned call tracing entity, then the Proxy MAY reject the request, or MAY remove the P-DCS-Trace-Party-ID header from the request. If the header is present in a valid request, and contains a private-URL that identifies the Proxy in the hostport, then the Originating Proxy SHOULD replace the private-URL with its original contents (i.e., the verified identity of the caller of the session that is being traced).
5.6.2. Procedures at Terminating Proxy
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.
This header MUST NOT appear in any request or response sent by a terminating proxy to an untrusted endpoint.
6. P-DCS-OSPS
6. P-DCS-OSPS
Some calls have special call processing requirements that may not be satisfied by normal user agent call processing. For example, when a user is engaged in a call and another call arrives, such a call might be rejected with a busy indication. However, some PSTN operator services require special call processing. In particular, the Busy Line Verification (BLV) and Emergency Interrupt (EI) services initiated by an operator from an Operator Services Position System
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
Marshall & Andreasen Informational [Page 8] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
Marshall & Andreasen Informational [Page 8] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
(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).
(OSPS) on the PSTN network have such a need. Similarly, emergency calls to a 9-1-1 Public Service Access Point (PSAP) may result in trunk signaling causing operator ringback using a howling tone or sustained ring on the originating line (country-specific variations may exist).
In order to inform the SIP user agent that special treatment should be given to a call, we use a new P-DCS-OSPS header field, which may be set to a value indicating when a special type of call processing is requested. We define three values in this header, namely "BLV" for busy line verification, "EI" for emergency interrupt, and "RING" for operator ringback (e.g., howling/sustained tone ring in the US).
In order to inform the SIP user agent that special treatment should be given to a call, we use a new P-DCS-OSPS header field, which may be set to a value indicating when a special type of call processing is requested. We define three values in this header, namely "BLV" for busy line verification, "EI" for emergency interrupt, and "RING" for operator ringback (e.g., howling/sustained tone ring in the US).
If the user agent decides to honor such a request, the response of the user agent to an INVITE with either "BLV" or "EI" will not be a busy indication. Since "EI" and "RING" only occur on established dialogs, they may also appear in UPDATE requests.
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
6.1. Syntax
The ABNF description of the P-DCS-OSPS header is as follows (some terms used in this ABNF are defined in [2]):
The ABNF description of the P-DCS-OSPS header is as follows (some terms used in this ABNF are defined in [2]):
P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag
OSPS-Tag = "BLV" / "EI" / "RING" / token
P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag OSPS-Tag = "BLV" / "EI" / "RING" / token
This document adds the following entry to Table 2 of [2]:
This document adds the following entry to Table 2 of [2]:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-OSPS R dr - - - o - -
Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-DCS-OSPS R dr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - o -
SUB NOT REF INF UPD PRA --- --- --- --- --- --- - - - - o -
The OSPS-Tag value of "token" is defined for extensibility, and is reserved for future use.
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)
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.
The P-DCS-OSPS header MUST NOT be sent in a request from an untrusted UAC.
Marshall & Andreasen Informational [Page 9] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
Marshall & Andreasen Informational [Page 9] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
6.3. Procedures at a Trusted User Agent Client (UAC)
6.3. Procedures at a Trusted User Agent Client (UAC)
This header is typically only inserted by a Media Gateway Controller [6] that is controlling a Media Gateway with special trunks to a PSTN OSPS system or PSAP. This trunk group is usually referred to as a BLV-trunk group and employs special signaling procedures that prevent inadvertent use. Calls originating at the PSTN OSPS system are sent over this trunk group, and result in an INVITE request with the P- DCS-OSPS header.
This header is typically only inserted by a Media Gateway Controller [6] that is controlling a Media Gateway with special trunks to a PSTN OSPS system or PSAP. This trunk group is usually referred to as a BLV-trunk group and employs special signaling procedures that prevent inadvertent use. Calls originating at the PSTN OSPS system are sent over this trunk group, and result in an INVITE request with the P- DCS-OSPS header.
This header MAY be sent in an INVITE request, and MUST NOT appear in any message other than those listed below.
This header MAY be sent in an INVITE request, and MUST NOT appear in any message other than those listed below.
OSPS-Tag value "BLV" MUST NOT appear in any request or response other than an initial INVITE request establishing a new dialog.
OSPS-Tag value "BLV" MUST NOT appear in any request or response other than an initial INVITE request establishing a new dialog.
OSPS-Tag value "EI" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a pre-existing dialog established with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a pre-existing dialog established with the OSPS-Tag value of "BLV".
OSPS-Tag value "EI" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a pre-existing dialog established with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a pre-existing dialog established with the OSPS-Tag value of "BLV".
OSPS-Tag value "RING" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a pre-existing dialog established by a UAC to an operator or PSAP, or (2) an UPDATE request within a pre-existing dialog established by a UAC to an operator or PSAP.
OSPS-タグ値の「リング」はどんな要求や(1) UACによってオペレータかPSAPに確立された先在の対話の中のその後の招待、または(2) UACによってオペレータに確立された先在の対話かPSAPの中の更新要求以外の応答にも現れてはいけません。
6.4. Procedures at an Untrusted User Agent Server (UAS)
6.4. 信頼されていないユーザエージェントサーバにおける手順(UAS)
If the UAS receives an INVITE request with an OSPS-Tag of "BLV", dialog identification that matches an existing dialog, and the existing call was not established with the OSPS-Tag, it MUST reject the request with a 403-Forbidden error code.
UASが受信するなら、"BLV"のOSPS-タグとのINVITE要求、既存の対話に合っている対話識別、および既存の呼び出しはOSPS-タグで確立されないで、それは403で禁制のエラーコードで要求を拒絶しなければなりません。
If the UAS receives an INVITE/UPDATE request with an OSPS-Tag value of "EI" or "RING", with dialog identification that does not match an existing dialog, it MUST reject the request with a 403-Forbidden response code.
UASが「穎娃」か「リング」のOSPS-タグ値でINVITE/UPDATE要求を受け取るなら、既存の対話に合っていない対話識別で、それは403で禁制の応答コードによる要求を拒絶しなければなりません。
If the UAS receives an INVITE that contains an OSPS-Tag value of "BLV" and is not willing to cooperate in offering this service, it MUST reject the request with a 403-Forbidden response code.
UASが"BLV"のOSPS-タグ値を含むINVITEを受けて、このサービスを提供するのに協力することを望んでいないなら、それは403で禁制の応答コードで要求を拒絶しなければなりません。
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.
UAS SHOULD NOTは忙しい状態のためBLV OSPS-タグでINVITEを拒絶します。 UAS MUST NOTは3xx再直接の応答コードでBLV OSPS-タグがあるINVITEに応じます。 BLV OSPS-タグがINVITEに存在しているなら、UAS SHOULD NOTはかかってきた電話試みのユーザを警告します。
Marshall & Andreasen Informational [Page 10] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[10ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
If an INVITE with OSPS-Tag of "BLV" is accepted (e.g., meeting all QoS pre-conditions, etc.), the UAS MUST send an audio stream on this connection to the address and port given in the SDP of the INVITE. The UAS MAY perform a mixing operation between the two ends of an existing active call and send the resulting media stream to the address and port indicated. Alternatively, the UAS MAY send a copy of the local voice stream, and (if no activity on the local voice stream) send a copy of the received voice stream of an existing call. If the state of the UAS is idle, the UAS SHOULD send a stream of silence packets to OSPS. If the state of the UAS is ringing or ringback, the UAS SHOULD send a ringback stream to OSPS.
"BLV"のOSPS-タグがあるINVITEを受け入れるなら(例えば、すべてのQoSプレ状態などを満たします)、UASはこの接続におけるオーディオストリームを招待のSDPのアドレスとポート当然のことに送らなければなりません。 UAS MAYは既存の活発な呼び出しの2つの終わりの間で混合操作を実行して、メディアがアドレスに流して、ポートが示した結果になることを送ります。 あるいはまた、UAS MAYは地方の声の流れのコピーを送って、既存の呼び出しの容認された声の流れのコピーを送ります(地方の声の流れの活動でないなら)。 UASの州が活動していないなら、UAS SHOULDは沈黙パケットの流れをOSPSに送ります。UASの州が鳴るかringbackであるなら、UAS SHOULDはringbackの流れを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.
「穎娃」のOSPS-タグがあるINVITE/UPDATEを受け入れるなら、UASはUACと地元のユーザとのコミュニケーションを可能にしなければなりません。 UAS MAYはどんな既存の呼び出しも保留にするか、または臨時の会議を開始します。
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.
「リング」のOSPS-タグがあるINVITE/UPDATEを受け入れるなら、ローカルの手順によると、UASはオペレータringbackを実行しなければなりません、例えば、3秒の遠吠えのトーンか持続しているリングを発生させてください、ユーザ設備の状態によって。
6.5. Procedures at a Trusted User Agent Server (UAS)
6.5. 信じられたユーザエージェントサーバにおける手順(UAS)
The procedures at a trusted UAS MUST be identical to those described in 6.4.
aにおける手順は、UAS MUSTが6.4で説明されたものと同じであると信じました。
6.6. Procedures at Proxy
6.6. プロキシにおける手順
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.
DCS構造では、OSPSは信じられたUACであると考えられます。 プロキシが要求に信頼できないソースからP-DCS-OSPSヘッダーを受け取るなら、それは、403で禁制の応答でヘッダーを取り除かなければならないか、または要求を拒絶しなければなりません。
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.
転送サービスを実行するプロキシは3xx応答でINVITE要求に応じてはいけません、要求がP-DCS-OSPSヘッダーを含んだなら。
7. P-DCS-BILLING-INFO
7. P-DCS支払いインフォメーション
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
プロキシは、呼び出しシグナリング経路に沿って加入者情報に近づく手段を持って、政策決定としてポイントと信じられた仲介者を務めます。 縁のルータはネットワーク接続とリソースを提供します。
Marshall & Andreasen Informational [Page 11] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[11ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
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.
方針実施メカニズム、捕獲、およびレポートも接続とリソース用法情報をネットワークでつなぎます。 縁のルータは、Record KeepingかBillingと共に登録できる情報にサーバを請求しながら与えられている必要があります。 呼び出しシグナリングと資源管理の間のコーディネートの主要なポイントとして、プロキシは呼ぶことの認証されたアイデンティティに基づいていて、パーティーと呼ばれるこの情報を提供できます。 プロキシの中に信用関係があるので、彼らでは、呼び出しにかかわるパーティーに情報関係を請求しながら信じられた交換を当てにすることができます。
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.
Usage Accounting記録に、呼び出しのために作り出されるすべてのイベント記録に関連づけることができる識別子を持つのが必要です。 SIP Call-IDヘッダーフィールドは、それが由来しているユーザエージェントによって選択されるのでそのような識別子として使用できないで、現在の呼び出しと同様に過去のすべての呼び出しの中でユニークでないかもしれません。 この識別子がサービスプロバイダーによって使用されることであるので、さらに、それは方法とサービスプロバイダーの需要を満たす形式で選ばれるべきです。
Billing information may not necessarily be unique for each user (consider the case of calls from an office all billed to the same account). Billing information may not necessarily be identical for all calls made by a single user (consider prepaid calls, credit card calls, collect calls, etc). It is therefore necessary to carry billing information separate from the calling and called party identification. Furthermore, some billing models call for split- charging where multiple entities are billed for portions of the call.
各ユーザには、支払い情報は必ずユニークであるかもしれないというわけではありません(オフィスからの呼び出しのケースが同じアカウントにすべて請求されていると考えてください)。 シングルユーザー(前払いの呼び出し、クレジットカード通話、コレクトコールなどを考える)によってかけられたすべての電話には、支払い情報は必ず同じであるかもしれないというわけではありません。 したがって、呼ぶのから別々の支払い情報と被呼者識別を運ぶのが必要です。 その上、モデルが求める何らかの支払いが、複数の実体が呼び出しの部分に請求されるところで充電しながら、分かれました。
The addition of a SIP General Header Field allows for the capture of billing information and billing identification for the duration of the call.
SIP Header Field司令官の添加は呼び出しの持続時間のための支払い情報と支払い識別の捕獲を考慮します。
It is the intent that the billing extensions would only appear on trusted network segments, and MAY be inserted by a proxy or trusted UA in INVITE requests in a trusted network segment, and removed before leaving trusted network segments. The P-DCS-Billing-Info header extension is used only on requests and responses between proxies and trusted User Agents. It is never sent to, nor sent by, an untrusted UA.
信じられたネットワークセグメントを残す前にINVITEのUAが信じられたネットワークセグメントで要求して、取り外したのは、支払い拡大が信じられたネットワークセグメントで見えるだけである意図であり、プロキシによって挿入されるか、または信じられるかもしれません。 P-DCS支払いインフォメーションヘッダー拡張子は単にプロキシと信じられたUserエージェントの間の要求と応答のときに使用されます。 それは決してそうではありません。信頼されていないUAで発信して、発信しました。
Marshall & Andreasen Informational [Page 12] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[12ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
7.1. Syntax
7.1. 構文
The DCS-Billing-Info header is defined by the following ABNF (some terms used in this ABNF are defined in [2]):
DCS支払いインフォメーションヘッダーは以下のABNFによって定義されます。(このABNFで使用されるいくつかの用語が[2])で定義されます:
P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON
Billing-Correlation-ID "/" FEID
*(SEMI Billing-Info-param)
Billing-Correlation-ID = 1*48(HEXDIG)
FEID = 1*16(HEXDIG) "@" host
Billing-Info-param = RKS-Group-ID-param / Charge-param /
Calling-param / Called-param /
Routing-param / Loc-Routing-param /
generic-param
RKS-Group-ID-param = "rksgroup" EQUAL RKS-Group-ID
RKS-Group-ID = token
Charge-param = "charge" EQUAL Acct-Charge-URI
Acct-Charge-URI = LDQUOT addr-spec RDQUOT
Calling-param = "calling" EQUAL Acct-Calling-URI
Acct-Calling-URI = LDQUOT addr-spec RDQUOT
Called-param = "called" EQUAL Acct-Called-URI
Acct-Called-URI = LDQUOT addr-spec RDQUOT
Routing-param = "routing" EQUAL Acct-Routing-URI
Acct-Routing-URI = LDQUOT addr-spec RDQUOT
Loc-Routing-param = "locroute" EQUAL Acct-Loc-Routing-URI
Acct-Loc-Routing-URI = LDQUOT addr-spec RDQUOT
」 一般的なparam RKSグループIDルート設定param / Locルート設定呼ばれた呼ぶ-param/param/param/param=FEID*(セミトレーラ支払いインフォメーションparam)支払いCorrelation ID=1*48(HEXDIG)FEID=1*16(HEXDIG)"@"料金ホスト支払いインフォメーションparam=RKSグループID param/param/"rksgroup"等しいRKSグループ「P-DCS支払いインフォメーション=「P-DCS支払いインフォメーション」HCOLON Billing Correlation ID」/ID RKSグループIDは「料金」象徴料金-param=同輩Acct Chargeユリと等しいです; LDQUOT addr-仕様RDQUOTルート設定-paramユリと呼ばれるURIと呼ばれるEQUAL Acct Acctと「呼ばれた」LDQUOT addr-仕様ユリに電話をするEQUAL Acct呼ぶURI Acct=RDQUOT Called-param===がLDQUOT addr-仕様"locroute"EQUAL Acct-Locルート設定URI Acct-Loc Routing LDQUOT addr-仕様RDQUOT Locルート設定「ルーティング」EQUAL Acctルート設定URI Acct Routingユリ=param=ユリ=RDQUOTを「呼ぶ」であるのとLDQUOT addr-仕様Acct Chargeユリ=RDQUOT Calling-paramは等しいです。
This document adds the following entry to Table 2 of [2]:
このドキュメントは[2]のTable2に以下のエントリーを加えます:
Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-DCS-Billing-Info admr - - - o - -
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG------------ ----- ----- --- --- --- --- --- --- P-DCS支払いインフォメーションadmr--、--、--o--、-
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
潜水艦審判INF UPD PRAでない--- --- --- --- --- --- - - - - - -
The P-DCS-Billing-Info extension contains an identifier that can be used by an event recorder to associate multiple usage records, possibly from different sources, with a billable account. It further contains the subscriber account information, and other information necessary for accurate billing of the service. This header is only used between proxies and trusted User Agents.
P-DCS支払いインフォメーション拡張子はイベントレコーダーによって使用される、複数の用法記録を関連づけることができる識別子を含んでいます、ことによるとさまざまな原因から、支払い請求可能なアカウントで。 それはさらに正確なサービスの支払いに必要な加入者会計情報、および他の情報を含んでいます。 このヘッダーはプロキシと信じられたUserエージェントの間で使用されるだけです。
The Billing-Correlation-ID is specified in [9] as a 24-byte binary structure, containing 4 bytes of NTP timestamp, 8 bytes of the unique identifier of the network element that generated the ID, 8 bytes
Billing Correlation IDは24バイトの2進の構造として[9]で指定されます、4バイトのNTPタイムスタンプを含んでいて、IDを発生させたネットワーク要素のユニークな識別子の8バイト、8バイト
Marshall & Andreasen Informational [Page 13] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[13ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
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.
そのネットワーク要素で時間帯、および4バイトの単調に増加する一連番号を与えます。 この識別子は、数カ月の窓のシステムの中でグローバルに特有になるように選ばれています。 最大48のキャラクタの16進ストリングとしてP-DCS支払いインフォメーションヘッダーでこれをコード化しなければなりません。 主なゼロは抑圧されるかもしれません。
The Financial-Entity-ID (FEID) is specified in [9] as an 8-byte structure, containing the financial identifier for that domain, followed by a domain name. FEID can be associated with a type of service and could be assigned to multiple domains by the same provider. A domain could contain multiple assigned FEIDs. This 8- byte structure MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 16 characters. Trailing zeroes MAY be suppressed. "Host" contains the domain name.
そのドメインのための財政的な識別子を含んでいて、8バイトの構造がドメイン名で従ったので、Financial Entity ID(FEID)は[9]で指定されます。 FEIDを一種のサービスに関連づけることができて、同じプロバイダーは複数のドメインに割り当てることができました。 ドメインは複数の割り当てられたFEIDsを含むかもしれません。 最大16のキャラクタの16進ストリングとしてP-DCS支払いインフォメーションヘッダーでこの8バイト構造をコード化しなければなりません。 末尾のゼロは抑圧されるかもしれません。 「ホスト」はドメイン名を含んでいます。
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.
RKSグループIDはイベントメッセージのためのこの呼び出しに関連する記録的なキープサーバ(または、協力サーバのグループ)を指定します。 それは、複数のイベントメッセージ小川を同じRecord Keeping Serverに送るとき、手順のある最適化を制御するのに使用されます。
Additional parameters contain the information needed for generation of event message records. Acct-Charge-URI, Acct-Calling-URI, Acct- Called-URI, Acct-Routing-URI, and Acct-Location-Routing-URI are each defined as URLs; they should all contain tel: URLs with E.164 formatted addresses. These fields are further defined in [9] under the element identifiers "Charge_Number" (element ID 16), "Calling_Party_Number" (element ID 4), "Called_Party_Number" (element ID 5), "Routing Number" (element ID 25), and "Location_Routing_Number" (element ID 22).
追加パラメタはイベントメッセージ記録の世代に必要である情報を含んでいます。 Acct料金URI、URIと呼ぶAcct、Acctの呼ばれたURI、Acctルート設定URI、およびAcct位置のルート設定URIはそれぞれURLと定義されます。 それらは皆、tel:を含むべきです。 E.164があるURLはアドレスをフォーマットしました。 これらの分野は要素識別子「料金_数」(要素ID16)、「_をパーティ_数と呼ぶ」(要素ID4)、「呼ばれた_パーティ_番号」(要素ID5)、「ルート設定番号」(要素ID25)、および「位置の_ルート設定_番号」(要素ID22)の下でさらに[9]で定義されます。
7.2. Procedures at an Untrusted User Agent Client (UAC)
7.2. 信頼されていないユーザエージェントのクライアントにおける手順(UAC)
This header is never sent to an untrusted UAC, and is never sent by an untrusted UAC.
このヘッダーは、信頼されていないUACに決して送られないで、また信頼されていないUACによって決して送られません。
7.3. Procedures at a Trusted User Agent Client (UAC)
7.3. 信じられたユーザエージェントのクライアントにおける手順(UAC)
The UAC MUST generate the Billing-Correlation-ID for the call, and insert it into the P-DCS-Billing-Info header in the initial INVITE message sent to the terminating proxy, along with the charging information for the call. The UAC MUST include its FEID, and the RKS-Group-ID for the Record-Keeping-Server being used by the UAC. If the UAC performed a Local Number Portability (LNP) query, it MUST include the Routing Number and Location Routing Number returned by the query.
UAC MUSTは呼び出しのためにBilling Correlation IDを発生させて、終わっているプロキシに送られた初期のINVITEメッセージのP-DCS支払いインフォメーションヘッダーにそれを挿入します、呼び出しのための充電情報と共に。 UAC MUSTはFEID、およびUACによって使用されるRecordキープサーバのためのRKSグループIDを含んでいます。 UACがLocal Number Portability(LNP)質問を実行したなら、それは質問で返されたルート設定NumberとLocationルート設定Numberを含まなければなりません。
Marshall & Andreasen Informational [Page 14] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[14ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
If the response to the initial INVITE is a 3xx-Redirect, the UAC generates a new initial INVITE request to the destination specified in the Contact: header, as per standard SIP. If a UAC receives a 3xx-Redirect response to an initial INVITE, the new INVITE generated by the UAC MUST contain the P-DCS-Billing-Info header from the 3xx- Redirect response. If the UAC is acting as a B2BUA, instead of generating a new INVITE it MAY generate a private-URL and place it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. This private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which indicates the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the originator to re-use this private-URL for multiple calls.
イニシャルへの応答であるなら、INVITEはaです。3xx再直接です、UACは新しい初期のINVITE要求をContactで指定された目的地に発生させます: 標準のSIPに従ってヘッダー。 UACが初期のINVITEへの3xx再直接の応答を受けるなら、UAC MUSTによって発生した新しいINVITEは3xxの再直接の応答からのP-DCS支払いインフォメーションヘッダーを含んでいます。 UACがB2BUAとして機能しているなら、新しいINVITEを発生させることの代わりに、それは、個人的なURLを発生させて、由来している終点に送られた3xx再直接の応答のContactヘッダーにそれを置くかもしれません。 または、この個人的なURLが含まなければならない、(ポインタを含んでいる、)、P-DCS支払いインフォメーション値、創始者の能力を再使用に制限するために、倍数のためのこの個人的なURLは呼びます。(それは、将来、非常にまもなく、新しい呼び出し、および満了時間充電アレンジメントを示します)。
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.
UAC、それが含んでいる、Refer、-、ヘッダー、a REFERが要求するコネが中にP-DCS支払いインフォメーションヘッダーを含まなければならない、Refer、-、URL。 このP-DCS支払いインフォメーションヘッダーはREFERの創始者の課金情報を入れなければなりません。
7.4. Procedures at an Untrusted User Agent Server (UAS)
7.4. 信頼されていないユーザエージェントサーバにおける手順(UAS)
This header is never sent to an untrusted UAS, and is never sent by an untrusted UAS.
このヘッダーは、信頼されていないUASに決して送られないで、また信頼されていないUASによって決して送られません。
7.5. Procedures at a Trusted User Agent Server (UAS)
7.5. 信じられたユーザエージェントサーバにおける手順(UAS)
The UAS MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE message. This P-DCS-Billing-Info header MUST include the Billing- Correlation-ID generated by the UAS, the FEID of the UAS, and the RKS-Group-ID of the Record-Keeping-Server being used by the UAS. The UAS MAY change the values of Acct-Charge-URI if it wishes to override the billing information that was present in the INVITE (e.g., for a toll-free call). The decision to do this and the contents of the new Acct-Charge-URI MUST be determined by service provider policy provisioned in the UAS. If the UAS performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.
UAS MUSTは初期のINVITEメッセージへの最初の信頼できる1xx(100を除いた)か2xx応答にP-DCS支払いインフォメーションヘッダーを含んでいます。 UASによって使用されて、このP-DCS支払いインフォメーションヘッダーはUAS、UASのFEID、およびRecordキープサーバのRKSグループIDによって発生したBilling Correlation IDを入れなければなりません。 INVITE(例えば、フリーダイヤル通話のための)で存在している支払い情報に優越したいなら、UAS MAYはAcct料金URIの値を変えます。 UASで食糧を供給されたサービスプロバイダー方針でこれをするという決定と新しいAcct料金URIのコンテンツを決定しなければなりません。 UASがLNP質問を実行したなら、それは質問で返されたルート設定NumberとLocationルート設定Numberを含まなければなりません。
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.
UAS MUSTは初期のINVITEへの3xx再直接の応答にP-DCS支払いインフォメーションヘッダーを加えます、呼び出し混載業者のために課金情報を与えて、目的地から転送している目的地までの呼び出しセグメントのために。
Marshall & Andreasen Informational [Page 15] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[15ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
7.6. Procedures at Proxy
7.6. プロキシにおける手順
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.
3セットのプロキシ手順は定義されます: (1) (2) (3) 2人乗り自転車プロキシにおける由来しているプロキシにおける手順、終わっているプロキシにおける手順、および手順。
The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.
由来しているプロキシは非信じられた終点からINVITE要求を受け取ったプロキシです。
The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint.
終わっているプロキシは非信じられた終点にINVITE要求を送るプロキシです。
A proxy that is neither an originating proxy, nor a terminating proxy, is a tandem proxy.
由来しているプロキシでなくてまた終わっているプロキシでないプロキシは、2人乗り自転車プロキシです。
For purposes of mid-call changes, such as call transfers, the proxy that receives the request from a non-trusted endpoint is considered the initiating proxy; the proxy that sends the request to a non- trusted endpoint is considered the recipient proxy. Procedures for the initiating proxy are included below with those for originating proxies, while procedures for the recipient proxy are included with those for terminating proxies.
呼び出し転送などの中間の呼び出し変化の目的のために、非信じられた終点から要求を受け取るプロキシは開始しているプロキシであると考えられます。 非信じられた終点に要求を送るプロキシは受取人プロキシであると考えられます。 開始しているプロキシのための手順は以下に由来しているプロキシのためのそれらで含まれています、受取人プロキシのための手順がプロキシを終えるためのそれらで含まれていますが。
A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to a non-trusted endpoint, performs both sets of procedures.
信頼されていない終点からINVITE要求を受け取って、非信じられた終点にINVITE要求を送るプロキシは両方のセットの手順を実行します。
7.6.1. Procedures at Originating Proxy
7.6.1. 由来しているプロキシにおける手順
The originating proxy MUST generate the Billing-Correlation-ID for the call, and insert it into the P-DCS-Billing-Info header in the initial INVITE message sent to the terminating proxy, along with the charging information for the call. The originating proxy MUST include its FEID, and the RKS-Group-ID for the Record-Keeping-Server being used by the originating proxy. If the originating proxy performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query. Any P-DCS-Billing- Info header present from an untrusted UA MUST be removed.
由来しているプロキシは、呼び出しのためにBilling Correlation IDを発生させて、終わっているプロキシに送られた初期のINVITEメッセージのP-DCS支払いインフォメーションヘッダーにそれを挿入しなければなりません、呼び出しのための充電情報と共に。 由来しているプロキシはFEID、および由来しているプロキシによって使用されるRecordキープサーバのためのRKSグループIDを入れなければなりません。 由来しているプロキシがLNP質問を実行したなら、それは質問で返されたルート設定NumberとLocationルート設定Numberを含まなければなりません。 信頼されていないUaから出席しているどんなP-DCSを請求しているインフォメーションのヘッダーも取り除かなければなりません。
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.
Request-URIが個人的なURLを含んでいて、解読されたユーザ名が支払い情報を含んでいるなら、それが情報であると解読されている状態で、由来しているプロキシはP-DCS支払いインフォメーションヘッダーを発生させなければなりません。 さもなければ、由来しているプロキシは、呼び出し創始者のために課金情報を決定して、その情報を含むP-DCS支払いインフォメーションヘッダーを挿入しなければなりません。
Marshall & Andreasen Informational [Page 16] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[16ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
If the response to the initial INVITE is a 3xx-Redirect, received prior to a 18x, the originating proxy generates a new initial INVITE request to the destination specified in the Contact: header, as per standard SIP. If an originating proxy receives a 3xx-Redirect response to an initial INVITE prior to a 18x response, the INVITE generated by the proxy MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect response.
初期のINVITEへの応答が3xx再直接の、そして、18xの前で受け取られていているaであるなら、由来しているプロキシは新しい初期のINVITE要求をContactで指定された目的地に発生させます: 標準のSIPに従ってヘッダー。 由来しているプロキシが18x応答の前に初期のINVITEへの3xx再直接の応答を受けるなら、プロキシによって発生したINVITEは3xx再直接の応答からのP-DCS支払いインフォメーションヘッダーを含まなければなりません。
If the response to the initial INVITE is a 3xx-Redirect, received after a 18x, the originating proxy generates a private-URL and places it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. This private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which indicate the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the originator to re-use this private-URL for multiple calls.
初期のINVITEへの応答が3xx再直接の、そして、18xの後に受け取られていているaであるなら、由来しているプロキシは、個人的なURLを発生させて、由来している終点に送られた3xx再直接の応答のContactヘッダーにそれを置きます。 または、この個人的なURLが含まなければならない、(ポインタを含んでいる、)、非常にすぐ未来のP-DCS支払いインフォメーション値、どれが新しい呼び出しのための充電アレンジメントを示すか、そして、および満了時間、創始者の能力を再使用に制限するために、倍数のためのこの個人的なURLは呼びます。
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.
信頼されていないUaからREFER要求を処理する由来しているプロキシが中でP-DCS支払いインフォメーションヘッダーを入れなければならない、Refer、-、URL。 このP-DCS支払いインフォメーションヘッダーは創始者の課金情報を入れなければなりません。
7.6.2. Procedures at Terminating Proxy
7.6.2. プロキシを終えることにおける手順
The terminating proxy MUST NOT send the P-DCS-Billing-Info header to an untrusted destination.
終わっているプロキシはP-DCS支払いインフォメーションヘッダーを信頼されていない目的地に送ってはいけません。
The terminating proxy MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE message. This P-DCS-Billing-Info header MUST include the Billing- Correlation-ID generated by the terminating proxy, the FEID of the terminating proxy, and the RKS-Group-ID of the Record-Keeping-Server being used by the terminating proxy. The terminating proxy MAY change the values of Acct-Charge-URI if it wishes to override the billing information that was present in the INVITE (e.g., for a toll-free call). The decision to do this and the contents of the resulting P-DCS-Billing-Info header MUST be determined by service provider policy provisioned in the terminating proxy. If the terminating proxy performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.
終わっているプロキシは初期のINVITEメッセージへの最初の信頼できる1xx(100を除いた)か2xx応答でP-DCS支払いインフォメーションヘッダーを入れなければなりません。 このP-DCS支払いインフォメーションヘッダーは終わっているプロキシ(終わっているプロキシのFEID)によって発生したBilling Correlation IDと終わっているプロキシによって使用されるRecordキープサーバのRKSグループIDを入れなければなりません。 INVITE(例えば、フリーダイヤル通話のための)で存在している支払い情報に優越したいなら、終わっているプロキシはAcct料金URIの値を変えるかもしれません。 終わっているプロキシで食糧を供給されたサービスプロバイダー方針でこれをするという決定と結果として起こるP-DCS支払いインフォメーションヘッダーのコンテンツを決定しなければなりません。 終わっているプロキシがLNP質問を実行したなら、それは質問で返されたルート設定NumberとLocationルート設定Numberを含まなければなりません。
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.
終わっているプロキシは初期のINVITEへの3xxの再直接の応答にP-DCS支払いインフォメーションヘッダーを加えなければなりません、呼び出し混載業者のために課金情報を与えて、目的地から転送している目的地までの呼び出しセグメントのために。
Marshall & Andreasen Informational [Page 17] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[17ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
A proxy receiving a mid-call REFER request that includes a Refer-to header generates a private-URL and places it in the Refer-to header sent to the endpoint. This private-URL MUST contain the P-DCS- Billing-Info value, which indicate the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the endpoint to re-use this private-URL for multiple calls.
それが含む中間の呼び出しREFER要求を受け取るプロキシ、Refer、-、ヘッダー、個人的なURLを発生させて、それを置く、Refer、-、ヘッダーは終点に発信しました。 この個人的なURLは、将来、非常にまもなく、終点が複数の呼び出しにこの個人的なURLを再使用する能力を制限するためにP-DCS支払いインフォメーション価値、どれが新しい呼び出しのための充電アレンジメントを示すか、そして、および満了時間を含まなければなりません。
7.6.3. Procedures at Tandem Proxy
7.6.3. 2人乗り自転車プロキシにおける手順
If the tandem proxy performed a LNP query, it MUST insert the Routing Number and Location Routing Number returned by the query into the P- DCS-Billing-Info header in the first reliable 1xx/2xx/3xx (except 100) response.
2人乗り自転車プロキシがLNP質問を実行したなら、それは最初の信頼できる1xx/2xx/3xx(100を除いた)応答でP DCS支払いインフォメーションヘッダーに質問で返されたルート設定NumberとLocationルート設定Numberを挿入しなければなりません。
8. P-DCS-LAES and P-DCS-REDIRECT
8. P-DCS-LAESでP-DCS再直接です。
NOTE: According to RFC 2804 [5], the IETF supports documentation of lawful intercept technology if it is necessary to develop it. The following section provides such documentation. The RFC 2119 language, as stated above, describes the requirements of the specification only if implemented, and strictly within the applicability domain described above. See RFC 2804 for description of issues regarding privacy, security, and complexity in relation to this technology.
以下に注意してください。 RFC2804[5]によると、それを開発するのが必要であるなら、IETFは合法的なインタセプト技術のドキュメンテーションを支持します。 以下のセクションはそのようなドキュメンテーションを提供します。 実行されて、上で厳密に適用性ドメインの中で説明される場合にだけ、2119年のRFC言語は、仕様の要件を上で述べられると説明します。 プライバシー、セキュリティ、および複雑さに関する問題の記述に関してこの技術と関連してRFC2804を見てください。
The P-DCS-LAES extension contains the information needed to support Lawfully Authorized Electronic Surveillance. This header contains the address and port of an Electronic Surveillance Delivery Function for delivery of a duplicate stream of event messages related to this call. The header may also contain an additional address and port for delivery of call content. Security key information is included to enable pairs of Delivery Functions to securely exchange surveillance information. This header is only used between proxies and trusted User Agents.
P-DCS-LAES拡張子はLawfully Authorized Electronic Surveillanceを支持するのに必要である情報を含んでいます。 このヘッダーはこの呼び出しに関連するイベントメッセージの写しストリームの配送のためのElectronic Surveillance Delivery Functionのアドレスとポートを含んでいます。 また、ヘッダーは呼び出し内容の配送のための追加アドレスとポートを含むかもしれません。 セキュリティの主要な情報は、組のDelivery Functionsがしっかりと監視情報を交換するのを可能にするために含まれています。 このヘッダーはプロキシと信じられたUserエージェントの間で使用されるだけです。
The P-DCS-Redirect extension contains call identifying information needed to support the requirements of Lawfully Authorized Electronic Surveillance of redirected calls. This header is only used between proxies and trusted User Agents.
P-DCS再直接の拡大は向け直された呼び出しのLawfully Authorized Electronic Surveillanceの要件を支持するのに必要である呼び出し身元が分かる情報を含んでいます。 このヘッダーはプロキシと信じられたUserエージェントの間で使用されるだけです。
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
P-DCS-LAESでP-DCS再直接の使用は従わなければならない法律、規則、および裁判所命令の組み合わせで制御されます。 これらのヘッダーのあるケース包含、示された要求と応答におけるプレゼントは、強制されて、したがって、中であるに違いありません。 他の場合では、これらのヘッダーの包含は、禁じられて、したがって、示された要求と応答で存在しているはずがありません。 続く小区分では、“SHOULD"の使用は意図します。
Marshall & Andreasen Informational [Page 18] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[18ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
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.
例えばこれらの闘争状況を得てください。a P-DCS-LAESヘッダーSHOULDがそれがどちらかであるに違いないのにもかかわらずの、含まれていて、INVITEが意味するか、または含まれていなくて、それが意味しなければならないイニシャルに含まれていて、適切に基づいて法廷は注文されます。
8.1. Syntax
8.1. 構文
The formats of the P-DCS-LAES and P-DCS-Redirect headers are given by the following ABNF (some terms used in this ABNF are defined in [2] and [3]):
P-DCS-LAESの形式とP-DCS再直接のヘッダーは以下のABNFによって与えられています。(このABNFで使用されるいくつかの用語が[2]と[3])で定義されます:
P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig
*(SEMI Laes-param)
Laes-sig = hostport
Laes-param = Laes-content / Laes-key / generic-param
Laes-content = "content" EQUAL hostport
Laes-key = "key" EQUAL token
P-DCS-LAES=「P-DCS-LAES」HCOLON Laes-sig*(セミトレーラLaes-param)Laes-sig=hostport Laes-paramは一般的なparam Laes Laes-キー/内容=「内容」等しいhostport Laes主要な=Laes-内容/「キー」等しい象徴と等しいです。
P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID
*(redir-params)
Called-ID = LDQUOT addr-spec RDQUOT
redir-params = redir-uri-param / redir-count-param /
generic-param
redir-uri-param = "redirector-uri" EQUAL Redirector
Redirector = LDQUOT addr-spec RDQUOT
redir-count-param = "count" EQUAL Redir-count
Redir-count = 1*DIGIT
「リダイレクタ-uri」一般的なP-DCS再直接の=LDQUOT addr-仕様RDQUOT redir-params=redir-uri-param / redirカウント「P-DCS再直接」のHCOLON Called-ID*(redir-params)呼ばれたID=param/param redir-uri-param=EQUAL Redirector RedirectorはRDQUOT redirがparamを数えているLDQUOT addr-仕様=「カウント」EQUAL Redir-カウントRedir-カウント=1*DIGITと等しいです。
This document adds the following entry to Table 2 of [2]:
このドキュメントは[2]のTable2に以下のエントリーを加えます:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-LAES adr - - - o - -
P-DCS-Redirect adr - - - o - -
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG------------ ----- ----- --- --- --- --- --- --- P-DCS-LAES adr------o----adrをP-DCS向け直してください------o--、-
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
- - - - - -
潜水艦審判INF UPD PRAでない--- --- --- --- --- --- - - - - - - - - - - - -
The values of Laes-sig and Laes-content are addresses of the Electronic Surveillance Delivery Function, and used as the destination address for call-identifying information and call- content, respectively. Laes-key is a string generated by the proxy that is used by the Delivery Function to securely transfer information between them [8].
Laes-sigとLaes-内容の値は、Electronic Surveillance Delivery Function、呼び出し身元が分かる情報のための送付先アドレスとして中古のアドレスであり、それぞれ内容と呼びます。 Laes-キーはしっかりとそれらの間に情報を移すのにDelivery Functionによって使用されるプロキシによって発生したストリングです。[8]。
Marshall & Andreasen Informational [Page 19] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[19ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
The P-DCS-Redirect header contains redirection information. The redir-uri-param indicates the original destination requested by the user (e.g., dialed number), the Redirector indicates the new destination, and the Redir-count indicates the number of redirections that have occurred.
P-DCS再直接のヘッダーはリダイレクション情報を含んでいます。 redir-uri-paramはユーザ(例えば、番号にダイヤルする)によって要求された元の目的地を示します、そして、Redirectorは新しい目的地を示します、そして、Redir-カウントは起こったリダイレクションの数を示します。
8.2. Procedures at an Untrusted User Agent Client (UAC)
8.2. 信頼されていないユーザエージェントのクライアントにおける手順(UAC)
This header MUST NOT be sent to an untrusted UAC, and MUST NOT be sent by an untrusted UAC.
このヘッダーは、信頼されていないUACに送ってはいけなくて、信頼されていないUACは送ってはいけません。
8.3. Procedures at a Trusted User Agent Client (UAC)
8.3. 信じられたユーザエージェントのクライアントにおける手順(UAC)
The UAC checks for an outstanding lawfully authorized surveillance order for the originating subscriber, and, if present, includes this information in the Authorization for Quality of Service [7] or signals this information to the device performing the intercept (e.g., a Media Gateway).
UACは由来している加入者の傑出している合法的に認可された監視命令がないかどうかチェックして、存在しているならService[7]のQualityのためのAuthorizationでこの情報を含めるか、またはインタセプト(例えば、メディアゲートウェイ)を実行する装置にこの情報に合図します。
If the P-DCS-LAES header is present in the first reliable 1xx (except 100), 2xx or 3xx response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), the UAC MUST include this information in the Authorization for Quality of Service, or MUST signal this information to the device performing the intercept (e.g., a Media Gateway).
最初の信頼できる1xx(100を除いた)、2xxまたは3xx応答(終わり設備がその機能を実行しないことができなかったなら、監視を示すのが終わっている加入者の上で必要である)で存在しています、UAC MUSTがServiceのQualityのためのAuthorizationのこの情報を含んでいるということである、またはP-DCS-LAESヘッダーがインタセプト(例えば、メディアゲートウェイ)を実行する装置にこの情報に合図しなければならないなら。
If a 3xx-Redirect response is received to the initial INVITE request, 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 new destination number, 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 surveillance system has the terminating equipment performing the surveillance for all the intermediate forwardings.
3xx再直接の応答を初期のINVITE要求に受けて、P-DCS-LAESヘッダーが3xx応答で出席しているなら、UAC SHOULDは再発行されたINVITEで変わりのないそのヘッダーを含んでいます。 また、UAC SHOULDは元のダイヤルされた数、新しい目的地番号、および起こったリダイレクションの数を含むP-DCS再直接のヘッダーを含んでいます。 由来している設備がこの監視を実行するのが、技術的に可能ですが(呼び出しの既存の監視の一助となってください)、監視システムの設計で、終わり設備はすべての中間的推進のための監視を実行します。
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 P-DCS-LAES header 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 SHOULD include a random string for use as a security key between the Delivery Functions.
UAC、それが含んでいる、Refer、-、ヘッダー、由来している加入者に傑出している合法的に認可された監視命令があるときのREFER要求では、SHOULDがヘッダーが付いたP-DCS-LAESを含んでいる、Refer、- P-DCS-LAESヘッダーSHOULDは呼び出しのイベントメッセージのコピーのための地方のElectronic Surveillance Delivery Functionのアドレスとポートを含んでいます、そして、SHOULDは呼び出し内容が妨害されることであるなら呼び出し内容のコピーのための地方のElectronic Surveillance Delivery Functionのアドレスとポートを含んでいます、そして、SHOULDはDelivery Functionsの間で主要なセキュリティとして使用のための無作為のストリングを含んでいます。
Marshall & Andreasen Informational [Page 20] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[20ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
The trusted UAC MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.
信じられたUAC MUST NOTはP-DCS-LAESとP-DCS再直接のヘッダーを信頼されていない実体に送ります。
8.4. Procedures at an Untrusted User Agent Server (UAS)
8.4. 信頼されていないユーザエージェントサーバにおける手順(UAS)
This header MUST NOT be sent to an untrusted UAS, and MUST NOT be sent by an untrusted UAS.
このヘッダーは、信頼されていないUASに送ってはいけなくて、信頼されていないUASは送ってはいけません。
8.5. Procedures at a Trusted User Agent Server (UAS)
8.5. 信じられたユーザエージェントサーバにおける手順(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 includes this information in the authorization for Quality of Service [7].
UASは終わっている加入者の傑出している合法的に認可された監視命令、またはINVITE要求における、P-DCS-LAESヘッダーの存在がないかどうかチェックします。 どちらかが存在しているなら、UASはService[7]のQualityのための認可にこの情報を含んでいます。
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 non-100 response requesting the originating proxy to perform the surveillance. The P-DCS-LAES header 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 SHOULD include a random string for use as a security key between the Delivery Functions.
終わり設備が必要な監視を実行できないなら(例えば、目的地がボイスメールサーバであるなら)、監視を実行するよう由来しているプロキシに要求しながら、UAS SHOULDは最初の信頼できる非100応答にP-DCS-LAESヘッダーを含んでいます。 P-DCS-LAESヘッダーSHOULDは呼び出しのイベントメッセージのコピーのための地方のElectronic Surveillance Delivery Functionのアドレスとポートを含んでいます、そして、SHOULDは呼び出し内容が妨害されることであるなら呼び出し内容のコピーのための地方のElectronic Surveillance Delivery Functionのアドレスとポートを含んでいます、そして、SHOULDは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 SHOULD include a P-DCS-LAES header in the 3xx-Redirect response, with contents as described above.
初期のINVITE要求への応答が3xx再直接の応答であり、終わっている加入者の傑出している合法的に認可された監視命令があれば、UAS SHOULDは3xx再直接の応答にP-DCS-LAESヘッダーを含んでいます、上で説明されるコンテンツで。
The trusted UAS MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.
信じられたUAS MUST NOTはP-DCS-LAESとP-DCS再直接のヘッダーを信頼されていない実体に送ります。
8.6. Procedures at Proxy
8.6. プロキシにおける手順
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.
2セットのプロキシ手順は定義されます: (1) (2) 由来しているプロキシにおける手順、および終わっているプロキシにおける手順。 由来しているプロキシは非信じられた終点からINVITE要求を受け取ったプロキシです。
The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint.
終わっているプロキシは非信じられた終点にINVITE要求を送るプロキシです。
Marshall & Andreasen Informational [Page 21] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[21ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
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, MUST NOT generate P-DCS-LAES nor P-DCS-Redirect headers.
信頼されていない終点からINVITE要求を受け取って、非信じられた終点にINVITE要求を送るプロキシは、P-DCS-LAESを発生させて、ヘッダーをP-DCS向け直してはいけません。
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.
由来しているプロキシでなくてまたSHOULDが要求と応答でP-DCS-LaesとP-DCS再直接のヘッダーを渡す終わっているプロキシでないプロキシ。
8.6.1. Procedures at Originating Proxy
8.6.1. 由来しているプロキシにおける手順
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.
Originating Proxyは信頼されていないプロキシ、または、UAか信頼されていないUAから要求か応答でどんなP-DCS-LAESとP-DCS再直接のヘッダーも取り外さなければなりません。
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 [7] or signals this information to the device performing the intercept (e.g., a Media Gateway).
由来しているプロキシは、由来している加入者の傑出している合法的に認可された監視命令がないかどうかチェックして、存在しているならService[7]のQualityのためのAuthorizationでこの情報を入れるか、またはインタセプト(例えば、メディアゲートウェイ)を実行する装置にこの情報に合図します。
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 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).
P-DCS-LAESヘッダーが最初の信頼できる1xx(100を除いた)、2xxまたは3xx応答で出席しているなら(終わり設備がその機能を実行しないことができなかったなら、監視を示すのが終わっている加入者の上で必要です)、由来しているプロキシは、ServiceのQualityのためのAuthorizationでこの情報を入れなければならないか、またはインタセプト(例えば、メディアゲートウェイ)を実行する装置にこの情報に合図しなければなりません。
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 header with the surveillance information.
初期のINVITE要求におけるRequest-URIが個人的なURLを含んでいるなら、由来しているプロキシは、呼び出し、および情報を処理する他の特別番組に関して本当の目的地を見つけるためにuserinfo情報を解読しなければなりません。 電子監視情報が解読されたuserinfoに含まれているなら、由来しているプロキシSHOULDは監視情報でP DCS-LAESヘッダーを発生させます。
If a 3xx-Redirect response is received to the initial INVITE request prior to a 18x, 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
18xの前で3xx再直接の応答を初期のINVITE要求に受けて、P-DCS-LAESヘッダーが3xx応答で出席しているなら、由来しているプロキシSHOULDは再発行されたINVITEで変わりのないそのヘッダーを含んでいます。 また、由来しているプロキシSHOULDはaを含んでいます。
Marshall & Andreasen Informational [Page 22] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[22ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
P-DCS-Redirect header containing the original dialed number, the new destination number, and the number of redirections that have occurred.
元のダイヤルされた数、新しい目的地番号、および起こったリダイレクションの数を含むP-DCS再直接のヘッダー。
If a 3xx-Redirect response is received to the initial INVITE request after a 18x, the originating proxy generates a private-URL and places it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. 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.
18xの後の初期のINVITE要求に3xx再直接の応答を受けるなら、由来しているプロキシは、個人的なURLを発生させて、由来している終点に送られた3xx再直接の応答のContactヘッダーにそれを置きます。 P-DCS-LAESヘッダーが3xx応答で出席しているなら、この個人的なURLは(1) 3xx再直接の応答からの電子監視情報、(2) 元の目的地番号、(3) 向け直すパーティーのアイデンティティ、および(4) この呼び出しのリダイレクションの数を含まなければなりません。
An originating proxy that processes a REFER request [4] 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. The P-DCS-LAES header SHOULD include (1) the address and port of the local Electronic Surveillance Delivery Function for a 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, and (3) a random string for use as a security key between the Delivery Functions.
由来している加入者に傑出している合法的に認可された監視命令があるとき信頼されていないUAからREFER要求[4]を処理する由来しているプロキシはその要求のためのB2BUAになります。 それ、SHOULDがヘッダーが加えたP-DCS-LAESとの要求を再発行する、Refer、-、URL。 P-DCS-LAESヘッダーSHOULDは呼び出し内容が妨害されることであり、(3)がDelivery Functionsの間で主要なセキュリティとしての使用のための無作為のストリングであるなら(1) (2) 呼び出し内容のコピーのための地方のElectronic Surveillance Delivery Functionの呼び出しのイベントメッセージのコピーのための地方のElectronic Surveillance Delivery Functionのアドレスとポート、アドレス、およびポートを含んでいます。
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.
中間の呼び出しREFER要求がそれで含んでいる開始しているプロキシ、Refer、-、ヘッダー、開始している加入者に傑出している合法的に認可された監視命令があるとき、SHOULDが中にP-DCS-LAESヘッダーを含んでいる、Refer、-、URL。
The originating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.
由来しているプロキシはP-DCS-LAESとP-DCS再直接のヘッダーを信頼されていない実体に送ってはいけません。
8.6.2. Procedures at Terminating Proxy
8.6.2. プロキシを終えることにおける手順
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.
Terminating ProxyはUAか信頼されていないプロキシかUAから要求か応答でどんなP-DCS-LAESとP-DCS再直接のヘッダーも取り外さなければなりません。
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 [7].
終わっているプロキシは終わっている加入者の傑出している合法的に認可された監視命令がないかどうかチェックします。 存在しているなら、終わっているプロキシはService[7]のQualityのための認可でこの情報を入れます。
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.
どちらか要求か応答におけるヘッダーとしての信頼されていない実体、またはヘッダーが要求か応答におけるURIに付いたので、終わっているプロキシはP-DCS-LAESとP-DCS再直接のヘッダーを送ってはいけません。
Marshall & Andreasen Informational [Page 23] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[23ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
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 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 SHOULD include a random string for use as a security key between the Delivery Functions.
終わり設備が必要な監視を実行できないなら(例えば、目的地がボイスメールサーバであるなら)、監視を実行するよう由来しているプロキシに要求しながら、終わっているプロキシSHOULDは最初の信頼できる1xx/2xx/3xx(100を除いた)応答にP-DCS-LAESヘッダーを含んでいます。 P-DCS-LAESヘッダーSHOULDは呼び出しのイベントメッセージのコピーのための地方のElectronic Surveillance Delivery Functionのアドレスとポートを含んでいます、そして、SHOULDは呼び出し内容が妨害されることであるなら呼び出し内容のコピーのための地方のElectronic Surveillance Delivery Functionのアドレスとポートを含んでいます、そして、SHOULDは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 SHOULD include a P-DCS-LAES header in the 3xx-Redirect response, with contents as described above.
初期のINVITE要求への応答が3xx再直接の応答であり、終わっている加入者の傑出している合法的に認可された監視命令があれば、終わっているプロキシSHOULDは3xx再直接の応答にP-DCS-LAESヘッダーを含んでいます、上で説明されるコンテンツで。
A proxy receiving a mid-call REFER request [4] 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 information from the attached header.
それが含む中間の呼び出しREFER要求[4]を受け取るプロキシ、Refer、-、ヘッダー、P-DCS-LAESと共に、添付のヘッダーはこの要求のためのB2BUAになります。 個人的なURLを発生させて、それを置かなければならない、Refer、-、ヘッダーは終点に発信しました。 この個人的なURLは付属ヘッダーからのP-DCS-LAES情報を含まなければなりません。
9. Security Considerations
9. セキュリティ問題
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 is REQUIRED. A minimum mandatory-to-implement IPsec configuration for the DCS architecture is given by [8]. 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.
QoSゲートコーディネート、支払い情報、および電子監視情報は、雨垂れから保護しなければならない機密情報であり、その上、保全の照合を必要とするとすべて考えられます。 したがって、信じられたUAsとプロキシが雨垂れといじるのからこの情報を保護するために予防策を講するのが必要です。 Proxiesの間のIPsecかTLSの使用はREQUIREDです。 [8]はDCS構造のための最小の実行するために義務的なIPsec構成を与えます。 また、REQUIREDは信じられたUAsとProxiesの間のProxiesと(2)の間の互いの認証(1)です。それの両方がProxiesのために行政上あらかじめ共有されたキーか、別の信頼できる第三者機関との相談を通して実行されるかもしれません。 IPsecが使用されているつもりであるなら、安全保障政策の仕様とこれらのヘッダーが適切である管理ドメインの手順(そして、連邦における管理ドメインの間のすべての関係)は共同利用できるオプションを定義しなければなりません。
Marshall & Andreasen Informational [Page 24] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[24ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
10. IANA Considerations
10. IANA問題
This document defines a number of SIP extension headers, which have been included in the registry of SIP headers defined in [2]. Registration information for new headers is as follows:
このドキュメントは多くのSIP拡張ヘッダーを定義します。(その拡張ヘッダーは、[2]で定義されたSIPヘッダーの登録に含まれています)。 新しいヘッダーへのレジスト情報は以下の通りです:
Header Field Name: P-DCS-Trace-Party-ID
RFC Number: 3603
Compact Form: none
ヘッダーフィールド名: P-DCS跡のParty ID RFC番号: 3603年のコンパクト形: なし
Header Field Name: P-DCS-OSPS
RFC Number: 3603
Compact Form: none
ヘッダーフィールド名: P-DCS-OSPS RFC番号: 3603年のコンパクト形: なし
Header Field Name: P-DCS-Billing-Info
RFC Number: 3603
Compact Form: none
ヘッダーフィールド名: P-DCS支払いインフォメーションRFC番号: 3603年のコンパクト形: なし
Header Field Name: P-DCS-LAES
RFC Number: 3603
Compact Form: none
ヘッダーフィールド名: P-DCS-LAES RFC番号: 3603年のコンパクト形: なし
Header Field Name: P-DCS-Redirect
RFC Number: 3603
Compact Form: none
ヘッダーフィールド名: P-DCS再直接のRFC番号: 3603年のコンパクト形: なし
11. Intellectual Property Rights Notice
11. 知的所有権通知
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] 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.
[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
Marshall & Andreasen Informational [Page 25] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[25ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[4] スパークス、R.、「セッション開始プロトコル(一口)は方法を参照する」RFC3515、2003年4月。
[5] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[5] IABとIESG(「盗聴に関するIETF方針」、RFC2804)は2000がそうするかもしれません。
12.2. Informative References
12.2. 有益な参照
[6] DCS Group, "Architectural Considerations for Providing Carrier
Class Telephony Services Utilizing SIP-based Distributed Call
Control Mechanisms", Work in Progress.
[6] 「一口ベースの分配された呼び出し制御機構を利用するサービスをキャリヤークラス電話に供給するための建築問題」というDCSグループは進行中で働いています。
[7] PacketCable Dynamic Quality of Service Specification, pkt-sp-
dqos-i07-030815, August 2003.
2003年8月のService Specification、pkt-sp- dqos-i07-030815の[7]PacketCable Dynamic Quality。
[8] PacketCable Security Specification, pkt-sp-sec-i09-030728, July
2003.
[8] PacketCable Security Specification、pkt-sp秒のi09-030728、7月2003日
[9] PacketCable Event Message Specification, pkt-sp-em-i07-030815,
August 2003.
[9] PacketCable Event Message Specification、pkt-sp-em-i07-030815、2003年8月。
[10] 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.
[10] ジョニングス、C.、ピーターソン、J.、およびM.ワトソン、「セッション開始への個人的な拡大は断言されたアイデンティティのために信じられたネットワークの中で(一口)について議定書の中で述べます」、RFC3325、2002年11月。
13. Acknowledgements
13. 承認
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.
PacketCableプロジェクトにおけるDistributed Call Signaling仕事は多くの人々の仕事です、多くの異なった会社を代表して。 作者がそうしたい、認識して、感謝する、: ジョン・ウィーラー、モトローラ。 デヴィッドBoardman、ダニエル・ポール、アリスInteractive。 ビル・ブルーム、ジョンFellows、ジェイStrater、ジェフ・オリス、クライヴHolborow、モトローラ。 ダグ・ニューリン、グイド・シュスター、Ikhlaq Sidhu、3Com。 ジリマトウシェク、ベイネットワークス。 Farzi Khazai、ノーテル。 ジョン・チャップマン、ビルGuckel、マイケルRamalho、シスコ。 チャックKalmanek、ダグNortz、ジョンLawser、ジェームス・チェン、タン・Haiシャオ、Partho Mishra、AT&T。 Telcordia技術。 そして、透明な有線通信。
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; 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
ビル・マーシャル( wtm@research.att.com )とK.K.Ramakrishnan( kkrama@research.att.com )、AT&T。 エド・ミラー( edward.miller@terayon.com )、Terayon。 グレン・ラッセル( G.Russell@Cablelabs.com )、CableLabs。 Burcak Beser( burcak@juniper.net )杜松ネットワークとマイクMannette( Michael_Mannette@3com.com )とカート・スタインブレナー( Kurt_Steinbrenner@3com.com )、3Com。 そしてデーヴ・オラン( oran@cisco.com )。
Marshall & Andreasen Informational [Page 26] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[26ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
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.
フレミングAndreasen( fandreas@cisco.com )、シスコシステムズ。 ジョン・ピケンズ( jpickens@com21.com )、Com21。 Poornima Lalwaney( poornima.lalwaney@nokia.com )、ノキア。 ジョンFellows( jfellows@coppermountain.com )、カッパーマウンテンネットワーク。 Doc Evans( n7dr@arrisi.com )・アリス、およびキース・ケリー( keith@netspeak.com )、NetSpeak。
14. Editors' Addresses
14. エディタのアドレス
Bill Marshall AT&T Florham Park, NJ 07932
ビルマーシャルAT&T Florham Park、ニュージャージー 07932
EMail: wtm@research.att.com
メール: wtm@research.att.com
Flemming Andreasen Cisco Edison, NJ
フレミング・Andreasen Ciscoエディソン(ニュージャージー)
EMail: fandreas@cisco.com
メール: fandreas@cisco.com
Marshall & Andreasen Informational [Page 27] RFC 3603 SIP Proxy-to-Proxy Extensions October 2003
マーシャルとAndreasenの情報[27ページ]のRFC3603はプロキシからプロキシへの拡大2003年10月にちびちび飲みます。
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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 implementation 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Marshall & Andreasen Informational [Page 28]
マーシャルとAndreasen情報です。[28ページ]
一覧
スポンサーリンク
