[要約] RFC 4458は、VoicemailやIVRなどのアプリケーションに使用されるSession Initiation Protocol (SIP) URIsに関する仕様です。このRFCの目的は、これらのアプリケーションのためのSIP URIの使用方法を定義することです。
Network Working Group C. Jennings
Request for Comments: 4458 Cisco Systems
Category: Informational F. Audet
Nortel Networks
J. Elwell
Siemens plc
April 2006
Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)
ボイスメールやインタラクティブな音声応答（IVR）などのアプリケーション用のセッション開始プロトコル（SIP）URIS
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications.
セッション開始プロトコル（SIP）は、ボイスメールやインタラクティブな音声認識システムなどのアプリケーションへの接続を開始するためによく使用されます。この仕様では、そのようなアプリケーションからのターゲットのリダイレクトに基づいて特定のサービスを要求するSIPサービスURIを設立するための条約について説明します。
Table of Contents
目次
1. Introduction ....................................................3
2. Mechanism (User Agent Server and Proxy) .........................4
2.1. Target .....................................................4
2.2. Cause ......................................................4
2.3. Retrieving Messages ........................................5
3. Interaction with Request History Information ....................5
4. Limitations of Voicemail URI ....................................6
5. Syntax ..........................................................6
6. Examples ........................................................7
6.1. Proxy Forwards Busy to Voicemail ...........................7
6.2. Endpoint Forwards Busy to Voicemail ........................9
6.3. Endpoint Forwards Busy to TDM via a Gateway ...............11
6.4. Endpoint Forwards Busy to Voicemail with History Info .....13
6.5. Zero Configuration UM System ..............................14
6.6. Call Coverage .............................................15
7. IANA Considerations ............................................15
8. Security Considerations ........................................16
8.1. Integrity Protection of Forwarding in SIP .................16
8.2. Privacy Related Issues on the Second Call Leg .............17
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................18
Many applications such as Unified Messaging (UM) systems and Interactive Voice Recognition (IVR) systems have been developed out of traditional telephony. They can be used for storing and interacting with voice, video, faxes, email, and instant messaging services. Users often use SIP to initiate communications with these applications. When a SIP call is routed to an application, it is necessary that the application be able to obtain several bits of information from the session initiation message so that it can deliver the desired services.
Unifiedメッセージング（UM）システムやインタラクティブな音声認識（IVR）システムなどの多くのアプリケーションは、従来の電話から開発されています。音声、ビデオ、ファックス、電子メール、インスタントメッセージングサービスの保存と対話に使用できます。ユーザーは多くの場合、SIPを使用してこれらのアプリケーションとの通信を開始します。SIPコールがアプリケーションにルーティングされる場合、アプリケーションがセッション開始メッセージからいくつかの情報を取得して、目的のサービスを提供できるようにする必要があります。
For the purpose of this document, we will use UM as the main example, but other applications may use the mechanism defined in this document. The UM needs to know what mailbox should be used and possible reasons for the type of service desired from the UM. Many voicemail systems provide different greetings depending whether the call went to voicemail because the user was busy or because the user did not answer. All of this information can be delivered in existing SIP signaling from the call control that retargets the call to the UM, but there are no conventions for describing how the desired mailbox and the service requested are expressed. It would be possible for every vendor to make this configurable so that any site could get it to work; however, this approach is unrealistic for achieving interoperability among call control, gateway, and unified messaging systems from different vendors. This specification describes a convention for describing this mailbox and service information in the SIP URI so that vendors and operators can build interoperable systems.
このドキュメントの目的のために、umを主な例として使用しますが、他のアプリケーションはこのドキュメントで定義されているメカニズムを使用する場合があります。UMは、どのメールボックスを使用すべきか、およびUMから望まれるサービスのタイプの可能性のある理由を知る必要があります。多くのボイスメールシステムは、ユーザーが忙しかったため、またはユーザーが応答しなかったために、通話がボイスメールにかかったかどうかに応じて、異なる挨拶を提供します。この情報はすべて、既存のSIPシグナリングで、UMへのコールをリターゲットするコールコントロールから配信できますが、要求されたサービスがどのように表現されるかを説明するための慣習はありません。すべてのベンダーがこれを構成可能にして、どのサイトを動作させることができるようにすることができます。ただし、このアプローチは、さまざまなベンダーからのコールコントロール、ゲートウェイ、統一されたメッセージングシステム間の相互運用性を達成するために非現実的です。この仕様では、ベンダーとオペレーターが相互運用可能なシステムを構築できるように、SIP URIでこのメールボックスとサービス情報を説明するための条約について説明します。
If there were no need to interoperate with Time Division Multiplexing (TDM)-based voicemail systems or to allow TDM systems to use VoIP unified messaging systems, this problem would be a little easier to solve. The problem that is introduced in the Voice over IP (VoIP) to TDM case is as follows. The SIP system needs to tell a Public Switched Telephone Network (PSTN) gateway both the subscriber's mailbox identifier (which typically looks like a phone number) and the address of the voicemail system in the TDM network (again a phone number).
時分割多重化（TDM）ベースのボイスメールシステムと相互運用する必要がない場合、またはTDMシステムがVoIP統合メッセージングシステムを使用できるようにする場合、この問題は解決が少し簡単です。Voice over IP（VoIP）からTDMケースに導入された問題は次のとおりです。SIPシステムは、サブスクライバーのメールボックス識別子（通常は電話番号のように見える）とTDMネットワーク内のボイスメールシステムのアドレス（再び電話番号）の両方の公開された電話ネットワーク（PSTN）ゲートウェイに指示する必要があります。
The question has been asked why the To header cannot be used to specify which mailbox to use. One problem is that the call control proxies cannot modify the To header, and the User Agent Clients (UACs) often set it incorrectly because they do not have information about the subscribers in the domain they are trying to call. This happens because the routing of the call often translates the URI multiple times before it results in an identifier for the desired user that is valid in the namespace that the UM system understands.
質問は、なぜ使用するメールボックスを指定するためにヘッダーを使用できない理由を尋ねられました。1つの問題は、コールコントロールプロキシがヘッダーを変更できないことであり、ユーザーエージェントクライアント（UACS）は、呼び出そうとしているドメイン内のサブスクライバーに関する情報がないため、しばしば誤って設定します。これは、コールのルーティングがURIを複数回変換することが多いために発生します。その後、UMシステムが理解している名前空間で有効な希望のユーザーの識別子になります。
The mechanism works by encoding the information for the desired service in the SIP Request-URI that is sent to the UM system. Two chunks of information are encoded, the first being the target mailbox to use and the second being the SIP status code that caused this retargeting and that indicates the desired service. The userinfo and hostport parts of the Request-URI will identify the voicemail service, the target mailbox can be put in the target parameter, and the reason can be put in the cause parameter. For example, if the proxy wished to use Bob's mailbox because his phone was busy, the URI sent to the UM system could be something like:
メカニズムは、UMシステムに送信されるSIPリクエスト-URIの目的のサービスの情報をエンコードすることにより機能します。2つの情報がエンコードされています。1つ目は使用するターゲットメールボックスであり、2つ目はこのリターゲティングを引き起こし、目的のサービスを示すSIPステータスコードです。Request-URIのuserInfoおよびHostport部分は、ボイスメールサービスを識別し、ターゲットメールボックスをターゲットパラメーターに配置し、理由を原因パラメーターに配置できます。たとえば、携帯電話が忙しかったためにプロキシがボブのメールボックスを使用したい場合、URIはUMシステムに送信される可能性があります。
sip:voicemail@example.com;target=bob%40example.com;cause=486
Target is a URI parameter that indicates the address of the retargeting entity: in the context of UM, this can be the mailbox number. For example, in the case of a voicemail system on the PSTN, the user portion will contain the phone number of the voicemail system, while the target will contain the phone number of the subscriber's mailbox.
ターゲットは、リターゲティングエンティティのアドレスを示すURIパラメーターです。UMのコンテキストでは、これはメールボックス番号になります。たとえば、PSTN上のボイスメールシステムの場合、ユーザー部分にはボイスメールシステムの電話番号が含まれ、ターゲットにはサブスクライバーのメールボックスの電話番号が含まれます。
Cause is a URI parameter that is used to indicate the service that the User Agent Server (UAS) receiving the message should perform. The following values for this URI parameter are defined:
原因は、メッセージを受信するユーザーエージェントサーバー（UAS）が実行するサービスを示すために使用されるURIパラメーターです。このURIパラメーターの次の値は定義されています。
+---------------------------------+-------+
| Redirecting Reason | Value |
+---------------------------------+-------+
| Unknown/Not available | 404 |
| User busy | 486 |
| No reply | 408 |
| Unconditional | 302 |
| Deflection during alerting | 487 |
| Deflection immediate response | 480 |
| Mobile subscriber not reachable | 503 |
+---------------------------------+-------+
The mapping to PSTN protocols is important both for gateways that connect the IP network to existing TDM customer's equipment, such as Private Branch Exchanges (PBXs) and voicemail systems, and for gateways that connect the IP network to the PSTN network. Integrated Services Digital Network User Part (ISUP) has signaling encodings for this information that can be treated as roughly equivalent for the purposes here. For this reason, this specification uses the names of Redirecting Reason values defined in ITU-T Q.732.2-5 [8]. In this specification, the Redirecting Reason Values are referred to as "Causes". It should be understood that the term "Cause" has nothing to do with PSTN "Cause values" (as per ITU-T Q.850 [9] and RFC 3398 [5]) but are instead mapped to ITU-T Q.732.2-5 Redirecting Reasons. Since ISUP interoperates with other PSTN networks, such as Q.931 [10] and QSIG [11], using well-known rules, it makes sense to use the ISUP names as the most appropriate superset. If no appropriate mapping to a cause value defined in this specification exists in a network, it would be mapped to 302 "Unconditional". Similarly, if the mapping occurs from one of the causes defined in this specification to a PSTN system that does not have an equivalent reason value, it would be mapped to that network's equivalent of "Unconditional". If a new cause parameter needs to be defined, this specification will have to be updated.
PSTNプロトコルへのマッピングは、IPネットワークを既存のTDM顧客の機器に接続するゲートウェイ（PBXS）やボイスメールシステムなど、IPネットワークをPSTNネットワークに接続するゲートウェイの両方にとって重要です。統合サービスデジタルネットワークユーザーパーツ（ISUP）には、この情報のシグナリングエンコーディングがあり、ここではほぼ同等のものとして扱われます。このため、この仕様では、ITU-T Q.732.2-5で定義されたリダイレクト理由値の名前を使用しています[8]。この仕様では、リダイレクト理由値が「原因」と呼ばれます。「原因」という用語は、PSTN「原因値」とは何の関係もないことを理解する必要があります（ITU-T Q.850 [9]およびRFC 3398 [5]）が、代わりにITU-T Q.732.2にマッピングされます-5理由のリダイレクト。ISUPは、Q.931 [10]やQSIG [11]などの他のPSTNネットワークと相互運用するため、よく知られているルールを使用して、ISUP名を最も適切なスーパーセットとして使用することは理にかなっています。この仕様で定義されている原因値への適切なマッピングがネットワークに存在しない場合、302「無条件」にマッピングされます。同様に、マッピングが、この仕様で定義された原因の1つから、同等の理由値を持たないPSTNシステムに発生すると、そのネットワークの「無条件」に相当するものにマッピングされます。新しい原因パラメーターを定義する必要がある場合、この仕様を更新する必要があります。
The user portion of the URI SHOULD be used as the address of the voicemail system on the PSTN, while the target SHOULD be mapped to the original redirecting number on the PSTN side.
URIのユーザー部分は、PSTN上のボイスメールシステムのアドレスとして使用する必要がありますが、ターゲットはPSTN側の元のリダイレクト番号にマッピングする必要があります。
The redirection counters SHOULD be set to one unless additional information is available.
追加情報が利用可能でない限り、リダイレクトカウンターは1に設定する必要があります。
The UM system MAY use the fact that the From header is the same as the URI target as a hint that the user wishes to retrieve messages.
UMシステムは、From HeaderがURIターゲットと同じであり、ユーザーがメッセージを取得したいというヒントとして使用する場合があります。
The Request History mechanism [6] provides more information relating to multiple retargetings. It is reasonable to have systems in which both the information in this specification and the History information are included and one or both are used.
リクエスト履歴メカニズム[6]は、複数のリターゲットに関する詳細情報を提供します。この仕様の情報と履歴情報の両方が含まれ、1つまたは両方が使用されるシステムがあることが合理的です。
History-Info specifies a means of providing the UAS and UAC with information about the retargeting of a request. This information includes the initial Request-URI and any retarget-to URIs. This information is placed in the History-Info header field, which, except where prevented by privacy considerations, is built up as the request progresses and, upon reaching the UAS, is returned in certain responses.
History-INFOは、リクエストのリターゲティングに関する情報をUASとUACに提供する手段を指定します。この情報には、最初のリクエスト-URIとリッカートゥウリスが含まれます。この情報は、プライバシーの考慮事項によって防止されている場合を除き、リクエストが進行するにつれて構築され、UASに到達すると特定の回答で返されると構築されます。
History-Info, when deployed at relevant SIP entities, is intended to provide a comprehensive trace of retargeting for a SIP request, along with the SIP response codes that led to retargeting.
History-INFOは、関連するSIPエンティティに展開された場合、SIPリクエストのリターゲティングの包括的なトレースと、リターゲティングにつながったSIP応答コードを提供することを目的としています。
History-Info can complement this specification. In particular, when a proxy inserts a URI containing the parameters defined in this specification into the Request-URI of a forwarded request, the proxy can also insert a History-Info header field entry into the forwarded request, and the URI in that entry will incorporate these parameters. Therefore, even if the Request-URI is replaced as a result of rerouting by a downstream proxy, the History-Info header field will still contain these parameters, which may be of use to the UAS. Consequently, UASes that make use of this information may find the information in the History-Info header and/or in the Request-URI, depending on the capability of the proxy to support generation of History-Info or on the behavior of downstream proxies; therefore, applications need to take this into account.
history-infoはこの仕様を補完できます。特に、プロキシがこの仕様で定義されたパラメーターを転送リクエストのリクエスト-URIに定義するパラメーターを含むURIを挿入すると、プロキシは履歴INFOヘッダーフィールドエントリを転送リクエストに挿入することもできます。これらのパラメーターを組み込みます。したがって、ダウンストリームプロキシによる再ルーティングの結果としてリクエスト-URIが置き換えられたとしても、History-INFOヘッダーフィールドには、UASに使用される可能性のあるこれらのパラメーターがまだ含まれています。したがって、この情報を使用するUASEは、履歴INFOのヘッダーおよび/またはリクエスト-URIで情報を見つけることができます。したがって、アプリケーションを考慮する必要があります。
This specification requires the proxy that is requesting the service to understand whether the UM system it is targeting supports the syntax defined in this specification. Today, this information is provided to the proxy by configuration. For practical purposes, this means that the approach is unlikely to work in cases in which the proxy is not configured with information about the UM system or in which the UM is not in the same administrative domain.
この仕様には、ターゲットとなっているUMシステムがこの仕様で定義されている構文をサポートするかどうかを理解するためにサービスを要求しているプロキシが必要です。今日、この情報は構成ごとにプロキシに提供されています。実用的な目的のために、これは、プロキシがUMシステムに関する情報や同じ管理ドメインにない情報でプロキシが構成されていない場合にアプローチが機能する可能性が低いことを意味します。
This approach only works when the service that the call control wants applied is fairly simple. For example, it does not allow the proxy to express information like "Do not offer to connect to the target's colleague because that address has already been tried".
このアプローチは、コールコントロールが適用したいサービスがかなり簡単な場合にのみ機能します。たとえば、プロキシは、「その住所がすでに試されているため、ターゲットの同僚に接続することを申し出ないでください」などの情報を表現することはできません。
The limitations discussed in this section are addressed by History-Info [6].
このセクションで説明されている制限は、歴史INFO [6]によって対処されています。
The ABNF[4] grammar for these parameters is shown below. The definitions of pvalue and Status-Code are defined in the ABNF in RFC 3261[1].
これらのパラメーターのABNF [4]文法を以下に示します。PValueとステータスコードの定義は、RFC 3261 [1]のABNFで定義されています。
target-param = "target" EQUAL pvalue
ターゲットパラム= "ターゲット"等しいpvalue
cause-param = "cause" EQUAL Status-Code
case-param = "原因"等しいステータスコード
Note that the ABNF requires some characters to be escaped if they occur in the value of the target parameters. For example, the "@" character needs to be escaped.
ABNFは、ターゲットパラメーターの値で発生する場合、一部の文字を逃れる必要があることに注意してください。たとえば、「@」文字を逃れる必要があります。
This section provides some example use cases for the solution proposed in this document. For the purpose of this document, UM is used as the main example, but other applications may use this mechanism. The examples are intended to highlight the potential applicability of this solution and are not intended to limit its applicability.
このセクションでは、このドキュメントで提案されているソリューションのユースケースの例を示します。このドキュメントの目的のために、UMは主な例として使用されますが、他のアプリケーションはこのメカニズムを使用する場合があります。この例は、このソリューションの潜在的な適用性を強調することを目的としており、その適用性を制限することを意図していません。
Also, the examples show just service retargeting on busy, but can easily be adapted to show other forms of retargeting.
また、この例は、忙しいときにリターゲティングするだけのサービスを示していますが、他の形のリターゲティングを表示するために簡単に適応できます。
In several of the examples, the URIs are broken across more than one line. This was only done for formatting and is not a valid SIP message. Some of the characters in the URIs are not correctly escaped to improve readability. The examples are all shown using sip: with UDP transport, for readability. It should be understood that using sips: with TLS transport is preferable.
いくつかの例では、URIは複数の行で壊れています。これはフォーマットのためにのみ行われ、有効なSIPメッセージではありません。URIの一部のキャラクターは、読みやすさを改善するために正しく逃げられていません。例はすべて、SIPを使用して表示されます。UDPトランスポートを使用して、読みやすくします。SIPを使用することを理解する必要があります：TLSトランスポートを使用することが望ましい。
In this example, Alice calls Bob. Bob's proxy determines that Bob is busy, and the proxy forwards the call to Bob's voicemail. Alice's phone is at 192.0.2.1, while Bob's phone is at 192.0.2.2. The important thing to note is the URI in message F7.
この例では、アリスはボブに電話します。ボブの代理は、ボブが忙しいと判断し、プロキシはボブのボイスメールへの呼び出しを転送します。アリスの電話は192.0.2.1で、ボブの電話は192.0.2.2です。注意すべき重要なことは、メッセージF7のURIです。
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 486 Busy F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDPがここに行く*
F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:+15555551002@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDPがここに行く*
F4: 486 192.0.2.2 -> proxy.example.com
SIP/2.0 486 Busy Here
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Content-Length: 0
F7: INVITE proxy.example.com -> um.example.com
INVITE sip:voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDPがここに行く*
In this example, Alice calls Bob. Bob is busy, but forwards the session directly to his voicemail. Alice's phone is at 192.0.2.1, while Bob's phone is at 192.0.2.2. The important thing to note is the URI in the Contact in message F3.
この例では、アリスはボブに電話します。ボブは忙しいですが、セッションをボイスメールに直接転送します。アリスの電話は192.0.2.1で、ボブの電話は192.0.2.2です。注意すべき重要なことは、メッセージF3の連絡先のURIです。
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | 302 Moved F3 | |
| 302 Moved F4 |<-------------| |
|<---------------| | |
| ACK F5 | | |
|--------------->| ACK F6 | |
| |------------->| |
| INVITE F7 |
|-------------------------------------------------->|
* Rest of flow not shown *
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDPがここに行く*
F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDPがここに行く*
F3: 302 192.0.2.2 -> proxy.example.com
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486;>
Content-Length: 0
F7: INVITE proxy.example.com -> um.example.com
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDPがここに行く*
In this example, the voicemail is reached via a gateway to a TDM network. Bob's number is +1 555 555-1002, while voicemail's number on the TDM network is +1-555-555-2000.
この例では、TDMネットワークへのゲートウェイを介してボイスメールに到達します。ボブの番号は1 555 555-1002ですが、TDMネットワーク上のボイスメール番号は1-555-555-2000です。
The call flow is the same as in Section 6.2 except for the Contact URI in F4 and the Request URI in F7.
コールフローは、F4の接触URIとF7のリクエストURIを除き、セクション6.2と同じです。
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 302 Moved F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *
F4: 486 192.0.2.2 -> proxy.example.com
SIP/2.0 302 Moved temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486>
Content-Length: 0
F7: INVITE proxy.example.com -> gw.example.com
INVITE sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486\
SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDPがここに行く*
This example illustrates how History Info works in conjunction with service retargeting. The scenario is the same as Section 6.1.
この例は、履歴情報がサービスのリターゲティングと組み合わせてどのように機能するかを示しています。シナリオはセクション6.1と同じです。
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDPがここに行く*
F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4>;index=1.1
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here* F7: INVITE proxy.example.com -> um.example.com
* SDPがここに行く* F7：proxy.example.comを招待 - > um.example.com
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4?Reason=SIP%3Bcause%3D302;\
text="Moved Temporarily">;index=1.1
<sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486>;index=2
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDPがここに行く*
In this example, the UM system has no configuration information specific to any user. The proxy is configured to pass a URI that provides the prompt to play and an email address in the user portion of the URI to which the recorded message is to be sent.
この例では、UMシステムには、任意のユーザーに固有の構成情報がありません。プロキシは、録音されたメッセージが送信されるURIのユーザー部分に再生されるプロンプトと電子メールアドレスを提供するURIを渡すように構成されています。
The call flow is the same as in Section 6.1, except that the URI in F7 changes to specify the user part as Bob's email address, and the Netann [7] URI play parameter specifies where the greeting to play can be fetched from.
コールフローはセクション6.1と同じですが、F7のURIがボブのメールアドレスとしてユーザーパーツを指定することを除いて、Netann [7] URI Playパラメーターは、プレイする挨拶がどこからフェッチできるかを指定します。
F7: INVITE proxy.example.com -> voicemail.example.com
INVITE sip:voicemail@example.com;target=mailto:bob%40example.com;\
cause=486;play=http://www.example.com/bob/busy.wav SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15555551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDPがここに行く*
In addition, if the proxy wished to indicate a Voice XML (VXML) script that the UM should execute, it could add a parameter to the URI in the above message that looked like:
さらに、ProxyがUMが実行するVoice XML（VXML）スクリプトを示したい場合、上記のメッセージのURIにパラメーターを追加することができます。
voicexml=http://www.example.com/bob/busy.vxml
VoiceXml = http：//www.example.com/bob/busy.vxml
In a Call Coverage example, a user on the PSTN calls an 800 number. The gateway sends this to the proxy, which recognizes that the helpdesk is the target. Alice and Bob are staffing the help desk and are tried sequentially, but neither answers, so the call is forwarded to the helpdesk's voicemail.
コールカバレッジの例では、PSTNのユーザーが800番号を呼び出します。ゲートウェイはこれをプロキシに送ります。これは、ヘルプデスクがターゲットであることを認識しています。アリスとボブはヘルプデスクに人員配置されており、連続して試されますが、どちらも答えられないため、コールはヘルプデスクのボイスメールに転送されます。
The details of this flow are trivial and not shown. The key item in this example is that the INVITE to Alice and Bob looks as follows:
このフローの詳細は些細なものであり、示されていません。この例の重要な項目は、アリスとボブへの招待状が次のように見えることです。
INVITE sip:voicemail@example.com;target=helpdesk%40example.com;\
cause=302 SIP/2.0
This specification adds two new values to the IANA registration in the "SIP/SIPS URI Parameters" registry as defined in [3].
この仕様は、[3]で定義されている「SIP/SIPS URIパラメーター」レジストリのIANA登録に2つの新しい値を追加します。
Parameter Name Predefined Values Reference
____________________________________________
target No [RFC4458]
cause Yes [RFC4458]
This document discusses transactions involving at least three parties, which increases the complexity of the privacy issues.
このドキュメントでは、少なくとも3つの当事者が関与するトランザクションについて説明し、プライバシーの問題の複雑さを高めます。
The new URI parameters defined in this document are generally sent from a Proxy or call control system to a Unified Messaging (UM) system or to a gateway to the PSTN and then to a voicemail system. These new parameters tell the UM what service the proxy wishes to have performed. Just as any message sent from the proxy to the UM needs to be integrity protected, these messages need to be integrity protected to stop attackers from, for example, causing a voicemail meant for a company's CEO to go to an attacker's mailbox. RFC 3261 provides a TLS mechanism suitable for performing this integrity protection.
このドキュメントで定義されている新しいURIパラメーターは、通常、プロキシまたはコールコントロールシステムから、統一されたメッセージング（UM）システムまたはPSTNへのゲートウェイ、およびボイスメールシステムに送信されます。これらの新しいパラメーターは、プロキシが実行したいサービスをumに伝えます。プロキシからUMに送信されたメッセージが整合性保護される必要があるように、これらのメッセージは、攻撃者が攻撃者を阻止するために整合性保護される必要があります。たとえば、企業のCEOが攻撃者のメールボックスに行くことを目的としています。RFC 3261は、この整合性保護の実行に適したTLSメカニズムを提供します。
The signaling from the Proxy to the UM or gateway will reveal who is calling whom and possibly some information about a user's presence based on whether the call was answered or sent to voicemail. This information can be protected by encrypting the SIP traffic between the Proxy and UM or gateway. Again, RFC 3261 contains mechanisms for accomplishing this using TLS.
プロキシからUMまたはゲートウェイへの信号は、誰が誰を呼んでいるか、そしておそらく通話が応答されたかボイスメールに送信されたかに基づいてユーザーの存在に関する情報を明らかにします。この情報は、プロキシとUMまたはゲートウェイの間のSIPトラフィックを暗号化することで保護できます。繰り返しますが、RFC 3261には、TLSを使用してこれを達成するためのメカニズムが含まれています。
Implementations should implement and use TLS.
実装は、TLSを実装および使用する必要があります。
The forwarding of a call in SIP brings up a very strange trust issue. Consider the normal case -- A calls B and the call gets forwarded to C by a network element in B's domain, and then C answers the call. A has called B but ended up talking to C. This scenario may be hard to separate from a man-in-the-middle attack.
SIPでの呼び出しの転送は、非常に奇妙な信頼の問題を引き起こします。通常のケースを考慮してください-A呼び出しBとコールは、Bのドメインのネットワーク要素によってCに転送され、Cは呼び出しに応答します。AはBと呼ばれていますが、Cと話すことになりました。このシナリオは、中間の攻撃から分離するのが難しいかもしれません。
There are two possible solutions. One is that B sends back information to A saying don't call me, call C, and signs it as B. The problem is that this solution involves revealing that B has forwarded to C, which B often may not want to do. For example, B may be a work phone that has been forwarded to a mobile or home phone. The user does not want to reveal their mobile or home phone number but, even more importantly, does not want to reveal that they are not in the office.
可能な解決策が2つあります。1つは、Bが情報を格言に送り返さないで、Cに電話したり、Cに電話したり、Bとして署名したりすることです。問題は、このソリューションがBがCに転送したことを明らかにすることであることです。たとえば、Bは、携帯電話や自宅の電話に転送された作業電話である場合があります。ユーザーは携帯電話番号や自宅の電話番号を明らかにしたくありませんが、さらに重要なことには、オフィスにいないことを明らかにしたくありません。
The other possible solution is that A needs to trust B only to forward to a trusted identity. This requires a hop-by-hop transitive trust such that each hop will only send to a trusted next hop and each hop will only do things that the user at that hop desired. This solution is enforced in SIP using the SIPS URI and TLS-based hop-by-hop security. It protects from an off-axis attack, but if one of the hops is not trustworthy, the call may be diverted to an attacker.
もう1つの可能な解決策は、Aは信頼できるアイデンティティに転送するためだけにBを信頼する必要があることです。これには、各ホップが信頼できる次のホップにのみ送信し、各ホップがそのホップのユーザーが望むことのみを行うように、ホップバイホップの透明信頼が必要です。このソリューションは、SIPS URIおよびTLSベースのホップバイホップセキュリティを使用してSIPで実施されます。それは軸外攻撃から保護しますが、ホップの1つが信頼できない場合、攻撃者に電話が迂回される可能性があります。
Any redirection of a call to an attacker's mailbox is serious. It is trivial for an attacker to make its mailbox seem very much like the real mailbox and forward the messages to the real mailbox so that the fact that the messages have been intercepted or even tampered with escapes detection. Approaches such as the SIPS URL and the History-Info[6] can help protect against these attacks.
攻撃者のメールボックスへの呼び出しのリダイレクトは深刻です。攻撃者がメールボックスを実際のメールボックスに非常によく似ており、メッセージを実際のメールボックスに転送するようにすることは些細なことです。そうすれば、メッセージがエスケープ検出で傍受または改ざんさえされているという事実があります。SIPS URLやHistory-INFO [6]などのアプローチは、これらの攻撃から保護するのに役立ちます。
In the case where A calls B and gets redirected to C, occasionally people suggest that there is a requirement for the call leg from B to C to be anonymous. The SIP case is not the PSTN, and there is no call leg from B to C; instead, there is a VoIP session between A and C. If A has put a To header field value containing B in the initial invite message, unless something special is done about it, C would see that To header field value. If the person who answers phone C says "I think you dialed the wrong number; who were you trying to reach?", A will probably specify B.
Aがbを呼び出してCにリダイレクトされる場合、時には人々は、bからCへのコールレッグが匿名であることを要件があることを示唆します。SIPケースはPSTNではなく、BからCへのコールレッグはありません。代わりに、AとCの間にVOIPセッションがあります。Aが最初の招待メッセージにBを含むヘッダーフィールド値を配置した場合、それについて特別なことが行われない限り、Cはヘッダーフィールド値を確認します。電話cに答えた人が「間違った番号をダイヤルしたと思う、誰が到達しようとしているのか」と言ったら、おそらくBを指定します。
If A does not want C to see that the call was to B, A needs a special relationship with the forwarding Proxy to induce it not to reveal that information. The call should go through an anonymization service that provides session or user level privacy (as described in RFC 3323 [2]) service before going to C. It is not hard to figure out how to meet this requirement, but it is unclear why anyone would want this service.
aがCに呼び出しがBであることを確認したくない場合、Aはその情報を明らかにしないように誘導するために、転送プロキシとの特別な関係が必要です。コールは、Cに行く前にセッションまたはユーザーレベルのプライバシー（RFC 3323 [2]で説明されている）サービスを提供する匿名化サービスを通過する必要があります。このサービスが必要です。
The scenario in which B wants to make sure that C does not see that the call was to B is easier to deal with but a bit weird. The usual argument is that Bill wants to forward his phone to Monica but does not want Monica to find out his phone number. It is hard to imagine that Monica would want to accept all Bill's calls without knowing how to call Bill to complain. The only person Monica will be able to complain to is Hillary, when she tries to call Bill. Several popular web portals will send SMS alert messages about things like stock prices and weather to mobile phone users today. Some of these contain no information about the account on the web portal that initiated them, making it nearly impossible for the mobile phone owner to stop them. This anonymous message forwarding has turned out to be a really bad idea even where no malice is present. Clearly some people are fairly dubious about the need for this, but never mind: let's look at how it is solved.
bがCがCOLLであることを確認していないことを確認したいシナリオは、bに対処するのが簡単ですが、少し奇妙です。通常の議論は、ビルが自分の電話をモニカに転送したいが、モニカに彼の電話番号を見つけたくないということです。モニカがビルの電話をかけて文句を言う方法を知らずに、すべてのビルの電話を受け入れたいと思うことを想像するのは難しいです。モニカが不平を言うことができるのは、ビルに電話しようとするとき、ヒラリーだけです。いくつかの人気のあるWebポータルは、今日の携帯電話ユーザーに株価や天気などに関するSMSアラートメッセージを送信します。これらのいくつかには、それらを開始したWebポータル上のアカウントに関する情報が含まれていないため、携帯電話の所有者がそれらを停止することはほとんど不可能です。この匿名のメッセージ転送は、悪意が存在しない場合でも本当に悪い考えであることが判明しました。明らかに、一部の人々はこれの必要性についてかなり疑っていますが、気にしないでください。それがどのように解決されているかを見てみましょう。
In the general case, the proxy needs to route the call through an anonymization service and everything will be cleaned up. Any anonymization service that performs the "Privacy: Header" Service in RFC 3323 [2] must remove the cause and target URI parameters from the URI. Privacy of the parameters, when they form part of a URI within the History-Info header, is covered in History-Info [6].
一般的なケースでは、プロキシは匿名化サービスを通じてコールをルーティングする必要があり、すべてがクリーンアップされます。RFC 3323 [2]で「プライバシー：ヘッダー」サービスを実行する匿名サービスは、URIから原因とターゲットURIパラメーターを削除する必要があります。パラメーターのプライバシーは、歴史INFOヘッダー内でURIの一部を形成する場合、History-INFOでカバーされています[6]。
This specification does not discuss the security considerations of mapping to a PSTN Gateway. Security implications of mapping to ISUP, for example, are discussed in RFC 3398 [5].
この仕様では、PSTNゲートウェイへのマッピングに関するセキュリティ上の考慮事項については説明していません。たとえば、ISUPへのマッピングのセキュリティへの影響については、RFC 3398 [5]で説明しています。
Many thanks to Mary Barnes, Steve Levy, Dean Willis, Allison Mankin, Martin Dolly, Paul Kyzivat, Erick Sasaki, Lyndsay Campbell, Keith Drage, Miguel Garcia, Sebastien Garcin, Roland Jesske, Takumi Ohba, and Rohan Mahy.
メアリー・バーンズ、スティーブ・レヴィ、ディーン・ウィリス、アリソン・マンキン、マーティン・ドリー、ポール・キジバット、エリック・ササキ、リンズー・キャンベル、キース・ドレイジ、ミゲル・ガルシア、セバスチャン・ガルシン、ローランド・ジェスケ、タクミ・オーバ、ロハン・マヒに感謝します。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[2] ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[3] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[3] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字権権（IANA）のユニフォームリソース識別子（URI）パラメーターレジストリを割り当てました」、BCP 99、RFC 3969、2004年12月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[4] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[5] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[5] Camarillo、G.、Roach、A.、Peterson、J。、およびL. Ong、「Integrated Services Digital Network（ISDN）ユーザーパーツ（ISUP）セッション開始プロトコル（SIP）マッピング」、RFC 3398、2002年12月。
[6] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[6] Barnes、M。、「リクエスト履歴情報のセッション開始プロトコル（SIP）の拡張」、RFC 4244、2005年11月。
[7] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[7] Burger、E.、van Dyke、J。、およびA. Spitzer、「SIP付きの基本ネットワークメディアサービス」、RFC 4240、2005年12月。
[8] "Stage 3 description for call offering supplementary services using signalling system No. 7: Call diversion services", ITU-T Recommendation Q.732.2-5, December 1999.
[8] 「シグナリングシステムを使用した補足サービスの提供のステージ3説明7：Call Diversion Services」、ITU-Tの推奨Q.732.2-5、1999年12月。
[9] "Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part", ITU-T Recommendation Q.850, May 1998.
[9] 「デジタルサブスクライバーシグナリングシステムNo. 1およびシグナリングシステムNo. 7 ISDNユーザーパーツの原因と位置の使用」、ITU-T推奨Q.850、1998年5月。
[10] "ISDN user-network interface layer 3 specification for basic call control", ITU-T Recommendation Q.931, May 1998.
[10] 「ISDNユーザーネットワークインターフェイスレイヤー3基本コールコントロールの仕様」、ITU-T推奨Q.931、1998年5月。
[11] "Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Circuit mode bearer services - Inter-exchange signalling procedures and protocol", ISO/IEC 11572, March 2000.
[11] 「情報技術 - システム間の電気通信と情報交換 - プライベート統合サービスネットワーク - サーキットモードベアラーサービス - 交換シグナル伝達手順とプロトコル」、ISO/IEC 11572、2000年3月。
Authors' Addresses
著者のアドレス
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose, CA 95134 USA
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose、CA 95134 USA
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Francois Audet Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US
フランソワオーデットノーテルネットワーク4655グレートアメリカパークウェイサンタクララ、カリフォルニア州95054米国
Phone: +1 408 495 3756
EMail: audet@nortel.com
John Elwell Siemens plc Technology Drive Beeston, Nottingham NG9 1LA UK
ジョンエルウェルシーメンスPLCテクノロジードライブビーストン、ノッティンガムNG9 1LA UK
EMail: john.elwell@siemens.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。