[要約] RFC 2848は、SIPとSDPを拡張して、IP経由で電話通話サービスにアクセスするためのPINTサービスプロトコルについて説明しています。このRFCの目的は、IPネットワーク上での電話通話サービスの実現と相互運用性の向上です。
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.
Copyright（c）The Internet Society（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):
インターネットから特定の電話サービスを呼び出すという欲求は、多くの異なるグループ（ユーザー、パブリックおよびプライベートネットワークオペレーター、コールセンターサービスプロバイダー、機器ベンダーなどを参照）によって特定されています。一般的なシナリオは次のとおりです（呼び出しが成功した場合）：
1. an IP host sends a request to a server on an IP network; 2. the server relays the request into a telephone network; 3. the telephone network performs the requested call service.
1. IPホストは、IPネットワーク上のサーバーにリクエストを送信します。2.サーバーは、リクエストを電話ネットワークにリレーします。3.電話ネットワークは、要求されたコールサービスを実行します。
As examples, consider a user who wishes to have a callback placed to his/her telephone. It may be that a customer wants someone in the support department of some business to call them back. Similarly, a user may want to hear some announcement of a weather warning sent from a remote automatic weather service in the event of a storm.
たとえば、電話にコールバックを配置したいユーザーを検討してください。顧客は、一部のビジネスのサポート部門の誰かに電話をかけることを望んでいる可能性があります。同様に、ユーザーは、嵐が発生した場合にリモートの自動気象サービスから送信された天気警告の発表を聞きたい場合があります。
We use the term "PSTN/Internet Interworking (PINT) Service" to denote such a complete transaction, starting with the sending of a request from an IP client and including the telephone call itself. PINT services are distinguished by the fact that they always involve two separate networks:
「PSTN/Internet Interworking（PINT）サービス」という用語を使用して、IPクライアントからのリクエストの送信から始まり、電話自体を含むような完全なトランザクションを示します。パイントサービスは、常に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をすべて使用してパイントサービスを提供できることが理解されています。また、サービスのリクエストは、インターネット全体から切断されたプライベート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.
パイントプロトコルの要件は、少数の固定電話サービスを呼び出す能力を提供することに意図的に制限されていました。これらの「マイルストーンパイントサービス」はセクション2で指定されています。ただし、可能な限り他のインターネットプロトコルと整合するプロトコルを開発するために、パイントへの将来の拡張がインターネット会議とともに開発できるように、細心の注意が払われています。
Within the Internet conference architecture, establishing media calls is done via a combination of protocols. SIP [1] is used to establish the association between the participants within the call (this association between participants within the call is called a "session"), and SDP [2] is used to describe the media to be exchanged within the session. The PINT protocol uses these two protocols together, providing some extensions and enhancements to enable SIP clients and servers to become PINT clients and servers.
インターネット会議アーキテクチャ内では、メディアコールの確立は、プロトコルの組み合わせを介して行われます。SIP [1]は、コール内の参加者間の関連を確立するために使用されます（コール内の参加者間のこの関連は「セッション」と呼ばれます）、SDP [2]はセッション内で交換されるメディアを記述するために使用されます。PINTプロトコルでは、これら2つのプロトコルを使用して、SIPクライアントとサーバーがパイントクライアントとサーバーになることを可能にするためのいくつかの拡張機能と拡張機能を提供します。
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.
電話ネットワーク内でサービスを呼び出したいパイントユーザーは、SIPを使用してリモートパイントサーバーをセッションに招待します。招待状には、ユーザーが実施したいメディアセッションのSDP説明が含まれています。これは、たとえば「FAXセッションの送信」または「電話セッション」などです。パイントサービスの実行セッションでは、メディアは電話システムを介して輸送されますが、SIPセッションではメディアは通常インターネット上で輸送されます。
When used to invoke a PINT service, SIP establishes an association between a requesting PINT client and the PINT server that is responsible for invoking the service within the telephone network. These two entities are not the same entities as the telephone network entities involved in the telephone network service. The SIP messages carry within their SDP payloads a description of the telephone network media session.
パイントサービスを呼び出すために使用される場合、SIPは、電話ネットワーク内のサービスを呼び出す責任を負う要求パイントクライアントとパイントサーバーとの間の関連を確立します。これらの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).
パイントサーバーが招待状とセッションが確立されるという事実は、メディアが正常に輸送されるという保証ではないことに注意してください。（これは、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.
パイントユーザーの特定の要件は、いくつかの新しいメッセージにつながります。パイントサーバーがFAXを電話Bに送信することに同意すると、FAXの一部が送信された後にFAXの送信が失敗する可能性があります。したがって、パイントクライアントは、確立されたパイントセッションの結果として呼び出された実際の電話セッションのステータスに関する情報を受け取ることをお勧めします。これを許可するために、サブスクライブ、サブスクライブ、および通知の3つの新しいリクエストがここにバニラ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の動作を何らかの形で変更することを意図していません。パイント拡張の目的は、通常の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では、マイルストーンサービスのパイントについて説明します。セクション3は、パイント機能およびプロトコルアーキテクチャを指定します。セクション4では、SIPおよびSDPの1.0拡張機能の例を示します。セクション5には、パイントのセキュリティ上の考慮事項が含まれています。最後のセクションには、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.
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 Client - An Internet host that sends requests for invocation of a PINT Service, in accordance with this document.
PINTクライアント - このドキュメントに従って、パイントサービスの呼び出しのリクエストを送信するインターネットホスト。
PINT Gateway - An Internet host that accepts requests for PINT Service and dispatches them onwards towards a telephone network.
パイントゲートウェイ - パイントサービスのリクエストを受け入れ、電話ネットワークに向かってそれらを派遣するインターネットホスト。
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サーバーで表されます。
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).
（サービスコール）当事者 - パイントサービスリクエストの実行に起因する電話ネットワークコール、または関与する電話ネットワークベースのリソース（自動ファックス送信者やテキストツーテキストなど音声ユニット）。
The original motivation for defining this protocol was the desire to invoke the following three telephone network services from within an IP network:
このプロトコルを定義するための元の動機は、IPネットワーク内から次の3つの電話ネットワークサービスを呼び出したいという願望でした。
A request is sent from an IP host that causes a phone call to be made, connecting party A to some remote party B.
電話が行われるIPホストからリクエストが送信され、パーティーAをリモートパーティBに接続します。
A request is sent from an IP host that causes a fax to be sent to fax machine B. The request MAY contain a pointer to the fax data (that could reside in the IP network or in the Telephone Network), OR the fax data itself. The content of the fax MAY be text OR some other more general image data. The details of the fax transmission are not accessible to the IP network, but remain entirely within the telephone network.
ファックスをファックスマシンBに送信するIPホストからリクエストが送信されます。リクエストには、ファックスデータ（IPネットワークまたは電話ネットワークに存在する可能性がある）またはFAXデータ自体へのポインターが含まれている場合があります。。FAXのコンテンツは、テキストまたは他のより一般的な画像データである場合があります。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上のFAX」に関連していないことに注意してください。IPネットワークは、特定のFAXを送信するリクエストを送信するためにのみ使用されます。もちろん、結果の電話ネットワークファックスコールがリアルタイムIP Faxソリューションを使用する可能性がありますが、これはパイントトランザクションに対して完全に透明です。
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にパイントリクエストが渡されるボタンがあり、その結果、ページ（またはその他の詳細）の内容が人に話されます。
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.
パイントリクエストによって呼び出される各電話サービスには、さまざまなバージョンとバリエーションがあります。ユーザーが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.
同様に、パイントリクエストがFAXを送信すると、数百のFAXプロトコルの詳細が交渉されるだけでなく、使用される電話ネットワーク内の送信の詳細があります。
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).
パイントリクエストでは、正確な電話側のサービスをあまり正確に指定していません。リクエストを実行する電話ネットワーク内の個々のイベントの運用の詳細は、パイントの範囲外です。これは、電話ネットワークセッションの特定の高レベルの詳細をパイントリクエスト内で表現することを妨げるものではありません。たとえば、SDP "Lang"属性を使用して、リクエストからハイアーテントサービスの言語の好みを表現することができます。特定のパイントシステムで、リクエストが電話ネットワークサイドサービスの詳細を含めることを許可したい場合、SDP属性メカニズムを使用します（セクション3.4.2を参照）。
Familiarity is assumed with SIP 2.0 [1] and with SDP [2].
SIP 2.0 [1]およびSDP [2]で親しみやすさが想定されています。
PINT clients and servers are SIP clients and servers. SIP is used to carry the request over the IP network to the correct PINT server in a secure and reliable manner, and SDP is used to describe the telephone network session that is to be invoked or whose status is to be returned.
パイントクライアントとサーバーは、SIPクライアントとサーバーです。SIPは、IPネットワーク上のリクエストを安全で信頼できる方法で正しいPintサーバーに携帯するために使用され、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.
パイントシステムは、SIPプロキシサーバーとリダイレクトサーバーを通常の目的で使用しますが、ある時点で、受信した要求を電話システムに中継し、これらのリレーリクエストの承認を受け取る手段を備えたパイントサーバーが必要です。この機能を備えたパイントサーバーは、「パイントゲートウェイ」と呼ばれます。パイントゲートウェイは、ユーザーエージェントサーバーとしてSIPシステムに表示されます。パイントゲートウェイは「ユーザー」を表すかのようにパイントインフラストラクチャに表示されますが、実際には、一連の電話ネットワークサービスを提供できる電話ネットワークインフラストラクチャ全体を実際に表しています。
So the PINT system might appear to an individual PINT client as follows:
したがって、パイントシステムは、次のように個々のパイントクライアントに表示される場合があります。
/\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\
___________ \ __/___ ___\_ \
| PINT | PINT \ PINT | PINT | |Exec| Telephone /
| client |<-------------->| server |gatewy|=====|Syst| Network \
|_________| protocol / cloud |______| |____| Cloud /
\ \ / \
/\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/
Figure 1: PINT Functional Architecture
図1：パイント機能アーキテクチャ
The system of PINT servers is represented as a cloud to emphasise that a single PINT request might pass through a series of location servers, proxy servers, and redirect servers, before finally reaching the correct PINT gateway that can actually process the request by passing it to the Telephone Network Cloud.
パイントサーバーのシステムは、単一のパイントリクエストが一連のロケーションサーバー、プロキシサーバー、およびリダイレクトサーバーを通過する可能性があることを強調するクラウドとして表され、最終的にそれを渡すことでリクエストを実際に処理できる正しいパイントゲートウェイに到達します電話ネットワーククラウド。
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.
パイントゲートウェイには、真の電話ネットワークインターフェイスがあるか、他のプロトコルまたは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。（インテリジェントネットワーク）システム、パイントゲートウェイは、サービスコントロールゲートウェイ機能を実現するように見える場合があります。オフィス環境では、オフィスLANとオフィスPBXの両方に接続されたオフィスPBXに付属するサーバーである可能性があります。
The Executive System that lies beyond the PINT gateway is outside the scope of 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 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.
1) SDP連絡先のテレフォニーURL 2）SIP/SDPテレフォニーURLの改良 *プライベートダイヤルプランの包含GSTN内のメディアの処理を示す輸送形式Q.763引数のプレゼンテーション制限表示 *フレームワーク8）SDPの拡張メカニズムは、「必要」ヘッダーを使用して、受信者が指定された拡張機能をサポートしていない場合に狭窄と強制障害を指定するための拡張メカニズム。9）「警告」ヘッダーに対する必須のサポートは、リクエスト処分に基づいてより詳細な情報を提供します。10）要求されたサービスの処分に関心を登録するメカニズム、およびその処分に関する兆候を受け取る。
Both PINT and SIP rely on features of MIME[4]. The use of SIP 2.0 is implied by PINT 1.0, and this also implies compliance with version 1.0 of MIME.
パイントと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で発生することを望んでいる特定の電話ネットワークセッションの説明が含まれています。この情報には、通話に関与する端末の電話ネットワークアドレス（つまり、「電話番号」）、輸送されるメディアタイプの指標（オーディオ、テキスト、画像、またはアプリケーションデータなど）などが含まれます。情報が音声、ファックス、またはポケットベルの輸送を介して電話ネットワーク上で輸送されるかどうかの兆候です。リモート電話端末に送信されるコンテンツの兆候（ある場合）も含まれています。
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.
以下は、PINT 1.0の拡張機能とSDPへの追加のリストです。
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）e。クライアントがサーバーでサポートする必要があることを示すためにクライアントが使用する新しい属性タグ「要求」（セクション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は、パイントクライアントからパイントゲートウェイへの電話サービスのリクエストを携帯するために使用され、特定のサービスに必要な場合は電話番号を含めることができます。以下は、パイントの強化とSIPの追加の完全なリストです。
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。購読して通知し、リクエストを登録解除（セクション3.5.3）i。要求：ヘッダー（セクション3.5.4）j。パイントリクエスト内のパイントURLの形式（セクション3.5.5）k。パイント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には、バイリクエストがパイント内でどのように使用されるかについての発言が含まれています。これは、ベースライン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.
これらのうち、TNネットワークタイプ（関連するRFC2543アドレスタイプ）と「要求」属性のみが、PINT 1.0クライアントとサーバーでサポートする必要があります。実際には、ほとんどのパイントサービスリクエストは他の変更を使用します。この変更は、リクエストのデータオブジェクトへの参照がパイントリクエストに表示される可能性が最も高いです。
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.
他の新しいパイントコンストラクトはそれぞれ異なる機能を有効にし、特定の関数を有効にしたいクライアントまたはサーバーが、このドキュメントで指定されたコンストラクトによってそうする必要があります。たとえば、他のマイルストーンサービスをサポートせずに、コールまでの電話サービスのみを提供するパイントクライアントとサーバーを構築することが許可されています。
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ヘッダーと「必要」属性を提供し、クライアントとサーバーが使用するメカニズムを提供し、特定の「新しい」パイントプロトコル要素をサポートする能力を示します。
It should be noted that many optional features of SIP and SDP make sense as specified in the PINT context. One example is the SDP a=lang: attribute, which can be used to describe the preferred language of the callee. Another example is the use of the "t=" parameter to indicate that the time at which the PINT service is to be invoked. This is the normal use of the "t=" field. A third example is the quality attributes. Any SIP or SDP option or facility is available to PINT clients and servers without change.
SIPとSDPの多くのオプションの機能は、パイントコンテキストで指定されているように意味があることに注意してください。1つの例は、SDP a = lang：属性です。これは、Calleeの好ましい言語を記述するために使用できます。別の例は、「t =」パラメーターを使用して、パイントサービスが呼び出される時間を示すことです。これは、「t =」フィールドの通常の使用です。3番目の例は、品質属性です。SIPまたはSDPオプションまたは機能は、変更せずにクライアントとサーバーをパイントすることができます。
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.
逆に、Internet Conferenceセッション内のデータオブジェクトのサポートは、GSTNサービスリクエストを提供しないことを目的としていても、有用かもしれません。この場合、これらのアイテムをカバーする拡張機能は、それ以外の場合は「プレーン」SIP/SDP招待状に組み込まれる場合があります。同様に、「従来の」SIP/SDPインフラストラクチャに機能を追加するためのフレームワークとして、SDPの「要求」のサポートは有用かもしれません。繰り返しますが、これらはパイントサービスリクエストには使用されない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.
パイント1.0は、SDPにオーディオ、ファックス、ポケットベルの電話セッションを説明する可能性を追加します。それは、電話ネットワークの基礎となる技術的な詳細と複雑さを隠すために意図的に設計されています。パイント用に定義されている唯一のネットワークタイプは、一般的な「TN」（電話ネットワーク）です。「ISDN」、「GSM」などのより正確なタグは定義されていません。同様に、トランスポートプロトコルは、単に「ファックス」、「音声」、および「ページャー」として指定されています。さまざまな電話ネットワークの音声、FAX、またはポケットベルのプロトコルの具体的な識別子はもうありません。同様に、輸送されるデータは、「テキスト」データ、イメージ「データ」、またはより一般的な「アプリケーション」データなどの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 [1]の図4に指定された「電話担当者」BNFのサブセットに準拠する文字列が続きます。この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番号計画アドレスとして解釈されるようになりますが、ローカルフォン番号は、デフォルトのダイヤルプランで指定された番号であり、受信者パイントゲートウェイ。
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」がこの形式の数字です。このような形式は、付録AのABNFの「その他のadddr」として定義されます。ほとんどのダイヤル可能な電話番号は、アドレスRFC2543内のローカルフォン数として表現可能であることに注意してください。新しいアドレスタイプは、そのように書くことができないフォーマットにのみ使用する必要があります。
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.
パイントを使用した従来のSIP/SDPインターネット会議セッションに対する重要な変更の1つは、パイントサービスリクエストがその要求でソース情報として使用されるデータオブジェクトを参照する可能性があることです。たとえば、パイントサービスリクエストは、FAXが送信される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を使用するために、そのようなメディアセッションを「そのような画像がFAXとして送信される特定の番号への電話」を説明する必要があります。
To support this, two extensions to the session description format are specified. These are some new allowed values for the Media Field, and a description of the "fmtp" parameter when used with the Media Field values (within the context of the Contact Field Network type "TN").
これをサポートするために、セッション説明形式への2つの拡張機能が指定されています。これらは、メディアフィールドのいくつかの新しい許可された値であり、メディアフィールド値で使用される場合の「FMTP」パラメーターの説明（連絡先ネットワークタイプ「TN」のコンテキスト内）。
An addition is also made to the SIP message format to allow the inclusion of data objects as sub-parts within the request message itself. The original SDP syntax (from [2]) for media-field is given as:
また、SIPメッセージ形式に追加され、データオブジェクトをリクエストメッセージ自体にサブパートとして含めることができます。メディアフィールドの元のSDP構文（[2]から）は次のように与えられています。
media-field = "m=" media space port ["/" integer] space proto 1*(space fmt) CRLF
Media-field = "M =" Media Space Port ["/" Integer] Space Proto 1*（Space 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.
パイントリクエスト内で使用すると、サブフィールドの定義がわずかに拡張されます。メディアサブフィールドの定義は、[4]で定義されているすべての個別の「トップレベルの」メディアタイプを受け入れるためにリラックスしています。マイルストーンサービスでは、個別のタイプの「ビデオ」は使用されず、追加のタイプ「データ」と「コントロール」も同様に必要ありません。これらのタイプの使用は排除されていませんが、そのようなタイプを含むリクエストを受信するパイントゲートウェイに期待される動作は、ここでは定義されていません。
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.
ポートサブフィールドには、宛先端末が「TN」アドレス指定を使用して指定されているため、パイントリクエストには意味がありません。したがって、パイントリクエストのポートサブフィールドの値は通常「1」に設定されます。ターミナルがメディアを受信していないことを示すために、SDPのように「0」の値を使用できます。これは、電話端末が一時的に「保留」していることを示すのに役立ちます。同様に、オプションの整数サブフィールドはパイントでは使用されません。
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]で述べたように、トランスポートプロトコルサブフィールドは、関連するアドレスタイプに固有です。先行導入コンタクトフィールドのアドレスタイプがネットワークタイプ「TN」で使用するために定義されている場合の1つである場合、トランスポートプロトコルサブフィールドに対して次の値が定義されています。
"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.
パイントリクエスト内のこのサブフィールドの解釈は、結果として生じるGSTNサービスの処理または処分です。したがって、トランスポートプロトコルの「音声」の場合、サービスはGSTNボイスコールになり、プロトコル「FAX」が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".
このサブフィールドは、ソースデータのメディアタイプとサブタイプを必ずしも指示しているわけではないことに注意してください。たとえば、マイルストーンサービスの1つは、テキストソースが結果の電話サービスコールでボコードされ、話されることを求めています。この場合の輸送プロトコル値は「音声」であり、メディアタイプは「テキスト」になります。
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]で輸送プロトコル固有であると説明されています。上記のプロトコル値のいずれかを持つPINTリクエスト内で使用する場合、このサブフィールドは1つ以上の値のリストで構成され、それぞれが関連するメディアサブフィールド値の定義されたMIMEサブタイプです。特別な値「 - 」は許可されています。つまり、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-Token>、つまり「X-」で始まる文字文字列として指定される場合があります。そのような値の使用は落胆し、そのような値が一般的な使用を見つけると予想される場合、標準のコンテンツタイプ登録プロセスを使用してIANAに登録する必要があります（付録Cを参照）。
When the Fmt parameter is the single character "-" ( a dash ), this is interpreted as meaning that a unspecified or default sub-type can be used for this service. Thus, the media field value "m=audio 1 voice -<CRLF>" is taken to mean that a voice call is requested, using whatever audio sub type is deemed appropriate by the Executive System. PINT service is a special case, in that the request comes from the IP network but the service call is provided within the GSTN. Thus the service request will not normally be able to define the particular codec used for the resulting GSTN service call. If such an intent IS required, then the quality attribute may be used (see "Suggested Attributes" section of [2]).
FMTパラメーターが単一の文字「 - 」（ダッシュ）である場合、これはこのサービスに不特定またはデフォルトのサブタイプを使用できることを意味します。したがって、メディアフィールド値「M = Audio 1 Voice - <CRLF>」は、エグゼクティブシステムによって適切と見なされるオーディオサブタイプを使用して、音声コールが要求されることを意味すると見なされます。リクエストはIPネットワークからのものであるが、サービスコールがGSTN内で提供されるという点で、パイントサービスは特別なケースです。したがって、サービス要求は通常、結果の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 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.
パイントサービスで使用するために、そのようなセットの要素はシーケンスとして送信されることに注意する必要があります。それらを並行して送ろうとすることが成功する可能性は低いです。
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属性には、異なる種類の要素の混合物を含めることができます。したがって、属性には、現在のメッセージのサブパートに保持されているデータを示すサブパート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ネットワーク上に他の場所に保存されているデータオブジェクトをパイントサービス内で処理するためのソースとして使用する場合、URI-REFフォームの使用と呼ばれる場合があります。これは、[9]で説明されているように、単に均一なリソース識別子（URI）です。
Note that the reference SHOULD be an absolute URI, as there may not be enough contextual information for the recipient server to resolve a relative reference; any use of relative references requires some private agreement between the sender and recipient of the message, and SHOULD be avoided unless the sender can be sure that the recipient is the one intended and the reference is unambiguous in context.
レシピエントサーバーが相対的な参照を解決するのに十分なコンテキスト情報がない可能性があるため、参照は絶対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.
また、これは、メッセージの最終的な受信者のコンテキストでこれらを解決する必要があるため、部分的なuris（「uri：http：http：//anode/index.htm」など）にも当てはまります。
The general syntax of a reference to an Internet-based external data object in a fmtp line within a PINT session description is:
パイントセッションの説明内のFMTP行のインターネットベースの外部データオブジェクトへの参照の一般的な構文は次のとおりです。
<uri-ref> := ("uri:" URI-reference)
where URI-reference is as defined in Appendix A of [9] For example:
場合、URI-Referenceは[9]の付録Aで定義されています。
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
means get this data object from the Internet and use it as a source for the requested GSTN Fax service.
このデータオブジェクトをインターネットから取得し、要求されたGSTN FAXサービスのソースとして使用します。
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.
パイントサービスは、IPネットワークではなくGSTN内で保持されているデータを指す場合があります。これらのアイテムが示される方法は、要求者またはパイントゲートウェイのコンテキスト内で意味を持たない必要はありません。参照は、エグゼクティブシステムが使用して、リクエストの一部として意図されたコンテンツを示すために使用できるデータにすぎません。これらのデータは、パイントインフラストラクチャを通じて「触れられていない」と送信されるという点で、不透明な参照を形成します。
A reference to some data object held on the GSTN has the general definition:
GSTNに保持されている一部のデータオブジェクトへの参照には、一般的な定義があります。
<opaque-ref> := ("opr:" *uric)
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にインデックス付けされたデータを送信します。エグゼクティブシステムは、データオブジェクトの控除に使用されるコンテキストを決定する際に、囲まれたSIPメッセージのフィールドに保持されている電話URLを取得することもできます。
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に保持されているドキュメントへのアクセスを承認するために必要になる可能性があります。ただし、不透明な参照が配置される目的は、このドキュメントの範囲外です。これは、パイントリクエスト内で運ばれる単なる指標です。
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.
不透明な参照は、使用する値が残りのリクエストで暗黙的である場合に価値がない場合があります。たとえば、一部の企業がパイントを使用して「ファックスバックサービス」を実装したいとします。現在の実装では、ファックスされる画像は、ダイヤルされた電話番号によって完全に定義されています。パイントリクエスト内では、この電話番号は「to」のフィールドのフィールド内に表示されるため、不透明な参照値は必要ありません。
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.
パイントサービスリクエストにいくつかの解像度があり、そのうちの1つが値のない不透明なリファレンスである場合、その不透明な参照は属性行に含める必要がありますが、空の値フィールドを使用する必要があります。
For example:
例えば：
c= TN RFC2543 +1-201-406-4090 m= text 1 fax plain a=fmtp:plain uri:http://www.sun.com/index.html opr:
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.
不透明な参照がパイントサービスリクエストの唯一の解像度であり、その参照は価値がない場合、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に保存されている暗黙のコンテンツがあり、これがSIP To-URIとセッション説明の接触フィールドの組み合わせによって一意に識別されることを意味します。
As an alternative to pointing to the data via a URI or an opaque reference to a data item held on the GSTN, it is possible to include the content data within the SIP request itself. This is done by using multipart MIME for the SIP payload. The first MIME part contains the SDP description of the telephone network session to be executed. The other MIME parts contain the content data to be transported.
GSTNに保持されているデータ項目へのURIまたは不透明な参照を介してデータを指す代わりに、SIP要求自体にコンテンツデータを含めることができます。これは、SIPペイロードにマルチパートMIMEを使用して行われます。最初のMIME部品には、実行される電話ネットワークセッションのSDP説明が含まれています。他のMIME部品には、輸送するコンテンツデータが含まれています。
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)
where Content-ID is as defined in Appendix A of [3] and in [10]).
Content-IDは、[3]および[10]の付録Aで定義されています。
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.
<content-id>パラメーターは、メッセージ内のmimeパーツの1つのコンテンツIDであり、このフラグメントは、要求ユーザーがこのメッセージのサブパートに保持されているデータオブジェクトを<content-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.
「電話ネットワーククラウド」の一部のエンティティによってのみ理解できるパイントリクエストサービスパラメーターに含めることが望まれる場合があります。SDP属性パラメーターは、この目的に使用されます。特定のメディアの説明内またはメディアの説明の外に表示される場合があります。
These attributes may also appear as parameters within PINT URLS (see section 3.5.6) as part of a SIP request.
これらの属性は、SIPリクエストの一部として、PINT URL内のパラメーターとして表示される場合があります（セクション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.
これは、属性を定義する必要がある電話端子が、次のように、パイントリクエストの行およびパイントセッションの説明内に表示できるようにするために必要です。
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. 電話番号は、さまざまな方法で到達できる可能性があります（競合する電話サービスプロバイダーなど）。パイントクライアントは、サービスプロバイダーの選択を示したいと考えています。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は、from：from：headers and/or 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）および「require：org.ietf.sdp.require」ヘッダーと併用する必要があります（セクション」3.5.4）。
It is not possible to standardise every possible internal telephone network parameter. PINT 1.0 attributes have been chosen for specification because they are common enough that many different PINT systems will want to use them, and therefore interoperability will be increased by having a single specification.
可能なすべての内部電話ネットワークパラメーターを標準化することはできません。多くの異なるパイントシステムがそれらを使用したいほど十分に一般的であるため、パイント1.0属性が仕様に選択されているため、単一の仕様を持つことで相互運用性が向上します。
Proprietary attribute "a=" lines, that by definition are not interoperable, may be nonetheless useful when it is necessary to transport some proprietary internal telephone network variables over the IP network, for example to identify the order in which service call legs are to be be made. These private attributes SHOULD BE, however, subject to the same IANA registration procedures mentioned in the SDP specification[2] (see also this Appendix C).
独自の属性 "a ="行は、定義上、相互運用不可能であることにもかかわらず、IPネットワーク上に独自の内部電話ネットワーク変数を輸送する必要がある場合に役立つ場合があります。作られます。ただし、これらのプライベート属性は、SDP仕様[2]に記載されている同じIANA登録手順の対象となる必要があります（この付録Cも参照）。
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.
「リモートローカルダイヤル」を有効にするために属性が指定されています。これは、パイントクライアントが通常数に到達できるエリアまたはネットワークのはるか外側から数字に到達できるようにするサービスです。送信または受信アドレスが、パイントクライアントの起源にremote延する可能性のあるローカルコンテキスト内でのみダイヤル可能である場合に役立ちます。
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.
たとえば、アリスが電話で問題を報告したい場合、彼女は「ネットワークワイド」のカスタマーケア番号をダイヤルする可能性があります。英国の英国通信ネットワーク内では、これは「152」です。この場合、彼女はトランクのプレフィックスをダイヤルしないことに注意してください - これはダイヤル数全体です。別のオペレーターのネットワークからダイヤルされた場合、British Telecom's Engineering Inquiries Servicesに接続しません。「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:
電話ネットワーク内では、「ローカルコンテキスト」は、サブスクライバーの端末と中央オフィスの間の物理的な接続によって提供されます。最初にリクエストを受信したパイントクライアントとパイントサーバーとの類似の関連付けは、この不足している「電話ネットワークのコンテキスト」を提供する必要がある理由です。この属性は次のように定義されます。
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
An intl-network-prefix and local-network-prefix MUST be a bona fide network prefix, and a network-prefix that is an intl-network-prefix MUST begin with an E.164 service code ("country code").
intl-network-prefixとlocal-network-prefixは真正なネットワークのプレフィックスである必要があり、intl-network-prefixであるネットワークプレフィックスは、e.164サービスコード（「国コード」）で開始する必要があります。
It is possible to register new private-prefixes with IANA so as to avoid collisions. Prefixes that are not so registered MUST begin with an "X-" to indicate their private, non-standard nature (see Appendix C).
衝突を避けるために、新しいプライベートプレフィックスをIANAに登録することが可能です。そのように登録されていないプレフィックスは、私的で標準以外の性質を示すために「x-」から始めなければなりません（付録Cを参照）。
Example 1:
例1：
c= TN RFC2543 1-800-765-4321
a=phone-context:+972
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がイスラエルの携帯電話プロバイダーの1つを定義し、123がそのネットワーク内でダイヤルされたときにカスタマーサービスに到達することがあります。
It may well be useful or necessary to use the SDP "require" parameter in conjunction with the phone-context attribute.
SDPの「要求」パラメーターをPhone-Context属性と組み合わせて使用することが有用または必要になる場合があります。
Example 4:
例4：
c= TN RFC2543 321 a=phone-context:X-acme.com-23
C = TN RFC2543 321 A =電話 - コンテキスト：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)
（ACME.com内からプライベートPBXネットワークに到達するために「7」がダイヤルされていると仮定して）
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ネットワークを介したサービスリクエストの輸送には影響しませんが、パイントサービスリクエストのオリジネーターが、結果のサービスコールの「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端末に当事者の電話番号を提示するかどうかを提示するかどうかは指定されていないかどうかは、この属性に基づいて行動するためのパイントゲートウェイまたはエグゼクティブシステムのすべての地域で必須ではありません。ただし、GSTN操作に規制上の制限がある場合に使用するためにここで定義されており、その場合、エグゼクティブシステムはそれを使用して発信者の要求を尊重することができます。
The attribute is specified as follows:
a=clir:<"true" | "false">
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.
この属性の予想される解釈は、それが存在し、値が「false」である場合、呼び出し線のアイデンティティを特派員の端末に提示することができるということです。呼び出し線のアイデンティティを提示します。
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「CaledPartyAddress」フィールド内に表示されるフィールドに対応しています（[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- <token>（（"： "<balue>）|" "）"です。可能な要素の3つとSDP属性での使用について説明します。他のQ763要素を使用する場合、これらは属性マッピングの構文を定義するためのさらなる仕様の主題である必要があります。このような仕様では、Q.763に示されている値セットを維持することをお勧めします。
The defined attributes are:
定義された属性は次のとおりです。
a=Q763-nature: - indicates the "nature of address indicator". The value MAY be any number between 0 and 127. The following values are specified:
a = q763 -nature： - 「アドレスインジケーターの性質」を示します。値は0〜127の任意の数字である場合があります。次の値が指定されています。
"1" a subscriber number "2" unknown "3" a nationally significant number "4" an internationally significant number
「1」加入者番号 "2"未知の "3"全国的に有意な数 "4"国際的にかなりの数字
The values have been chosen to coincide with the values in Q.763. Note that other values are possible, according to national rules or future expansion of Q.763.
値は、Q.763の値と一致するように選択されています。Q.763の国家規則または将来の拡大に従って、他の価値が可能であることに注意してください。
a=Q763-plan: - indicates the numbering plan to which the address belongs. The value MAY be any number between 0 and 7. The following values are specified:
a = q763 -plan： - アドレスが属する番号付け計画を示します。値は0〜7の任意の数値である場合があります。次の値が指定されています。
"1" Telephone numbering plan (ITU-T E.164) "3" Data numbering plan (ITU-T X.121) "4" Telex numbering plan (ITU-T F.69)
"1"電話番号計画（ITU-T e.164） "3"データ番号付け計画（ITU-T X.121） "4" Telex番号付け計画（ITU-T F.69）
The values have been chosen to coincide with the values in Q.763. Other values are allowed, according to national rules or future expansion of Q.763.
値は、Q.763の値と一致するように選択されています。国の規則またはQ.763の将来の拡大に従って、他の価値が許可されています。
a=Q763-INN - indicates if routing to the Internal Network Number is allowed. The value MUST be ONE of:
a = q763 -inn-内部ネットワーク番号へのルーティングが許可されているかどうかを示します。値は次のいずれかでなければなりません。
"0" routing to internal network number allowed "1" routing to internal network number not allowed
「0」内部ネットワーク番号へのルーティング許可「1」は、内部ネットワーク番号へのルーティングが許可されていない
The values have been chosen to coincide with the values in Q.763. Note that it is possible to use a local-phone-number and indicate via attributes that the number is in fact an internationally significant E.164 number. Normally this SHOULD NOT be done; an internationally significant E.164 number is indicated by using a "global-phone-number" for the address string.
値は、Q.763の値と一致するように選択されています。ローカルフォン番号を使用して、数値が実際に国際的に重要なe.164数であることを属性を介して示すことが可能であることに注意してください。通常、これは行うべきではありません。国際的に重要な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サーバーは、理解できない属性パラメーターを無視するだけで許可されています。サーバーがパイント属性の1つを理解していない場合、リクエストを拒否させるために、クライアントは次のように指定された「要求」属性を使用する必要があります。
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（悪い要求）など）を返す必要があり、適切な警告を返す必要があります。理解できない属性を含む。サーバーがリストされている属性を認識しますが、属性の存在によって暗示される要求を満たすことができない場合、リクエストは（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仕様は、それを無視するための要件属性を理解していないサーバーを許可します。パイントサーバーが「要求」属性に準拠することを確認するために、パイントクライアントには次の要求を含める必要があります。
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.
パイント拡張機能の大部分は「タグ付け」されており、これらのタグは必要な狭窄に含めることができることに注意してください。例外は、SDPパーツでの電話番号の使用です。ただし、これらは新しいネットワークとアドレスタイプとして定義されているため、受信SIP/SDPサーバーがこれらのフォームをサポートするかどうかを検出できるようになります。SDP受信者のデフォルトの動作は、TNおよびRFC2543またはXトークンネットワークとアドレスタイプを認識またはサポートしていない場合、パイントリクエストに失敗することです。したがって、この場合、別の狭窄は必要ありません。
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.
パイントリクエストはSIPリクエストです。このドキュメント内の仕様の多くは、パイントの目的で既存の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.
パイントリクエストには、マルチパートMIMEのペイロードを含めることができます。この場合、最初の部分には、セクション3.4.3で指定された「コンテンツデータを含む」の形式固有の属性タグの少なくとも1つを含むSDPセッションの説明を含める必要があります。後続の部品には、要求された電話サービスに転送される可能性のあるコンテンツデータが含まれています。前述のように、単一のパイントリクエスト内で、一部のデータはリクエスト内の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.
含まれたデータがパイントサービスリクエスト内で伝達される場合、囲まれた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].
囲まれたボディの部分には、必要に応じてパーツ固有のコンテンツタイプヘッダーを含める必要があります（セッションの説明を保持する最初のボディパーツの「アプリケーション/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]のメッセージと、PINTサーバーまたは電話ネットワークがUnicodeを処理できない場合、同じコンテンツの代替バージョンがテキスト/プレーンに含まれる場合があります。
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.
パイントクライアントは、含まれているデータをパイントリクエスト内に送信する際に非常に注意する必要があります。このような要求は、断片化を避け、データを確実に送信するために、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.
クライアントがパイントゲートウェイの実際の場所を知らず、SIPロケーションサービスを使用してそれを見つけている場合、付属のデータがいくつかのIPデータグラムで輸送される可能性が高い場合は、最初のパイントリクエストをお勧めしますデータオブジェクトを含めるのではなく、代わりにそれを参照します。
A PINT server MUST support the SIP "Warning:" header so that it can signal lack of support for individual PINT features. As an example, suppose the PINT request is to send a jpeg picture to a fax machine, but the server cannot retrieve and/or translate jpeg pictures from the Internet into fax transmissions.
PINTサーバーは、個々のパイント機能のサポートの欠如を示すように、SIP「警告：」ヘッダーをサポートする必要があります。例として、パイントリクエストがJPEG画像をファックスマシンに送信することであると仮定しますが、サーバーはインターネットからJPEGの写真をFAX送信に取得および/または翻訳することはできません。
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.
パイント拡張機能をまったく理解していない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).
また、警告：パイントサービスの呼び出しに関する条件についてクライアントに通知する必要がある場合は、ヘッダーを通知リクエストに含めることができます（次を参照）。
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.
要求されたサービスが完了したかどうか、そしてもしそうならそれが成功したかどうかを調べることは非常に便利です。これは特に、サービスを要求する人が（必ずしも）当事者ではないため、そのサービスの処分を見つける簡単な方法がない場合があります。同様に、サービスがいつ変更されたか、たとえばサービスコールがいつ開始されたかを示すことは有用かもしれません。
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を参照）。パイント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.
パイント1.0ステータス登録と表示スキームは、3つの新しい方法を使用します。購読、登録解除、および通知。これらは、パイントクライアントがサービスリクエストのステータスに利息を登録する（または「サブスクライブ」する）ことを可能にするために使用されます。返品サービス指標。購読/登録解除の状態マシンは、招待/さようならのマシンと同じです。招待状のシグナルとさようならシグナルとメディアセッションへの参加の終了と同様に、監視セッションへの参加の終了を登録し、登録解除信号をサブスクライブします。監視セッション中に、通知メッセージが送信され、セッション状態または処分の変更をサブスクライバーに通知します。
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.
サブスクライブリクエストがパイントサーバーに送信されると、ユーザーがサービスセッションのステータスに関する情報を受信したいことを示します。リクエストは、元のセッションの説明とリクエストを含めることにより、関心のセッションを識別し、Origin-Fieldの一部を形成してサービスセッションを一意に識別するSDP Global-Session-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).
サブスクライブリクエスト（進行中のセッションに関する他のSIPリクエストと同様）は、元の招待状を送信されたのと同じサーバーに送信されるか、連絡先で指定されたサーバーに送信されます。セッションのゲートウェイ）。
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.
関心のセッションを開始した元の招待状で使用されているコールIDの再利用が可能な状況がありますが、そうでない状況は他にもあります。詳細には、元のサービス要求を開始したユーザーがサブスクリプションが作成されている場合、コールIDは、以前に確立されたセッションを参照することが受信者に知られているため、使用できます。ただし、リクエストが元のリクエストユーザー以外のユーザーからの場合、サブスクライブリクエストは新しいSIPコールレッグを構成するため、Call-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.
「関心セッション」を識別する2つの異なる方法を持つのではなく、選択は、SDPサブパートのOrigin-Fieldを使用することです。
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.
リクエストには、セッションの説明以外のサブパートを含めてはならないことに注意してください。囲まれたセッションの説明を除いて、サーバーはサブスクライブリクエストに含まれるサブパートを無視する必要があります。
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.
さらに、有効期限を抑える必要があります。ヘッダーは、パイントリクエスト担当者がセッションステータスの通知を受信したい期間を示しています。サブスクライブリクエストの有効期限が切れる前の期間を「サブスクリプション期間」と呼びます。セクション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).
Gatewayによると、サブスクライブリクエストに対する成功した応答には、セッションの説明が含まれます。通常、これは、ゲートウェイが同じSDPグローバルセッションIDに関して任意のリクエストに返された最後のキャッシュされた応答と同じです（[2]、セクション6、O =フィールドを参照）。ただし、実際の開始時間または停止時間を示すためにT =線を変更する場合があります。ゲートウェイは、セッションの説明にi =行を追加して、送信されたFAXページの数などの情報を示す場合があります。ゲートウェイには、有効期限が含まれている必要があります。ヘッダーは、監視セッションを維持する意思があるかを示すヘッダーです。これがPINT Requestorに容認できない場合は、即時の登録メッセージを送信することでセッションを閉じることができます（3.5.3.3を参照）。
In principle, a user might send a SUBSCRIBE request after the telephone network service has completed. This allows, for example, checking up "the morning after" to see if the fax was successfully transmitted. However, a PINT gateway is only required to keep state about a call for as long as it indicated previously in an Expires: header sent within the response to the original INVITE message that triggered the service session, within the response to the SUBSCRIBE message, within the response to any UNSUBSCRIBE message, or within its own UNSUBSCRIBE message (but see section 3.5.8, point 3).
原則として、ユーザーは電話ネットワークサービスが完了した後に購読リクエストを送信する場合があります。これにより、たとえば、「The Morning After」をチェックして、FAXが正常に送信されたかどうかを確認できます。ただし、パイントゲートウェイは、以前に有効期限が切れている限り、予定を維持するためにのみ必要です。ヘッダーは、サブスクライブメッセージへの応答内で、サービスセッションをトリガーした元の招待メッセージへの応答内で送信されました。登録解除メッセージに対する応答、または独自の登録メッセージ内の応答（ただし、セクション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.
サーバーがリクエスタがサブスクライブしているセッションの記録がなくなった場合、適切な警告とともに「許容されない606」を返します。これは、セッションが終了した後にセッションのステータスに関する情報が必要であることを知っている要求クライアントが、セッションが終了する前に購読リクエストを送信する必要があることを意味します。
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.
サブスクリプション期間中、ゲートウェイは、連絡先に示されているエンティティに自発的な通知リクエストを随時送信できます。「オープニング」サブスクライブリクエストのヘッダー。通常、これは、要求者がサブスクライブしたサービスセッションのステータスの変更の結果として発生します。
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」）を返すことでこれを認める必要があります。パイント拡張機能のこのバージョンでは、ゲートウェイはリダイレクト（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 = Line内で示す場合があります。
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
c=... i=3 pages of 5 sent t=...
c = ... i = 3ページの3ページ送信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.
ある時点で、クライアントの代表的なユーザーエージェントサーバーまたはゲートウェイが監視セッションを終了することを決定する場合があります。これは、登録解除リクエストをCRORSPROSERENTENT SERVERに送信することによって達成されます。このような要求は、送信者が監視セッションをすぐに閉じる予定であり、受信サーバーからの最終的な応答を受け取ったときに、セッションが終了したことを示しています。
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.)
パイントゲートウェイによって送信されることのない購読要求とは異なり、監視セッションがクローズされていることを示すために、パイントゲートウェイによってユーザーエージェントサーバーに登録されていないリクエストを送信できることに注意してください。（これは、ゲートウェイが招待状を送信しないという事実に類似していますが、電話が終了したことを示すためにさようならを送ることができます。）
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.
ゲートウェイが、登録解除メッセージを送信して監視セッションの閉鎖を開始する場合、「有効期限が切れる」を含める必要があります。これは、クライアントが新しいサブスクライブメッセージを送信して別の監視セッションを開くことができる最小時間として機能します。期限切れに記載された時間の後：ヘッダーゲートウェイはサービスセッションの記録を自由に処分できます。そのため、後続のサブスクライブリクエストを「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.
クライアントによって指定されたサブスクリプション期間の有効期限が切れた場合、ゲートウェイはクライアントの代表的なユーザーエージェントサーバーに即時の登録リクエストを送信する場合があります。これにより、監視セッションが常に登録されていない/応答交換で完了し、代表的なユーザーエージェントサーバーが特定の状況で状態を維持することを避けることができます。
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.
招待されたセッションの説明のコピーを持っているゲートウェイに依存しているため、購読メッセージは発行できるときに制限されます。ゲートウェイは、この監視セッションを関連付けるサービスリクエストを受け取っている必要があります。これは、ゲートウェイが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を送信する前に、サブスクライブリクエストを確実に送信できます。この点を超えて、クライアントは、最初のサービスリクエストに対するゲートウェイの最終的な応答が短い期限をとっていない場合を除き、決定したときに購読要求を自由に送信できます。
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 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.
ただし、ACKを送信するPINTクライアントによってサービスが確認される直前に監視セッションを開始することが適切な理由（6.4を参照）があります。この時点で、ゲートウェイはサービス要求を処理できるかどうかを決定しましたが、エグゼクティブシステムにリクエストを渡すことはできません。したがって、エグゼクティブシステムに、サービスリクエストを以降に送信するときに監視を可能にするように依頼するのは良い立場にあります。実際の実装では、これがサービス実行フェーズの開始時に重要であると示されている場合、一時的なサービスステータスに関するより多くの情報が利用可能になる可能性があります。実行が始まると、返品できる情報のレベルを変更するのが難しい場合があります。
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.
したがって、ゲートウェイからサービスリクエストへの暫定応答を受け取った後、任意の時点で購読リクエストを自由に送信できますが、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:
PINTクライアントは、要件を使用します。ヘッダーは、SIPの特定のパイント拡張機能が必要であることをパイントサーバーに信号に合わせます。パイント1.0は、必要ヘッダーに入ることができる2つの文字列を定義します。
org.ietf.sip.subscribe -- the server can fulfill SUBSCRIBE requests and associated methods (see section 3.5.3)
org.ietf.sip.subscribe-サーバーはサブスクライブリクエストと関連する方法を満たすことができます（セクション3.5.3を参照）
org.ietf.sdp.require -- the PINT server (or the SDP parser associated to it) understands the "require" attribute defined in (section 3.4.4)
org.ietf.sdp.require-パイントサーバー（またはそれに関連するSDPパーサー）は、（セクション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.
通常、パイントURLに表示されるホスト名とドメイン名は、個々のパイントシステムの内部問題です。クライアントは、適切なSDPペイロードを使用して、呼び出したい特定のサービスを示します。特定のURLを使用してサービスを識別する必要はありません。
A PINT URL is used in two different ways within PINT requests: within the Request-URI, and within the To: and From: headers. Use within the Request-URI requires clarification in order to ensure smooth interworking with the Telephone Network serviced by the PINT infrastructure, and this is covered next.
PINT URLは、PINTリクエスト内の2つの異なる方法で使用されます。リクエスト-URI内、およびfrom：headers。Request-URI内での使用には、パイントインフラストラクチャがサービスする電話ネットワークとのスムーズなインターワーキングを確保するために説明が必要です。これは次にカバーされます。
There are some occasions when it may be useful to indicate service information within the URL in a standardized way:
URL内のサービス情報を標準化された方法で示すことが有用な場合があります。
a. it may not be possible to use SDP information to route the request if it is encrypted; b. it allows implementation that make use of I.N. "service indicators"; c. It enables multiple competing PINT gateways to REGISTER with a single "broker" server (proxy or redirect) (see section 6.3)
a. SDP情報を使用して、暗号化されている場合にリクエストをルーティングすることはできない場合があります。b。i.n.を使用する実装を可能にします。「サービスインジケーター」;c。複数の競合するパイントゲートウェイが単一の「ブローカー」サーバー（プロキシまたはリダイレクト）に登録できるようにします（セクション6.3を参照）
For these reasons, the following conventions for URLs are offered for use in PINT requests:
これらの理由により、PINTリクエストで使用するために、URLの次の規則が提供されます。
1. The user portion of a sip URL indicates the service to be requested. At present the following services are defined:
1. 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」がパイントマイルストーンサービス用に予約されています。要求されたサービスがマイルストーンサービスの1つではない場合、他のユーザー部分を使用する必要があります。サービスブローカーとして機能する単一のパイントプロキシサーバーと競合することにより、登録に関するいくつかの関連する考慮事項については、セクション6.2を参照してください。
2. The host portion of a sip URL contains the domain name of the PINT service provider.
2. SIP URLのホスト部分には、パイントサービスプロバイダーのドメイン名が含まれています。
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」（「電話サービスプロバイダー」の場合）と定義されています。これを使用して、実際の電話ネットワークプロバイダーを使用して、パイントリクエストを満たすために使用できます。
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
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).
すべての法的SIP URLは、リクエスト-URI内または次のパイントURLとして表示されます。パイントリクエストのヘッダー。しかし、住所が電話アドレスである場合、セクション3.4.3で、リモートの電話端末またはサービスを識別するために、より多くの情報を正しく順番に含める必要があることを示しました。PINTクライアントには、必要な場合、またはSIP URL内の電話番号を補完する有用な場合、PINT URL内にこれらの属性タグを含めることができます。これらの属性タグは、[1]で定義されているURLパラメーターとして含める必要があります（つまり、セミコロン分離方法）。
The following is an example of a PINT URL containing extra attribute tags:
以下は、追加の属性タグを含むパイントURLの例です。
sip:+9725228808@pint.br.com;user=phone;require=Q763-plan;a=Q763-plan: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内では必要ありません。これは、サーバーが電話番号を正しく解釈できるように利用できるコンテキストが非常に多いためです。特に、To：HeaderにはSIP URLがあり、リクエスト-URIもあります。ほとんどの場合、これは電話網に十分な情報を提供します。
The SDP attributes defined in section 3 above will normally only be used when they are needed to supply necessary context to identify a telephone terminal.
上記のセクション3で定義されているSDP属性は、通常、電話端子を識別するために必要なコンテキストを提供するために必要な場合にのみ使用されます。
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.
パイントゲートウェイは、SIPユーザーエージェントサーバーです。ユーザーエージェントサーバーは、レジスタリクエストを使用して、プロキシまたはリダイレクトサーバーに「通話の受信」（つまり、サービスリクエストに）を使用できることを伝えます。したがって、パイントゲートウェイはプロキシまたはリダイレクトサーバーを登録し、SIPでは特定の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.
単一のパイントサーバーで登録しようとする同じパイントサービスを提供できる競合するパイントサーバーがある場合があります。パイントサーバーは、リクエストを満たすことができるさまざまなパイントゲートウェイの中で「ブローカー」として機能する場合があります。パイントURLの形式は、独立したパイントシステムが同じサービスを提供するオファーを登録できるようにするセクション3.5.5で指定されました。レジストラは独自のメカニズムとポリシーを適用して、サービスを求めているクライアントから招待に応答する方法を決定できます（いくつかの可能な展開オプションについては、セクション6.3を参照）。SIPとPINTレジスタのセマンティクスまたは構文の間に変更はありません。
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.
もちろん、レジスタリクエスト内のパイントURLの情報は、ゲートウェイが提供できるサービスを完全に定義するのに十分ではない場合があります。PINTレジスタリクエスト内で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つの問題は、「残ることはできない」会議に関するものであり、もう1つの問題は、さようなら後にコール状態を維持しています。
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クライアントがAからBへの電話の呼び出しを引き起こすリクエストを行うと、クライアントからのBYEリクエストが受け入れられた場合、電話が終了するはずです。
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.
さようならのリクエストを受け取ったときに電話が開始されていない場合、これが当てはまると予想されるかもしれません。たとえば、FAXのリクエストがT =行で送信された場合、FAXが明日午前4時に送信されることを示す場合、リクエスタは指定された時間前にリクエストをキャンセルすることを希望する場合があります。
However, even if the call has yet to start, it may not be possible to terminate the media session on the telephone system side. For example, the fax call may be in progress when the BYE arrives, and perhaps it is just not possible to cancel the fax in session. Another possibility is that the entire telephone-side service might be completed before the BYE is received. In the above Request-to-Fax example, the BYE might be sent the following morning, and the entire fax has been sent before the BYE was received. It is too late to send the BYE.
ただし、電話がまだ開始されていない場合でも、電話システム側のメディアセッションを終了することはできない場合があります。たとえば、BYEが到着するとFAXコールが進行中である可能性があります。おそらく、セッションでFAXをキャンセルすることは不可能です。別の可能性は、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.
したがって、パイントでは、「受け入れられない」応答を招待してリクエストを招待して返す場合があります。これは、セッションの説明のいくつかの側面が要求を受け入れられないことを示しています。
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
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.
サーバーは、さようならに対する成功した応答内で更新されたセッションの説明を返す可能性があることに注意してください。これは、たとえば、電話セッションの実際の開始時間と停止時間、またはファックス伝送で送信されたページの数を示すために使用できます。
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:
2番目の問題は、さようならを受け取った後、サーバーがコール状態を維持する期間に関するものです。他のクライアントは、パイントトランザクションの主題である電話ネットワークセッションに関するクエリをまだ送信したいと思うかもしれないので、疑問が生じます。通常の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. さようならは、リクエストクライアントが応答を成功させるとすぐにすべてのコール状態をクリアすることを示します。クライアントは、さようならを送信した後、購読リクエストを送信しないでください。
2. A server may return an Expires: header within a successful response to a BYE request. This indicates for how long the server will retain session state about the telephone network session. At any point during this time, a client may send a SUBSCRIBE request to the server to learn about the session state (although as explained in the previous paragraph, a client that has sent a BYE will not normally send a SUBSCRIBE).
2. サーバーは有効期限を返す場合があります：BYEリクエストへの成功した応答内のヘッダー。これは、サーバーが電話ネットワークセッションに関するセッション状態を保持する期間を示しています。この時点で、クライアントはセッション状態について学習するためにサーバーにサブスクライブリクエストを送信することができます（ただし、前の段落で説明されているように、さようならを送信したクライアントは通常サブスクライブを送信しません）。
3. When engaged in a SUBSCRIBE/NOTIFY monitoring session, PINT servers that send UNSUBSCRIBE to a URL listed in the Contact: header of a client request SHOULD not clear session state until after the successful response to the UNSUBSCRIBE message is received. For example, it may be that the requesting client host is turned off (or 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. サブスクライブ/Notify Monitoringセッションに従事している場合、連絡先にリストされているURLに登録解除を送信するパイントサーバー：クライアント要求のヘッダーは、登録解除メッセージへの応答が成功するまでセッション状態をクリアしてはなりません。たとえば、電話サービスが実行されたときに要求するクライアントホストがオフになっている（または低電力モードで）（したがって、連絡先で以前に指定された場所では利用できない：属性）、パイントサーバーの受信を受信する可能性があります。登録解除。もちろん、登録解除リクエストは単にタイムアウトする可能性があります。
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
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サーバーに暗黙的に知られています。しかし、電話を受けたい人の電話は、北米の番号付け計画に該当する国際的に重要なE.164番号として明示的に特定されています（C = Line内の「1」のため）。
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
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 -
The To: line might include the Mary James's phone number instead of a email-like address. An implementation that cannot accept email-like URLs in the "To:" header must decline the request with a 606 Not Acceptable. Note that the sending PINT client "knows" that the PINT Gateway contacted with the "marketing@pint.mailorder.com" Request-URI is capable of processing the client request as expected. (see 3.5.5.1 for a discussion on this).
to：行は、電子メールのようなアドレスではなく、メアリージェームズの電話番号が含まれる場合があります。「to」で電子メールのようなURLを受け入れることができない実装は、606が許容できない606でリクエストを拒否する必要があります。送信パイントクライアントは、「Marketing@pint.mailorder.com」と接触したパイントゲートウェイがリクエスト-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 =」属性行で示される場合があります。サービスの一貫性のためのこのような属性行の仕様は、1.0仕様の範囲を超えています。
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
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.
この例では、送信されるFAXは、Pint Serverが置かれているIPネットワーク内からの名前のみを解決できるか、その名前のみに到達可能である可能性があるローカルサーバー（LocalStore）に保存されます。ダイヤルされる電話番号も「ローカルの電話番号」です。「電話コンテキスト」属性はないため、コンテキスト（この場合、その数は「全国的に重要」です）は、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.
それを受信したサーバーが数を理解していない場合、リクエストを拒否し、「理解されていないネットワークアドレス」警告を含める必要があります。「要求」属性をサポートしていないサーバーでもリクエストを提供できる可能性が非常に高いため、ここでは「要求」属性は使用されなかったことに注意してください。
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
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
4.5. A request to send an included text page to a friend's pager.
4.5. 含まれるテキストページを友人のポケットベルに送信するリクエスト。
In this example, the text to be paged out is included in the request.
この例では、ページングするテキストがリクエストに含まれています。
C->S: INVITE sip:R2F@pint.pager.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:scott.petrack@chinet.net
To: sip:R2F@pint.pager.com
Call-ID: 19974505.66.79@chinet.net
CSeq: 4714 INVITE
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
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は優先形式です。写真が存在するHTTPサーバーはローカルであり、パイントサーバーもローカルであることに注意してください（マシン名「Petrack」を解決できるため）
4.7. A request to read out over the phone two pieces of content in sequence.
4.7. 電話で2つのコンテンツを順番に読み取るリクエスト。
First some included text is read out by text-to-speech. Then some text that is stored at some URI on the internet is read out.
最初にいくつかの含まれたテキストは、テキストツースピーチで読み上げられます。次に、インターネット上のいくつかのURIに保存されているテキストが読み上げられます。
C->S: INVITE sip:R2HC@pint.acme.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:scott.petrack@chinet.net
To: sip:R2HC@pint.acme.com
Call-ID: 19974505.66.79@chinet.net
CSeq: 4716 INVITE
Content-Type: multipart/related; boundary=next
--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
--next
Content-Type: text/plain
Content-ID: 2@53655768
Content-Length: 172
Hello!! I am about to read out to you the document you requested, "uri:http://www.your.com/texts/stuff.doc". We hope you like acme.com's new speech synthesis server. --next--
こんにちは！！「URI：http：//www.your.com/texts/stuff.doc」という要求したドキュメントを読みます。Acme.comの新しいSpeech Synthesis Serverが気に入っていただければ幸いです。 - 次 -
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
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
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
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 -
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
--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
Content-Type: text/plain
Content-ID: 2@53655768
Content-Length: 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.
「暗黙の」ファックスバックコンテンツは、この例の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
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
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
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>
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).
注：この場合、不透明なリファレンスは、特定のコンテンツを選択するのではなく、要求者がこの情報を取得する権利を持っていることをエグゼクティブシステムに納得させるために使用されるデータのコレクションです。「それだけでそれをします）。
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.
パイントゲートウェイ、およびそのゲートウェイが関連付けられているエグゼクティブシステムは、ピントリクエスト担当者にサービスを提供するために存在します。パイントプロトコルの目的は、関連するエグゼクティブシステムがそれらのリクエストにサービスを提供できるように、それらのユーザーからパイントゲートウェイにリクエストを渡すことです。
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ベースの呼び出しを行う機能には、いくつかのリスクがあります。リクエストは、FAX番号の誤った電話を指定できます。また、リクエスターが罪のない第三者の電話番号を意図的に入力した可能性もあります。最後に、要求は、介在するパイントまたは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オペレーターは、これが誰かではないことを好むので、パイントゲートウェイとエグゼクティブシステムの組み合わせが、ゲートウェイまたはエグゼクティブシステムの実装または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.
リクエストが特定の要求者から来て、パイントサービスプロバイダーによって誠実に行動されたことが示された場合、リクエストを行う責任は、これらのリクエストを実行したオペレーターではなく、リクエスターにかかることがあります。
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.
最後に、パイントサービスプロバイダーが、ある程度の起源の保証がある要求に応じてのみ行動することを示すことが重要かもしれません。多くの管轄区域では、GSTNオペレーターの要件であり、必要に応じて通話の当事者を特定できる場合にのみ電話をかけます（悪意のある通話トレースを実行するために必要な場合など）。少なくとも、パイントサービスのプロバイダーが同様の責任を負う可能性があります。
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.
そのため、パイントサービスプロバイダーは、リクエスターの身元を確認する必要がある場合があります。そのような確認が利用できない場合、サービスを提供しないように強制される（または選択する）ことがあります。この識別には、要求するユーザーの個人認証が必要になる場合があります。
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リソースがパイントサービスを提供するために使用される場合、少なくとも誰かがそれを支払わなければならない可能性があります。たとえば、既存の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.
もちろん、これは唯一の可能性ではありません。たとえば、パイントサービスはサブスクリプションベースで提供される場合があり、他にも多くのモデルがあります。ただし、どちらのモデルが選択されても、要求者がパイントリクエストを行う権限が確認されるという要件があるかもしれません。
If such confirmation is not available, then, again, the PINT Gateway and associated Executive System may choose not to provide service.
そのような確認が利用できない場合、再び、パイントゲートウェイと関連するエグゼクティブシステムは、サービスを提供しないことを選択する場合があります。
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.
リクエストユーザーの識別とリクエストを行う権限が知られていても、リクエスタとパイントゲートウェイの間の輸送中に、リクエストが破損、悪意のある、または交換される可能性が残っています。
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).
要求ユーザーがパイントリクエストを行うように承認するデータは、彼らとサービスプロバイダーにのみ知られる必要があります。ただし、この情報は、インターネット内で通常使用されるスキームと一致しない形式である場合があります。たとえば、X.509証明書[14]は、IPセキュリティアーキテクチャ[12]とTLSプロトコル[13]の両方で、インターネット上の保護されたトランザクションに一般的に使用されますが、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.
リクエストユーザーは、サービスのリクエストが機密であるという合理的な期待を持っています。一部のパイントサービスでは、インターネット上にコンテンツが掲載されていません。ただし、結果のサービスコールに対する当事者の電話またはファックス番号は、敏感であると見なされる場合があります。その結果、リクエスター（およびそのパイントサービスプロバイダー）は、インターネットを介して送信されるリクエストが盗聴者に対して保護されることを要求する可能性があります。要するに、リクエストを暗号化する必要があります。
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.
いくつかの特別な考慮事項は、サブスクライブと通知メッセージを使用した監視セッションに関連しています。パイントサービストランザクションの処分への関心を登録するために使用される購読メッセージは、関連する招待メッセージに掲載された元のセッションの説明を使用します。この現在の仕様は、このような購読メッセージのソースを制限していないため、盗聴者が保護されていないセッションの説明をキャプチャし、それを後続のサブスクライブリクエストで使用することができます。このようにして、そのトランザクションの詳細を見つけることができます。
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.
このリスクの最初の解決策は、後続の購読メッセージ内で使用できるセッションの説明を保護することを推奨することです。
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.
ただし、さらなるリスクがあります。使用されているOrigin-Fieldが「推測可能」である場合、攻撃者がセッションの説明を再構築し、サブスクライブメッセージ内でこの再構成を使用することが可能かもしれません。
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]のセクション6を参照、「O = "フィールド）は、SESS-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.
したがって、セッション識別子が推測できないことを確認するために、[17]のセクション6.3に記載されている手法を使用することができます。パイント招待メッセージ内で使用されるセッション説明の原点フィールドを生成するときに使用できます。特定のパイント要求エンティティからのすべての要求（および応答）が保護されている場合、これは必要ありません。このような状況が保証されておらず、セッション監視がサポートされている場合、セッションの説明内の原点フィールドが推測できない方法を使用する必要があります。
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.
同じサービスを提供するために、任意の数のパイントゲートウェイが登録できます。これは、登録要求のヘッダーフィールドに同じ「userininfo」部分を指定するゲートウェイによって示されます。このようなあいまいさは、「コア」SIPでカバーされているシナリオでは起こりそうにありませんが、パイントには非常にありそうです。たとえば、「ファックスへのリクエスト」サービスをサポートする意思があるサービスプロバイダーはすべて存在する可能性があります。
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.
リクエストがゲートウェイ名を明示的に指定しない限り、いくつかのゲートウェイがすべて登録している登録データベースに作用する介在プロキシは、選択したアルゴリズムを使用してレジストランドから選択する立場にあります。原則として、「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手順は、ワイルドカード値を持つコンタクトフィールドとのレジスタリクエストを送信し、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.
解決策は同じです。パイントゲートウェイによるすべての登録は認証する必要があります。これには、新規または見かけの交換登録の両方、および現在の登録のキャンセルが含まれます。この推奨事項はSIP仕様でも行われますが、パイントの正しい操作のために、それは非常に重要です。
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.
パイントは、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.
いくつかのパイントサービスでは、TO：TO：SIPのヘッダーフィールドを使用して、結果のサービスコールの当事者の1つを識別します。パイントリクエストコールサービスは例です。SIP仕様で述べたように、このフィールドは、対応するユーザーエージェントサーバー間のリダイレクトサーバーとプロキシサーバーのインフラストラクチャを介してSIPメッセージをルーティングするために使用されるため、暗号化することはできません。これは、輸送中に個人的または機密データの大部分が保護されているが、パイントサービスコールの当事者の1つの電話（またはFAX）の数は、傍受に対して「見える」ことができないことを意味します。Pint Milestoneサービスの場合、これは許容される場合があります。これは、次のように指定されている発信者は、通常、コールセンターなどの「よく知られている」プロバイダーアドレスです。
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.
これのもう1つの側面は、要求ユーザーがプライベートになるためのパイントサービスの電話またはファックス番号をパイントサービスに考慮していなくても、それらの当事者がそうかもしれないということです。パイントサーバーには、リクエスト装置がそうしていなくても、これがリクエストを暗号化する必要があると信じる理由があります。これは、たとえば、会社内の要求ユーザーがパイントリクエストを行った場合に発生する可能性があり、これが会社のイントラネットを介してプロキシ/ファイアウォールに携帯され、インターネットを介して別の場所のパイントゲートウェイに運ばれました。
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).
リクエストが盗聴者によって再利用される可能性のあるデータを、要求者の認可トークンを盗聴者のリクエストに挿入することにより、リクエスターを「スプーフィング」するか、パイントサービスを取得するために運ばれる場合、このデータを保護する必要があります。これは、認証トークンが静的テキスト（アカウントコードや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.
1つのアプローチは、SIP仕様で説明されているメソッドを使用して、リクエスト全体を暗号化することです。別の方法として、承認トークンが不透明な参照として保持されることは許容される場合があります（3.4.2.3および例4.11および4.12を参照）。傍受や再利用に耐性があります。また、リクエスターが暗号化されたリクエストの外側で承認トークンを使用できない可能性があります。もしそうなら、この要件は緩和される可能性があります。この場合、トークンは別のもので再利用できません。ただし、リクエスターとゲートウェイの両方がそうであることが保証されていない限り、承認トークンは敏感であると扱われなければならないため、暗号化する必要があります。
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.
パイントリクエストには、SDPメッセージ本文内にデータが含まれている場合があります。このデータには、そのリクエストをルーティングするためにより効率的に使用できます。たとえば、1つのゲートウェイとエグゼクティブシステムの組み合わせが、パーティーの1つをポケットベルとして指定するリクエストを処理できないのに、別のパーティーができるかもしれません。どちらのゲートウェイもパイント/SIPレジストラに登録している可能性があり、この情報は介在するパイント/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).
その結果、プロキシはそれを処理できないゲートウェイにリクエストを配信する場合があります。意味は、パイント/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 Request-URIのuserInfo部分で渡されるサービス名の選択は柔軟性があり、検査せずにプロキシが適切なゲートウェイを選択できるようにする名前を選択することをお勧めしますSDPボディの部分。したがって、ここに示されている例では、輸送中にSDP体の部分が保護されている可能性がある場合、サービスは「R2F」のより一般的な使用ではなく、「Page-to-Page」または「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.
最後に、リクエストユーザーは、リクエストを満たすエグゼクティブシステムのオペレーターとの事前の関係を持つ一方で、パイントゲートウェイとの事前の関係を持たない可能性があることに注意してください。したがって、認証と承認には2つのレベルがあります。1つは、SIP仕様で説明されている手法（リクエスターとゲートウェイの間で使用するため）を使用して実行され、もう1つはリクエストユーザーまたはリクエスターとエグゼクティブシステムの間で使用されています。
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.
たとえば、リクエストユーザーには、パイントサービスプロバイダーにアカウントを持つ場合があります。そのプロバイダーは、サービスを提供するように確信する前に、このリクエストにこのアイデンティティを含めることを要求する場合があります。さらに、インターネットを介して輸送中にリクエストに対する攻撃に対抗するには、ゲートウェイにはリクエストの別のX.509ベースの認証が必要になる場合があります。これらは2つの個別の手順であり、前者に必要なデータは通常、リクエストのSDPボディ部分内の不透明な参照に保持されると予想されます。
The detailed operation of this mechanism is, by definition, outside the scope of an Internet Protocol, and so must be considered a private matter. However, one approach to indicating to the Requestor that such "second level" authentication or authorization is required by their Service Provider would be to ask for this inside the textual description carried with a 401 response returned from the PINT Gateway.
このメカニズムの詳細な操作は、定義上、インターネットプロトコルの範囲外であるため、個人的な問題と見なす必要があります。ただし、このような「第2レベル」の認証または承認が必要であることを要求者に示すための1つのアプローチは、パイントゲートウェイから返された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.
パイントはSIPとSDPに基づいており、[1]（セクション13および15）で概説されているセキュリティ手順を使用できます。ただし、パイントの場合、リクエストと応答が保護される可能性があるというSIPの推奨では十分ではありません。パイントメッセージを保護する必要があるため、PINTの実装はSIPセキュリティ（[1]、セクション13および15で説明されている）をサポートし、そのような受信メッセージを処理できるようにする必要があります。
In some configurations, PINT Clients, Servers, and Gateways can be sure that they operate using the services of network level security [13], transport layer security [12], or physical security for all communications between them. In these cases messages MAY be exchanged without SIP security, since all traffic is protected already. Clients and servers SHOULD support manual configuration to use such lower layer security facilities.
一部の構成では、パイントクライアント、サーバー、およびゲートウェイは、ネットワークレベルのセキュリティ[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]を使用する場合、セキュリティポリシーデータベースを構成して、パイントトラフィックに適切な保護を提供する必要があります。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とは対照的に、パイントリクエストは、多くの場合、以前のコミュニケーション関係が存在する当事者に送信されます（電話担体など）。この場合、クライアントとパイントゲートウェイの間に共有された秘密があるかもしれません。このようなパイントシステムは、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.
ただし、パイントの操作には影響があります。パイントプロキシまたはリダイレクトサーバーが使用される場合は、伝達されたIPデータグラムのコンテンツを調べることができなければなりません。その結果、パイントクライアントとパイントゲートウェイの間のネットワーク層セキュリティを使用したエンドツーエンドのアプローチは、介在するプロキシの使用を排除することになります。クライアントとゲートウェイ間の通信は、このノードを介してIPデータグラムが運ばれていても、介在するエンティティがアクセスできないトンネルを介して運ばれます。逆に、「ホップバイホップ」アプローチが使用されている場合、介在するパイントプロキシ（またはリダイレクトサーバー）は、信頼できるエンティティです。
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).
ただし、基礎となるネットワークまたは輸送層のセキュリティ協会が存在することに疑問がある場合は、パイントプロトコル交換のプレーヤーは、プロトコル自体内に暗号化と認証手法を使用する必要があります。RFC2543のセクション15で説明されている手法は、当事者間で合意された代替保護スキームがない限り、使用する必要があります。どちらの場合でも、パイントリクエストまたは応答内で運ばれるメッセージ本文（またはボディ）のコンテンツを保護する必要があります。これは、プロキシを介したルーティングリクエストのオプションに影響を与えます（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リクエスト内のフィールドヘッダーは保護できません。ベースラインパイントサービスでは、これらのフィールドには機密情報が含まれている場合があります。これは考慮事項であり、これらのデータが敏感であると見なされる場合、これによりSIPテクニックの唯一の使用が排除されます。このような状況では、輸送[12]またはネットワーク層[13]保護メカニズムを使用する必要があります。
As a final point, this choice will in turn have an influence on the choice of transport layer protocol that can be used; if a TLS association is available between two nodes, then TCP will have to be used. This is different from the default behaviour of SIP (try UDP, then try TCP if that fails).
最後の点として、この選択は、使用できる輸送層プロトコルの選択に影響を与えます。TLSアソシエーションが2つのノード間で利用可能である場合、TCPを使用する必要があります。これは、SIPのデフォルト動作とは異なります（UDPを試してから、失敗した場合はTCPを試してください）。
6. Deployment considerations and the Relationship PINT to I.N. (Informative)
6. 展開の考慮事項とI.N.への関係パイント（有益）
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ブラウザーとサーバーの数が多いため、一部のパイントシステムはHTML/HTTPを「フロントエンド」として使用する可能性があります。このシナリオでは、HTTPは、リクエストユーザーのWebブラウザー（WC）から中間Webサーバー（WS）への接続を介して使用されます。これは、パイントクライアントに密接に関連しています（不特定のメカニズムを使用して、データをWebサーバーから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.
特定のパイントゲートウェイが、さまざまな場所でGSTNに接続できるエグゼクティブシステム（またはシステム）に関連付けられている可能性があります。同様に、パイントサーバーのチェーンがある場合、これらの中間サーバーまたはプロキシサーバー（PP）のそれぞれが、特定のポイントでGSTNに接続するエグゼクティブシステムにパイントリクエストをルーティングできる場合があります。その結果、特定のリクエストに対処できる複数のパイントゲートウェイまたはエグゼクティブシステムがある可能性があります。リクエストを配信する場所の選択がこのドキュメントの範囲外であるメカニズム。
[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.
ただし、2つのアプローチがあるようです。プロキシまたはリダイレクトとして機能するサーバーは、適切なゲートウェイ自体を選択し、それに応じてリクエストを送信するか、可能な場所のリストがリクエストユーザーに選択したユーザーに返されます。
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.
ただし、パイント内では、そのようなあいまいさは非常に一般的かもしれません。それは、特定のサービスの多くの可能なプロバイダーがあることを意味します。
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:
パイントを使用すると、登録は個人向けではなく、サービスプロバイダーが処理できるサービス向けです。したがって、「r2c@telcoa.com」としてサービスR2Cをサポートする機能について、ドメインTelcoa.comのパイントサーバーによる登録を想定できます。com "domain from" r2c@pint.telcoa.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」にパイントシステムがあるとします。broker.comからコールへのリクエストサービスを要求するパイントクライアントは、以前にレジストラに登録していたさまざまなサービスプロバイダーのいずれかにリダイレクトまたはプロキシングされることを非常に喜んでいる可能性があります。パイントサーバーは、サービスプロバイダーを明示的に指定していないリクエストのサービスを提供すること、および「それらに」指示されたリクエストを提供することにも関心があるかもしれません。
To enable such service, PINT servers would REGISTER at the broker PINT server registrations of the form:
このようなサービスを有効にするために、パイントサーバーは、フォームのブローカーパイントサーバー登録に登録します。
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.:
そのようなレジスタメッセージがレジストラに表示される場合、それぞれがfromのURLのみが異なります。line、レジストラには多くの可能性があります。
(i) it overwrites the prior registration for "R2C@broker.telcos.com" when the next comes in;
(i) 次の登録が「r2c@broker.telcos.com」の以前の登録を上書きします。
(ii) it rejects the subsequent registration for "R2C@broker.telcos.com";
（ii）「r2c@broker.telcos.com」のその後の登録を拒否します。
(iii) it maintains all such registrations.
（iii）そのようなすべての登録を維持します。
In this last case, on receiving an Invitation for the "general" service, either:
この最後のケースでは、「一般的な」サービスへの招待状を受け取ることについて、どちらも次のとおりです。
(iii.1) it passes on the invitation to all registered service providers, returning a collated response with all acceptances, using multiple Location: headers, or (iii.2) it silently selects one of the registrations (using, for example, a "round robin" approach) and routes the Invitation and response onwards without further comment.
（iii.1）すべての登録されたサービスプロバイダーへの招待状を渡し、すべての受け入れで照合された応答を返し、複数の場所を使用して：ヘッダー、または（iii.2）登録の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.
（iv）「一般」サービスの登録を許可しないことを選択し、そのような登録要求をすべて拒否します。
The algorithm by which such a choice is made will be implementation-dependent, and is outside the scope of PINT. Where a behaviour is to be defined by requesting users, then some sort of call processing language might be used to allow those clients, as a pre-service operation, to download the behaviour they expect to the server making such decisions. This, however, is a topic for other protocols, not for PINT.
このような選択が行われるアルゴリズムは、実装依存性に依存し、パイントの範囲外です。動作がユーザーを要求して定義される場合、何らかのコール処理言語を使用して、事前サービス操作としてこれらのクライアントが、そのような決定を下すサーバーに期待する動作をダウンロードできるようにすることができます。ただし、これは他のプロトコルのトピックであり、パイントではありません。
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.
パイントの参照構成は、パイントゲートウェイを介して、インテリジェントネットワークのサービス制御機能（SCF）を満たすエグゼクティブシステムにサービス要求が送信されることです（[11]を参照）。結果として得られるサービスコールの成功または失敗は、SCFが利用できる情報である可能性があるため、パイントゲートウェイが利用できるようになる可能性があります。サービスが成功したかどうかの歴史的記録に関しては、大規模なSCFが1時間あたり100万回のコール試行を扱っている可能性があります。サービストランザクションの量を考えると、それを超えてサービス処分記録を保存できない限りの制限があります。先月、忙しい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.
成功したサービスコールの完了時など、その他のステータスの変更は、パフォーマンス上の理由で、サービスが正常に行われないようにサービスコールの監視を手配する必要があります。ほとんどの実装では、実行を開始したらサービスを中断して変更することは効率的に困難です。そのため、2つの異なるサービスが必要な場合があります。サービスコール終了を監視するためにGSTNリソースを設定するもの、およびそうでないもの。サービスが開始されたら、監視が必要であることを決定することは可能ではありません。
These factors can have implications both on the information that is potentially available at the PINT Gateway, and when a request to register interest in the status of a PINT service can succeed. The alternative to using a general SCF is to provide a dedicated Service Node just for PINT services. As this node is involved in placing all service calls, it is in a position to collect the information needed. However, it may well still not be able to respond successfully to a registration of interest in call state changes once a service logic program instance is running.
これらの要因は、パイントゲートウェイで利用可能な潜在的な情報と、パイントサービスのステータスへの関心を登録するリクエストが成功する場合の両方に影響を与える可能性があります。一般的なSCFを使用する代わりには、パイントサービス専用のサービスノードを提供することです。このノードはすべてのサービスコールの配置に関与しているため、必要な情報を収集する立場にあります。ただし、サービスロジックプログラムインスタンスが実行されていると、コールステートの変更への関心の登録にうまく対応できない場合があります。
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.
したがって、リクエストユーザーはサービスリクエストのステータスに興味を登録する場合がありますが、パイントゲートウェイはそのリクエストを遵守する立場にない場合があります。これは、リクエスターとパイントゲートウェイの間で使用されるプロトコルには影響しませんが、返された応答に影響を与える可能性があります。実行後にサービスロジックを変更する問題を回避するには、ステータスの変更への関心の登録は、サービスリクエストが行われる時間以前に行われる必要があります。
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 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.システム。
This section describes how parameters needed to specify certain traditional GSTN services can be carried within PINT requests.
このセクションでは、特定の従来のGSTNサービスを指定するために必要なパラメーターをパイントリクエスト内でどのように実行できるかについて説明します。
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).
リクエストユーザーがサービスを実行するように要求する場合、もちろん、どのようなサービスを指定する必要があります。これは、To：HeaderとRequest-URI内のURLで実行できます（セクション3.5.5.1を参照）。
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のパーティーを指定する必要があります。Aパーティーは、たとえば、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パーティを指定する必要があります（それぞれ宛先ファックスマシンの電話番号または話し言葉のコンテンツを配信する電話番号）が、Aパーティーは電話ネットワークベースのリソース（FAXまたはSpeech Transcoder/Senderのいずれか）、そして暗黙的です。要求しているユーザーは、それを指定していません（そしてできません）。
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パーティは、ファックスを送信したいファックスマシンの電話番号です。ただし、このバリアント内で、Aパーティは、特定のドキュメントを取得する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.
ファックスへのリクエストとハアーコンテンツリクエストサービスにより、トランスコードされるソース情報はインターネット上で保持されます。つまり、この情報はリクエスト自体とともに運ばれること、またはこの情報のソースへの参照が与えられることを意味します。
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.
さらに、サービスコールにFAXまたは音声が搭載され、可能な場合はソース情報の形式を指定することを主張するのが便利です。
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内でのみ重要である不透明な参照です。ドキュメントストア番号とドキュメント番号が一緒になって、FAXで実際のコンテンツを一意に指定します。
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.
コールフォーマットパラメーター値「音声」または「FAX」は、結果のサービスコールの種類を示しています。
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）であるか、メッセージが「インライン」であることを意味します。ソースインジケータ「または」は、渡される値が、メッセージの残りの部分と一緒に運ばれるべき不透明な参照であることを意味しますが、宛先（GSTN）コンテキスト内でのみ解釈されることです。別の方法として、「ファイル」スタイルを備えた「ローカル」リファレンスとして、または「HTTP」スタイルで部分的な参照を使用することもできます。ただし、そのような参照が解釈される方法は、受信パイントサーバーとエグゼクティブシステムの問題です。事実上、不透明な参照のままです。
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の観点から指定されているか、「インライン」に運ばれることを意味します。一部のデータの場合、形式は検査によって検出されるか、他のすべてが失敗した場合、URIから想定できることに注意してください（たとえば、URLのファイル拡張部分がデータ型を示していると仮定することで）。不透明なリファレンスの場合、ソース形式はインターネットでは使用できないため、与えられません。
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サービスリクエストを完全に指定するために必要なパラメーターが「パイント拡張」メッセージ内で実行される可能性があることについて説明します。他の選択肢があり、これらは排除されていません。ただし、要求するユーザーが予想されるサービスを確実に受信するためには、パラメーターとそのアテンダントエグゼクティブシステムに渡されたパラメーターと期待される動作について何らかの理解を共有する必要があります。
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要素として送信できます。したがって、パイントの招待状の最初の行は、次の形式です。
INVITE <serviceID>@<pint-server>.<domain> 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.
リクエストリクエストサービスのリクエストと「ファックスバック」バリアントのパーティーは、「to」ヘッダーフィールドに保持できます。この場合、「to：」ヘッダー値はリクエスト-URIとは異なります。Aパーティーが指定されていないサービスでは、「to」フィールドは、リクエスト-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 =」、 " - " - "またはサブタイプのいずれかとして保持されます。後者は通常、「 - 」フォームが使用される場合がある場合、コールへのリクエストまたは「ファックスバック」を除くすべてのサービスに必要です。前述のように、サービスのリクエストを生成するときにソース形式とソースが必ずしも必要ではありません。ただし、ソース形式仕様のすべてのリクエストに含めると、リクエストの解析がより簡単になり、将来他のサービスを指定できるため、値が常に与えられます。ソース形式のパラメーターは、セクション3.4.2で「メディアタイプ」要素としてカバーされています。
The source itself is identified by an "a=fmtp:" field value, where needed. With the exception of the Request-to-Call service, all invitations will normally include such a field. From the perspective of the SDP extensions, it can be considered as qualifying the media sub-type, as if to say, for example, "when I say jpeg, what I mean is the following".
ソース自体は、必要に応じて「a = fmtp：」フィールド値によって識別されます。コールへのリクエストサービスを除き、すべての招待状には通常、そのようなフィールドが含まれます。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
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] Handley、M.、Schooler、E.、Schulzrinne、H。、およびJ. Rosenberg、「SIP：セッション開始プロトコル」、RFC 2543、1999年3月。
[2] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley、M。and V. Jacobsen、「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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[4] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[5] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.
[5] Unicode Consortium、「Unicode Standard-バージョン2.0」、Addison-Wesley、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] Lu、H.、Krishnaswamy、M.、Conroy、L.、Bellovin、S.、Burg、F.、Desimone、A.、Tewani、K.、Davidson、P.、Schulzrinne、H。and K. Vishwanathan "PSTN/Internet Inter-Networking-PRE-PINT実装」、RFC 2458、1998年11月。
[8] ITU-T Study Group XI, "Q.763 - Formats and Codes for the ISDN User Part of SS No7" ITU-T, August 1994.
[8] ITU-T研究グループXI、「Q.763- SS NO7のISDNユーザー部分のフォーマットとコード」ITU-T、1994年8月。
[9] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[10] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[10] Crocker、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] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[13] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[13] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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.、Ford、W.、Polk W. and D. Solo、「Internet X.509公開キーインフラストラクチャ証明書とCRLプロファイル」、RFC 2459、1999年1月。
[15] Crocker, D. and P. Overall, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[15] Crocker、D。およびP.全体的に、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[16] Mills, D., "Network Time Protocol (version 3) specification and implementation", RFC 1305, March 1992.
[16] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様と実装」、RFC 1305、1992年3月。
[17] Eastlake, D., Crocker, S. and J.Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[17] Eastlake、D.、Crocker、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] Levinson、E。、「The Mime MultiPart/関連コンテンツタイプ」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.
著者は、この仕様の準備に役立つコメントについて、パイントワーキンググループのメンバーに感謝したいと考えています。Ian Elzのコメントは、内部PSTN操作の理解に非常に役立ちました。購読と通知のリクエストは、ヘニングシュルツリンヌとジョナサンローゼンバーグによって最初に提案されました。0のオーディオポートを使用して、電話が「保留中」であること（つまり、音声を受け取らない）がレイジブマンによるものであることを表現するための提案。最後に、Bernie Hoeneisenの密接な校正に感謝します。
Appendix A: Collected ABNF for PINT Extensions
付録A：パイント拡張機能のためにABNFを収集しました
;; --(ABNF is specified in RFC 2234 [15])
;; --Variations on SDP definitions
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
nettype = ("IN"/"TN")
; -- redefined as a superset of the SDP definition
addrtype = (INAddrType / TNAddrType)
; -- redefined as a superset of the SDP definition
INAddrType = ("IP4"/"IP6")
; -- this non-terminal added to hold original SDP address types
TNAddrType = ("RFC2543"/OtherAddrType)
OtherAddrType = (<X-Token>)
; -- X-token is as defined in RFC2045
addr = (<FQDN> / <unicast-address> / TNAddr)
; -- redefined as a superset of the original SDP definition
; -- FQDN and unicast address as specified in SDP
TNAddr = (RFC2543Addr/OtherAddr)
; -- TNAddr defined only in context of nettype == "TN"
RFC2543Addr = (INPAddr/LDPAddr)
INPAddr = "+" <POS-DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
; -- POS-DIGIT and DIGIT as defined in SDP
LDPAddr = <DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
OtherAddr = 1*<uric>
; -- OtherAdd defined in the context of OtherAddrType
; -- uric is as defined in 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
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)
proto = (INProto/TNProto)
; -- redefined as a superset of the original SDP definition
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"
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 "-".
attribute-fields = *("a=" attribute-list <CRLF>)
; -- redefined as a superset of the definition given in SDP
; -- CRLF is as defined in SDP
attribute-list = 1(PINT-attribute / <attribute>)
; -- attribute is as defined in SDP
PINT-attribute = (clir-attribute / q763-nature-attribute /
q763plan-attribute / q763-INN-attribute /
phone-context-attribute / tsp-attribute /
pint-fmtp-attribute / strict-attribute)
clir-attribute = clir-tag ":" ("true" / "false")
clir-tag = "clir"
q763-nature-attribute = Q763-nature-tag ":" q763-natures
Q763-Nature-Attribute = Q763-Nature-Tag "：" Q763-Natures
q763-nature-tag = "Q763-nature"
q763-natures = ("1" / "2" / "3" / "4")
q763-plan-attribute = Q763-plan-tag ":" q763-plans
q763-plan-tag = "Q763-plan"
q763-plans = ("1" / "2" / "3" / "4" / "5" / "6" / "7")
; -- of these, the meanings of 1, 3, and 4 are defined in the text
q763-INN-attribute = Q763-INN-tag ":" q763-INNs
Q763-inn-aTtribute = q763-inn-tag "：" q763-inns
q763-INN-tag = "Q763-INN"
q763-INNs = ("0" / "1")
phone-context-attribute = phone-context-tag ":" phone-context-ident
Phone-context-aTtribute = phone-context-tag "：" phone-context-ident
phone-context-tag = "phone-context"
phone-context-ident = network-prefix / private-prefix
network-prefix = intl-network-prefix / local-network-prefix
Network-Prefix = intl-network-prefix / local-network-prefix
intl-network-prefix = "+" 1*<DIGIT>
local-network-prefix = 1*<DIGIT>
private-prefix = 1*excldigandplus 0*<uric>
excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d))
tsp-attribute = tsp-tag "=" provider-domainname
tsp-tag = "tsp"
provider-domainname = <domain>
; -- domain is defined in 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
resolution = (uri-ref / opaque-ref / sub-part-ref)
uri-ref = uri-tag ":" <URI-Reference>
; -- URI-Reference defined in RFC2396
;-RFC2396で定義されたURI-Reference
uritag = "uri"
opaque-ref = opr-tag ":" 0*<uric>
opr-tag = "opr"
sub-part-ref = spr-tag ":" <Content-ID>
; -- Content-ID is as defined in RFC2046 and RFC822
spr-tag = "spr"
strict-attribute = "require:" att-tag-list
strict-aTtribute = "require：" att-tag-list
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
PINT-att-tag-list = (phone-context-tag / clir-tag /
q763-nature-tag / q763-plan-tag /
q763-INN-tag)
pint-fmtp-tag-list = (uri-tag / opr-tag / spr-tag)
;; --Variations on SIP definitions
clir-parameter = clir-tag "=" ("true" / "false")
q763-nature-parameter = Q763-nature-tag "=" Q763-natures
q763-nature-parameter = q763-nature-tag "=" q763-natures
q763plan-parameter = Q763-plan-tag "=" q763plans
q763plan-parameter = q763-plan-tag "=" q763plans
q763-INN-parameter = Q763-INN-tag "=" q763-INNs
q763-inn-parameter = q763-inn-tag "=" q763-inns
tsp-parameter = tsp-tag "=" provider-domainname
tsp-parameter = tsp-tag "=" Provider-domainname
phone-context-parameter = phone-context-tag "=" phone-context-ident
Phone-context-parameter = phone-context-tag "=" phone-context-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
PINT-param = ( clir-parameter / q763-nature-parameter /
q763plan-parameter / q763-INN-parameter/ tsp-parameter / phone-context-parameter )
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
Require-header = "require:" 1(required-extensions)
*("," required-extensions)
; -- NOTE this is redefined as a subset of the SIP definition
; -- (from RFC2543/section 6.30)
required-extensions = ("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に登録する必要があるパイント拡張機能に使用される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.
*このドキュメントのセクション3.4.2で説明されているように、メディア形式のサブタイプ。
*セクション3.4.3に記載されているプライベート属性
*セクション3.4.3.1で説明されているように、プライベート電話のコンテキスト値。
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.
プライベートアドレスタイプ（セクション3.4.1）は、Xトークンの形である必要があるため、このプロセスから明示的に除外されていることに注意する必要があります。
Taking these in turn, the media format sub-types are used within the PINT extensions to SDP to specify the attribute line that holds the data source definitions. In normal use, the values in this field are sub-types of MIME discrete types[4]. If a value other than an IANA-registered sub-type is to be used, then it should either be an X-Token (i.e. start with "X-") or it should be registered with IANA. if the intention is to describe a new MIME sub-type, then the procedures specified in RFC 2048 should be used. It is ASSUMED that any new MIME sub-type would follow the syntactic rules for interpretation of associated PINT fmtp lines defined in this document.
これらを順番に使用すると、メディア形式のサブタイプがPINT拡張機能内でSDPに使用され、データソースの定義を保持する属性行を指定します。通常の使用では、このフィールドの値はMIME離散タイプのサブタイプです[4]。IANA登録されたサブタイプ以外の値を使用する場合、Xトークン（つまり、「X-」で開始）であるか、IANAに登録する必要があります。新しいMIMEサブタイプを説明する意図がある場合、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内にデータソースの定義を含める新しい方法を定義する意図である場合、そのような新しい「パイントメディア形式のサブタイプ」登録をサポートするドキュメントで、関連するものの構文を指定する必要があります。識別子としての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の解釈がパイントのデフォルトに従っている場合、ここで与えられた構文定義を繰り返すのではなく、定義文書でこれを言及するのは適切です（ただし、この場合、このような新しい登録が必要な理由は不明です）。前と同様に、メディア形式のサブタイプは、それが定義されている「プロト」フィールドの値を指定する必要がありますが、これは「tnprotoのすべての値」になる可能性があります。
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で使用されているメカニズムと同じです。属性が1パイント内でのみ使用するために定義されている場合、サポートドキュメントでこれについて言及することが適切かもしれません。ここで説明されているパイント1.0仕様では、このような登録された属性行を「require：」節に追加するメカニズムはないことに注意してください。
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.
パイントリクエストに使用されるセッションの説明内で、電話コンテキスト属性を使用して、関連する電話番号（接続ライン内）を解釈するプレフィックスまたはコンテキストを指定することができます。
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.
「パブリック」電話のコンテキストの場合、使用するプレフィックスは、数字または「」で開始する必要があります。プライベート電話のコンテキストは、これらの文字のいずれからも始めない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はそうしません（プライベートネットワークがLucentが内部で使用していない限り）。
In addition, the supporting documentation MUST either declare that there is no associated token, or define the syntax by which that token can be parsed (e.g. vnd.fbi.gov <space> 1*DIGIT). Note that the registration describes a format, not a value range; it is sufficient that the private context can be parsed, without the value being interpreted.
さらに、サポートドキュメントは、関連するトークンがないことを宣言するか、そのトークンを解析できる構文を定義する必要があります（例：vnd.fbi.gov <sace> 1*桁）。登録は、値の範囲ではなく形式を記述していることに注意してください。値が解釈されることなく、プライベートコンテキストを解析できるだけで十分です。
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.
* 登録の種類（すなわち、パイントサービスリクエストのサービス説明内で使用するプライベート電話コンテキスト属性） *登録要求（名前、組織、電子メールアドレス、公開電話番号）の責任者の連絡先の詳細初期トークン名（例：vnd.fbi.gov） *プライベートコンテキストの構文（例： "vnd.fbi.gov" <Space> 1 * digit、または "vnd.gtn.gov.uk"） *使用の説明（e.g. ""この電話コンテキストは、関連する電話番号が「政府の通信ネットワーク」内にあると宣言しています。番号は内部またはプライベート番号計画フォームです） *ネットワークタイプとアドレスタイプがこのプライベートコンテキストが関連付けられています。タイプ（このドキュメントで指定）が使用されているように、値は「netType = tn」、addrtype = "rfc2543addr"として表示されます。ただし、このコンテキストが別のアドレスタイプで使用される場合、次に参照します。そのアドレスタイプ名とそのアドレス値の構文が必要です。
In short, this context is the telephone equivalent of a "Net 10" address space behind a NAT, and the initial name (and contact information) shows the context within which that address is valid. It also specifies the format for the network and address types (and address value syntax) with which this context is associated.
要するに、このコンテキストは、NATの背後にある「ネット10」アドレススペースに相当する電話であり、初期名（および連絡先情報）は、そのアドレスが有効なコンテキストを示しています。また、このコンテキストが関連付けられているネットワークとアドレスタイプ（およびアドレス値の構文）の形式も指定します。
Of course, IANA may refer the requested registration to the IESG or an appropriate IETF working group for review, and may require revisions to be made before the registration is accepted.
もちろん、IANAは、要求された登録をIESGまたは適切なIETFワーキンググループに紹介するために照会することができ、登録が受け入れる前に改訂を行う必要がある場合があります。
Authors' Addresses
著者のアドレス
Scott Petrack MetaTel, Inc. 45 Rumford Ave. Waltham MA 02453-3844
Scott Petrack Metatel、Inc。45 Rumford Ave. Waltham MA 02453-3844
Phone: +1 (781)-891-9000
EMail: scott.petrack@metatel.com
Lawrence Conroy Siemens Roke Manor Research Roke Manor Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN
ローレンス・コンロイ・シーメンス・ローク・マナー研究ローク・マナーオールド・ソールズベリー・レーン・ロンシー、ハンプシャー英国SO51 0ZN
Phone: +44 (1794) 833666
EMail: lwc@roke.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。