Network Working Group S. Petrack
Request for Comments: 2848 MetaTel
Category: Standards Track L. Conroy
Siemens Roke Manor Research
June 2000
The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services
パイントサービスプロトコル：電話コールサービスへのIPアクセスのためのSIPとSDPへの拡張
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書では、IPネットワークから特定の電話サービスを呼び出すためのプロトコルを定義しPINTサービスプロトコル1.0の仕様が含まれています。これらのサービスは、基本的な電話をかけるファクスの送受信、電話を介してコンテンツを受信することを含みます。プロトコルはSIP 2.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
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
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
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.
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 /インターネットインターワーキング（PINT）サービスは、」IPクライアントからのリクエストの送信や電話自体を含めて始まる、そのような完全なトランザクションを表すために使用します。 PINTサービスは、彼らは常に2つの別々のネットワークを伴うという事実によって区別されています。
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.
コールの配置を要求するIPネットワーク、およびグローバルは実際の呼び出しを実行するために電話網（GSTN）を交換しました。インテリジェントネットワークシステム、民間のPBX、携帯電話網、ISDNとは、すべてのPINTサービスを提供するために使用できることが理解されます。また、サービスの要求は、全体のインターネットから切断されたプライベートIPネットワーク内から来るかもしれません。
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プロトコルはPINTクライアントとサーバになるためにSIPクライアントおよびサーバを有効にするには、いくつかの拡張機能と拡張機能を提供し、一緒にこれらの2つのプロトコルを使用しています。
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記述が含まれています。これは、例えば、または「通話セッション」「ファックス・セッションを送信する」かもしれません。 SIPセッションでメディアが正常にインターネット上で搬送しながらPINTサービス実行セッションではメディアは、電話システムの上に輸送されます。
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にFAXを送信することに同意した場合、それがファックスの一部が送信された後、FAX送信が失敗している可能性があります。したがって、PINTクライアントは、確立されたPINTセッションの結果として呼び出された実際の通話セッションの状態に関する情報を受信することを望むかもしれません。三つの新しい要求、UNSUBSCRIBEをSUBSCRIBEと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サービスを拡張することです。別に既存のプロトコルとアーキテクチャ、および再利用の利点にうまく統合するから、これは、ここで指定されたプロトコルは、ちょうどマイルストーンサービスよりも通話サービスのではなく、より広いクラスを扱うことができることを意味します。
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のマイルストーンサービスについて説明します。セクション3はPINT機能とプロトコルアーキテクチャを指定します。セクション4は、SIPとSDPのPINT 1.0拡張の例を与えます。セクション5は、PINTのためのいくつかのセキュリティ上の考慮事項が含まれています。最後のセクションはPINTプロトコルがGSTNを介してサービスを提供するために使用することができる方法を記述しています。
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の拡張を説明します。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますまたRFC 2119に記載されるように解釈されるべきで、構築物は、「MUST .... OR ....」が（ドットによって表さ記載二つの可能性のいずれかを実施するために、本明細書の絶対的な要件であることを意味上記フレーズ）。実装は、二つの可能性のいずれかを選択する別の実装と相互運用できなければなりません。
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サービス - PINTクライアントから受け取った要求に応答して、電話システム内で呼び出されたサービス。
PINT Client - An Internet host that sends requests for invocation of a PINT Service, in accordance with this document.
PINTクライアント - この文書に従って、PINTサービスの呼び出しにリクエストを送信し、インターネットホスト。
PINT Gateway - An Internet host that accepts requests for PINT Service and dispatches them onwards towards a telephone network.
PINTゲートウェイ - PINTサービスの要求を受け付け、電話網に向けて以降ディスパッチインターネットホスト。
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.
エグゼクティブシステム - PINTサーバへと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.
サービスの要求のイニシエータ - ユーザーの要求。この役割は、要求から生じる任意の電話網コールに「当事者」のものとは異なるかもしれません。
(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).
（サービスコール）パーティー - PINTサービス要求の実行から得られる電話ネットワーク呼び出しに関与している人、または（例えば自動ファックス送信者またはテキストツーとして関与している電話ネットワークベースのリソーススピーチ単位）。
The original motivation for defining this protocol was the desire to invoke the following three telephone network services from within an IP network:
このプロトコルを定義するためのオリジナルの動機は、IPネットワーク内から次の三つの電話ネットワークサービスを呼び出すための願望でした。
A request is sent from an IP host that causes a phone call to be made, connecting party A to some remote party B.
要求は、一部のリモートパーティBにパーティAを接続し、作られている電話の原因となるIPホストから送信されます
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.
要求は、要求がFAXデータへのポインタ（すなわちIPネットワークまたは電話網に存在する可能性）を含むことができるマシンBをファックスに送信するファックスを引き起こすIPホスト、またはファックスデータ自体から送信されます。ファックスの内容は、テキストや他の多くの一般的な画像データであってもよいです。 FAX送信の詳細は、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トランザクションに対して完全に透過的です。
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ホストから送信されます。リクエストは、コンテンツを指すURLが含まれている、またはコンテンツ自体を含める必要があります。内容は、テキストや他の多くの一般的なアプリケーションデータであってもよいです。コンテンツ伝送の詳細は、IPネットワークにアクセスすることはできませんが、電話網内に完全に残っています。このサービスは、同じように、「要求コンテンツ聞くために」と呼ぶことができ、ユーザーの目標は、彼らに話されたコンテンツを聞くことです。要求が処方されるメカニズムは、この文書の範囲外です。しかし、例では、Webページを人に話されて押されたときは、ページのコンテンツ（または他の詳細）で得られた、PSTNに渡されるPINT要求を引き起こすことボタンを有していることかもしれません。
2.4 Relation between PINT milestone services and traditional telephone services
PINTのマイルストーンサービスと従来の電話サービスとの間に2.4の関係
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要求ツーコールサービスを介して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 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要求内で発現されるの電話網セッションの特定の高レベルの詳細を排除するものではありません。例えば、リクエスト・ツー・聞く・コンテンツサービスのための言語設定を表現するためにSDP「LANG」属性を使用することが可能です。特定のPINTシステムは、要求が電話ネットワーク側のサービスの詳細を含むことができるようにしたい場合は、SDP属性メカニズム（セクション3.4.2を参照）を使用します。
Familiarity is assumed with SIP 2.0 [1] and with SDP [2].
親密[2] [1]とSDPとSIP 2.0と仮定されます。
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ゲートウェイは、ユーザエージェントサーバとしてSIPシステムに表示されます。それは、「ユーザー」を表しているかのように、実際にそれが本当に電話ネットワークサービスのセットを提供することができ、全体の電話ネットワークインフラストラクチャを表しながらPINTゲートウェイは、PINTインフラストラクチャに表示されていることに注意してください。
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 /
\ \ / \
/\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/
Figure 1: PINT Functional Architecture
図1：PINT機能アーキテクチャ
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要求が最終的に実際にそれを渡すことによって、要求を処理することができ、正しい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.以内（インテリジェントネットワーク）システム、PINTゲートウェイは、サービス制御ゲートウェイ機能を実現するために表示される場合があります。オフィス環境では、オフィスのLANやオフィスのPBXの両方に接続されているオフィスのPBXへのサーバーの補助、かもしれません。
The Executive System that lies beyond the PINT gateway is outside the scope of PINT.
PINTゲートウェイ向こうにあるエグゼクティブ・システムは、PINTの範囲外です。
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:
以下のリストは、PINT 1.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）SIP / SDPテレフォニーURLの改良では電話のURL *電話サービスプロバイダー（TSP）および/または電話コンテキストURLパラメータ4）データがセッションメディアなどのオブジェクトの3）仕様プライベートダイヤルプランを含めます
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）プロトコルトランスポートフォーマットはGSTN内のメディアの処理を示すために5）インラインマルチパート/ MIME 7）精密化/不透明引数の明確化を使用してデータオブジェクトがエグゼクティブ・システムに以降渡さ6）暗黙的（間接的）メディアストリームと不透明引数* Q.763引数のプレゼンテーション規制指示*フレームワークのためのフレームワーク狭窄を指定して、受信者がヘッダを「必要」を使用して、指定した拡張子をサポートしていないときに障害を強制的にSDPのため8）拡張メカニズム。 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]の機能に依存しています。 SIP 2.0の使用は、PINT 1.0によって暗示され、これはまた、MIMEのバージョン1.0に準拠することを意味します。
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で発生することを希望する特定の電話網セッションの記述を含みます。この情報は、電話網のアドレスの呼び出しに関与端子（S）の（つまり、「電話番号」）、輸送されるメディアタイプの表示（例えば、音声、テキスト、画像、またはアプリケーションデータ）のようなものが含まれ、情報は、音声、ファックス、またはポケットベル輸送を介して電話網を介して転送される場合と表示。遠隔電話端末に送信するコンテンツの表示（任意がある場合）も含まれます。
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は、独立して、これらのパラメータを伝えるのに十分な柔軟性があります。例えば、音声トランスポートを経由して、いくつかのテキストを送信するための要求は、いくつかのテキストを音声に変換するオーバー電話サービスを呼び出すことによって成就され、ファックスでテキストを送信するための要求は、いくつかのテキスト・ツー・ファックスを呼び出すことによって実現されますサービス。
The following is a list of PINT 1.0 enhancements and additions to SDP.
以下は、SDPにPINT 1.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。新しいネットワーク型の「TN」とアドレスタイプ「RFC2543」と「X -...」（セクション3.4.1）、B。新しいメディアタイプ「テキスト」、「イメージ」、および「アプリケーション」、新しいプロトコル輸送キーワード「声」、「ファックス」と「ポケットベル」と関連したフォーマットの種類や属性タグ（セクション3.4.2）
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）電子に情報を渡すために使用されます。新しい属性タグは、いくつかの属性は、サーバー（3.4.4）でサポートする必要があることを示すために、クライアントによって使用される、「必要」
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：「警告」のために必須のサポート。 SUBSCRIBEとNOTIFY、およびUNSUBSCRIBE要求（セクション3.5.3）は、i。必要：ヘッダ（セクション3.5.4）jは。 PINT要求（セクション3.5.5）K内PINT URLのフォーマット。 PINTの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の拡張ではありません。電話網のセッションで使用した場合にのみ意味論の明確化のためにここに含まれています。
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.
これらのうち、唯一の（それに関連するRFC2543アドレスタイプを持つ）TNネットワークタイプと「必要」属性がPINT 1.0クライアントとサーバでサポートしなければなりません。実際には、ほとんどのPINTサービス要求は、要求内のデータオブジェクトへの参照が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の構築物のそれぞれは、異なる機能を可能にし、その特定の機能を有効にしたいクライアントまたはサーバは、この文書で指定された構築物により行う必要があります。たとえば、唯一のリクエスト・ツー・コールの通話サービスを提供する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プロトコル要素をサポートする能力を示すために、クライアントとサーバーで使用可能なメカニズムを提供する属性「必要」：「必要」。
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.
PINTコンテキストで指定されたSIPとSDPの多くのオプション機能が意味をなすことに留意すべきです。属性、呼び出し先の言語を記述するために使用することができる。一例では、SDPのA = LANGあります。別の例では、時間はれるPINTサービスが呼び出されるべきであることを示すために「T =」パラメータを使用することです。これは、「トン=」フィールドの通常の使用です。第三の例では、品質属性です。任意の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.
逆に、インターネットコンファレンスセッション内のデータオブジェクトのサポートは、目的がGSTNサービスのリクエストを提供しない場合でも、有用である可能性があります。この場合には、これらの項目をカバーする拡張は、そうでなければ「普通」SIP / SDP招待に組み込むことができます。同様に、SDPのサポートは、「必要」、「伝統的な」SIP / SDPインフラストラクチャへの機能の追加のためのフレームワークとして、有用であり得ます。再び、これらはPINTサービス要求のために使用されないSIP / 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.
PINT 1.0は、音声、ファックス、およびポケットベルの電話セッションを記述するために可能性をSDPする追加されます。意図的に電話ネットワークの基盤となる技術的な詳細や複雑さを隠すように設計されています。 PINTのために定義された唯一のネットワークの種類は、一般的な「TN」（電話網）です。そのような「ISDN」、「GSM」としてより正確なタグは、定義されていません。同様に、トランスポートプロトコルは、単に「ファックス」、「音声」、および「ポケットベル」として指定されています。様々な電話網の音声、ファックス、またはポケットベルのプロトコルのためのより具体的な識別子はありません。同様に、搬送されるべきデータは、「テキスト」データ、「画像」データ、またはいくつかのより一般的な「アプリケーション」データとして、唯一のMIMEコンテンツタイプによって識別されます。 「アプリケーション」データを輸送する重要な例は、マイルストーンサービス「Webコンテンツへのボイスアクセス」です。搬送されるデータは、URIによって指し示されている。この場合において、データのコンテンツタイプは、アプリケーション/ URIであり、トランスポートプロトコルが「音声」であろう。音声合成機能のいくつかの並べ替えは、電話に出て言えば、このサービスを実行するために呼び出される必要があります。
This section gives details of the new SDP keywords.
このセクションでは、新しいSDPキーワードの詳細を示します。
The TN ("Telephone Network") network type is used to indicate that the terminal is connected to a telephone network.
TN（「電話網」）ネットワークタイプは、端末が電話網に接続されていることを示すために使用されます。
The address types allowed for network type TN are "RFC2543" and private address types, which MUST begin with an "X-".
ネットワーク型TNに許可されたアドレスの種類は、「RFC2543」と「X-」で始まる必要がありますプライベートアドレスの種類、です。
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.
アドレスタイプRFC2543は、SIPの図4に指定された「電話加入者」BNFのサブセットに準拠した文字列[1]）が続きます。この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つのタイプの一つです。これらは、「プラス」記号（「+」）でグローバルな電話番号を先行で区別されています。グローバル電話番号[6]によって定義されるローカル電話番号がのコンテキスト内でデフォルトのダイヤルプランで指定された数であるが、国際的に有意なE.164番号計画アドレスとして解釈されるべきデフォルトで受信者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 = TN X-mytype.mydomain.com A * 8-HELEN
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」は、このプライベートアドレスの種類を識別し、「A * 8-HELENが」この形式の数値です。そのようなフォーマットは、最もダイヤル可能な電話番号がアドレスRFC2543内のローカル電話番号として発現可能である付録A注意のABNFで「OtherAddr」として定義されます。新しいアドレスの種類はだけなので、書き込むことができない形式には、使用されてください。
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インターネット会議セッションにわたって一の有意な変化はPINTサービス要求は、その要求の送信元の情報として使用するデータ・オブジェクトを参照することができるということです。例えば、PINTサービス要求は、ファックスが送信されるGSTNサービスの一部として処理されるドキュメントを指定してもよいです。同様に、GSTNサービスは、Webページを取得し、そのページと電話で内容を話すボコーダ処理につながるかもしれません。
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 call to a certain number during which such-and-such an image is sent as a fax".
SDP仕様は、参照または要求内のデータオブジェクトのキャリッジを明示的にサポートしていません。 PINTのためのSDPを使用するために、「このようなアンドそのような画像はファックスとして送信されている間の特定の番号に電話呼」などのメディアセッションを記述する必要があります。
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つの拡張が指定されています。これらは、メディアフィールドのためのいくつかの新しい許可された値、および（連絡先フィールドネットワークタイプ「TN」の文脈の中で）メディアフィールドの値で使用される「の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メッセージフォーマットになります。メディアフィールドの（[2]）から元のSDP構文は次のように与えられます。
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.
ポートサブフィールドPINT要求のポートのサブフィールドの値は、通常「1」に設定されているように、宛先端末は、アドレス指定の「TN」を使用して指定されているようPINT要求の中には意味がありません。 「0」の値は、端末がメディアを受信していないことを示すために、SDPのように使用することができます。これは、電話端末が一時的に「hold」になったことを示すために有用です。同様に、オプションの整数サブフィールドは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]で述べたように、トランスポートプロトコルのサブフィールドは、関連するアドレスタイプに特異的です。先行Contactフィールドでのアドレスタイプが「TN」ネットワークタイプで使用するために定義されたものの一つである場合には、以下の値がトランスポートプロトコルのサブフィールドのために定義されています。
"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音声呼をもたらすことです送信されました。
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".
このサブフィールドは、必ずしもすべてのソースデータのメディアタイプとサブタイプを指示しないことに注意してください。テキストソースがボコード、そして得られた電話サービスコールで話させるために、たとえば、マイルストーンサービスの一つが呼び出されます。メディアタイプが「テキスト」になりながら、この場合のトランスポートプロトコル値は、「声」になります。
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要求内で使用される場合、このサブフィールドは、関連するメディアサブフィールド値の定義されたMIMEサブタイプであり、各々が1つ以上の値のリストからなります。特別な値は、「 - 」はMIMEサブタイプが存在しないことを意味し、許可されています。このサブフィールドは、リストは、最初は、好ましい値であると、別のサブタイプのセットを含むことをその意味（[2]から）を保持します。
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-」で始まる文字列。 （付録Cを参照）、このような値の使用が推奨され、そしてそのような値は、一般的な用途を見出すことが期待される場合、それは標準のコンテンツタイプの登録プロセスを使用して、IANAに登録されるべきです。
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パラメータは、単一の文字である場合には（ダッシュ）、これは未指定またはデフォルトのサブタイプは、このサービスのために使用することができることを意味すると解釈されます。したがって、メディア・フィールド値「M = 1オーディオ音声 - <CRLF>は」オーディオ・サブタイプはエグゼクティブシステムによって適切とみなされるものは何でも使用して、音声通話が要求されていることを意味するものと解釈されます。要求は、IPネットワークから来ているが、サービスコールがGSTN内に設けられていることにPINTサービスは、特殊なケースです。したがって、サービス要求は、通常、得られたGSTNサービス呼び出しのために使用される特定のコーデックを定義することができません。そのような意図が必要な場合は、品質属性を使用することができる（[2]の「提案された属性」を参照）。
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-REF> | <不透明-ref>を| <サブパート-ref>要素）
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サブフィールド内のエントリは、（リストの最初の好ましいものを有する）の代替です。各エントリは、一致するの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属性は、要素の異なる種類の混合物を含有することができます。したがって属性は保持されている一部のデータへのURI-REFポインティング続いGSTN上のいくつかのコンテンツを参照すると、不透明な-REF続いて、現在のメッセージのサブ部分に保持されている含まれるデータを示すサブ部分-REFを、含まれている場合があります外部IPネットワーク上。
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.
各解像度要素がとる形を示すために、それらのそれぞれが独自のリテラルタグで始まり。各形態の詳細な構文は、以下のサブセクションに記載されています。
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ネットワーク上の他の場所に格納されたデータオブジェクトがPINTサービス内の処理のための供給源として使用される場合、それらは、URI-REFフォームを使用して参照することができます。 [9]に記載されているように、これは、単にのURI（Uniform Resource Identifier）です。
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.
相対参照を解決するために、受信者サーバーのための十分なコンテキスト情報があってもなくてもよいような基準は、絶対URIされるべきであることに注意してください。相対参照のいずれかの使用は、メッセージの送信者と受信者の間にいくつかの民間の合意が必要であり、送信者は受信者が意図した一つであり、参照がコンテキストで曖昧でないことを確認することができない限り避けるべきです。
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.
これらは、メッセージの最終的な受信者のコンテキストで解決する必要がありますので、これはまた、（「//aNode/index.htm：HTTP URI」のような）部分のURIのために保持しています。
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-REF> =（ "URI" URI参照）
where URI-reference is as defined in Appendix A of [9]
URI参照は、付録Aで定義されるとおりである[9]
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 = TN RFC2543 + 1-201-406-4090メートル=テキスト1ファックスプレーンA =のfmtp：平野URI：FTP：//ftp.isi.edu/in-notes/rfc2468.txtか：C = TN RFC2543 +1 -201-406-4090メートル=テキスト1枚のファックスプレーン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ファックスサービスのソースとしてそれを使用することを意味します。
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ネットワーク上ではなく、GSTN内に保持されているデータを参照することができます。これらのアイテムは、必要性を示さされる方法は、リクエスタまたはPINTゲートウェイの文脈の中で意味がありません。参照は、単に要求の一部として意図されるコンテンツを示すために、執行システムによって使用され得るいくつかのデータです。彼らはPINTインフラストラクチャを通じて、「そのまま」送信されるにこれらのデータは、不透明なリファレンスを形成します。
A reference to some data object held on the GSTN has the general definition:
GSTNに保持されたいくつかのデータオブジェクトへの参照は、一般的な定義を有します。
<opaque-ref> := ("opr:" *uric)
<不透明-REF>：=（ "OPR：" *尿）
where uric is as defined in Appendix A of [9].
尿は、[9]の付録Aで定義される通りです。
For example:
例えば：
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain 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.
+ 1-201-406-4090にファックス機に基準値「APPL.123.456」によってGSTN ONインデックス付けされたデータを送信します。エグゼクティブシステムは、電話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 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.
もちろん、不透明な基準は、他の目的のために使用することもできます。例えば、むしろ、単にデータオブジェクトを明確に要求されるよりも、GSTNに開催された文書へのアクセスを許可するために必要になることができました。不透明な参照が置かされている目的は、しかし、この文書の範囲外です。それは単にPINT要求の中に運ば指標です。
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を使用したいとします。彼らの現在の実装では、FAX送信すべき画像（単数または複数）は、完全にダイヤルされた電話番号によって定義されます。 PINT要求の中で、この電話番号は、「宛先：」内に表示されます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サービス要求のためのいくつかの解決策があり、これらのいずれかが値を持たない不透明な参照である場合、その不透明なリファレンスは、属性行に含まれていますが、空の値フィールドでなければなりません。
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:
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サービス要求の唯一の解決され、その参照が値を必要としない特殊な場合には、全くFMTリストは必要ありません。サービスの意図はそれ以上の解像度のない曖昧でありません。
For example:
例えば：
c= TN RFC2543 +1-201-406-4090
m= text 1 fax -
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上に格納された暗黙のコンテンツが存在すること、そしてこれが一意に-URI SIPセッション記述のContactフィールドの組み合わせによって識別されることを意味します。
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.
URIまたはGSTNに保持されたデータ項目への不透明な参照を介してデータをポイントする代わりに、SIP要求自体内のコンテンツデータを含むことが可能です。これは、SIPペイロードのためのマルチパートMIMEを使用して行われます。最初のMIME部分が実行される電話網セッションのSDP記述を含みます。他のMIME部分が搬送されるコンテンツのデータが含まれています。
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)
<サブ部分REF>：=（ "SPR：" コンテンツID）
where Content-ID is as defined in Appendix A of [3] and in [10]).
[3]の付録Aおよび[10]）で定義されるようにContent-IDがあります。
For example:
例えば：
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain spr:<Content-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パートのうちの一つのコンテンツIDであり、この断片は、要求側ユーザが標識このメッセージのサブ部分に保持されたデータオブジェクトを希望することを意味する<コンテンツID>電話番号+ 1 - 201-406-4090でマシンにファックスします。
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を参照してください。
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.
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:
これらの属性の目的は、クライアントが特定の電話番号が解釈されるべきであるその中の余分なコンテキストを指定できるようにすることです。余分なコンテキストが与えられた電話番号を解釈する必要があるかもしれない多くの理由があります。
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は、携帯電話のコンテキストを指定する属性を使用することが通常必要ではありません。以下とから：へ内のこのような152@pint.bt.co.ilなどのURLヘッダおよび/または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).
ヘッダー（セクション：クライアントは属性がサポートされていない場合に失敗する要求を希望する場合、これらの属性は、「必要」属性（セクション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.
あらゆる可能な内部電話ネットワークパラメータを標準化することはできません。彼らは多くの異なったPINTシステムがそれらを使用したいということは十分一般的であるため、PINT 1.0の属性は、仕様のために選択されているので、相互運用性は、単一の仕様を持っていることによって増加されます。
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).
サービスコールレッグをする順序を識別するために、例えば、IPネットワーク上でいくつかの独自の内部の電話ネットワーク変数を輸送する必要がある場合には、独自の属性定義によって相互運用可能ではないことを「=」の行は、それにもかかわらず、有用である可能性があります作られます。これらのプライベート属性は、[2]（この付録Cを参照）、しかしながら、SDPの明細書において言及同じIANA登録手続きを受けるべきです。
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 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.
アリスは彼女の電話の問題を報告したい場合たとえば、彼女はその後、「ネットワーク全体」顧客ケア番号をダイヤルするかもしれません。 U.K.でのブリティッシュテレコムのネットワーク内で、これは「152」です。この場合には、彼女がどんなトランク接頭辞をダイヤルしないことに注意してください - これは全体のダイヤル可能な番号です。他の事業者のネットワークからダイヤルする場合は、ブリティッシュテレコムのエンジニアのお問い合わせサービスに接続しません。そして、ダイヤル「+44 152」は、通常成功しません。このような数字は、ネットワーク固有のサービス番号と呼ばれています。
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クライアントと第1の要求を受信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 =ネットワークプレフィックス/プライベート・プレフィックスのネットワークプレフィックス=国際ネットワークプレフィックス/ローカル・ネットワーク・プレフィックスインターナショナル・ネットワーク・プレフィックス=「+」 1 * DIGITローカルネットワークプレフィックス= 1 * DIGITのexcldigandplus =（0x21-0x2d、0x2f、0x40-0x7d））民間-接頭辞= 1 * excldigandplus 0 *尿
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").
インターナショナル・ネットワーク・プレフィックスとローカル・ネットワーク・プレフィックスは、善意のネットワークプレフィックスでなければならない、と国際ネットワークプレフィックスであるネットワークプレフィックスが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に新しいプライベート・プレフィックスを登録することが可能です。その登録されていない接頭辞は（付録Cを参照してください）自分の秘密、非標準的な性質を示すために、「X-」で始まる必要があります。
Example 1:
例1：
c= TN RFC2543 1-800-765-4321
a=phone-context:+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
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台の電話端末が異なっています。実際に、彼らは別の国に位置しています。
Example 3:
例3：
c=TN RFC2543 123
a=phone-context:+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イスラエルの携帯電話プロバイダのいずれかを定義することが起こると、そのネットワーク内でダイヤルする場合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
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番号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:
要求を受信PINTサーバがacme.comネットワーク内にある場合は、次のように、同じ端末がアドレス指定可能であるかもしれないことに注意してください。
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ネットワークに到達するためにダイヤルされると仮定して）
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ネットワークを介してサービス要求の輸送に影響を与えていませんが、PINTサービス要求の発信者は、彼らが結果のサービスコールで「B党が」提示することを希望するかどうかを示すことを可能にする必要性があるかもしれません「党の」発信電話番号を持ちます。これは、呼び出し側が彼らの通信員は、（自動番号の表示や発信者の表示や回線コーリングアイデンティティプレゼンテーション機器を使用して）発信電話番号を見つけることができるかどうかを選択することができ、いくつかの法域では法的要件です。したがって、属性は、発信者の好みを示すために必要とすることができます。
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 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端子に相手の電話番号を提示提示するかしないかどうかは指定されていない、そしてそれは、この属性に基づいて行動するPINTゲートウェイまたは執行システムのためのすべての地域では必須ではありません。しかし、GSTN操作上の規制上の制約がある使用するため、ここで定義されており、その場合には執行システムは、発信者の要求を尊重するためにそれを使用することができます。
The attribute is specified as follows: a=clir:<"true" | "false">
= 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.
この属性の予想解釈は、それが存在し、値が「偽」であれば、それは「真」である場合に可能ならば、執行システムがないことが要求されながら、その後回線コーリングアイデンティティは、相手端末に提示することができ、ということです回線コーリングアイデンティティを提示します。
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クライアントは場合、端末のアドレスに関連する他のパラメータを指定するために、これらの属性を使用します。 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- <トークン>（（"： "<値>）| ""）"。 SDP属性で可能な要素とその使用の3つは、ここで説明されています。他の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:
= Q763-自然： - 「アドレスインジケータの性質」を示します。値は以下の値が指定されて0と127の間の任意の数であってもよいです。
"1" a subscriber number
"2" unknown
"3" a nationally significant number
"4" an internationally significant number
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:
= 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)
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:
= Q763 - イン - 内部ネットワーク番号にルーティングが許可されている場合を示しています。値は、のいずれかである必要があります
"0" routing to internal network number allowed
"1" routing to internal network number not
allowed
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番号である属性を経由して示しています。通常、これは行うべきではありません。国際重要なE.164番号をアドレス文字列のための「グローバル・電話番号」を用いて示されています。
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属性のいずれかを理解していない場合は、要求を拒否するようにサーバを強制するためには、使用すべきであるクライアントは、次のように指定し、属性を「必要」：
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サーバは、両方の属性を理解しなければならないし、また必要と属性の属性リスト内に現れる属性ごとに、属性の存在によって暗黙の要求を満たします。
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（不良拡張）又は400（悪いRequest）など）、エラーステータスコードを返さなければならない、そして適切な警告を返す必要があります問題またはサポートされていないを説明する行：ヘッダそれは理解していない属性を含みます。サーバがリストされている属性を認識した場合が、属性の存在によって暗黙の要求を満たすことができない、要求は、適切なサポートされていないと一緒に、（606許容できない）のステータスコードを拒絶しなければなりません：ヘッダーまたは警告：行。
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の仕様では、それを無視する必要が属性を理解していないサーバーを可能にします。タグ付きヘッダーを「org.ietf.sdp.require」（セクション3.5.4）：PINTサーバが「必要」属性を遵守することを保証するために、PINTクライアントが要求を含むべきです
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拡張子の大半は「タグ付け」されており、これらのタグは、狭窄を要求に含めることができることに注意してください。例外は、SDP部分で電話番号を使用することです。受信SIP / SDPサーバは、これらの形式をサポートしているか否かを検出することができなければならないように、しかし、これらは、新たなネットワークとアドレスタイプとして定義されます。任意のSDPの受信者のデフォルトの動作は、内容が全くメディアセッションを作成することはできなかった認識されずとして、TNおよびRFC2543またはX-トークンネットワークとアドレスタイプを認識またはサポートしていない場合、それはPINT要求を失敗するということです。したがって別狭窄は、この場合には必要とされません。
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機能を使用する方法について説明します。
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セッション記述を含まなければなりません。後続の部品が要求された電話通話サービスに転送することができるコンテンツデータが含まれています。前述したように、単一PINT要求内に、データの一部は、要求内のURIによって指し示されてもよく、データの一部は、要求内に含まれてもよいです。
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メッセージのコンテンツタイプエンティティヘッダは、これを示さなければなりません。これを行うには、このエンティティヘッダ内のメディアタイプの値が「マルチパート」の値に設定しなければなりません。サブ部分が一緒に扱われるべきである、このような状況のために意図されているコンテンツのサブタイプが存在します。これは、（[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].
囲まれた体の部分を適宜部分固有のコンテンツタイプヘッダを含むべきである（後続のそれぞれのための適切なコンテンツタイプで、セッション記述を保持する第1の本体部分の「SDPアプリケーション/」部「データオブジェクトを含んで」）。 [4]で定義されたように、これはMIMEマルチパートメッセージの標準構文と一致します。
For example, in a multipart message where the string
例えば、マルチパートメッセージにおける場合ストリング
"------next-------" is the boundary, the first two parts might be as
follows:
------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
----------next-------
Content-Type: text/plain
Content-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.
輸送されるコンテンツのためのさまざまな選択肢を示す能力は選択肢がリクエストに含まれている場合でも、便利です。例えば、ポケットベルにショートメッセージを送信するためのリクエストがUnicodeでメッセージ[5]、text / plainの中の同じコンテンツの代替バージョンが含まれる場合があり、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クライアントは非常に注意しなければなりません。このような要求は、断片化を避けるために、かつ確実にデータを送信するために、TCP経由で送ってください。 PINTサーバは、要求がアプリケーション大量のデータが含まれている場合は悲惨なことができ、要求を、複製フォークするプロキシサーバであることも可能です。 PINTプロキシサーバは、その中に大量のデータを使用して要求の多くのコピーを作成しないように注意する必要があります。
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ゲートウェイの実際の場所を知らないし、それを見つけるために、SIP位置情報サービスを使用しており、含まれるデータは、いくつかのIPデータグラムで輸送される可能性が高いPINT要求を行った場合、それは最初のPINT要求することを推奨されますデータオブジェクトが含まれるが、代わりにそれへの参照を保持しません。
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機能のサポートの欠如を知らせることができるようにヘッダ：PINTサーバは、SIP「警告」をサポートしなければなりません。例として、PINT要求は、ファックス機にJPEG画像を送信することですが、サーバーが取得および/またはファックス送信にインターネットからJPEG画像を変換することができないと仮定します。
In such a case the server fails the request and includes a Warning such as the following:
このような場合、サーバはその要求を失敗し、次のような警告が含まれています。
Warning: 305 pint.acme.com Incompatible media format: jpeg
警告：305 pint.acme.com互換性のないメディア形式：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拡張が理解されていない示すために、ヘッダー：すべてのPINT拡張を理解しないSIPサーバは、強く警告を実装することをお勧めします。
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.
要求されたサービスが完了したかどうか、そしてそれが成功したそうかどうかを調べるために非常に便利です。これは、サービスを要求する人は（必ずしも）それへの当事者ではない、ので、そのサービスの配置を見つけるの簡単な方法を持っていない可能性があり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を参照）。 PINT 1.0は、それにもかかわらず、有用な情報を提供する必要があり、単純な方式を採用しています。必要であれば、それは後日向上させることができるので、「後方互換性」の方法でスキームを拡大することが可能となります。
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 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.
PINT 1.0ステータスの登録と表示方式は、3の新しいメソッドを使用しています。 、SUBSCRIBE UNSUBSCRIBE、およびNOTIFY。これらは、PINTクライアントが興味を登録する（またはに「購読」）前の関心は（状態からすなわち「退会」）を経過したことを示している、とするサーバー用にするために、サービス要求の状況をできるようにするために使用されていますサービスの表示を返します。 SUBSCRIBE / UNSUBSCRIBEのステートマシンは、INVITE / BYEのものと同一です。信号を最初のINVITEとBYEがメディアセッションへの参加の終了を知らせる同じように、最初の信号をサブスクライブしUNSUBSCRIBE監視セッションにおける参加の終わりを知らせます。監視セッション中に、NOTIFYメッセージは、セッション状態または処分の変化の加入者に通知するために送信されます。
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.
SUBSCRIBEリクエストがPINTサーバに送信されると、ユーザがサービスセッションの状態に関する情報を受信したいことを示しています。要求は、一意のサービスセッションを識別するために、原点フィールドの一部を形成するSDPグローバルセッションIDを使用して、要求と一緒に元のセッション記述を含んでいることによって関心のあるセッションを識別する。
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).
後続の応答内のフィールド（これはよくPINTかもしれない：（進行中のセッションに関する他のSIP要求など）SUBSCRIBEリクエストは、元のINVITEを送信し、又は接触するように指定されたサーバと同一サーバに送信されますセッションのためのゲートウェイ）。
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.
Call-IDを元に使用される関心のセッションが可能です開始したINVITEのを再利用する状況がある一方で、それがないような他の状況があります。以前に確立されたセッションを参照するために、受信機に知られているであろうようにサブスクリプションが元のサービス要求を開始したユーザによって行われている詳細には、Call-IDを使用してもよいです。しかし、要求は要求元のユーザ以外のユーザから来るとき、SUBSCRIBEリクエストは、新しいSIPコールレッグを構成し、そのコールIDを使用すべきではありません。唯一の共通識別子は、元のサービスリクエスト内に封入されたセッション記述の原点フィールドであり、これは使用しなければなりません。
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このSUBSCRIBEリクエストの両方に含まれるSDPサブ部分の原点フィールドを使用することです。
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要求に存在した場合でも、セッション記述以外のサブ部分を含んではならないことに留意されたいです。サーバは、囲まれたセッション記述の唯一の例外とSUBSCRIBEリクエストに含まれるどのサブ部分無視しなければなりません。
The request MAY contain a "Contact:" header, specifying the PINT User Agent Server to which such information should be sent.
どのような情報が送信されるべきためにPINTユーザエージェントサーバを指定して、ヘッダー：要求は、「連絡先」を含むかもしれません。
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.
また、有効期限含むべきである：ヘッダー、PINTリクエスタは、セッション状態の通知を受信することを望むどのくらいのために示しています。私たちは、「サブスクリプション期間」としてSUBSCRIBEリクエストの有効期限までの時間を参照してください。セクション5.1.4を参照してください。セキュリティ上の考慮事項、特にプライバシーへの影響について。
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.
内の0の値は、有効期限：ヘッダが単一の即時応答（すなわち、要求がすぐに満了する）を受信したい旨を示します。それは、オープンするモニタリングセッションのシーケンスのために可能であるが存在し、かつ完全な、すべて同じサービス・セッションに関連します。
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).
SUBSCRIBEリクエストに対する正常な応答は、ゲートウェイに応じて、セッション記述を含んでいます。通常、これはゲートウェイが同じSDPグローバルセッションID（[2]、セクション6、O =フィールドを参照）に関する任意の要求に戻すことが最後にキャッシュされた応答と同じであろう。 T =ラインしかし、実際の開始を示すか、時間を停止するように変更されてもよいです。ゲートウェイは、多くのファックスページが送信されたかなどの情報を示すために、セッション記述にI =の行を追加することがあります。ヘッダは、モニタリングセッションを維持する意思があるどのくらい示す：ゲートウェイは、有効期限が挙げられるべきです。これはPINT要求者に受け入れられない場合、それは（3.5.3.3を参照）即時UNSUBSCRIBEメッセージを送信することにより、セッションを閉じることができます。
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).
原則として、ユーザーは、電話ネットワークサービスが終了した後にSUBSCRIBEリクエストを送信することがあります。これは、例えば、ファックスが正常に送信されたかどうかを確認するために、「後の朝」までチェックし、ことができます。しかしながら、PINTゲートウェイのみであれば、以前に示されているようにするためのコールに関する状態を維持するために必要とされる有効期限：元に応答内で送信されたヘッダは以内、SUBSCRIBEメッセージに対する応答内に、サービスセッションをトリガINVITEメッセージ任意UNSUBSCRIBEメッセージに対する応答、または独自UNSUBSCRIBEメッセージ内（ただし、セクション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.
SDPセッションIDが有効でなくなっていることを示すない307ヘッダー：サーバーは、もはやリクエスタが加入しているセッションの記録を持っている場合、それは適切な警告と一緒に、「606受け入れられない」と返しません。つまりそれは、セッションが終了する前に、SUBSCRIBEリクエストを送るべきであるセッション終了後のセッションのステータスに関する情報が必要になることを知っている要求しているクライアント。
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.
「開口部」のヘッダは、SUBSCRIBEリクエスト：サブスクリプション期間中に、ゲートウェイは、時々、自発的な連絡先に示されたエンティティにNOTIFYリクエストを送信することができます。通常、これは、リクエスタが加入しているため、サービスセッションの状態の変化の結果として発生します。
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.
受信ユーザエージェントサーバは、最終的な応答（通常は「200 OK」）を返すことによって、これを承認しなければなりません。 PINT拡張子のこのバージョンでは、ゲートウェイは、障害として扱うことがありそうリダイレクト（3xxのコード）をサポートするために必要とされていません。
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.
ゲートウェイは、警告を含んでいてもよい：ヘッダは、サービスの呼び出しにいくつかの問題を説明するために、そして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 SIP：petrack@pager.com SIP / 2.0：SIP：petrack@pager.comから：SIP：R2F.pint.com@service.comコールID：19971205T234505.56.78@pager.comのCSeq：4711は、SUBSCRIBE警告：xxxはファックス中止され、次の時間のためにしようとします。コンテンツタイプ：アプリケーション/ SDP
c=...
i=3 pages of 5 sent
t=...
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.
ある時点で、クライアントの代表ユーザエージェントサーバやゲートウェイのいずれかを監視セッションを終了することを決定することができます。これは、対応サーバへUNSUBSCRIBEリクエストを送信することにより達成されます。そのような要求は、送信者が受信サーバからの最終的な応答を受信すると、セッションを超えると見なされる、すぐに監視セッションを閉じ、そしてしようとしていることを示しています。
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ゲートウェイによって送信されることはありませんSUBSCRIBEリクエストとは異なり、UNSUBSCRIBE要求を監視セッションが閉じていることを示すために、ユーザエージェントサーバへのPINTゲートウェイによって送信することができることに注意してください。 （これは、電話の呼び出しが終了したことを示すためにBYEを送ることができますが、ゲートウェイは、INVITEを送信しないという事実に類似しています。）
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.
ヘッダは、このモニタリングセッションが閉じられた後、サービスセッションの情報を保存するために喜んでどのくらい長く表示：ゲートウェイはUNSUBSCRIBEメッセージを送信することにより、モニタリングセッションの閉鎖を開始する場合、それは「有効期限」が含まれるべきです。これは、クライアントが別の監視セッションを開くために新しいSUBSCRIBEメッセージを送信することができ、その中最小の時間として機能します。で示された時間後に有効期限：後続のSUBSCRIBEリクエストが「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.
クライアントによって指定されたサブスクリプション期間が終了した場合、ゲートウェイはクライアントの代表ユーザエージェントサーバに即時UNSUBSCRIBEの要求を送信することができます。これは、モニタリングセッションは常に脱退/応答交換を完了し、代表的なユーザエージェントサーバは、特定の状況で状態を維持することを避けることができようになります。
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.
それは招待セッション記述のコピーを持つゲートウェイに依存しているとして、それを発行することができたときに、SUBSCRIBEメッセージがで制限されています。ゲートウェイはクライアントの観点から、すぐにゲートウェイがそれに戻っての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.
これが行われた後しかし、クライアントは、監視要求を送信しない理由はありません。これは、ゲートウェイからの最終的な応答を待つ必要がない、そしてそれは確かにサービス要求の最終応答に対するACKを送信する前に、SUBSCRIBEリクエストを送信することができます。時間：それは決定したとき、最初のサービス要求へのゲートウェイの最終的な応答は短いが、有効期限の指示がない限り、この点を超えると、クライアントは、SUBSCRIBEリクエストを送信して自由です。
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
ただし、正当な理由（6.4を参照）サービスはACKを送信PINTクライアントによって確認される前に、すぐに監視セッションを開始することが適切である理由があります。この時点で、ゲートウェイは、それがサービス要求を処理できるかどうかを決めていますが、執行システムへの要求に合格していません。これは、エグゼクティブを尋ねるために良い位置にあるため、
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.
それは以降のサービス要求を送信するときに監視を可能にするシステム。実用的な実装では、これはサービス実行フェーズの開始前またはとして重要であることが示されている場合、過渡サービスのステータスに関する詳細情報が利用可能になると思われます。実行が始まった後に返すことができる情報のレベルを変更することが困難な場合があります。
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.
したがって、任意の時点で、SUBSCRIBEリクエストを送信して自由である一方では、そのサービス要求へのゲートウェイからの暫定応答を受け取った後、それをクライアントが直前の場合は、サービスを確認するACKメッセージを送信するには、このような監視要求を送信しなければならないことをお勧めしますそれは、一時サービスステータスメッセージに興味があります。
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:
SIPの特定のPINT拡張が必要とされるPINTサーバに通知するためにヘッダ：PINTクライアントは、要求を使用します。 PINT 1.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 - サーバは要求と関連メソッドを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 - PINTサーバ（または、それに関連したSDPパーサ）が「必要」属性で定義された理解（セクション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.
それは本当にオプションがサポートされていない場合、要求を拒絶するようにサーバを必要とヘッダー：クライアントは、要求を含むべきです。
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.
要求URI内、およびTo内：：とから：ヘッダPINT URLはPINT要求の中の2つの異なる方法で使用されています。要求URI内で使用PINTインフラストラクチャによってサービス電話網との円滑な相互動作を確保するために、明確化が必要で、これは次覆われています。
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)
For these reasons, the following conventions for URLs are offered for use in PINT requests:
これらの理由から、URLの次の規則は、PINT要求で使用するために提供されています：
1. The user portion of a sip URL indicates the service to be requested. At present the following services are defined:
1. SIPの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は」PINTのマイルストーンサービスのために予約されています。他のユーザー部分は、要求されたサービスは、マイルストーンサービスの一つではない場合に使用しなければなりません。サービスブローカーとして動作する単一PINTプロキシサーバーへのPINTシステムを競合することによって登録に関するいくつかの関連する考慮事項についてはセクション6.2を参照してください。
2. The host portion of a sip URL contains the domain name of the PINT service provider.
2. SIPの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パラメータは、（「電話サービスプロバイダ」のための）「TSP」になるように定義されます。これは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
したがって、例えば： - SIPのINVITE：R2C@pint.pintservice.com SIP / 2.0は、SIP INVITE：R2F@pint.pintservice.comと、TSP = telco.com SIP / 2.0は、SIP INVITE：R2HC@pint.mycom.comと、TSP = pbx23.mycom.com SIP / 2.0 INVITE SIP：13@pint.telco.com SIP / 2.0
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 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).
PINT要求のヘッダー：任意の法的なSIPのURLは、Request-URI内またはにPINT URLとして表示されます。アドレスは電話アドレスである場合でも、我々は遠隔電話端末やサービスを識別するために、正しくために、より多くの情報を含めることが必要であることセクション3.4.3に示されています。彼らは必要ですかSIP URL内の電話番号への便利な補完場合PINTクライアントがPINTのURL内でこれらの属性タグを含むかもしれません。これらの属性タグで定義されるようにURLパラメータとして含める必要があります[1]（すなわち、セミコロン分離方法で）。
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
SIP：+9725228808@pint.br.com;ユーザー=電話; = Q763-計画を必要と; = Q763-計画：4
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内で必要とされることはありません。ヘッダは、リクエスト-URIもある。具体的には、SIP URLが内にあります。ほとんどの場合、これは電話ネットワークのための十分な情報を提供します。
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属性は、通常のみ使用されます。
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ユーザエージェントサーバです。ユーザエージェントサーバ（すなわち、サービス要求に）プロキシを伝えるか、「電話を受ける」ために利用可能なサーバをリダイレクトするREGISTERリクエストを使用しています。したがって、PINTゲートウェイは、プロキシに登録するか、サーバーにSIPで、ユーザが特定の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システムを可能セクション3.5.5で指定されました。レジストラは（いくつかの可能な導入オプションのためのセクション6.3を参照）のサービスを求めているクライアントからのINVITEに応答する方法を決定するために、独自のメカニズムとポリシーを適用することができます。 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の使用は、今後の研究の主題です。
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]は、通常、元のエンティティがもはや指定されたコールに関与することを望むことを示していないために使用されます。リクエストは、コールおよびメディアセッションを終了します。 PINTクライアントはB、クライアントからのBYE要求への電話の呼び出しにつながる要求を行う場合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要求を受信したときに、通話が開始されていない場合は、1つは、このようなケースであることを期待するかもしれません。例えば、ファックス要求がファックス4 AMにて明日送信されることを示すT =行で送信される場合、要求者は、指定された時間の前に要求をキャンセルすることを望むかもしれません。
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が受信される前に全体電話側のサービスが完了されるかもしれないということです。上記リクエスト・ツー・ファックス例では、BYEは翌朝送信されるかもしれない、とBYEが受信された前の全体のFAXが送信されました。 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.
警告の組み合わせ：セッション記述内のヘッダとI =行が問題の正確な性質を示すために使用することができます。
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: ...
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
TIF URI：ます：http：//tifsRus.com/yyyyyy.tif V = 0 ... ...私は= 5ページの図3は、=のfmtp TIF OK C = TNのRFC2543 12014064090メートル=画像1ファックスを送りました
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:
第二の問題への懸念は、どのくらいのサーバがBYEを受け取った後に通話状態を維持しなければなりません。他のクライアントがまだ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. A BYEを要求しているクライアントは、すぐにそれが正常な応答を受信すると、すべてのコールの状態をクリアすることを示します。それはBYEを送信した後、クライアントは、SUBSCRIBEリクエストを送信することはできません。
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).
ヘッダBYE要求に対する成功応答内2.サーバーが有効期限を返すことができます。これは、サーバが電話網セッションについてのセッション状態が保持されますどのくらいのために示します。この時間の中の任意の時点で、クライアントはセッション状態について学ぶためにサーバにSUBSCRIBEリクエストを（のように前の段落で説明したが、BYEを送信したクライアントが正常にSUBSCRIBE送信されません）を送信することができます。
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 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.
3.、SUBSCRIBE / NOTIFY監視セッションで連絡先に記載されたURLにUNSUBSCRIBEを送るPINTサーバを従事：クライアント要求のヘッダーがないはず明確なセッション状態UNSUBSCRIBEメッセージに正常な応答が受信された後まで。 PINTサーバのを受け取るために：たとえば、要求元のクライアントホストがオフ（または低電力モードで）電話サービスが実行されたとき（属性、したがって、以前に連絡先に指定された場所では使用できない）されている可能性がありUNSUBSCRIBE。もちろん、UNSUBSCRIBE要求は、単にタイムアウトする可能性があります。
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：にanon-1827631872@chinet.net：：SIP：R2C@pint.mailorder.com SIP / 2.0経由：SIP / 2.0 / UDP 169.130.12.5から：一口一口をINVITE + 1-201-456- 7890@iron.org;ユーザー=電話-ID：19971205T234505.56.78@pager.comのCSeq：4711は、件名をINVITE：アイロンボードコンテンツタイプの販売：アプリケーション/ SDPコンテンツの長さ：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
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).
この例では、へを解釈するために必要とされるコンテキスト：電話番号などのアドレスが明示的に指定されていません。これは、暗黙的にR2C@pint.mailorder.comサーバに知られています。しかし、明示的に（なぜならC =ライン内の「+1」の）北米番号計画内に収まって国際的重要なE.164番号として識別されたコールを受信したい人の電話。
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 SIP：marketing@pint.mailorder.com SIP / 2.0経由：SIP / 2.0 / UDP 169.130.12.5から：SIP：john.jones.3@chinet.netへ：SIP：mary.james@mailorder .COMは、コールID：19971205T234505.56.78@pager.comのCSeq：4712は、INVITE
Subject: Defective Ironing Board - want refund
Content-type: application/sdp
Content-Length: 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 = 0 0 = - IP4 128.3.4.5 S =マーケティングe=john.jones.3@chinet.net C = TN RFC2543 + 1-201-406-4090トン= 2353687640 0メートル=オーディオ1声で2353687640 2353687640 -
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).
宛先：行は、メアリー・ジェームズの電話番号の代わりに、電子メールのようなアドレスが含まれる場合があります。 「宛先：」で、電子メールのようなURLを受け入れることができない実装ヘッダは許容できない606で要求を拒否しなければなりません。送信PINTクライアントがPINTゲートウェイがと接触することを「知っている」ことに注意してください「marketing@pint.mailorder.com」のRequest-URIが期待通りにクライアント要求を処理することができます。 （これについての議論のための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.
そのような電話サービスは異なる内容との電話側で実装することができることにも注意してください。例えば、それは、その最初のエージェントの電話が鳴るかもしれないが、その後、顧客の電話が鳴る、またはその最初の顧客の電話が鳴るかもしれないと、エージェントがオンラインになるまで、彼は愚かな音楽を聞きます。必要に応じて、サービスパラメータの詳細は、セッション記述の中に「A =」属性のラインで示されている可能性があります。サービスの一貫性のため、このような属性行の仕様は、PINT 1.0仕様の範囲を超えています。
4.3. A request from the same user to get a fax back on how to assemble the Ironing Board
4.3. バックアイロン台を組み立てる方法についてのファックスを取得するために同じユーザからの要求
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 SIP：faxback@pint.mailorder.com SIP / 2.0経由：SIP / 2.0 / UDP 169.130.12.5から：SIP：john.jones.3@chinet.netへ：SIP：1-800-3292225 @ steam.edu;ユーザー=電話;電話コンテキスト= + 1のCall-ID：19971205T234505.66.79@chinet.netのCSeq：4713は、Content-typeをINVITE：アプリケーション/ SDPコンテンツの長さ：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 c=TN RFC2543 1-201-406-4091
a=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）に格納され送信される、またはそれのみPINTサーバが着座するIPネットワーク内から到達可能であってもよいです。ダイヤルする電話番号は、同様に、「ローカルの電話番号」です。 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.
それは数を理解していない受信サーバは、その要求を拒否し、「ネットワークが分からないアドレス」という警告を含みますか。要求にも「必要」属性をサポートしていないサーバがサービスを提供することができる可能性が非常に高いですので、何も「必要」属性は、ここで使用されなかったことに注意してください。
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 SIP：faxback@pint.mailorder.com SIP / 2.0経由：SIP / 2.0 / UDP 169.130.12.5から：SIP：john.jones.3@chinet.netへ：SIP：1-800-3292225 @ steam.edu;ユーザー=電話;電話コンテキスト= + 1のCall-ID：19971205T234505.66.79@chinet.netのCSeq：4713は、コンテンツタイプをINVITE：アプリケーション/ SDPコンテンツ長：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
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 SIP：R2F@pint.pager.com SIP / 2.0経由：SIP / 2.0 / UDP 169.130.12.5から：SIP：SIP：：へscott.petrack@chinet.net R2F@pint.pager.comコールID：19974505.66.79@chinet.netのCSeq：4714 INVITE
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
----next
Content-Type: text/plain
Content-ID: 2@53655768
Content-Length:50
Hi Joe! Please call me asap at 555-1234.
ジョー・こんにちは！ 555-1234で、できるだけ早く私に電話をしてください。
----next--
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 SIP：faxserver@pint.vocaltec.com SIP / 2.0経由：SIP / 2.0 / UDP 169.130.12.5から：SIP：scott.petrack@chinet.netへ：SIP：faxserver@pint.vocaltec.comコールIDを：19971205T234505.66.79@chinet.netのCSeq：4715コンテンツタイプをINVITE：アプリケーション/ SDPのContent-Lengthを：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
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は、好ましい形式です。 （それはマシン名「2000 Petrackとを」解決することができますので）画像が存在するhttpサーバがローカルであることに注意してください、とPINTサーバは、ローカルであります
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 SIP：R2HC@pint.acme.com SIP / 2.0経由：SIP / 2.0 / UDP 169.130.12.5から：SIP：SIP：：へscott.petrack@chinet.net R2HC@pint.acme.comコールID：19974505.66.79@chinet.netのCSeq：4716 Content-TypeのINVITE：マルチパートを/関連;次回=境界
--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
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-4091トン= 2353687720 0メートル=テキスト1音声プレーンA =のfmtp：平野SPR：=のfmtp 2メートル53655768 @ =テキスト1音声平野A：プレーンURIます。http：// WWW .your.com /テキスト/ stuff.doc
--next Content-Type: text/plain Content-ID: 2@53655768 Content-Length: 172
--nextのContent-Type：text / plainのコンテンツID：2のContent-Length 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--
こんにちは！！私はあなたにあなたが要求した文書、「します。http：//www.your.com/texts/stuff.doc URI」を読み出すことについてです。私たちは、acme.comの新しい音声合成サーバのようにあなたを願っています。 - 次 -
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
SIPのINVITE：R2FB@pint.bt.co.uk SIP / 2.0経由：SIP / 2.0 / UDP 169.130.12.5に：SIP：0345-12347-01@pint.bt.co.uk;ユーザー=電話;電話コンテキスト= + 44から：一口：価格リストコンテンツタイプ：アプリケーション/ SDPのContent-Length件名をINVITE 4716：19981204T201505.56.78@demon.co.ukのCSeq：-IDを呼び出しhank.wangford@newts.demon.co.uk： 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 = 0 0 = - 2353687740 2353687740 IP4 128.3.4.5 S = R2FB I = ISDN価格表e=hank.wangford@newts.demon.co.ukトン= 2353687740 0メートル=テキスト1ファックス、IN - C = TN RFC2543 +44 -1794-8331010
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
SIP / 2.0 / UDP 169.130.12.5：SIP：R2C@pint.bt.co.uk SIP / 2.0経由：SIPのINVITE;ユーザー=電話; 0345-123456@pint.bt.co.uk電話コンテキスト= + 44投稿者：SIP：hank.wangford@newts.demon.co.ukコールIDを：19981204T234505.56.78@demon.co.ukのCSeq：4717は、件名をINVITE：それはどのくらいの費用がかかりますか？コンテンツタイプ：アプリケーション/ SDPコンテンツの長さ：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 -
V = 0 0 = - IP4 128.3.4.5 S = R 2 C I = ISDNプリセールスクエリe=hank.wangford@newts.demon.co.uk C = TN RFC2543 + 44-1794-8331013 T IN 2353687760 2353687760 = 2353687760 0 M = 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
SIPのINVITE：R2FB@pint.bt.co.uk SIP / 2.0経由：SIP / 2.0 / UDP 169.130.12.5に：SIP：0345-12347-01@pint.bt.co.uk;ユーザー=電話;電話コンテキスト=から+ 44：SIP：要求されたContentとして、価格情報：件名をINVITE 1147：19981205T234505.56.78@sales.hh.bt.co.ukのCSeq：-IDを呼び出しcolin.masterton@sales.hh.bt.co.ukタイプ：マルチパート/関連;次回=境界
--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
--nextコンテンツタイプ：アプリケーション/ SDPのContent-Length：325 V = 0 0 = - IP4 128.3.4.5 S = R2FB I IN 2353687780 2353687780 =あなたの文書e=colin.masterton@sales.hh.bt.co.uk T = 2353687780 0メートル= 1枚のアプリケーションファックスオクテットストリームC = TNのRFC2543 + 44-1794-8331010 =のfmtp：オクテットストリームURI：HTTP：//www.bt.co.uk/imgs/pipr.gif OPR： SPR：2 @ 53655768
--next Content-Type: text/plain Content-ID: 2@53655768 Content-Length: 352
--nextのContent-Type：text / plainのコンテンツID：2のContent-Length 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ジョブの参照を引用してください。敬具、コリン・マスタートン--next--
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線の中央に空の不透明な基準によって与えられることに留意されたいです。
(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
（ⅰ）電話SIP INVITE：にSIP / 2.0 / UDP 169.130.12.5：SIP：R2FB@pint.wwos.skynet.com SIP / 2.0経由を1-900-123-456-7@wwos.skynet.com;ユーザー=電話;電話コンテキスト= + 1から：SIP：fred.football.fan@skynet.com-IDを呼び出します19971205T234505.56.78@chinet.netのCSeq：4721 INVITEを件名：スポーツNFL最終スコアのContent-Typeでのワンダフル・ワールド：アプリケーション/ SDPコンテンツの長さ：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>
(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
（ⅱ）ファックスSIPのINVITE：R2FB@pint.wwos.skynet.com SIP / 2.0経由の：SIP / 2.0 / UDP 169.130.12.5へ：SIP：1-900-123-456-7@wwos.skynet.com;ユーザー=電話;電話コンテキスト= + 1から：SIP：fred.football.fan@skynet.com-IDを呼び出します19971205T234505.56.78@chinet.netのCSeq：4722 INVITE件名：スポーツNFL最終スコアのContent-Typeでのワンダフルワールド：アプリケーション/ SDPコンテンツの長さ：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>
(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
SIP / 2.0 / UDP 169.130.12.5：SIP：R2FB@pint.wwos.skynet.com SIP / 2.0経由：（III）ページャは、SIPのINVITE 1-900-123-456-7@wwos.skynet.com、ユーザ=電話;電話コンテキスト= + 1から：SIP：fred.football.fan@skynet.com-IDを呼び出します19971205T234505.56.78@chinet.netのCSeq：4723 INVITEを件名：スポーツNFL最終スコアのContent-Typeでのワンダフルワールド：アプリケーション/ SDPコンテンツの長さ：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>
Note that these are all VERY similar.
これらはすべて非常に類似していることに注意してください。
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
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>
V = 0 0 = - 2353687860 2353687860 IP4 128.3.4.5 S = BillsRUs I =ジョー・ペンドルトンの電話ビルe=agent.mulder@fbi.gov C = TNのRFC2543 + 1-202-833-1010トン= 2353687860 0メートル=テキストで1枚のファックスX-ファイル-ID = Aのfmtp：X-ファイル-IDのOPR：fbi.gov/jdcn-123@45：3DES、BASE64、<署名>
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).
注意：SIPのフィールド「ラッパー：この場合には、不透明な参照は、要求側がむしろに特定のコンテンツ（政党を選択するよりも、この情報を取得する権利を有する執行システムを説得するために使用されるデータの集合であります"）だけであることありません。
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ゲートウェイ、およびゲートウェイが関連付けられていることをエグゼクティブ・システム（単数または複数）は、リクエスタをPINTにサービスを提供するために存在します。 PINTプロトコルの目的は、その関連するエグゼクティブ・システムがこれらの要求にサービスを提供することができますPINT Gatewayにそれらのユーザーからの要求を渡すことです。
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ベースの呼び出しを行うの施設は、しかし、いくつかのリスクが付属しています。リクエストは、ファックス番号の間違った電話を指定することができます。リクエスタが意図的に無実の第三者の電話番号を入力した可能性もあります。最後に、要求は、任意の介在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オペレータは、この誰かが彼らではないことを好むので、彼らはどんなPINTゲートウェイと執行システムの組み合わせは、いくつかのゲートウェイでのエラーや執行システムの実装やGSTN内部の通信障害による不正な呼び出しを生成しないことを確認する必要があります。同様に、オペレータが、彼らは彼らだけが正しいと信じる十分な理由を持っているの要求に基づいて行動することを示すことができることが重要です。彼らがリクエスタからの輸送中に破損していないことを確認されない限り、ゲートウェイが要求に合格してはならないことを意味します。
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.
リクエストが特定のリクエスタから来ているとPINTサービスプロバイダーによって誠実に行動にされていることを示すことができる場合は、要求を行うための責任が良くリクエスタではなく、これらの要求を実行したオペレータに落ちることがあります。
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サービスプロバイダは、彼らは彼らだけが起源の保証のいくつかの学位を持っているの要求に基づいて行動することを示してできるようにするために最後に、それは重要であるかもしれません。多くの国では、それは、彼らが、必要であれば、（そのような悪意のあるコールのトレースを実行するために必要な場合など）、コールに関係者を識別することができた場合にのみ電話をかけることGSTN演算子の要件です。それは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サービスプロバイダーは、リクエスタの身元が確認されることを必要とするかもしれないということになります。このような確認が利用できない場合、彼らはサービスを提供しないように強制的に（または選択）することができます。この識別は、要求しているユーザの個人認証が必要な場合があります。
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サービスを提供するために使用される場合、それは、誰かがそれを支払わなければならないことを少なくとも可能です。例えば、無料の電話のような既存の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サービスは、サブスクリプションベースで提供されてもよいし、他のモデルの数があります。しかし、選択された方のモデル、リクエスタの権限がPINT要求が確認されていることを確認する必要があるかもしれません。
If such confirmation is not available, then, again, the PINT Gateway and associated Executive System may choose not to provide service.
このような確認が利用できない場合、その後、再び、PINTゲートウェイと関連する執行システムがサービスを提供しないこともできます。
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.
彼らは彼らの要求を知らされていることを確認し、その下要求しているユーザーと権限のアイデンティティは、要求が悪意を持って変更され、あるいはリクエスタと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).
同様に、要求がなされた下機関に関する情報が十分にその要求の中で運ばれてもよいです。盗聴者がこれを盗み、自分の要求の中でそれを使用する場合がありますので、これは、機密情報とすることができます。それは（クレジットカード番号やPINなど）の財務情報であるかのようにそのような権限が扱われるべきです。
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).
PINT要求をするために要求するユーザを認証データは、それらとサービスプロバイダーに知られている必要があります。しかし、この情報は、通常、インターネット内で使用される方式と一致しない形態であってもよいです。たとえば、X.509証明書[14]（一般に[13] IPセキュリティアーキテクチャ[12]およびTLSプロトコルの両方で、インターネット上でセキュアなトランザクションのために使用されるが、GSTNプロバイダは、アカウントコードとPINを格納することができますすなわち数字の固定文字列）。
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.
要求しているユーザーは、サービスのための彼らの要求が機密であることを合理的な期待を持っています。いくつかのPINTサービスでは、何のコンテンツがインターネット上で行われていません。しかし、結果としてサービスコールへの電話やパーティーのファックス番号は、機密と見なすことができます。その結果、リクエスタ（およびそのPINTサービスプロバイダー）は、インターネット経由で送信されるすべての要求が盗聴から保護することが必要になる可能性があります。要するに、要求を暗号化する必要があります。
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.
いくつかの特別な考慮事項は、SUBSCRIBEとNOTIFYメッセージを使用して、セッションの監視に関連します。 PINTサービス取引の処分への関心を登録するために使用されるSUBSCRIBEメッセージは、関連するINVITEメッセージで運ばれたオリジナルのセッション記述を使用しています。この現在の仕様では、そのようなSUBSCRIBEメッセージのソースを限定するものではないので、盗聴者は、保護されていないセッション記述を取得し、SUBSCRIBE後続の要求でこれを使用することが可能です。このようにしても機密と見なすことができるその取引についての詳細を知ることができます。
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.
このリスクの初期溶液は、その後のSUBSCRIBEメッセージ内で使用することができるセッション記述は、保護されるべきであることをお勧めすることです。
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.
しかし、更なる危険性があります。使用原点フィールドは「推測」である場合、攻撃者がセッション記述を再構築し、SUBSCRIBEメッセージ内のこの再構成を使用するために、それは可能かもしれません。
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は、（[2]、「O =」フィールドのセクション6を参照）のSES-IDフィールドを生成するために使用されるメカニズムを指定し、ネットワークタイムプロトコルによって生成されたタイムスタンプに基づいて、その方法が提案されている[16]を用いることができません。これは、同じ発信元からの他の保護されていない要求が利用可能な場合は特に、一意性を保証するのに十分であるが、その値を推測できるようにすることができます。
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に記載された技術を用いることができる推測されていないことを確実にします。特定のPINT要求エンティティ（にと応答）すべてからの要求が保護されている場合、これは必要ありません。そのような状況が確保されていない場合、セッションの監視がサポートされている場合、AND、次いでセッション記述内の原点フィールドが推測されていないことによって方法を使用すべきです。
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ゲートウェイの任意の数が同じサービスを提供するために登録することもできます。 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.
要求は、明示的にいくつかのゲートウェイがすべて登録されているために、登録データベースに作用する介在プロキシゲートウェイ名を指定しない限り、それが選ぶどんなアルゴリズム使用して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リクエストを送信することであり、そうでない場合は1つのPINTサービスとして、PINTのレジストラがRegistrandの認証を使用することが重要である0の値を持つパラメータを満了しましたプロバイダは別の「なりすまし」のことができるように、その登録を削除します。これは、そのプロバイダへの要求を渡すプロキシを停止するように、これは両方の増加要求が不正に送信され、犠牲者に行くの要求を停止しているでしょう。
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.
この攻撃のもう一つの変異体は、別のプロバイダによって登録された名前を使用してゲートウェイを登録することです。したがって、不正なオペレータは、それによって要求をハイジャック、「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ゲートウェイによってすべての登録が認証されなければなりません。これは、新規または見かけ交換登録、及び現在の登録のいずれかの取消の両方を含んでいます。この勧告はまた、SIP仕様で作られているが、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]、および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サービスのいくつかのために：SIPのヘッダフィールドは、得られたサービスコールの当事者のいずれかを識別するために使用されます。 PINT要求ツーコールサービスは一例です。 SIP仕様で述べたように、このフィールドは、対応するユーザエージェントサーバ間のリダイレクトとプロキシサーバのインフラストラクチャを介して経路SIPメッセージに使用され、そのため、暗号化することができません。これはPINTサービスコールに、個人データや機密データの大半は輸送中にいる間に保護することができるが、という当事者の一方の電話（またはファックス）番号を意味することはできませんし、任意の傍受に「見える」となります。呼び出し側がに名付けので、PINTのマイルストーンサービスの場合、これは、許容できる：サービスは、一般的なコールセンターなどの「周知の」プロバイダのアドレス、です。
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.
これの別の態様は、要求しているユーザは、これらの当事者がかもしれませんが、プライベートであることをPINTサービスへのパーティーの電話またはファックス番号を考慮しない場合でも、ということです。 PINTサーバは、このような場合、彼らはリクエスタがそうしなかった場合でも、要求を暗号化すべきであるかもしれないと信じるに足る理由を持っているところ。企業内の要求しているユーザがPINT要求を配置し、これを別の場所で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).
要求が盗聴者「なりすまし」のリクエスタまたは盗聴者の要求にリクエスタの認証トークンを挿入することにより、PINTサービスを取得するのいずれかで再利用できるデータを運ぶ場合、このデータは保護されなければなりません。認証トークンは、（例えば、アカウントコード、および/またはPINのような）静的なテキストで構成されている場合、これは特に重要です。
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.
一つのアプローチは、SIP仕様で記載された方法を使用して、要求の全体を暗号化することです。代替として、それは不透明な基準として保持される認証トークンのために許容可能である（セクション3.4.2.3および実施例4.11と4.12を参照）、いくつかの独自の方式を使用して、この限り、リクエスタおよびPINTサービスプロバイダとの間で合意傍受して再利用するために耐性です。また、許可トークンを暗号リクエスタによって署名された要求の外で使用することができないことがあってもよいです。従ってこの場合にトークンが他によって再使用することができないようにこの要件は、緩和することができます。リクエスタとゲートウェイの両方が、これが事実であることが保証されていない限り、しかし、任意の認証トークンは機密として扱う必要があり、そのために暗号化されなければなりません。
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つのゲートウェイと執行システムの組み合わせは、他の缶ながら、ポケットベルなど、当事者のいずれかを指定する要求を処理できないことかもしれません。両方のゲートウェイはPINT / SIPレジストラに登録されている可能性があり、この情報はPINT / SIPプロキシの介在に利用可能であってもよいです。メッセージ本文が暗号化されている場合は、その要求はプロキシサーバで復号することができない、などに含まれる情報に基づいて、ゲートウェイ選択が存在することができません。
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).
その結果、プロキシがそれを扱うことができないゲートウェイにリクエストを送ることができるということです。含意はPINT / SIPプロキシは、補正に適切なゲートウェイ被験者のためにその選択を考えると、選択された最初のゲートウェイから501又は415拒絶を受けて、別のものを試みるべきであることです。それが遅延する場合であっても、すべての可能であればこのように、要求は成功します（不適切なゲートウェイのリソースをタイアップ）。
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.
これは、サービス拒否のための興味深い道を開きます。異なるゲートウェイの数に適していると思わ有効な要求を送信し、単に彼らが提供できないサービスを要求するメッセージを解読するには、これらのゲートウェイを占めます。セクション3.5.5.1で述べたように、SIPリクエストURIのユーザー情報部分に渡されるサービス名の選択が柔軟であり、プロキシを検討することなく、適切なゲートウェイを選択することを可能にするその名が選択することを推奨されていますSDPの身体の部分。輸送中に保護されているSDP本体部分の可能性がある場合はこのように、ここに挙げた例では、サービスは、むしろ「R2F」のより一般的な使用より「リクエストからページへ」または「R2P」と呼ばれるかもしれません。
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招待と同じ方法で最小化することができます。プロキシは、最初のゲートウェイから返された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.
最後に、要求しているユーザーはまだ彼らの要求を満たし執行システムのオペレータとの事前の関係を有する一方で、PINTゲートウェイとの事前の関係を持たないかもしれないことに注意してください。したがって、認証と認可、2つのレベルが存在し得ます。一つは、別の要求しているユーザまたはリクエスタと執行システムの間で使用されると、（リクエスタとゲートウェイの間の使用のための）SIP仕様に記載された技術を用いて行います。
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.
例えば、要求しているユーザは、PINTサービスプロバイダーのアカウントを持っていることがあります。そのプロバイダは、彼らがサービスを提供することを確信される前に、要求がこのIDを含めることが必要な場合があります。それはインターネットを介して輸送中にある間に、追加の攻撃に対抗するために、ゲートウェイは、要求の別の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.
このメカニズムの詳細な動作は、インターネットプロトコルの範囲外で、定義することで、そのため個人的な問題を考慮しなければなりません。しかしながら、そのような「第二レベル」認証または許可は、そのサービスプロバイダによって必要とされることを要求者に指示するための一つのアプローチは、PINTゲートウェイから返された応答401を用いて実施テキスト記述の内部にこれを依頼することであろう。
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実装は（[1]、セクション13および15に記載されているように）SIPセキュリティをサポートし、そして、受信メッセージを処理することができなければなりませんので、PINTメッセージは、保護されなければなりません。
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クライアントは、サーバー、およびゲートウェイは、彼らがそれらの間のすべての通信のためのネットワークレベルのセキュリティ[13]、トランスポート層セキュリティ[12]、または物理的なセキュリティのサービスを使用して動作することを確認することができます。すべてのトラフィックがすでに保護されていますので、これらのケースでのメッセージは、SIPのセキュリティなしで交換することができます。クライアントとサーバは、下位層のセキュリティ機能を使用するように手動設定をサポートする必要があります。
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トラフィックに適切な保護を提供するように構成されなければなりません。 TLSを使用する場合は、設定されたポートは、非TLSトラフィック用に設定しないでください。 TLSを使用する場合は、基本認証をサポートしなければなりませんし、クライアント側の証明書をサポートすることができます。
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.
要求を行ったクライアントの認証は、しかしながら、必要とされるので、これを使用し、基礎となるメカニズムによって提供されていない場合、それはSIP認証技術を使用して、PINTメッセージ内に含まれなければなりません。 SIPとは対照的に、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クライアントとPINTゲートウェイとの間のネットワーク・レイヤ・セキュリティを使用して、エンドツーエンドアプローチが介在するプロキシの使用を排除することになります。クライアントとゲートウェイ間の通信は、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のセクション15に記載された技術を使用しなければなりません。いずれの場合においても、PINT要求または応答の中で運ば任意のメッセージ本体（または本体）の含有量は、保護されなければなりません。これは、（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技術を使用して、要求URIとするためには：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のデフォルトの動作とは異なります（それが失敗したならば、TCPを試し、UDPを試してみてください）。
6. Deployment considerations and the Relationship PINT to I.N. (Informative)
I.N. 6.展開に関する考慮事項と関係PINT （参考情報）
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.
いくつかの他のプロトコルが要求しているユーザーの要求を通信するために使用される可能性があります。利用可能なWebブラウザとサーバの高い数字には、いくつかのPINTシステムは、「フロントエンド」としてHTML / HTTPを使用する可能性が高いようです。このシナリオでは、HTTPは、中間Webサーバ（WS）に要求しているユーザのWebブラウザ（WC）からの接続を介して使用されます。これは密接に（PINTクライアントにWebサーバーからデータを転送するために、いくつかの不特定のメカニズムを使用して）PINTクライアントに関連付けられます。 PINT ClientはPINTゲートウェイのため、必要なアクションを実行する執行システムに要求しているユーザを表します。
[WC]------[WS]
[PC]
\
\
[PG]
[XS]
Figure 2: Basic "Web-fronted" Configuration
図2：基本「のWebフロントエンド」の設定
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に接続できるエグゼクティブ・システム（またはシステム）に関連付けられていることは非常に可能です。 PINTサーバの鎖が存在する場合も同様に、これらの中間体またはプロキシサーバー（PP）のそれぞれは、GSTNに特定のポイントで接続エグゼクティブ・システムへのルートPINT要求することができるかもしれません。この結果は、特定の要求に対処することができ、複数のPINTゲートウェイまたは執行システムがあるかもしれないことです。メカニズムは、それによって要求を配信する場合に選択が、この文書の範囲外です。
[WC]------[WS] [WC]------[WS]
[PC] [PC]
\ \
\ \
[PG] [PP]
.........[XS]......... / \
: : / \
[PG] [PG]
[XS] [XS]
Figure 3: Multiple Access Configurations
図3：複数のアクセスの構成
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.
しかし、二つのアプローチがあるように思えます。プロキシとして動作するか、リダイレクトサーバーは、適切なゲートウェイ自体を選択し、要求が応じて上送信する、または可能な場所のリストは、彼らが彼らの選択を選択することができ、そこから要求しているユーザに返される原因になりますどちらか。
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では、含意はプロキシが要求先のための単一のユニークなマッチに解決できない場合は、選択肢のリストを含む応答を選択するために要求しているユーザに返却しなければならない、ということです。これも可能性の高いシナリオ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の中には、そのような曖昧さはかなり一般的であってもよく、それは、与えられたサービスの可能なプロバイダの数があることを意味します。
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では、登録は個人のためではなく、サービスプロバイダによって処理できるサービスのためではありません。このように、一つは「broker.telcosのためのレジストラとして動作する仲介サーバーに送信された「R2C@telcoA.com」としてサービスR2Cをサポートする能力のドメインtelcoA.comのPINTサーバで登録を想定することができます。次のようにR2C@pint.telcoA.com 『COM」からドメイン』：
REGISTER sip:registrar@broker.telcos.com SIP/2.0
To: sip:R2C@pint.telcoA.com
From: sip: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".
「R2C」サービスをサポートするすべての人の異なったサービスプロバイダの数がある場合は、何が起こりますか？ドメイン「broker.com」でPINTシステムがあるとします。 broker.comからのリクエスト・ツー・コールのサービスを要求PINTクライアントは以前にレジストラに登録されていたさまざまなサービスプロバイダーのいずれかにリダイレクトまたはプロキシされることは非常に喜んかもしれません。 PINTサーバも、明示的にサービスプロバイダを指定するだけでなく、「彼らに」向けられていたものを要求していない要求のためのサービスを提供するに興味があるかもしれません。
To enable such service, PINT servers would REGISTER at the broker PINT server registrations of the form:
そのようなサービスを有効にするには、PINTサーバは、フォームのブローカーPINTサーバの登録時に登録します：
REGISTER sip:registrar@broker.com SIP/2.0
To: sip:R2C@broker.com
From: sip:R2C@pint.telcoA.com
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.:
そのようないくつかのREGISTERメッセージがレジストラに表示された場合、それぞれがからにURLのみが異なる：ライン、レジストラは多くの可能性、例えばを持っています：
(i) it overwrites the prior registration for "R2C@broker.telcos.com" when the next comes in;
次は入って来たときに（私は）それは「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.
（ⅲ）それはすべて、このような登録を維持しています。
In this last case, on receiving an Invitation for the "general" service, either:
この最後の場合には、「一般的な」サービスのための招待状を受信すると、次のいずれか
(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.2）は静かに、例えば、使用して登録（のいずれかを選択する：（III.1）は、複数の場所を使用して、全ての承諾と照合応答を返す、すべての登録されたサービス・プロバイダへの招待に渡し「ラウンドロビン」アプローチ）とルートさらなるコメントなし以降招待状と応答。
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要求を拒否し、「一般」サービスの登録を許可しないことを選択できます。
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. SUBSCRIBEのための入手可能な情報及び要求タイミングの制限
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 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.
PINTのための基準の設定要求がインテリジェントネットワークのサービス制御機能（SCF）を満たす執行システムに、PINTゲートウェイを介して、送信されるサービスである（[11]）。結果として、サービスコールの成功または失敗は、SCFが利用可能な情報であってもよいので、潜在的にPINTゲートウェイに利用できるようにすることができます。サービスが成功したかどうかの歴史的な記録の面では、大規模なSCFは時速百万のコールの試みに対処することができます。サービス取引のボリュームを考えると、それがサービス気質レコードを格納することはできませんそれを超えて有限の制限があります。ファックスが忙しい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が必要です。ほとんどの実装では、それが実行を開始していたら、それを変更するには、サービスを中断することが効率的に困難であり、二つの異なるサービスを持つことが必要になることがあり、サービスコールの終了を監視するためにGSTNリソースを設定し、1、としないもの。サービスが開始された後、監視が必要であることを決定することが可能になることはほとんどありません。
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サービスのための専用のサービスノードを提供することです。このノードは、すべてのサービスコールを置くことに関与しているとして、それは必要な情報を収集する位置にあります。しかし、それもまだサービス論理プログラムインスタンスが実行されると、コール状態変化への関心の登録に成功した対応ができない場合があります。
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.
要求側ユーザがサービス要求のステータスに関心を登録することができるもののしたがって、PINTゲートウェイはその要求を遵守する立場にないかもしれません。これは、リクエスタと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.
過去リクエストがサービスの配置で行われている場合、サービスが完了した後に逆に、これは短時間で行われるべきです。エグゼクティブシステムが長いため、サービス要求の結果を保存することはほとんどありません。これらは、エグゼクティブ・システムがそれらを維持する理由を持っていない、ので、彼らは破棄されることがあり、その後、すぐにAMA（自動メッセージ会計）レコードとして処理されています。
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ゲートウェイと執行システムが密接にリンクされている場合は、ゲートウェイは、サービスの実行中に発生し、ステータスサブスクリプション要求に応答することができます。これは、これらの要求を受け入れ、単純にさえ、それはサービスが単に最終ステータスを返し、完了したという情報を持ってまで執行システムを照会しようとしないことがあります。 PINTゲートウェイがさえ知らされていないながら、このようにPINTリクエスタは、それが監視状態であると考えている何であってもよく、
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.
要求が行われた執行システム。それが連動ステートマシンの複雑なセットを持っていますが、状態の登録と表示がI.N.と一緒に提供できることを意味し、その中でこれはPINTゲートウェイの内部の複雑さを増加しますシステム。
6.5. Parameters needed for invoking traditional GSTN Services within PINT
6.5. PINTの中に伝統的なGSTNサービスを呼び出すために必要なパラメータ
This section describes how parameters needed to specify certain traditional GSTN services can be carried within PINT requests.
このセクションでは、特定の伝統的なGSTNサービスを指定するために必要なパラメータがPINT要求の中に行うことができる方法を説明します。
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).
サービスを実行するために要求しているユーザが要求すると、彼または彼女は、もちろん、どのサービス何らかの方法で指定する必要があります。ヘッダとRequest-URI（セクション3.5.5.1を参照）：これは、へ内のURLで行うことができます。
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).
リクエスト・ツー・コールのサービスでは、彼らはまた、彼らは結果としてサービスコールに従事したいAとBの関係者を指定する必要があります。 Bパーティーが彼らの電話番号（すなわち、コールセンターのエージェントが呼び出すことが誰であるか）である一方で当事者は、例えば、彼らはコールバックをしたい、そこからコールセンターを特定することができました。
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.
リクエスト・ツー・ファックスおよびリクエスト・ツー・聞く・コンテンツサービスを指定するBパーティ（それぞれ、宛先ファックスの電話番号や発話コンテンツが配信されるべき電話）を必要とするが、当事者であります電話網ベースのリソース（どちらかファックスまたはスピーチトランスコーダ/送信者）、および暗黙的です。要求しているユーザーはいません（とすることはできません）、それを指定します。
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.
（配信されるコンテンツは、GSTN上に存在する、すなわち）リクエスト・ツー・ファックスサービス、の「ファックス・バック」変種で、彼らはまた、2人のパーティーを指定する必要があります。前述のように、Bパーティーが、彼らは、ファックスを送信する先のFAX機の電話番号です。しかしながら、この変形内Aパーティは、特定の文書が検索されるからGSTNベースのドキュメントストアの「文書の文脈では、」識別する。ここでのアナロジーはGSTNのユーザーが特定の電話番号をダイヤルしてから、「タッチトーン」の数字を使用して返される文書番号を入力することです。彼らはダイヤルの電話番号は、「タッチトーン」の数字は、その店舗内の文書を選択すると、ドキュメントストアやパーティーのことです。
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.
リクエストに余分なパラメータの観点では、サービスが再び異なります。リクエスト・ツー・コールのサービスは、AとBの関係者を必要とします。また、目的地GSTN内のエグゼクティブ・システムは、指定された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.
リクエスト・ツー・FAXとリクエスト・ツー・聞く・コンテンツサービスでは、ソース情報は、インターネット上で開催されるトランスコードします。つまり、この情報は、要求自体に沿って実施されること、又はこの情報のソースへの参照が与えられていることのいずれかを意味します。
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.
リクエスト・ツー・ファックスサービスのGSTNベースのコンテンツまたは「ファックス・バック」バリアントは、文書ストアの数と情報が伝達される上記ファックス番号を指定する必要があります。先のエグゼクティブ・システムは、その文書の店舗番号に対するアサーションと宛先ファックスのことをチェックすることができるかもしれとしてコールは、ファックスデータを運ぶだろうと主張すると便利です。
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内の意義を持っています。ドキュメントストア番号と伝票番号が一緒に一意にファックスされる実際のコンテンツを指定します。
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例えば認証または許可トークンとして、または有効期限）ことに留意されたいです。
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
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).
記載されているサービスは、リクエスト・ツー・コール（R2C）され、リクエスト・ツー・ファックス（R2F）、GSTNベースのコンテンツまたは「ファックス・バック」リクエスト・ツー・ファックス（R2FB）のバリアント、および要求-には、聞きます-content（R2HC）。
The Call Format parameter values "voice" or "fax" indicate the kind of service call that results.
コール・フォーマットパラメータ値「声」や「ファックス」の結果、サービスコールの種類を示しています。
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.
ソースインジケータ「URI / ILは、」情報は、インターネットソース参照（ユニバーサルリソース識別子、またはURI）であるか、メッセージに「インライン」実施されることを意味します。ソースインジケータは、「OR」渡された値は、メッセージの残りと共に運ばだけ先（GSTN）コンテキスト内で解釈されるべきであるしなければならない不明瞭な参照であることを意味します。別の方法として、それは「ファイル」スタイルと「ローカル」参照として与えられた、あるいは「HTTP」スタイルで部分参照を使用することができます。しかし、そのような参照が解釈される方法は、受信PINT Serverと執行システムの問題です。それは、実際には、不透明なリファレンスのまま。
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.
ソース形式値「ISF / ILSFは、」ソースのフォーマットは、URIの観点からか、「インライン」実施されていることのいずれかに指定されていることを意味します。他のすべてが失敗した場合、いくつかのデータに対して、フォーマットのいずれかが、検査によって検出された又はされ得ることに留意されたい（例えば、URLのファイル拡張子部分はデータ型を示すと仮定して）URIから推定することができます。不透明な参考のために、ソース形式は、インターネット上で利用できない、ので、与えられていません。
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が拡張」メッセージ内で運ばれるかもしれない方法を説明します。他にも選択肢があり、これらは除外されません。しかし、要求しているユーザは、彼らが期待するサービスを受けることを確保するためには、渡されたパラメータとPINT Serverとそれに付随執行システムの期待される動作のいくつかの共通の理解を持つことが必要です。
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を要素として送信することができます。したがって、PINT招待の最初の行は次の形式になります。
INVITE <serviceID>@<pint-server>.<domain> SIP/2.0
INVITE <サービスID> @ <パイントサーバー>。<ドメイン> SIP / 2.0
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.
ヘッダフィールド：リクエスト・ツー・コールおよびリクエスト・ツー・ファックスサービスの「ファックス・バック」バリアントのためのA党は「へ」で開催することができます。この場合には「：を」ヘッダ値は、Request-URIとは異なるであろう。 Aパーティが指定されていないサービスでは、「宛先：」フィールドは、Request-URIで開催された値を反復して自由です。これは、とリクエスト・ツー・聞く・コンテンツ・サービス・ファックス-への要求のためのケースです。
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パーティは、これらすべてのマイルストーンサービスに必要とされ、そして「C =」フィールドの値として、囲まSDPサブ部分に保持することができます。
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 =」フィールドの値の一部として保持することができます。このドキュメントのセクション3.4.2で説明したように、それは、「トランスポートプロトコル」要素にマッピングされます。
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」に保持されます。 「 - 」の形で使用することができる、後者は通常、リクエスト・ツー・コールまたは「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".
必要なフィールド値：ソース自体は「=のfmtp A」によって識別されます。リクエスト・ツー・コールのサービスを除き、すべての招待状は、通常、そのようなフィールドが含まれます。 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) ---
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>
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サービスID：<SIPリクエスト-URIユーザー情報> R2FB APartyは：SIP：<フィールドにSIP>：1-730-1234@p.com BParty <SDPは、C =フィールド> TN RFCxxx 441213553 CallFormat <SDP転送プロトコルサブM =フィールドのフィールド>ファックスSourceFmt：<M =フィールド> JPEGソースのM =分野>画像<SDPメディアサブタイプサブフィールドのSDPメディアタイプのサブフィールド<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>
[1] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[1]ハンドレー、M.、学生はE.、Schulzrinneと、H.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[2] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2]ハンドレー、M.およびV.ヤコブセン、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[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）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、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：メディアタイプ"、RFC 2046、1996年11月。
[5] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.
[5]ユニコードコンソーシアム、 "Unicode規格 - バージョン2.0"、アディソン・ウェズリー、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、1997年6月。
[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]呂、H.、Krishnaswamy、M.、コンロイ、L.、Bellovin氏、S.、ブルグ、F.、DeSimoneさん、A.、Tewani、K.、ダビッドソン、P.、Schulzrinneと、H.及びK. 、RFC 2458、1998年11月 - "プリPINTの実装PSTN /インターネットインターネットワーキングに向けて" Vishwanathan。
[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スタディグループXI、 - ITU-T、1994年8月 "Q.763 SS NO7のISDNユーザ部のためのフォーマットとコード"。
[9] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[10] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[10]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[11] ITU-T Study Group XI, "Q.1204 - IN Distributed Functional Plane Architecture", ITU-T, February 1994.
[11] ITU-TスタディグループXI、 "Q.1204 - 分散機能プレーンアーキテクチャでは"、ITU-T、1994年2月。
[12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[12]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[13] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[13]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、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.およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書とCRLプロファイル"、RFC 2459、1999年1月。
[15] Crocker, D. and P. Overall, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[15]クロッカー、D.、およびP.全体的に、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[16] Mills, D., "Network Time Protocol (version 3) specification and implementation", RFC 1305, March 1992.
[16]ミルズ、D.、 "ネットワークタイムプロトコル（バージョン3）仕様と実装"、RFC 1305、1992年3月。
[17] Eastlake, D., Crocker, S. and J.Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[17]イーストレイク、D.、クロッカー、S.とJ.Schiller、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[18] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[18] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
[19] Levinson, E., "The MIME Multipart/Related Content-type" RFC 2387, August 1998.
[19]レビンソン、E.、 "MIMEマルチパート/関連コンテンツ・タイプ" RFC 2387、1998年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ワーキンググループのメンバーに感謝したいです。イアン・エルツのコメントは、内部のPSTN操作の我々の理解に非常に有用でした。 SUBSCRIBEとNOTIFYリクエストは、最初のヘニングSchulzrinneとジョナサン・ローゼンバーグによって提案されました。 （すなわち、音声を受信していない）携帯電話は「保留」であることを表現するために0のオーディオポートを使用する提案がレイZibmanによるものです。最後に、彼の近くに校正用バーニーHoeneisenに感謝。
Appendix A: Collected ABNF for PINT Extensions
付録A：PINT拡張のために収集ABNF
;; --(ABNF is specified in RFC 2234 [15])
;; - （ABNFは、RFC 2234で指定されている[15]）
;; --Variations on SDP definitions
;; SDP定義の--Variations
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" / "TN"）; - 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）。 - TNAddrだけNETTYPEのコンテキストで定義==「TN」
RFC2543Addr = (INPAddr/LDPAddr)
RFC2543Addr =（INPAddr / LDPAddr）
INPAddr = "+" <POS-DIGIT> 0*(("-" <DIGIT>)/<DIGIT>) ; -- POS-DIGIT and DIGIT as defined in SDP
INPAddr = "+" <POS-DIGIT> 0 *（（ " - " <DIGIT>）/ <DIGIT>）。 - SDPで定義されるようにPOS-DIGITとDIGIT
LDPAddr = <DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
LDPAddr = <DIGIT> 0 *（（ " - " <DIGIT>）/ <DIGIT>）
OtherAddr = 1*<uric> ; -- OtherAdd defined in the context of OtherAddrType ; -- uric is as defined in RFC2396
OtherAddr = 1 * <尿>。 - OtherAdd OtherAddrTypeの文脈で定義されます。 - 尿は、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 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
メディア・フィールド= "M =" メディア<スペース>ポート<スペース>プロト1 *（<スペース> FMT）<CRLF>。 - NOTEは、オリジナルのSDP定義のサブセット/リラクゼーションとして再定義しました。 - SDPメディア=（「アプリケーション」/「オーディオ」/「画像」/「テキスト」）で定義された空間とCRLF。 - 注元のSDPの定義の一部として再定義しました。 - これは、任意のMIMEディスクリート型である可能性があります。だけに列挙したものです。 - PINT 1.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"）。 - NOTEは、オリジナルのSDP定義から再定義しました。 ; - 0「一時的にメディアなし」の通常のSDPの意味を保持します。 - （すなわち、「ラインが保留中です」）。 - （1メディアがあることを意味します）
proto = (INProto/TNProto) ; -- redefined as a superset of the original SDP definition
プロト=（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 *（<英数字>）。 - これは、IF NETTYPE ==「IN」定義「古典的な」SDPプロトコルです。 - SDP TNProto =（「音声」/「FAX」/「ページャ」）で定義されるように英数字です。 - これはPINTプロトコルであり、定義された場合NETTYPE ==「TN」
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
属性フィールド= *（ "A =" 属性リスト<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)
PINT-属性=（CLIR属性/ q763-性質属性/ q763plan属性/ q763イン属性/電話コンテキストの属性/ TSP-属性/ PINT-のfmtp属性/厳密属性）
clir-attribute = clir-tag ":" ("true" / "false")
クリア・クリア・タグ属性=「：」（「真」/「偽」）
clir-tag = "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-plan-attribute = Q763-plan-tag ":" q763-plans
q763-性質=（ "1" / "2" / "3" / "4"）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-INN属性= Q763-INN-タグ "：" q763-旅館
q763-INN-tag = "Q763-INN"
q763-INN-タグ= "Q763-INN"
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-network-prefix = "+" 1*<DIGIT>
インターナショナル・ネットワーク・プレフィックス= "+" 1 * <DIGIT>
local-network-prefix = 1*<DIGIT>
ローカル・ネットワーク・プレフィックス= 1 * <DIGIT>
private-prefix = 1*excldigandplus 0*<uric>
プライベートプレフィックス= 1 * excldigandplus 0 * <尿>
excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d)) tsp-attribute = tsp-tag "=" provider-domainname
excldigandplus =（0x21-0x2d、0x2f、0x40-0x7d））TSP-属性= TSP-タグ "=" プロバイダドメイン名
tsp-tag = "tsp"
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 PINT-のfmtp属性= "のfmtp：" で、通常の使用に対して再定義されます。<サブタイプ> <スペース>解像度*（<スペース>解像度）（<スペース> "" 1（<属性> ）*（<スペース> <属性>））; - RFC2046で定義されたサブタイプ。 ; - この値は、最終的に先行のFMTと一致する必要があります。 - メディアフィールド; - SDPで定義された属性があります
resolution = (uri-ref / opaque-ref / sub-part-ref)
解像度=（URI-REF /不透明-REF /サブ部分-REF）
uri-ref = uri-tag ":" <URI-Reference>
REFの= S-S-タグ "：" <URIリファレンス>
; -- URI-Reference defined in RFC2396
; - RFC2396で定義されたURIリファレンス
uritag = "uri"
uritag = "URI"
opaque-ref = opr-tag ":" 0*<uric>
不透明-REF = OPR-タグ "：" 0 * <尿>
opr-tag = "opr"
OPR-タグ= "OPR"
sub-part-ref = spr-tag ":" <Content-ID> ; -- Content-ID is as defined in RFC2046 and RFC822
サブ部分REF = SPRタグ「：」<コンテンツID>。 - RFC2046とRFC822で定義されているようにContent-IDがあります
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
タグリスト= 1（PINT-にタグリスト/ <フィールド> /パイントのfmtpタグリスト）*（ ""（PINT-にタグリスト/ <フィールド> /パイントのfmtp-タグリスト））; - フィールドは、SDPで定義されています
PINT-att-tag-list = (phone-context-tag / clir-tag / q763-nature-tag / q763-plan-tag / q763-INN-tag)
PINT-ATT TAG-リスト=（電話マーカー日/ CLIR日/ q763-性質日/ q763-SMB-日/ q763イン日）
pint-fmtp-tag-list = (uri-tag / opr-tag / spr-tag)
パイントのfmtpタグリスト=（URI-日/ OPR-日/ SPR-タグ）
;; --Variations on SIP definitions
;; SIP定義の--Variations
clir-parameter = clir-tag "=" ("true" / "false")
クリア・クリア-tagパラメータ= "="（ "真" / "偽"）
q763-nature-parameter = Q763-nature-tag "=" Q763-natures
q763-自然パラメータ= Q763-自然-タグ "=" Q763-性質
q763plan-parameter = Q763-plan-tag "=" q763plans
q763planパラメータ= Q763-PLAN-タグ "=" q763plans
q763-INN-parameter = Q763-INN-tag "=" q763-INNs
q763インパラメータ= Q763インタグ "=" q763-イン
tsp-parameter = tsp-tag "=" provider-domainname
TSP-パラメータ= TSP-タグ "=" プロバイダードメイン名
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
SIP-PARAM =（<トランスポートPARAM> / <ユーザPARAM> / <方法-PARAM> / <TTL-PARAM> / <MADDR-PARAM> / <その他-PARAM>）。 - このリストの値は、すべてのSIPで定義されている通り
PINT-param = ( clir-parameter / q763-nature-parameter /
パイントPARAM =（クリアパラメータ/ q763-自然パラメータ/
q763plan-parameter / q763-INN-parameter/
tsp-parameter / phone-context-parameter )
URL-parameter = (SIP-param / PINT-param) ; -- redefined SIP's URL-parameter to include ones defined in PINT
URLパラメータ=（SIP-PARAM / PINT-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拡張に使用される識別子の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.
* Media形式のサブタイプは、この文書のセクション3.4.2で説明したように。セクション3.4.3.1で説明したようにセクション3.4.3で述べたように*プライベート属性*プライベート電話のコンテキスト値、。
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.
彼らがX-トークンの形態でなければならないよう（セクション3.4.1で）プライベートアドレスのタイプを明示的に、このプロセスから除外されていることに留意すべきです。
B.1. Media Format Sub-types
B.1。 Media形式のサブタイプ
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.
今度はこれらを取って、メディアフォーマットのサブタイプは、データソースの定義を保持する属性の行を指定するには、SDPにPINT拡張内で使用されています。通常の使用では、このフィールドの値は、MIME離散型のサブタイプがある[4]。 IANAに登録サブタイプ以外の値が使用される場合、それはX-トークンでなければならないのいずれか（すなわち、「X-」で始まる）、または、それは、IANAに登録されなければなりません。意図は、新しいMIMEサブタイプを記述する場合、その後RFC 2048で指定された手順が使用されるべきです。どんな新しいMIMEサブタイプがこの文書で定義された関連するPINTののfmtpラインの解釈のための構文規則に従ってしまうことが想定されます。
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".
SDP記述に合わせて、そのような登録は、それらが定義されている内に、「プロト」フィールド値を含むべきである、ということに注意してください。しかし、彼らが「TNProtoのすべての値」で使用できる唯一のように指定することが適切です。
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内のデータソース定義を含む新しい方法を定義することである場合は逆に、そのような新しい「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のデフォルトを次の場合、（新規登録が必要とされるであろう、なぜこのような場合には、それは不明である、が）ここで与えられた構文定義を繰り返すのではなく、定義文書でこれを言及するのに十分です。前述のように、メディアフォーマットのサブタイプは、それが定義されている中に「プロト」フィールドの値を指定する必要がありますが、これは「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内で使用するために定義されている場合、サポートドキュメントでこれを言及することが適切であろう。句：ここでは取り上げPINT 1.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に登録することができます。そのような接頭辞は、潜在的に関連する数値ID（セクション3.4.3.1例4を参照）と、プライベートネットワークを識別するのに有用であり得ます。例では、プレフィックスは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 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).
必要に応じて数字の文字列、または他のトークンが続くドメイン名を含むトークンの一般的な形式を、持っている任意のプライベートコンテキストを登録することをお勧めします。初期トークン名前空間の適切な形態は、サブタイプ（例えばvnd.acme.com）のためにプライベートまたはベンダーの登録のために使用されるものと同様であろう。ただし、登録は、顧客のプライベートネットワーク番号計画の形式を指定するために使用されるのではなく、自社の機器ベンダーの顧客のすべてのために一般的に使用されていることに注意してください。したがって、fbi.govは適切であろうが、（プライベートネットワークは内部ルーセントによって使用されることもしていた場合を除き）lucent.comないでしょう。
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:
具体的には、登録要求が含まれている必要があります
* 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.
*登録の種類（つまり、プライベート電話コンテキスト属性は、PINTサービス要求のサービスの説明の中で使用される）*登録要求（名前、組織、電子メールアドレス、公衆電話番号）*民間の責任者のための連絡先の詳細プレフィックス最初のトークン名（例えばvnd.fbi.gov）*プライベートコンテキストの構文（例えば「vnd.fbi.gov」<スペース> 1 * DIGIT、または「vnd.gtn.gov.uk」）*使用の説明（たとえば、 「この電話コンテキストは、 『政府の電気通信ネットワーク』内にあるように関連付けられている電話番号を宣言します。数は、内部またはプライベート番号計画の形式である）*ネットワークタイプと、このプライベートコンテキストが関連付けられているアドレスタイプ;場合は 『』ノーマル電話タイプ（この文書で指定されるように）、値は次のように示されるであろう、使用されている：「NETTYPE = TN」、ADDRTYPE =「RFC2543Addr」、しかし、このコンテキストが別のアドレス・タイプで使用された場合には、参照そのアドレスタイプ名とそのアドレス値の構文にrequiがあることでしょう赤。
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ワーキンググループに要求された登録を参照して、登録が受理される前に修正が行われるために必要な場合があります。
Authors' Addresses
著者のアドレス
Scott Petrack MetaTel, Inc. 45 Rumford Ave. Waltham MA 02453-3844
スコット2000 PetrackとMetaTel社45ランフォードアベニュー。ウォルサムMA 02453-3844
Phone: +1 (781)-891-9000 EMail: scott.petrack@metatel.com
電話：+1（781）-891-9000 Eメール：scott.petrack@metatel.com
Lawrence Conroy Siemens Roke Manor Research Roke Manor Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN
ローレンスコンロイシーメンスRokeマナー研究Rokeマナーオールド・ソールズベリーレーンロムジー、ハンプシャーU.K. SO51 0ZN
Phone: +44 (1794) 833666 EMail: lwc@roke.co.uk
電話：+44（1794）833666 Eメール：lwc@roke.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。