RFC3298 日本語訳
3298 Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) ProtocolRequirements. I. Faynberg, J. Gato, H. Lu, L. Slutsman. August 2002. (Format: TXT=36560 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group I. Faynberg, Editor
Request for Comments: 3298 Lucent Technologies
Category: Informational J. Gato
Vodaphone
H. Lu
Lucent Technologies
L. Slutsman
AT&T
August 2002
Network Working Group I. Faynberg, Editor Request for Comments: 3298 Lucent Technologies Category: Informational J. Gato Vodaphone H. Lu Lucent Technologies L. Slutsman AT&T August 2002
Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements
Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements
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 (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Abstract
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol.
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol.
Faynberg, et al. Informational [Page 1] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg, et al. Informational [Page 1] RFC 3298 SPIRITS Protocol Requirements August 2002
1. Conventions used in this document
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Unless otherwise qualified, the term PINT is used here not to refer to the present PINT services and protocol, but in reference to the scope of the generic PINT (vs. SPIRITS) service characteristics-- services being invoked from an IP network (vs. PSTN).
Unless otherwise qualified, the term PINT is used here not to refer to the present PINT services and protocol, but in reference to the scope of the generic PINT (vs. SPIRITS) service characteristics-- services being invoked from an IP network (vs. PSTN).
2. Introduction
2. Introduction
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service.") The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service.") The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. The joint PINT/SPIRITS architecture (described in [1]) is depicted in Figure 1.
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. The joint PINT/SPIRITS architecture (described in [1]) is depicted in Figure 1.
It is assumed that the Spirits Client is either co-located with the IN Service Control Function (SCF) or communicates with it (over the PSTN-specific interface D) in such a way so as to act on behalf of the PSTN/IN. (This assumption is confirmed by current implementations, as reported in [2].)
It is assumed that the Spirits Client is either co-located with the IN Service Control Function (SCF) or communicates with it (over the PSTN-specific interface D) in such a way so as to act on behalf of the PSTN/IN. (This assumption is confirmed by current implementations, as reported in [2].)
The SPIRITS services are invoked (and, subsequently, the SPIRITS protocol is initiated) when a message from a SPIRITS Client (located in the IN Service Control Point [SCP] or Service Node [SN]) arrives on interface C to the SPIRITS gateway. The Spirits gateway processes the message and, in turn, passes it on over the Interface B to the SPIRITS server. In most practically important cases, the request from a SPIRITS client is ultimately caused by a request from a Central Office (i.e., a telephone switch) sent to either the SCP or
The SPIRITS services are invoked (and, subsequently, the SPIRITS protocol is initiated) when a message from a SPIRITS Client (located in the IN Service Control Point [SCP] or Service Node [SN]) arrives on interface C to the SPIRITS gateway. The Spirits gateway processes the message and, in turn, passes it on over the Interface B to the SPIRITS server. In most practically important cases, the request from a SPIRITS client is ultimately caused by a request from a Central Office (i.e., a telephone switch) sent to either the SCP or
Faynberg, et al. Informational [Page 2] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg, et al. Informational [Page 2] RFC 3298 SPIRITS Protocol Requirements August 2002
SN, although the Internet-based service initiation by these elements that had not been triggered by the Central Office is theoretically possible. (Definitely, none of the SPIRITS benchmark services are initiated in such a way, so, for the purposes of the SPIRITS protocol development, it should be assumed that the service invocation was a direct result of an earlier action by the Service Switching Function.)
SN, although the Internet-based service initiation by these elements that had not been triggered by the Central Office is theoretically possible. (Definitely, none of the SPIRITS benchmark services are initiated in such a way, so, for the purposes of the SPIRITS protocol development, it should be assumed that the service invocation was a direct result of an earlier action by the Service Switching Function.)
Faynberg, et al. Informational [Page 3] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg, et al. Informational [Page 3] RFC 3298 SPIRITS Protocol Requirements August 2002
......................
+----------------+ . .
| +------------+ | . +------------+ .
| | | | A . | | .
| | PINT Client|********************|PINT Server/|********
| | | | . | Gateway | *
| +------------+ | . +------------+ . *
| | . . *
| Subscriber's | . . *
| | . . *
| IP Host | . . *
| | . +------------+ . *
| +------------+ | . | SPIRITS | . *
| | SPIRITS | | B . | Gateway | . *
| | Server |********************| | . * E
| | | | . +------------+ . *
| +------------+ | . * . *
+----------------+ . * . *
...........*.......... *
* *
* *
Subscriber's * C *
Telephone * *
* *
(---) * *
* * *
* * * *
++++++++++++++++++++++++++ PSTN ++++++++++++++++++++++++++
* * *
* * *
* +------------------+ *
* Line | SPIRITS Client | *
* | | *
+--------------------+ +---+----- D ---------+-*+
| | INAP/SS7 | |
|Service Switching ************Service Control Function |
| Function | | |
| | +-------------------------+
| |
| |
+--------------------+
...................... +----------------+ . . | +------------+ | . +------------+ . | | | | A . | | . | | PINT Client|********************|PINT Server/|******** | | | | . | Gateway | * | +------------+ | . +------------+ . * | | . . * | Subscriber's | . . * | | . . * | IP Host | . . * | | . +------------+ . * | +------------+ | . | SPIRITS | . * | | SPIRITS | | B . | Gateway | . * | | Server |********************| | . * E | | | | . +------------+ . * | +------------+ | . * . * +----------------+ . * . * ...........*.......... * * * * * Subscriber's * C * Telephone * * * * (---) * * * * * * * * * ++++++++++++++++++++++++++ PSTN ++++++++++++++++++++++++++ * * * * * * * +------------------+ * * Line | SPIRITS Client | * * | | * +--------------------+ +---+----- D ---------+-*+ | | INAP/SS7 | | |Service Switching ************Service Control Function | | Function | | | | | +-------------------------+ | | | | +--------------------+
Figure 1. Joint PINT/SPIRITS Architecture
Figure 1. Joint PINT/SPIRITS Architecture
Faynberg, et al. Informational [Page 4] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg, et al. Informational [Page 4] RFC 3298 SPIRITS Protocol Requirements August 2002
With PINT (and that also applies to the PINT architecture and protocol as described in [3]), the service request to the PINT Server is always initiated by the PINT Client over the interface A. The PINT Server can either be co-located with the IN Service Control or a similar entity (referred to as "Executive System" by [3]) or communicate with it over the PSTN-specific interface E.
With PINT (and that also applies to the PINT architecture and protocol as described in [3]), the service request to the PINT Server is always initiated by the PINT Client over the interface A. The PINT Server can either be co-located with the IN Service Control or a similar entity (referred to as "Executive System" by [3]) or communicate with it over the PSTN-specific interface E.
As Figure 1 shows, the PINT Client and SPIRITS Server are co-located in Subscriber's IP Host. In fact, both can be implemented to run as one process. No provision is made for interactions between the PINT Client and Spirits Server. Similarly, the PINT Server/PINT Gateway and SPIRITS gateway are assumed to be co-located, too. This assumption is convenient but not essential; the PINT Server could also be co-located with the SPIRITS Client. In either case, no specific provision is made to define interworking between either the PINT Server and Spirits Gateway or PINT Server and SPIRITS Client other than by listing the overall PINT-related requirements.
As Figure 1 shows, the PINT Client and SPIRITS Server are co-located in Subscriber's IP Host. In fact, both can be implemented to run as one process. No provision is made for interactions between the PINT Client and Spirits Server. Similarly, the PINT Server/PINT Gateway and SPIRITS gateway are assumed to be co-located, too. This assumption is convenient but not essential; the PINT Server could also be co-located with the SPIRITS Client. In either case, no specific provision is made to define interworking between either the PINT Server and Spirits Gateway or PINT Server and SPIRITS Client other than by listing the overall PINT-related requirements.
Since the currently deployed worldwide wireless networks are based on circuit switching, they are considered PSTN networks for the SPIRITS purposes. Adding SPIRITS type of services to wireless networks can allow new services to be developed (for example geolocation information can be handled in the IP network).
Since the currently deployed worldwide wireless networks are based on circuit switching, they are considered PSTN networks for the SPIRITS purposes. Adding SPIRITS type of services to wireless networks can allow new services to be developed (for example geolocation information can be handled in the IP network).
Nevertheless, there are certain peculiarities of wireless networks, which force considerations to be made in the protocol requirements and in the SPIRITS architecture.
Nevertheless, there are certain peculiarities of wireless networks, which force considerations to be made in the protocol requirements and in the SPIRITS architecture.
A particular Wireless IN standard development being considered here is CAMEL phase 3, standardized by the Third Generation Partnership group (3GPP). The relevant service and architectural considerations and protocol requirements are presented later in this document. As far as the architecture is concerned, certain wireless events are generated by Home Location Register (HLR), which may, but does not have to, be part of the Mobile Switching Center (MSC) (a wireless equivalent of the SSP). These events are communicated to Service Control, at which point they use the same mechanism for invoking SPIRITS services that the IN would.
A particular Wireless IN standard development being considered here is CAMEL phase 3, standardized by the Third Generation Partnership group (3GPP). The relevant service and architectural considerations and protocol requirements are presented later in this document. As far as the architecture is concerned, certain wireless events are generated by Home Location Register (HLR), which may, but does not have to, be part of the Mobile Switching Center (MSC) (a wireless equivalent of the SSP). These events are communicated to Service Control, at which point they use the same mechanism for invoking SPIRITS services that the IN would.
The rest of this document addresses the general requirements, IN Requirements, specific Wireless IN requirements, PINT Requirements, the protocol development methodology, and security issues, in that order.
The rest of this document addresses the general requirements, IN Requirements, specific Wireless IN requirements, PINT Requirements, the protocol development methodology, and security issues, in that order.
Faynberg, et al. Informational [Page 5] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg, et al. Informational [Page 5] RFC 3298 SPIRITS Protocol Requirements August 2002
3. General Requirements
3. General Requirements
Based on the success of extending SIP for PINT ([3]) and, especially, the results of pre-SPIRITS implementations reported in [2], the Session Initiation Protocol (SIP) [7] has been chosen as the signaling base protocol for SPIRITS.
Based on the success of extending SIP for PINT ([3]) and, especially, the results of pre-SPIRITS implementations reported in [2], the Session Initiation Protocol (SIP) [7] has been chosen as the signaling base protocol for SPIRITS.
Thus, it is a requirement that specific SPIRITS-related parameters be carried in a manner consistent with SIP practices. In particular, either Session Description Protocol (SDP) [8] or Multi-purpose Internet Mail Extensions MIME [5-6] may be used for this purpose. Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], and extensions already defined in PINT, no new SIP extensions are foreseen; instead the SPIRITS protocol is to rely on the above extension mechanisms.
Thus, it is a requirement that specific SPIRITS-related parameters be carried in a manner consistent with SIP practices. In particular, either Session Description Protocol (SDP) [8] or Multi-purpose Internet Mail Extensions MIME [5-6] may be used for this purpose. Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], and extensions already defined in PINT, no new SIP extensions are foreseen; instead the SPIRITS protocol is to rely on the above extension mechanisms.
It is by no means a requirement that any SPIRITS implementation automatically support PINT services. The SPIRITS protocol must be defined in a manner where, as the minimum, it can support only the basic notification mechanism without relying on PINT services or otherwise relying on persistent interactions with PSTN. Nevertheless, it has been demonstrated [2] that combining PINT building blocks with those of SPIRITS is beneficial to building rich, enhanced PSTN/Internet services, so the SPIRITS protocol must meet the PINT-related requirements listed in section 7 of this document.
It is by no means a requirement that any SPIRITS implementation automatically support PINT services. The SPIRITS protocol must be defined in a manner where, as the minimum, it can support only the basic notification mechanism without relying on PINT services or otherwise relying on persistent interactions with PSTN. Nevertheless, it has been demonstrated [2] that combining PINT building blocks with those of SPIRITS is beneficial to building rich, enhanced PSTN/Internet services, so the SPIRITS protocol must meet the PINT-related requirements listed in section 7 of this document.
One specific example demonstrating the application of the latter requirement, which is elaborated on further in this document, is as follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far as the minimum SPIRITS protocol is concerned. Thus, the initial PSTN (Detection Point) notification will always arrive via the SIP INVITE method; however, to implement persistent interactions with the PSTN, the SUBSCRIBE method may be used to obtain further notifications of the PSTN events. Subsequently, these events will be reported on by means of the NOTIFY method.
One specific example demonstrating the application of the latter requirement, which is elaborated on further in this document, is as follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far as the minimum SPIRITS protocol is concerned. Thus, the initial PSTN (Detection Point) notification will always arrive via the SIP INVITE method; however, to implement persistent interactions with the PSTN, the SUBSCRIBE method may be used to obtain further notifications of the PSTN events. Subsequently, these events will be reported on by means of the NOTIFY method.
4. IN Requirements
4. IN Requirements
The interface immediately relevant to IN is that between the SPIRITS Client and SPIRITS Gateway (interface C). A typical message (which starts a SPIRITS service) looks like this:
The interface immediately relevant to IN is that between the SPIRITS Client and SPIRITS Gateway (interface C). A typical message (which starts a SPIRITS service) looks like this:
C -> G: <Event Notification>, <Parameter-List (DP)>
C -> G: <Event Notification>, <Parameter-List (DP)>
The relevant events correspond to the detection points (DPs) of the IN Basic Call State Model (BCSM). The <Parameter-List> is a function of a specific DP; it contains the parameters relevant to it. The following requirements apply:
The relevant events correspond to the detection points (DPs) of the IN Basic Call State Model (BCSM). The <Parameter-List> is a function of a specific DP; it contains the parameters relevant to it. The following requirements apply:
Faynberg, et al. Informational [Page 6] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg, et al. Informational [Page 6] RFC 3298 SPIRITS Protocol Requirements August 2002
1) The list of the DPs to be covered encompasses those defined in the
IN Capability Set 3 BCSM as well as those which relate to the
Wireless IN (WIN) specified by the IMT 2000 project in ITU-T.
1) The list of the DPs to be covered encompasses those defined in the IN Capability Set 3 BCSM as well as those which relate to the Wireless IN (WIN) specified by the IMT 2000 project in ITU-T.
2) Not all parameters associated with such DPs are needed by the
SPIRITS benchmark services, nor may all the parameters be needed
in SPIRITS. The selection of the relevant parameters is part of
the SPIRITS protocol definition.
2) Not all parameters associated with such DPs are needed by the SPIRITS benchmark services, nor may all the parameters be needed in SPIRITS. The selection of the relevant parameters is part of the SPIRITS protocol definition.
3) It is desirable to avoid semantic overload of protocol messages.
(One way to achieve that is to match each type of an event with a
message that corresponds to it.) As the SPIRITS protocol is
designed as a set of extensions to another (existing) protocol
with the defined message set, the syntax and semantics of the
extensions should be defined with this requirement in mind.
3) プロトコルメッセージの意味オーバーロードを避けるのは望ましいです。 (それを達成する1つの方法は出来事の各タイプをそれに対応するメッセージに合わせることです。) SPIRITSプロトコルが1セットの拡大として別の(存在)に設計されているように、定義されたメッセージセット、構文で議定書を作ってください。そうすれば、拡大の意味論は念頭でこの要件で定義されるべきです。
4) The ITU-T Recommendations use the abstract syntax notation (ASN.1)
to specify the semantics of the IN Application Protocol (INAP)
parameters, which are expected to be binary-encoded. Neither the
use of the ASN.1, nor the requirement for binary encoding are the
typical requirements for the IETF application protocols.
Recognizing that, provisions must be made for careful
specification of the conversion of the INAP parameters to text,
which must preserve their original semantics. The actual
conversion of the parameters is the function of the SPIRITS
Client.
4) ITU-T Recommendationsは、バイナリーによってコード化されていると予想されるIN Applicationプロトコル(INAP)パラメタの意味論を指定するのに、抽象構文記法(ASN.1)を使用します。 ASN.1の使用も2進のコード化のための要件もIETFアプリケーション・プロトコルのための典型的な要件ではありません。 それを認識して、INAPパラメタの変換の慎重な仕様のために条項をテキストにしなければなりません。(それは、それらのオリジナルの意味論を保存しなければなりません)。 パラメタの実際の変換はSPIRITS Clientの機能です。
In order to issue an initial query (or a notification) to service
control, a switch must have such a DP set. This can be done
statically via service management (this particular action should
be left to implementation and thus is considered outside of the
scope of SPIRITS Protocol) or dynamically--but only for the
purpose of a particular call--from the service control. In the
latter case, it is part of the SPIRITS (or PINT) protocol to
request the event notification from the service control. The SIP
specific event notification scheme [4] should be specifically
considered. This function can be performed by either the Spirits
Client or PINT Server, the distinction being further discussed in
the next section. Assuming that it is performed by the SPIRITS
Client, the relevant message should look like:
初期の質問(または、通知)をサービス制御に発行するために、スイッチで、そのようなDPを用意ができさせなければなりません。 サービス管理(この特定の動作は、実現に残されるべきであり、その結果、SPIRITSプロトコルの範囲の外で考えられる)を通してダイナミックに、しかし、単にサービス制御からの特定の呼び出しの目的のために静的にこれができます。 後者の場合では、サービス制御からイベント通知を要求するのは、SPIRITS(または、PINT)プロトコルの一部です。 SIPの特定のイベント通知計画[4]は明確に考えられるべきです。 Spirits ClientかPINT Server(次のセクションでさらに議論する区別)のどちらかがこの機能を実行できます。 それがSPIRITS Clientによって実行されると仮定する場合、関連メッセージに似るべきです:
G->C: SUBSCRIBE <Event> <Mode> <DP-specific parameters>,
G>C: 登録、<Event><Mode><DP特有のパラメタ>。
where <Event> refers to a particular DP; <Mode> determines whether
the Event Detection Point (EDP) is to be armed as EDP Request
(EDP-R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is
not foreseen because it would not provide any additional
capability for SPIRITS); and the <DP-specific parameters> is the
<Event>が特定のDPを呼ぶところ。 <モード>は、Event Detection Point(EDP)がEDP Request(EDP-R)、EDP Notification(EDP-N)、またはTDP-Rとして軍備されることになっているかどうか(少しの追加能力もSPIRITSに供給しないでしょう、したがって、TDP-Nの必要性は見通されません)決定します。 そして、<DP特有のパラメタ>はそうです。
Faynberg, et al. Informational [Page 7] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg、他 情報[7ページ]のRFC3298スピリッツは要件2002年8月に議定書を作ります。
list of the values of the parameters associated with the EDP (for
example, if the DP in question is O_No_Answer, then the value of
the appropriate timer should be included in the list). Note that
such a subscription may also originate at a) PINT Client or b)
SPIRITS Gateway, either of which may (but does not have to) have a
locally significant definition of the <Event>. In either case, it
is the function of the SPIRITS Client to translate the definition
of the Event into a particular DP (or set of DPs) when passing the
message to Service Control. To summarize, for the case when PINT
and SPIRITS events are defined in a way where they do not refer to
the BCSM DPs, it is the function of the SPIRITS Client to define a
mapping:
EDP(例えば、問題のDPがO_いいえ_Answerであるなら、適切なタイマの値はリストに含まれるべきである)に関連しているパラメタの値のリスト。 また、そのような購読がa)で由来するかもしれないことに注意してください。 PINT Clientかb) SPIRITSゲートウェイ。それのどちらかには、<Event>の局所的に重要な定義があるかもしれません(しかし、そうする必要はありません)。 どちらかの場合では、それはメッセージをService Controlに通過するとき特定のDP(または、DPsのセット)にEventの定義を翻訳するSPIRITS Clientの機能です。 PINTとSPIRITS出来事が彼らがBCSM DPsについて言及しない方法で定義されるときのケースのためにそれをまとめるのは、マッピングを定義するSPIRITS Clientの機能です:
Event -> DP List,
イベント->DPは記載します。
for each event for which the PSTN notification is needed.
PSTN通知が必要である各出来事のために。
The list of CS-3 DPs envisioned in SPIRITS is:
SPIRITSで思い描かれたCS-3 DPsのリストは以下の通りです。
- origination_attempt_authorized (the SPIRITS service can control
call attempts, (for example, to limit calls during specific
time periods)
- 創作_は認可された_を試みます。(サービスが制御できるSPIRITSは、試みと呼びます。(例えば特定の期間の限界呼び出しに)
- collected_information and analyzed_information (for SPIRITS
outgoing call screening)
- 集まっている_情報と分析_情報(SPIRITS発信電話選別のための)
- o_answer, o_term_seized, and t_answer (to release SPIRITS
resources after the call is complete and perform relevant OA&M
actions such as creating a record of attempts to reach a party
via various means like land-line phone, cell phone, SMS, or
paging.)
- o_答え、_が捕らえたo_用語、およびt_に答えます。(呼び出しが完全になった後にSPIRITSリソースを発表して、達する試みに関する記録を作成などなどの関連OAとM動作を実行するために、様々な手段を通したパーティーは地上通信線電話、携帯電話、SMS、またはページングが好きです。)
- o_no_answer, route_select_failure, and t_no_answer (to re-route
a call)
- ○ __答え、ルート_選んだ_の故障、およびt_いいえ_答えがありません。(呼び出しを別ルートで送る)
- o_called_party_busy (to re-route a call and for Internet Call
Waiting)
- o_は、_パーティー_が忙しいと言いました。(呼び出しとインターネットCall Waitingのために別ルートで送る)
- o_mid_call and t_mid_call (to assist a midcall action)
- o_の中間の_呼び出しとt_の中間の_呼び出し(midcall動作を促進する)
- o_abandon, o_disconnect, t_abandon, and t_disconnect (to
terminate a SPIRITS service and release the resources and
perform relevant OA&M actions such as creating a record of
attempts to reach a party via various means like land-line
phone, cell phone, SMS, or paging.)
- o_放棄、o_分離、t_放棄、およびt_は連絡を断ちます。(SPIRITSサービスを終えて、リソースを発表して、達する試みに関する記録を作成などなどの関連OAとM動作を実行するために、様々な手段を通したパーティーは地上通信線電話、携帯電話、SMS、またはページングが好きです。)
Faynberg, et al. Informational [Page 8] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg、他 情報[8ページ]のRFC3298スピリッツは要件2002年8月に議定書を作ります。
In addition, the following DPs are relevant to the present SPIRITS milestone services:
さらに、以下のDPsは現在のSPIRITS重大事件サービスに関連しています:
- termination_attempt_authorized
- _が認可した終了_試み
- facility_selected_and_available (could be used in SPIRITS
Internet Caller-ID)
- _利用可能な施設の選択された_と_(SPIRITSインターネット発信番号表示に使用できました)
- t_busy (for Internet Call Waiting and Call Forwarding).
- t_忙しいです(インターネットCall WaitingとCall Forwardingのための)。
5. Wireless-IN-related Requirements
5. 関連の無線電信要件
Wireless IN covers several types of "calls," which are neither circuit switched nor have an effect on circuit switched calls. For this reason, those are not considered in SPIRITS requirements. To further clarify this point, the types of "calls" not considered are:
無線のINはいくつかのタイプの「呼び出し」を含んでいて、どれで切り換えられなかったどちらのサーキットであるのも、サーキットへの効果を切り換えるかは呼びます。 この理由で、ものはSPIRITS要件で考えられません。 さらにこのポイントをはっきりさせるために、考えられなかった「呼び出し」のタイプは以下の通りです。
- USSD (Unstructured Supplementary Service Data)
- USSD(不統一な補っているサービスデータ)
- GPRS (General Packet Radio System)
- GPRS(汎用パケット無線システム)
- SMS (Short Message System)
- SMS(短いメッセージシステム)
The types of calls relevant to SPIRITS are as follows:
SPIRITSに関連している呼び出しのタイプは以下の通りです:
a) Voice Calls. In this case no new DP is needed since CAMEL DPs
are included in CS2. The only special case is "Not Reachable"
(when it is detected that the mobile user is out of coverage or
has switched off), which is mapped as a special cause in the
Busy DP. Since the Busy DP parameters would be received (if a
SPIRITS service has subscribed to Busy), it would be possible
to distinguish a "busy" from a "not reachable" situation.
a) 声は呼びます。 CAMEL DPsがCS2に含まれているので、この場合、どんな新しいDPも必要ではありません。 唯一の特別なケースが「届いていない」、(それが検出される、可動のユーザは、適用範囲の外にいるか、または下に切り替わりました)、特別な原因としてBusy DPで写像される。 Busy DPパラメタを受け取るでしょう(SPIRITSサービスがBusyに加入したなら)、したがって、「届いていない」状況と「忙しさ」を区別するのは可能でしょう。
This translates into the requirement that one of the parameters
in the Event Notification message (from SPIRITS Client to
SPIRITS Gateway, over the interface C) denotes the "cause" for
the Busy Detection Point.
これはEvent Notificationメッセージ(インタフェースCの上のSPIRITSゲートウェイへのSPIRITS Clientからの)のパラメタの1つがBusy Detection Pointの「原因」を指示するという要件に翻訳されます。
Another aspect of difference, when compared to PSTN, is setting
of static DPs. In CAMEL networks, this is done in the Home
Location Register (HLR) (and copied to the VLR during location
update). It is important to note this difference, even though
it has no effect on SPIRITS protocol.
PSTNと比べると、違いのもう一つの側面は静的なDPsの設定です。 CAMELネットワークでは、ホームLocation Register(HLR)(そして、位置のアップデートの間、VLRにコピーされる)でこれをします。 SPIRITSへの効果は全くそれで議定書を作りませんが、この違いに注意するのは重要です。
Faynberg, et al. Informational [Page 9] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg、他 情報[9ページ]のRFC3298スピリッツは要件2002年8月に議定書を作ります。
b) Mobility Management events. This allows a SPIRITS server to be
notified of changes of location of a mobile user. The events
would only be applicable to mobile users reachable through a
Circuit-Switched network. To provide for this function, the
subscription marks must be set in the subscriber's HLR. This
is equivalent to setting TDPs in the SSP. In this case, the
marks in the HLR (which are copied to the Visitor Location
Register [VLR] on location update) are not mapped into Trigger
Detection Points.
b) 移動性Management出来事。 これは、SPIRITSサーバが可動のユーザの位置の変化について通知されるのを許容します。 出来事は単にCircuit-交換網を通して届いている可動のユーザに適切でしょう。 この機能に備えるために、加入者のHLRに購読マークを設定しなければなりません。 これはSSPにTDPsをはめ込むのに同等です。 この場合、HLR(位置のアップデートのときにVisitor Location Register[VLR]にコピーされる)でのマークはTrigger Detection Pointsに写像されません。
As with TDP setting, this is outside of the scope of SPIRITS
protocol.
TDP設定のように、これはSPIRITSプロトコルの範囲の外にあります。
In order to support this function in SPIRITS, the SPIRITS
protocol should be able to map the CAMEL specific operations
into events notification to the SPIRITS client. Since the SCP
receives the information about the mobility state, this
involves the C interface. (This is just an extension of the DP
notification mechanism from the SPIRITS client to the SPIRITS
gateway).
SPIRITSでこの機能をサポートするために、SPIRITSプロトコルはSPIRITSクライアントへのイベント通知にCAMELの特定の操作を写像できるべきです。 SCPが移動性状態に関して知らせを聞くので、これはCインタフェースにかかわります。 (SPIRITSクライアントからSPIRITSゲートウェイまでこれはただDP通知メカニズムの拡大です。)
The events (which are not DP-related) which need notifications
are:
通知を必要とする出来事(DP関連でない)は以下の通りです。
- Location Update in the same VLR service area
- 同じVLRサービスエリアの位置のUpdate
- Location Update in another VLR service area
- 別のVLRサービスエリアの位置のUpdate
- IMSI attach
- IMSIは付きます。
- MS initiated IMSI detach
- MSの開始しているIMSIは取り外します。
- Network initiated IMSI detach.
- 開始しているIMSIが取り外すネットワーク。
With this mechanism, the SPIRITS services can use the user-
profile-based location information. For example, the Internet
Call Waiting service can re-direct the call to a mobile phone.
このメカニズムと共に、SPIRITSサービスはユーザのプロフィールベースの位置情報を使用できます。 例えば、インターネットCall Waitingサービスは携帯電話に呼び出しを向け直すことができます。
c) Supplementary Services Notification.
c) 補っているサービス通知。
This mechanism makes a SPIRITS server aware of a subscriber
having invoked one of the following supplementary services:
Explicit Call Transfer, Call Deflection, Call Completion on
Busy Subscriber, or Multi-Party.
このメカニズムで、SPIRITSサーバは加入者には以下の補っているサービスの呼び出された1つがあるのを意識するようになります: 明白な呼び出し転送、呼び出し偏向、忙しい加入者、またはマルチパーティにおける呼び出し完成。
Faynberg, et al. Informational [Page 10] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg、他 情報[10ページ]のRFC3298スピリッツは要件2002年8月に議定書を作ります。
6. PINT-related Requirements
6. パイント関連の要件
Before a SPIRITS service can be invoked, the relevant IP Host must be registered. Thus, Registration is an essential service, which is initiated from the IP side. The registration information is ultimately used by the PSTN to authenticate the subscriber.
SPIRITSサービスを呼び出すことができる前に、関連IP Hostを登録しなければなりません。 したがって、Registrationは重要負荷です。(その重要負荷はIP側から開始されます)。 レジスト情報は、結局、加入者を認証するのにPSTNによって使用されます。
Depending on the model, this can be done in two ways with the present architecture:
モデルに頼っていて、現在の構造で2つの方法でこれができます:
1) The PINT Client issues the appropriate Register message over the interface A, which is then passed by the PINT server to the SPIRITS Gateway and SPIRITS Client:
1) PINT ClientはインタフェースAの上で適切なRegisterメッセージを発行します:次に、インタフェースはPINTサーバによってSPIRITSゲートウェイとSPIRITS Clientに通過されます。
PINT C.: -- Register --> PINT S. [--> SPIRITS Gateway --> SPIRITS C.]. In this case the SPIRITS Client (co-located with the service control) is responsible for record keeping and the authentication.
パイントC.: -- 登録してください-->パイントS.[-->はゲートウェイに生気を与えさせます-->スピリッツC.]。 この場合、SPIRITS Client(サービス制御で共同見つけられている)は記録的なキープと認証に責任があります。
2) The PINT Client issues the appropriate Register message to the PINT Server, which then passes this information to the PSTN service control "by magic".
2) PINT Clientは「魔法」によるPSTNサービス制御へのこの情報がその時終わるPINT Serverに適切なRegisterメッセージを発行します。
The second model is much easier to handle, because it involves only
one relevant interface ("A"); however it assumes no interworking
between PINT and SPIRITS except that the SPIRITS Client finds "by
magic" that a friendly and expecting IP Host is alive and well.
ある関連インタフェース(「A」)だけにかかわるので、第2代モデルははるかに扱いやすいです。 しかしながら、SPIRITS Clientが、好意的でおめでたの予定のIP Hostが健在であることが「魔法」でわかる以外に、それはPINTとSPIRITSの間の織り込むことを仮定しません。
Finally, in the event PINT is not implemented, the SIP SUBSCRIBE mechanism can be used.
最終的に、出来事では、PINTを実行しないで、SIP SUBSCRIBEメカニズムを使用できます。
As noted in the previous section, the existing SUBSCRIBE/NOTIFY PINT building blocks [3] must be extended for their use in SPIRITS for the purposes of setting DPs/getting DP event notifications. (A more general SIP mechanism for the same PINT-introduced block is described in [4]; it provides the necessary mechanism for specifying relevant events.) Conversely, the same building blocks for the functional capabilities can be used in both PINT and SPIRITS protocols. Note, however, that in SPIRITS the PSTN notification may arrive without a particular subscription to an event (in the case of a statically set DP).
登録、前項、既存/NOTIFY PINTでSPIRITSにおける、彼らのDPs/得るDPイベント通知を設定する目的の使用のためにブロック[3]を広げなければならないことに注意するので。 (より一般的なSIPメカニズムは[4]に同じPINTによって導入されたブロックに説明されます; それは関連出来事を指定するのに必要なメカニズムを提供します。) 逆に、PINTとSPIRITSプロトコルの両方で機能的な能力のための同じブロックを使用できます。 しかしながら、SPIRITSに、PSTN通知が出来事(静的に設定されたDPの場合における)の特定の購読なしで到着するかもしれないことに注意してください。
7. Follow-up on Event Notifications
7. イベント通知のフォローアップ
The requirements of this section are neither PINT-specific, nor IN- specific; their role is to outline the remaining element necessary for the delivery of the SPIRITS service, which is the reaction to the notification received.
このセクションの要件は、PINT特有でなくて、またIN特有ではありません。 それらの役割がSPIRITSサービスの配送に必要な残っている要素について概説することであり、どれが通知への反応であるかは受信されました。
Faynberg, et al. Informational [Page 11] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg、他 情報[11ページ]のRFC3298スピリッツは要件2002年8月に議定書を作ります。
In a particular scenario where:
特定のシナリオ、どこ:
a) The IP subscriber registers a SPIRITS service;
a) IP加入者はSPIRITSサービスを登録します。
b) A call triggering the SPIRITS service is received (and
notification is sent); and
b) SPIRITSサービスの引き金となる呼び出しは受け取られています(通知を送ります)。 そして
c) The call disposition is performed by the end user, the
signalling flow is demonstrated in Figure 2.
c) 呼び出し気質はエンドユーザによって実行されて、合図流動は図2に示されます。
|----> Registration ----->|
SPIRITS |<-- Event Notification <-- | SPIRITS
Gateway |---> Call Disposition ---->| Client
| |
|
|
|
V
Service Control
|
|
V
SSP
|---->登録----->| スピリッツ| <-- イベント通知<--| スピリッツゲートウェイ|--->呼び出し気質---->| クライアント| | | | | Vサービス制御| | V SSP
Figure 2: Sequence of SPIRITS actions
図2: SPIRITS動作の系列
One of the following actions is required by benchmark services:
以下の動作の1つがベンチマークサービスで必要です:
a) Accept the incoming call
a) かかってきた電話を受け入れてください。
b) Reject the incoming call
b) かかってきた電話を拒絶してください。
c) Redirect the incoming call
c) かかってきた電話を向け直してください。
d) Accept the call via VoIP (this particular item is outside of
the scope of SPIRITS WG).
d) VoIPを通して呼び出しを受け入れてください(この特定の項目はSPIRITS WGの範囲の外にあります)。
Accordingly, the SPIRITS protocol should define the following message types:
それに従って、SPIRITSプロトコルは以下のメッセージタイプを定義するべきです:
a) S->G: <Accept Call>
a) S>G: <は呼び出し>を受け入れます。
b) S->G: <[Reject Call],[Cause]>
b) S>G: <[呼び出しを拒絶します][原因]>。
c) S->G: <[Redirect Call],[Redirection Destination]>
c) S>G: <[再直接の呼び出し][リダイレクションの目的地] >。
Faynberg, et al. Informational [Page 12] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg、他 情報[12ページ]のRFC3298スピリッツは要件2002年8月に議定書を作ります。
8. Methodology
8. 方法論
To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set of messages), the PSTN events associated with each detection point of the Basic Call State Model should be examined. To date, the CS-3 BSCM has the richest set of DPs, although not all switching exchanges have implemented it.
MINIMUM SPIRITSプロトコルボキャブラリー(すなわち、メッセージのセット)を決定するために、Basic Call州Modelのそれぞれの検出先に関連しているPSTN出来事は調べられるべきです。 これまで、CS-3 BSCMには、すべて切り替わっていない交換はそれを実行しましたが、DPsの最も豊かなセットがあります。
To determine the MINIMUM information available to the SPIRITS client (this information is to be carried by the SPIRITS protocol from SPIRITS client to SPIRITS server), each DP-specific information elements needs to be examined.
SPIRITSクライアント(この情報はSPIRITSプロトコルによってSPIRITSクライアントからSPIRITSサーバまで運ばれることである)にとって、利用可能なMINIMUM情報、各DP-特殊情報を決定するために、要素は、調べられる必要があります。
Parameters should be event-specific, the following generic types of parameters are expected to be mandatory:
パラメタがイベント特有であるべきである、以下の一般的なタイプのパラメタが義務的であると予想されます:
- timer (for no answer)
- タイマ(答えでない)
- midcall control info (for mid_call)
- midcallコントロールインフォメーション(中間の_に関して、電話をしてください)
- number of digits (for collected_information)
- ケタの数(集まっている_情報のための)
9. Security Considerations
9. セキュリティ問題
Overall, the basic aspects of security apply to SPIRITS protocol:
全体的に見て、セキュリティの基本的な局面はSPIRITSプロトコルに適用されます:
- Authentication:
In the communications between the SPIRITS Client and SPIRITS
Gateway as well as the SPIRITS Gateway and SPIRITS Server, it is
required that the information be sent between known and trusted
partners.
- 認証: SPIRITSゲートウェイとSPIRITS Serverと同様にSPIRITS ClientとSPIRITSゲートウェイとのコミュニケーションでは、情報が知られていて信じられたパートナーの間に送られるのが必要です。
- Integrity:
It is a requirement that no exchanged data be modified in transit.
- 保全: それは交換されたデータが全くトランジットで変更されないという要件です。
- Confidentiality:
It is a requirement that any private user information or
confidential network data be protected by the protocol (typically
through encryption, for which the protocol should allow a choice
in the algorithm selection.
- 秘密性: (通常暗号化で。それはどんな個人的なユーザー情報や秘密のネットワークデータもプロトコルによって保護されるという要件です。(プロトコルはそれのためにアルゴリズム選択における選択を許すべきです)。
- Availability:
It is a requirement that the communicating endpoints remain in
service for authorized use only.
- 有用性: それは交信終点が認可された使用だけに使用中のままで残っているという要件です。
Faynberg, et al. Informational [Page 13] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg、他 情報[13ページ]のRFC3298スピリッツは要件2002年8月に議定書を作ります。
In addition, the protocol should support non-repudiation for those control messages pertinent to charging the PSTN subscriber.
さらに、プロトコルはPSTN加入者を請求するのに適切なそれらのコントロールメッセージのための非拒否を支持するべきです。
As Figure 1 demonstrates, there are two distinct communications interfaces, B and C. The B interface is, in general, across the public Internet and is thus most vulnerable to security attacks resulting in theft or denial of service. The C interface, on the other hand is likely to be implemented across a service providers intranet, where the security measures should be applied at the discretion of the service provider. Even then, because at least one IP host (the PINT gateway) is connected to the Internet, special measures (e.g., installation of firewalls, although this particular measure alone may be insufficient) need to be taken to protect the interface C and the rest of the network from security attacks.
図1が示すように、2つの異なったコミュニケーションインタフェースがあります、B、C. Bインタフェースは一般に、公共のインターネットのむこうにあって、その結果、サービスの窃盗か否定をもたらすセキュリティー攻撃に最も傷つきやすいです。 他方では、Cインタフェースはサービスプロバイダーイントラネットの向こう側に実行されそうです。そこでは、安全策がサービスプロバイダーの裁量で適用されるべきです。 少なくとも1人のIPホスト(PINTゲートウェイ)がインターネットに接続されるので、その時でさえ、特別な測定(例えば、ファイアウォールのインストール、これですが、特定の程度だけが不十分であるかもしれない)は、セキュリティー攻撃からインタフェースCとネットワークの残りを保護するために取られる必要があります。
The assumption that the PINT Client and SPIRITS server are co- located, dictates that the security considerations for the A and B interfaces are exactly same. Detailed security requirements and solutions for interface A (and, consequently, B) can be found in RFC 2848 [3].
PINT ClientとSPIRITSサーバが共同見つけられているという仮定、AとBのためのセキュリティ問題が連結する命令はまさに同じです。 RFC2848[3]でインタフェースA(その結果B)の詳細なセキュリティ要件と解決策を見つけることができます。
Possible security attacks can result in both theft and denial of services. In addition, such attacks may violate the privacy of a PSTN subscriber. For example, with Internet Call Waiting, a fraudulent registration (or a manipulation of integrity of a valid registration) may force a network operator to provide to an authorized party a full log of attempted telephone calls (accompanied by the identification of callers). Furthermore, the calls may be diverted to wrong recipients (who may further defraud the unsuspecting calling party). In this case, the calling party is using only the PSTN and thus expecting the security of communications that are typical of the PSTN. The PSTN service providers may be liable for the consequences of establishing wrong connections. In addition, the PSTN service providers may be liable for inadvertent divulging of the private information of the subscriber.
可能なセキュリティー攻撃は窃盗とサービスの否定の両方をもたらすことができます。 さらに、そのような攻撃はPSTN加入者のプライバシーに違反するかもしれません。 例えば、インターネットCall Waitingと共に、ネットワーク・オペレータは詐偽登録(または、有効な登録の保全の操作)によって試みられた通話(訪問者の識別で、伴われる)の完全なログを認可されたパーティーにやむを得ず提供するかもしれません。 その上、呼び出しは間違った受取人(さらに疑わない起呼側をだますかもしれません)に紛らされるかもしれません。 この場合、起呼側は、PSTNだけを使用して、その結果、PSTNの典型であるコミュニケーションのセキュリティを予想しています。 PSTNサービスプロバイダーは間違った接続を確立する結果に責任があるかもしれません。 さらに、PSTNサービスプロバイダーは加入者の個人情報を不注意な明かすのに責任があるかもしれません。
The service and network providers need to review the possibilities of the security attacks and prepare the means of protection from them. Some of this may be achieved by using the means outside of those provided by the protocol itself. For example, administrative information (such as statistics collected by PINT MIB or SPIRITS MIB) can help in determining violations and thwarting them. As far as the protocol is concerned, it must provide the means for authenticating a subscriber as well as a session. It must also provide a capability to carry encrypted information in its body.
サービスとネットワーク内の提供者は、セキュリティー攻撃の可能性を見直して、それらから保護の手段を準備する必要があります。 この或るものは、プロトコル自体によって提供されたものの外で手段を使用することによって、達成されるかもしれません。 例えば、管理情報(PINT MIBかSPIRITS MIBによって集められた統計などの)は違反を決定して、それらを阻むのを手伝うことができます。 プロトコルに関する限り、それはセッションと同様に加入者を認証するための手段を提供しなければなりません。 また、それはボディーでコード化された情報を運ぶ能力を提供しなければなりません。
Faynberg, et al. Informational [Page 14] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg、他 情報[14ページ]のRFC3298スピリッツは要件2002年8月に議定書を作ります。
10. Acknowledgements
10. 承認
The authors are grateful to all participants in the SPIRITS group for the discussion that has been shaping this work. Many thanks go to Jorgen Bjorkner, Alec Brusilovsky, Jim Buller, Lawrence Conroy, Soren Nyckelgard, and John Voelker for their incisive comments. Special thanks are to Vijay Gurbani, Dave Hewins, and Kumar Vemuri, whose careful, detailed reviews of several versions of this document have been particularly helpful in improving its quality.
作者はSPIRITSグループのすべての関係者にこの仕事を形成している議論に感謝しています。 彼らの鋭いコメントにおいてヨルゲンBjorkner、アレクBrusilovsky、ジムブラー川、ローレンス・コンロイ、ゾーレンNyckelgard、およびジョンVoelkerに許可していた状態で、ありがとうございます。 特別な感謝はビジェイGurbani、デーヴHewinsへのそうであり、クマーはVemuriです。このドキュメントのいくつかのバージョンのその慎重で、詳細なレビューは品質を改良する際に特に役立っています。
11. References
11. 参照
[1] Slutsman, L., Faynberg, I., Lu, H. and M. Weissman, "The Spirits
Architecture", RFC 3136, June 2001.
[1]SlutsmanとL.とFaynbergとI.とLuとH.とM.ワイズマン、「スピリッツ構造」、RFC3136、2001年6月。
[2] Lu, H. (Editor), Faynberg, I., Voelker, J., Weissman, M., Zhang,
W., Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S.,
Nyckelgard, S., Yoakum, J. and L. Robart, "Pre-SPIRITS
Implementations of PSTN-Initiated Services", RFC 2995, November
2000.
[2]Lu、H.(エディタ)、Faynberg、I.、Voelker、J.、ワイズマン、M.、チャン、W.、Rhim、S.、ファン、J.前、S.(Moeenuddin、S.、Hadvani、S.、Nyckelgard、S.、Yoakum、J.、およびL.Robart)は「PSTNによって開始されたサービスの実現にあらかじめ生気を与えます」、RFC2995、11月2000
[3] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions
to SIP and SDP for IP Access to Telephone Call Services", RFC
2848, June 2000.
[3] Petrack、S.、およびL.コンロイ、「パイントサービスは議定書を作ります」。 「通話サービスへのIPアクセスのための一口とSDPへの拡大」、RFC2848、2000年6月。
[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[4] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[5]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[6]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[7] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[7] ハンドレー、M.、学生、E.、Schulzrinne、H.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[8] Handley, M. and V. Jacobsen, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[8] ハンドレー、M.、およびV.ジェイコブセン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
Faynberg, et al. Informational [Page 15] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg、他 情報[15ページ]のRFC3298スピリッツは要件2002年8月に議定書を作ります。
12. Authors' Addresses
12. 作者のアドレス
Lev Slutsman AT&T Laboratories 200 Laurel Ave. Middletown, New Jersey, 07748
レフSlutsman AT&T研究所200ローレルAve。 ミドルタウン、ニュージャージー 07748
Phone: (732) 420-3752 EMail: lslutsman@att.com
以下に電話をしてください。 (732) 420-3752 メールしてください: lslutsman@att.com
Igor Faynberg Bell Labs/Lucent Technologies Room 4D-601A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733
イーゴリFaynbergベル研究所/ルーセントテクノロジーズ余地の4D-601A、101Crawfordsが道路Holmdel、ニュージャージー 07733を追い詰めます。
Phone: (732) 949-0137 EMail: faynberg@lucent.com
以下に電話をしてください。 (732) 949-0137 メールしてください: faynberg@lucent.com
Jorge Gato Vodaphone Avda de Europa, 1. 28108 Alcobendas (Madrid). Spain
1歳のホルヘ・GatoボーダーフォンAvda deエウロペ。 28108 アルコベンダス(マドリード)。 スペイン
Phone: +34 607 13 31 10 Fax: +34 607 13 30 57 EMail: jgato@airtel.es
以下に電話をしてください。 +34 607 13 31 10、Fax: +34 607 13 30 57はメールされます: jgato@airtel.es
Hui-Lan Lu Bell Labs/Lucent Technologies Room 4C-607A, 101 Crawfords Corner Road Holmdel, New Jersey, 07733
ホイ-ランLuベル研究所/ルーセントテクノロジーズ余地の4C-607A、101Crawfordsが道路Holmdel、ニュージャージー 07733を追い詰めます。
Phone: (732) 949-0321 EMail: huilanlu@lucent.com
以下に電話をしてください。 (732) 949-0321 メールしてください: huilanlu@lucent.com
Faynberg, et al. Informational [Page 16] RFC 3298 SPIRITS Protocol Requirements August 2002
Faynberg、他 情報[16ページ]のRFC3298スピリッツは要件2002年8月に議定書を作ります。
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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 assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Faynberg, et al. Informational [Page 17]
Faynberg、他 情報[17ページ]
一覧
スポンサーリンク
