RFC2848 日本語訳
2848 The PINT Service Protocol: Extensions to SIP and SDP for IPAccess to Telephone Call Services. S. Petrack, L. Conroy. June 2000. (Format: TXT=168851 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Petrack
Request for Comments: 2848 MetaTel
Category: Standards Track L. Conroy
Siemens Roke Manor Research
June 2000
Petrackがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2848年のMetaTelカテゴリ: 標準化過程L.コンロイジーメンスRoke荘園研究2000年6月
The PINT Service Protocol:
Extensions to SIP and SDP for IP Access to Telephone Call Services
パイントサービスプロトコル: 通話サービスへのIPアクセスのためのちびちび飲む拡大とSDP
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols.
このドキュメントはPINT Serviceプロトコル1.0の仕様を含んでいます。(プロトコルは、IPネットワークからある電話サービスを呼び出すためにプロトコルを定義します)。 ファックスを送って、受け止めて、電話の上に内容を受け取って、これらのサービスは、基本的な電話をするのを含んでいます。 プロトコルは1セットの増進と追加としてSIP2.0とSDPプロトコルに指定されます。
Table of Contents
目次
1. Introduction ................................................. 4
1.1 Glossary .................................................... 6
2. PINT Milestone Services ...................................... 6
2.1 Request to Call ............................................. 7
2.2 Request to Fax Content ...................................... 7
2.3 Request to Speak/Send/Play Content .......................... 7
2.4 Relation between PINT milestone services and traditional
telephone services .......................................... 7
3. PINT Functional and Protocol Architecture .................... 8
3.1. PINT Functional Architecture ............................... 8
3.2. PINT Protocol Architecture ................................. 9
3.2.1. SDP operation in PINT .................................... 10
3.2.2. SIP Operation in PINT .................................... 11
3.3. REQUIRED and OPTIONAL elements for PINT compliance ......... 11
3.4. PINT Extensions to SDP 2.0 ................................. 12
1. 序論… 4 1.1用語集… 6 2. パイント重大事件サービス… 6 2.1 電話をするよう要求します。 7 2.2 ファックスで内容を送るよう要求します。 7 2.3 内容を話すか、送る、またはプレーするよう要求します。 7 PINT重大事件サービスと伝統的な電話サービスとの2.4関係… 7 3. パイント機能的、そして、プロトコルアーキテクチャ… 8 3.1. パイント機能的な建築… 8 3.2. パイントプロトコルアーキテクチャ… 9 3.2.1. PINTでのSDP操作… 10 3.2.2. パイントにおける操作をちびちび飲んでください… 11 3.3. PINTコンプライアンスのためのREQUIREDとOPTIONAL要素… 11 3.4. SDP2.0へのパイント拡大… 12
Petrack & Conroy Standards Track [Page 1] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[1ページ]。
3.4.1. Network Type "TN" and Address Type "RFC2543" ............. 12
3.4.2. Support for Data Objects within PINT ..................... 13
3.4.2.1. Use of fmtp attributes in PINT requests ................ 15
3.4.2.2. Support for Remote Data Object References in PINT ...... 16
3.4.2.3. Support for GSTN-based Data Objects in PINT ............ 17
3.4.2.4. Session Description support for included Data Objects .. 18
3.4.3. Attribute Tags to pass information into the Telephone
Network .................................................. 19
3.4.3.1. The phone-context attribute ............................ 20
3.4.3.2. Presentation Restriction attribute ..................... 22
3.4.3.3. ITU-T CalledPartyAddress attributes parameters ......... 23
3.4.4. The "require" attribute .................................. 24
3.5. PINT Extensions to SIP 2.0 ................................. 25
3.5.1. Multi-part MIME (sending data along with SIP request) .... 25
3.5.2. Warning header ........................................... 27
3.5.3. Mechanism to register interest in the disposition of a PINT
service, and to receive indications on that disposition .. 27
3.5.3.1. Opening a monitoring session with a SUBSCRIBE request .. 28
3.5.3.2. Sending Status Indications with a NOTIFY request ....... 30
3.5.3.3. Closing a monitoring session with an UNSUBSCRIBE request 30
3.5.3.4. Timing of SUBSCRIBE requests ........................... 31
3.5.4. The "Require:" header for PINT ........................... 32
3.5.5. PINT URLs within PINT requests ........................... 32
3.5.5.1. PINT URLS within Request-URIs .......................... 33
3.5.6. Telephony Network Parameters within PINT URLs ............ 33
3.5.7. REGISTER requests within PINT ............................ 34
3.5.8. BYE Requests in PINT ..................................... 35
4. Examples of PINT Requests and Responses ...................... 37
4.1. A request to a call center from an anonymous user to receive
a phone call ............................................... 37
4.2. A request from a non anonymous customer (John Jones) to
receive a phone call from a particular sales agent
(Mary James) ............................................... 37
4.3. A request to get a fax back ................................ 38
4.4. A request to have information read out over the phone ...... 39
4.5. A request to send an included text page to a friend's pager. 39
4.6. A request to send an image as a fax to phone number
+972-9-956-1867 ............................................ 40
4.7. A request to read out over the phone two pieces of content
in sequence ................................................ 41
4.8. Request for the prices for ISDN to be sent to my fax
machine .................................................... 42
4.9. Request for a callback ..................................... 42
4.10.Sending a set of information in response to an enquiry ..... 43
4.11.Sportsline "headlines" message sent to your phone/fax/pager 44
4.12.Automatically giving someone a fax copy of your phone bill . 45
5. Security Considerations ...................................... 46
5.1. Basic Principles for PINT Use ............................. 46
3.4.1. タイプ「テネシー」とアドレスタイプ"RFC2543"をネットワークでつないでください… 12 3.4.2. データには、パイントの中でオブジェクトを支えてください… 13 3.4.2.1. PINT要求におけるfmtp属性の使用… 15 3.4.2.2. リモートデータ・オブジェクトには、パイントにおける参照をサポートしてください… 16 3.4.2.3. GSTNベースのデータには、パイントでオブジェクトを支えてください… 17 3.4.2.4. 含まれているData Objectsのセッション記述サポート。 18 3.4.3. Tagsを結果と考えて、情報をTelephone Networkに通過してください… 19 3.4.3.1. 電話文脈属性… 20 3.4.3.2. プレゼンテーションRestriction属性… 22 3.4.3.3. ITU-T CalledPartyAddress属性パラメタ… 23 3.4.4. 「必要」属性… 24 3.5. 一口2.0へのパイント拡大… 25 3.5.1. 複合MIME(SIPに伴うデータが要求する発信)… 25 3.5.2. 警告ヘッダー… 27 3.5.3. PINTサービスの気質への関心を示して、その気質で指摘を受けるメカニズム。 27 3.5.3.1. 登録とのモニターしているセッションが要求する始まり。 28 3.5.3.2. NOTIFY要求と共にStatus Indicationsを送ります… 30 3.5.3.3. 登録削除とのモニターしているセッションを終えると、30は要求されます。3.5 .3 .4。 調節する、登録、要求… 31 3.5.4. 「以下を必要としてください」 PINTのためのヘッダー… 32 3.5.5. PINT要求の中のPINT URL… 32 3.5.5.1. 要求URIの中のパイントURLS… 33 3.5.6. パイントURLの中の電話回路パラメータ… 33 3.5.7. PINTの中のREGISTER要求… 34 3.5.8. パイントにおけるさようなら要求… 35 4. パイント要求と応答に関する例… 37 4.1. 電話を受ける匿名のユーザからのコールセンターへの要求… 37 4.2. 特定の販売代理店(メアリ・ジェームス)から電話を受ける非匿名の顧客(ジョン・ジョーンズ)からの要求… 37 4.3. ファックスを取り戻すという要求… 38 4.4. 情報を持っているという要求は電話による外で読みました… 39 4.5. 含まれているテキストページを友人のポケットベルに送るという要求。 39 4.6. ファックスとして電話番号+972-9-956-1867にイメージを送るという要求… 40 4.7. 電話で連続して内容の2つの断片を読みだすという要求… 41 4.8. 価格で、ISDNが私のファックス装置に送られるよう要求します。 42 4.9. コールバックのために、要求します。 42 4.10. 調査に対応して1セットの情報を送ります… 43 4.11. Sportsline「見出し」メッセージで、44 4.12.Automaticallyはあなたの電話/ファックス/ポケットベルにあなたの電話代請求書. 45 5のファックスコピーをだれかに与えました。 セキュリティ問題… 46 5.1. パイント使用のための基本的なプリンシプルズ… 46
Petrack & Conroy Standards Track [Page 2] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[2ページ]。
5.1.1. Responsibility for service requests ..................... 46
5.1.2. Authority to make requests .............................. 47
5.1.3. Privacy ................................................. 47
5.1.4. Privacy Implications of SUBSCRIBE/NOTIFY ................ 48
5.2. Registration Procedures ................................... 49
5.3. Security mechanisms and implications on PINT service ...... 50
5.4. Summary of Security Implications .......................... 52
6. Deployment considerations and the Relationship PINT to I.N.
(Informative) ................................................ 54
6.1. Web Front End to PINT Infrastructure ....................... 54
6.2. Redirects to Multiple Gateways ............................. 54
6.3. Competing PINT Gateways REGISTERing to offer the same
service .................................................... 55
6.4. Limitations on Available Information and Request Timing for
SUBSCRIBE .................................................. 56
6.5. Parameters needed for invoking traditional GSTN Services
within PINT................................................. 58
6.5.1. Service Identifier ....................................... 58
6.5.2. A and B parties .......................................... 58
6.5.3. Other Service Parameters ................................. 59
6.5.4. Service Parameter Summary ................................ 59
6.6. Parameter Mapping to PINT Extensions........................ 60
7. References ................................................... 62
8. Acknowledgements ............................................. 64
Appendix A: Collected ABNF for PINT Extensions .................. 65
Appendix B: IANA Considerations ................................. 69
Authors' Addresses .............................................. 72
Full Copyright Statement ........................................ 73
5.1.1. サービスのリクエストへの責任… 46 5.1.2. 要求をする権威… 47 5.1.3. プライバシー… 47 5.1.4. プライバシー含意、申し込むか、または通知してください… 48 5.2. 登録手順… 49 5.3. PINTサービスでのセキュリティー対策と含意… 50 5.4. セキュリティ含意の概要… 52 6. I.N.(有益な)への展開問題とRelationship PINT… 54 6.1. パイントインフラストラクチャへのウェブフロントエンド… 54 6.2. 複数のゲートウェイに向け直します。 54 6.3. 同じサービスを提供する競争しているPINT Gateways REGISTERing… 55 6.4. 入手可能な情報における制限と要求タイミング、登録… 56 6.5. PINTの中に伝統的なGSTN Servicesを呼び出すのに必要であるパラメタ… 58 6.5.1. 識別子を修理してください… 58 6.5.2. AとBパーティー… 58 6.5.3. 他のサービスパラメタ… 59 6.5.4. パラメタ概要を修理してください… 59 6.6. パイント拡大へのパラメタマッピング… 60 7. 参照… 62 8. 承認… 64 付録A: パイント拡大のためのABNFを集めます… 65 付録B: IANA問題… 69人の作者のアドレス… 72 完全な著作権宣言文… 73
Petrack & Conroy Standards Track [Page 3] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[3ページ]。
1. Introduction
1. 序論
The desire to invoke certain telephone call services from the Internet has been identified by many different groups (users, public and private network operators, call center service providers, equipment vendors, see [7]). The generic scenario is as follows (when the invocation is successful):
インターネットからある通話サービスを呼び出す願望は多くの異なったグループによって特定されました。(ユーザ(設備ベンダーのコールセンターサービスプロバイダーの公共の、そして、個人的なネットワーク・オペレータ)は[7])を見ます。 ジェネリックシナリオは以下の通りです(実施がうまくいっているとき):
1. an IP host sends a request to a server on an IP network;
2. the server relays the request into a telephone network;
3. the telephone network performs the requested call service.
1. IPホストはIPネットワークで要求をサーバに送ります。 2. サーバは電話網に要求をリレーします。 3. 電話網は要求された呼び出しサービスを実行します。
As examples, consider a user who wishes to have a callback placed to his/her telephone. It may be that a customer wants someone in the support department of some business to call them back. Similarly, a user may want to hear some announcement of a weather warning sent from a remote automatic weather service in the event of a storm.
例と、その人の電話にコールバックを置いて頂きたいユーザを考えてください。 多分、顧客は、何らかのビジネスのサポート部のだれかにそれらに電話し直して欲しいです。 同様に、ユーザは、気象警報の何らかの発表が嵐の場合、リモート自動天気測候事業から送られるのを聞きたがっているかもしれません。
We use the term "PSTN/Internet Interworking (PINT) Service" to denote such a complete transaction, starting with the sending of a request from an IP client and including the telephone call itself. PINT services are distinguished by the fact that they always involve two separate networks:
私たちはそのような完全なトランザクションを指示するのに「(パイント)がサービスであると織り込むPSTN/インターネット」という用語を使用します、IPクライアントからの要求の発信から始めて、通話自体を含んでいて。 いつも2つの別々のネットワークにかかわるという事実によってPINTサービスは区別されます:
an IP network to request the placement of a call, and the Global
Switched Telephone Network (GSTN) to execute the actual call. It
is understood that Intelligent Network systems, private PBXs,
cellular phone networks, and the ISDN can all be used to deliver
PINT services. Also, the request for service might come from
within a private IP network that is disconnected from the whole
Internet.
実際の呼び出しを実行するよう呼び出しのプレースメント、およびGlobal Switched Telephone Network(GSTN)に要求するIPネットワーク。 サービスをPINTに提供するのにIntelligent Networkシステム、個人的なPBXs、携帯電話ネットワーク、およびISDNをすべて使用できるのが理解されています。 また、サービスを求める要求は全体のインターネットから切断されるプライベートアイピーネットワークから来るかもしれません。
The requirements for the PINT protocol were deliberately restricted to providing the ability to invoke a small number of fixed telephone call services. These "Milestone PINT services" are specified in section 2. Great care has been taken, however, to develop a protocol that is aligned with other Internet protocols where possible, so that future extensions to PINT could develop along with Internet conferencing.
PINTプロトコルのための要件は故意に少ない数の固定通話サービスを呼び出す能力を提供するのに制限されました。 これらの「重大事件PINTサービス」はセクション2で指定されます。 しかしながら、可能であるところで他のインターネットプロトコルに並べられるプロトコルを開発するために高度の注意を取りました、PINTへの今後の拡大がインターネット会議と共に発生できるように。
Within the Internet conference architecture, establishing media calls is done via a combination of protocols. SIP [1] is used to establish the association between the participants within the call (this association between participants within the call is called a "session"), and SDP [2] is used to describe the media to be exchanged within the session. The PINT protocol uses these two protocols together, providing some extensions and enhancements to enable SIP clients and servers to become PINT clients and servers.
インターネット会議アーキテクチャの中では、メディア呼び出しはプロトコルの組み合わせで確立されます。 SIP[1]は呼び出しの中で関係者の間の協会を証明するのに使用されます、そして、(「セッション」は呼び出しの中の関係者の間のこの協会に呼ばれます)SDP[2]は、セッション中に交換するためにメディアを説明するのに使用されます。 PINTプロトコルはこれらの2つのプロトコルを一緒に使用します、SIPクライアントとサーバがPINTクライアントとサーバになるのを可能にするためにいくつかの拡大と増進を提供して。
Petrack & Conroy Standards Track [Page 4] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[4ページ]。
A PINT user who wishes to invoke a service within the telephone network uses SIP to invite a remote PINT server into a session. The invitation contains an SDP description of the media session that the user would like to take place. This might be a "sending a fax session" or a "telephone call session", for example. In a PINT service execution session the media is transported over the phone system, while in a SIP session the media is normally transported over an internet.
電話網の中にサービスを呼び出したがっているPINTユーザは、セッションまでリモートPINTサーバを招待するのにSIPを使用します。 招待はユーザが取りたがっているのが入賞するメディアセッションのSDP記述を含んでいます。 例えば、これは、「ファックスセッションを送ります」か「通話セッション」であるかもしれません。 PINTサービスでは、通常、SIPセッションのメディアである間のメディアが電話システムの上で輸送される実行セッションはインターネットの上で輸送されます。
When used to invoke a PINT service, SIP establishes an association between a requesting PINT client and the PINT server that is responsible for invoking the service within the telephone network. These two entities are not the same entities as the telephone network entities involved in the telephone network service. The SIP messages carry within their SDP payloads a description of the telephone network media session.
PINTサービスを呼び出すのに使用されると、SIPは要求しているPINTクライアントとPINTサーバとの電話網の中にサービスを呼び出すのに責任がある仲間を設立します。 電話にかかわる電話網実体がサービスをネットワークでつなぐとき、これらの2つの実体は同じ実体ではありません。 SIPメッセージはそれらのSDPペイロードの中に電話網メディアセッションの記述を運びます。
Note that the fact that a PINT server accepts an invitation and a session is established is no guarantee that the media will be successfully transported. (This is analogous to the fact that if a SIP invitation is accepted successfully, this is no guarantee against a subsequent failure of audio hardware).
PINTサーバが招待に応じて、セッションが確立されるという事実がメディアが首尾よく輸送されるという保証でないことに注意してください。 (これはSIP招待状が首尾よく応じられるなら、これがオーディオ機材のその後の失敗に対する保証でないという事実に類似しています。)
The particular requirements of PINT users lead to some new messages. When a PINT server agrees to send a fax to telephone B, it may be that the fax transmission fails after part of the fax is sent. Therefore, the PINT client may wish to receive information about the status of the actual telephone call session that was invoked as a result of the established PINT session. Three new requests, SUBSCRIBE, UNSUBSCRIBE, and NOTIFY, are added here to vanilla SIP to allow this.
PINTユーザの特定の要件はいくつかの新しいメッセージにつながります。 PINTサーバが、Bに電話をするためにファックスを送信するのに同意するとき、ファックスの一部を送った後に多分、ファックス送信は失敗します。 したがって、PINTクライアントは確立したPINTセッションの結果、呼び出された実際の通話セッションの状態の情報を受け取りたがっているかもしれません。 3つの新しい要求、登録、登録削除、そして、NOTIFY、ここで、これを許容するためにバニラSIPに加えられます。
The enhancements and additions specified here are not intended to alter the behaviour of baseline SIP or SDP in any way. The purpose of PINT extensions is to extend the usual SIP/SDP services to the telephone world. Apart from integrating well into existing protocols and architectures, and the advantages of reuse, this means that the protocol specified here can handle a rather wider class of call services than just the Milestone services.
ここで指定された増進と追加が何らかの方法で基線SIPかSDPのふるまいを変更することを意図しません。 PINT拡張子の目的は電話世界に対する普通のSIP/SDPサービスを広げることです。 既存のプロトコルとアーキテクチャとよく統合して、再利用の利点は別として、これは、ここで指定されたプロトコルがまさしくMilestoneサービスよりかなり広いクラスの呼び出しサービスを扱うことができることを意味します。
The rest of this document is organised as follows: Section 2 describes the PINT Milestone services; section 3 specifies the PINT functional and protocol architecture; section 4 gives examples of the PINT 1.0 extensions of SIP and SDP; section 5 contains some security considerations for PINT. The final section contains descriptions of how the PINT protocol may be used to provide service over the GSTN.
このドキュメントの残りは以下の通り構成されています: セクション2はPINT Milestoneサービスについて説明します。 セクション3はPINT機能的、そして、プロトコルアーキテクチャを指定します。 セクション4はSIPとSDPのPINT1.0拡張子に関する例を出します。 セクション5はPINTのためのいくつかのセキュリティ問題を含みます。 最後のセクションはPINTプロトコルがGSTNをサービスオーバーに提供するのにどう使用されるかもしれないかに関する記述を含んでいます。
Petrack & Conroy Standards Track [Page 5] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[5ページ]。
For a summary of the extensions to SIP and SDP specified in this document, Section 3.2 gives an combined list, plus one each describing the extensions to SIP and SDP respectively.
本書では指定されたSIPとSDPへの拡大の概要に関しては、セクション3.2は結合したリスト、およびそれぞれそれぞれSIPとSDPに拡大について説明する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 RFC 2119. In addition, the construct "MUST .... OR ...." implies that it is an absolute requirement of this specification to implement one of the two possibilities stated (represented by dots in the above phrase). An implementation MUST be able to interoperate with another implementation that chooses either of the two possibilities.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。 追加、構造物「必須」で… 「OR」… それがこの仕様が述べられた(上記の句のドットで、表されます)2つの可能性の1つを実装するという絶対条件であることを含意します。 実装は選ばれる2つの可能性の別の実装で共同利用できなければなりません。
1.1 Glossary
1.1 用語集
Requestor - An Internet host from which a request for service originates
要請者--サービスを求める要求が起因するインターネット・ホスト
PINT Service - A service invoked within a phone system in response to a request received from an PINT client.
PINT Service--電話システムの中に要求に対応して呼び出されたサービスはPINTクライアントから受信されました。
PINT Client - An Internet host that sends requests for invocation of a PINT Service, in accordance with this document.
PINT Client--このドキュメントに応じてPINT Serviceの実施を求める要求を送るインターネット・ホスト。
PINT Gateway - An Internet host that accepts requests for PINT Service and dispatches them onwards towards a telephone network.
PINTゲートウェイ--受け入れるインターネット・ホストはPINT Serviceと発信のために前方へ電話網に向かってそれらを要求します。
Executive System - A system that interfaces to a PINT Server and to a telephone network that executes a PINT service. It need not be directly associated with the Internet, and is represented by the PINT Server in transactions with Internet entities.
幹部社員System--PINT Serverと、そして、PINTサービスを実行する電話網に連結するシステム。 それは、直接インターネットに関連している必要はなくて、インターネット実体でトランザクションでPINT Serverによって表されます。
Requesting User - The initiator of a request for service. This role may be distinct from that of the "party" to any telephone network call that results from the request.
Userを要求します--サービスを求める要求の創始者。 この役割は「パーティー」のものから要求から生じるどんな電話網呼び出しまでも異なっているかもしれません。
(Service Call) Party - A person who is involved in a telephone network call that results from the execution of a PINT service request, or a telephone network-based resource that is involved (such as an automatic Fax Sender or a Text-to-Speech Unit).
(Call) パーティを修理してください--PINTサービスのリクエストの実行から生じる電話網呼び出し、または電話網でベースでかかわる人}というかかわるリソース(自動ファックスSenderかTextからスピーチへのUnitなどの)。
2. PINT Milestone Services
2. パイント重大事件サービス
The original motivation for defining this protocol was the desire to invoke the following three telephone network services from within an IP network:
このプロトコルを定義することに関するオリジナルの動機はIPネットワークから以下の3つの電話ネットワーク・サービスを呼び出す願望でした:
Petrack & Conroy Standards Track [Page 6] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[6ページ]。
2.1 Request to Call
2.1 呼ぶという要求
A request is sent from an IP host that causes a phone call to be made, connecting party A to some remote party B.
電話をかけさせるIPホストから要求を送ります、いくつかのリモートパーティーBへのパーティーAに接して。
2.2 Request to Fax Content
2.2 ファックスで内容を送るという要求
A request is sent from an IP host that causes a fax to be sent to fax machine B. The request MAY contain a pointer to the fax data (that could reside in the IP network or in the Telephone Network), OR the fax data itself. The content of the fax MAY be text OR some other more general image data. The details of the fax transmission are not accessible to the IP network, but remain entirely within the telephone network.
ファックスで要求が含むかもしれないマシンB.にファックスデータへの指針を送るために送られるファックス(それはIPネットワークかTelephone Networkに住むことができた)、ORにファックスデータ自体を引き起こすIPホストから要求を送ります。 ファックスの内容はテキストORがある他のより一般的なイメージデータであったならそうするかもしれません。 ファックス送信の詳細はIPネットワークにアクセス可能ではありませんが、電話網に完全に残ってください。
Note that this service does not relate to "Fax over IP": the IP network is only used to send the request that a certain fax be sent. Of course, it is possible that the resulting telephone network fax call happens to use a real-time IP fax solution, but this is completely transparent to the PINT transaction.
このサービスが「IPの上のファックス」に関連しないことに注意してください: IPネットワークは単に送った状態であるファックスがある要求を送るのにおいて使用されています。 もちろん、結果として起こる電話網ファックス呼び出しがたまたまリアルタイムのIPファックス解決を使用するのが、可能ですが、これはPINTトランザクションに完全に透明です。
2.3 Request to Speak/Send/Play Content
2.3 内容を話すか、送る、またはプレーするという要求
A request is sent from an IP host that causes a phone call to be made to user A, and for some sort of content to be spoken out. The request MUST EITHER contain a URL pointing to the content, OR include the content itself. The content MAY be text OR some other more general application data. The details of the content transmission are not accessible to the IP network, but remain entirely within the telephone network. This service could equally be called "Request to Hear Content"; the user's goal is to hear the content spoken to them. The mechanism by which the request is formulated is outside the scope of this document; however, an example might be that a Web page has a button that when pressed causes a PINT request to be passed to the PSTN, resulting in the content of the page (or other details) being spoken to the person.
ユーザA、およびある種の内容のためにはっきりと話されるのを電話をかけさせるIPホストから要求を送ります。 要求MUST EITHERは内容を示すURLを含んでいて、ORは内容自体を含んでいます。 内容はテキストORがある他のより一般的なアプリケーションデータであったならそうするかもしれません。 満足しているトランスミッションの詳細はIPネットワークにアクセス可能ではありませんが、電話網に完全に残ってください。 等しくこのサービスを「内容を聞くという要求」と呼ぶことができました。 ユーザの目標は内容が彼らに話されるのを聞くことです。 このドキュメントの範囲の外に要求が定式化されるメカニズムがあります。 しかしながら、例はウェブページには押されるとPSTNに通過されるというPINT要求を引き起こすボタンがあるということであるかもしれません、人に話されるページ(または、他の詳細)の内容をもたらして。
2.4 Relation between PINT milestone services and traditional telephone
services
2.4 PINT重大事件サービスと伝統的な電話サービスとの関係
There are many different versions and variations of each telephone call service invoked by a PINT request. Consider as an example what happens when a user requests to call 1-800-2255-287 via the PINT Request-to-Call service.
PINT要求で呼び出されたそれぞれの通話サービスの多くの異なった見解と変化があります。 例がユーザがPINT Requestから呼び出しに対するサービスで呼び出しに1-800-2255-287を要求するとき起こることであるとみなしてください。
There may be thousands of agents in the call center, and there may be any number of sophisticated algorithms and pieces of equipment that are used to decide exactly which agent will return the call. And once
何千人ものエージェントがコールセンターにいるかもしれません、そして、どのエージェントが呼び出しを返すかをまさに決めるのに使用される設備のいろいろな高度なアルゴリズムと断片があるかもしれません。 一度
Petrack & Conroy Standards Track [Page 7] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[7ページ]。
this choice is made, there may be many different ways to set up the call: the agent's phone might ring first, and only then the original user will be called; or perhaps the user might be called first, and hear some horrible music or pre-recorded message while the agent is located.
この選択をして、呼び出しをセットアップする多くの異なった方法があるかもしれません: エージェントの電話は最初に鳴るかもしれません、そして、次にだけ、オリジナルのユーザは呼ばれるでしょう。 または、エージェントが見つけられている間、ユーザは、恐らく、最初に呼ばれて、何らかのものすごい音楽かプレ録音メッセージを聞くかもしれません。
Similarly, when a PINT request causes a fax to be sent, there are hundreds of fax protocol details to be negotiated, as well as transmission details within the telephone networks used.
PINT要求でファックスを送るとき、同様に、交渉されるために、何百ものファックスプロトコルの詳細があります、電話網の中の詳細が使用したトランスミッションと同様に。
PINT requests do not specify too precisely the exact telephone-side service. Operational details of individual events within the telephone network that executes the request are outside the scope of PINT. This does not preclude certain high-level details of the telephone network session from being expressed within a PINT request. For example, it is possible to use the SDP "lang" attribute to express a language preference for the Request-to-Hear-Content Service. If a particular PINT system wishes to allow requests to contain details of the telephone-network-side service, it uses the SDP attribute mechanism (see section 3.4.2).
PINT要求はあまりに正確に正確な電話サイドサービスを指定しません。 PINTの範囲の外に要求を実行する電話網の中の個人種目の操作上の詳細があります。 これはPINT要求の中で言い表されるのからの電話網セッションのあるハイレベルの詳細を排除しません。 例えば、内容を聞くRequest Serviceのために言語優先を言い表すのにSDP"lang"属性を使用するのは可能です。 特定のPINTシステムが電話ネットワークサイドサービスの詳細を含むという要求を許したいなら、それはSDP属性メカニズムを使用します(セクション3.4.2を見てください)。
3. PINT Functional and Protocol Architecture
3. パイント機能的、そして、プロトコルアーキテクチャ
3.1. PINT Functional Architecture
3.1. パイント機能的な建築
Familiarity is assumed with SIP 2.0 [1] and with SDP [2].
親しみはSIP2.0[1]とSDP[2]で想定されます。
PINT clients and servers are SIP clients and servers. SIP is used to carry the request over the IP network to the correct PINT server in a secure and reliable manner, and SDP is used to describe the telephone network session that is to be invoked or whose status is to be returned.
PINTクライアントとサーバは、SIPクライアントとサーバです。 SIPは安全で信頼できる方法で正しいPINTサーバへのIPネットワークの上まで要求を運ぶのに使用されます、そして、SDPは、呼び出されることになっているか、または返される状態がことである電話網セッションについて説明するのに使用されます。
A PINT system uses SIP proxy servers and redirect servers for their usual purpose, but at some point there must be a PINT server with the means to relay received requests into a telephone system and to receive acknowledgement of these relayed requests. A PINT server with this capability is called a "PINT gateway". A PINT gateway appears to a SIP system as a User Agent Server. Notice that a PINT gateway appears to the PINT infrastructure as if it represents a "user", while in fact it really represents an entire telephone network infrastructure that can provide a set of telephone network services.
PINTシステムがSIPプロキシサーバを使用して、それらの普通の目的のためにサーバを向け直しますが、何らかのポイントに、受信された要求を電話にリレーして、これらのリレーされた要求の承認を受ける手段でPINTサーバがあるに違いありません。 この能力があるPINTサーバは「PINTゲートウェイ」と呼ばれます。 PINTゲートウェイはUserエージェントServerとしてSIPシステムに現れます。PINTゲートウェイがまるで「ユーザ」を表すかのようにPINTインフラストラクチャに見えるのに注意してください、事実上、本当に1セットの電話ネットワーク・サービスを提供できる全体の電話ネットワークインフラを表しますが。
Petrack & Conroy Standards Track [Page 8] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[8ページ]。
So the PINT system might appear to an individual PINT client as follows:
それで、PINTシステムは以下の個々のPINTクライアントにとって現れるかもしれません:
/\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\
___________ \ __/___ ___\_ \
| PINT | PINT \ PINT | PINT | |Exec| Telephone /
| client |<-------------->| server |gatewy|=====|Syst| Network \
|_________| protocol / cloud |______| |____| Cloud /
\ \ / \
/\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/
/\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\ ___________ \ __/___ ___\_ \ | パイント| パイント\パイント| パイント| |幹部| 電話/| クライアント| <、-、-、-、-、-、-、-、-、-、-、-、-、--、>| サーバ|gatewy|=====|Syst| ネットワーク\|_________| プロトコル/雲|______| |____| 雲/\\/\/\/\/\/\/\/\/\\/\/\/\/\/\/\/\/
Figure 1: PINT Functional Architecture
図1: パイント機能的な建築
The system of PINT servers is represented as a cloud to emphasise that a single PINT request might pass through a series of location servers, proxy servers, and redirect servers, before finally reaching the correct PINT gateway that can actually process the request by passing it to the Telephone Network Cloud.
PINTサーバのシステムは強調する独身のPINTが一連の位置のサーバ、プロキシサーバ、および再直接のサーバを通り抜けるかもしれないよう要求する雲として表されます、最終的に実際にそれをTelephone Network Cloudに通過することによって要求を処理できる正しいPINTゲートウェイに達する前に。
The PINT gateway might have a true telephone network interface, or it might be connected via some other protocol or API to an "Executive System" that is capable of invoking services within the telephone cloud.
PINTゲートウェイには、本当の電話ネットワーク・インターフェースがあるかもしれませんか、またはそれはある他のプロトコルかAPIを通して電話雲の中にサービスを呼び出すできる「エグゼクティブ・システム」に接続されるかもしれません。
As an example, within an I.N. (Intelligent Network) system, the PINT gateway might appear to realise the Service Control Gateway Function. In an office environment, it might be a server adjunct to the office PBX, connected to both the office LAN and the office PBX.
例として、I.N.(知的なNetwork)システムの中では、PINTゲートウェイはService ControlゲートウェイFunctionがわかるのを現れるかもしれません。 オフィス環境では、それはオフィスPBXへのサーバ付属物であるかもしれません、オフィスLANとオフィスPBXの両方に接続されています。
The Executive System that lies beyond the PINT gateway is outside the scope of PINT.
PINTの範囲の外にPINTゲートウェイにあるExecutive Systemがあります。
3.2. PINT Protocol Architecture
3.2. パイントプロトコルアーキテクチャ
This section explains how SIP and SDP work in combination to convey the information necessary to invoke telephone network sessions.
このセクションはSIPとSDPが電話網セッションを呼び出すために必要情報を伝えるために組み合わせでどう働いているかを説明します。
The following list summarises the extension features used in PINT 1.0. Following on from this the features are considered separately for SDP and then for SIP:
以下のリストはPINT1.0で使用される拡大機能について略言します。 これからの特徴で続くのはSDPとそして、SIPのために別々に考えられます:
1) Telephony URLs in SDP Contact Fields
2) Refinement of SIP/SDP Telephony URLs
* Inclusion of private dialling plans
3) Specification of Telephone Service Provider (TSP) and/or phone-
context URL-parameters
4) Data Objects as session media
1) SDP接触分野2)の電話URL 個人的なダイヤルすることのSIP/SDP Telephony URL*包含の気品は3を)計画しています。 Telephone Service Provider(TSP)、そして/または、電話文脈URLパラメタ4)の仕様 セッションメディアとしてのデータObjects
Petrack & Conroy Standards Track [Page 9] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[9ページ]。
4a) Protocol Transport formats to indicate the treatment of the media
within the GSTN
5) Implicit (Indirect) media streams and opaque arguments
6) In-line data objects using multipart/mime
7) Refinement/Clarification of Opaque arguments passed onwards to
Executive Systems
* Framework for Presentation Restriction Indication
* Framework for Q.763 arguments
8) An extension mechanism for SDP to specify strictures and force
failure when a recipient does NOT support the specified
extensions, using "require" headers.
9) Mandatory support for "Warning" headers to give more detailed
information on request disposition.
10) Mechanism to register interest in the disposition of a requested
service, and to receive indications on that disposition.
4a) TransportがGSTN5)の中にメディアの処理を示すためにフォーマットするプロトコル 暗黙(間接的な)のメディアストリームと不透明な議論6) 複合/パントマイム7)を使用するインラインデータ・オブジェクト Q.763議論8)のためのPresentation Restriction Indication*フレームワークのために前方へExecutive Systems*フレームワークに通過されたOpaque議論の気品/明確化 受取人であるときに、SDPが狭窄を指定して、失敗を強制する拡張機能は指定された拡大をサポートしません、「必要」ヘッダーを使用して。 9) 以上をヘッダーに「警告」である義務的なサポートは要求気質の情報を詳しく述べました。 10) 要求されたサービスの気質への関心を示して、その気質で指摘を受けるメカニズム。
Both PINT and SIP rely on features of MIME[4]. The use of SIP 2.0 is implied by PINT 1.0, and this also implies compliance with version 1.0 of MIME.
PINTとSIPの両方がMIME[4]の特徴を当てにします。 SIP2.0の使用はPINT1.0によって含意されます、そして、また、これはMIMEのバージョン1.0へのコンプライアンスを含意します。
3.2.1. SDP operation in PINT
3.2.1. PINTでのSDP操作
The SDP payload contains a description of the particular telephone network session that the requestor wishes to occur in the GSTN. This information includes such things as the telephone network address (i.e. the "telephone number") of the terminal(s) involved in the call, an indication of the media type to be transported (e.g. audio, text, image or application data), and an indication if the information is to be transported over the telephone network via voice, fax, or pager transport. An indication of the content to be sent to the remote telephone terminal (if there is any) is also included.
SDPペイロードは要請者がGSTNに生じたがっている特定の電話網セッションの記述を含んでいます。 この情報は情報が電話網の上で声、ファックス、またはポケットベル輸送で輸送されることであるなら端末の電話網アドレス(すなわち、「電話番号」)が呼び出しにかかわったようなもの、輸送されるべきメディアタイプ(例えば、オーディオ、テキスト、イメージまたはアプリケーションデータ)のしるし、および指示を含んでいます。 また、遠く離れた電話端末(いずれかあれば)に送られる内容のしるしは含まれています。
SDP is flexible enough to convey these parameters independently. For example, a request to send some text via voice transport will be fulfilled by invoking some text-to-speech-over-the-phone service, and a request to send text via fax will be fulfilled by invoking some text-to-fax service.
SDPは独自にこれらのパラメタを伝えるほどフレキシブルです。 例えば、声の輸送で何らかのテキストを送るという要求がいくつかを呼び出すことによって実現する、スピーチへのテキスト、過剰、電話、サービス、およびaは、ファックスでテキストを送るのがいくらかのテキストからファックスサービスを呼び出すことによって実現するよう要求します。
The following is a list of PINT 1.0 enhancements and additions to SDP.
↓これはSDPへのPINT1.0増進と追加のリストです。
a. A new network type "TN" and address types "RFC2543" and "X-..."
(section 3.4.1)
b. New media types "text", "image", and "application", new
protocol transport keywords "voice", "fax" and "pager" and the
associated format types and attribute tags (section 3.4.2)
a。 新しいネットワークタイプのアドレスタイプの「テネシー」、"RFC2543"、および"X"… (セクション3.4.1) b。 ニューメディアタイプ「テキスト」、「イメージ」、および「アプリケーション」、新しいプロトコル輸送キーワード「声」、「ファックス」、および「ポケットベル」、関連形式タイプ、および属性タグ(セクション3.4.2)
Petrack & Conroy Standards Track [Page 10] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[10ページ]。
c. New format specific attributes for included content data
(section 3.4.2.4)
d. New attribute tags, used to pass information to the telephone
network (section 3.4.3)
e. A new attribute tag "require", used by a client to indicate
that some attribute is required to be supported in the server
(section 3.4.4)
c。 新しい形式詳細が含まれている満足しているデータのために結果と考える、(セクション3.4 .2 .4) d。 電話網(セクション3.4.3)eに情報を通過するのに使用される新しい属性タグ。 何らかの属性がサーバでサポートされるのに必要であることを示すのにクライアントによって使用された「必要新しい属性タグ」(セクション3.4.4)
3.2.2. SIP Operation in PINT
3.2.2. パイントにおける一口操作
SIP is used to carry the request for telephone service from the PINT client to the PINT gateway, and may include a telephone number if needed for the particular service. The following is a complete list of PINT enhancements and additions to SIP:
SIPはPINTクライアントからPINTゲートウェイまでの電話サービスを求める要求を運ぶのに使用されて、特定のサービスに必要であるなら、電話番号を含むかもしれません。 ↓これはSIPへのPINT増進と追加に関する全リストです:
f. The multipart MIME payloads (section 3.5.1)
g. Mandatory support for "Warning:" headers (section 3.5.2)
h. The SUBSCRIBE and NOTIFY, and UNSUBSCRIBE requests (section
3.5.3)
i. Require: headers (section 3.5.4)
j. A format for PINT URLS within a PINT request (section 3.5.5)
k. Telephone Network Parameters within PINT URLs (section 3.5.6)
f。 複合MIMEペイロード(セクション3.5.1)g。 義務的なサポート、「警告:」 ヘッダー(セクション3.5.2)h。 そして、登録、登録削除、NOTIFY、および要求(セクション3.5.3)i。 必要です: ヘッダー(セクション3.5.4)j。 PINT要求(セクション3.5.5)kの中のPINT URLSのための形式。 パイントURLの中の電話網パラメタ(セクション3.5.6)
Section 3.5.8 contains remarks about how BYE requests are used within PINT. This is not an extension to baseline SIP; it is included here only for clarification of the semantics when used with telephone network sessions.
セクション3.5 .8 BYE要求がPINTの中でどう使用されるかに関する所見を含んでいます。 これは基線SIPへの拡大ではありません。 電話網セッションと共に使用されると、それは意味論の明確化のためだけにここに含まれています。
3.3. REQUIRED and OPTIONAL elements for PINT compliance
3.3. PINTコンプライアンスのためのREQUIREDとOPTIONAL要素
Of these, only the TN network type (with its associated RFC2543 address type) and the "require" attribute MUST be supported by PINT 1.0 clients and servers. In practice, most PINT service requests will use other changes, of which references to Data Objects in requests are most likely to appear in PINT requests.
これらでは、PINT1.0クライアントとサーバでテネシーネットワークタイプ(関連RFC2543アドレスタイプがある)と「必要」属性だけをサポートしなければなりません。 実際には、ほとんどのPINTサービスのリクエストが他の変化を使用するでしょう。(そこでは、要求におけるData Objectsの参照がPINT要求に最も現れそうです)。
Each of the other new PINT constructs enables a different function, and a client or server that wishes to enable that particular function MUST do so by the construct specified in this document. For example, building a PINT client and server that provide only the Request-to- Call telephone call service, without support for the other Milestone services, is allowed.
それぞれの他の新しいPINT構造物が異なった機能、およびクライアントを可能にしなければなりませんか、またはその特定の機能を可能にしたがっているサーバは本書では指定された構造物でそうしなければなりません。 例えば、他のMilestoneサービスのサポートなしでRequestから呼び出しに対する通話サービスだけを提供するPINTクライアントとサーバを組立てるのは許されています。
The "Require:" SIP header and the "require" attribute provide a mechanism that can be used by clients and servers to signal their need and/or ability to support specific "new" PINT protocol elements.
「以下を必要としてください」 SIPヘッダーと「必要」属性はクライアントとサーバによって使用される、彼らの必要性に合図できるメカニズム、そして/または、特定の「新しい」PINTプロトコル要素を支える能力を提供します。
Petrack & Conroy Standards Track [Page 11] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[11ページ]。
It should be noted that many optional features of SIP and SDP make sense as specified in the PINT context. One example is the SDP a=lang: attribute, which can be used to describe the preferred language of the callee. Another example is the use of the "t=" parameter to indicate that the time at which the PINT service is to be invoked. This is the normal use of the "t=" field. A third example is the quality attributes. Any SIP or SDP option or facility is available to PINT clients and servers without change.
SIPとSDPに関する多くのオプション機能がPINT文脈で指定されるように理解できることに注意されるべきです。 1つの例がSDP a=langです: 属性。(訪問される人の都合のよい言語を説明するのにその属性を使用できます)。 別の例はそれを示す「t=」パラメタの使用です。呼び出されるPINTサービスがことである時。 これは「t=」分野の通常の使用です。 3番目の例は上質の属性です。 どんなSIPや、SDPオプションやまたは施設も変化なしでPINTクライアントとサーバに利用可能です。
Conversely, support for Data Objects within Internet Conference sessions may be useful, even if the aim is not to provide a GSTN service request. In this case, the extensions covering these items may be incorporated into an otherwise "plain" SIP/SDP invitation. Likewise, support for SDP "require" may be useful, as a framework for addition of features to a "traditional" SIP/SDP infrastructure. Again, these may be convenient to incorporate into SIP/SDP implementations that would not be used for PINT service requests. Such additions are beyond the scope of this document, however.
逆に、インターネットコンファレンスセッション以内のData Objectsのサポートは役に立つかもしれません、目的がGSTNサービスのリクエストを提供しないことであるなら。 この場合、これらの項目をカバーする拡大はそうでなければ、「明瞭な」SIP/SDP招待状に組み入れられるかもしれません。 同様に、「必要SDP」のサポートは特徴の追加のためのフレームワークとして「伝統的な」SIP/SDPインフラストラクチャの役に立つかもしれません。 一方、これらは、PINTサービスのリクエストに使用されないSIP/SDP実装に盛込むのに便利であるかもしれません。 しかしながら、そのような追加はこのドキュメントの範囲を超えています。
3.4. PINT Extensions to SDP
3.4. SDPへのパイント拡大
PINT 1.0 adds to SDP the possibility to describe audio, fax, and pager telephone sessions. It is deliberately designed to hide the underlying technical details and complexity of the telephone network. The only network type defined for PINT is the generic "TN" (Telephone Network). More precise tags such as "ISDN", "GSM", are not defined. Similarly, the transport protocols are designated simply as "fax", "voice", and "pager"; there are no more specific identifiers for the various telephone network voice, fax, or pager protocols. Similarly, the data to be transported are identified only by a MIME content type, such as "text" data, "image" data, or some more general "application" data. An important example of transporting "application" data is the milestone service "Voice Access to Web Content". In this case the data to be transported are pointed to by a URI, the data content type is application/URI, and the transport protocol would be "voice". Some sort of speech-synthesis facility, speaking out to a Phone, will have to be invoked to perform this service.
PINT1.0はオーディオ、ファックス、およびポケットベル電話セッションについて説明する可能性をSDPに加えます。 それは、電話網の基本的な技術的詳細と複雑さを隠すように故意に設計されています。 PINTのために定義された唯一のネットワークタイプがジェネリック「テネシー」(電話網)です。 「ISDN」などの、より正確なタグ"GSM"は定義されません。 同様に、トランスポート・プロトコルは単に「ファックス」、「声」、および「ポケットベル」として指定されます。 様々な電話網声、ファックス、またはポケットベルプロトコルのためのそれ以上の特定の識別子がありません。 同様に、輸送されるべきデータはMIME content typeだけによって特定されます、「テキスト」データ、「イメージ」データ、またはそれ以上の一般的な「アプリケーション」データなどのように。 輸送「アプリケーション」データの重要な例は重大事件サービス「ウェブ内容への声のアクセス」です。 この場合、輸送されるべきデータはURIによって示されます、そして、データcontent typeはアプリケーション/URIです、そして、トランスポート・プロトコルは「声」でしょう。 電話にはっきりと話して、ある種の音声合成施設が、このサービスを実行するために呼び出されなければならないでしょう。
This section gives details of the new SDP keywords.
このセクションは新しいSDPキーワードの詳細を明らかにします。
3.4.1. Network Type "TN" and Address Type "RFC2543"
3.4.1. ネットワークタイプの「テネシー」とアドレスタイプ"RFC2543"
The TN ("Telephone Network") network type is used to indicate that
the terminal is connected to a telephone network.
テネシー(「電話網」)ネットワークタイプは、端末が電話網につなげられるのを示すのに使用されます。
The address types allowed for network type TN are "RFC2543" and private address types, which MUST begin with an "X-".
ネットワークタイプテネシーに許容されたアドレスタイプは、"RFC2543"とプライベート・アドレスタイプです。(そのタイプは「X」と共に始まらなければなりません)。
Petrack & Conroy Standards Track [Page 12] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[12ページ]。
Address type RFC2543 is followed by a string conforming to a subset of the "telephone-subscriber" BNF specified in figure 4 of SIP [1]). Note that this BNF is NOT identical to the BNF that defines the "phone-number" within the "p=" field of SDP.
4図で指定された「電話加入者」BNF SIP[1])の部分集合に一致しているストリングはアドレスタイプRFC2543を支えています。 このBNFがSDPの「p=」分野の中で「電話番号」を定義するBNFと同じでないことに注意してください。
Examples:
例:
c= TN RFC2543 +1-201-406-4090
cはTN RFC2543+1-201-406-4090と等しいです。
c= TN RFC2543 12014064090
cはTN RFC2543 12014064090と等しいです。
A telephone-subscriber string is of one of two types: global-phone-
number or local-phone-number. These are distinguished by preceeding
a global-phone-number with a "plus" sign ("+"). A global-phone-number
is by default to be interpreted as an internationally significant
E.164 Number Plan Address, as defined by [6], whilst a local-phone-
number is a number specified in the default dialling plan within the
context of the recipient PINT Gateway.
2つのタイプのひとりには電話加入者ストリングがあります: グローバルな電話番号かローカルの電話番号です。 これらは、「プラス」サイン(「+」)でグローバルな電話番号をpreceedingすることによって、区別されます。 グローバルな電話番号はデフォルトで、地方の電話番号が数である間、[6]によって定義されるように国際的に重要なE.164 Number Plan Addressとして解釈されるのが受取人PINTゲートウェイの文脈の中でプランにダイヤルするデフォルトで指定したということです。
An implementation MAY use private addressing types, which can be useful within a local domain. These address types MUST begin with an "X-", and SHOULD contain a domain name after the X-, e.g. "X- mytype.mydomain.com". An example of such a connection line is as follows:
実装は個人的なアドレシングタイプを使用するかもしれません。(タイプは局所領域の中で役に立つ場合があります)。 これらのアドレスタイプは、「X」と共に始まらなければならなくて、例えば、X、「X mytype.mydomain.com」の後にドメイン名を含むべきです。 そのような接続系列の例は以下の通りです:
c= TN X-mytype.mydomain.com A*8-HELEN
cはテネシーX-mytype.mydomain.com A*8ヘレンと等しいです。
where "X-mytype.mydomain.com" identifies this private address type, and "A*8-HELEN" is the number in this format. Such a format is defined as an "OtherAddr" in the ABNF of Appendix A. Note that most dialable telephone numbers are expressable as local-phone-numbers within address RFC2543; new address types SHOULD only be used for formats which cannot be so written.
"X-mytype.mydomain.com"がどこでこのプライベート・アドレスタイプを特定するか、そして、「*8ヘレン」はこの形式の数です。 そのような書式はアドレスRFC2543の中でほとんどの「ダイヤル-可能」電話番号が「言い表-可能」であるAppendix A.NoteのABNFの"OtherAddr"ローカルの電話番号と定義されます。 新しいアドレスはSHOULDをタイプします。書かれていて、そうすることができない形式に単に非常に使用されてください。
3.4.2. Support for Data Objects within PINT
3.4.2. パイントの中のデータ・オブジェクトのサポート
One significant change over traditional SIP/SDP Internet Conference sessions with PINT is that a PINT service request may refer to a Data Object to be used as source information in that request. For example, a PINT service request may specify a document to be processed as part of a GSTN service by which a Fax is sent. Similarly, a GSTN service may be take a Web page and result in a vocoder processing that page and speaking the contents over a telephone.
PINTとの伝統的なSIP/SDPインターネットコンファレンスセッションの間の1回の著しい変化はPINTサービスのリクエストがその要求におけるソース情報として使用されるためにData Objectについて言及するかもしれないということです。 例えば、PINTサービスのリクエストは、ファックスが送られるGSTNサービスの一部として処理されるためにドキュメントを指定するかもしれません。 同様に、GSTNサービスはそのページを処理して、電話の上でコンテンツを話しながらボコーダでウェブページと結果を取ることであるかもしれません。
The SDP specification does not have explicit support for reference to or carriage of Data Objects within requests. In order to use SDP for PINT, there is a need to describe such media sessions as "a telephone
SDP仕様は要求の中にData Objectsの参照か運搬の明白なサポートを持っていません。 PINTにSDPを使用するために、「電話」としてそのようなメディアセッションを記述する必要があります。
Petrack & Conroy Standards Track [Page 13] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[13ページ]。
call to a certain number during which such-and-such an image is sent as a fax".
「そのようなイメージがファックスとして送られるある数に呼びかけてください。」
To support this, two extensions to the session description format are specified. These are some new allowed values for the Media Field, and a description of the "fmtp" parameter when used with the Media Field values (within the context of the Contact Field Network type "TN").
これをサポートするために、セッション記述形式への2つの拡大が指定されます。 メディアField値(タイプ「テネシー」というContact Field Networkの文脈の中の)と共に使用されると、これらは、メディアFieldのためのいくつかの新しい許容値と、"fmtp"パラメタの記述です。
An addition is also made to the SIP message format to allow the inclusion of data objects as sub-parts within the request message itself. The original SDP syntax (from [2]) for media-field is given as:
また、要求メッセージ自体の中の同じくらいサブ部品のデータ・オブジェクトの包含を許容するのを追加をSIPメッセージ・フォーマットにします。 オリジナルのSDP構文、(以下としてメディア分野への[2])から与えます。
media-field = "m=" media space port ["/" integer]
space proto 1*(space fmt) CRLF
メディア分野=「m=」メディアスペース・ポート[「/」整数]スペースプロト1*(スペースfmt)CRLF
When used within PINT requests, the definition of the sub-fields is expanded slightly. The Media sub-field definition is relaxed to accept all of the discrete "top-level" media types defined in [4]. In the milestone services the discrete type "video" is not used, and the extra types "data" and "control" are likewise not needed. The use of these types is not precluded, but the behaviour expected of a PINT Gateway receiving a request including such a type is not defined here.
PINT要求の中で使用されると、サブ分野の定義はわずかに広げられます。 メディアサブフィールド定義は、[4]で定義された離散的な「トップレベル」メディアタイプを皆、受け入れるためにリラックスします。 離散的なタイプ「ビデオ」が重大事件サービスは使用されていません、そして、付加的なタイプ「データ」と「コントロール」は同様に必要ではありません。 これらのタイプの使用は排除されませんが、PINTゲートウェイがそのようなタイプを含む要求を受け取るのに予想されたふるまいはここで定義されません。
The Port sub-field has no meaning in PINT requests as the destination terminals are specified using "TN" addressing, so the value of the port sub-field in PINT requests is normally set to "1". A value of "0" may be used as in SDP to indicate that the terminal is not receiving media. This is useful to indicate that a telephone terminal has gone "on hold" temporarily. Likewise, the optional integer sub-field is not used in PINT.
あて先端末が「テネシー」アドレシングを使用することで指定されるときPortサブ分野にはPINT要求における意味でないのがあるので、通常、パイント要求のサブ分野のポートの値が「1インチ」に設定されます。 「0インチは端末が受信メディアでないことを示すSDPのように使用されるかもしれない」値。 これは、電話端末が一時「保持」に行ったのを示すために役に立ちます。 同様に、任意の整数サブ分野はPINTで使用されません。
As mentioned in [2], the Transport Protocol sub-field is specific to the associated Address Type. In the case that the Address Type in the preceeding Contact field is one of those defined for use with the Network Type "TN", the following values are defined for the Transport Protocol sub-field:
[2]で言及されるように、Transportプロトコルサブ分野は関連Address Typeに特定です。 preceeding Contact分野のAddress TypeがNetwork Type「テネシー」との使用のために定義されたもののひとりであり、以下の値はトランスポート・プロトコルサブ分野と定義されます:
"voice", "fax", and "pager".
「声」、「ファックス」、および「ポケットベル。」
The interpretation of this sub-field within PINT requests is the treatment or disposition of the resulting GSTN service. Thus, for transport protocol "voice", the intent is that the service will result in a GSTN voice call, whilst for protocol "fax" the result will be a GSTN fax transmission, and protocol "pager" will result in a pager message being sent.
PINT要求の中のこのサブ分野の解釈は、結果として起こるGSTNサービスの処理か気質です。 したがって、意図はトランスポート・プロトコル「声」のためのサービスがGSTN音声通話をもたらすということです、プロトコル「ファックス」のために結果はGSTNファックス送信になるでしょう、そして、プロトコル「ポケットベル」は送られるポケットベルのメッセージをもたらすでしょうが。
Petrack & Conroy Standards Track [Page 14] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[14ページ]。
Note that this sub-field does not necessarily dictate the media type and subtype of any source data; for example, one of the milestone services calls for a textual source to be vocoded and spoken in a resulting telephone service call. The transport protocol value in this case would be "voice", whilst the media type would be "text".
このサブ分野が必ずどんなソースデータのメディアのタイプと「副-タイプ」も決めるというわけではないことに注意してください。 例えば、重大事件サービスのひとりは、原文のソースが結果として起こる電話業務通話でvocodedされて、話されるように求めます。 この場合、トランスポート・プロトコル値は「声」でしょうが、メディアタイプは「テキスト」でしょう。
The Fmt sub-field is described in [2] as being transport protocol- specific. When used within PINT requests having one of the above protocol values, this sub-field consists of a list of one or more values, each of which is a defined MIME sub-type of the associated Media sub-field value. The special value "-" is allowed, meaning that there is no MIME sub-type. This sub-field retains (from [2]) its meaning that the list will contain a set of alternative sub-types, with the first being the preferred value.
Fmtサブ分野は[2]で輸送プロトコル特有であると説明されます。 上のプロトコル値の1つを持ちながらPINT要求の中で使用されると、このサブ分野は1つ以上の値のリストから成ります。それはそれぞれ関連メディアサブ分野のサブタイプが評価する定義されたMIMEです。 MIMEサブタイプが全くないことを意味して、特別な値の「-」は許容されています。 このサブ分野が保有する、([2]) リストが1セットの代替のサブタイプを含むと都合のよい値である1番目で言うのから。
For experimental purposes and by mutual consent of the sender and recipient, a sub-type value may be specified as an <X-token>, i.e. a character string starting with "X-". The use of such values is discouraged, and if such a value is expected to find common use then it SHOULD be registered with IANA using the standard content type registration process (see Appendix C).
実験目的と送付者と受取人で合意で、サブタイプ値は<X-トークンとして指定されて、すなわち、>、キャラクタが「X」を始めに通すということであるかもしれません。 そのような値の使用がお勧めできなく、そのような値がコモンを見つけると予想されるならその時それを使用してください、SHOULD、標準のcontent type登録手続を使用するIANAに登録されてください(Appendix Cを見てください)。
When the Fmt parameter is the single character "-" ( a dash ), this is interpreted as meaning that a unspecified or default sub-type can be used for this service. Thus, the media field value "m=audio 1 voice -<CRLF>" is taken to mean that a voice call is requested, using whatever audio sub type is deemed appropriate by the Executive System. PINT service is a special case, in that the request comes from the IP network but the service call is provided within the GSTN. Thus the service request will not normally be able to define the particular codec used for the resulting GSTN service call. If such an intent IS required, then the quality attribute may be used (see "Suggested Attributes" section of [2]).
Fmtパラメタが単一のキャラクタ「-」(ダッシュ)であるときに、このサービスに不特定であるかデフォルトサブタイプを使用できることを意味するとこれは解釈されます。 したがって、音声通話が要求されていることを意味するためにメディア分野値の「1声-<のm=オーディオCRLF>」を取ります、適切であるとExecutive Systemによって考えられるどんなオーディオ潜水艦タイプも使用して。 要求がIPネットワークから来るので、PINTサービスは特別なケースですが、GSTNの中で業務通話を提供します。 したがって、通常、サービスのリクエストは結果として起こるGSTN業務通話に使用される特定のコーデックを定義できないでしょう。 そのような意図が必要であるなら、品質属性は使用されるかもしれません。(「提案された属性」セクションの[2])を見てください。
3.4.2.1. Use of fmtp attributes in PINT requests
3.4.2.1. PINT要求におけるfmtp属性の使用
For each element of the Fmt sub-field, there MUST be a following fmtp attribute. When used within PINT requests, the fmtp attribute has a general structure as defined here:
Fmtサブ分野の各要素のために、次のfmtp属性があるに違いありません。 PINT要求の中で使用されると、fmtp属性に、一般構造体がここで定義されるようにあります:
"a=fmtp:" <subtype> <space> resolution
*(<space> resolution)
(<space> ";" 1(<attribute>)
*(<space> <attribute>))
where:
<resolution> := (<uri-ref> | <opaque-ref> | <sub-part-ref>)
「a=fmtp:」 「<「副-タイプ」><宇宙>解決*(<宇宙>解決)、(<スペース>、」 ; 」 1 (<属性>) *(<スペース><属性>)) どこ: <解決>:=(<uri-審判>| <分っている審判>| <サブ部分の審判>)
Petrack & Conroy Standards Track [Page 15] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[15ページ]。
A fmtp attribute describes the sources used with a given Fmt entry in the Media field. The entries in a Fmt sub-field are alternatives (with the preferred one first in the list). Each entry will have a matching fmtp attribute. The list of resolutions in a fmtp attribute describes the set of sources that resolve the matching Fmt choice; all elements of this set will be used.
fmtp属性はメディア分野での与えられたFmtエントリーと共に使用されるソースについて説明します。 Fmtサブ分野でのエントリーは代替手段(都合のよい1/1がリストにある)です。 各エントリーには、合っているfmtp属性があるでしょう。 fmtp属性における解決のリストは合っているFmt選択を決議するソースのセットについて説明します。 このセットのすべての要素が使用されるでしょう。
It should be noted that, for use in PINT services, the elements in such a set will be sent as a sequence; it is unlikely that trying to send them in parallel would be successful.
そのようなセットにおける要素が系列としてPINTサービスにおける使用において送られることに注意されるべきです。 それらを平行に送ろうとするのがうまくいっているのは、ありそうもないです。
A fmtp attribute can contain a mixture of different kinds of element. Thus an attribute might contain a sub-part-ref indicating included data held in a sub-part of the current message, followed by an opaque-ref referring to some content on the GSTN, followed by a uri- ref pointing to some data held externally on the IP network.
fmtp属性は異種の要素の混合物を含むことができます。 したがって、GSTNに関する何らかの内容を示しながら分っている審判によって従われた現在のメッセージのサブ部分に保持された含まれているデータがIPネットワークに外部的に保持されたいくつかのデータを示すuri審判で従ったのを示しながら、属性はサブ部分の審判を含むかもしれません。
To indicate which form each resolution element takes, each of them starts with its own literal tag. The detailed syntax of each form is described in the following sub-sections.
それぞれの解決要素がどの形を取るかを示すために、それぞれのそれらはそれ自身の文字通りのタグから始まります。 それぞれのフォームの詳細な構文は以下の小区分で説明されます。
3.4.2.2. Support for Remote Data Object References in PINT
3.4.2.2. パイントにおけるリモートデータ・オブジェクト参照のサポート
Where data objects stored elsewhere on the IP Network are to be used as sources for processing within a PINT service, they may be referred to using the uri-ref form. This is simply a Uniform Resource Identifier (URI), as described in [9].
IP Networkのほかの場所に保存されたデータ・オブジェクトが処理にソースとしてPINTサービスの中で使用されることであるところと、彼らは、uri-審判フォームを使用することで呼ばれるかもしれません。 これは[9]で説明されるように単にUniform Resource Identifier(URI)です。
Note that the reference SHOULD be an absolute URI, as there may not be enough contextual information for the recipient server to resolve a relative reference; any use of relative references requires some private agreement between the sender and recipient of the message, and SHOULD be avoided unless the sender can be sure that the recipient is the one intended and the reference is unambiguous in context.
参照SHOULDが絶対URIであることに注意してください、受取人サーバが相対参照を決議できるくらいの文脈上の情報がないかもしれないので。 相対参照のどんな使用もメッセージ、およびSHOULDの送付者と受取人との何らかの個人的な協定を必要とします。送付者が受取人が意図するものであり、参照が状況内において明白であることを確信しているはずがないなら、避けられてください。
This also holds for partial URIs (such as"uri:http://aNode/index.htm") as these will need to be resolved in the context of the eventual recipient of the message.
「また、これは部分的なURI(such as"uri: http://aNode/index.htm のために成立する」) これらが、メッセージの最後の受取人の文脈で決議される必要があるとき。
The general syntax of a reference to an Internet-based external data object in a fmtp line within a PINT session description is:
PINTセッション記述の中のfmtp系列におけるインターネットを利用する外部のデータ・オブジェクトの参照の一般的な構文は以下の通りです。
<uri-ref> := ("uri:" URI-reference)
<uri-審判>:=(「uri:」 URI参照)
where URI-reference is as defined in Appendix A of [9]
どこに、URI参照がAppendix Aで定義されるようにありますか。[9]
Petrack & Conroy Standards Track [Page 16] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[16ページ]。
For example:
例えば:
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain uri:ftp://ftp.isi.edu/in-notes/rfc2468.txt
or:
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain
uri:http://www.ietf.org/meetings/glance_minneapolis.txt
または、cが+1-201-406-4090m=のTN RFC2543テキスト1ファックスの明瞭なa=fmtp: 明瞭なuri: ftp://ftp.isi.edu/in-notes/rfc2468.txt と等しい、: +1-201-406-4090m=のTN RFC2543テキスト1c=ファックスの明瞭なa=fmtp: 明瞭なuri: http://www.ietf.org/meetings/glance_minneapolis.txt
means get this data object from the Internet and use it as a source for the requested GSTN Fax service.
手段は、インターネットからこのデータ・オブジェクトを手に入れて、要求されたGSTNファックスサービスにソースとしてそれを使用します。
3.4.2.3. Support for GSTN-based Data Objects in PINT
3.4.2.3. パイントにおけるGSTNベースのデータ・オブジェクトのサポート
PINT services may refer to data that are held not on the IP Network but instead within the GSTN. The way in which these items are indicated need have no meaning within the context of the Requestor or the PINT Gateway; the reference is merely some data that may be used by the Executive System to indicate the content intended as part of the request. These data form an opaque reference, in that they are sent "untouched" through the PINT infrastructure.
PINTサービスはIP Networkに保持されるのではなく、代わりにGSTNの中に保持されるデータを示すかもしれません。 これらの項目が示される方法はRequestorかPINTゲートウェイの文脈の中に意味を持つ必要はありません。 参照は要求の一部として意図する内容を示すのにExecutive Systemによって使用されるかもしれない単にいくつかのデータです。 これらのデータは、PINTインフラストラクチャを通して「触れません、な」状態でそれらを送るので、不明瞭な参照を形成します。
A reference to some data object held on the GSTN has the general definition:
GSTNで持たれていたいくらかのデータ・オブジェクトの参照には、一般的な定義があります:
<opaque-ref> := ("opr:" *uric)
<分っている審判>:=(「opr:」 *、尿、)
where uric is as defined in Appendix A of [9].
尿であるところに、[9]が定義されるとしてAppendixにAがありますか?
For example:
例えば:
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain opr:APPL.123.456
+1-201-406-4090m=のTN RFC2543テキスト1c=ファックスの明瞭なa=fmtp: 明瞭なopr: APPL.123.456
means send the data that is indexed ON THE GSTN by the reference value "APPL.123.456" to the fax machine on +1-201-406-4090. The Executive System may also take the Telephone URL held in the To: field of the enclosing SIP message into account when deciding the context to be used for the data object dereference.
手段が基準値でON GSTNを索引をつけられるデータに送る、「APPL、.123、0.456インチ、+1-201-406-4090のファックス装置、」 また、Executive SystemはTo:に保持されたTelephone URLを取るかもしれません。 データ・オブジェクト反参照に使用されるために文脈について決めるときSIPがアカウントへ通信させる同封の分野。
Of course, an opaque reference may also be used for other purposes; it could, for example, be needed to authorise access to a document held on the GSTN rather than being required merely to disambiguate
もちろん、また、不明瞭な参照は他の目的に使用されるかもしれません。 例えば、それが、GSTNに保持されたドキュメントへのアクセスを認可するのに単にあいまいさを除くために必要とするよりむしろ必要であったかもしれません。
Petrack & Conroy Standards Track [Page 17] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[17ページ]。
the data object. The purpose to which an opaque reference is put, however, is out of scope for this document. It is merely an indicator carried within a PINT Request.
データ・オブジェクト。 このドキュメントのための範囲の外にしかしながら、不明瞭な参照が置かれる目的があります。 それは単にPINT Requestの中で運ばれたインディケータです。
An opaque reference may have no value in the case where the value to be used is implicit in the rest of the request. For example, suppose some company wishes to use PINT to implement a "fax-back service". In their current implementation, the image(s) to be faxed are entirely defined by the telephone number dialled. Within the PINT request, this telephone number would appear within the "To:" field of the PINT request, and so there is no need for an opaque reference value.
不明瞭な参照は使用されるべき値が要求の残りで暗に示されている場合で値を全く持っていないかもしれません。 例えば、ある会社が「ファックス逆サービス」を実装するのにPINTを使用したがっていると仮定してください。 それらの現在の実装では、ファックスで送られるイメージはダイヤルされた電話番号によって完全に定義されます。 PINT要求の中では、この電話番号は「To:」の中に現れるでしょう。 PINT要求、不透明な基準値の必要は全くないように、さばきます。
If there are several resolutions for a PINT Service Request, and one of these is an opaque reference with no value, then that opaque reference MUST be included in the attribute line, but with an empty value field.
PINT Service Requestのためのいくつかの解決があって、これらの1つが値がなければ不明瞭な参照であるなら、その不明瞭な参照は属性系列に含まれていますが、人影のない値の分野で含まれなければなりません。
For example:
例えば:
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain uri:http://www.sun.com/index.html opr:
+1-201-406-4090m=のTN RFC2543テキスト1c=ファックスの明瞭なa=fmtp: 明瞭なuri: http://www.sun.com/index.html opr:
might be used to precede some data to be faxed with a covering note.
仮契約書でファックスで送られるいくつかのデータに先行するのに使用されるかもしれません。
In the special case where an opaque reference is the sole resolution of a PINT Service Request, AND that reference needs no value, there is no need for a Fmt list at all; the intent of the service is unambiguous without any further resolution.
不明瞭な参照がPINT Service Requestの唯一の解決であり、その参照が値を全く必要としない特別な場合には、全くFmtリストの必要は全くありません。 サービスの意図は少しもさらなる解決なしで明白です。
For example:
例えば:
c= TN RFC2543 +1-201-406-4090
m= text 1 fax -
cが+1-201-406-4090m=のTN RFC2543テキスト1ファックスと等しい、-
means that there is an implied content stored on the GSTN, and that this is uniquely identified by the combination of SIP To-URI and the Contact field of the session description.
GSTNに保存された暗示している内容があって、これがSIP To-URIの組み合わせとセッション記述のContact分野によって唯一特定されることを意味します。
3.4.2.4. Session Description support for included Data Objects
3.4.2.4. 含まれているData Objectsのセッション記述サポート
As an alternative to pointing to the data via a URI or an opaque reference to a data item held on the GSTN, it is possible to include the content data within the SIP request itself. This is done by using multipart MIME for the SIP payload. The first MIME part contains the SDP description of the telephone network session to be executed. The other MIME parts contain the content data to be transported.
GSTNに保持されたデータ項目のURIか不明瞭な参照でデータを示すことに代わる手段として、SIP要求自体の中に満足しているデータを含んでいるのは可能です。 SIPペイロードに複合MIMEを使用することによって、これをします。 最初のMIME部分は実行されるべき電話網セッションのSDP記述を含んでいます。 他のMIMEの部品は輸送されるべき満足しているデータを含んでいます。
Petrack & Conroy Standards Track [Page 18] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[18ページ]。
Format specific attribute lines within the session description are used to indicate which other MIME part within the request contains the content data. Instead of a URI or opaque reference, the format- specific attribute indicates the Content-ID of the MIME part of the request that contains the actual data, and is defined as:
セッション記述の中の形式の特定の属性系列は、要求の中のどの他のMIME部分が満足しているデータを含むかを示すのに使用されます。 URIか不明瞭な参照の代わりに、形式の特定の属性は実際のデータを含んでいて、以下と定義される要求のMIME部分のコンテントIDを示します。
<sub-part-ref> := ("spr:" Content-ID)
<サブ部分の審判>:=(「spr:」 コンテントID)
where Content-ID is as defined in Appendix A of [3] and in [10]).
コンテントIDが[3]のAppendix Aで定義されて[10])にあるところ。
For example:
例えば:
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain spr:<Content-ID>
+1-201-406-4090m=のTN RFC2543テキスト1c=ファックスの明瞭なa=fmtp: 明瞭なspr: <コンテントID>。
The <Content-ID> parameter is the Content-ID of one of the MIME parts inside the message, and this fragment means that the requesting user would like the data object held in the sub-part of this message labelled <Content-ID> to be faxed to the machine at phone number +1- 201-406-4090.
<コンテントID>パラメタはメッセージにおけるMIMEの部品の1つのコンテントIDです、そして、この断片は要求しているユーザが、電話番号+1 201-406-4090にマシンにファックスされるために<コンテントID>とラベルされたこのメッセージのサブ部分でデータ・オブジェクトを持って欲しいことを意味します。
See also section 3.5.1 for a discussion on the support needed in the enclosing SIP request for included data objects.
また、SIPが含まれているデータ・オブジェクトのために要求する同封で必要であるサポートについての議論に関してセクション3.5.1を見てください。
3.4.3. Attribute Tags to pass information into the Telephone Network
3.4.3. Tagsを結果と考えて、情報をTelephone Networkに通過してください。
It may be desired to include within the PINT request service parameters that can be understood only by some entity in the "Telephone Network Cloud". SDP attribute parameters are used for this purpose. They MAY appear within a particular media description or outside of a media description.
PINTの中に何らかの実体だけで「電話網雲」で理解できる要求サービスパラメタを含んでいるのは必要であるかもしれません。 SDP属性パラメタはこのために使用されます。 彼らは特定のメディア記述以内かメディア記述の外に現れるかもしれません。
These attributes may also appear as parameters within PINT URLS (see section 3.5.6) as part of a SIP request.
また、これらの属性はパラメタとしてSIP要求の一部としてのPINT URLS(セクション3.5.6を見る)の中に現れるかもしれません。
This is necessary so that telephone terminals that require the attributes to be defined can appear within the To: line of a PINT request as well as within PINT session descriptions.
これが、属性が定義されるのを必要とする電話端末がTo:の中に現れることができるくらい必要です。 要求とPINTセッション記述の中のPINTの系列。
The purpose of these attributes is to allow the client to specify extra context within which a particular telephone number is to be interpreted. There are many reasons why extra context might be necessary to interpret a given telephone number:
これらの属性の目的はクライアントが解釈される特定の電話番号がことである付加的な文脈を指定するのを許容することです。 付加的な文脈が与えられた電話番号を解釈するのに必要であるかもしれない多くの理由があります:
Petrack & Conroy Standards Track [Page 19] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[19ページ]。
a. The telephone number might be reachable in many different ways
(such as via competing telephone service providers), and the
PINT client wishes to indicate its selection of service
provider.
b. The telephone number might be reachable only from a limited
number of networks (such as an '800' freephone number).
c. The telephone number might be reachable only within a single
telephone network (such as the '152' customer service number of
BT). Similarly, the number might be an internal corporate
extension reachable only within the PBX.
a。 電話番号は多くの異なった方法(競争している電話サービスプロバイダーを通したなど)で届くかもしれません、そして、PINTクライアントはサービスプロバイダーbの選択を示したがっています。 電話番号はネットワーク('800'フリーダイヤル番号などの)単に限られた数のcから届いているかもしれません。 電話番号はただ一つの電話網(BTの'152'顧客認識番号などの)だけの中で届いているかもしれません。 同様に、数はPBXだけの中で届いている内部の法人の拡大であるかもしれません。
However, as noted above, it is not usually necessary to use SDP attributes to specify the phone context. URLs such as 152@pint.bt.co.il within the To: and From: headers and/or Request- URI, normally offer sufficient context to resolve telephone numbers.
しかしながら、上で述べたように、通常、電話文脈を指定するのにSDP属性を使用するのは必要ではありません。 To:の中の 152@pint.bt.co.il などのURL そして、From: ヘッダー、そして/または、Request URIで、通常、申し出電話番号を決議できるくらいの関係。
If the client wishes the request to fail if the attributes are not supported, these attributes SHOULD be used in conjunction with the "require" attribute (section 3.4.4) and the "Require:org.ietf.sdp.require" header (section 3.5.4).
クライアントが、属性がサポートされないなら失敗する要求、これらの属性SHOULDが「必要」に関連して使用されることを願うなら、(セクション3.4.4)と「: org.ietf.sdp.requireを必要としてください」というヘッダー(セクション3.5.4)を結果と考えてください。
It is not possible to standardise every possible internal telephone network parameter. PINT 1.0 attributes have been chosen for specification because they are common enough that many different PINT systems will want to use them, and therefore interoperability will be increased by having a single specification.
あらゆる可能な内線電話回路パラメータを標準化するのは可能ではありません。 1.0の属性が選ばれたPINTは、それらを使用して、したがって、それらが多くの異なったPINTシステムがそうしたくなるほど一般的であるので仕様は相互運用性を使用するので、ただ一つの仕様を持っていることによって、増強されるでしょう。
Proprietary attribute "a=" lines, that by definition are not interoperable, may be nonetheless useful when it is necessary to transport some proprietary internal telephone network variables over the IP network, for example to identify the order in which service call legs are to be be made. These private attributes SHOULD BE, however, subject to the same IANA registration procedures mentioned in the SDP specification[2] (see also this Appendix C).
独占属性「a=」が立ち並んでいて、IPネットワークの上でいくつかの独占内線電話ネットワーク変数を輸送して、例えばあるどの業務通話脚がことであることであるかでされたオーダーを特定するのが必要であるときに、それは、定義上共同利用できないで、それにもかかわらず、役に立つかもしれません。 これらの個人的な属性SHOULD BE、しかしながら、同じIANAを条件として、登録手順はSDPで仕様[2](また、このAppendix Cを見ます)に言及しました。
3.4.3.1. The phone-context attribute
3.4.3.1. 電話文脈属性
An attribute is specified to enable "remote local dialling". This is the service that allows a PINT client to reach a number from far outside the area or network that can usually reach the number. It is useful when the sending or receiving address is only dialable within some local context, which may be remote to the origin of the PINT client.
属性は、「リモート地方のダイヤルすること」を可能にするために指定されます。 これはPINTクライアントが通常、数に達することができる領域かネットワークの外でかけ離れるのから数に達することができるサービスです。 送付かアドレスを受け取るのが何らかのローカルの関係の中で「ダイヤル-可能」であるだけであるときに、それは役に立ちます。関係はPINTクライアントの生まれにリモートであるかもしれません。
For example, if Alice wanted to report a problem with her telephone, she might then dial a "network wide" customer care number; within the British Telecom network in the U.K., this is "152". Note that in this case she doesn't dial any trunk prefix - this is the whole dialable
例えば、アリスが報告したかったなら、彼女に関する問題に電話をして、彼女はその時がダイヤルする力です。aは顧客ケア番号を「広く、ネットワークでつなぎます」。 イギリスのブリティッシュ・テレコムネットワークの中では、これは「152」です。 この場合彼女がどんなトランク接頭語にもダイヤルしないことに注意してください--これは全体の「ダイヤル-可能」です。
Petrack & Conroy Standards Track [Page 20] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[20ページ]。
number. If dialled from another operator's network, it will not connect to British Telecom's Engineering Enquiries service; and dialling "+44 152" will not normally succeed. Such numbers are called Network-Specific Service Numbers.
数。 別のオペレータのネットワークからダイヤルされると、ブリティッシュ・テレコムのEngineering Enquiriesサービスに接続しないでしょう。 「そして、」 +44に通常、152がインチ引き継がないダイヤルすること。 そのような数はNetwork特有のService民数記と呼ばれます。
Within the telephone network, the "local context" is provided by the physical connection between the subscriber's terminal and the central office. An analogous association between the PINT client and the PINT server that first receives the request may not exist, which is why it may be necessary to supply this missing "telephone network context". This attribute is defined as follows:
電話網の中では、「ローカルの関係」は加入者の端末と電話局との物理接続によって提供されます。 要求が最初に受信されるPINTクライアントとPINTサーバとの類似の仲間はいないかもしれません(このなくなった「電話網文脈」を供給するのが必要であるかもしれない理由です)。 この属性は以下の通り定義されます:
a=phone-context: <phone-context-ident> phone-context-ident = network-prefix / private-prefix network-prefix = intl-network-prefix / local-network-prefix intl-network-prefix = "+" 1*DIGIT local-network-prefix = 1*DIGIT excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d)) private-prefix = 1*excldigandplus 0*uric
=電話文脈: ローカルのネットワーク<電話文脈個人的なident>電話文脈ident=ネットワーク接頭語/接頭語ネットワーク接頭語=intlネットワーク接頭語/接頭語intlネットワーク接頭語=「+」 *1ケタローカルのネットワーク接頭語=1*ケタexcldigandplus=(0×21 0x2d、0x2f、0×40 0x7d)個人的な接頭語=1*excldigandplus0*尿です。
An intl-network-prefix and local-network-prefix MUST be a bona fide
network prefix, and a network-prefix that is an intl-network-prefix
MUST begin with an E.164 service code ("country code").
intlネットワーク接頭語とローカルのネットワーク接頭語は誠実なネットワーク接頭語であるに違いありません、そして、intlネットワーク接頭語であるネットワーク接頭語はE.164接客規範(「国名略号」)で始まらなければなりません。
It is possible to register new private-prefixes with IANA so as to avoid collisions. Prefixes that are not so registered MUST begin with an "X-" to indicate their private, non-standard nature (see Appendix C).
新しい個人的な接頭語をIANAに登録するのは、衝突を避けるために可能です。 そのように登録されない接頭語は「X」と共に彼らの個人的で、標準的でない本質を示し始めなければなりません(付録Cを見てください)。
Example 1:
例1:
c= TN RFC2543 1-800-765-4321
a=phone-context:+972
電話TN RFC2543 1-800-765-4321c=a=文脈: +972
This describes an terminal whose address in Israel (E.164 country code 972) is 1-800-765-4321.
これはイスラエル(E.164国名略号972)のアドレスが1-800-765-4321である端末について説明します。
Example 2:
例2:
c= TN RFC2543 1-800-765-4321
a=phone-context:+1
電話TN RFC2543 1-800-765-4321c=a=文脈: +1
This describes an terminal whose address in North America (E.164 country code 1) is 1-800-765-4321.
これは北アメリカ(E.164国名略号1)のアドレスが1-800-765-4321である端末について説明します。
The two telephone terminals described by examples 1 and 2 are different; in fact they are located in different countries.
例1と2によって説明された2台の電話端末が異なっています。 事実上、それらは異なった国に位置しています。
Petrack & Conroy Standards Track [Page 21] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[21ページ]。
Example 3:
例3:
c=TN RFC2543 123
a=phone-context:+97252
=電話文脈あたりTN RFC2543c=123: +97252
This describes a terminal whose address when dialled from within the network identified by +97252 is the string "123". It so happens that +97252 defines one of the Israeli cell phone providers, and 123 reaches customer service when dialled within that network.
これは中からダイヤルされて、ネットワークが+97252を特定したアドレスがストリング「123」である端末について説明します。 偶然、+97252をイスラエルの携帯電話プロバイダーの1つを定義します、そして、そのネットワークの中でダイヤルされると、123は顧客サービスに達します。
It may well be useful or necessary to use the SDP "require" parameter in conjunction with the phone-context attribute.
SDPが電話文脈属性に関連してパラメタを「必要」が、使用に役に立つか、またはたぶん必要でしょう。
Example 4:
例4:
c= TN RFC2543 321
a=phone-context:X-acme.com-23
=電話文脈あたりTN RFC2543c=321: X-acme.com-23
This might describe the telephone terminal that is at extension 321 of PBX number 23 within the acme.com private PBX network. It is expected that such a description would be understandable by the acme.com PINT server that receives the request.
これはacme.comの私設のPBXネットワークの中にPBX No.23の拡大321にはある電話端末について説明するかもしれません。 そのような記述が要求を受け取るacme.com PINTサーバで理解できると予想されます。
Note that if the PINT server receiving the request is inside the acme.com network, the same terminal might be addressable as follows:
acme.comネットワークの中に要求を受け取るPINTサーバがあるなら、同じ端末が以下の通りアドレス可能であるかもしれないことに注意してください:
c= TN RFC2543 7-23-321
cはTN RFC2543 7-23-321と等しいです。
(assuming that "7" is dialled in order to reach the private PBX network from within acme.com)
(それを仮定する、「7インチがacme.comから私設のPBXネットワークに達するようにダイヤルされる、)、」
3.4.3.2. Presentation Restriction attribute
3.4.3.2. プレゼンテーションRestriction属性
Although it has no affect on the transport of the service request through the IP Network, there may be a requirement to allow originators of a PINT service request to indicate whether or not they wish the "B party" in the resulting service call to be presented with the "A party's" calling telephone number. It is a legal requirement in some jurisdictions that a caller be able to select whether or not their correspondent can find out the calling telephone number (using Automatic Number Indication or Caller Display or Calling Line Identity Presentation equipment). Thus an attribute may be needed to indicate the originator's preference.
IP Networkを通したサービスのリクエストの輸送に感情を全く持っていませんが、PINTサービスのリクエストの創始者が、彼らが「Aパーティー」の職業電話番号が与えられるという結果として起こる業務通話における「Bパーティー」を願っているかどうかを示すのを許容するという要件があるかもしれません。 それはいくつかの管内で訪問者が、彼らの通信員が呼ぶ電話番号を見つけることができるかどうかを(Automatic Number Indication、Caller DisplayまたはCalling線Identity Presentation設備を使用して)選択できるという法的必要条件です。 したがって、属性が、創始者の好みを示すのに必要であるかもしれません。
Whether or not the default behaviour of the Executive System is to present or not present a party's telephone number to the correspondent GSTN terminal is not specified, and it is not mandatory in all territories for a PINT Gateway or Executive System to act on
現在のプレゼントにはExecutive Systemのデフォルトのふるまいがあるか否かに関係なく、通信員GSTN端末へのパーティーの電話番号は指定されません、そして、それはPINTゲートウェイかExecutive Systemが影響するすべての領土で義務的ではありません。
Petrack & Conroy Standards Track [Page 22] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[22ページ]。
this attribute. It is, however, defined here for use where there are regulatory restrictions on GSTN operation, and in that case the Executive System can use it to honour the originator's request.
この属性。 しかしながら、GSTN操作には規定の制限があるところでそれは使用のためにここで定義されます、そして、その場合、Executive Systemは創始者の要求を尊敬するのにそれを使用できます。
The attribute is specified as follows:
a=clir:<"true" | "false">
属性は以下の通り指定されます: a=clir: <「本当」| 「誤った">"
This boolean value is needed within the attribute as it may be that the GSTN address is, by default, set to NOT present its identity to correspondents, and the originator wants to do so for this particular call. It is in keeping with the aim of this attribute to allow the originator to specify what treatment they want for the requested service call.
デフォルトで多分GSTNアドレスが通信員へのアイデンティティを提示しないように設定されるとき、このブール値が属性の中で必要です、そして、創始者はこの特定の呼び出しのためにそうしたがっています。 創始者が、彼らが要求された業務通話のためにどんな処理が欲しいかを指定するのを許容するためにこの属性の目的で保つのにおいてそれがあります。
The expected interpretation of this attribute is that, if it is present and the value is "false" then the Calling Line Identity CAN be presented to the correspondent terminal, whilst if it is "true" then if possible the Executive System is requested to NOT present the Calling Line Identity.
この属性の予想された解釈はそれが存在していて、値が「誤っている」なら、Calling線Identityを通信員端末まで寄贈できます、それが「本当である」ならできればExecutive SystemがCalling線Identityを寄贈しないよう要求されますがことです。
3.4.3.3. ITU-T CalledPartyAddress attributes parameters
3.4.3.3. ITU-T CalledPartyAddress属性パラメタ
These attributes correspond to fields that appear within the ITU-T Q.763 "CalledPartyAddress" field (see [8] ,section 3.9). PINT clients use these attributes in order to specify further parameters relating to Terminal Addresses, in the case when the address indicates a "local-phone-number". In the case that the PINT request contains a reference to a GSTN terminal, the parameters may be required to correctly identify that remote terminal.
これらの属性はITU-T Q.763「CalledPartyAddress」分野の中に現れる野原に対応しています([8]、セクション3.9を見てください)。 PINTクライアントはTerminal Addressesに関連するさらなるパラメタを指定するのにこれらの属性を使用します、アドレスが「ローカルの電話番号」を示すときの場合で。 PINT要求がGSTN端末の参照を含んでいて、パラメタが、正しくその遠隔端末を特定するのに必要であるかもしれません。
The general form of this attribute is: "a=Q763-<token>((":" <value>)
|"")". Three of the possible elements and their use in SDP
attributes are described here. Where other Q763 elements are to be
used, then these should be the subject of further specification to
define the syntax of the attribute mapping. It is recommended that
any such specification maintains the value sets shown in Q.763.
この属性の一般的なフォームは以下の通りです。 「「a=Q763、-、<トークン>(「:」 <値の>)|、」、」、)、」 3つの可能な要素とSDP属性における彼らの使用はここで説明されます。 Q763要素が使用されている他であるところでは、ことである、そして、これらが、属性マッピングの構文を定義するためにはさらなる仕様の対象であるべきです。 どんなそのような仕様もQ.763で見せられた選択値群を維持するのは、お勧めです。
The defined attributes are:
定義された属性は以下の通りです。
a=Q763-nature: - indicates the "nature of address indicator".
The value MAY be any number between 0 and 127.
The following values are specified:
a=Q763-自然: - 「アドレスインディケータの本質」を示します。 値はどんな0〜127の数であるかもしれません。 以下の値は指定されます:
"1" a subscriber number
"2" unknown
"3" a nationally significant number
"4" an internationally significant number
「1インチのa加入者番号、「2インチの未知、「3インチ、全国的に重要な数、「4インチ、国際的に重要な数、」
Petrack & Conroy Standards Track [Page 23] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[23ページ]。
The values have been chosen to coincide with the values in Q.763. Note that other values are possible, according to national rules or future expansion of Q.763.
値は、Q.763に値と同時に起こるように選ばれました。 Q.763の国家の規則か今後の拡張に従って他の値が可能であることに注意してください。
a=Q763-plan: - indicates the numbering plan to which the address
belongs. The value MAY be any number between 0
and 7. The following values are specified:
a=Q763-プラン: - アドレスが属する付番プランについて簡単に述べます。 値はどんな0〜7の数であるかもしれません。 以下の値は指定されます:
"1" Telephone numbering plan (ITU-T E.164)
"3" Data numbering plan (ITU-T X.121)
"4" Telex numbering plan (ITU-T F.69)
「1インチのTelephone付番プラン(ITU-T E.164)、「3インチのデータ付番プラン(ITU-T X.121)「4インチのテレックス付番プラン」(ITU-T F.69)
The values have been chosen to coincide with the values in Q.763. Other values are allowed, according to national rules or future expansion of Q.763.
値は、Q.763に値と同時に起こるように選ばれました。 Q.763の国家の規則か今後の拡張に従って、他の値は許容されています。
a=Q763-INN - indicates if routing to the Internal Network Number
is allowed. The value MUST be ONE of:
a=Q763-INN--Internal Network Numberへのルーティングが許されているかどうかを示します。 値は以下のONEでなければなりません。
"0" routing to internal network number allowed
"1" routing to internal network number not
allowed
「内部のネットワーク・ナンバーへの0インチのルーティングは「内部のネットワーク・ナンバーへのルーティングが許容しなかった1インチ」を許容しました。
The values have been chosen to coincide with the values in Q.763. Note that it is possible to use a local-phone-number and indicate via attributes that the number is in fact an internationally significant E.164 number. Normally this SHOULD NOT be done; an internationally significant E.164 number is indicated by using a "global-phone- number" for the address string.
値は、Q.763に値と同時に起こるように選ばれました。 ローカルの電話番号を使用して、事実上、数が国際的に重要なE.164番号であることを属性で示すのが可能であることに注意してください。 通常このSHOULD NOT、してください。 国際的に重要なE.164番号は、アドレスストリングの「グローバルな電話の数」を使用することによって、示されます。
3.4.4. The "require" attribute
3.4.4. 「必要」属性
According to the SDP specification, a PINT server is allowed simply to ignore attribute parameters that it does not understand. In order to force a server to decline a request if it does not understand one of the PINT attributes, a client SHOULD use the "require" attribute, specified as follows:
SDP仕様に従って、PINTサーバはそれが理解していない属性パラメタを単に、無視できます。 分からないならサーバを依頼を断らせるために、PINT属性の1つ、クライアントSHOULDは「必要」属性を使用します、以下の通り指定されて:
a=require:<attribute-list>
=は: <属性リスト>を必要とします。
where the attribute-list is a comma-separated list of attributes that appear elsewhere in the session description.
属性リストがセッション記述におけるほかの場所に現れる属性のコンマで切り離されたリストであるところ。
In order to process the request successfully the PINT server must BOTH understand the attribute AND ALSO fulfill the request implied by the presence of the attribute, for each attribute appearing within the attribute-list of the require attribute.
PINTサーバ必須BOTHが首尾よく要求を処理するためにAND ALSOが属性リストの中に現れる各属性のために属性の存在によって含意された要求を実現させる属性を理解している、属性を必要としてください。
Petrack & Conroy Standards Track [Page 24] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[24ページ]。
If the server does not recognise the attribute listed, the PINT server MUST return an error status code (such as 420 (Bad Extension) or 400 (Bad Request)), and SHOULD return suitable Warning: lines explaining the problem or an Unsupported: header containing the attribute it does not understand. If the server recognizes the attribute listed, but cannot fulfill the request implied by the presence of the attribute, the request MUST be rejected with a status code of (606 Not Acceptable), along with a suitable Unsupported: header or Warning: line.
サーバが記載された属性を認識しないなら、PINTサーバは誤りステータスコード(420(悪いExtension)としてのそのようなものか400(悪いRequest))を返さなければなりません、そして、SHOULDは適当なWarningを返します: 問題かUnsupportedがわかる系列: それが理解していない属性を含むヘッダー。 サーバが、記載しますが、属性が属性の存在によって含意された要求を実現させることができないと認めるなら、(606Not Acceptable)のステータスコードで要求を拒絶しなければなりません、適当なUnsupportedと共に: ヘッダーかWarning: 立ち並んでください。
The "require" attribute may appear anywhere in the session description, and any number of times, but it MUST appear before the use of the attribute marked as required.
「必要」属性はセッション記述、およびいろいろな回どこでも現れるかもしれませんが、それは必要に応じてマークされた属性の使用の前に現れなければなりません。
Since the "require" attribute is itself an attribute, the SIP specification allows a server that does not understand the require attribute to ignore it. In order to ensure that the PINT server will comply with the "require" attribute, a PINT client SHOULD include a Require: header with the tag "org.ietf.sdp.require" (section 3.5.4)
SIP仕様が「必要」属性がそれ自体で属性であるので分からないサーバを許容する、属性を必要として、それを無視してください。 PINTサーバが「必要」に従うのを確実にするために、属性、PINTクライアントSHOULDはRequireを含んでいます: タグ"org.ietf.sdp.require"があるヘッダー(セクション3.5.4)
Note that the majority of the PINT extensions are "tagged" and these tags can be included in Require strictures. The exception is the use of phone numbers in SDP parts. However, these are defined as a new network and address type, so that a receiving SIP/SDP server should be able to detect whether or not it supports these forms. The default behaviour for any SDP recipient is that it will fail a PINT request if it does not recognise or support the TN and RFC2543 or X-token network and address types, as without the contents being recognised no media session could be created. Thus a separate stricture is not required in this case.
PINT拡張子の大部分が「タグ付けをしてい」て、Require狭窄にこれらのタグを含むことができると述べてください。 例外はSDPの部品での電話番号の使用です。 しかしながら、これらは新しいネットワークとアドレスタイプと定義されます、受信SIP/SDPサーバが、それがこれらのフォームをサポートするかどうか検出できるべきであるように。どんなSDP受取人のためのデフォルトのふるまいもテネシーとRFC2543かX-トークンネットワークとアドレスタイプを見分けないか、またはサポートしないとPINT要求に失敗するということです、認識されるコンテンツなしでメディアセッションを全く作成できなかったとき。 したがって、別々の狭窄はこの場合必要ではありません。
3.5. PINT Extensions to SIP 2.0
3.5. 一口2.0へのパイント拡大
PINT requests are SIP requests; Many of the specifications within this document merely explain how to use existing SIP facilities for the purposes of PINT.
PINT要求はSIP要求です。 このドキュメントの中の仕様の多くで、単にPINTの目的に既存のSIP施設を使用する方法がわかります。
3.5.1. Multi-part MIME (sending data along with SIP request)
3.5.1. 複合MIME(SIPに伴うデータが要求する発信)
A PINT request can contain a payload which is multipart MIME. In this case the first part MUST contain an SDP session description that includes at least one of the format specific attribute tags for "included content data" specified above in section 3.4.3. Subsequent parts contain content data that may be transferred to the requested Telephone Call Service. As discussed earlier, within a single PINT request, some of the data MAY be pointed to by a URI within the request, and some of the data MAY be included within the request.
PINT要求は複合MIMEであるペイロードを含むことができます。 この場合、最初の部分はセクション3.4.3に少なくとも「含まれている満足しているデータ」のための特定の属性タグが上で指定した形式の1つを含んでいるSDPセッション記述を含まなければなりません。 その後の部品は要求されたTelephone Call Serviceに移されるかもしれない満足しているデータを含んでいます。 以前に検討したことであるが、いくつかのデータが要求の中にただ一つのPINT要求の中では、URIによって示されるかもしれなくて、いくつかのデータが要求の中に含まれるかもしれません。
Petrack & Conroy Standards Track [Page 25] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[25ページ]。
Where included data is carried within a PINT service request, the Content Type entity header of the enclosing SIP message MUST indicate this. To do so, the media type value within this entity header MUST be set to a value of "multipart". There is a content sub-type that is intended for situations like this in which sub-parts are to be handled together. This is the multipart/related type (defined in [19]), and it's use is recommended.
含まれているデータがPINTサービスのリクエストの中で運ばれるところでは、同封のSIPメッセージのContent Type実体ヘッダーはこれを示さなければなりません。 そうするために、タイプがこの実体ヘッダーの中に評価するメディアを「複合」の値に設定しなければなりません。 サブの部品が一緒に扱われることになっているこのような状況のために意図する満足しているサブタイプがあります。 複合の、または、関連するタイプが(であるという定義されたコネ[19])、およびそれこの使用はお勧めです。
The enclosed body parts SHOULD include the part-specific Content Type
headers as appropriate ("application/sdp" for the first body part
holding the session description, with an appropriate content type for
each of the subsequent, "included data object" parts). This matches
the standard syntax of MIME multipart messages as defined in [4].
同封のボディーパートSHOULDは適宜(それぞれのその後の「含まれているデータ・オブジェクト」の部品への適切なcontent typeがあるセッション記述を保持する最初の身体の部分の「アプリケーション/sdp」)部分特有のContent Typeヘッダーを含んでいます。 これは[4]で定義されるようにMIMEの複合メッセージの標準の構文に合っています。
For example, in a multipart message where the string
例えば、a複合では、どこを通信させてくださいか、ストリング
"------next-------" is the boundary, the first two parts might be as follows:
"------次へ-------「境界であり、最初の2つの部品は以下の通りであるかもしれないということです:、」
------next-------
Content-Type: application/sdp
....
c= TN RFC2543 +1-201-406-4090
m= text 1 pager plain
a=fmtp:plain spr:17@mymessage.acme.com
------次へ------- コンテントタイプ: アプリケーション/sdp… cは1つのポケットベルのTN RFC2543の+1-201-406-4090m=のテキストの明瞭なa=fmtp: 明瞭なspr: 17@mymessage.acme.com と等しいです。
----------next-------
Content-Type: text/plain
Content-ID: 17@mymessage.acme.com
----------次へ------- コンテントタイプ: テキスト/明瞭なコンテントID: 17@mymessage.acme.com
This is the text that is to be paged to +1-201-406-4090
これは+1-201-406-4090まで呼び出されることになっているテキストです。
----------next-----------
----------次へ-----------
The ability to indicate different alternatives for the content to be transported is useful, even when the alternatives are included within the request. For example, a request to send a short message to a pager might include the message in Unicode [5] and an alternative version of the same content in text/plain, should the PINT server or telephone network not be able to process the unicode.
内容が輸送されるために異なった代替手段を示す能力は役に立ちます、代替手段が要求の中に含まれるときさえ。 例えば、短いメッセージをポケットベルに送るという要求はテキスト/平野にユニコード[5]によるメッセージと同じ内容の異本を含むかもしれません、PINTサーバか電話網がユニコードを処理できないなら。
PINT clients should be extremely careful when sending included data within a PINT request. Such requests SHOULD be sent via TCP, to avoid fragmentation and to transmit the data reliably. It is possible that the PINT server is a proxy server that will replicate and fork the request, which could be disastrous if the request contains a large amount of application data. PINT proxy servers should be careful not to create many copies of a request with large amounts of data in it.
送付がPINT要求の中にデータを含んでいたとき、PINTクライアントは非常に慎重であるはずです。 そのようなものは、SHOULDが断片化を避けて、データを確かに送るためにTCPを通して送られるよう要求します。 PINTサーバが要求が多量のアプリケーションデータを含んでいるなら悲惨であるかもしれない要求を模写して、分岐させるプロキシサーバであることは可能です。 PINTプロキシサーバは、多量のデータがそれにある状態で要求の多くのコピーを作成しないように慎重であるはずです。
Petrack & Conroy Standards Track [Page 26] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[26ページ]。
If the client does not know the actual location of the PINT gateway, and is using the SIP location services to find it, and the included data makes the PINT request likely to be transported in several IP datagrams, it is RECOMMENDED that the initial PINT request not include the data object but instead hold a reference to it.
クライアントがPINTゲートウェイの実際の場所を知らないで、PINTがデータから要求するそれ、および包含が数個のIPデータグラムで輸送されそうであるのがわかるのにSIP位置のサービスを利用しているなら、それは初期のPINTがデータ・オブジェクトを含んでいませんが、代わりにそれの参照を保持するよう要求するRECOMMENDEDです。
3.5.2. Warning header
3.5.2. 警告ヘッダー
A PINT server MUST support the SIP "Warning:" header so that it can signal lack of support for individual PINT features. As an example, suppose the PINT request is to send a jpeg picture to a fax machine, but the server cannot retrieve and/or translate jpeg pictures from the Internet into fax transmissions.
PINTサーバがSIPをサポートしなければならない、「警告:」 それは、ヘッダー、合図するので、個々のPINTの特徴のサポートの不足に合図できます。 例として、PINT要求がjpeg画像を送ることであるなら、サーバだけが、jpeg画像をファックス送信へのインターネットからファックス装置に、検索する、そして/または、翻訳できません。
In such a case the server fails the request and includes a Warning such as the following:
このような場合にはサーバは、要求に失敗して、以下などのWarningを含んでいます:
Warning: 305 pint.acme.com Incompatible media format: jpeg
警告: 305 pint.acme.com Incompatibleメディア形式: jpeg
SIP servers that do not understand the PINT extensions at all are strongly encouraged to implement Warning: headers to indicate that PINT extensions are not understood.
全くPINT拡張子を理解していないSIPサーバがWarningを実装するよう強く奨励されます: PINT拡張子が理解されていないのを示すヘッダー。
Also, Warning: headers may be included within NOTIFY requests if it is necessary to notify the client about some condition concerning the invocation of the PINT service (see next).
警告も: 何らかの状態に関してPINTサービスの実施に関してクライアントに通知するのが必要であるなら(次にを見てください)、ヘッダーはNOTIFY要求の中に含まれるかもしれません。
3.5.3. Mechanism to register interest in the disposition of a PINT
service, and to receive indications on that disposition
3.5.3. PINTサービスの気質への関心を示して、その気質で指摘を受けるメカニズム
It can be very useful to find out whether or not a requested service has completed, and if so whether or not it was successful. This is especially true for PINT service, where the person requesting the service is not (necessarily) a party to it, and so may not have an easy way of finding out the disposition of that service. Equally, it may be useful to indicate when the service has changed state, for example when the service call has started.
aが、サービスが完成したよう要求したかどうかと、そうだとすれば、それがうまくいったかどうか見つけるのは非常に役に立つ場合があります。 PINTサービスに、これは特に本当です、サービスを要求する人が(必ず)それへのパーティーでないのでそのサービスの気質を見つける簡単な方法を持っていないかもしれないところで。 等しく、サービスがいつ状態を変えたかを示すのは役に立つかもしれません、例えば、業務通話が始まったとき。
Arranging a flexible system to provide extensive monitoring and control during a service is non-trivial (see section 6.4 for some issues); PINT 1.0 uses a simple scheme that should nevertheless provide useful information. It is possible to expand the scheme in a "backwards compatible" manner, so if required it can be enhanced at a later date.
サービスの間、大規模なモニターとコントロールを提供するためにフレキシブルなシステムをアレンジするのは重要です(いくつかの問題に関してセクション6.4を見てください)。 PINT1.0はそれにもかかわらず、役に立つ情報を提供するべきである簡単な体系を使用します。 aで体系を広げるのが可能である、「後方に、」 方法、必要ならそれを高めることができるaが後で日付を入れるコンパチブルそう。
The PINT 1.0 status registration and indication scheme uses three new methods; SUBSCRIBE, UNSUBSCRIBE, and NOTIFY. These are used to allow a PINT client to register an interest in (or "subscribe" to) the
3つのPINT1.0状態登録と指示体系用途の新しいメソッド。 申し込んでください、そして、外してください、そして、通知してください。 または、PINTクライアントが関心を示すのを許容するのにおいてこれらが使用されている、(「申し込む」、)
Petrack & Conroy Standards Track [Page 27] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[27ページ]。
status of a service request, to indicate that a prior interest has lapsed (i.e "unsubscribe" from the status), and for the server to return service indications. The state machine of SUBSCRIBE/UNSUBSCRIBE is identical to that of INVITE/BYE; just as INVITE signals the beginning and BYE signals the end of participation in a media session, SUBSCRIBE signals the beginning and UNSUBSCRIBE signals the end of participation in a monitoring session. During the monitoring session, NOTIFY messages are sent to inform the subscriber of a change in session state or disposition.
サービスのリクエストの状態、それを示すために、先の関心は経過しました、そして、(i.eは状態から「外す」)サーバが戻るのが指摘を修理します。 マシンを述べる、登録、/、登録削除、INVITE/BYEのものと同じです。 そして、登録、ちょうど、INVITEが始めに合図して、BYEがメディアセッションにおける参加の終わりに合図するように始めに合図する、登録削除、モニターしているセッションにおける参加の終わりの信号。 モニターしているセッション、メッセージがセッション状態の変化について加入者に知らせるために送られるNOTIFYまたは気質の間。
3.5.3.1. Opening a monitoring session with a SUBSCRIBE request
3.5.3.1. 登録とのモニターしているセッションが要求する始まり
When a SUBSCRIBE request is sent to a PINT Server, it indicates that a user wishes to receive information about the status of a service session. The request identifies the session of interest by including the original session description along with the request, using the SDP global-session-id that forms part of the origin-field to identify the service session uniquely.
登録ときに、要求をPINT Serverに送って、それは、ユーザがサービスセッションの状態の情報を受け取りたがっているのを示します。 要求は要求に伴うオリジナルのセッション記述を含んでいることによって、興味があるセッションを特定します、唯一サービスセッションを特定するために発生源分野の一部を形成するSDPのグローバルなセッションイドを使用して。
The SUBSCRIBE request (like any other SIP request about an ongoing session) is sent to the same server as was sent the original INVITE, or to a server which was specified in the Contact: field within a subsequent response (this might well be the PINT gateway for the session).
登録、オリジナルのINVITEを送ったこと、または、Contactで指定されたサーバへの同じサーバに要求(進行中のおよそセッションいかなる他のSIP要求のようなも)を送ります: その後の応答(これはたぶんセッションのためのPINTゲートウェイである)の中でさばきます。
Whilst there are situations in which re-use of the Call-ID used in the original INVITE that initiated the session of interest is possible, there are other situations in which it is not. In detail, where the subscription is being made by the user who initiated the original service request, the Call-ID may be used as it will be known to the receiver to refer to a previously established session. However, when the request comes from a user other than the original requesting user, the SUBSCRIBE request constitutes a new SIP call leg, so the Call-ID SHOULD NOT be used; the only common identifier is the origin-field of the session description enclosed within the original service request, and so this MUST be used.
興味があるセッションを開始したオリジナルのINVITEで使用されるCall-IDの再使用が可能である状況がありますが、それがそうでない他の状況があります。 詳細に、以前に確立したセッションを参照するのが受信機に知られるとき、購読がオリジナルのサービスのリクエストを開始したユーザによってされているところでCall-IDは使用されるかもしれません。 要求は新しいSIP呼び出し脚を構成します、そのように、Call-ID SHOULD NOT。しかしながら、要求がユーザを要求するオリジナル以外のユーザから来ると登録、使用されてください。 唯一の一般的な識別子がオリジナルのサービスのリクエストの中に同封されたセッション記述の発生源分野であるので、これを使用しなければなりません。
Rather than have two different methods of identifying the "session of interest" the choice is to use the origin-field of the SDP sub-part included both in the original INVITE and in this SUBSCRIBE request.
ともにオリジナルのINVITEにSDPサブ部分を含んでいて、選択が発生源分野を使用することになっている「興味があるセッション」を特定する2つの異なったメソッドを持っていてこれのラザー、登録、要求。
Note that the request MUST NOT include any sub-parts other than the session description, even if these others were present in the original INVITE request. A server MUST ignore whatever sub-parts are included within a SUBSCRIBE request with the sole exception of the enclosed session description.
要求がセッション記述以外のどんなサブの部品も含んではいけないことに注意してください、これらの他のものがオリジナルのINVITE要求に出席していたとしても。 サーバは同封のセッション記述の唯一の例外がある登録の中に含まれているどんなサブの部品要求も無視しなければなりません。
Petrack & Conroy Standards Track [Page 28] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[28ページ]。
The request MAY contain a "Contact:" header, specifying the PINT User Agent Server to which such information should be sent.
5月がaを含んでいるという要求は「以下に連絡します」。 ヘッダー、PINT UserエージェントServerをどのそのようなものに指定して、情報を送るべきです。
In addition, it SHOULD contain an Expires: header, which indicates for how long the PINT Requestor wishes to receive notification of the session status. We refer to the period of time before the expiration of the SUBSCRIBE request as the "subscription period". See section 5.1.4. for security considerations, particularly privacy implications.
さらに、それ、SHOULDはExpiresを含んでいます: ヘッダー。(そのヘッダーは、どれくらい長い間、PINT Requestorがセッション状態の通知を受け取りたがっているのを示すか)。 私たちが満了の前に期間を参照する、登録、「販売期間」として、要求します。 セキュリティ問題、特にプライバシー含意に関して.4にセクション5.1を見てください。
A value of 0 within the Expires: header indicates a desire to receive one single immediate response (i.e. the request expires immediately). It is possible for a sequence of monitoring sessions to be opened, exist, and complete, all relating to the same service session.
Expiresの中の0の値: ヘッダーは1つのただ一つの即時型反応を受ける願望を示します(すなわち、要求はすぐに、期限が切れます)。 モニターしているセッションの系列が開かれるのが、可能であり、存在してください、そして、完全であることで、同じくらいすべて関連して、セッションを修理してください。
A successful response to the SUBSCRIBE request includes the session description, according to the Gateway. Normally this will be identical to the last cached response that the Gateway returned to any request concerning the same SDP global session id (see [2], section 6, o= field). The t= line may be altered to indicate the actual start or stop time, however. The Gateway might add an i= line to the session description to indicate such information as how many fax pages were sent. The Gateway SHOULD include an Expires: header indicating how long it is willing to maintain the monitoring session. If this is unacceptable to the PINT Requestor, then it can close the session by sending an immediate UNSUBSCRIBE message (see 3.5.3.3).
うまくいっている応答、登録、ゲートウェイによると、要求はセッション記述を含んでいます。 通常、これはゲートウェイが同じSDPのグローバルなセッションイドに関してどんな要求にも返した最後にキャッシュされた応答と同じになるでしょう([2]を見てください、セクション6、o=分野)。 t=系列は、しかしながら、実際の始めか停止時間を示すために変更されるかもしれません。ゲートウェイは、いくつのファックスページを送ったかような情報を示すためにi=系列をセッション記述に加えるかもしれません。 ゲートウェイSHOULDはExpiresを含んでいます: それが、どれくらい長い間モニターしているセッションを維持しても構わないと思っているかを示すヘッダー。 見てください。これがPINT Requestorに容認できないなら発信することによってセッションを終えることができる、即座である、登録削除、メッセージ、(3.5 .3 .3)。
In principle, a user might send a SUBSCRIBE request after the telephone network service has completed. This allows, for example, checking up "the morning after" to see if the fax was successfully transmitted. However, a PINT gateway is only required to keep state about a call for as long as it indicated previously in an Expires: header sent within the response to the original INVITE message that triggered the service session, within the response to the SUBSCRIBE message, within the response to any UNSUBSCRIBE message, or within its own UNSUBSCRIBE message (but see section 3.5.8, point 3).
原則として、ユーザはサービスが完成した電話網の後に要求を登録に送るかもしれません。 これは、例えば、「翌朝」のときにファックスが首尾よく送られたかどうかを見るために調査するのを許容します。 しかしながら、PINTゲートウェイが中に以前に、Expiresを示した限り、呼び出しに関して状態を維持するのに必要であるだけです: ヘッダーが応答の中でサービスセッションの引き金となったオリジナルのINVITEメッセージへの応答の中で発信した、登録、いずれへの応答の中で登録削除を通信してください、通信するか、またはそれ自身のところの中で登録削除、メッセージ(セクション3.5.8を見てください、そして、3を指してください)。
If the Server no longer has a record of the session to which a Requestor has SUBSCRIBEd, it returns "606 Not Acceptable", along with the appropriate Warning: 307 header indicating that the SDP session ID is no longer valid. This means that a requesting Client that knows that it will want information about the status of a session after the session terminates SHOULD send a SUBSCRIBE request before the session terminates.
ServerにRequestorにはSUBSCRIBEdがあるセッションに関する記録がもうないなら、「許容できない606」を返します、適切なWarningと共に: SDPセッションIDがもう有効でないことを示す307ヘッダー。 これは、セッションが終わる前にセッションがSHOULDを終えた後にセッションの状態の情報が欲しくなるのを知っている要求Clientが要求を登録に送ることを意味します。
Petrack & Conroy Standards Track [Page 29] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[29ページ]。
3.5.3.2. Sending Status Indications with a NOTIFY request
3.5.3.2. NOTIFYとStatus Indicationsが要求する発信
During the subscription period, the Gateway may, from time to time, send a spontaneous NOTIFY request to the entity indicated in the Contact: header of the "opening" SUBSCRIBE request. Normally this will happen as a result of any change in the status of the service session for which the Requestor has subscribed.
販売期間の間、ゲートウェイは時々自然発生的なNOTIFY要求をContactで示された実体に送るかもしれません: 「始まり」のヘッダー、登録、要求。 通常、これはRequestorが申し込んだサービスセッションの状態のどんな変化の結果、起こるでしょう。
The receiving user agent server MUST acknowledge this by returning a final response (normally a "200 OK"). In this version of the PINT extensions, the Gateway is not required to support redirects (3xx codes), and so may treat them as a failure.
受信ユーザエージェントサーバは、最終的な応答(通常「200OK」)を返すことによって、これを承認しなければなりません。 ゲートウェイによる必要でないことで、(3xxコード)をサポートに向け直すので失敗としてそれらを扱うかもしれないというPINT拡張子のこのバージョンでは、ことです。
Thus, if the response code class is above 2xx then this may be treated by the Gateway as a failure of the monitoring session, and in that situation it will immediately attempt to close the session (see next).
したがって、2xxの上に応答コードのクラスがあるなら、これはモニターしているセッションの失敗としてゲートウェイが扱われるかもしれません、そして、その状況で、それはすぐに、セッションを終えるのを試みるでしょう(次にを見てください)。
The NOTIFY request contains the modified session description. For example, the Gateway may be able to indicate a more accurate start or stop time.
NOTIFY要求は変更されたセッション記述を含んでいます。 例えば、ゲートウェイは、より正確な始めか停止時間を示すことができるかもしれません。
The Gateway may include a Warning: header to describe some problem with the invocation of the service, and may indicate within an i= line some information about the telephone network session itself.
ゲートウェイはWarningを含めるかもしれません: ヘッダー、サービスの実施に関する何らかの問題について説明してください、そして、電話網セッション自体頃にi=系列の中に何らかの情報を示してもよいです。
Example:
NOTIFY sip:petrack@pager.com SIP/2.0
To: sip:petrack@pager.com
From: sip:R2F.pint.com@service.com
Call-ID: 19971205T234505.56.78@pager.com
CSeq: 4711 SUBSCRIBE
Warning: xxx fax aborted, will try for the next hour.
Content-Type:application/sdp
例: NOTIFY一口: petrack@pager.com SIP/2.0To: 一口: petrack@pager.com From: 一口: R2F.pint.com@service.com Call-ID: 19971205T234505.56.78@pager.com CSeq: 4711は警告を申し込みます: xxxファックスは中止になって、次の時間に試みるでしょう。 コンテントタイプ: アプリケーション/sdp
c=...
i=3 pages of 5 sent
t=...
5のc=…i=3ページはt=を送りました…
3.5.3.3. Closing a monitoring session with an UNSUBSCRIBE request
3.5.3.3. 登録削除とのモニターしているセッションが要求する閉鎖
At some point, either the Client's representative User Agent Server or the Gateway may decide to terminate the monitoring session. This is achieved by sending an UNSUBSCRIBE request to the correspondent server. Such a request indicates that the sender intends to close the monitoring session immediately, and, on receipt of the final response from the receiving server, the session is deemed over.
何らかのポイントでは、ClientのUserエージェントServer代表かゲートウェイのどちらかが、モニターしているセッションを終えると決めるかもしれません。 これは、要求を登録削除に送ることによって、通信員サーバに実現されます。そのような要求は、送付者がすぐに、モニターしているセッションを終えるつもりであり、受信サーバからの最終的な応答を受け取り次第セッションが終わっていると考えられるのを示します。
Petrack & Conroy Standards Track [Page 30] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[30ページ]。
Note that unlike the SUBSCRIBE request, which is never sent by a PINT gateway, an UNSUBSCRIBE request can be sent by a PINT gateway to the User Agent Server to indicate that the monitoring session is closed. (This is analogous to the fact that a gateway never sends an INVITE, although it can send a BYE to indicate that a telephone call has ended.)
それに注意する、登録、どれが決して発信しないかはPINTゲートウェイによってUserエージェントServerに送られてモニターしているセッションが閉じられるのを示すことができる登録削除が、PINT門、要求する要求してください。 (これはゲートウェイがINVITEを決して送らないという事実に類似しています、通話が終わったのを示すためにBYEを送ることができますが。)
If the Gateway initiates closure of the monitoring session by sending an UNSUBSCRIBE message, it SHOULD include an "Expires:" header showing for how much longer after this monitoring session is closed it is willing to store information on the service session. This acts as a minimum time within which the Client can send a new SUBSCRIBE message to open another monitoring session; after the time indicated in the Expires: header the Gateway is free to dispose of any record of the service session, so that subsequent SUBSCRIBE requests can be rejected with a "606" response.
ゲートウェイがメッセージを登録削除に送ることによってモニターしているセッションの閉鎖を開始して、それがSHOULDインクルードである、「以下を吐き出します」。 この後より長い間セッションをモニターするのがどれほど閉じられるかためにそれが、サービスセッションの情報を保存しても構わないと思っているのを示すヘッダー。 これがClientがaを送ることができる最小の時として新しく機能する、登録、別のモニターしているセッションを開くメッセージ。 時にExpiresで示された後: ヘッダーゲートウェイが自由にサービスセッションに関するどんな記録も処分できる、登録、要求は、その後ためのそうであることができます。「606」応答で、拒絶されます。
If the subscription period specified by the Client has expired, then the Gateway may send an immediate UNSUBSCRIBE request to the Client's representative User Agent Server. This ensures that the monitoring session always completes with a UNSUBSCRIBE/response exchange, and that the representative User Agent Server can avoid maintaining state in certain circumstances.
Clientの代表しているUserエージェントにServerを要求してください。Clientによって指定された販売期間が期限が切れたならゲートウェイが発信するかもしれない、即座である、登録削除、これは、モニターしているセッションがいつも登録削除で/応答交換を終了して、UserエージェントServer代表が、ある特定の状況では状態を維持するのを避けることができるのを保証します。
3.5.3.4. Timing of SUBSCRIBE requests
3.5.3.4. 調節する、登録、要求
As it relies on the Gateway having a copy of the INVITEd session description, the SUBSCRIBE message is limited in when it can be issued. The Gateway must have received the service request to which this monitoring session is to be associated, which from the Client's perspective happens as soon as the Gateway has sent a 1xx response back to it.
登録、メッセージはそうです。INVITEdセッション記述のコピーを持っているゲートウェイを当てにするとき制限する、それを発行できるとき、中では、制限されます。 ゲートウェイは関連しているこのモニターしているセッションがことであるサービスのリクエストを受け取ったに違いなくて、どれがゲートウェイの次第Clientの見解から起こるかが1xx応答をそれに送り返しました。
However, once this has been done, there is no reason why the Client should not send a monitoring request. It does not have to wait for the final response from the Gateway, and it can certainly send the SUBSCRIBE request before sending the ACK for the Service request final response. Beyond this point, the Client is free to send a SUBSCRIBE request when it decides, unless the Gateway's final response to the initial service request indicated a short Expires: time.
しかしながら、これがいったん完了していると、Clientがモニターしている要求を送るはずがない理由が全くありません。 ゲートウェイから最終的な応答を待つ必要はなくて、確かに、発信できる、登録、発信する前に、ServiceのためのACKが最終的な応答を要求するよう要求してください。 決めるとき、このポイントを超えて、Clientは自由に要求を登録に送ることができます、初期のサービスのリクエストへのゲートウェイの最終的な応答が短いExpiresを示さなかったなら: 時間。
However, there are good reasons (see 6.4) why it may be appropriate to start a monitoring session immediately before the service is confirmed by the PINT Client sending an ACK. At this point the Gateway will have decided whether or not it can handle the service request, but will not have passed the request on to the Executive System. It is therefore in a good position to ask the Executive
しかしながら、サービスがPINT Clientによって確認される直前モニターしているセッションがACKを送り始めるのが、適切であるかもしれない十分な理由(6.4を見る)があります。 ここに、ゲートウェイは、それがサービスのリクエストを扱うことができるかどうか決めてしまうでしょうが、要求にExecutive Systemに合格していないでしょう。 それはしたがって、Executiveに尋ねる良い立場にあります。
Petrack & Conroy Standards Track [Page 31] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[31ページ]。
System to enable monitoring when it sends the service request onwards. In practical implementations, it is likely that more information on transient service status will be available if this is indicated as being important BEFORE or AS the service execution phase starts; once execution has begun the level of information that can be returned may be difficult to change.
前方へサービスのリクエストを送るときモニターを可能にするシステム。 実用的な実装では、利用可能であるのはこれがサービス実行段階が始動する重要なBEFOREかASであるとして示されるなら一時的なサービス状態に関する詳しい情報がなる傾向があります。 実行がいったん始まると、返すことができる情報のレベルは変えるのが難しいかもしれません。
Thus, whilst it is free to send a SUBSCRIBE request at any point after receiving an Interim response from the Gateway to its service request, it is recommended that the Client should send such a monitoring request immediately prior to sending an ACK message confirming the service if it is interested in transient service status messages.
したがって、自由に登録を送ることができる間、Interim応答を受けた後の任意な点でゲートウェイからサービスのリクエストまで、それは一時的なサービスステータスメッセージに関心があるならACKメッセージにサービスを確認させるすぐ前にClientがそのようなモニターしている要求を送るはずであるのが、お勧めであるよう要求してください。
3.5.4. The "Require:" header for PINT
3.5.4. 「以下を必要としてください」 PINTのためのヘッダー
PINT clients use the Require: header to signal to the PINT server that a certain PINT extension of SIP is required. PINT 1.0 defines two strings that can go into the Require header:
PINTクライアントはRequireを使用します: SIPのあるPINT拡張子がPINTサーバですが、合図するヘッダーが必要です。 PINT1.0はRequireヘッダーに入ることができる2個のストリングを定義します:
org.ietf.sip.subscribe -- the server can fulfill SUBSCRIBE requests
and associated methods (see section 3.5.3)
org.ietf.sip.subscribe、--、サーバが実現できる登録、要求と関連メソッド(セクション3.5.3を見ます)
org.ietf.sdp.require -- the PINT server (or the SDP parser
associated to it) understands the "require"
attribute defined in (section 3.4.4)
org.ietf.sdp.require--サーバ(または、それに関連づけられたSDPパーサ)が定義された「必要」属性を理解しているPINT(セクション3.4.4)
Example:
Require:org.ietf.sip.subscribe,org.ietf.sdp.require
例: : org.ietf.sip.subscribe、org.ietf.sdp.requireを必要としてください。
A client SHOULD only include a Require: header where it truly requires the server to reject the request if the option is not supported.
クライアントSHOULDはRequireを含んでいるだけです: 本当に、要求を拒絶するのがサーバを必要とするヘッダーはオプションであるなら支えられません。
3.5.5. PINT URLs within PINT requests
3.5.5. PINT要求の中のPINT URL
Normally the hostnames and domain names that appear in the PINT URLs are the internal affair of each individual PINT system. A client uses the appropriate SDP payload to indicate the particular service it wishes to invoke; it is not necessary to use a particular URL to identify the service.
通常、PINT URLに現れるホスト名とドメイン名はそれぞれの個々のPINTシステムの内部の事です。 クライアントはそれが呼び出したがっている特定のサービスを示すのに適切なSDPペイロードを使用します。 サービスを特定するのに特定のURLを使用するのは必要ではありません。
A PINT URL is used in two different ways within PINT requests: within the Request-URI, and within the To: and From: headers. Use within the Request-URI requires clarification in order to ensure smooth interworking with the Telephone Network serviced by the PINT infrastructure, and this is covered next.
PINT URLはPINT要求の中で2つの異なった方法で使用されます: 要求URI、およびTo: そして、From: ヘッダー。 Request-URIの中の使用はTelephone NetworkがPINTインフラストラクチャによって調整されている滑らかな織り込むことを確実にするために明確化を必要とします、そして、これは次に、カバーされています。
Petrack & Conroy Standards Track [Page 32] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[32ページ]。
3.5.5.1. PINT URLS within Request-URIs
3.5.5.1. 要求URIの中のパイントURLS
There are some occasions when it may be useful to indicate service information within the URL in a standardized way:
URLの中に標準化された方法でサービス情報を示すのが役に立つかもしれないいくつかの時があります:
a. it may not be possible to use SDP information to route the
request if it is encrypted;
b. it allows implementation that make use of I.N. "service
indicators";
c. It enables multiple competing PINT gateways to REGISTER with a
single "broker" server (proxy or redirect) (see section 6.3)
a. それが暗号化されているなら、要求を発送するのにSDP情報を使用するのは可能でないかもしれません。 b. それはI.N.「サービスインディケータ」を利用する実装を許容します。 c。 ただ一つの「ブローカー」サーバが(プロキシか再直接)でそれはREGISTERへの複数の競争しているPINTゲートウェイを可能にします。(セクション6.3を見ます)
For these reasons, the following conventions for URLs are offered for use in PINT requests:
これらの理由で、PINT要求における使用のためにURLのための以下のコンベンションを提供します:
1. The user portion of a sip URL indicates the service to be requested. At present the following services are defined:
1. 1つの一口URLのユーザ部分は、要求されているためにサービスを示します。 現在のところ、以下のサービスは定義されます:
R2C (for Request-to-Call) R2F (for Request-to-Fax) R2HC (for Request-to-Hear-Content)
R2C(呼ぶという要求のための)R2F(ファックスで送る要求のための)R2HC(内容を聞くという要求のための)
The user portions "R2C", "R2F", and "R2HC" are reserved for the PINT milestone services. Other user portions MUST be used in case the requested service is not one of the Milestone services. See section 6.2 for some related considerations concerning registrations by competing PINT systems to a single PINT proxy server acting as a service broker.
ユーザ部分の"R2C"、"R2F"、および"R2HC"はパイント重大事件サービスのために予約されます。 要求されたサービスがMilestoneサービスの1つでないといけないので、他のユーザ部分を使用しなければなりません。 いくつかのためのセクション6.2が競争しているPINTシステムで登録証明書に関してサービスブローカーとして務めるただ一つのPINTプロキシサーバに問題を関係づけたのを確実にしてください。
2. The host portion of a sip URL contains the domain name of the PINT service provider.
2. 1つの一口URLのホスト部分はPINTサービスプロバイダーのドメイン名を含んでいます。
3. A new url-parameter is defined to be "tsp" (for "telephone service provider"). This can be used to indicate the actual telephone network provider to be used to fulfill the PINT request.
3. 新しいurl-パラメタは、「ティースプーンフル」(「電話サービスプロバイダー」のための)になるように定義されます。 PINT要求を実現させるのに使用されるために実際の電話ネットワーク内の提供者を示すのにこれを使用できます。
Thus, for example:-
INVITE sip:R2C@pint.pintservice.com SIP/2.0
INVITE sip:R2F@pint.pintservice.com;tsp=telco.com SIP/2.0
INVITE sip:R2HC@pint.mycom.com;tsp=pbx23.mycom.com SIP/2.0
INVITE sip:13@pint.telco.com SIP/2.0
このようにして、そして、例えば:、-INVITEはちびちび飲みます: R2C@pint.pintservice.com SIP/2.0 INVITEはちびちび飲みます: R2F@pint.pintservice.com;tsp はtelco.com SIP/2.0INVITE一口と等しいです: R2HC@pint.mycom.com;tsp はpbx23.mycom.com SIP/2.0INVITE一口: 13@pint.telco.com SIP/2.0と等しいです。
3.5.6. Telephony Network Parameters within PINT URLs
3.5.6. パイントURLの中の電話回路パラメータ
Any legal SIP URL can appear as a PINT URL within the Request-URI or To: header of a PINT request. But if the address is a telephone address, we indicated in section 3.4.3 that it may be necessary to include more information in order correctly to identify the remote
どんな法的なSIP URLもPINT URLとしてRequest-URIかTo:の中に現れることができます。 PINT要求のヘッダー。 しかし、アドレスが電話アドレスであるなら、私たちは、セクション3.4.3でリモートを特定するためにオーダーに正しく詳しい情報を含むのが必要であるかもしれないことを示しました。
Petrack & Conroy Standards Track [Page 33] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[33ページ]。
telephone terminal or service. PINT clients MAY include these attribute tags within PINT URLs if they are necessary or a useful complement to the telephone number within the SIP URL. These attribute tags MUST be included as URL parameters as defined in [1] (i.e. in the semi-colon separated manner).
端末かサービスに電話をしてください。 それらが必要であって、役に立ってSIP URLの中の電話番号に理想的であるなら、PINTクライアントはPINT URLの中でこれらの属性タグを入れるかもしれません。 [1](すなわち、セミコロンの切り離された方法による)で定義されるURLパラメタとしてこれらの属性タグを含まなければなりません。
The following is an example of a PINT URL containing extra attribute tags:
↓これは付加的な属性タグを含むPINT URLに関する例です:
sip:+9725228808@pint.br.com;user=phone;require=Q763-plan;a=Q763-plan:4
一口: + 9725228808@pint.br.com;user は電話と等しいです; =Q763-プランを必要としてください; : 4をa=Q763計画してください。
As we noted in section 3.4.3, these extra attribute parameters will not normally be needed within a URL, because there is a great deal of context available to help the server interpret the phone number correctly. In particular, there is the SIP URL within the To: header, and there is also the Request-URI. In most cases this provides sufficient information for the telephone network.
私たちがセクション3.4.3で注意したように、通常、これらの付加的な属性パラメタはURLの中で必要でないでしょう、サーバが正しく電話番号を解釈するのを助けるために利用可能な多くの文脈があるので。 To:の中に特に、SIP URLがあります。 ヘッダー、また、Request-URIがあります。 多くの場合、これは電話網のための十分な情報を提供します。
The SDP attributes defined in section 3 above will normally only be used when they are needed to supply necessary context to identify a telephone terminal.
電話端末を特定するために必要な文脈を提供するのが必要であるときにだけ、通常、上のセクション3で定義されたSDP属性は使用されるでしょう。
3.5.7. REGISTER requests within PINT
3.5.7. PINTの中のREGISTER要求
A PINT gateway is a SIP user agent server. A User Agent Server uses the REGISTER request to tell a proxy or redirect server that it is available to "receive calls" (i.e. to service requests). Thus a PINT Gateway registers with a proxy or redirect server the service that is accessible via itself, whilst in SIP, a user is registering his/her presence at a particular SIP Server.
PINTゲートウェイはSIPユーザエージェントサーバです。UserエージェントServerは「呼び出しを受ける」(すなわち、サービスのリクエストに)が利用可能であるとプロキシか再直接のサーバに言うというREGISTER要求を使用します。 したがって、PINTゲートウェイはそれ自体を通してアクセスしやすいサービスをプロキシか再直接のサーバに登録します、ユーザが特定のSIP ServerにSIPにその人の存在を示している間。
There may be competing PINT servers that can offer the same PINT service trying to register at a single PINT server. The PINT server might act as a "broker" among the various PINT gateways that can fulfill a request. A format for PINT URLs was specified in section 3.5.5 that enables independent PINT systems to REGISTER an offer to provide the same service. The registrar can apply its own mechanisms and policies to decide how to respond to INVITEs from clients seeking service (See section 6.3 for some possible deployment options). There is no change between SIP and PINT REGISTER semantics or syntax.
同じであるただ一つのPINTサーバで登録しようとするPINTサービスのを提供できる競争しているPINTサーバがあるかもしれません。PINTサーバは「ブローカー」として要求を実現させることができる様々なPINTゲートウェイの中で機能するかもしれません。 PINT URLのための形式は独立しているPINTシステムをREGISTERに可能にするセクション3.5.5で指定されました。同じサービスを提供するという申し出。 記録係は、サービスを求めているクライアントからINVITEsに応じる方法を決めるためにそれ自身のメカニズムと方針を適用できます(いくつかの可能な展開オプションに関してセクション6.3を見てください)。 SIPとPINT REGISTER意味論か構文の間には、変化が全くありません。
Of course, the information in the PINT URLs within the REGISTER request may not be sufficient to completely define the service that a gateway can offer. The use of SIP and SDP within PINT REGISTER requests to enable a gateway to specify in more detail the services it can offer is the subject of future study.
もちろん、REGISTER要求の中のPINT URLの情報は、ゲートウェイが提供できるサービスを完全に定義するために十分でないかもしれません。 ゲートウェイがさらに詳細にそれが提供できるサービスを指定するのを可能にするというPINT REGISTER要求の中のSIPとSDPの使用は今後の研究の対象です。
Petrack & Conroy Standards Track [Page 34] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[34ページ]。
3.5.8. BYE Requests in PINT
3.5.8. パイントにおけるさようなら要求
The semantics of BYE requests within PINT requires some extra precision. One issue concerns conferences that "cannot be left", and the other concerns keeping call state after the BYE.
PINTの中のBYE要求の意味論は何らかの付加的な精度を必要とします。 1つの問題が「残すことができない」会議に関係があります、そして、もう片方がBYEの後に呼び出し状態を維持するのが関係があります。
The BYE request [1] is normally used to indicate that the originating entity no longer wishes to be involved in the specified call. The request terminates the call and the media session. Applying this model to PINT, if a PINT client makes a request that results in invocation of a telephone call from A to B, a BYE request from the client, if accepted, should result in a termination of the phone call.
BYEは、通常、[1]が起因する実体がもう指定された呼び出しにかかわりたくないのを示すのに使用されるよう要求します。 要求は呼び出しとメディアセッションを終えます。 受け入れるならクライアントからのBYE要求は電話の終了をもたらして、PINTクライアントがAからBまでの通話の実施をもたらす要求をするなら、このモデルをPINTに適用するべきです。
One might expect this to be the case if the telephone call has not started when the BYE request is received. For example, if a request to fax is sent with a t= line indicating that the fax is to be sent tomorrow at 4 AM, the requestor might wish to cancel the request before the specified time.
BYE要求が受信されているとき、通話が始まっていないなら、人は、これがそうであると予想するかもしれません。 例えば、t=系列が、ファックスが明日の午前4時に送られることであることを示していてファックスで送る要求を送るなら、要請者は指定された時の前に要求を中止したがっているかもしれません。
However, even if the call has yet to start, it may not be possible to terminate the media session on the telephone system side. For example, the fax call may be in progress when the BYE arrives, and perhaps it is just not possible to cancel the fax in session. Another possibility is that the entire telephone-side service might be completed before the BYE is received. In the above Request-to-Fax example, the BYE might be sent the following morning, and the entire fax has been sent before the BYE was received. It is too late to send the BYE.
しかしながら、呼び出しがまだ始まらないでも、電話側でメディアセッションを終えるのは可能でないかもしれません。 BYEが到着するとき、例えば、ファックス呼び出しは進行しているかもしれません、そして、恐らく、セッションのときにファックスを取り消すのはただ可能ではありません。 別の可能性はBYEが受け取られている前に全体の電話サイドサービスが終了するかもしれないということです。 Requestからファックスへの上記の例では、次の朝BYEを送るかもしれません、そして、BYEを受け取る前に全体のファックスを送りました。 BYEを送るのは遅過ぎます。
In the case where the telephone network cannot terminate the call, the server MUST return a "606 Not Acceptable" response to the BYE, along with a session description that indicates the telephone network session that is causing the problem.
電話網が呼び出しを終えることができない場合では、サーバはBYEへの「許容できない606」応答を返さなければなりません、問題を引き起こしている電話網セッションを示すセッション記述と共に。
Thus, in PINT, a "Not Acceptable" response MAY be returned both to INVITE and BYE requests. It indicates that some aspect of the session description makes the request unacceptable.
したがって、PINTでは、「許容できない」応答をINVITEとBYE要求に返すかもしれません。 それは、セッション記述の何らかの局面で要求が容認できなくなるのを示します。
By allowing a server to return a "Not Acceptable" response to BYE requests, we are not changing its semantics, just enlarging its use.
サーバがBYE要求への「許容できない」応答を返すのを許容することによって、私たちは意味論を変えていません、ただ使用を拡大して。
A combination of Warning: headers and i= lines within the session description can be used to indicate the precise nature of the problem.
Warningの組み合わせ: 問題の正確な本質を示すのにセッション記述の中のヘッダーとi=系列を使用できます。
Petrack & Conroy Standards Track [Page 35] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[35ページ]。
Example:
例:
SIP/2.0 606 Not Acceptable
From: ...
To: .......
.....
Warning: 399 pint.mycom.com Fax in progress, service cannot be
aborted
Content-Type: application/sdp
Content-Length: ...
許容できるFrom:ではなく、一口/2.0 606 ... To: ....... ..... 警告: 399 ファックス進行中のpint.mycom.com、サービスは中止になっているコンテントタイプであるはずがありません: sdp Contentアプリケーション/長さ: ...
v=0
...
...
i=3 of 5 pages sent OK
c=TN RFC2543 +12014064090
m=image 1 fax tif
a=fmtp:tif uri:http://tifsRus.com/yyyyyy.tif
v=0… … 5ページのi=3はTN RFC2543の+12014064090m=のOK c=イメージの1つのファックスのtif a=fmtp:tif uri: http://tifsRus.com/yyyyyy.tif を送りました。
Note that the server might return an updated session description within a successful response to a BYE as well. This can be used, for example, to indicate the actual start times and stop times of the telephone session, or how many pages were sent in the fax transmission.
サーバがまた、BYEへのうまくいっている応答の中でアップデートされたセッション記述を返すかもしれないことに注意してください。 例えば、電話セッションの実際のスタート時間と停止時間、またはいくつのページがファックス送信で送られたかを示すのにこれを使用できます。
The second issue concerns how long must a server keep call state after receiving a BYE. A question arises because other clients might still wish to send queries about the telephone network session that was the subject of the PINT transaction. Ordinary SIP semantics have three important implications for this situation:
問題関心がどれくらい長い間そうしなければならない秒に、サーバは不戦勝を得た後に、呼び出し状態を維持するか。 他のクライアントがPINTトランザクションの対象であった電話網セッション頃にまだ質問を送りたがっているかもしれないので、質問は起こります。 普通のSIP意味論には、この状況のための3つの重要な意味があります:
1. A BYE indicates that the requesting client will clear out all call state as soon as it receives a successful response. A client SHOULD NOT send a SUBSCRIBE request after it has sent a BYE.
1. BYEは、うまくいっている応答を受けるとすぐに、要求しているクライアントがすべての呼び出し状態を取り除くのを示します。 SHOULD NOTが登録をそれの後の要求がBYEを送った送るクライアント。
2. A server may return an Expires: header within a successful response to a BYE request. This indicates for how long the server will retain session state about the telephone network session. At any point during this time, a client may send a SUBSCRIBE request to the server to learn about the session state (although as explained in the previous paragraph, a client that has sent a BYE will not normally send a SUBSCRIBE).
2. サーバはExpiresを返すかもしれません: BYE要求へのうまくいっている応答の中のヘッダー。 これは、どれくらい長い間、サーバが電話網セッション頃にセッション状態を保有するのを示すか。 今回の間の任意な点では、クライアントが、セッション頃に状態(BYEを送ったクライアントは前のパラグラフで説明されるように通常登録を送らないでしょうが)を学ぶためにサーバへの要求を登録に送るかもしれません。
3. When engaged in a SUBSCRIBE/NOTIFY monitoring session, PINT servers that send UNSUBSCRIBE to a URL listed in the Contact: header of a client request SHOULD not clear session state until after the successful response to the UNSUBSCRIBE message is received. For example, it may be that the requesting client host is turned off (or
3. 登録に従事している/NOTIFYモニターしているセッション、記載されたURLへの登録削除、Contactを送るPINTサーバであるときに: 登録削除、メッセージはそうです。SHOULDがうまくいっている応答の後のセッション状態をきれいにしないクライアント要求のヘッダー、受け取ります。 または例えば、多分、要求しているクライアントホストが下に変えられる、(。
Petrack & Conroy Standards Track [Page 36] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[36ページ]。
in a low power mode) when the telephone service is executed (and is therefore not available at the location previously specified in the Contact: attribute) to receive the PINT server's UNSUBSCRIBE. Of course, it is possible that the UNSUBSCRIBE request will simply time out.
そして、中、低パワーモード) 電話が修理するいつ、実行されるか、(したがって、以前にContactで指定された位置では、利用可能ではありません: サーバのPINTものを受け取ってください。属性)、登録削除。 もちろん、それが可能である、それ、登録削除、要求は単にタイムアウトがそうするでしょう。
4. Examples of PINT Requests and Responses
4. パイント要求と応答に関する例
4.1. A request to a call center from an anonymous user to receive a
phone call.
4.1. 電話を受ける匿名のユーザからのコールセンターへの要求。
C->S: INVITE sip:R2C@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:anon-1827631872@chinet.net
To: sip:+1-201-456-7890@iron.org;user=phone
Call-ID: 19971205T234505.56.78@pager.com
CSeq: 4711 INVITE
Subject: Sale on Ironing Boards
Content-type: application/sdp
Content-Length: 174
C>S: INVITE一口: R2C@pint.mailorder.com SIP/2.0Via: UDP169.130.12.5一口/2.0/From: 一口: anon-1827631872@chinet.net To: 一口: + 1-201-456-7890@iron.org;user は電話Call-IDと等しいです: 19971205T234505.56.78@pager.com CSeq: 4711はSubject:を招待します。 アイロン台文書内容における販売: sdp Contentアプリケーション/長さ: 174
v=0
o=- 2353687637 2353687637 IN IP4 128.3.4.5
s=R2C
i=Ironing Board Promotion
e=anon-1827631872@chinet.net
t=2353687637 0
m=audio 1 voice -
c=TN RFC2543 +1-201-406-4090
v=0oアイロンかけ=-2353687637 2353687637IN IP4 128.3.4.5 s=R2C i=Board Promotion eが anon-1827631872@chinet.net t=と等しい、2353687637、0m、オーディオの1回の声と等しい、--cがTN RFC2543+1-201-406-4090と等しい
In this example, the context that is required to interpret the To: address as a telephone number is not given explicitly; it is implicitly known to the R2C@pint.mailorder.com server. But the telephone of the person who wishes to receive the call is explicitly identified as an internationally significant E.164 number that falls within the North American numbering plan (because of the "+1" within the c= line).
この例では、文脈がTo:を解釈するのが必要です。 電話番号としてのアドレスは明らかに与えられていません。 それはそれとなく R2C@pint.mailorder.com サーバに知られています。しかし、呼び出しを受けたがっている人の電話は北米の付番プランの中に下がる国際的に重要なE.164番号として明らかに特定されます(「+1」のために、中では、cが系列と等しいです)。
4.2. A request from a non anonymous customer (John Jones) to receive a
phone call from a particular sales agent (Mary James) concerning
the defective ironing board that was purchased
4.2. 購入された欠陥があるアイロン台に関して特定の販売代理店(メアリ・ジェームス)から電話を受ける非匿名の顧客(ジョン・ジョーンズ)からの要求
C->S: INVITE sip:marketing@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:john.jones.3@chinet.net
To: sip:mary.james@mailorder.com
Call-ID: 19971205T234505.56.78@pager.com
CSeq: 4712 INVITE
C>S: INVITE一口: marketing@pint.mailorder.com SIP/2.0Via: UDP169.130.12.5一口/2.0/From: 一口: john.jones.3@chinet.net To: 一口: mary.james@mailorder.com Call-ID: 19971205T234505.56.78@pager.com CSeq: 4712年の招待
Petrack & Conroy Standards Track [Page 37] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[37ページ]。
Subject: Defective Ironing Board - want refund
Content-type: application/sdp
Content-Length: 150
Subject: 欠陥があるIroning Board--還付文書内容が欲しいです: sdp Contentアプリケーション/長さ: 150
v=0
o=- 2353687640 2353687640 IN IP4 128.3.4.5
s=marketing
e=john.jones.3@chinet.net
c= TN RFC2543 +1-201-406-4090
t=2353687640 0
m=audio 1 voice -
v=0o=-2353687640 2353687640IN IP4 128.3.4.5 s=マーケティングeがTN RFC2543+1-201-406-4090 john.jones.3@chinet.net c=t=と等しい、2353687640、0m、オーディオの1回の声と等しい、-
The To: line might include the Mary James's phone number instead of a email-like address. An implementation that cannot accept email-like URLs in the "To:" header must decline the request with a 606 Not Acceptable. Note that the sending PINT client "knows" that the PINT Gateway contacted with the "marketing@pint.mailorder.com" Request-URI is capable of processing the client request as expected. (see 3.5.5.1 for a discussion on this).
To: 系列はメールのようなアドレスの代わりにメアリ・ジェームスの電話番号を含むかもしれません。 「To:」でメールのようなURLを受け入れることができない実装 ヘッダーは606Not Acceptableとの要求を断らなければなりません。 送付PINTクライアントが、" marketing@pint.mailorder.com "要求URIで連絡されたPINTゲートウェイが予想されるようにクライアント要求を処理できるのを「知っている」と述べてください。 (3.5に.5を見てください、これについての議論のための.1)
Note also that such a telephone call service could be implemented on the phone side with different details. For example, it might be that first the agent's phone rings, and then the customer's phone rings, or it might be that first the customer's phone rings and he hears silly music until the agent comes on line. If necessary, such service parameter details might be indicated in "a=" attribute lines within the session description. The specification of such attribute lines for service consistency is beyond the scope of the PINT 1.0 specifications.
また、電話側で異なった詳細でそのような通話サービスを実装することができたことに注意してください。 例えば、次に、最初に、エージェントの電話リングと、顧客の電話リングか、最初に、顧客の電話が鳴って、エージェントが系列をつくまで彼が愚かな音楽を聞くということであるかもしれないということであるかもしれません。 必要なら、そのようなサービスパラメタの詳細はセッション記述の中に「=」属性系列で示されるかもしれません。 サービスの一貫性のためのそのような属性系列の仕様はPINT1.0仕様の範囲を超えています。
4.3. A request from the same user to get a fax back on how to assemble
the Ironing Board
4.3. どうIroning Boardを組み立てるかに関するファックスを手に入れる同じユーザからの要求
C->S: INVITE sip:faxback@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:john.jones.3@chinet.net
To: sip:1-800-3292225@steam.edu;user=phone;phone-context=+1
Call-ID: 19971205T234505.66.79@chinet.net
CSeq: 4713 INVITE
Content-type: application/sdp
Content-Length: 218
C>S: INVITE一口: faxback@pint.mailorder.com SIP/2.0Via: UDP169.130.12.5一口/2.0/From: 一口: john.jones.3@chinet.net To: 一口: 1-800-3292225@steam.edu;user は電話と等しいです; 電話文脈は+1 Call-IDと等しいです: 19971205T234505.66.79@chinet.net CSeq: 4713は文書内容を招待します: sdp Contentアプリケーション/長さ: 218
v=0
o=- 2353687660 2353687660 IN IP4 128.3.4.5
s=faxback
e=john.jones.3@chinet.net
t=2353687660 0
m=application 1 fax URI
v=0o=-2353687660 2353687660IN IP4 128.3.4.5 s=faxback e= john.jones.3@chinet.net tは0mの2353687660の=のアプリケーションの1つのファックスのURIと等しいです。
Petrack & Conroy Standards Track [Page 38] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[38ページ]。
c=TN RFC2543 1-201-406-4091
a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html
c=TN RFC2543 1-201-406-4091a=fmtp: URI uri: http://localstore/Products/IroningBoards/2344.html
In this example, the fax to be sent is stored on some local server (localstore), whose name may be only resolvable, or that may only be reachable, from within the IP network on which the PINT server sits. The phone number to be dialled is a "local phone number" as well. There is no "phone-context" attribute, so the context (in this case, for which nation the number is "nationally significant") must be supplied by the faxback@pint.mailorder.com PINT server.
この例では、送られるファックスが単に名前が溶解性であるかもしれない何らかのローカルサーバ(localstore)に保存されるか、またはそれは届くだけであるかもしれません、IPネットワークから中PINTサーバが座る。 ダイヤルされるべき電話番号はまた、「ローカルの電話番号」です。 「電話文脈」属性が全くなくて、そうが文脈である、(この場合、どの国に、数が「全国的に、重要であるか」、)、 faxback@pint.mailorder.com PINTサーバは供給しなければなりません。
If the server that receives it does not understand the number, it SHOULD decline the request and include a "Network Address Not Understood" warning. Note that no "require" attribute was used here, since it is very likely that the request can be serviced even by a server that does not support the "require" attribute.
それを受けるサーバがそうしないなら、数を理解してください、それ。SHOULDは要求を断って、「ネットワーク・アドレスは分からなかった」という警告を含んでいます。 いいえが属性を「必要である」というメモはここで使用されました、「必要」属性をサポートしないサーバでさえ要求を非常に修理できそうであるので。
4.4. A request from same user to have that same information read out
over the phone
4.4. 同じ情報が電話で読みだしたいる同じユーザからの要求
C->S: INVITE sip:faxback@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:john.jones.3@chinet.net
To: sip:1-800-3292225@steam.edu;user=phone;phone-context=+1
Call-ID: 19971205T234505.66.79@chinet.net
CSeq: 4713 INVITE
Content-type: application/sdp
Content-Length: 220
C>S: INVITE一口: faxback@pint.mailorder.com SIP/2.0Via: UDP169.130.12.5一口/2.0/From: 一口: john.jones.3@chinet.net To: 一口: 1-800-3292225@steam.edu;user は電話と等しいです; 電話文脈は+1 Call-IDと等しいです: 19971205T234505.66.79@chinet.net CSeq: 4713は文書内容を招待します: sdp Contentアプリケーション/長さ: 220
v=0
o=- 2353687660 2353687660 IN IP4 128.3.4.5
s=faxback
e=john.jones.3@chinet.net
t=2353687660 0
m=application 1 voice URI
c=TN RFC2543 1-201-406-4090
a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html
v=0o=-2353687660 2353687660IN IP4 128.3.4.5 s=faxback e= john.jones.3@chinet.net tが等しい、2353687660、0m、= 1つのアプリケーション声のURI cがuri: TN RFC2543 1-201-406-4090a=fmtp: URI http://localstore/Products/IroningBoards/2344.html と等しいです。
4.5. A request to send an included text page to a friend's pager.
4.5. 含まれているテキストページを友人のポケットベルに送るという要求。
In this example, the text to be paged out is included in the request.
この例では、外に呼び出されるべきテキストは要求に含まれています。
C->S: INVITE sip:R2F@pint.pager.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:scott.petrack@chinet.net
To: sip:R2F@pint.pager.com
Call-ID: 19974505.66.79@chinet.net
CSeq: 4714 INVITE
C>S: INVITE一口: R2F@pint.pager.com SIP/2.0Via: UDP169.130.12.5一口/2.0/From: 一口: scott.petrack@chinet.net To: 一口: R2F@pint.pager.com Call-ID: 19974505.66.79@chinet.net CSeq: 4714年の招待
Petrack & Conroy Standards Track [Page 39] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[39ページ]。
Content-Type: multipart/related; boundary=--next
コンテントタイプ: 複合か関連する。 境界=--次に
----next
Content-Type: application/sdp
Content-Length: 236
v=0
o=- 2353687680 2353687680 IN IP4 128.3.4.5
s=R2F
e=scott.petrack@chinet.net
t=2353687680 0
m=text 1 pager plain
c= TN RFC2543 +972-9-956-1867
a=fmtp:plain spr:2@53655768
----次のコンテントタイプ: sdp Contentアプリケーション/長さ: 236v=0o=-2353687680 2353687680IN IP4 128.3.4.5 s=R2F eが scott.petrack@chinet.net t=と等しい、2353687680、0m、= 1つのテキストポケットベル平野cがTN RFC2543+972-9-956-1867a=fmtp: 明瞭なspr: 2@53655768 と等しいです。
----next
Content-Type: text/plain
Content-ID: 2@53655768
Content-Length:50
----次のコンテントタイプ: テキスト/明瞭なコンテントID: 2@53655768 コンテンツの長さ: 50
Hi Joe! Please call me asap at 555-1234.
こんにちは、ジョー! 私を555-1234までasapと呼んでください。
----next--
----次--
4.6. A request to send an image as a fax to phone number +972-9-956-1867
4.6. ファックスとして電話番号+972-9-956-1867にイメージを送るという要求
C->S: INVITE sip:faxserver@pint.vocaltec.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:scott.petrack@chinet.net
To: sip:faxserver@pint.vocaltec.com
Call-ID: 19971205T234505.66.79@chinet.net
CSeq: 4715 INVITE
Content-type: application/sdp
Content-Length: 267
C>S: INVITE一口: faxserver@pint.vocaltec.com SIP/2.0Via: UDP169.130.12.5一口/2.0/From: 一口: scott.petrack@chinet.net To: 一口: faxserver@pint.vocaltec.com Call-ID: 19971205T234505.66.79@chinet.net CSeq: 4715は文書内容を招待します: sdp Contentアプリケーション/長さ: 267
v=0
o=- 2353687700 2353687700 IN IP4 128.3.4.5
s=faxserver
e=scott.petrack@chinet.net
t=2353687700 0
m=image 1 fax tif gif
c= TN RFC2543 +972-9-956-1867
a=fmtp:tif uri:http://petrack/images/tif/picture1.tif
a=fmtp:gif uri:http://petrack/images/gif/picture1.gif
v=0o=-2353687700 2353687700IN IP4 128.3.4.5 s=faxserver e= scott.petrack@chinet.net tが等しい、2353687700、0m、= イメージ1ファックスtif gif cはTN RFC2543+972-9-956-1867a=fmtp:tif uri: http://petrack/images/tif/picture1.tif a=fmtp:gif uri: http://petrack/images/gif/picture1.gif と等しいです。
Petrack & Conroy Standards Track [Page 40] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[40ページ]。
The image is available as tif or as gif. The tif is the preferred format. Note that the http server where the pictures reside is local, and the PINT server is also local (because it can resolve machine name "petrack")
イメージはtifとして、または、gifとして利用可能です。 tifは都合のよい形式です。 絵があるhttpサーバがローカルであり、また、PINTサーバもローカルであることに注意してください。(マシン名"petrack"を決議できるので)
4.7. A request to read out over the phone two pieces of content in
sequence.
4.7. 電話で連続して内容の2つの断片を読みだすという要求。
First some included text is read out by text-to-speech. Then some text that is stored at some URI on the internet is read out.
まず最初に、何らかの含まれているテキストがテキストからスピーチによって読みだされます。 そして、インターネットに何らかのURIで格納される何らかのテキストが読みだされます。
C->S: INVITE sip:R2HC@pint.acme.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:scott.petrack@chinet.net
To: sip:R2HC@pint.acme.com
Call-ID: 19974505.66.79@chinet.net
CSeq: 4716 INVITE
Content-Type: multipart/related; boundary=next
C>S: INVITE一口: R2HC@pint.acme.com SIP/2.0Via: UDP169.130.12.5一口/2.0/From: 一口: scott.petrack@chinet.net To: 一口: R2HC@pint.acme.com Call-ID: 19974505.66.79@chinet.net CSeq: 4716はコンテントタイプを招待します: 複合か関連する。 次の境界=
--next
Content-Type: application/sdp
Content-Length: 316
v=0
o=- 2353687720 2353687720 IN IP4 128.3.4.5
s=R2HC
e=scott.petrack@chinet.net
--次のコンテントタイプ: sdp Contentアプリケーション/長さ: 316 v=0o=-2353687720 2353687720IN IP4 128.3.4.5 s=R2HC e= scott.petrack@chinet.net
c= TN RFC2543 +1-201-406-4091
t=2353687720 0
m=text 1 voice plain
a=fmtp:plain spr:2@53655768
m=text 1 voice plain
a=fmtp:plain uri:http://www.your.com/texts/stuff.doc
c=TN RFC2543+1-201-406-4091tが等しい、2353687720、0m、= テキスト1は明瞭なa=fmtpを声に出します: 明瞭なspr: 2@53655768 mはテキスト1声の明瞭なa=fmtp: 明瞭なuri: http://www.your.com/texts/stuff.doc と等しいです。
--next
Content-Type: text/plain
Content-ID: 2@53655768
Content-Length: 172
--次のコンテントタイプ: テキスト/明瞭なコンテントID: 2@53655768 コンテンツの長さ: 172
Hello!! I am about to read out to you the document you
requested, "uri:http://www.your.com/texts/stuff.doc".
We hope you like acme.com's new speech synthesis server.
--next--
こんにちは! 私はご要望のドキュメント、「uri: http://www.your.com/texts/stuff.doc 」をあなたに読みだそうとしています。 あなたがacme.comの新しい音声合成サーバが好きであることを願っている、--次--
Petrack & Conroy Standards Track [Page 41] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[41ページ]。
4.8. Request for the prices for ISDN to be sent to my fax machine
4.8. 私のファックス装置に送られるISDNの価格を求める要求
INVITE sip:R2FB@pint.bt.co.uk SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 To: sip:0345-12347-01@pint.bt.co.uk;user=phone;phone-context=+44 From: sip:hank.wangford@newts.demon.co.uk Call-ID: 19981204T201505.56.78@demon.co.uk CSeq: 4716 INVITE Subject: Price List Content-type: application/sdp Content-Length: 169
INVITE一口: R2FB@pint.bt.co.uk SIP/2.0Via: UDP169.130.12.5一口/2.0/To: 一口: 0345-12347-01@pint.bt.co.uk;user は電話と等しいです; 電話文脈は+44From:と等しいです。 一口: hank.wangford@newts.demon.co.uk Call-ID: 19981204T201505.56.78@demon.co.uk CSeq: 4716はSubject:を招待します。 リスト文書内容に値を付けてください: sdp Contentアプリケーション/長さ: 169
v=0 o=- 2353687740 2353687740 IN IP4 128.3.4.5 s=R2FB i=ISDN Price List e=hank.wangford@newts.demon.co.uk t=2353687740 0 m=text 1 fax - c=TN RFC2543 +44-1794-8331010
v=0o ISDN=-2353687740 2353687740IN IP4 128.3.4.5 s=R2FB i=Price List eが hank.wangford@newts.demon.co.uk t=と等しい、2353687740、0m、=テキスト1ファックス、--cがTN RFC2543+44-1794-8331010と等しい
4.9. Request for a callback
4.9. 回収を求める要求
INVITE sip:R2C@pint.bt.co.uk SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 To: sip:0345-123456@pint.bt.co.uk;user=phone;phone-context=+44 From: sip:hank.wangford@newts.demon.co.uk Call-ID: 19981204T234505.56.78@demon.co.uk CSeq: 4717 INVITE Subject: It costs HOW much? Content-type: application/sdp Content-Length: 176
INVITE一口: R2C@pint.bt.co.uk SIP/2.0Via: UDP169.130.12.5一口/2.0/To: 一口: 0345-123456@pint.bt.co.uk;user は電話と等しいです; 電話文脈は+44From:と等しいです。 一口: hank.wangford@newts.demon.co.uk Call-ID: 19981204T234505.56.78@demon.co.uk CSeq: 4717はSubject:を招待します。 HOWは多くをそれに費やしますか? 文書内容: sdp Contentアプリケーション/長さ: 176
v=0 o=- 2353687760 2353687760 IN IP4 128.3.4.5 s=R2C i=ISDN pre-sales query e=hank.wangford@newts.demon.co.uk c=TN RFC2543 +44-1794-8331013 t=2353687760 0 m=audio 1 voice -
TN RFC2543v=0o=-2353687760 2353687760IN IP4 128.3.4.5 s=R2C i=ISDNプレ販売質問e= hank.wangford@newts.demon.co.uk c=+44-1794-8331013tが等しい、2353687760、0m、オーディオの1回の声と等しい、-
Petrack & Conroy Standards Track [Page 42] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[42ページ]。
4.10. Sending a set of information in response to an enquiry
4.10. 調査に対応して1セットの情報を送ります。
INVITE sip:R2FB@pint.bt.co.uk SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 To: sip:0345-12347-01@pint.bt.co.uk;user=phone;phone-context=+44 From: sip:colin.masterton@sales.hh.bt.co.uk Call-ID: 19981205T234505.56.78@sales.hh.bt.co.uk CSeq: 1147 INVITE Subject: Price Info, as requested Content-Type: multipart/related; boundary=next
INVITE一口: R2FB@pint.bt.co.uk SIP/2.0Via: UDP169.130.12.5一口/2.0/To: 一口: 0345-12347-01@pint.bt.co.uk;user は電話と等しいです; 電話文脈は+44From:と等しいです。 一口: colin.masterton@sales.hh.bt.co.uk Call-ID: 19981205T234505.56.78@sales.hh.bt.co.uk CSeq: 1147はSubject:を招待します。 要求された通り価格Info、コンテントタイプ: 複合か関連する。 次の境界=
--next
Content-type: application/sdp
Content-Length: 325
v=0
o=- 2353687780 2353687780 IN IP4 128.3.4.5
s=R2FB
i=Your documents
e=colin.masterton@sales.hh.bt.co.uk
t=2353687780 0
m=application 1 fax octet-stream
c=TN RFC2543 +44-1794-8331010
a=fmtp:octet-stream uri:http://www.bt.co.uk/imgs/pipr.gif opr:
spr:2@53655768
--次の文書内容: sdp Contentアプリケーション/長さ: あなたの325v=0o=-2353687780 2353687780IN IP4 128.3.4.5 s=R2FB i=ドキュメントeが colin.masterton@sales.hh.bt.co.uk t=と等しい、2353687780、0m、= アプリケーション1つのファックス八重奏流れのcはoprにTN RFC2543+44-1794-8331010a=fmtp: 八重奏流れのuri: http://www.bt.co.uk/imgs/pipr.gif と等しいです: spr: 2@53655768
--next Content-Type: text/plain Content-ID: 2@53655768 Content-Length: 352
--次のコンテントタイプ: テキスト/明瞭なコンテントID: 2@53655768 コンテンツの長さ: 352
Dear Sir,
Thank you for your enquiry. I have checked availability in your
area, and we can provide service to your cottage. I enclose a
quote for the costs of installation, together with the ongoing
rental costs for the line. If you want to proceed with this,
please quote job reference isdn/hh/123.45.9901.
Yours Sincerely,
Colin Masterton
--next--
拝啓、調査ありがとうございます。 私はあなたの領域で有用性をチェックしました、そして、私たちはあなたのコテージに対するサービスを提供できます。 私は進行中のレンタルのコストと共にインストールのコストのための見積りを線に同封します。 これを続けたいなら、仕事の参照isdn/hh/123.45.9901を引用してください。 敬具、次にコリン・マスタートン--
Note that the "implicit" faxback content is given by an EMPTY opaque reference in the middle of the fmtp line in this example.
「暗黙」のfaxback内容がこの例でfmtp線の中央でEMPTYの不明瞭な参照で与えられていることに注意してください。
Petrack & Conroy Standards Track [Page 43] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[43ページ]。
4.11. Sportsline "headlines" message sent to your phone/pager/fax
4.11. あなたの電話/ポケットベル/ファックスに送られたSportsline「見出し」メッセージ
(i) phone
INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To:
sip:1-900-123-456-7@wwos.skynet.com;user=phone;phone-context=+1
From: sip:fred.football.fan@skynet.com
Call-ID: 19971205T234505.56.78@chinet.net
CSeq: 4721 INVITE
Subject: Wonderful World Of Sports NFL Final Scores
Content-type: application/sdp
Content-Length: 220
(i)電話INVITE一口: R2FB@pint.wwos.skynet.com SIP/2.0Via: UDP169.130.12.5一口/2.0/To: 一口: 1-900-123-456-7@wwos.skynet.com;user は電話と等しいです; 電話文脈は+1From:と等しいです。 一口: fred.football.fan@skynet.com Call-ID: 19971205T234505.56.78@chinet.net CSeq: 4721はSubject:を招待します。 スポーツNFL決勝のワンダフル・ワールドは文書内容を得点します: sdp Contentアプリケーション/長さ: 220
v=0
o=- 2353687800 2353687800 IN IP4 128.3.4.5
s=R2FB
i=NFL Final Scores
e=fred.football.fan@skynet.com
c=TN RFC2543 +44-1794-8331013
t=2353687800 0
m=audio 1 voice x-pay
a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
TN RFC2543v=0o=-2353687800 2353687800IN IP4 128.3.4.5 s=R2FB i=NFL Final Scores e= fred.football.fan@skynet.com c=+44-1794-8331013tが等しい、2353687800、0m、=オーディオ1声のx-賃金a=fmtp: x-賃金opr:mci.com/md5:<暗号署名>。
(ii) fax
INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:1-900-123-456-7@wwos.skynet.com;user=phone;
phone-context=+1
From: sip:fred.football.fan@skynet.com
Call-ID: 19971205T234505.56.78@chinet.net
CSeq: 4722 INVITE
Subject: Wonderful World Of Sports NFL Final Scores
Content-type: application/sdp
Content-Length: 217
(ii)ファックスINVITE一口: R2FB@pint.wwos.skynet.com SIP/2.0Via: UDP169.130.12.5一口/2.0/To: 一口: 1-900-123-456-7@wwos.skynet.com;user は電話と等しいです。 電話文脈=+1From: 一口: fred.football.fan@skynet.com Call-ID: 19971205T234505.56.78@chinet.net CSeq: 4722はSubject:を招待します。 スポーツNFL決勝のワンダフル・ワールドは文書内容を得点します: sdp Contentアプリケーション/長さ: 217
v=0
o=- 2353687820 2353687820 IN IP4 128.3.4.5
s=R2FB
i=NFL Final Scores
e=fred.football.fan@skynet.com
c=TN RFC2543 +44-1794-8331010
t=2353687820 0
m=text 1 fax x-pay
a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
TN RFC2543v=0o=-2353687820 2353687820IN IP4 128.3.4.5 s=R2FB i=NFL Final Scores e= fred.football.fan@skynet.com c=+44-1794-8331010tが等しい、2353687820、0m、= テキスト1はx-賃金a=fmtp: x-賃金opr:mci.com/md5:<暗号署名>にファックスします。
Petrack & Conroy Standards Track [Page 44] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[44ページ]。
(iii) pager
INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:1-900-123-456-7@wwos.skynet.com;user=phone;
phone-context=+1
From: sip:fred.football.fan@skynet.com
Call-ID: 19971205T234505.56.78@chinet.net
CSeq: 4723 INVITE
Subject: Wonderful World Of Sports NFL Final Scores
Content-type: application/sdp
Content-Length: 219
(iii)ポケットベルINVITE一口: R2FB@pint.wwos.skynet.com SIP/2.0Via: UDP169.130.12.5一口/2.0/To: 一口: 1-900-123-456-7@wwos.skynet.com;user は電話と等しいです。 電話文脈=+1From: 一口: fred.football.fan@skynet.com Call-ID: 19971205T234505.56.78@chinet.net CSeq: 4723はSubject:を招待します。 スポーツNFL決勝のワンダフル・ワールドは文書内容を得点します: sdp Contentアプリケーション/長さ: 219
v=0
o=- 2353687840 2353687840 IN IP4 128.3.4.5
s=R2FB
i=NFL Final Scores
e=fred.football.fan@skynet.com
c=TN RFC2543 +44-1794-8331015
t=2353687840 0
m=text 1 pager x-pay
a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
TN RFC2543v=0o=-2353687840 2353687840IN IP4 128.3.4.5 s=R2FB i=NFL Final Scores e= fred.football.fan@skynet.com c=+44-1794-8331015tが等しい、2353687840、0m、=のテキストの1つのポケットベルのx-賃金a=fmtp: x-賃金opr:mci.com/md5:<暗号署名>。
Note that these are all VERY similar.
これらが非常にすべて同様であることに注意してください。
4.12. Automatically giving someone a fax copy of your phone bill
4.12. 自動的に、あなたの電話代請求書のファックスコピーをだれかに与えます。
INVITE sip:BillsRUs@pint.sprint.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:+1-555-888-1234@fbi.gov;user=phone
From: sip:agent.mulder@fbi.gov
Call-ID: 19991231T234505.56.78@fbi.gov
CSeq: 911 INVITE
Subject: Itemised Bill for January 98
Content-type: application/sdp
Content-Length: 247
INVITE一口: BillsRUs@pint.sprint.com SIP/2.0Via: UDP169.130.12.5一口/2.0/To: 一口: + 1-555-888-1234@fbi.gov;user =電話From: 一口: agent.mulder@fbi.gov Call-ID: 19991231T234505.56.78@fbi.gov CSeq: 911はSubject:を招待します。 1月98日の文書内容のためにビルを箇条書します: sdp Contentアプリケーション/長さ: 247
v=0
o=- 2353687860 2353687860 IN IP4 128.3.4.5
s=BillsRUs
i=Joe Pendleton's Phone Bill
e=agent.mulder@fbi.gov
c=TN RFC2543 +1-202-833-1010
t=2353687860 0
m=text 1 fax x-files-id
a=fmtp:x-files-id opr:fbi.gov/jdcn-123@45:3des;base64,<signature>
TN RFC2543+1-202-833-1010v=0oジョー=-2353687860 2353687860IN IP4 128.3.4.5 s=BillsRUs i=Pendleton'sのPhoneビルe= agent.mulder@fbi.gov c=tが等しい、2353687860、0m、1つのファックスの=テキストxファイルイドa=fmtp: xファイルイドopr: fbi.gov/jdcn-123@45 :3des; base64、lt;、署名>。
Petrack & Conroy Standards Track [Page 45] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[45ページ]。
Note: in this case the opaque reference is a collection of data used to convince the Executive System that the requester has the right to get this information, rather than selecting the particular content (the A party in the To: field of the SIP "wrapper" does that alone).
以下に注意してください。 この場合、不明瞭な参照はこの情報を得るためにリクエスタが権利があるとExecutive Systemに納得させるのに特定の内容を選択するよりむしろ使用されるデータの収集(SIP「包装紙」のTo:分野のAパーティーは単独でそれをする)です。
5. Security Considerations
5. セキュリティ問題
5.1. Basic Principles for PINT Use
5.1. パイント使用のための基本原理
A PINT Gateway, and the Executive System(s) with which that Gateway is associated, exist to provide service to PINT Requestors. The aim of the PINT protocol is to pass requests from those users on to a PINT Gateway so an associated Executive System can service those requests.
PINTゲートウェイ、およびそのゲートウェイが関連しているExecutive System(s)は、PINT Requestorsに対するサービスを提供するために存在しています。 PINTプロトコルの目的は関連Executive Systemがそれらの要求を修理できるようにそれらのユーザよりPINTゲートウェイに要求を移ることです。
5.1.1. Responsibility for service requests
5.1.1. サービスのリクエストへの責任
The facility of making a GSTN-based call to numbers specified in the PINT request, however, comes with some risks. The request can specify an incorrect telephone of fax number. It is also possible that the Requestor has purposely entered the telephone number of an innocent third party. Finally, the request may have been intercepted on its way through any intervening PINT or SIP infrastructure, and the request may have been altered.
しかしながら、PINT要求の、数へのGSTNベースの呼び出しを指定させる能力はいくつかのリスクと共に来ます。 要求はファックス番号の不正確な電話を指定できます。 また、Requestorがわざわざ潔白な第三者の電話番号を入れたのも、可能です。 最終的に、要求はどんな介入しているPINTやSIPインフラストラクチャを通しても途中で妨害されたかもしれません、そして、要求は変更されたかもしれません。
In any of these cases, the result may be that a call is placed incorrectly. Where there is intent or negligence, this may be construed as harassment of the person incorrectly receiving the call. Whilst the regulatory framework for misuse of Internet connections differs throughout the world and is not always mature, the rules under which GSTN calls are made are much more settled. Someone may be liable for mistaken or incorrect calls.
これらの場合のいずれではも、結果は電話が不当に出されるということであるかもしれません。 故意又は過失があるところでは、これは不当に呼び出しを受ける人のハラスメントに理解されるかもしれません。 インターネット接続の誤用のための規定の枠組みが世界中で異なって、いつも熟すというわけではない間、GSTN電話がかけられる規則ははるかに決着します。 だれかが間違われたか不正確な呼び出しに責任があるかもしれません。
Understandably, the GSTN Operators would prefer that this someone is not them, so they will need to ensure that any PINT Gateway and Executive System combination does not generate incorrect calls through some error in the Gateway or Executive system implementation or GSTN-internal communications fault. Equally, it is important that the Operator can show that they act only on requests that they have good reason to believe are correct. This means that the Gateway must not pass on requests unless it is sure that they have not been corrupted in transit from the Requestor.
GSTN Operatorsは、このだれかが彼らでないことを目立って、好むでしょう、したがって、彼らがどんなPINTゲートウェイとExecutive System組み合わせもゲートウェイ、Executiveシステムの実現またはGSTN内部のコミュニケーション欠点における何らかの誤りによる不正確な呼び出しを発生させないのを保証する必要があるでしょう。 等しく、Operatorが、それらがそれらには信じているのが正しい十分な理由があるという要求だけに影響するのを示すことができるのは、重要です。 これは、Requestorからトランジットで腐敗していないのが確かでない場合ゲートウェイが要求を伝えてはいけないことを意味します。
If a request can be shown to have come from a particular Requestor and to have been acted on in good faith by the PINT service provider, then responsibility for making requests may well fall to the Requestor rather than the Operator who executed these requests.
特定のRequestorから来て、PINTサービスプロバイダーによって誠実に影響されたように要求を示すことができるなら、要求をすることへの責任はたぶんこれらの要求を実行したOperatorよりむしろRequestorに落下するでしょう。
Petrack & Conroy Standards Track [Page 46] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[46ページ]。
Finally, it may be important for the PINT service provider to be able to show that they act only on requests for which they have some degree of assurance of origin. In many jurisdictions, it is a requirement on GSTN Operators that they place calls only when they can, if required, identify the parties to the call (such as when required to carry out a Malicious Call Trace). It is at least likely that the provider of PINT services will have a similar responsibility placed on them.
最終的に、PINTサービスプロバイダーが、それらには起源の保証がいくらかのある要求にだけ影響するのを示すことができるのは、重要であるかもしれません。 多くの管内では、それが必要なら要求(Malicious Call Traceを行うのに必要であるいつなどの)へのパーティーを特定できるかときだけ、彼らが電話をするというGSTN Operatorsに関する要件です。 PINTサービスのプロバイダーは同様の責任をそれらに少なくとも置きそうでしょう。
It follows that the PINT service provider may require that the identity of the Requestor be confirmed. If such confirmation is not available, then they may be forced (or choose) not to provide service. This identification may require personal authentication of the Requesting User.
PINTサービスプロバイダーが、Requestorのアイデンティティが確認されるのを必要とするかもしれないということになります。 そのような確認が利用可能でないなら、彼らはやむを得ずサービスを提供しないかもしれません(選んでください)。 この識別はRequesting Userの本人認証を必要とするかもしれません。
5.1.2. Authority to make requests
5.1.2. 要求をする権威
Where GSTN resources are used to provide a PINT service, it is at least possible that someone will have to pay for it. This person may not be the Requestor, as, for example, in the case of existing GSTN split-charging services like free phone in which the recipient of a call rather than the originator is responsible for the call cost.
それがGSTNリソースがPINTサービスを提供するのに使用されるのが少なくとも可能であるところに、そのだれかがそれの代価を払わなければならないでしょう。 この人はRequestorでないかもしれません、例えば既存に創始者よりむしろ呼び出しの受取人が呼び出し費用に責任がある無料の電話のような分裂を請求するGSTNサービスのケースのように。
This is not, of course, the only possibility; for example, PINT service may be provided on a subscription basis, and there are a number of other models. However, whichever model is chosen, there may be a requirement that the authority of a Requestor to make a PINT request is confirmed.
これはもちろん唯一の可能性ではありません。 例えば、購読ベースでPINTサービスを提供するかもしれません、そして、他の多くのモデルがあります。 しかしながら、どれがモデルを選ばれても、RequestorがPINT要求をする権威が確認されるという要件があるかもしれません。
If such confirmation is not available, then, again, the PINT Gateway and associated Executive System may choose not to provide service.
次に、そのような確認が再び利用可能でないなら、PINTゲートウェイと関連Executive Systemは、サービスを提供しないのを選ぶかもしれません。
5.1.3. Privacy
5.1.3. プライバシー
Even if the identity of the Requesting User and the Authority under which they make their request is known, there remains the possibility that the request is either corrupted, maliciously altered, or even replaced whilst in transit between the Requestor and the PINT Gateway.
彼らが自分達の要求をするRequesting UserとAuthorityのアイデンティティが知られても、要求を崩壊するか、陰湿に変更するか、または取り替えさえする可能性はトランジットにはある間、RequestorとPINTゲートウェイの間に残っています。
Similarly, information on the Authority under which a request is made may well be carried within that request. This can be sensitive information, as an eavesdropper might steal this and use it within their own requests. Such authority SHOULD be treated as if it were financial information (such as a credit card number or PIN).
同様に、要求がされるAuthorityの情報はたぶんその要求の中で運ばれるでしょう。 立ち聞きする者がそれら自身の要求の中でこれを盗んで、それを使用するかもしれないので、これは機密情報であるかもしれません。 そのような権威SHOULD、まるでそれが財務情報(クレジットカード番号か暗証番号などの)であるかのように、扱われてください。
Petrack & Conroy Standards Track [Page 47] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[47ページ]。
The data authorizing a Requesting User to make a PINT request should be known only to them and the service provider. However, this information may be in a form that does not match the schemes normally used within the Internet. For example, X.509 certificates[14] are commonly used for secured transactions on the Internet both in the IP Security Architecture[12] and in the TLS protocol[13], but the GSTN provider may only store an account code and PIN (i.e. a fixed string of numbers).
Requesting UserがPINT要求をするのを認可するデータはそれらとサービスプロバイダーだけにおいて知られているべきです。 しかしながら、この情報は通常、インターネットの中で使用された計画に合っていないフォームにあるかもしれません。 例えば、X.509証明書[14]は担保付き取引にインターネットでIP Security Architecture[12]とTLSプロトコル[13]に一般的に使用されますが、GSTNプロバイダーは勘定符号と暗証番号(すなわち、数の固定ストリング)を格納するだけであるかもしれません。
A Requesting User has a reasonable expectation that their requests for service are confidential. For some PINT services, no content is carried over the Internet; however, the telephone or fax numbers of the parties to a resulting service calls may be considered sensitive. As a result, it is likely that the Requestor (and their PINT service provider) will require that any request that is sent across the Internet be protected against eavesdroppers; in short, the requests SHOULD to be encrypted.
サービスを求める彼らの要求は合理的な期待ですが、Requesting Userは秘密でした。秘密。 いくつかのPINTサービスにおいて、内容は全くインターネットの上まで運ばれません。 しかしながら、結果として起こる業務通話へのパーティーの電話かファックス番号が敏感であると考えられるかもしれません。 その結果、Requestor(そして、それらのPINTサービスプロバイダー)は、インターネットの向こう側に送られるどんな要求も立ち聞きする者に対して保護されるのを必要としそうでしょう。 コード化されるという要するに要求SHOULD。
5.1.4. Privacy Implications of SUBSCRIBE/NOTIFY
5.1.4. プライバシー含意、申し込むか、または通知してください。
Some special considerations relate to monitoring sessions using the SUBSCRIBE and NOTIFY messages. The SUBSCRIBE message that is used to register an interest in the disposition of a PINT service transaction uses the original Session Description carried in the related INVITE message. This current specification does not restrict the source of such a SUBSCRIBE message, so it is possible for an eavesdropper to capture an unprotected session description and use this in a subsequent SUBSCRIBE request. In this way it is possible to find out details on that transaction that may well be considered sensitive.
いくつかの特別な問題が使用することでモニターしているセッションまで関係する、登録、そして、NOTIFYメッセージ。 登録、PINTサービス取引の気質への関心を示すのに使用されるメッセージは関連するINVITEメッセージで運ばれたオリジナルのSession記述を使用します。 この現在の仕様が登録が通信させるそのようなものの源を制限しないので立ち聞きする者が保護のないセッション記述を得て、aその後でこれを使用するのが、可能である、登録、要求。 その取引に関する詳細を見つけるのが可能であるこのように、それは敏感であるとたぶん考えられるでしょう。
The initial solution to this risk is to recommend that a session description that may be used within a subsequent SUBSCRIBE message SHOULD be protected.
このリスクの初期の解決策は登録、メッセージSHOULDというaその後中で使用されて、ことであるかもしれないセッション記述が保護されることを勧めることです。
However, there is a further risk; if the origin-field used is "guessable" then it might be possible for an attacker to reconstruct the session description and use this reconstruction within a SUBSCRIBE message.
しかしながら、さらなるリスクがあります。 使用される起源分野が「推測可能である」なら、攻撃者が登録の中のこの再建が通信させるセッション記述と使用を再建するのは、可能であるかもしれません。
SDP (see section 6 of [2], "o=" field) does not specify the mechanism used to generate the sess-id field, and suggests that a method based on timestamps produced by Network Time Protocol [16] can be used. This is sufficient to guarantee uniqueness, but may allow the value to be guessed, particularly if other unprotected requests from the same originator are available.
SDPは、sess-イド分野を発生させるのに使用されるメカニズムを指定しないで、Network Timeプロトコル[16]によって作り出されたタイムスタンプに基づく方法は使用できるのを示します([2]のセクション6を見てください、「o=」分野)。 これは、値が推測されるのをユニークさを保証できるくらい許容するかもしれません、特に同じ創始者からの他の保護のない要求が利用可能であるなら。
Petrack & Conroy Standards Track [Page 48] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[48ページ]。
Thus, to ensure that the session identifier is not guessable the techniques described in section 6.3 of [17] can be used when generating the origin-field for a session description to be used inside a PINT INVITE message. If all requests from (and responses to) a particular PINT requesting entity are protected, then this is not needed. Where such a situation is not assured, AND where session monitoring is supported, then a method by which an origin-field within a session description is not guessable SHOULD be used.
セッション記述がPINT INVITEメッセージに使用されるために起源分野を発生させるとき、したがって、セッション識別子が確実に推測可能にならないようにするのに、[17]のセクション6.3で説明されたテクニックは使用できます。 すべての要求である、(応答、)、実体を要求するa特定のPINTが保護されて、次に、これは必要ではありません。 セッションモニターが支持されて、その時がセッション記述の中の起源分野がguessable SHOULDでない方法であるところで保証されないで、そのような状況がそうで使用されてください。
5.2. Registration Procedures
5.2. 登録手順
Any number of PINT Gateways may register to provide the same service; this is indicated by the Gateways specifying the same "userinfo" part in the To: header field of the REGISTER request. Whilst such ambiguity would be unlikely to occur with the scenarios covered by "core" SIP, it is very likely for PINT; there could be any number of service providers all willing to support a "Request-To-Fax" service, for example.
いろいろなPINT Gatewaysが同じサービスを提供するために登録するかもしれません。 これはTo:で同じ"userinfo"部分を指定するGatewaysによって示されます。 REGISTER要求のヘッダーフィールド。 シナリオが「コア」SIPでカバーされている状態で、そのようなあいまいさは起こりそうでないでしょうが、PINTに、それは非常にありそうです。 例えば「要求からファックス」サービスを支持しても構わないと思っているいろいろなサービスプロバイダーがすべて、あるかもしれません。
Unless a request specifies the Gateway name explicitly, an intervening Proxy that acts on a registration database to which several Gateways have all registered is in a position to select from the registrands using whatever algorithm it chooses; in principle, any Gateway that has registered as "R2F" would be appropriate.
要求が明らかにゲートウェイ名を指定しない場合、数個のGatewaysがすべて、登録した登録データベースに影響する介入しているProxyがそれが選ぶどんなアルゴリズムも使用することでregistrandsから選び抜く立場にあります。 原則として、"R2F"として登録されたどんなゲートウェイも適切でしょう。
However, this opens up an avenue for attack, and this is one in which a "rogue" Gateway operator stands to make a significant gain. The standard SIP procedure for releasing a registration is to send a REGISTER request with a Contact field having a wildcard value and an expires parameter with a value of 0. It is important that a PINT Registrar uses authentication of the Registrand, as otherwise one PINT service provider would be able to "spoof" another and remove their registration. As this would stop the Proxy passing any requests to that provider, this would both increase requests being sent to the rogue and stop requests going to the victim.
しかしながら、これは攻撃のために大通りを開けます、そして、「凶暴な」ゲートウェイのオペレータが重要な利得を作るのがあらせるものです。 そして、登録をリリースするための標準のSIP手順がワイルドカード値を持っているContact分野があるREGISTER要求を送ることである、0の値でパラメタを吐き出します。 PINT RegistrarがRegistrandの認証を使用するのは、重要です、さもなければ、1つのPINTサービスプロバイダーが別のものを「だまし」て、彼らの登録を取り除くことができるだろうというとき。 Proxyがどんな要求にもそのプロバイダーに合格するのを止めるように、これは、悪党に送られる要求を増加させて、要求が犠牲者のものになるのを止めるでしょう。
Another variant on this attack would be to register a Gateway using a name that has been registered by another provider; thus a rogue Operator might register its Gateway as "R2C@pint.att.com", thereby hijacking requests.
この攻撃での別の異形は別のプロバイダーによって登録された名前を使用することでゲートウェイを登録することになっているでしょう。 したがって、凶暴なOperatorは" R2C@pint.att.com "としてゲートウェイを登録して、その結果、要求をハイジャックするかもしれません。
The solution is the same; all registrations by PINT Gateways MUST be authenticated; this includes both new or apparent replacement registrations, and any cancellation of current registrations. This recommendation is also made in the SIP specification, but for the correct operation of PINT, it is very important indeed.
解決策は同じです。 PINT Gatewaysによるすべての登録証明書を認証しなければなりません。 これは新しいか見かけの交換登録証明書と現在の登録証明書のどんなキャンセルの両方も含んでいます。 また、SIP仕様でこの推薦状をしますが、PINTの正しい操作において、本当に、それは非常に重要です。
Petrack & Conroy Standards Track [Page 49] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[49ページ]。
5.3. Security mechanisms and implications on PINT service
5.3. PINTサービスでのセキュリティー対策と含意
PINT is a set of extensions to SIP[1] and SDP[2], and will use the security procedures described in SIP. There are several implications of this, and these are covered here.
PINTはSIP[1]とSDP[2]への1セットの拡大であり、SIPで説明されたセキュリティ手順を用いるでしょう。 このいくつかの含意があります、そして、これらはここに覆われています。
For several of the PINT services, the To: header field of SIP is used to identify one of the parties to the resulting service call. The PINT Request-To-Call service is an example. As mentioned in the SIP specification, this field is used to route SIP messages through an infrastructure of Redirect and Proxy server between the corresponding User Agent Servers, and so cannot be encrypted. This means that, although the majority of personal or sensitive data can be protected whilst in transit, the telephone (or fax) number of one of the parties to a PINT service call cannot, and will be "visible" to any interception. For the PINT milestone services this may be acceptable, since the caller named in the To: service is typically a "well known" provider address, such as a Call Center.
いくつかのPINTサービス、To:のために SIPのヘッダーフィールドは、結果として起こる業務通話へのパーティーのひとりを特定するのに使用されます。 PINT Requestから呼び出しに対するサービスは例です。 SIP仕様で言及されるように、RedirectとProxyサーバのインフラストラクチャを通して対応するUserエージェントServersの間にSIPメッセージを発送するのに使用されるので、この分野をコード化できません。 これはそれを意味します、PINT業務通話へのパーティーのひとりの電話(または、ファックス)番号がトランジットでは、目に見えることができないで、どんな妨害への」にもなる間「目に見える個人的であるか機密のデータの大部分を保護できますが。 PINT重大事件サービスにおいて、To:で指定された訪問者以来これは許容できるかもしれません。 通常、サービスはCallセンターなどの「よく知られている」プロバイダーアドレスです。
Another aspect of this is that, even if the Requesting User does not consider the telephone or fax numbers of the parties to a PINT service to be private, those parties might. Where PINT servers have reason to believe this might be the case they SHOULD encrypt the request, even if the Requestor has not done so. This could happen, for example, if a Requesting User within a company placed a PINT request and this was carried via the company's Intranet to their Proxy/firewall and thence over the Internet to a PINT Gateway at another location.
このもう一つの側面はRequesting Userが、PINTサービスへのパーティーの電話かファックス番号が個人的であると考えないでもそれらのパーティーがそうするかもしれないということです。 PINTサーバにはこれを信じる理由がケースがそれらであったかもしれないならあるところでは、SHOULDは要求をコード化します、Requestorがそうしていなくても。 例えば、会社の中のRequesting UserがPINT要求を置いて、これがそれらのProxy/ファイアウォールとそこからインターネットの上の会社のイントラネットでもう1つの位置のPINTゲートウェイまで運ばれるなら、起こることができるでしょうに。
If a request carries data that can be reused by an eavesdropper either to "spoof" the Requestor or to obtain PINT service by inserting the Requestor's authorization token into an eavesdropper's request, then this data MUST be protected. This is particularly important if the authorization token consists of static text (such as an account code and/or PIN).
要求が立ち聞きする者がRequestorを「だます」か、またはRequestorの認可象徴を立ち聞きする者の要求に挿入することによってPINTサービスを得るために再利用できるデータを運ぶなら、このデータを保護しなければなりません。 認可象徴が静的なテキスト(勘定符号、そして/または、暗証番号などの)から成るなら、これは特に重要です。
One approach is to encrypt the whole of the request, using the methods described in the SIP specification. As an alternative, it may be acceptable for the authorization token to be held as an opaque reference (see section 3.4.2.3 and examples 4.11 and 4.12), using some proprietary scheme agreed between the Requestor and the PINT service provider, as long as this is resistant to interception and re-use. Also, it may be that the authorization token cannot be used outside of a request cryptographically signed by the Requestor; if so then this requirement can be relaxed, as in this case the token cannot be re-used by another. However, unless both the Requestor and the Gateway are assured that this is the case, any authorization token MUST be treated as sensitive, and so MUST be encrypted.
1つのアプローチはSIP仕様で説明された方法を使用して、要求の全体をコード化することです。 代替手段として、認可象徴が不明瞭な参照として持たれているのは、許容できるかもしれません(セクション3.4.2の.3と例4.11と4.12を見てください)、RequestorとPINTサービスプロバイダーの間で同意される何らかの独占計画を使用して、これは妨害と再使用に抵抗力がある限り。 また、そして、多分、Requestorによって暗号でサインされた要求の外で認可象徴を使用できません。 そうだとすれば、そして、別のものがこの場合象徴を再使用できないようにこの要件はリラックスできます。 しかしながら、Requestorとゲートウェイの両方がこれがそうであることが保証されない場合、敏感であるとして扱わなければならないので、どんな認可象徴もコード化しなければなりません。
Petrack & Conroy Standards Track [Page 50] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[50ページ]。
A PINT request may contain data within the SDP message body that can be used more efficiently to route that request. For example, it may be that one Gateway and Executive System combination cannot handle a request that specifies one of the parties as a pager, whilst another can. Both gateways may have registered with a PINT/SIP Registrar, and this information may be available to intervening PINT/SIP Proxies. However, if the message body is encrypted, then the request cannot be decoded at the Proxy server, and so Gateway selection based on contained information cannot be made there.
PINT要求はその要求を発送するのにより効率的に使用できるSDPメッセージボディーの中にデータを含むかもしれません。 例えば、多分、1つのゲートウェイとExecutive System組み合わせはポケットベルとしてパーティーのひとりを指定する要求を扱うことができません、別のものがそうすることができますが。 両方のゲートウェイはPINT/SIP Registrarとともに記名したかもしれません、そして、この情報は介入しているPINT/SIP Proxiesに利用可能であるかもしれません。 しかしながら、メッセージ本体がコード化されているならProxyサーバで要求を解読できないので、そこで含まれた情報に基づくゲートウェイ選択はすることができません。
The result is that the Proxy may deliver the request to a Gateway that cannot handle it; the implication is that a PINT/SIP Proxy SHOULD consider its choice for the appropriate Gateway subject to correction, and, on receiving a 501 or 415 rejection from the first gateway chosen, try another. In this way, the request will succeed if at all possible, even though it may be delayed (and tie up resources in the inappropriate Gateways).
結果はProxyがそれを扱うことができないゲートウェイに要求を提供するかもしれないということです。 含意はPINT/SIP Proxy SHOULDが適切なゲートウェイ対象のための選択を修正と考えて、選ばれた最初のゲートウェイから501か415拒絶を受けるとき別のものを試みるということです。 このように、できれば、要求は成功するでしょう、遅れるかもしれませんが(不適当なGatewaysのリソースをタイアップしてください)。
This opens up an interesting avenue for Denial Of Service; sending a valid request that appears to be suitable for a number of different Gateways, and simply occupying those Gateways in decrypting a message requesting a service they cannot provide. As mentioned in section 3.5.5.1, the choice of service name to be passed in the userinfo portion of the SIP Request-URI is flexible, and it is RECOMMENDED that names be chosen that allow a Proxy to select an appropriate Gateway without having to examine the SDP body part. Thus, in the example given here, the service might be called "Request-To-Page" or "R2P" rather than the more general use of "R2F", if there is a possibility of the SDP body part being protected during transit.
これはDenial Of Serviceのためにおもしろい大通りを開けます。 有効な要求にそれを送るのは多くの異なったGatewaysに適当であるように見えます、そして、サービスを要求するメッセージを解読しながら単にそれらのGatewaysに従事していて、彼らは前提とすることができません。 セクション3.5.5で.1、サービス名の選択が通過されて、SIP Request-URIのuserinfo部分がフレキシブルであり、それが名前に選ばれているのが、RECOMMENDEDであるということであると言及するように、SDP身体の部分を調べる必要はなくて、Proxyに適切なゲートウェイを選択させてください。 したがって、ここに、出された例ではサービスは「要求からページ」か"R2F"の、より一般的な使用よりむしろ"R2P"と呼ばれるかもしれません、トランジットの間に保護されるSDP身体の部分の可能性があれば。
A variation on this attack is to provide a request that is syntactically invalid but that, due to the encryption, cannot be detected without expending resources in decoding it. The effects of this form of attack can be minimised in the same way as for any SIP Invitation; the Proxy should detect the 400 rejection returned from the initial Gateway, and not pass the request onwards to another.
この攻撃の変化はシンタクス上無効ですが、暗号化のためそれを解読しながらリソースを使わないで検出できない要求を提供することです。 同様に、この形式の攻撃の効果はどんなSIP Invitationのようにも最小となることができます。 Proxyは初期のゲートウェイから返された400拒絶を検出して、前方へ別のものに要求に合格するはずがありません。
Finally, note that the Requesting User may not have a prior relationship with a PINT Gateway, whilst still having a prior relationship with the Operator of the Executive System that fulfills their request. Thus there may be two levels of authentication and authorization; one carried out using the techniques described in the SIP specification (for use between the Requestor and the Gateway), with another being used between the Requesting User or the Requestor and the Executive System.
最終的に、まだ彼らの要求を実現させるExecutive SystemのOperatorとの先の関係を持っている間、Requesting UserにはPINTゲートウェイとの先の関係がないかもしれないことに注意してください。 したがって、2つのレベルの認証と承認があるかもしれません。 1つは外でSIP仕様で説明されたテクニックを使用することで運ばれました(Requestorとゲートウェイの間の使用のために)、別のものがRequesting UserかRequestorとExecutive Systemの間で使用されている状態で。
Petrack & Conroy Standards Track [Page 51] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[51ページ]。
For example, the Requesting User may have an account with the PINT service provider. That provider might require that requests include this identity before they will be convinced to provide service. In addition, to counter attacks on the request whilst it is in transit across the Internet, the Gateway may require a separate X.509-based certification of the request. These are two separate procedures, and data needed for the former would normally be expected to be held in opaque references inside the SDP body part of the request.
例えば、Requesting Userには、PINTサービスプロバイダーとのアカウントがあるかもしれません。 そのプロバイダーは、彼らがサービスを提供するように確信する前に要求がこのアイデンティティを含んでいるのを必要とするかもしれません。 さらに、それがトランジットインターネットのむこうで中である間、要求に対する攻撃に対抗するために、ゲートウェイは要求の別々のX.509ベースの証明を必要とするかもしれません。 これらは2つの別々の手順です、そして、通常、要求のSDP身体の部分の中に不明瞭な参照に前者に必要であるデータが保持されると予想されるでしょう。
The detailed operation of this mechanism is, by definition, outside the scope of an Internet Protocol, and so must be considered a private matter. However, one approach to indicating to the Requestor that such "second level" authentication or authorization is required by their Service Provider would be to ask for this inside the textual description carried with a 401 response returned from the PINT Gateway.
インターネットプロトコルの範囲の外に定義上あるので、個人的な問題であるとこのメカニズムの詳細な操作を考えなければなりません。 しかしながら、そのような「2番目の平らな」認証か承認がそれらのService Providerによって必要とされるのをRequestorに示すことへの1つのアプローチはPINTゲートウェイから401応答を返していて運ばれた原文の記述でこれを求めるだろうことです。
5.4. Summary of Security Implications
5.4. セキュリティ含意の概要
From the above discussion, PINT always carries data items that are sensitive, and there may be financial considerations as well as the more normal privacy concerns. As a result, the transactions MUST be protected from interception, modification and replay in transit.
上の議論から、PINTは敏感なデータ項目をいつも運びます、そして、より正常なプライバシーの問題と同様に財政的な問題があるかもしれません。 その結果、トランザクションは、妨害、変更から保護されて、トランジットで再演されなければなりません。
PINT is based on SIP and SDP, and can use the security procedures outlined in [1] (sections 13 and 15). However, in the case of PINT, the SIP recommendation that requests and responses MAY be protected is not enough. PINT messages MUST be protected, so PINT Implementations MUST support SIP Security (as described in [1], sections 13 & 15), and be capable of handling such received messages.
PINTはSIPとSDPに基づいていて、[1](セクション13と15)に概説されたセキュリティ手順を用いることができます。 しかしながら、PINTの場合では、要求と応答が保護されるかもしれないというSIP推薦は十分ではありません。 PINTメッセージを保護しなければならないので、PINT ImplementationsはSIP Security([1]、セクション13と15で説明されるように)をサポートして、そのような受信されたメッセージを扱うことができなければなりません。
In some configurations, PINT Clients, Servers, and Gateways can be sure that they operate using the services of network level security [13], transport layer security [12], or physical security for all communications between them. In these cases messages MAY be exchanged without SIP security, since all traffic is protected already. Clients and servers SHOULD support manual configuration to use such lower layer security facilities.
いくつかの構成をPINT Clients、Servers、およびGatewaysは彼らがそれらのすべてのコミュニケーションにネットワークレベルセキュリティ[13]、トランスポート層セキュリティ[12]、または物理的なセキュリティのサービスを利用することで作動するのを確認している場合があります。 これらの場合では、すべてのトラフィックが既に保護されるので、SIPセキュリティなしでメッセージを交換するかもしれません。 クライアントとサーバSHOULDは、そのような下層セキュリティ施設を使用するために手動の構成をサポートします。
When using network layer security [13], the Security Policy Database MUST be configured to provide appropriate protection to PINT traffic. When using TLS, a port configured MUST NOT also be configured for non-TLS traffic. When TLS is used, basic authentication MUST be supported, and client-side certificates MAY be supported.
ネットワーク層セキュリティ[13]を使用するとき、適切な保護をPINTトラフィックに提供するためにSecurity Policy Databaseを構成しなければなりません。 また、TLSを使用するとき、非TLSトラフィックのために構成されたポートを構成してはいけません。 TLSが使用されているとき、基本認証をサポートしなければなりません、そして、クライアントサイド証明書は支えられるかもしれません。
Petrack & Conroy Standards Track [Page 52] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[52ページ]。
Authentication of the Client making the request is required, however, so if this is not provided by the underlying mechanism used, then it MUST be included within the PINT messages using SIP authentication techniques. In contrast with SIP, PINT requests are often sent to parties with which a prior communications relationship exists (such as a Telephone Carrier). In this case, there may be a shared secret between the client and the PINT Gateway. Such PINT systems MAY use authentication based on shared secrets, with HTTP "basic authentication". When this is done, the message integrity and privacy must be guaranteed by some lower layer mechanism.
要求をするClientの認証が必要であるので、SIP認証のテクニックを使用して、これが使用される発症機序で提供されないなら、しかしながら、PINTメッセージの中にそれを含まなければなりません。 SIPと比べて、しばしば先のコミュニケーション関係が存在するパーティー(Telephone Carrierなどの)にPINT要求を送ります。 この場合、クライアントとPINTゲートウェイの間には、共有秘密キーがあるかもしれません。 そのようなPINTシステムはHTTP「基本認証」がある共有秘密キーに基づく認証を使用するかもしれません。 これが完了していると、何らかの下層メカニズムでメッセージの保全とプライバシーを保証しなければなりません。
There are implications on the operation of PINT here though. If a PINT proxy or redirect server is used, then it must be able to examine the contents of the IP datagrams carried. It follows that an end-to-end approach using network-layer security between the PINT Client and a PINT Gateway precludes the use of an intervening proxy; communication between the Client and Gateway is carried via a tunnel to which any intervening entity cannot gain access, even if the IP datagrams are carried via this node. Conversely, if a "hop-by-hop" approach is used, then any intervening PINT proxies (or redirect servers) are, by implication, trusted entities.
もっとも、PINTの操作には含意がここにあります。 PINTプロキシか再直接のサーバが使用されているなら、データグラムが運んだIPのコンテンツを調べることができなければなりません。 終わりから終わりへのPINT ClientとPINTゲートウェイの間のネットワーク層セキュリティを使用するアプローチが介入しているプロキシの使用を排除するということになります。 Clientとゲートウェイとのコミュニケーションはどんな介入している実体もアクセスを得ることができないトンネルを通って運ばれます、IPデータグラムがこのノードで運ばれても。 逆に、「ホップごとの」アプローチが使用されているなら、いくつかの介入しているPINTプロキシ(サーバを向け直す)が含意、信じられた実体であります。
However, if there is any doubt that there is an underlying network or transport layer security association in place, then the players in a PINT protocol exchange MUST use encryption and authentication techniques within the protocol itself. The techniques described in section 15 of RFC2543 MUST be used, unless there is an alternative protection scheme that is agreed between the parties. In either case, the content of any message body (or bodies) carried within a PINT request or response MUST be protected; this has implications on the options for routing requests via Proxies (see 5.3).
しかしながら、何か基本的なネットワークかトランスポート層セキュリティ協会が適所にあるという疑問があれば、PINTプロトコル交換におけるプレーヤーはプロトコル自体の中で暗号化と認証のテクニックを使用しなければなりません。 RFC2543 MUSTのセクション15で説明されたテクニックが使用されて、代替の保護体系がない場合、パーティーの間でそれは同意されます。 どちらの場合ではも、PINT要求か応答の中で運ばれたどんなメッセージ本体(または、ボディー)の内容も保護しなければなりません。 これはProxiesを通してルーティング要求のためのオプションに意味を持っています(5.3を見てください)。
Using SIP techniques for protection, the Request-URI and To: fields headers within PINT requests cannot be protected. In the baseline PINT services these fields may contain sensitive information. This is a consideration, and if these data ARE considered sensitive, then this will preclude the sole use of SIP techniques; in such a situation, transport [12] or network layer [13] protection mechanisms MUST be used.
保護にSIPのテクニックを使用する、Request-URI、およびTo: PINTの中のヘッダーが保護できないよう要求する分野。 基線PINTサービスでは、これらの分野は機密情報を含むかもしれません。 これは考慮です、そして、これらのデータが敏感であると考えられると、SIPのテクニックの唯一の使用を排除するでしょう。 そのような状況で、輸送[12]かネットワーク層[13]保護メカニズムを使用しなければなりません。
As a final point, this choice will in turn have an influence on the choice of transport layer protocol that can be used; if a TLS association is available between two nodes, then TCP will have to be used. This is different from the default behaviour of SIP (try UDP, then try TCP if that fails).
最終的なポイントとして、この選択は使用できるトランスポート層プロトコルの選択のときに順番に影響するでしょう。 TLS協会が2つのノードの間で利用可能であるなら、TCPは使用されなければならないでしょう。 これはSIPのデフォルトのふるまいと異なっています(UDPを試みてください、そして、それが失敗するなら、次に、TCPを試みてください)。
Petrack & Conroy Standards Track [Page 53] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[53ページ]。
6. Deployment considerations and the Relationship PINT to I.N. (Informative)
6. I.Nへの展開問題とRelationship PINT。(有益)です。
6.1. Web Front End to PINT Infrastructure
6.1. パイントインフラストラクチャへのウェブフロントエンド
It is possible that some other protocol may be used to communicate a Requesting User's requirements. Due to the high numbers of available Web Browsers and servers it seems likely that some PINT systems will use HTML/HTTP as a "front end". In this scenario, HTTP will be used over a connection from the Requesting User's Web Browser (WC) to an Intermediate Web Server (WS). This will be closely associated with a PINT Client (using some unspecified mechanism to transfer the data from the Web Server to the PINT Client). The PINT Client will represent the Requesting User to the PINT Gateway, and thus to the Executive System that carries out the required action.
ある他のプロトコルがRequesting Userの要件を伝えるのに使用されるのは、可能です。 利用可能なウェブBrowsersとサーバの大きい数のため、HTML/HTTPは「フロントエンド」としていくつかのPINTシステムは使用されそうでしょう。 このシナリオでは、HTTPはRequesting UserのウェブBrowser(トイレ)からIntermediateウェブServer(WS)までの接続の上で使用されるでしょう。 これは密接にPINT Clientに関連づけられるでしょう(ウェブServerからPINT Clientまでデータを移すのに何らかの不特定のメカニズムを使用して)。 PINT ClientはPINTゲートウェイと、そして、その結果、必要な動作を行うExecutive SystemにRequesting Userを表すでしょう。
[WC]------[WS]
[PC]
\
\
[PG]
[XS]
[トイレ]------[W][PC]\\[未成年者不適当映画][XS]
Figure 2: Basic "Web-fronted" Configuration
図2: 基本的な「ウェブで向かわれた」構成
6.2. Redirects to Multiple Gateways
6.2. 倍数にゲートウェイを向け直します。
It is quite possible that a given PINT Gateway is associated with an Executive System (or systems) that can connect to the GSTN at different places. Equally, if there is a chain of PINT Servers, then each of these intermediate or proxy servers (PP) may be able to route PINT requests to Executive Systems that connect at specific points to the GSTN. The result of this is that there may be more than one PINT Gateway or Executive System that can deal with a given request. The mechanisms by which the choice on where to deliver a request are outside the scope of this document.
与えられたPINTゲートウェイが異なった場所のGSTNに接続できるExecutive System(または、システム)に関連しているのは、かなり可能です。 等しく、PINT Serversのチェーンがあれば、それぞれのこれらの中間的かプロキシサーバ(PP)が特定のポイントでGSTNに接続するExecutive SystemsにPINT要求を発送できるかもしれません。 この結果は与えられた要求に対処できる1PINTゲートウェイかExecutive Systemがあるかもしれないということです。 このドキュメントの範囲の外に要求をどこに提供するかに関する選択があるメカニズム。
[WC]------[WS] [WC]------[WS]
[PC] [PC]
\ \
\ \
[PG] [PP]
.........[XS]......... / \
: : / \
[PG] [PG]
[XS] [XS]
[トイレ]------[W][トイレ]------[W][PC][PC]\\\\[未成年者不適当映画][pp]…[XS]… / \ : : /\[未成年者不適当映画][未成年者不適当映画][XS][XS]
Figure 3: Multiple Access Configurations
図3: 複数のアクセス構成
Petrack & Conroy Standards Track [Page 54] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[54ページ]。
However, there do seem to be two approaches. Either a Server that acts as a proxy or redirect will select the appropriate Gateway itself and will cause the request to be sent on accordingly, or a list of possible Locations will be returned to the Requesting User from which they can select their choice.
しかしながら、2つのアプローチがあるように思えます。 プロキシか再直接として務めるServerが適切なゲートウェイ自体を選択して、それに従って、転送されるという要求を引き起こすだろうか、または彼らが自分達の選択を選択できるRequesting Userに可能なLocationsのリストを返すでしょう。
In SIP, the implication is that, if a proxy cannot resolve to a single unique match for a request destination, then a response containing a list of the choices should be returned to the Requesting User for selection. This is not too likely a scenario within the normal use of SIP.
SIPでは、含意はそれです、プロキシが、次に、選択のリストを含む応答が選択のためにRequesting Userに返されるべきであると要求の目的地への単一のユニークなマッチに決議できないなら。 これはSIPの通常の使用の中のありそう過ぎるシナリオではありません。
However, within PINT, such ambiguity may be quite common; it implies that there are a number of possible providers of a given service.
しかしながら、PINTの中では、そのようなあいまいさは全く一般的であるかもしれません。 それは、与えられたサービスの多くの可能なプロバイダーがあるのを含意します。
6.3. Competing PINT Gateways REGISTERing to offer the same service
6.3. 同じサービスを提供する競争しているPINT Gateways REGISTERing
With PINT, the registration is not for an individual but instead for a service that can be handled by a service provider. Thus, one can envisage a registration by the PINT Server of the domain telcoA.com of its ability to support the service R2C as "R2C@telcoA.com", sent to an intermediary server that acts as registrar for the "broker.telcos.com" domain from "R2C@pint.telcoA.com" as follows:
PINTと共に、登録は個人のためのものではありませんが、代わりに、サービスにおいて、サービスプロバイダーはそれを扱うことができます。 したがって、人は" R2C@telcoA.com "が" R2C@pint.telcoA.com "からの"broker.telcos.com"ドメインへの記録係として以下の通りに務める仲介者サーバに発信したのでサービスがR2Cであるとサポートする性能のドメインtelcoA.comのPINT Serverによる登録を考えることができます:
REGISTER sip:registrar@broker.telcos.com SIP/2.0
To: sip:R2C@pint.telcoA.com
From: sip:R2C@pint.telcoA.com
...
REGISTER一口: registrar@broker.telcos.com SIP/2.0To: 一口: R2C@pint.telcoA.com From: ちびちび飲んでください: R2C@pint.telcoA.com
This is the standard SIP registration service.
これは標準のSIP登録サービスです。
However, what happens if there are a number of different Service Providers, all of whom support the "R2C" service? Suppose there is a PINT system at domain "broker.com". PINT clients requesting a Request-to-Call service from broker.com might be very willing to be redirected or proxied to any one of the various service providers that had previously registered with the registrar. PINT servers might also be interested in providing service for requests that did not specify the service provider explicitly, as well as those requests that were directed "at them".
しかしながら、多くの異なったService Providers(そのすべてが、"R2C"がサービスであるとサポートする)があれば、何が起こりますか? PINTシステムがドメイン"broker.com"にあると仮定してください。 broker.comからRequestから呼び出しに対するサービスを要求するPINTクライアントは、以前に記録係とともに記名した様々なサービスプロバイダーのどれかに向け直される、またはproxiedされても構わないと非常に思っているかもしれません。 また、PINTサーバは明らかにサービスプロバイダーを指定しなかった要求のためのサービスを提供したがっているかもしれません、「それら」で指示されたそれらの要求と同様に。
To enable such service, PINT servers would REGISTER at the broker PINT server registrations of the form:
そのようなサービスを可能にするために、PINTサーバがそうするだろう、形式のブローカーPINTサーバ登録証明書におけるREGISTER:
REGISTER sip:registrar@broker.com SIP/2.0
To: sip:R2C@broker.com
From: sip:R2C@pint.telcoA.com
REGISTER一口: registrar@broker.com SIP/2.0To: 一口: R2C@broker.com From: 一口: R2C@pint.telcoA.com
Petrack & Conroy Standards Track [Page 55] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[55ページ]。
When several such REGISTER messages appear at the registrar, each differing only in the URL in the From: line, the registrar has many possibilities, e.g.:
From:のURLだけにおいてそれぞれ異なって、そのようないくつかのREGISTERメッセージが記録係に現れる場合 立ち並んでください、そして、記録係は例えば多くの可能性を持っています:
(i) it overwrites the prior registration for "R2C@broker.telcos.com"
when the next comes in;
(i) " R2C@broker.telcos.com "のための次が入る先の登録を上書きします。
(ii) it rejects the subsequent registration for
"R2C@broker.telcos.com";
(ii) それは" R2C@broker.telcos.com "のためにその後の登録を拒絶します。
(iii) it maintains all such registrations.
(iii) それはそのようなすべての登録証明書を維持します。
In this last case, on receiving an Invitation for the "general" service, either:
これでは、「一般的な」サービスのためにInvitationを受けるとき、最後にどちらかをケースに入れてください:
(iii.1) it passes on the invitation to all registered service
providers, returning a collated response with all
acceptances, using multiple Location: headers,
or
(iii.2) it silently selects one of the registrations (using, for
example, a "round robin" approach) and routes the Invitation
and response onwards without further comment.
(iii.1) それはすべての登録されたサービスプロバイダーへの招待を伝えます、すべての承認と共に照合された応答を返して、複数のLocationを使用して: ヘッダー、(iii.2)それは、静かに登録証明書(例えば「連続」アプローチを使用する)の1つを選択して、前方へそれ以上意見を述べずにInvitationと応答を発送します。
As an alternative to all of the above approaches, it:
上のアプローチのすべてに代わる手段としてそれ:
(iv) may choose to not allow registrations for the "general" service,
rejecting all such REGISTER requests.
そのようなすべてのREGISTER要求を拒絶して、(iv)は、「一般的な」サービスのための登録証明書を許容しないのを選ぶかもしれません。
The algorithm by which such a choice is made will be implementation- dependent, and is outside the scope of PINT. Where a behaviour is to be defined by requesting users, then some sort of call processing language might be used to allow those clients, as a pre-service operation, to download the behaviour they expect to the server making such decisions. This, however, is a topic for other protocols, not for PINT.
そのような選択がされるアルゴリズムは、実装に依存して、PINTの範囲の外にあります。 そして、ユーザを要求することによって定義されるところでは、ふるまいがことであるある種の呼び出し処理言語が、彼らがそのような決定をするサーバに予想するふるまいをダウンロードへのプレサービス操作としてのそれらのクライアントに許容するのに使用されるかもしれません。 しかしながら、これはPINTではなく、他のプロトコルのための話題です。
6.4. Limitations on Available Information and Request Timing for
SUBSCRIBE
6.4. 入手可能な情報における制限と要求タイミング、登録。
A reference configuration for PINT is that service requests are sent, via a PINT Gateway, to an Executive System that fulfills the Service Control Function (SCF) of an Intelligent Network (see [11]). The success or failure of the resulting service call may be information available to the SCF and so may potentially be made available to the PINT Gateway. In terms of historical record of whether or not a service succeeded, a large SCF may be dealing with a million call attempts per hour. Given that volume of service transactions, there
PINTのための参照構成はサービスのリクエストを送るということです、PINTゲートウェイを通して、Intelligent NetworkのService Control Function(SCF)を実現させるExecutive Systemに。([11])を見てください。 PINTゲートウェイは、SCFに利用可能な情報であるかもしれないので潜在的に結果として起こる業務通話の成否を入手するかもしれません。 サービスが成功したかどうかに関する歴史的な記録に関して、大きいSCFは毎時の100万の呼び出し試みに対処しているかもしれません。 サービス取引のそのボリュームに、そこに与えます。
Petrack & Conroy Standards Track [Page 56] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[56ページ]。
are finite limits beyond which it cannot store service disposition records; expecting to find out if a Fax was sent last month from a busy SCF is unrealistic.
それがサービス気質記録を保存できない有限限界です。 ファックスが先月忙しいSCFから送られたかどうか見つけると予想するのは非現実的です。
Other status changes, such as that on completion of a successful service call, require the SCF to arrange monitoring of the service call in a way that the service may not do normally, for performance reasons. In most implementations, it is difficult efficiently to interrupt a service to change it once it has begun execution, so it may be necessary to have two different services; one that sets GSTN resources to monitor service call termination, and one that doesn't. It is unlikely to be possible to decide that monitoring is required once the service has started.
うまくいっている業務通話の完成でのそれなどの他の状態変化は、SCFが通常、サービスがしないかもしれない方法における、業務通話のモニターをアレンジするのを必要とします、性能理由で。 ほとんどの実装では、いったん実行を始めたあとにそれを変えるためにサービスを中断するのは2つの異なったサービスを持つのが必要であることができなるように効率的に難しいです。 GSTNリソースに業務通話終了をモニターするように設定するもの、およびそうしないもの。 サービスがいったん始まるとモニターが必要であるのが決めるのにおいて可能でありそうにはありません。
These factors can have implications both on the information that is potentially available at the PINT Gateway, and when a request to register interest in the status of a PINT service can succeed. The alternative to using a general SCF is to provide a dedicated Service Node just for PINT services. As this node is involved in placing all service calls, it is in a position to collect the information needed. However, it may well still not be able to respond successfully to a registration of interest in call state changes once a service logic program instance is running.
これらの要素はともにPINTゲートウェイで潜在的に利用可能な情報に意味を持つことができます、そして、登録するという要求であるときに、PINTサービスの状態への関心は成功できます。 一般的なSCFを使用することへの代替手段はまさしくPINTサービスに専用Service Nodeを提供することです。 このノードがすべての業務通話を置くのにかかわるとき、それは必要である情報を集める立場にあります。 しかしながら、サービス論理プログラムインスタンスがいったん稼働していると、それはたぶん呼び出し状態変化で興味がある登録にまだ首尾よく応じることができないでしょう。
Thus, although a Requesting User may register an interest in the status of a service request, the PINT Gateway may not be in a position to comply with that request. Although this does not affect the protocol used between the Requestor and the PINT Gateway, it may influence the response returned. To avoid the problem of changing service logic once running, any registration of interest in status changes should be made at or before the time at which the service request is made.
したがって、Requesting Userはサービスのリクエストの状態への関心を示すかもしれませんが、PINTゲートウェイがその要求に応じる立場にないかもしれません。 これはRequestorとPINTゲートウェイの間で使用されるプロトコルに影響しませんが、それは返された応答に影響を及ぼすかもしれません。 時代かサービスのリクエストが作られる時代の前にサービス論理を変えるのが一度稼働するという問題を避けるために、状態変化における興味があるどんな登録もするべきです。
Conversely, if a historical request is made on the disposition of a service, this should be done within a short time after the service has completed; the Executive System is unlikely to store the results of service requests for long; these will have been processed as AMA (Automatic Message Accounting) records quickly, after which the Executive System has no reason to keep them, and so they may be discarded.
サービスの気質で歴史的な要求をするなら、サービスがした後に逆に、短い間以内にこれをするべきである、完成されます。 Executive Systemは長い間、サービスのリクエストの結果を保存しそうにはありません。 Executive Systemが理由を全くどれに持っていないかがそれらを保った後にAMA(自動Message Accounting)がすばやく記録するようにこれらが処理されてしまうだろうので、それらは捨てられるかもしれません。
Where the PINT Gateway and the Executive System are intimately linked, the Gateway can respond to status subscription requests that occur while a service is running. It may accept these requests and simply not even try to query the Executive System until it has information that a service has completed, merely returning the final status. Thus the PINT Requestor may be in what it believes is a monitoring state, whilst the PINT Gateway has not even informed the
PINTゲートウェイとExecutive Systemが親密にリンクされるところでは、ゲートウェイはサービスが稼働している間に現れる状態購読要求に応じることができます。 それは、これらの要求を受け入れて、サービスが完成した情報があるまで、Executive Systemについて絶対に質問しようとさえしないかもしれません、単に最終的な状態を返して。 したがって、それがモニターしている状態であると信じていることにはPINT Requestorがあるかもしれません、PINTゲートウェイは知らせてさえいませんが
Petrack & Conroy Standards Track [Page 57] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[57ページ]。
Executive System that a request has been made. This will increase the internal complexity of the PINT Gateway in that it will have a complex set of interlocking state machines, but does mean that status registration and indication CAN be provided in conjunction with an I.N. system.
要求がされた幹部社員System。 これは、複雑なセットの連動している州のマシンを持つのでPINTゲートウェイの内部の複雑さを増強しますが、I.N.システムに関連して状態登録と指示を提供できることを意味します。
6.5. Parameters needed for invoking traditional GSTN Services within
PINT
6.5. PINTの中に伝統的なGSTN Servicesを呼び出すのに必要であるパラメタ
This section describes how parameters needed to specify certain traditional GSTN services can be carried within PINT requests.
このセクションはPINT要求の中でどうある伝統的なGSTNサービスを指定するのに必要であるパラメタを運ぶことができるかを説明します。
6.5.1. Service Identifier
6.5.1. サービス識別子
When a Requesting User asks for a service to be performed, he or she will, of course, have to specify in some way which service. This can be done in the URLs within the To: header and the Request-URI (see section 3.5.5.1).
Requesting Userが、サービスが実行されるように頼むとき、その人はもちろん何らかの方法でどのサービスを指定しなければならないだろうか。 To:の中でURLでこれができます。 セクション3.5を見てください。ヘッダーとRequest-URI、(.5 .1)。
6.5.2. A and B parties
6.5.2. AとBパーティー
With the Request-to-Call service, they will also need to specify the A and B parties they want to be engaged in the resulting service call. The A party could identify, for example, the Call Center from which they want a call back, whilst the B party is their telephone number (i.e. who the Call Center agent is to call).
また、Requestから呼び出しに対するサービスで、彼らは、結果として起こる業務通話に従事するのにAと彼らが欲しいBパーティーを指定する必要があるでしょう。 Aパーティーは例えば彼らが呼び出しに戻っていて欲しいCallセンターを特定できました、Bパーティーがそれらの電話番号(すなわち、Callセンターのエージェントはだれを呼ぶことになっていますか)ですが。
The Request-to-Fax and Request-to-Hear-Content services require the B party to be specified (respectively the telephone number of the destination Fax machine or the telephone to which spoken content is to be delivered), but the A party is a Telephone Network based resource (either a Fax or speech transcoder/sender), and is implicit; the Requesting User does not (and cannot) specify it.
Requestからファックスとコンテンツサービスを聞くRequestが、Bパーティーが指定されるのを(それぞれ提供される話された内容がことである目的地ファックスマシンか電話の電話番号)必要としますが、Aパーティーは、Telephone Networkのベースのリソース(ファックスかスピーチトランスコーダ/送付者のどちらか)であり、内在しています。 Requesting Userは指定しません。(and cannot)はそれを指定します。
With the "Fax-Back" variant of the Request-to-Fax service, (i.e. where the content to be delivered resides on the GSTN) they will also have specify two parties. As before, the B party is the telephone number of the fax machine to which they want a fax to be sent. However, within this variant the A party identifies the "document context" for the GSTN-based document store from which a particular document is to be retrieved; the analogy here is to a GSTN user dialling a particular telephone number and then entering the document number to be returned using "touch tone" digits. The telephone number they dial is that of the document store or A party, with the "touch tone" digits selecting the document within that store.
Requestからファックスサービスの「ファックス逆」異形で、(すなわち、提供される内容はGSTNにそこにあります)それらは持つでしょう。また、2回のパーティーを指定させます。 従来と同様、Bパーティーは彼らがファックスを送って欲しいファックス装置の電話番号です。 しかしながら、この異形の中では、Aパーティーは検索される特定のドキュメントがことであるGSTNベースのドキュメント店のための「ドキュメント文脈」を特定します。 「接触トーン」ケタを使用することで返すために特定の電話番号にダイヤルして、次に公文書番号を入れるGSTNユーザにはここでの類推があります。 彼らがダイヤルする電話番号はドキュメント店かAパーティーのものです、「接触トーン」ケタがその店の中でドキュメントを選択している状態で。
Petrack & Conroy Standards Track [Page 58] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[58ページ]。
6.5.3. Other Service Parameters
6.5.3. 他のサービスパラメタ
In terms of the extra parameters to the request, the services again differ. The Request-to-Call service needs only the A and B parties. Also it is convenient to assert that the resulting service call will carry voice, as the Executive System within the destination GSTN may be able to check that assertion against the A and B party numbers specified and may treat the call differently.
要求への付加的なパラメタに関して、サービスは再び異なります。 Requestから呼び出しに対するサービスはAとBパーティーだけを必要とします。 また、結果として起こる業務通話が声を通ると断言するのも便利です、目的地GSTNの中のExecutive SystemがAとBパーティー番号に対する主張が指定したのをチェックできるかもしれなくて、呼び出しを異なって扱うとき。
With the Request-to-Fax and Request-to-Hear-Content services, the source information to be transcoded is held on the Internet. That means either that this information is carried along with the request itself, or that a reference to the source of this information is given.
Requestからファックスとコンテンツサービスを聞くRequestがあるので、移コード化されるべきソース情報はインターネットに保持されます。 それは、この情報が要求自体と共に運ばれるか、またはこの情報の源の参照が与えられていることを意味します。
In addition, it is convenient to assert that the service call will carry fax or voice, and, where possible, to specify the format for the source information.
さらに、そして、業務通話がソース情報に形式を指定するために可能であるところにファックスか声を通ると断言するのは便利です。
The GSTN-based content or "Fax-Back" variant of the Request-to-Fax service needs to specify the Document Store number and the Fax machine number to which the information is to be delivered. It is convenient to assert that the call will carry Fax data, as the destination Executive System may be able to check that assertion against the document store number and that of the destination Fax machine.
RequestからファックスサービスのGSTNベースの内容か「ファックス逆」異形が、提供される情報がことであるDocumentストア番号とファックス機械番号を指定する必要があります。 呼び出しがファックスデータを運ぶと断言するのは便利です、目的地Executive Systemが目的地ファックスマシンのドキュメント店番号とものに対してその主張をチェックできるとき。
In addition, the document number may also need to be sent. This parameter is an opaque reference that is carried through the Internet but has significance only within the GSTN. The document store number and document number together uniquely specify the actual content to be faxed.
また、さらに、公文書番号は、送られる必要があるかもしれません。 このパラメタはインターネットを通して運ばれますが、GSTNだけの中に意味を持っている不明瞭な参照です。 一緒にドキュメント店番号と公文書番号は唯一ファックスで送られる実際の内容を指定します。
6.5.4. Service Parameter Summary
6.5.4. サービスパラメタ概要
The following table summarises the information needed in order to specify fully the intent of a GSTN service request. Note that it excludes any other parameters (such as authentication or authorisation tokens, or Expires: or CallId: headers) that may be used in a request.
以下のテーブルはGSTNサービスのリクエストの意図を完全に指定するのに必要である情報について略言します。 いかなる他のパラメタも除くことに注意してください。(: CallId: ヘッダー) それが使用されるかもしれないaが要求する認証、認可トークン、またはExpiresなどのように。
Service ServiceID AParty BParty CallFmt Source SourceFmt ------- --------- ------ ------ ------- ------ ------- R2C x x x voice - - R2F x - x fax URI/IL ISF/ILSF R2FB x x x fax OR - R2HC x - x voice URI/IL ISF/ILSF
サービスServiceID AParty BParty CallFmtソースSourceFmt------- --------- ------ ------ ------- ------ ------- R2C x x x声--OR--R2HC x----R2F x--xファックスURI/IL ISF/ILSF R2FB x x xファックスx声のURI/IL ISF/ILSF
Petrack & Conroy Standards Track [Page 59] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[59ページ]。
In this table, "x" means that the parameter is required, whilst "-" means that the parameter is not required.
このテーブルでは、「x」は、パラメタが必要であることを意味しますが、「-」は、パラメタが必要でないことを意味します。
The Services listed are Request-to-Call (R2C), Request-to-Fax (R2F), the GSTN-based content or "Fax-back" Variant of Request-to-Fax (R2FB), and Request-to-Hear-Content (R2HC).
記載されたServicesはRequestからファックスへの(R2FB)、および内容を聞くRequest(R2HC)のRequestから呼び出しへの(R2C)、Requestからファックスへの(R2F)、GSTNベースの内容または「ファックス逆」Variantです。
The Call Format parameter values "voice" or "fax" indicate the kind of service call that results.
Call Formatパラメタ値「声」か「ファックス」は結果として生じる業務通話の種類を示します。
The Source Indicator "URI/IL" implies that the information is either an Internet source reference (a Universal Resource Identifier, or URI) or is carried "in-line" with the message. The Source indicator "OR" means that the value passed is an Opaque Reference that should be carried along with the rest of the message but is to be interpreted only within the destination (GSTN) context. As an alternative, it could be given as a "local" reference with the "file" style, or even using a partial reference with the "http" style. However, the way in which such a reference is interpreted is a matter for the receiving PINT Server and Executive System; it remains, in effect, an opaque reference.
Source Indicator「URI/IL」は、情報がインターネットソース参照(普遍的なリソース識別子、またはユリ)であることを含意するか、またはメッセージで「インライン」で運ばれます。 値が終わったという「OR」が意味するSourceインディケータはメッセージの残りと共に運ばれるべきですが、目的地(GSTN)文脈だけの中で解釈されることになっている不明瞭な参照です。 代替手段として、それは、「ファイル」スタイルと共に「地方」の照会先として出されるか、または"http"スタイルと共に部分的な参照を使用してさえいるかもしれません。 しかしながら、そのような参照が解釈される方法は受信PINT ServerとExecutive Systemのための問題です。 それは事実上、不明瞭な参照のままで残っています。
The Source Format value "ISF/ILSF" means that the format of the source is specified either in terms of the URI or that it is carried "in-line". Note that, for some data, the format either can be detected by inspection or, if all else fails, can be assumed from the URI (for example, by assuming that the file extension part of a URL indicates the data type). For an opaque reference, the Source Format is not available on the Internet, and so is not given.
Source Format値の"ISF/ILSF"は、ソースの形式がURIで指定されるか、またはそれが「インライン」で運ばれることを意味します。 いくつかのデータによってそれに注意してください、点検で形式を検出できるか、すべてほかなら、失敗して、URI(例えば1つのURLのファイル拡張子部分がデータ型を示すと仮定することによって)から想定できます。 不明瞭な参照において、Source Formatは、インターネットで利用可能でないので、与えられていません。
6.6. Parameter Mapping to PINT Extensions
6.6. パイント拡大へのパラメタマッピング
This section describes the way in which the parameters needed to specify a GSTN service request fully might be carried within a "PINT extended" message. There are other choices, and these are not precluded. However, in order to ensure that the Requesting User receives the service that they expect, it is necessary to have some shared understanding of the parameters passed and the behaviour expected of the PINT Server and its attendant Executive System.
このセクションはGSTNサービスのリクエストを指定するのに必要であるパラメタが「PINTは広がった」というメッセージの中で完全に運ばれるかもしれない方法を述べます。 他の選択があります、そして、これらは排除されません。 しかしながら、Requesting Userが彼らが予想するサービスを受けるのを確実にするために、パラメタの何らかの共通の理解を通過させて、PINT Serverとその付き添いのExecutive Systemにふるまいを予想させるのが必要です。
The Service Identifier can be sent as the userinfo element of the Request-URI. Thus, the first line of a PINT Invitation would be of the form:
Request-URIのuserinfo要素としてService Identifierを送ることができます。 したがって、PINT Invitationの最初の系列はフォームのものでしょう:
INVITE <serviceID>@<pint-server>.<domain> SIP/2.0
一口/2.0に<serviceID>@<パイントサーバ><ドメイン>を招待してください。
Petrack & Conroy Standards Track [Page 60] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[60ページ]。
The A Party for the Request-to-Call and "Fax-back" variant of Request-to-Fax service can be held in the "To:" header field. In this case the "To:" header value will be different from the Request-URI. In the services where the A party is not specified, the "To:" field is free to repeat the value held in the Request-URI. This is the case for Request-to-Fax and Request-to-Hear-Content services.
「To:」にRequestからファックスサービスのRequestから呼び出しと「ファックス逆」異形のためのAパーティを保持できます。 ヘッダーフィールド。 この場合「To:」 ヘッダー値はRequest-URIと異なるでしょう。 Aパーティーが指定されないサービス、「To:」で 分野は自由にRequest-URIで保持された値を繰り返すことができます。 これはRequestからファックスとコンテンツサービスを聞くRequestのためのそうです。
The B party is needed in all these milestone services, and can be held in the enclosed SDP sub-part, as the value of the "c=" field.
Bパーティーがこれらのすべての重大事件サービスで必要であり、同封のSDPサブ部分で行うことができます、「c=」分野の値として。
The call format parameter can be held as part of the "m=" field value. It maps to the "transport protocol" element as described in section 3.4.2 of this document.
「m=」分野価値の一部として呼び出し形式パラメタを保持できます。 それはこの.2通のセクション3.4ドキュメントで説明されるように「トランスポート・プロトコル」に要素を写像します。
The source format specifier is held in the "m=", as a type and either "-" or sub-type. The latter is normally required for all services except Request-to-Call or "Faxback", where the "-" form may be used. As shown earlier, the source format and source are not always required when generating requests for services. However, the inclusion in all requests of a source format specifier can make parsing the request simpler and allows for other services to be specified in the future, and so values are always given. The source format parameter is covered in section 3.4.2 as the "media type" element.
ソース形式特許説明書の作成書は、「m=」でタイプとどちらかの「-」として保持されるかサブタイプです。 通常、後者が「-」フォームが使用されるかもしれない呼ぶRequestか"Faxback"を除いたすべてのサービスに必要です。 サービスを求める要求を発生させるとき、より早く示されるように、ソース形式とソースがいつも必要であるというわけではありません。 しかしながら、ソース形式特許説明書の作成書のすべての要求での包含が、要求を分析するのをより簡単にすることができて、他のサービスが将来指定されるのを許容するので、いつも値を与えます。 ソース形式パラメタは「メディアタイプ」要素としてセクション3.4.2でカバーされています。
The source itself is identified by an "a=fmtp:" field value, where needed. With the exception of the Request-to-Call service, all invitations will normally include such a field. From the perspective of the SDP extensions, it can be considered as qualifying the media sub-type, as if to say, for example, "when I say jpeg, what I mean is the following".
ソース自体が特定される、「a=fmtp:」 必要であるところで値をさばいてください。 Requestから呼び出しに対するサービスを除いて、通常、すべての招待状がそのような分野を含むでしょう。 SDP拡張子の見解から、メディアサブタイプに資格を与えながら、それをみなすことができます、例えば、「私がjpegを言うとき、私が言っていることは以下です」と言うように。
In summary, the parameters needed by the different services are carried in fields as shown in the following table:
概要では、異なったサービスで必要であるパラメタは以下のテーブルに示されるように分野で運ばれます:
Service Svc Param PINT/SIP or SDP field used Example value
------- --------- -------------------------- -------------
R2C
ServiceID: <SIP Request-URI userinfo> R2C
AParty: <SIP To: field> sip:123@p.com
BParty: <SDP c= field> TN RFC2543 4567
CallFormat: <SDP transport protocol
sub-field of m= field> voice
SourceFmt: <SDP media type sub-field
of m= field> audio
(--- only "-" sub-type
sub-field value used) ---
Source: (--- No source specified) ---
Svc Param PINT/SIPかSDPがさばくサービスはExample値を使用しました。------- --------- -------------------------- ------------- R2C ServiceID: <SIP Request-URI userinfo>R2C AParty: <一口To: 分野>一口: 123@p.com BParty: <SDP cは分野>テネシーRFC2543 4567 CallFormatと等しいです: <SDPはm=分野>声のSourceFmtのプロトコルサブ野原を輸送します: <SDPメディアが分野>m=オーディオのサブ分野をタイプする、(-、--、サブ分野値が使用した「-」サブタイプだけ)--- ソース: (-、--、指定されなかったソース全く) ---
Petrack & Conroy Standards Track [Page 61] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[61ページ]。
R2F
ServiceID: <SIP Request-URI userinfo> R2F
AParty: (--- SIP To: field not used) sip:R2F@pint.xxx.net
BParty: <SDP c= field> TN RFCxxx +441213553
CallFormat: <SDP transport protocol
sub-field of m= field> fax
SourceFmt: <SDP media type sub-field
of m= field> image
<SDP media sub-type sub-field
of m= field> jpeg
Source: <SDP a=fmtp: field qualifying
preceding m= field> a=fmtp:jpeg<uri-ref>
R2F ServiceID: <SIP Request-URI userinfo>R2F AParty: (-、--、使用されないSIP To:分野) 一口: R2F@pint.xxx.net BParty: <SDP cは分野>テネシーRFCxxx+441213553CallFormatと等しいです: <SDPはm=分野>ファックスSourceFmtのプロトコルサブ野原を輸送します: <SDPメディアはm=分野>jpeg Sourceの分野>イメージ<SDPメディアサブm=タイプのサブ分野サブ分野をタイプします: <SDP a=fmtp: m=分野>a=fmtpに先行する分野の資格を得ること: jpeg<uri-審判>。
R2FB
ServiceID: <SIP Request-URI userinfo> R2FB
AParty: <SIP To: field> sip:1-730-1234@p.com
BParty: <SDP c= field> TN RFCxxx +441213553
CallFormat: <SDP transport protocol
sub-field of m= field> fax
SourceFmt: <SDP media type sub-field
of m= field> image
<SDP media sub-type sub-field
of m= field> jpeg
Source: <SDP a=fmtp: field qualifying
preceding m= field> a=fmtp:jpeg opr:1234
R2FB ServiceID: <SIP Request-URI userinfo>R2FB AParty: <一口To: 分野>一口: 1-730-1234@p.com BParty: <SDP cは分野>テネシーRFCxxx+441213553CallFormatと等しいです: <SDPはm=分野>ファックスSourceFmtのプロトコルサブ野原を輸送します: <SDPメディアはm=分野>jpeg Sourceの分野>イメージ<SDPメディアサブm=タイプのサブ分野サブ分野をタイプします: <SDP a=fmtp: m=分野>a=fmtpに先行する分野の資格を得ること: jpeg opr: 1234
R2HC
ServiceID: <SIP Request-URI userinfo> R2HC
AParty: (--- SIP To: field not used) sip:R2HC@pint.ita.il
BParty: <SDP c= field> TN RFCxxx +441213554
CallFormat: <SDP transport protocol
sub-field of m= field> voice
SourceFmt: <SDP media type sub-field
of m= field> text
<SDP media sub-type sub-field
of m= field> html
Source: <SDP a=fmtp: field qualifying
preceding m= field> a=fmtp:html<uri-ref>
R2HC ServiceID: <SIP Request-URI userinfo>R2HC AParty: (-、--、使用されないSIP To:分野) 一口: R2HC@pint.ita.il BParty: <SDP cは分野>テネシーRFCxxx+441213554CallFormatと等しいです: <SDPはm=分野>声のSourceFmtのプロトコルサブ野原を輸送します: <SDPメディアはm=分野>html Sourceの分野>テキスト<SDPメディアサブm=タイプのサブ分野サブ分野をタイプします: <SDP a=fmtp: m=分野>a=fmtpに先行する分野の資格を得ること: html<uri-審判>。
7. References
7. 参照
[1] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[1] ハンドレー、M.、学生、E.、Schulzrinne、H.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[2] Handley, M. and V. Jacobsen, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[2] ハンドレー、M.、およびV.ジェイコブセン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
Petrack & Conroy Standards Track [Page 62] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[62ページ]。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[3]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[4]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[5] The Unicode Consortium, "The Unicode Standard -- Version 2.0",
Addison-Wesley, 1996.
[5] ユニコード共同体、「バージョン2インチ、アディソン・ウエスリー、ユニコード規格--1996。」
[6] ITU-T Study Group 2, "E.164 - The International Public Network
Numbering Plan", ITU-T, June 1997.
[6] ITU-Tはグループを研究します。2 「E.164--国際公衆通信回線付番は計画している」、ITU-T、6月1997
[7] Lu, H., Krishnaswamy, M., Conroy, L., Bellovin, S., Burg, F.,
DeSimone, A., Tewani, K., Davidson, P., Schulzrinne, H. and K.
Vishwanathan "Toward the PSTN/Internet Inter-Networking--Pre-
PINT Implementations", RFC 2458, November 1998.
[7]Lu、H.、Krishnaswamy、M.、コンロイ、L.、Bellovin、S.、町、F.、DeSimone、A.、Tewani、K.、ディヴィッドソン、P.、Schulzrinne、H.、およびK.ウィシュワナタン、「パイントプレPSTN/インターネットインターネットワーキング、実現、」、RFC2458(1998年11月)
[8] ITU-T Study Group XI, "Q.763 - Formats and Codes for the ISDN
User Part of SS No7" ITU-T, August 1994.
[8] ITU-T研究グループξ、「Q.763--ISDNユーザのための形式とコードはSS No7"ITU-Tを離れさせます、1994年8月。」
[9] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
[10] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[10] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[11] ITU-T Study Group XI, "Q.1204 - IN Distributed Functional Plane
Architecture", ITU-T, February 1994.
1994年2月の[11] ITU-T研究グループξ、「分配された機能的な飛行機構造のQ.1204」ITU-T。
[12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[12] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[13] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[13] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[14] Housley, R., Ford, W., Polk W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", RFC
2459, January 1999.
[14]HousleyとR.とフォードとW.とポークW.と一人で生活して、「インターネットX.509公開鍵基盤の証明書とCRLは輪郭を描く」D.、RFC2459、1999年1月。
[15] Crocker, D. and P. Overall, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[15] クロッカー、D.、および全体的に見てP.、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[16] Mills, D., "Network Time Protocol (version 3) specification and
implementation", RFC 1305, March 1992.
[16] 工場(D.)が「Timeプロトコル(バージョン3)仕様と実現をネットワークでつなぐ」、RFC1305、3月1992日
Petrack & Conroy Standards Track [Page 63] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[63ページ]。
[17] Eastlake, D., Crocker, S. and J.Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[17] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[18] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[18]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[19] Levinson, E., "The MIME Multipart/Related Content-type" RFC
2387, August 1998.
[19] レヴィンソン、1998年8月、E.、「MIMEの複合の、または、関連の文書内容」RFC2387。
8. Acknowledgements
8. 承認
The authors wish to thank the members of the PINT working group for comments that were helpful to the preparation of this specification. Ian Elz's comments were extremely useful to our understanding of internal PSTN operations. The SUBSCRIBE and NOTIFY requests were first suggested by Henning Schulzrinne and Jonathan Rosenberg. The suggestion to use an audio port of 0 to express that the phone is "on hold" (i.e. not receiving voice) is due to Ray Zibman. Finally, thanks to Bernie Hoeneisen for his close proofreading.
作者はこの仕様の準備に役立っているコメントについてPINTワーキンググループのメンバーに感謝したがっています。 イアンElzのコメントは非常に私たちの内部のPSTN操作の理解の役に立ちました。 そして、登録、NOTIFY要求は最初に、ヘニングSchulzrinneとジョナサン・ローゼンバーグによって提案されました。 電話が「保持」である(すなわち、声を受けない)と言い表すのに0のオーディオポートを使用する提案はレイZibmanのためです。 最終的に、彼の厳密な校正のためにバーニーHoeneisenをありがとうございます。
Petrack & Conroy Standards Track [Page 64] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[64ページ]。
Appendix A: Collected ABNF for PINT Extensions
付録A: パイント拡大のための集まっているABNF
;; --(ABNF is specified in RFC 2234 [15])
;; --(ABNFはRFC2234[15])で指定されます。
;; --Variations on SDP definitions
;; --SDP定義の変化
connection-field = ["c=" nettype space addrtype space
connection-address CRLF]
; -- this is the original definition from SDP, included for completeness
; -- the following are PINT interpretations and modifications
接続分野は[「c=」nettype宇宙addrtype宇宙接続アドレスCRLF]と等しいです。 -- これは完全性のために含まれていたSDPからのオリジナルの定義です。 -- ↓これは、PINT解釈と変更です。
nettype = ("IN"/"TN")
; -- redefined as a superset of the SDP definition
nettype=(「IN」/「テネシー」)。 -- SDP定義のスーパーセットと再定義されます。
addrtype = (INAddrType / TNAddrType) ; -- redefined as a superset of the SDP definition
addrtypeは(INAddrType / TNAddrType)と等しいです。 -- SDP定義のスーパーセットと再定義されます。
INAddrType = ("IP4"/"IP6")
; -- this non-terminal added to hold original SDP address types
INAddrTypeが等しい、(「IP4"/、「IP6")、;、」 -- オリジナルのSDPアドレスを保持するために加えられたこの非端末はタイプされます。
TNAddrType = ("RFC2543"/OtherAddrType)
TNAddrType=("RFC2543"/OtherAddrType)
OtherAddrType = (<X-Token>) ; -- X-token is as defined in RFC2045
OtherAddrTypeは(<X-象徴>)と等しいです。 -- X-象徴がRFC2045で定義されるようにあります。
addr = (<FQDN> / <unicast-address> / TNAddr) ; -- redefined as a superset of the original SDP definition ; -- FQDN and unicast address as specified in SDP
addr=(<FQDN<ユニキャスト>/アドレス>/TNAddr)。 -- オリジナルのSDP定義のスーパーセットと再定義されます。 -- SDPの指定されるとしてのFQDNとユニキャストアドレス
TNAddr = (RFC2543Addr/OtherAddr) ; -- TNAddr defined only in context of nettype == "TN"
TNAddrは(RFC2543Addr/OtherAddr)と等しいです。 -- 状況内においてnettypeだけについて定義されたTNAddr=「テネシー」
RFC2543Addr = (INPAddr/LDPAddr)
RFC2543Addr=(INPAddr/LDPAddr)
INPAddr = "+" <POS-DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
; -- POS-DIGIT and DIGIT as defined in SDP
INPAddrは「+」 <POSケタ>0*((「-」<ケタ>)/<ケタ>)と等しいです。 -- SDPで定義されるPOS-DIGITとDIGIT
LDPAddr = <DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
LDPAddrは<ケタ>0*と等しいです。((「-」<ケタ>)/<ケタ>)
OtherAddr = 1*<uric> ; -- OtherAdd defined in the context of OtherAddrType ; -- uric is as defined in RFC2396
OtherAddrは1*<の尿の>と等しいです。 -- OtherAddrTypeの文脈で定義されたOtherAdd。 -- 尿、RFC2396で定義されるように、あります。
media-field = "m=" media <space> port <space> proto
1*(<space> fmt) <CRLF>
; -- NOTE redefined as subset/relaxation of original SDP definition
; -- space and CRLF as defined in SDP
メディア分野=「m=」メディア<スペース>は<スペース>proto1*(<スペース>fmt)<CRLF>を移植します。 -- オリジナルのSDP定義の部分集合/緩和と再定義された注意。 -- SDPで定義されるスペースとCRLF
Petrack & Conroy Standards Track [Page 65] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[65ページ]。
media = ("application"/"audio"/"image"/"text")
; -- NOTE redefined as a subset of the original SDP definition
; -- This could be any MIME discrete type; Only those listed are
; -- used in PINT 1.0
メディアは(「アプリケーション」/「オーディオ」/「イメージ」/「テキスト」)と等しいです。 -- オリジナルのSDP定義の部分集合と再定義された注意。 -- これはどんなMIMEの離散的なタイプであるかもしれませんも。 記載された唯一のものはそうです。 -- PINT1.0では、使用されます。
port = ("0" / "1")
; -- NOTE redefined from the original SDP definition;
; -- 0 retains usual sdp meaning of "temporarily no media"
; -- (i.e. "line is on hold")
; -- (1 means there is media)
=を移植してください、(「0インチ/、「1インチ)、;、」 -- オリジナルのSDP定義から再定義された注意。 ; -- 0が普通のsdp意味を保有する、「一時的である、メディアがない、」、。 -- (すなわち、「線は保留しています」) ; -- (そこの1つの手段がメディアです)
proto = (INProto/TNProto) ; -- redefined as a superset of the original SDP definition
protoは(INProto/TNProto)と等しいです。 -- オリジナルのSDP定義のスーパーセットと再定義されます。
INProto = 1* (<alpha-numeric>)
; -- this is the "classic" SDP protocol, defined if nettype == "IN"
; -- alpha-numeric is as defined in SDP
TNProto = ("voice"/"fax"/"pager")
; -- this is the PINT protocol, defined if nettype == "TN"
INProto=1*(<アルファベット数字式>)。 -- これはnettypeであるなら定義された「古典的な」SDPプロトコル=「IN」です。 -- アルファベット数字式がSDP TNProto=(「声」/「ファックス」/「ポケットベル」)で定義されるようにあります。 -- これはnettype=「テネシー」であるなら定義されたPINTプロトコルです。
fmt = (<subtype> / "-") ; -- NOTE redefined as a subset of the original SDP definition ; -- subtype as defined in RFC2046, or "-". MUST be a subtype of type held ; -- in associated media sub-field or the special value "-".
fmtは(<「副-タイプ」>/「-」)と等しいです。 -- オリジナルのSDP定義の部分集合と再定義された注意。 -- RFC2046で定義される「副-タイプ」、または「-。」 保持されたタイプの「副-タイプ」でなければなりません。 -- 関連メディアサブ分野か特別番組では、「-」を評価してください。
attribute-fields = *("a=" attribute-list <CRLF>)
; -- redefined as a superset of the definition given in SDP
; -- CRLF is as defined in SDP
属性分野は*(「=」属性リスト<CRLF>)と等しいです。 -- SDPで与えられた定義のスーパーセットと再定義されます。 -- CRLFがSDPで定義されるようにあります。
attribute-list = 1(PINT-attribute / <attribute>) ; -- attribute is as defined in SDP
属性リスト=1(PINT-属性/<属性>)。 -- 属性がSDPで定義されるようにあります。
PINT-attribute = (clir-attribute / q763-nature-attribute /
q763plan-attribute / q763-INN-attribute /
phone-context-attribute / tsp-attribute /
pint-fmtp-attribute / strict-attribute)
パイント属性=(厳しいパイントfmtpティースプーンフル電話文脈q763-INN q763plan q763自然clir-属性/属性/属性/属性/属性/属性/属性/属性)
clir-attribute = clir-tag ":" ("true" / "false")
「clir-属性=clir-タグ」:、」 (「本当である」か「誤っている」)です。
clir-tag = "clir"
clir-タグ="clir"
q763-nature-attribute = Q763-nature-tag ":" q763-natures
「q763自然属性=Q763自然タグ」:、」 q763-自然
q763-nature-tag = "Q763-nature"
q763自然タグ=「Q763-自然」
q763-natures = ("1" / "2" / "3" / "4")
q763-自然=("1" / "2" / "3" / "4")
Petrack & Conroy Standards Track [Page 66] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[66ページ]。
q763-plan-attribute = Q763-plan-tag ":" q763-plans
「q763プラン属性=Q763プランタグ」:、」 q763-プラン
q763-plan-tag = "Q763-plan"
q763プランタグ=「Q763-プラン」
q763-plans = ("1" / "2" / "3" / "4" / "5" / "6" / "7")
; -- of these, the meanings of 1, 3, and 4 are defined in the text
q763-プランが等しい、(「1インチ/、「2インチ/、「3インチ/、「4インチ/、「5インチ/、「6インチ/、「7インチ)」、。 -- これらでは、1の意味であり、3、および4はテキストで定義されます。
q763-INN-attribute = Q763-INN-tag ":" q763-INNs
「q763旅館属性=Q763旅館タグ」:、」 q763-旅館
q763-INN-tag = "Q763-INN"
q763旅館タグ=「Q763-旅館」
q763-INNs = ("0" / "1")
q763-旅館=("0" / "1")
phone-context-attribute = phone-context-tag ":" phone-context-ident
「電話文脈属性=電話文脈タグ」:、」 文脈identに電話をしてください。
phone-context-tag = "phone-context"
電話文脈タグ=「電話文脈」
phone-context-ident = network-prefix / private-prefix
電話文脈identの個人的な=ネットワーク接頭語/接頭語
network-prefix = intl-network-prefix / local-network-prefix
ローカルのネットワークネットワーク接頭語=intlネットワーク接頭語/接頭語
intl-network-prefix = "+" 1*<DIGIT>
intlネットワーク接頭語=「+」 1*<ケタ>。
local-network-prefix = 1*<DIGIT>
ローカルのネットワーク接頭語=1*<DIGIT>。
private-prefix = 1*excldigandplus 0*<uric>
個人的な接頭語=1*excldigandplus0*<尿の>。
excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d)) tsp-attribute = tsp-tag "=" provider-domainname
excldigandplusはティースプーンフル属性=ティースプーンフルタグ「=」プロバイダードメイン名と等しいです(0×21 0x2d、0x2f、0×40 0x7d)。
tsp-tag = "tsp"
ティースプーンフルタグ=「ティースプーンフル」
provider-domainname = <domain> ; -- domain is defined in RFC1035
プロバイダードメイン名は<ドメイン>と等しいです。 -- ドメインはRFC1035で定義されます。
; -- NOTE the following is redefined relative to the normal use in SDP
pint-fmtp-attribute = "fmtp:" <subtype> <space> resolution
*(<space> resolution)
(<space> ";" 1(<attribute>) *(<space>
<attribute>))
; -- subtype as defined in RFC2046.
; -- NOTE that this value MUST match a fmt on the ultimately preceeding
; -- media-field
; -- attribute is as defined in SDP
; -- 注意、以下によるSDPにおける通常の使用に比例して再定義されて、パイントfmtp属性=が「以下をfmtpする」ということです。 「<「副-タイプ」><宇宙>解決*(<宇宙>解決)、(<スペース>、」 ; 」 1 (<属性>) *(<スペース><属性>)。 -- RFC2046で定義される「副-タイプ」。 ; -- これが結局preceedingしているときのfmtを合わせなければならないのを評価する注意。 -- メディア分野。 -- 属性がSDPで定義されるようにあります。
resolution = (uri-ref / opaque-ref / sub-part-ref)
解決=(サブ部分の分っているuri-審判/審判/審判)
uri-ref = uri-tag ":" <URI-Reference>
「uri-審判=uri-タグ」:、」 <URI参照>。
Petrack & Conroy Standards Track [Page 67] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[67ページ]。
; -- URI-Reference defined in RFC2396
; -- RFC2396で定義されたURI参照
uritag = "uri"
uritagは"uri"と等しいです。
opaque-ref = opr-tag ":" 0*<uric>
「分っている審判=opr-タグ」:、」 0*<の尿の>。
opr-tag = "opr"
opr-タグ="opr"
sub-part-ref = spr-tag ":" <Content-ID> ; -- Content-ID is as defined in RFC2046 and RFC822
「サブ部分の審判=spr-タグ」:、」 <コンテントID>。 -- コンテントIDがRFC2046とRFC822で定義されるようにあります。
spr-tag = "spr"
spr-タグ="spr"
strict-attribute = "require:" att-tag-list
厳しい属性=「以下を必要としてください」 attタグリスト
att-tag-list = 1(PINT-att-tag-list / <att-field> /
pint-fmtp-tag-list)
*(","
(PINT-att-tag-list / <att-field> /
pint-fmtp-tag-list)
)
; -- att-field as defined in SDP
attタグリスト=1(<att PINT-attタグリスト/分野パイントfmtpタグ>/リスト)*、(「」、(<attパイントattタグリスト/分野パイントfmtpタグ>/リスト)。 -- SDPで定義されるatt-分野
PINT-att-tag-list = (phone-context-tag / clir-tag /
q763-nature-tag / q763-plan-tag /
q763-INN-tag)
パイントattタグリスト=(q763-INN q763プランq763自然clir電話文脈タグ/タグ/タグ/タグ/タグ)
pint-fmtp-tag-list = (uri-tag / opr-tag / spr-tag)
パイントfmtpタグリスト=(spr opr uri-タグ/タグ/タグ)
;; --Variations on SIP definitions
;; --SIP定義の変化
clir-parameter = clir-tag "=" ("true" / "false")
clir-パラメタはclir-タグ「=」と等しいです。(「本当である」か「誤っている」)です。
q763-nature-parameter = Q763-nature-tag "=" Q763-natures
q763自然パラメタ=Q763自然タグ「=」Q763-自然
q763plan-parameter = Q763-plan-tag "=" q763plans
q763plan-パラメタ=Q763プランタグ「=」q763plans
q763-INN-parameter = Q763-INN-tag "=" q763-INNs
q763旅館パラメタ=Q763旅館タグ「=」q763-旅館
tsp-parameter = tsp-tag "=" provider-domainname
ティースプーンフルパラメタ=ティースプーンフルタグ「=」プロバイダードメイン名
phone-context-parameter = phone-context-tag "=" phone-context-ident
電話文脈パラメタ=電話文脈タグ「=」電話文脈ident
SIP-param = ( <transport-param> / <user-param> / <method-param> /
<ttl-param> / <maddr-param> / <other-param> )
; -- the values in this list are all as defined in SIP
一口param=(param>/<ユーザ-paramを輸送している<<方法>/param>/<ttl-param>/<maddr-param>/<の他のparamの>)。 -- このリストの値はSIPで定義されるようにすべてです。
PINT-param = ( clir-parameter / q763-nature-parameter /
PINT-paramが等しい、(q763自然clirパラメタ/パラメタ/
Petrack & Conroy Standards Track [Page 68] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[68ページ]。
q763plan-parameter / q763-INN-parameter/
tsp-parameter / phone-context-parameter )
電話文脈ティースプーンフルq763-INN q763plan-パラメタ/パラメタ/パラメタ/パラメタ)
URL-parameter = (SIP-param / PINT-param) ; -- redefined SIP's URL-parameter to include ones defined in PINT
URLパラメタは(パイント一口param/param)と等しいです。 -- PINTで定義されたものを含む再定義されたSIPのURLパラメタ
Require-header = "require:" 1(required-extensions)
*("," required-extensions)
; -- NOTE this is redefined as a subset of the SIP definition
; -- (from RFC2543/section 6.30)
=がヘッダーが必要な「以下を必要とします」。 1(必要な拡大)*、(「」、必要な拡大)、。 -- 注意、これはSIP定義の部分集合と再定義されます。 -- (RFC2543/セクション6.30からの)
required-extensions = ("org.ietf.sip.subscribe" /
"org.ietf.sdp.require")
必要な拡大=("org.ietf.sip.subscribe"/"org.ietf.sdp.require")
Appendix B: IANA Considerations
付録B: IANA問題
There are three kinds of identifier used in PINT extensions that SHOULD be registered with IANA, if a new value is specified. These are:
IANAに示されたPINT拡張子に使用されるSHOULDがある識別子の3種類があります、新しい値が指定されるなら。 これらは以下の通りです。
* Media Format sub-types, as described in section 3.4.2 of this
document.
* Private Attributes as mentioned in section 3.4.3
* Private Phone Context values, as described in section 3.4.3.1.
* この.2通のセクション3.4ドキュメントの説明されるとしてのサブタイプのメディアFormat。 * セクション3.4.3で.1に説明されるようにセクション3.4.3の*個人的な電話Context値で言及する個人的なAttributes
It should be noted that private Address Types (in section 3.4.1) have been explicitly excluded from this process, as they must be in the form of an X-Token.
個人的なAddress Types(セクション3.4.1における)がこの過程から明らかに除かれたことに注意されるべきです、彼らがX-象徴の形にあるに違いないとき。
B.1. Media Format Sub-types
B.1。 メディアはサブタイプをフォーマットします。
Taking these in turn, the media format sub-types are used within the PINT extensions to SDP to specify the attribute line that holds the data source definitions. In normal use, the values in this field are sub-types of MIME discrete types[4]. If a value other than an IANA- registered sub-type is to be used, then it should either be an X- Token (i.e. start with "X-") or it should be registered with IANA. if the intention is to describe a new MIME sub-type, then the procedures specified in RFC 2048 should be used. It is ASSUMED that any new MIME sub-type would follow the syntactic rules for interpretation of associated PINT fmtp lines defined in this document.
順番に、メディアがフォーマットするこれらを取って、サブタイプは、データ送信端末定義を保持する属性線を指定するためにPINT拡張子の中でSDPに慣れています。 通常の使用で、この分野の値はMIMEの離散的なタイプ[4]のサブタイプです。 IANAの登録されたサブタイプ以外の値が使用されていることであるなら、それはX象徴であるべきです(すなわち、「X」から始める)かそれがIANAに登録されるべきです。意志が新しいMIMEサブタイプについて説明することであるなら、RFC2048で指定された手順は用いられるべきです。 どんな新しいMIMEサブタイプも本書では定義された関連PINT fmtp線の解釈のための構文の規則に従うのは、ASSUMEDです。
Note that, in keeping with the SDP description, such registrations SHOULD include the "proto" field values within which they are defined; however, it is appropriate to specify only that they can be used with "all values of TNProto".
そのような登録証明書SHOULDがSDP記述で保つ際にそれらが定義される"proto"分野値を含んでいることに注意してください。 しかしながら、「TNProtoのすべての値」と共にそれらを使用できるだけであると指定するのは適切です。
Petrack & Conroy Standards Track [Page 69] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[69ページ]。
Conversely, if the intent is to define a new way of including data source definitions within PINT, then it will be necessary to specify, in the documentation supporting any such new "PINT Media Format Sub- type" registration, the syntax of the associated "fmtp" attribute line, as the identifier serves to indicate the interpretation that should be made of format specific attribute lines "tagged" with such a sub-type.
逆に、指定するのが意図がPINTの中にデータ送信端末定義を含む新しい方法を定義することであるなら必要でしょう、そのようなどんな「メディアFormat SubがタイプするPINT」新しい登録も支持するドキュメンテーションで、関連"fmtp"属性線の構文、識別子が、そのようなサブタイプで特定の属性線が「タグ付けをした」形式でされるべきである解釈を示すのに役立つとき。
If the fmtp interpretation follows the PINT default, then it is adequate to mention this in the defining document rather than repeating the syntax definition given here (although, in this case, it is unclear why such a new registration would be required). As before, the Media Format sub-type SHOULD specify the values of "proto" field within which it is defined, but this can be "all values of TNProto".
fmtp解釈がPINTデフォルトに従うなら、ここに与えられた構文定義を繰り返すより定義文書でむしろこれについて言及するのは適切です(そのような新規登録がなぜ必要であるかが、この場合不明瞭ですが)。 従来と同様、メディアFormatサブタイプSHOULDはそれが定義される"proto"分野の値を指定しますが、これは「TNProtoのすべての値」であることができます。
B.2. Private Attributes
B.2。 個人的な属性
Any proprietary attribute lines that are added may be registered with IANA using the procedures mentioned in [2]; the mechanism is the same as that used in SDP. If the attribute is defined for use only within PINT, then it may be appropriate to mention this in the supporting documentation. Note that, in the PINT 1.0 specification covered here, there is no mechanism to add such freshly registered attribute lines to a "require:" clause.
加えられるどんな独占属性線も[2]で言及された手順を用いるIANAに示されるかもしれません。 メカニズムはSDPで使用されるそれと同じです。 属性がPINTだけの中の使用のために定義されるなら、解説文書でこれについて言及するのは適切であるかもしれません。 そのような新たに登録された属性線を「以下を必要としてください」に加えるためにここにカバーされたPINT1.0仕様にはメカニズムが全くないことに注意してください。 節。
B.3. Private phone-contexts
B.3。 個人的な電話関係
Within the session description used for PINT requests, a phone- context attribute may be used to specify the prefix or context within which an associated telephone-number (in a connection line) should be interpreted.
PINT要求に使用されるセッション記述の中では、電話文脈属性は、関連電話番号(接続線における)が解釈されるべきである接頭語か文脈を指定するのに使用されるかもしれません。
For "public" phone contexts the prefix to be used MUST start with either a DIGIT or a "+". Private phone contexts may be registered with IANA that do NOT start with either of these characters. Such a prefix may be useful to identify a private network, potentially with an associated numeric ID (see example 4 in section 3.4.3.1). In the example, the prefix acts as the context for X-acme.com's private network numbering plan.
「公共」の電話文脈に関しては、使用されるべき接頭語はDIGITか「+」のどちらかから始まらなければなりません。 個人的な電話関係はこれらのどちらのキャラクタからも始めないIANAに示されるかもしれません。 セクション3.4の例4を見てください。そのような接頭語が関連数値IDと共に私設のネットワークを潜在的に特定するために役に立つかもしれない、(.3 .1)。 例では、接頭語はX-acme.comの個人的なネットワーク付番プランのための文脈として機能します。
It is recommended that any private context to be registered have the general form of a token including a domain name, optionally followed by a digit string or other token. The appropriate form of the initial token name space will be similar to that used for private or vendor registrations for sub-types (e.g. vnd.acme.com). However, note that the registration will be used to specify a customer's private network numbering plan format rather than being used generally for all of
どんな登録されるべき個人的な関係にもケタストリングか他の象徴が任意に支えたドメイン名を含む象徴の一般的なフォームがあるのは、お勧めです。 スペースという初期の象徴名の適切なフォームはサブタイプ(例えば、vnd.acme.com)に個人的であるか業者登録証明書に使用されるそれと同様になるでしょう。 しかしながら、登録が一般に、すべてに、中古の存在よりむしろ顧客の個人的なネットワーク付番プラン形式を指定するのにおいて使用することに注意してください。
Petrack & Conroy Standards Track [Page 70] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[70ページ]。
their equipment vendor's customer's; thus, fbi.gov would be appropriate, but lucent.com would not (unless the private network were to be that used by Lucent internally).
彼らの設備業者の顧客のもの。 したがって、fbi.govは適切でしょうが、lucent.comは適切でないでしょう(私設のネットワークによるLucentによって内部的に使用されたというわけではないそれであることになっていたなら)。
In addition, the supporting documentation MUST either declare that there is no associated token, or define the syntax by which that token can be parsed (e.g. vnd.fbi.gov <space> 1*DIGIT). Note that the registration describes a format, not a value range; it is sufficient that the private context can be parsed, without the value being interpreted.
さらに、解説文書は、どんな関連象徴もないと宣言しなければならないか、またはその象徴を分析できる構文(例えば、vnd.fbi.gov<スペース>1*DIGIT)を定義しなければなりません。 登録が値の範囲ではなく、形式について説明することに注意してください。 解釈される値なしで個人的な関係を分析できるのは十分です。
In detail, the registration request SHOULD include:
詳細に、登録要求SHOULDは:
* Kind of registration (i.e. private phone-context attribute to be
used within the service description of PINT service requests)
* Contact details for the person responsible for the registration
request (name, organisation, e-mail address, public telephone
number)
* Private Prefix initial token name (e.g. vnd.fbi.gov)
* syntax for private context (e.g. "vnd.fbi.gov" <space> 1*DIGIT, or
"vnd.gtn.gov.uk")
* Description of use (e.g. "This phone context declares an
associated telephone number to be within the 'government
telecommunications network'; the number is in an internal or
private number plan form)
* Network Type and Address Type with which this private context is
associated; If the "normal" telephone types (as specified in this
document) are used, then the values would be shown as:
"nettype=TN" , addrtype="RFC2543Addr". If, however, this context
were to be used with another address type, then a reference to
that address type name and the syntax of that address value would
be required.
* ちょっと個人的な関係において、登録要求(名前、機構、Eメールアドレス、公衆は数に電話をする)*個人的なPrefix初期の象徴名(例えば、vnd.fbi.gov)*構文に責任がある人への登録(すなわち、PINTサービスのリクエストのサービス記述の中で使用されるべき個人的な電話文脈属性)*詳細な連絡先; (例えば、「」 <が"vnd.gtn.gov.uk") >1*DIGIT、または*記述を区切るvnd.fbi.govはこの個人的な関係が関連している*ネットワークTypeとAddress Typeを使用(例えば、「この電話文脈は、'政府テレコミュニケーションネットワークの中に関連電話番号があると宣言する'; 数が内部的、または、個人的な数のプランフォームにあります)」。 「正常な」電話タイプ(本書では指定されるように)が使用されているなら、値は以下として示されるでしょう。 「nettype=テネシー」、addrtypeは"RFC2543Addr"と等しいです。 この文脈がしかしながら、別のアドレスタイプで使用されることであるなら、そのアドレス型名の参照とそのアドレス値の構文が必要です。
In short, this context is the telephone equivalent of a "Net 10" address space behind a NAT, and the initial name (and contact information) shows the context within which that address is valid. It also specifies the format for the network and address types (and address value syntax) with which this context is associated.
要するに、この文脈は「名前(そして、問い合わせ先)がそのアドレスが有効である文脈を示しているNAT、および初期の後ろの10インチのネットのアドレス空間」の電話同等物です。 また、それはこの文脈が関連しているネットワークとアドレスタイプ(値の構文を記述する)に形式を指定します。
Of course, IANA may refer the requested registration to the IESG or an appropriate IETF working group for review, and may require revisions to be made before the registration is accepted.
もちろん、IANAはレビューについてIESGか適切なIETFワーキンググループに要求された登録を任せて、登録を受け入れる前に改正をするのを必要とするかもしれません。
Petrack & Conroy Standards Track [Page 71] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[71ページ]。
Authors' Addresses
作者のアドレス
Scott Petrack MetaTel, Inc. 45 Rumford Ave. Waltham MA 02453-3844
スコットPetrack MetaTel Inc.45ラムフォードAve。 ウォルサムMA02453-3844
Phone: +1 (781)-891-9000 EMail: scott.petrack@metatel.com
以下に電話をしてください。 +1 (781)891-9000メール: scott.petrack@metatel.com
Lawrence Conroy Siemens Roke Manor Research Roke Manor Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN
ローレンスコンロイジーメンスRoke荘園研究のRokeの荘園の古いLaneロムジー、ソールズベリーハンプシャーイギリスのSO51 0ZN
Phone: +44 (1794) 833666 EMail: lwc@roke.co.uk
以下に電話をしてください。 +44(1794) 833666 メール: lwc@roke.co.uk
Petrack & Conroy Standards Track [Page 72] RFC 2848 The PINT Service Protocol June 2000
PetrackとコンロイStandardsはパイントサービスプロトコル2000年6月にRFC2848を追跡します[72ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Petrack & Conroy Standards Track [Page 73]
Petrackとコンロイ標準化過程[73ページ]
一覧
スポンサーリンク
