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)
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).
著作権（C）インターネット協会（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.
そのようなユニファイドメッセージング（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から目的のサービスの種類の理由を使用し、可能なすべきか、メールボックスを知っている必要があります。多くのボイスメールシステムは、ユーザーがビジーまたはユーザーが応答しなかったためであったため、コールがボイスメールに行ったかどうかによって異なる挨拶を提供しています。この情報の全ては、UMへの呼び出しを再ターゲティング呼制御から既存のSIPシグナリングに送達することができるが、所望のメールボックスと、要求されたサービスを表現する方法を説明するための規則は存在しません。いずれかのサイトはそれが仕事を得ることができるように、すべてのベンダーが、これは設定可能にすることが可能です。しかし、このアプローチは、コール制御、ゲートウェイ、および異なるベンダーからのユニファイドメッセージングシステム間の相互運用性を実現するためには非現実的です。この仕様は、ベンダーや事業者が相互運用可能なシステムを構築できるように、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のユニファイドメッセージングシステムを使用できるようにする必要はありませんでした場合は、この問題が解決することが少し楽になります。次のようにTDMの場合にボイスオーバーIP（VoIP）の中に導入される問題があります。 SIPシステムは、公衆交換電話網（PSTN）教えて加入者のメールボックス（通常、電話番号のように見える）の識別子とTDMネットワーク内のボイスメールシステムのアドレス（再度、電話番号）の両方をゲートウェイする必要があります。
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.
ヘッダするために使用するメールボックスを指定するために使用することはできませんなぜ質問が尋ねてきました。一つの問題は、呼制御プロキシはToヘッダー変更できないことである、と彼らは呼び出ししようとしているドメイン内の加入者についての情報を持っていないので、ユーザエージェントクライアント（求めるUAC）は、多くの場合、間違って設定します。それはUMシステムが理解する名前空間の有効な目的のユーザの識別子になり前のコールのルーティングは、多くの場合、URIを複数回変換するためです。
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およびこのリターゲットを引き起こし、それが所望のサービスを示すSIPステータスコードである第2。リクエスト-URIのuserinfoをとホスト側の部分は、ターゲットメールボックスがターゲットパラメータに入れることができ、その理由は、原因パラメータに入れることができ、ボイスメールサービスを識別します。プロキシが彼の電話が混雑していたために、ボブのメールボックスを使用することを望む場合たとえば、URIは次のようなものになる可能性がUMシステムに送信しました：
sip:voicemail@example.com;target=bob%40example.com;cause=486
SIP：voicemail@example.com;ターゲット=ボブ％40example.com;原因= 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プロトコルへのマッピングは、PBX（構内交換機）やボイスメールシステムなどのTDMお客様の機器を、既存のIPネットワークを接続するゲートウェイ用とPSTNネットワークにIPネットワークを接続するゲートウェイの両方が重要です。総合デジタル通信網ユーザ部（ISUP）は、ここでの目的のためにとほぼ同等に処理することができ、この情報のためのエンコーディングのシグナリングました。この理由のため、本明細書は、ITU-T Q.732.2-5 [8]で定義される理由値をリダイレクトの名前を使用します。本明細書では、リダイレクト理由値は、「原因」と呼ばれています。 （[5]、[9]及びRFC 3398 ITU-T Q.850通り）という用語は、「原因」PSTN「Cause値」とは何の関係もないことが理解されるべきではなくITU-T Q.732.2にマッピングされます-5理由をリダイレクトします。 ISUPは、Q.931 [10]およびQSIGのような他のPSTNネットワーク、[11]と相互運用するため、周知の規則を使用して、それが最も適切なスーパーセットとしてISUP名を使用することが理にかなっています。本明細書で定義される理由値への適切なマッピングがネットワーク内に存在しない場合、それは302、「無条件」にマッピングされることになります。マッピングは同等の理由値を有していない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.
ターゲットはPSTN側の元のリダイレクト番号にマッピングされるべきであるURIのユーザ部分は、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ヘッダー、ユーザーがメッセージを取得することを希望するヒントとして、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]は複数retargetingsに関するより多くの情報を提供します。なお、本明細書に記載されている情報と履歴情報の両方が含まれており、一方または両方が使用されているシステムを持つことが合理的です。
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.
履歴情報は、要求のターゲット変更に関する情報をUASとUACを提供する手段を指定します。この情報は、初期のRequest-URIおよび任意の宛先再-へのURIが含まれています。この情報は、要求が進むにつれて、プライバシーの配慮によって防止する場合を除いて、構築された、歴史-Infoヘッダーフィールドに置かれると、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.
歴史・情報関連の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.
歴史-情報は、この仕様書を補完することができます。プロキシがRequest-URI転送要求の中に、本明細書で定義されたパラメータを含むURIを挿入したとき、特に、プロキシは、そのエントリに転送された要求に履歴-Infoヘッダフィールドのエントリ、およびURIを挿入することができますこれらのパラメーターを組み込みます。したがって、リクエストURIが下流プロキシによって再ルーティングの結果として、置換されていても、履歴-Infoヘッダフィールドは依然としてUASに有用であり得るこれらのパラメータを含むであろう。したがって、この情報を利用するUASes歴史-INFOまたは下流のプロキシの挙動上の生成をサポートするためのプロキシの能力に応じて、および/またはリクエストURIに履歴-Infoヘッダ内の情報を検索することができます。そのため、アプリケーションはこれを考慮に入れる必要があります。
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システムに関するまたは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].
この項で説明する制限は歴史-情報[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]文法を以下に示します。 p値とステータスコードの定義は、RFC 3261でABNFで定義されている[1]。
target-param = "target" EQUAL pvalue
ターゲット-PARAM = "ターゲット" EQUAL値
cause-param = "cause" EQUAL Status-Code
原因-PARAM = "原因" EQUALステータスコード
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の中の文字の一部が正しく読みやすさを向上させるためにエスケープされません。 UDPトランスポートで、読みやすくするために：例では、すべてのSIPを使用して示されています。 TLSの輸送に好適である：SIPを使用することを理解すべきです。
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.2である一方、アリスの携帯電話は、192.0.2.1です。注意すべき重要なことは、メッセージ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
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*
SIP INVITE：+15555551002@example.comを、ユーザー=電話のSIP / 2.0経由：SIP / 2.0 / TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9から：アリス<SIP：+15551001@example.com;ユーザー=電話>;タグ= 9fxced76slへ：SIP：+15555551002@example.com;ユーザー=電話-ID：c3x842276298220188511のCSeq：マックス・フォワードを1 INVITE：70お問い合わせ：<SIP：alice@192.0.2.1>のContent-Type：アプリケーション/ SDPのContent-Length：*ボディの長さはここに*
* SDP goes here*
* SDPはここに*
F2: INVITE proxy.example.com -> 192.0.2.2
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*
SIPのINVITE：+15555551002@192.0.2.2 SIP / 2.0経由：SIP / 2.0 / TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1経由：SIP / 2.0 / TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9タグ= 9fxced76sl：SIP：+15555551002@example.com;ユーザー=電話番号：アリス<;ユーザー=電話+15551001@example.com SIP：>からc3x842276298220188511のCSeq：マックス・フォワードを1 INVITE：70お問い合わせ：<SIP：alice@192.0.2.1>のContent-Type：アプリケーション/ SDPのContent-Length：*ボディの長さはここに*
* SDP goes here*
* SDPはここに*
F4: 486 192.0.2.2 -> proxy.example.com
P-4：486 192.0.o 2 - > Broxa.ksmpel.kom
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
SIP / 2.0 / TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9：アリス<SIP SIP / 2.0 / TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1経由：経由SIP / 2.0ここでビジー486： +15551001@example.com;ユーザー=電話>;、タグ= 9fxced76sl：SIP：+15555551002@example.com;ユーザー=電話;タグは= 09xde23d80コールID：c3x842276298220188511のCSeq：コンテンツ長をINVITE 1：0
F7: INVITE proxy.example.com -> um.example.com
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*
SIP INVITE：voicemail@example.comを; \ターゲット=一口：+ 15555551002% 40example.com;ユーザー=電話; \原因= 486 SIP / 2.0経由：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から：アリス<SIP：+15551001@example.com;ユーザー=電話>;タグ= 9fxced76slに：SIP：+ 15555551002例@。 COM;ユーザー=電話-ID：c3x842276298220188511のCSeq：マックス・フォワードを1 INVITE：70お問い合わせ：<SIP：alice@192.0.2.1>のContent-Type：アプリケーション/ SDPのContent-Length：*ボディの長さは*ここに行きます
* 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.2である一方、アリスの携帯電話は、192.0.2.1です。注意すべき重要なことは、メッセージ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
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*
SIP INVITE：+15555551002@example.comを、ユーザー=電話のSIP / 2.0経由：SIP / 2.0 / TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9から：アリス<SIP：+15551001@example.com;ユーザー=電話>;タグ= 9fxced76slへ：SIP：+15555551002@example.com;ユーザー=電話-ID：c3x842276298220188511のCSeq：マックス・フォワードを1 INVITE：70お問い合わせ：<SIP：alice@192.0.2.1>のContent-Type：アプリケーション/ SDPのContent-Length：*ボディの長さはここに*
* SDP goes here*
* SDPはここに*
F2: INVITE proxy.example.com -> 192.0.2.2
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*
SIPのINVITE：line1@192.0.2.2のSIP / 2.0経由：SIP / 2.0 / TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1経由：SIP / 2.0 / TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9から：アリス<SIP：+15551001@example.com;ユーザー=電話>;タグ= 9fxced76slへ：SIP：+15555551002@example.com;ユーザー=電話-ID：c3x842276298220188511のCSeq：マックス・フォワードを1 INVITE：70お問い合わせ： <一口：alice@192.0.2.1>のContent-Type：アプリケーション/ SDPのContent-Length：*ボディの長さはここに*
* SDP goes here*
* SDPはここに*
F3: 302 192.0.2.2 -> proxy.example.com
有効：302 192.0.o 2 - > Broxa.ksmpel.kom
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
SIP / 2.0 302は、ビア一時的に移動：SIP / 2.0 / TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1経由：SIP / 2.0 / TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9をから：アリス<SIP： +15551001@example.com;ユーザー=電話>;、タグ= 9fxced76sl：SIP：+15555551002@example.com;ユーザー=電話;タグは= 09xde23d80コールID：c3x842276298220188511のCSeq：連絡先を招待1：<SIP：ボイスメールの例@ .COM; \ターゲットは= SIP：+ 15555551002%の40example.com;ユーザー=電話; \原因= 486;>のContent-Length：0
F7: INVITE proxy.example.com -> um.example.com
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*
SIP INVITE：voicemail@example.comを; \ターゲット=一口：+ 15555551002% 40example.com;ユーザー=電話; \原因= 486 SIP / 2.0経由：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から：アリス<SIP：+15551001@example.com;ユーザー=電話>;タグ= 9fxced76slに：SIP：+ 15555551002例@。 COM;ユーザー=電話-ID：c3x842276298220188511のCSeq：マックス・フォワードを1 INVITE：70お問い合わせ：<SIP：alice@192.0.2.1>のContent-Type：アプリケーション/ SDPのContent-Length：*ボディの長さは*ここに行きます
* 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ネットワークへのゲートウェイを介して達成されます。 TDMネットワーク上のボイスメールの数は、+ 1-555-555-2000いる間にボブの数は、1 555 555から1002です。
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
P-4：486 192.0.o 2 - > Broxa.ksmpel.kom
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
SIP / 2.0 302は、ビア一時的に移動：SIP / 2.0 / TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1経由：SIP / 2.0 / TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9をから：アリス<SIP： +15551001@example.com;ユーザー=電話>;、タグ= 9fxced76sl：SIP：+15555551002@example.com;ユーザー=電話;タグは= 09xde23d80コールID：c3x842276298220188511のCSeq：連絡先を1 INVITE：<SIP：+ 15555552000 @ example.com;ユーザー=電話; \ターゲット= TEL：+15555551002;原因= 486>のContent-Length：0
F7: INVITE proxy.example.com -> gw.example.com
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*
SIP INVITE：+15555552000@example.comを、ユーザー=電話; \ターゲット= TEL：15555551002;原因= 486 \ SIP / 2.0経由：SIP / 2.0 / TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2経由し：SIP / 2.0 / TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9から：アリス<SIP：+15551001@example.com;ユーザー=電話>;タグ= 9fxced76slに：SIP：+15555551002@example.com、ユーザ=電話-ID：c3x842276298220188511のCSeq：マックス・フォワードを1 INVITE：70お問い合わせ：<SIP：alice@192.0.2.1;運輸= TCP>のContent-Type：アプリケーション/ SDPのContent-Length：*ボディの長さは*ここに行くを
* 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
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*
SIP INVITE：+15555551002@example.comを、ユーザー=電話のSIP / 2.0経由：SIP / 2.0 / TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9から：アリス<SIP：+15551001@example.com;ユーザー=電話>;タグ= 9fxced76slへ：SIP：+15555551002@example.com;ユーザー=電話-ID：c3x842276298220188511のCSeq：マックス・フォワードを1 INVITE：70お問い合わせ：<SIP：alice@192.0.2.1>歴史-情報：<一口：+15555551002@example.com;ユーザー=電話>;インデックス= 1つのContent-Type：アプリケーション/ SDPのContent-Length：*ボディの長さは*ここに行きます
* SDP goes here*
* SDPはここに*
F2: INVITE proxy.example.com -> 192.0.2.2
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
SIPのINVITE：line1@192.0.2.2のSIP / 2.0経由：SIP / 2.0 / TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1経由：SIP / 2.0 / TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9から：アリス<SIP：+15551001@example.com;ユーザー=電話>;タグ= 9fxced76slへ：SIP：+15555551002@example.com;ユーザー=電話-ID：c3x842276298220188511のCSeq：マックス・フォワードを1 INVITE：70お問い合わせ： <一口：alice@192.0.2.1>歴史-情報：<SIP：+15555551002@example.com;ユーザー=電話>;指数= 1、<SIP：line1@192.0.2.4>;指数= 1.1
Content-Type: application/sdp Content-Length: *Body length goes here*
コンテンツタイプ：アプリケーション/ SDPのContent-Length：*ボディの長さはここに*
* SDP goes here*
* SDPはここに*
F7: INVITE proxy.example.com -> um.example.com
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> 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*
SIP INVITE：voicemail@example.comを; \ターゲット=一口：+ 15555551002% 40example.com;ユーザー=電話; \原因= 486 SIP / 2.0経由：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から：アリス<SIP：+15551001@example.com;ユーザー=電話>;タグ= 9fxced76slに：SIP：+ 15555551002例@。 COM;ユーザー=電話-ID：c3x842276298220188511のCSeq：マックス・フォワードを1 INVITE：70お問い合わせ：<SIP：alice@192.0.2.1>歴史-情報：<SIP：+15555551002@example.com;ユーザー=電話>;インデックス= 1、：インデックス= 1.1 <一口<一口line1@192.0.2.4理由= SIPの％3Bcause％3D302; \テキスト= "一時的に移動"？>：voicemail@example.com; \ターゲット= SIP：+ 15555551002%の40example .COM;ユーザー=電話; \原因= 486>;インデックス= 2連絡先：<SIP：alice@192.0.2.1>のContent-Type：アプリケーション/ SDPのContent-Length：*ボディの長さは*ここに行きます
* 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.
コールフローは、F7の変化でURIがボブの電子メール・アドレスなどのユーザー部分を指定することを除いて、6.1節と同じであり、かつNetann [7] URIは、パラメータをプレイする。挨拶から取り出すことができる場所を指定します。
F7: INVITE proxy.example.com -> voicemail.example.com
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*
SIP INVITE：voicemail@example.comを、ターゲット=のmailto：ボブ％40example.com; \原因= 486;果たし=のhttp：//www.example.com/bob/busy.wavのSIP / 2.0経由：SIP / 2.0 / TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2経由：SIP / 2.0 / TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9から：アリス<SIP：+15555551001@example.com;ユーザー=電話>;タグ=へ9fxced76sl：SIP：+15555551002@example.com;ユーザー=電話-ID：c3x842276298220188511のCSeq：1 INVITEマックス・フォワード：70お問い合わせ：<SIP：alice@192.0.2.1>のContent-Type：アプリケーション/ SDPコンテンツ-length：*ボディの長さは*ここに行きます
* 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:
プロキシがUMが実行すべきことをボイス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が見えることです。
INVITE sip:voicemail@example.com;target=helpdesk%40example.com;\ cause=302 SIP/2.0
SIP INVITE：voicemail@example.comと、目標=ヘルプデスク％40example.com; \原因= 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]で定義されているこの仕様は、IANAに登録への2つの新しい値を追加し、レジストリ「SIP / URIパラメータをSIPS」。
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と呼ばれるが、このシナリオは、man-in-the-middle攻撃から分離するのは難しいかもしれ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つの解決策があります。一つは、Bが、問題は、このソリューションは、Bは、Bが頻繁にやりたくないかもしれませんCに転送していることを明らかに含むことであることわざに情報を送り返す私を呼び出すことはありません、Cを呼び出し、およびBとの兆候それをということです。例えば、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.
他の可能な解決策は、Aのみ、信頼できるアイデンティティに転送するためにBを信頼する必要があるということです。これは、各ホップが唯一信頼できる次のホップに送信されますと、各ホップのみをそのホップのユーザが希望という事を行いますようにホップバイホップ推移性の信頼関係が必要です。この溶液をSIPS URIとTLSベースのホップバイホップセキュリティを使用して、SIPに適用されます。これは、オフアクシスの攻撃から保護しますが、ホップのいずれかが信頼できない場合は、呼び出しが攻撃者に流用することができます。
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や歴史、情報としてのアプローチは、[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は特別な何かがそれについて行われていない限り、最初にBを含むToヘッダーフィールド値は、招待メッセージを入れている場合は代わりに、AとCの間のVoIPセッションがあり、Cはそれがフィールド値をヘッダにはを参照してくださいます。電話Cに答える人が言うならば、「私はあなたが間違った番号をダイヤルしたと思います。誰があなたが到達しようとしていた？」、Aは、おそらく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.に行く前に（[2] RFC 3323で説明したように）セッションまたはユーザーレベルのプライバシーを提供して匿名化サービスを経る必要があり、それは、なぜ誰も不明ですこのサービスを望みます。
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は、コールが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の一部を形成するパラメータのプライバシー、履歴-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.
メアリー・バーンズ、スティーブ・レヴィ、ディーンウィリス、アリソンマンキン、マーティン・ドリー、ポールKyzivat、エリック佐々木、リンゼー・キャンベル、キース糖剤、ミゲル・ガルシア、セバスチャンGarcin、ローランドJesske、匠大場、およびローハンマーイに感謝します。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[2]ピーターソン、J.、RFC 3323 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"、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]カマリロ、G.、BCP 99、RFC 3969、2004年12月 "セッション開始プロトコル（SIP）のための番号機関（IANA）のURI（Uniform Resource Identifier）パラメータレジストリの割り当てインターネット"。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[4]クロッカー、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]カマリロ、G.、ローチ、A.、ピーターソン、J.、およびL.オングを、 "総合デジタル通信網（ISDN）ユーザ部（ISUP）セッション開始プロトコル（SIP）へのマッピング"、RFC 3398、12月2002。
[6] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[6]バーンズ、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]バーガー、E.、ヴァン・ダイク、J.、およびA.スピッツァー、 "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]「シグナリングシステム番号7を使用して付加サービスを提供するためのコールステージ3の説明：転換サービスを呼び出す」、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]、ITU-T勧告Q.850、1998年5月「デジタル加入者線信号方式番号1及びシグナリングシステム7号ISDNユーザパートにおける原因と場所の使用法」。
[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
カレンジェニングスシスコシステムズ170西タスマンドライブメールストップSJC-2分の21サンノゼ、CA 95134 USA
Phone: +1 408 421-9990 EMail: fluffy@cisco.com
電話：+1 408 421-9990 Eメール：fluffy@cisco.com
Francois Audet Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US
フランソワAudet Nortel Networksの4655グレートアメリカパークウェイサンタクララ、カリフォルニア州95054米国
Phone: +1 408 495 3756 EMail: audet@nortel.com
電話：+1 408 495 3756 Eメール：audet@nortel.com
John Elwell Siemens plc Technology Drive Beeston, Nottingham NG9 1LA UK
ジョンエルウェルシーメンスのPLC技術ドライブビーストン、ノッティンガムNG9 1LA英国
EMail: john.elwell@siemens.com
メールアドレス：john.elwell@siemens.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。