Independent Submission S. Levy
Request for Comments: 5806 Cisco Systems
Category: Historic M. Mohali, Ed.
ISSN: 2070-1721 Orange Labs
March 2010
Diversion Indication in SIP
Abstract
抽象
This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for later Informational RFCs. The original Abstract follows.
SIPワーキンググループにもともと提出されたインターネットドラフトのテキストが含まれています。このRFCは、歴史的な記録のために今、公開されていると、後で情報RFCの基準を提供します。オリジナルの要旨は次の通りです。
This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent.
この文書では、セッション開始プロトコル（SIP）の拡張を提案しています。この拡張は、コールが転送され、なぜコールが転送された誰から識別するために呼び出されるSIPユーザエージェントのための機能を提供します。拡張は、呼び出されたユーザエージェントに他のSIPユーザエージェントとプロキシから迂回情報を伝える一般的なヘッダ、宛先を定義します。
This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies that receive diversion information may use this as supplemental information for feature invocation decisions.
この拡張は、ユニファイドメッセージング、サードパーティ製ボイスメール、および自動着信分配（ACD）を含むさまざまな機能、サポートの強化が可能になります。迂回路情報を受信SIPユーザエージェントとSIPプロキシは、機能の起動の決定のために、このように補足情報を使用することができます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントはインターネット標準化過程仕様ではありません。それは歴史的な記録のために公開されています。
This document defines a Historic Document for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのための歴史的な文書を定義します。これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5806.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5806で取得することができます。
IESG Note
IESG注意
This document contains an early proposal to the IETF SIP Working Group that was not chosen for standardization. Discussions on the topic resulted in the informational RFC 3325, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", and the standard solution that was chosen can be found in RFC 4244, "An Extension to the Session Initiation Protocol (SIP) for Request History Information".
この文書では、標準化のために選ばれていなかったIETF SIPワーキンググループへの早期の提案が含まれています。トピックに関する議論は、情報提供RFC 3325で「信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張機能」、およびRFC 4244で見つけることができる選ばれた標準溶液、「セッションへの拡張をもたらしリクエスト履歴情報のため開始プロトコル（SIP）」。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
2.1. Requirements Language ......................................4
2.2. Definitions ................................................4
2.3. Abbreviations ..............................................5
3. Overview ........................................................5
3.1. When Is the Diversion Header Used? .........................6
4. Extension Syntax ................................................6
5. Detailed Semantics ..............................................7
5.1. UAS Behavior ...............................................7
5.2. UAC Behavior ...............................................7
5.3. Redirect Server Behavior ...................................7
5.4. Proxy Server Behavior ......................................7
6. Examples Using Diversion Header .................................8
6.1. Call Forward Unconditional .................................8
6.2. Call Forward on Busy ......................................13
6.3. Call Forward on No-Answer .................................17
6.4. Call Forward on Unavailable ...............................21
6.5. Multiple Diversions .......................................24
7. Security Considerations ........................................27
8. Further Examples ...............................................27
8.1. Night Service/Automatic Call Distribution (ACD)
Using Diversion Header ....................................27
8.2. Voicemail Service Using Diversion Header ..................36
8.3. Questions and Answers on Alternative Approaches ...........41
9. Mapping ISUP/ISDN Redirection Information to SIP
Diversion Header ...............................................42
9.1. Mapping ISUP/ISDN Diversion Reason Codes ..................42
9.2. Mapping ISUP Redirection Information to SIP
Diversion Header ..........................................43
9.3. Mapping ISDN Redirection Information to SIP
Diversion Header ..........................................47
9.4. Information Loss in SIP to ISUP/ISDN Translation ..........52
10. Contributors ..................................................53
11. Acknowledgements ..............................................53
12. Normative References ..........................................53
This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for later Informational RFCs.
SIPワーキンググループにもともと提出されたインターネットドラフトのテキストが含まれています。このRFCは、歴史的な記録のために今、公開されていると、後で情報RFCの基準を提供します。
In the legacy telephony network, redirection information is passed through the network in ISDN/ISUP (ISDN User Part) signaling messages. This information is used by various service providers and business applications to support enhanced features for the end user.
レガシーテレフォニーネットワークでは、リダイレクト情報は、シグナリングメッセージをISDN / ISUP（ISDNユーザ部）でのネットワークを通過します。この情報は、エンドユーザーのための拡張機能をサポートするために、さまざまなサービスプロバイダーやビジネスアプリケーションで使用されています。
An analogous mechanism of providing redirection information would enable such enhanced features for SIP users.
リダイレクト情報を提供する類似したメカニズムは、SIPユーザのため、このような拡張機能を可能にします。
The Diversion header allows implementation of feature logic based on from whom the call was diverted.
Diversionヘッダーは、コールが転送された誰からに基づく特徴・ロジックの実装を可能にします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
diversion:
転換：
A change to the ultimate destination endpoint of a request. A change in the Request-URI of a request that was not caused by a routing decision. This is also sometimes called a deflection or redirection.
リクエストの最終的な宛先エンドポイントに変更。ルーティング決定によって引き起こされていなかったリクエストのRequest-URIの変化。これはまた、時々、たわみやリダイレクションと呼ばれています。
A diversion can occur when the "user" portion of the Request-URI is changed for a reason other than expansion or translation.
転換は、Request-URIの「ユーザ」部分は、膨張又は翻訳以外の理由で変更されたときに起こり得ます。
A diversion can occur when only the "host" portion of the Request-URI has changed if the change was due to a non-routing decision.
転換は、変更が非ルーティングの決定によるものであった場合のRequest-URIの唯一の「ホスト」の部分が変更されたときに発生する可能性があります。
divertor:
ダイバータ：
The entity that diverted the call.
コールを流用するエンティティ。
recursing:
再帰：
A SIP proxy or user agent that handles a received or internally generated 3xx response by forking new request(s) itself.
新しい要求（S）自体をフォークによって受信または内部生成された3xx応答を処理するSIPプロキシまたはユーザエージェント。
non-recursing:
非再帰：
A SIP proxy or user agent that handles a received or internally generated 3xx response by forwarding it upstream.
上流それを転送することによって受信または内部生成された3xx応答を処理するSIPプロキシまたはユーザエージェント。
CFUNC: Call Forward Unconditional
CFUNC：フォワード無条件に電話
CFTOD: Call Forward Time-of-Day
CFTOD：コールフォワード時間帯
CFB: Call Forward on Busy
CFB：ビジーに電話転送
CFNA: Call Forward on No Answer
CFNA：無回答で電話転送
CFUNV: Call Forward Unavailable
CFUNV：利用不可電話転送
ACD: Automatic Call Distribution
ACD：自動着信分配
In order to implement certain third-party features such as Third-Party Voicemail and Automatic Call Distribution (ACD) applications, diversion information needs to be given to the called third party so that he may respond to the caller intelligently. In these situations, the party receiving a diverted call needs answers for two questions:
こうしたサードパーティ製ボイスメールと自動着信分配（ACD）アプリケーションなどの特定のサードパーティの機能を実装するためには、迂回路情報は、彼がインテリジェントに、発信者に応答することができるようにと呼ばれる第三者に与えられる必要があります。このような状況では、流用呼び出しを受けた当事者は二つの質問に対しての答えを必要とします：
Question 1: From whom was the request diverted?
質問1：誰からの要求が転用されたのですか？
Question 2: Why was the request diverted?
質問2：なぜリクエストが転用されたのですか？
This document proposes usage of the Diversion header to answer these questions for the party receiving the diverted call.
この文書では、流用コールを受信パーティーのためにこれらの質問に答えるためのDiversionヘッダーの使用を提案しています。
Insertion of the previous Request-URI (before the diversion occurred) into the Diversion header answers question 1.
宛先ヘッダ回答に以前のRequest-URI（転用発生前）の挿入は、1質問します。
Insertion of the "reason" tag into the Diversion header (by the divertor) answers question 2.
（ダイバータによって）宛先ヘッダに「理由」タグの挿入は、質問2に答えます。
The Diversion header SHOULD be added when a SIP proxy server, SIP redirect server, or SIP user agent changes the ultimate endpoint that will receive the call.
SIPプロキシサーバ、SIPリダイレクト・サーバ、またはSIPユーザエージェントは、呼を受信する究極のエンドポイントを変更したときに宛先ヘッダが追加されるべきです。
Diversion information SHOULD NOT be added for normal call routing changes to the Request-URI. Thus, the Diversion header is not added when features such as speed dial change the Request-URI.
迂回路情報は、Request-URIに、通常のコールルーティングの変更を追加しないでください。そのような短縮ダイヤルなどの機能がRequest-URIを変更したときしたがって、宛先ヘッダが付加されません。
When a diversion occurs, a Diversion header SHOULD be added to the forwarded request or forwarded 3xx response. The Diversion header MUST contain the Request-URI of the request prior to the diversion. The Diversion header SHOULD contain a reason that the diversion occurred.
転換が発生した場合、宛先ヘッダは、転送された要求または転送3xx応答に追加する必要があります。宛先ヘッダ前転換への要求のリクエストURIを含まなければなりません。宛先ヘッダは、迂回が発生した理由を含むべきです。
Existing Diversion headers received in an incoming request MUST NOT be removed or changed in forwarded requests.
着信要求で受信した既存の宛先ヘッダは、転送された要求に除去または変更してはなりません。
Existing Diversion headers received in an incoming response MUST NOT be removed or changed in the forwarded response.
着信応答して受信された既存の宛先ヘッダは、転送応答して削除または変更してはなりません。
A Diversion header is added when features such as call forwarding or call deflection change the Request-URI.
宛先ヘッダは、コール転送またはコールたわみなどの機能がRequest-URIを変更したときに追加されます。
The syntax of the Diversion header is:
宛先ヘッダの構文は次のとおりです。
Diversion = "Diversion" ":" 1# (name-addr *( ";" diversion_params )) diversion-params = diversion-reason | diversion-counter | diversion-limit | diversion-privacy | diversion-screen | diversion-extension diversion-reason = "reason" "=" ( "unknown" | "user-busy" | "no-answer" | "unavailable" | "unconditional" | "time-of-day" | "do-not-disturb" | "deflection" | "follow-me" | "out-of-service" | "away" | token | quoted-string ) diversion-counter = "counter" "=" 1*2DIGIT diversion-limit = "limit" "=" 1*2DIGIT diversion-privacy = "privacy" "=" ( "full" | "name" | "uri" | "off" | token | quoted-string ) diversion-screen = "screen" "=" ( "yes" | "no" | token | quoted-string ) diversion-extension = token ["=" (token | quoted-string)]
流用= "転用" "：" 1＃（名-addrには*（ ";" diversion_params））流用-のparams =迂回-理由|流用カウンター|流用制限|流用-プライバシー|流用画面|流用拡張迂回-理由= "理由" "="（ "不明" | "ユーザー・ビジー" | "無応答" | "利用不可" | "無条件" | "時刻" |「DO-ありません-disturb「| 『たわみ』 | 『フォローミー』 | 『アウトオブサービス』 | 『離れ』 |トークン|引用符で囲まれた文字列）流用カウンタ= 『カウンター』 『=』 1 * 2DIGIT流用制限=」リミット " "=" 1 * 2DIGIT流用-プライバシー= "プライバシー" "="（ "フル" | "名前" | "URI" | "オフ" |トークン|引用符で囲まれた文字列）流用スクリーン= "画面"" = "（ "YES" | "NO" |トークン|引用符で囲まれた文字列）流用-延長=トークン[" =」（トークン|引用符で囲まれた文字列）]
The following is an extension of tables 4 and 5 in [RFC3261] for the
Diversion header:
where enc. e-e ACK BYE CAN INV OPT REG
_____________________________________________________________
Diversion R h - - - o - -
Diversion 3xx h - - - o - -
A SIP User Agent Service (UAS) that receives a request and returns a 3xx SHOULD add a Diversion header containing the previous Request-URI and the reason for the diversion.
要求を受信し、3XXは、以前のRequest-URIおよび迂回の理由を含む宛先ヘッダを追加すべきである返すSIPユーザエージェントサービス（UAS）。
A SIP UAC that receives a 3xx containing a Diversion header SHOULD copy the Diversion header into each downstream forked request that resulted from the 3xx.
3XXから生じた各下流二股要求に宛先ヘッダをコピーする必要があり迂回ヘッダを含む3XXを受信SIP UAC。
A SIP redirect server that receives a request and returns a 3xx containing a Contact that diverts the request to a different endpoint SHOULD add a Diversion header containing the Request-URI from the incoming request and the reason for the diversion.
要求を受信し、着信要求と迂回理由からのRequest-URIを含む宛先ヘッダを追加すべきである別のエンドポイントに要求を分岐接触を含む3XXを返すSIPリダイレクトサーバ。
A non-recursing SIP proxy that receives a 3xx containing a Diversion header SHOULD forward the 3xx containing the Diversion header upstream unchanged.
宛先ヘッダーを含む3XXを受信する非再帰のSIPプロキシは、上流不変宛先ヘッダを含む3XXを転送すべきです。
A SIP proxy that receives a request and invokes a feature that changes the Request-URI of the forwarded request in order to divert the request to a different endpoint SHOULD add a Diversion header containing the Request-URI from the incoming request and the reason for the diversion.
要求を受信し、着信要求からのRequest-URIおよび理由を含む宛先ヘッダを追加すべきである別のエンドポイントに要求をそらすために、転送要求のリクエストURIを変更する機能を呼び出すSIPプロキシ流用。
A SIP proxy that receives a request and returns a 3xx containing a Contact that diverts the request to a different endpoint SHOULD add a Diversion header containing the Request-URI from the incoming request and the reason for the diversion.
要求を受信し、着信要求と迂回理由からのRequest-URIを含む宛先ヘッダを追加すべきである別のエンドポイントに要求を分岐接触を含む3XXを返すSIPプロキシ。
if (pdu.is_request()) {
if (request-URI is changed due to a called feature) {
if (proxy.is_recursing()) {
Add the Diversion header (indicating the reason
that the call has been diverted) to
the downstream forwarded request(s).
} else {
Add the Diversion header (indicating the reason
that the call has been diverted) to
the upstream forwarded 3xx response.
}
}
} else if (pdu.is_response()) {
if (pdu.is_3xx()) {
if (proxy.is_recursing()) {
Copy Diversion header into forwarded INVITE(s).
} else {
Forward response upstream.
}
}
}
There are several implementations of call forwarding features that can be implemented by either recursing or non-recursing SIP proxies or SIP user agents.
再帰または非再帰SIPプロキシまたはSIPユーザエージェントのどちらかで実現することができるコール転送機能のいくつかの実装があります。
A SIP proxy or user agent that generates or forwards 3xxs upstream is non-recursing. A SIP proxy or user agent that handles received (or internally generated) 3xxs itself is recursing.
SIPプロキシまたは生成または転送上流3xxsユーザエージェントは、非再帰です。 SIPプロキシまたは受信（又は内部で生成）処理ユーザエージェントは、それ自体を3xxs再帰れます。
The following examples illustrate usage of the Diversion header for some of the variants of recursing and non-recursing proxies and user agents.
以下の実施例は、再帰と非再帰プロキシとユーザエージェントの変異体の一部のための宛先ヘッダの使用を示します。
Usage of the Diversion header is shown below for several variant implementations of Call Forward Unconditional.
宛先ヘッダの使用は、コール転送無条件のいくつかのバリアントの実装については、以下に示されます。
In this message flow, the call would normally be routed to Bob@B. However, Proxy 2 (P2) recursively implements Call Forward Unconditional (CFUNC) to Carol@C.
このメッセージ・フローでは、呼び出しが正常にボブの@ Bにルーティングされることになります。しかし、プロキシ2（P2）は、再帰的にキャロル@ Cにコール転送無条件（CFUNC）を実装しています。
+------------------------+
| Bob@P2: CFUNC->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INVITE Carol@C------->|
| | | Diversion: Bob@P2 |
| | | ;reason=unconditional
| | | | |
| | |<-200-------------------|
| | | | |
| |<-200---------| | |
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
6.1.2. Network Call Forward Unconditional (P1 Non-Recursing, P2 Non-Recursing)
6.1.2. ネットワークコール転送無条件（P1非再帰的、P2ない-再帰的）
In this message flow, Proxy 2 (P2) non-recursively implements Call Forward Unconditional (CFUNC) to Carol@C. Proxy 1 (P1) is non-recursing.
このメッセージフローでは、プロキシ2（P2）は、非再帰的キャロル@ Cにコール転送無条件（CFUNC）を実装します。プロキシ1（P1）は、非再帰です。
+------------------------+
| Bob@P2: CFUNC->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
non-recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=unconditional | |
| | | | |
| |--ACK-------->| | |
| | | | |
|<-302---------| | | |
| Contact: Carol@C | | |
| Diversion: Bob@P2 | | |
| ;reason=unconditional | | |
| | | | |
|--ACK-------->| | | |
| | | | |
|--INVITE Carol@C------------------------------------->|
| Diversion: Bob@P2 | | |
| ;reason=unconditional | | |
| | | | |
|<-200-------------------------------------------------|
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
6.1.3. Network Call Forward Unconditional (P1 Recursing, P2 Non-Recursing)
6.1.3. ネットワークコール転送無条件（P1再帰、P2非再帰的に）
In this message flow, Proxy 2 (P2) non-recursively implements Call Forward Unconditional (CFUNC) to Carol@C. Proxy 1 (P1) is recursing.
このメッセージフローでは、プロキシ2（P2）は、非再帰的キャロル@ Cにコール転送無条件（CFUNC）を実装します。プロキシ1（P1）が再帰されます。
+------------------------+
| Bob@P2: CFUNC->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=unconditional | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@P2 | |
| | ;reason=unconditional | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
6.1.4. Endpoint Call Forward Unconditional (P1 Recursing, P2 Non-Recursing)
6.1.4. エンドポイントのコールフォワード無条件（P1再帰、P2非再帰的に）
In this message flow, user agent server B (B) non-recursively implements Call Forward Unconditional (CFUNC) to Carol@C. Proxy 2 (P2) is non-recursing. Proxy 1 (P1) is recursing.
このメッセージフローでは、ユーザエージェントサーバB（B）は、非再帰的キャロル@ Cにコール転送無条件（CFUNC）を実装します。プロキシ2（P2）は、非再帰です。プロキシ1（P1）が再帰されます。
+-----------------------+
| Bob@B: CFUNC->Carol@C |
+------+----------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | |--INV Bob@B--->| |
| | | | |
| | |<-302----------| |
| | | Contact: Carol@C |
| | | Diversion: Bob@B |
| | | ;reason=unconditional
| | | | |
| | |--ACK--------->| |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@B | |
| | ;reason=unconditional | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C------------------------>|
| | Diversion: Bob@B | |
| | ;reason=unconditional | |
| | | | |
| |<-200------------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK-------------------------------------------------->|
| | | | |
| | | | |
Usage of the Diversion header is shown below for several variant implementations of Call Forward on Busy.
宛先ヘッダの使用がビジーにコール転送のいくつかのバリアントの実装については、以下に示されます。
In this message flow, Proxy 2 (P2) recursively implements Call Forward on Busy (CFB) to Carol@C.
このメッセージフローでは、プロキシ2（P2）は、再帰的にキャロル@ C多忙にコール転送（CFB）を実装します。
+----------------------+
| Bob@P2: CFB->Carol@C |
+------+---------------+
\
\
A P1 P2 B C
recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-486--------| |
| | | | |
| | |--ACK------->| |
| | | | |
| | |--INVITE Carol@C------->|
| | | Diversion: Bob@P2 |
| | | ;reason=user-busy |
| | | | |
| | |<-200-------------------|
| | | | |
| |<-200---------| | |
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
6.2.2. Network Call Forward on Busy (P1 Non-Recursing, P2 Non-Recursing)
6.2.2. 話中時コールフォワードネットワーク（P1非再帰的、P2ない-再帰的）
In this message flow, Proxy 2 (P2) non-recursively implements Call Forward on Busy (CFB) to Carol@C. Proxy 1 (P1) is non-recursing.
このメッセージフローでは、プロキシ2（P2）は、非再帰的キャロル@ Cにビジー（CFB）上のコール転送を実装します。プロキシ1（P1）は、非再帰です。
+----------------------+
| Bob@P2: CFB->Carol@C |
+------+---------------+
\
\
A P1 P2 B C
non-recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-486--------| |
| | | | |
| | |--ACK------->| |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=user-busy | |
| | | | |
| |--ACK-------->| | |
| | | | |
|<-302---------| | | |
| Contact: Carol@C | | |
| Diversion: Bob@P2 | | |
| ;reason=user-busy | | |
| | | | |
|--ACK-------->| | | |
| | | | |
|--INVITE Carol@C------------------------------------->|
| Diversion: Bob@P2 | | |
| ;reason=user-busy | | |
| | | | |
|<-200-------------------------------------------------|
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
In this message flow, Proxy 2 (P2) non-recursively implements Call Forward on Busy (CFB) to Carol@C. Proxy 1 (P1) is recursing.
このメッセージフローでは、プロキシ2（P2）は、非再帰的キャロル@ Cにビジー（CFB）上のコール転送を実装します。プロキシ1（P1）が再帰されます。
+----------------------+
| Bob@P2: CFB->Carol@C |
+------+---------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-486--------| |
| | | | |
| | |--ACK------->| |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=user-busy | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@P2 | |
| | ;reason=user-busy | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
In this message flow, user agent server B (B) non-recursively implements Call Forward on Busy (CFB) to Carol@C. Proxy 2 (P2) is non-recursing. Proxy 1 (P1) is recursing.
このメッセージフローでは、ユーザエージェントサーバB（B）は、非再帰的キャロル@ Cにビジー（CFB）にコール転送を実装します。プロキシ2（P2）は、非再帰です。プロキシ1（P1）が再帰されます。
+---------------------+
| Bob@B: CFB->Carol@C |
+------+--------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-302--------| |
| | | Contact: Carol@C |
| | | Diversion: Bob@B |
| | | ;reason=user-busy |
| | | | |
| | |--ACK------->| |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@B | |
| | ;reason=user-busy | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@B | |
| | ;reason-user-busy | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
Usage of the Diversion header is shown below for several variant implementations of Call Forward on No-Answer.
宛先ヘッダの使用は、無応答時コール転送のいくつかのバリアントの実装については、以下に示されます。
In this message flow, Proxy 2 (P2) recursively implements Call Forward on No Answer (CFNA) to Carol@C.
このメッセージフローでは、プロキシ2（P2）は、再帰的にキャロル@ Cに無応答（CFNA）にコール転送を実装します。
+-----------------------+
| Bob@P2: CFNA->Carol@C |
+------+----------------+
\
\
A P1 P2 B C
recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-180--------| |
| | | | |
| | | | |
| | | | |
| | timeout | |
| | |--INVITE Carol@C------->|
| | | Diversion: Bob@P2 |
| | | ;reason=no-answer |
| | | | |
| | |<-200-------------------|
| | | | |
| |<-200---------| | |
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
6.3.2. Network Call Forward on No-Answer (P1 Non-Recursing, P2 Non-Recursing)
6.3.2. 無回答のネットワークコールフォワード（P1非再帰的、P2ない-再帰的）
In this message flow, Proxy 2 (P2) non-recursively implements Call Forward on No Answer (CFNA) to Carol@C. Proxy 1 (P1) is non-recursing.
このメッセージフローでは、プロキシ2（P2）は、非再帰的キャロル@ Cに無応答（CFNA）にコール転送を実装します。プロキシ1（P1）は、非再帰です。
+-----------------------+
| Bob@P2: CFNA->Carol@C |
+------+----------------+
\
\
A P1 P2 B C
non-recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-180--------| |
| | | | |
| | | | |
| | | | |
| | timeout | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=no-answer | |
| | | | |
| |--ACK-------->| | |
| | | | |
|<-302---------| | | |
| Contact: Carol@C | | |
| Diversion: Bob@P2 | | |
| ;reason=no-answer | | |
| | | | |
|--ACK-------->| | | |
| | | | |
|--INVITE Carol@C------------------------------------->|
| Diversion: Bob@P2 | | |
| ;reason=no-answer | | |
| | | | |
|<-200-------------------------------------------------|
| | | | |
|--ACK------------------------------------------------>|
| | | | |
6.3.3. Network Call Forward on No Answer (P1 Recursing, P2 Non-Recursing)
6.3.3. 無応答時コールフォワードネットワーク（P1再帰、P2非再帰的に）
In this message flow, Proxy 2 (P2) non-recursively implements Call Forward on No Answer (CFNA) to Carol@C. Proxy 1 (P1) is recursing.
このメッセージフローでは、プロキシ2（P2）は、非再帰的キャロル@ Cに無応答（CFNA）にコール転送を実装します。プロキシ1（P1）が再帰されます。
+-----------------------+
| Bob@P2: CFNA->Carol@C |
+------+----------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-180--------| |
| | | | |
| | | | |
| | | | |
| | timeout | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=no-answer | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@P2 | |
| | ;reason=no-answer | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
6.3.4. Endpoint Call Forward on No-Answer (P1 Recursing, P2 Non-Recursing, B Non-Recursing)
6.3.4. 無回答上のエンドポイントコールフォワード（P1再帰、P2非再帰、B非再帰的）
In this message flow, user agent server B (B) non-recursively implements Call Forward on No Answer (CFNA) to Carol@C. Proxy 2 (P2) is non-recursing. Proxy 1 (P1) is recursing.
このメッセージ・フローでは、ユーザエージェントサーバB（B）は、非再帰的にキャロル@ Cへの無回答（CFNA）にコール転送を実装しています。プロキシ2（P2）は、非再帰です。プロキシ1（P1）が再帰されます。
+----------------------+
| Bob@B: CFNA->Carol@C |
+------+---------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | | | |
| | | | |
| | | timeout |
| | |<-302--------| |
| | | Contact: Carol@C |
| | | Diversion: Bob@B |
| | | ;reason=no-answer |
| | | | |
| | |--ACK------->| |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@B | |
| | ;reason=no-answer | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@B | |
| | ;reason-no-answer | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
Usage of the Diversion header is shown below for several variant implementations of Call Forward on Unavailable.
宛先ヘッダの使用は、使用不可にコール転送のいくつかのバリアントの実装については、以下に示されます。
In this message flow, Proxy 2 (P2) recursively implements Call Forward on Unavailable (CFUNV) to Carol@C.
このメッセージフローでは、プロキシ2（P2）は、再帰的にキャロル@ Cに使用不可にコールフォワード（CFUNV）を実装します。
+------------------------+
| Bob@P2: CFUNV->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
recursing
| | | | |
|--INV Bob@P1->| | | |
|<-100---------| | | |
| |--INV Bob@P2->| | |
| |<-100---------| | |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | | ... | |
| | |--INV Bob@B->| |
| | timeout | |
| | |--INVITE Carol@C------->|
| | | Diversion: Bob@P2 |
| | | ;reason=unavailable
| | | | |
| | |<-200-------------------|
| | | | |
| |<-200---------| | |
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
6.4.2. Network Call Forward on Unavailable (P1 Non-Recursing, P2 Non-Recursing)
6.4.2. 使用不可のネットワークコールフォワード（P1非再帰的、P2ない-再帰的）
In this message flow, Proxy 2 (P2) non-recursively implements Call Forward on Unavailable (CFUNV) to Carol@C. Proxy 1 (P1) is non-recursing.
このメッセージフローでは、プロキシ2（P2）は、非再帰的キャロル@ Cに使用できません（CFUNV）上のコール転送を実装します。プロキシ1（P1）は、非再帰です。
+------------------------+
| Bob@P2: CFUNV->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
non-recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| |<-100---------| | |
| | | | |
|<-100---------| | | |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | | ... | |
| | |--INV Bob@B->| |
| | timeout | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=unavailable | |
| | | | |
| |--ACK-------->| | |
| | | | |
|<-302---------| | | |
| Contact: Carol@C | | |
| Diversion: Bob@P2 | | |
| ;reason=unavailable | | |
| | | | |
|--ACK-------->| | | |
| | | | |
|--INVITE Carol@C------------------------------------->|
| Diversion: Bob@P2 | | |
| ;reason=unavailable | | |
| | | | |
|<-200-------------------------------------------------|
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
6.4.3. Network Call Forward on Unavailable (P1 Recursing, P2 Non-Recursing)
6.4.3. 使用不可のネットワークコールフォワード（P1再帰、P2非再帰的に）
In this message flow, Proxy 2 (P2) non-recursively implements Call Forward on Unavailable (CFUNV) to Carol@C. Proxy 1 (P1) is recursing.
このメッセージフローでは、プロキシ2（P2）は、非再帰的キャロル@ Cに使用できません（CFUNV）上のコール転送を実装します。プロキシ1（P1）が再帰されます。
+------------------------+
| Bob@P2: CFUNV->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
|<-100---------| | | |
| |--INV Bob@P2->| | |
| |<-100---------| | |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | | ... | |
| | |--INV Bob@B->| |
| | timeout | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=unavailable | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@P2 | |
| | ;reason=unavailable | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
Usage of the Diversion header when multiple diversions occur are shown the following two examples.
複数の転換が起こる宛先ヘッダの使用は、以下の2つの例を示しています。
In this message flow, Proxy 2 (P2) implements Call Forward Unconditional (CFUNC) to Carol@C. C then implements Call Forward on Busy (CFB) to 5551234@D. P2 is non-recursing. P1 is recursing. C is non-recursing.
このメッセージフローでは、プロキシ2（P2）は、キャロル@ Cにコール転送無条件（CFUNC）を実装します。 Cは、D @ 5551234にビジー（CFB）の上にコール転送を実装しています。 P2は、非再帰です。 P1は再帰されます。 Cは非再帰です。
+------------------------+ +-------------------------+
| Bob@P2: CFUNC->Carol@C | | Carol@C: CFB->5551234@D |
+---------------+--------+ +--------+----------------+
\ \
\ \
A P1 P2 B C D
recursing non-recursing non-recursing
| | | | | |
|--INV Bob@P1->| | | | |
| | | | | |
| |--INV Bob@P2->| | | |
| | | | | |
| |<-302---------| | | |
| | Contact: Carol@C | | |
| | Diversion: Bob@P2 | | |
| | ;reason=unconditional | | |
| | | | | |
| |--ACK-------->| | | |
| | | | | |
| |--INVITE Carol@C---------------------->| |
| | Diversion: Bob@P2 | | |
| | ;reason=unconditional | | |
| | | | | |
| |<-302----------------------------------| |
| | Contact: 5551234@D | | |
| | Diversion: Carol@C | | |
| | ;reason=user-busy | | |
| | ;privacy="full" | | |
| | Diversion: Bob@P2 | | |
| | ;reason=unconditional | | |
| | | | | |
| |--ACK--------------------------------->| |
| | | | | |
| |--INVITE 5551234@D------------------------------->|
| | Diversion: Carol@C | | |
| | ;reason=user-busy | | |
| | ;privacy="full" | | |
| | Diversion: Bob@P2 | | |
| | ;reason=unconditional | | |
| | | | | |
| |<-200---------------------------------------------|
| | | | | |
|<-200---------| | | | |
| | | | | |
|--ACK----------------------------------------------------------->|
| | | | | |
| | | | | |
In this message flow, Proxy 2 (P2) implements Call Forward Unconditional (CFUNC) to Carol@C. (P2 would normally have routed the call to B). C then implements Call Forward on No Answer (CFNA) to 5551234@D. P2 is recursing. C is recursing.
このメッセージフローでは、プロキシ2（P2）は、キャロル@ Cにコール転送無条件（CFUNC）を実装します。 （P2は、通常Bへの呼び出しをルーティングされているだろう）。 Cは、D @ 5551234に無応答（CFNA）にコール転送を実装しています。 P2が再帰されます。 Cは再帰されています。
+------------------------+ +--------------------------+
| Bob@P2: CFUNC->Carol@C | | Carol@C: CFNA->5551234@D |
+------------------+-----+ +-----+--------------------+
\ \
\ \
A P1 P2 B C D
recursing recursing
| | | | | |
|--INV Bob@P1->| | | | |
| | | | | |
| |--INV Bob@P2->| | | |
| | | | | |
| | |--INV Carol@C->| |
| | | Diversion: Bob@P2 |
| | | ;reason=unconditional |
| | | | | |
| | |<--180---------| |
| | | | | |
| |<-180---------| | | |
| | | | | |
|<-180---------| | | | |
| | | | | |
| | | | | |
| | | | timeout |
| | | | |--INV 5551234@D->|
| | | | |Diversion: Carol@C
| | | | | ;reason=no-answer
| | | | | ;privacy="full"
| | | | |Diversion: Bob@P2
| | | | | ;reason= unconditional
| | | | | |
| | | | |<-200------------|
| | | | | | |
| | |<-200----------| | |
| | | | | | |
| |<-200---------| | | | |
| | | | | | |
|<-200---------| | | | | |
| | | | | | |
|--ACK--------------------------------------------------------->|
| | | | | | |
There are some privacy considerations when using the Diversion header. Usage of the Diversion header implies that the diverting UAS trusts the diverted-to UAS. Usage of the Diversion header by SIP proxies or SIP user agents can cause information leakage of route information and called information to untrusted SIP proxies and untrusted callers in upstream 3xxs. Leakage of this information can be mitigated by having a recursing trusted upstream proxy server. For a SIP network architecture where all proxies are required to be non-recursive, Diversion header hiding may be considered necessary in order to prevent leakage of route information to the caller. To accomplish Diversion header hiding, a trusted upstream proxy would add a Record-Route header and use a secret key to encrypt the contents of the Diversion header in 3xxs that are forwarded upstream. On receipt of re-INVITEs, the proxy would decrypt the contents of the Diversion header (using its secret key) and forward the INVITE. There is no currently defined interaction of the Diversion and Hide headers. Question: Should there be?
Diversionヘッダーを使用している場合、いくつかのプライバシーの考慮事項があります。宛先ヘッダの使用は、分流UASはUAS迂回-に信頼していることを意味します。 SIPプロキシまたはSIPユーザエージェントによって宛先ヘッダの使用は、経路情報の情報漏洩の原因となり、信頼されていないSIPプロキシおよび上流3xxsで信頼できない発信者情報と呼ぶことができます。この情報の漏洩は、再帰、信頼できる上流のプロキシサーバーを持つことによって軽減することができます。全てのプロキシが非再帰的であることが要求されているSIPネットワークアーキテクチャのために、宛先ヘッダ隠蔽は、呼び出し元に経路情報の漏洩を防止するために必要であると考えてもよいです。 Diversionヘッダーの隠蔽を達成するために、信頼できる上流プロキシはRecord-Routeヘッダを追加し、上流に転送され3xxsに転用ヘッダの内容を暗号化するために秘密鍵を使用します。再度のINVITEを受信すると、プロキシは、（その秘密鍵を使用して）宛先ヘッダの内容を解読し、INVITEを転送することになります。そこ転用のない現在定義された相互作用はありませんとヘッダを非表示にします。質問：があるはず？
Only the relevant headers have been included in the following examples. The contents of the Session Description Protocols (SDPs) have also been omitted.
唯一の関連ヘッダは、以下の例に含まれています。セッション記述プロトコル（のSDP）の内容も省略されています。
8.1. Night Service/Automatic Call Distribution (ACD) Using Diversion Header
8.1. ナイトサービス/転用ヘッダーを使用して自動着信分配（ACD）
In the following two message flows, two separate companies, WeSellPizza.com and WeSellFlowers.com, have contracted with a third company, NightService.com to provide nighttime support for their incoming voice calls.
以下の2つのメッセージ・フローでは、2つの別個の企業は、WeSellPizza.comとWeSellFlowers.com、その着信音声通話のための夜間のサポートを提供するために、第三の会社、NightService.comと契約しています。
In the first flow, Alice calls out for pizza. In the second flow, Alice calls for roses. In both instances, the same night service company (and receptionist, Carol) answers the call. However, because the Diversion header is used, Carol is able to customize her greeting to the caller.
最初のフローでは、アリスはピザのために呼び出します。第二流では、アリスは、薔薇のために呼び出します。どちらの場合も、同じ夜サービス会社（および受付、キャロル）がコールに応答します。 Diversionヘッダーを使用しているのでしかし、キャロルは、呼び出し側に彼女の挨拶をカスタマイズすることができます。
+-------------------------------------+
| WeSellPizza@P2: CFTOD->nightserv@P3 |
+------------+------------------------+
\
\
UAC P1 P2 P3 UAS1
(WeSellPizza.com) (NightService.com)
(ACD)
| [1] | | | |
|-INV pizza@P1->| | | |
| | | | |
| | | | |
| | [2] INVITE WeSellPizza@P2 | |
| |------------->| | |
| | | | |
| | | [3] | |
| | |-INV nightserv@P3->| |
| | | Diversion: WeSellPizza@P2 |
| | | ;reason=time-of-day |
| | | | |
| | | | [4] |
| | | |-INV Carol@uas1-->|
| | | Diversion: WeSellPizza@P2 |
| | | ;reason=time-of-day |
| | | | |
| | | |<-[5] 200---------|
| | |<-[6] 200----------| |
| |<-[7] 200-----| | |
|<-[8] 200------| | | |
| | | | |
|--[9] ACK----------------------------------------------------------->|
| | | | |
|<=========================================="Hello, WeSellPizza"======|
| | | | |
| | | | |
Alice calls for pizza.
アリスはピザのために呼び出します。
[1] SIP UAC to SIP proxy server 1:
[1] SIP UACは、プロキシサーバ1のSIPに：
INVITE sip:pizza@p1.isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:pizza@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
The ISP's originating proxy translated the keyword pizza to the company WeSellPizza.com
ISPの発信プロキシが会社にキーワードピザを翻訳WeSellPizza.com
[2] SIP proxy server 1 to SIP proxy server 2 (WeSellPizza.com):
SIPプロキシサーバ2へ[2] SIPプロキシサーバ1（WeSellPizza.com）：
INVITE sip:WeSellPizza@p2.isp.com SIP/2.0
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:pizza@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
It's after midnight and the pizza people are in bed. Fortunately, WeSellPizza.com has contracted with NightService.com to answer their nighttime calls. Thus, P2 implements CFTOD to NightService.com.
それは真夜中の後だとピザの人はベッドです。幸い、WeSellPizza.comは彼らの夜間コールに応答するためにNightService.comと契約しています。したがって、P2はNightService.comにCFTODを実装しています。
[3] SIP proxy server 2 (WeSellPizza.com) to SIP proxy server 3 (NightService.com):
[3] SIPプロキシサーバ2（WeSellPizza.com）プロキシサーバ3をSIPする（NightService.com）：
INVITE sip:NightService@p3.isp.com SIP/2.0
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:pizza@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:WeSellPizza@p2.isp.com>
;reason=time-of-day
Content-Type: application/sdp
Carol is available to receive the incoming call.
キャロルは、着信コールを受信することができます。
[4] SIP proxy server 3 (NightService.com) to UAS1 (Carol):
[4] SIPプロキシサーバ3 UAS1（キャロル）の（NightService.com）：
INVITE sip:carol@uas1.nightservice.com SIP/2.0
Via: SIP/2.0/UDP p3.isp.com
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:pizza@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:WeSellPizza@p2.isp.com>
;reason=time-of-day
Content-Type: application/sdp
The ACD keys off the Diversion header to pull up the WeSellPizza FAQ on Carol's web browser.
DiversionヘッダーオフACDは、キーキャロルのウェブブラウザ上でWeSellPizzaよくある質問をプルアップします。
[5] UAS1 to SIP proxy server 3:
[5] UAS1プロキシサーバ3をSIPします。
SIP/2.0 200 OK
Via: SIP/2.0/UDP p3.isp.com
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:pizza@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[6] SIP proxy server 3 to SIP proxy server 2:
SIPプロキシサーバ2〜[6]のSIPプロキシサーバ3：
SIP/2.0 200 OK
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:pizza@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[7] SIP proxy server 2 to SIP proxy server 1:
SIPプロキシサーバ1〜[7] SIPプロキシサーバ2：
SIP/2.0 200 OK
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:pizza@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[8] SIP proxy server 1 to UAC
UAC〜[8] SIPプロキシサーバ1
SIP/2.0 200 OK
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:pizza@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[9] SIP UAC to UAS1:
[9] UAS1にSIP UACを：
ACK sip:uas1.nightservice.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: <sip:pizza@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
The RTP flows begin and Carol answers "Hello, WeSellPizza. How may I help you?"
RTPフローが始まるとキャロルは答え、「こんにちは、WeSellPizzaは。どのように私はあなたを助けるかもしれません？」
+---------------------------------------+
| WeSellFlowers@P4: CFTOD->nightserv@P3 |
+-------------+-------------------------+
\
\
UAC P1 P4 P3 UAS1
(WeSellFlowers.com) (NightService.com)
(ACD)
| [1] | | | |
|-INV roses@P1->| | | |
| | | | |
| | [2] INVITE WeSellFlowers@P4 | |
| |--------------->| | |
| | | | |
| | [3] | | |
| |<-302-----------| | |
| | Contact: nightservice@P3 | |
| | Diversion: WeSellFlowers@P4 | |
| | ;reason=time-of-day | |
| | | | |
| |--[4] ACK------>| | |
| | | | |
| | [5] | | |
| |-INVITE nightservice@P3------------>| |
| | Diversion: WeSellFlowers@P4 | |
| | ;reason=time-of-day | |
| | | | |
| | | | [6] |
| | | -INV Carol@uas1----->|
| | | Diversion: WeSellFlowers@P4
| | | ;reason=time-of-day
| | | |
| | | |<-[7] 200------------|
| |<-[8] 200---------------------------| |
|<-[9] 200------| | | |
| | | | |
|--[10] ACK---------------------------------------------------------->|
| | | | |
|<======================================="Hello, WeSellFlowers"=======|
| | | | |
| | | | |
Alice calls for roses.
アリスは、薔薇のために呼び出します。
[1] SIP UAC to SIP proxy server 1:
[1] SIP UACは、プロキシサーバ1のSIPに：
INVITE sip:roses@p1.isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:roses@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
The ISP's originating proxy translated the keyword roses to the company WeSellFlowers.com
ISPの発信プロキシが会社にキーワードバラを翻訳WeSellFlowers.com
[2] SIP proxy server 1 to SIP proxy server 4 (WeSellFlowers.com):
SIPプロキシサーバ4へ[2] SIPプロキシサーバ1（WeSellFlowers.com）：
INVITE sip:WeSellFlowers@p4.isp.com SIP/2.0
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:roses@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
It's now 1 a.m. and the florists are also in bed. Fortunately, WeSellFlowers.com has contracted with NightService.com to answer their nighttime calls, too. Thus, P4 implements CFTOD to NightService.com.
今は午前1時だと花屋はベッドの中でもあります。幸いなことに、WeSellFlowers.comも、彼らの夜間呼び出しに応答するNightService.comと契約しています。このように、P4はNightService.comにCFTODを実装しています。
[3] SIP proxy server 4 (WeSellFlowers.com) to SIP proxy server 1 (NightService.com):
[3] SIPプロキシサーバ4（WeSellFlowers.com）プロキシサーバ1はSIPする（NightService.com）：
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: NightService@p3.isp.com
From: sip:alice@isp.com
To: <sip:roses@p1.isp.com>;tag=p4
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:WeSellFlowers@p4.isp.com>
;reason=time-of-day
[4] SIP proxy server 1 to SIP proxy server 4 (WeSellFlowers.com): ACK sip:uas1.nightservice.com SIP/2.0 Via: SIP/2.0/UDP alice-pc.isp.com From: sip:alice@isp.com To: <sip:roses@p1.isp.com>;tag=p4 Call-ID: 12345600@alice-pc.isp.com CSeq: 1 INVITE
ACK SIP：uas1.nightservice.com SIP / 2.0経由：SIP / 2.0 / UDP alice-pc.isp.comから：SIP：アリス@のISP SIPプロキシサーバ4（WeSellFlowers.com）〜[4] SIPプロキシサーバ1 .COMに<SIP：roses@p1.isp.com>;タグ= P4コール-ID：12345600@alice-pc.isp.comのCSeq：INVITE 1
[5] SIP proxy server 1 (WeSellFlowers.com) to SIP proxy server 3 (NightService.com):
[5] SIPプロキシサーバ1（WeSellFlowers.com）プロキシサーバ3をSIPする（NightService.com）：
INVITE sip:NightService@p3.isp.com SIP/2.0
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:roses@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:WeSellFlowers@p4.isp.com>
;reason=time-of-day
Content-Type: application/sdp
Carol is available to receive the incoming call.
キャロルは、着信コールを受信することができます。
[6] SIP proxy server 3 (NightService.com) to UAS1 (Carol):
[6] SIPプロキシサーバ3 UAS1（キャロル）の（NightService.com）：
INVITE sip:carol@uas1.nightservice.com SIP/2.0
Via: SIP/2.0/UDP p3.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:roses@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:WeSellFlowers@p4.isp.com>
;reason=time-of-day
Content-Type: application/sdp
The ACD keys off the Diversion header to pull up the WeSellFlowers FAQ on Carol's web browser.
DiversionヘッダーオフACDは、キーキャロルのウェブブラウザ上でWeSellFlowersよくある質問をプルアップします。
[7] SIP UAS1 to SIP proxy server 3:
[7] SIP UAS1は、プロキシサーバ3をSIPします。
SIP/2.0 200 OK
Via: SIP/2.0/UDP p3.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:roses@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[8] SIP proxy server 3 to SIP proxy server 1:
SIPプロキシサーバ1〜[8] SIPプロキシサーバ3：
SIP/2.0 200 OK
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:roses@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[9] SIP proxy server 1 to UAC
UAC〜[9] SIPプロキシサーバ1
SIP/2.0 200 OK
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:roses@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[10] SIP UAC to SIP UAS1:
SIP UAS1乃至[10]のSIP UAC：
ACK sip:uas1.nightservice.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: <sip:roses@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
The RTP flows begin and Carol answers "Hello, WeSellFlowers. How may I help you?"
RTPフローが始まるとキャロルは答え、「こんにちは、WeSellFlowersは。どのように私はあなたを助けるかもしれません？」
Bob has contracted his Voicemail to a third-party company, Voicemail.com. In this message flow, Bob has hit the Do-Not-Disturb button on his phone. The Do-Not-Disturb functionality of Bob's phone is configured to CFUNC (Call Forward Unconditional) to voicemail@isp.com. Because the Diversion header is used, Voicemail.com is able to place the incoming call into Bob's voice mailbox.
ボブは、サードパーティの会社、Voicemail.comに彼のボイスメールを契約しています。このメッセージ・フローでは、ボブは彼の携帯電話上のDO-NOT-ディスターブボタンを襲っています。ボブの携帯電話のDO-NOT-ディスターブ機能はvoicemail@isp.comにCFUNC（フォワード無条件に電話）に設定されています。 Diversionヘッダーが使用されるため、Voicemail.comはボブの音声メールボックスに着信コールを配置することができます。
+---------------------------------------------+
| Bob@UAS1: CFDoNotDisturb->voicemail@isp.com |
+--------------------------------------+------+
\
\
UAC1 P1 P2 UAS1 UAS2
Voicemail.com
| | | | |
|--[1] INV Bob@P1->| | | |
| | | | |
| |--[2] INV Bob@P2->| | |
| | | | |
| | [3] INV Bob@uas1->| |
| | | | |
| | [4] <- 302-------| |
| | Contact: voicemail@isp.com |
| | Diversion: Bob@uas1 |
| | ;reason=do-not-disturb |
| | | | |
| | |[5] ACK------>| |
| | | | |
| |<-[6] 302---------| | |
| | Contact: voicemail@isp.com | |
| | Diversion: Bob@uas1 | |
| | ;reason=do-not-disturb | |
| | | | |
| |--[7] ACK-------->| | |
|<-[8] 302---------| | | |
| Contact: voicemail@isp.com | | |
| Diversion: Bob@uas1 | | |
| ;reason=do-not-disturb | | |
| | | | |
|--[9] ACK-------->| | | |
| | | | |
|--[10] INVITE voicemail@isp.com------------------------------->|
| Diversion: Bob@uas1 | | |
| ;reason=do-not-disturb | | |
| | | | |
|<--[11] 200----------------------------------------------------|
| | | | |
|---[12] ACK--------------------------------------------------->|
| | | | |
| | | | |
Alice calls Bob.
アリスはボブを呼び出します。
[1] SIP UAC to SIP proxy server 1:
[1] SIP UACは、プロキシサーバ1のSIPに：
INVITE sip:Bob@p1.isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:Bob@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
The ISP's originating proxy routes the request to proxy 2 (P2).
ISPの発信プロキシルートプロキシ2（P2）への要求。
[2] SIP proxy server 1 to SIP proxy server 2:
SIPプロキシサーバ2へ[2] SIPプロキシサーバ1：
INVITE sip:Bob@p2.isp.com SIP/2.0
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:Bob@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[3] SIP proxy server 2 to UAS1 (Bob's SIP phone):
UAS1（BobのSIPフォン）[3] SIPプロキシサーバ2：
INVITE sip:Bob@uas1.isp.com SIP/2.0
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:Bob@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
Since Bob had hit the Do-Not-Disturb button on his SIP phone, Bob's phone forwards the call to his voicemail service.
ボブは彼のSIPフォンにDO--邪魔しないでボタンを押していたので、ボブの電話が彼のボイスメールサービスにコールを転送します。
[4] User agent server 1 (UAS1) to SIP proxy server 2 (P2)
プロキシサーバ2（P2）をSIP〜[4]ユーザエージェントサーバ1（UAS1）
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: Voicemail@isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:Bob@uas1.isp.com>
;reason=do-not-disturb
[5] SIP proxy server 2 to UAS1 (Bob's SIP phone):
UAS1（BobのSIPフォン）〜[5] SIPプロキシサーバ2：
ACK sip:Bob@uas1.isp.com SIP/2.0
Via: SIP/2.0/UDP p2.isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
[6] SIP proxy server 2 (P2) to SIP proxy server 1 (P1):
[6]プロキシサーバ1（P1）をSIPするSIPプロキシサーバ2（P2）を：
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: Voicemail@isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:Bob@uas1.isp.com>
;reason=do-not-disturb
[7] SIP proxy server 1 to SIP proxy server 2:
SIPプロキシサーバ2〜[7] SIPプロキシサーバ1：
ACK sip:Bob@p2.isp.com SIP/2.0
Via: SIP/2.0/UDP p1.isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
[8] SIP proxy server 1 (P1) to UAC (alice-pc):
[8] UAC（アリス-PC）へSIPプロキシサーバ1（P1）を：
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: Voicemail@isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:Bob@uas1.isp.com>
;reason=do-not-disturb
[9] SIP UAC to SIP proxy server 1:
[9] SIP UACは、プロキシサーバ1のSIPに：
ACK sip:Bob@p1.isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
[10] SIP UAC (alice-pc) to Voicemail server.
ボイスメールサーバへの[10]のSIP UAC（アリス-PC）。
INVITE sip:Voicemail@isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:Bob@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:Bob@uas1.isp.com>
;reason=do-not-disturb
Content-Type: application/sdp
[11] Voicemail server to SIP UAC (alice-pc):
UAC（アリス-PC）をSIPする[11]ボイスメールサーバー。
SIP/2.0 200 OK
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: Voicemail@isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas2
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[12] SIP UAC to Voicemail server:
ボイスメールサーバへの[12]のSIP UAC：
ACK sip:Voicemail@isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas2
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Because the Diversion header is present, the Voicemail server is able to place Alice's message into Bob's voice mailbox.
Diversionヘッダーが存在するため、ボイスメールサーバは、ボブの音声メールボックスにアリスのメッセージを配置することができます。
Question 1:
質問1：
Why do we need the Diversion header when we can see the To: header?
ヘッダー：我々が見ることができるのに、なぜ私たちはDiversionヘッダーが必要なのでしょうか？
Answer:
回答：
a) The To: header is not guaranteed to have significance to the called party.
a）から：ヘッダは、着信側に意義を持つことが保証されていません。
For example, the To: header may contain a locally significant URL (to the caller) such as a private numbering plan, speed dial digits, telephony escape digits, or telephony prefix digits.
たとえば、To：ヘッダーには、プライベート番号計画、スピードダイヤル番号、電話エスケープ桁、または電話プレフィックス番号として（呼び出し側に）ローカルで有効なURLが含まれていてもよいです。
Without a Diversion header, enumerating all possible locally significant To: headers that anyone might use to contact Bob@uas1.isp.com becomes a configuration problem at Voicemail@isp.com and is prone to namespace collision.
誰もがBob@uas1.isp.comがVoicemail@isp.comで設定の問題となると、名前空間の衝突を起こしやすい連絡を使用する場合があります：ヘッダのDiversionヘッダーがなければ、すべての可能性にローカルで有効な列挙。
Support for Diversion headers enables Bob to contract a third-party service (Voicemail@isp.com) with a single globally significant URL for his voice mailbox (Bob@uas1.isp.com).
Diversionヘッダーのサポートは彼のボイスメールボックス（Bob@uas1.isp.com）のための単一のグローバル重要なURLで、サードパーティのサービス（Voicemail@isp.com）を収縮させるボブを可能にします。
b) Given a set of multiple diversions, there is a policy decision of which Diversion header takes precedence for service logic.
B）複数転換のセットが与えられると、宛先ヘッダは、サービスロジックに優先されたポリシー決定があります。
Different services (or even different users for the same service) may want to configure this policy differently (first, last, second to last, etc.).
異なるサービス（または同じサービスのためにも、異なるユーザ）は（最後まで最初、最後、第2など）異なっこのポリシーを設定することもできます。
Question 2:
質問2：
Why do we need the Diversion header when we can see the Via: header?
なぜ我々は経由を見ることができるのDiversionヘッダーが必要です：ヘッダを？
Answer:
回答：
The Via header does not contain information about servers whom have deflected the call (using a 3xx).
Viaヘッダは、（300番台を使用して）コールを偏向しているサーバに関する情報が含まれていません。
The discussions below regarding ISUP/ISDN reflect generic elements in ISUP/ISDN. In some variations of ISUP/ISDN, the information elements are represented differently. Regardless of the ISUP/ISDN variant, translation should be performed for the "first redirecting number" and the "last redirecting number".
ISUP / ISDNに関する以下の議論はISUP / ISDNでの一般的な要素を反映しています。 ISUP / ISDNのいくつかの変形例では、情報要素は異なる表現されます。かかわらず、ISUP / ISDN変異体の、翻訳は「最初のリダイレクト番号」と「最後のリダイレクト番号」のために実行する必要があります。
In order to prevent ambiguity, it is important to highlight a terminology mismatch between ISUP/ISDN and SIP. In SIP, a "redirect" indicates the act of returning a 3xx response. In ISUP/ISDN, a "redirection" is diversion of a call by a network entity. In ISUP/ISDN, a call may also be deflected (by an endpoint). Diversion is the more generic term that refers to either the act of an network redirection or endpoint deflection.
あいまいさを防ぐためには、ISUP / ISDNとSIP間の用語の不一致を強調することが重要です。 SIPでは、「リダイレクト」3xx応答を返すの行為を示します。 ISUP / ISDNでは、「リダイレクションは、」ネットワーク・エンティティによってコールの転換です。 ISUP / ISDNでは、コールは、（エンドポイントによって）偏向されてもよいです。転換は、ネットワークのリダイレクトまたはエンドポイントのたわみの行為のいずれかを意味する、より一般的な用語です。
In SIP, Diversion can be implemented as either an upstream 3xx (non-recursive) or an additionally forked downstream request (recursive). In the following text, a lowercase "redirect" indicates the SIP usage, while an uppercase "Redirect" indicates ISUP usage.
SIPにおいては、転換は、上流3XX（非再帰的）に又は追加的に二股下流要求（再帰的）のいずれかとして実装することができます。大文字の「リダイレクト」はISUPの使用を示しながら、以下のテキストでは、小文字の「リダイレクト」、SIPの使用を示しています。
ISUP and ISDN define the following diversion reasons:
ISUPとISDNは、次の転換の理由を定義します。
0000 = Unknown 0001 = Call forwarding busy or called DTE busy 0010 = Call forwarding no reply 1111 = Call forwarding unconditional or systematic call redirection 1010 = Call deflection or call forwarding by the called DTE 1001 = Call forwarding DTE out of order
0000 =不明0001 =コールがビジー転送またはDTE忙しい0010 =コールが返事を転送しない1111 =コールは無条件または系統的なコールのリダイレクト1010 =コールのたわみを転送したりと呼ばれるDTE 1001 =コールが故障してDTEを転送することによって転送を呼び出すと呼ばれます
Mapping of ISUP/ISDN reason codes to Diversion reason codes is performed as follows:
次のように迂回理由コードにISUP / ISDN理由コードのマッピングが行われます。
ISUP/ISDN reason code Diversion reason code 0001 "user-busy" 0010 "no-answer" 1111 "unconditional" 1010 "deflection" 1001 "unavailable" 0000 all others
ISUP / ISDN理由コード迂回理由コード0001「ユーザー・ビジー」0010「応答なし」1111「無条件」1010「たわみ」1001「利用できません」0000他のすべて
This section describes how generic ISUP diversion information elements may be translated across an ISUP/SIP gateway.
このセクションでは、一般的なISUP迂回情報要素はISUP / SIPゲートウェイを横切って変換することができる方法を記載しています。
Called Party Number The number of the party to which the call is currently being routed.
パーティの数はコールが現在ルーティングされているために着番号。
Redirecting Number The number to which the call was being routed when the last diversion occurred.
最後の転換が発生したときにコールがルーティングされた先の番号数をリダイレクトします。
Redirecting Reason The reason that the last diversion occurred.
最後の迂回が発生した理由理由をリダイレクトします。
Original Called Number The number to which the call was being routed when the first diversion occurred.
最初の分岐が発生したときに、コールがルーティングされた数の先のオリジナル着番号。
Original Redirecting Reason The reason that the first diversion occurred.
オリジナルリダイレクト理由最初の転換が発生したことを理由。
Redirection Counter The count of the total number of diversions that have occurred.
リダイレクトが発生した気分転換の合計数のカウントをカウンタ。
Address Presentation Indication of whether presentation is allowed or restricted.
プレゼンテーションが許可または制限されているかどうかのプレゼンテーション表示に対応しています。
When a SIP call transits a SIP/ISUP gateway, the following information in the ISUP message should be examined/set when translating SIP Diversion headers to ISUP diversion information:
SIPコールは、SIP / ISUPゲートウェイを通過するときに、ISUPメッセージに次の情報は、ISUP迂回情報にSIP迂回ヘッダを変換するときに設定/検討されるべきです。
1) Redirecting Number
1）リダイレクト数
2) Redirecting Reason
2）理由のリダイレクト
3) Redirecting Address Presentation
3）リダイレクトアドレスプレゼンテーション
4) Original Called Number
4）オリジナル着番号
5) Original Redirecting Reason
5）オリジナルリダイレクト理由
6) Original Address Presentation
6）オリジナル住所プレゼンテーション
7) Redirection Counter
7）リダイレクトカウンター
An ISUP message contains information on the first and last diversions that occurred. The Redirection number is the number to which the call was being routed when the last diversion occurred. The Redirecting Reason is the reason that the last diversion occurred.
ISUPメッセージが発生した最初と最後の転換に関する情報が含まれています。リダイレクト番号は、最後の分岐が発生したときにコールがルーティングされた先の番号です。リダイレクト理由は、最後の分岐が発生した理由です。
The Original Called Number is the number to which the call was being routed when the first diversion occurred. The Original Redirecting Reason is the reason that the first diversion occurred.
オリジナル着信番号最初の分岐が発生したときにコールがルーティングされた先の番号です。オリジナルリダイレクト理由は、最初の分岐が発生した理由です。
When only one Diversion has occurred, the number to which the call was being routed when the diversion occurred is in the Redirecting Number and the reason for that diversion is carried in the Redirect Reason.
唯一の転換が発生した場合には、転換が発生したときに、コールがルーティングされた先の数は、リダイレクト番号であり、その迂回する理由は、リダイレクト理由で運ばれます。
The ISUP Redirecting Number SHOULD be used to set the value of the name-addr of the top-most Diversion header. The ISUP Redirecting Number address presentation SHOULD be used to set the value of the diversion-privacy of the top-most Diversion header. The ISUP Redirecting Reason SHOULD be used to set the value of the diversion-reason of the top-most Diversion header. When present, the Original Called Number SHOULD be used to set the name-addr of the bottom-most Diversion header. When present, the Original Redirecting Reason SHOULD be used to set the diversion-reason of the bottom-most Diversion header. When present, the Original Address Presentation SHOULD be used to set the diversion-privacy of the bottom-most Diversion header.
ISUPリダイレクト数最上位宛先ヘッダの名前-ADDRの値を設定するために使用されるべきです。 ISUPのリダイレクト番号アドレスの提示が最上位のDiversionヘッダーの転換 - プライバシーの値を設定するために使用されるべきです。 ISUPリダイレクト理由は、一番上の宛先ヘッダの流用理由の値を設定するために使用されるべきです。存在する場合、オリジナル被呼番号は、最も下の宛先ヘッダの名前-ADDRを設定するために使用されるべきです。存在する場合、元のリダイレクト理由は、一番下の宛先ヘッダの迂回理由を設定するために使用されるべきです。存在する場合、元のアドレスのプレゼンテーションは、一番下のDiversionヘッダーの流用、プライバシーを設定するために使用されるべきです。
The Redirection Counter value minus 1 SHOULD be stored in the diversion- counter associated with the top-most Diversion header. Presence of the diversion-counter for the bottom-most Diversion header is optional. If present, the diversion-counter of the bottom-most Diversion header SHOULD be 1.
リダイレクトカウンタ値マイナス1が最上位の宛先ヘッダに関連付けられたdiversion-カウンタに保存されるべきです。一番下の宛先ヘッダの転用カウンタの存在は任意です。存在する場合、最も下の宛先ヘッダの転用カウンタは1であるべきです。
The name-addr of the top-most Diversion header SHOULD be used to set the ISUP Redirecting Number. The diversion-reason of the top-most Diversion header SHOULD be used to set the ISUP Redirecting Reason. The diversion-privacy of the top-most Diversion header SHOULD be used to set the ISUP Redirecting Address Presentation.
最上位の宛先ヘッダの名前-addrがISUPリダイレクト数を設定するために使用されるべきです。最上位の宛先ヘッダの流用理由はISUPリダイレクト理由を設定するために使用されるべきです。最上位のDiversionヘッダーの転換 - プライバシーはアドレスプレゼンテーションをリダイレクトISUPを設定するために使用されるべきです。
When multiple Diversion headers are present, the name-addr of the bottom- most Diversion header SHOULD be used to set the ISUP Original Redirecting Number. When multiple Diversion headers are present, the diversion-reason of the bottom-most Diversion header SHOULD be used to set the ISUP Original Redirecting Reason. When multiple Diversion headers are present, the diversion-privacy of the bottom-most Diversion header SHOULD be used to set the ISUP Original Redirecting Address Presentation.
複数の宛先ヘッダが存在する場合、ボトム最も宛先ヘッダの名前-addrがISUPオリジナルリダイレクト数を設定するために使用されるべきです。複数の宛先ヘッダが存在する場合、最も下の宛先ヘッダの流用理由はISUPオリジナルリダイレクト理由を設定するために使用されるべきです。複数の宛先ヘッダが存在する場合、最も下の宛先ヘッダの転用、プライバシーがISUPオリジナルリダイレクトアドレスプレゼンテーションを設定するために使用されるべきです。
The ISUP Redirection Counter SHOULD be set equal to the sum of the counters of all Diversion headers in the SIP message. A Diversion header that does not explicitly specify a diversion-counter tag counts as 1.
ISUPリダイレクトカウンタは、SIPメッセージ内のすべての宛先ヘッダのカウンタの和に等しく設定されるべきです。明示的に1として流用カウンタタグカウントが指定されていない宛先ヘッダ。
ISUP/SIP GW
|
--IAM--------------------------------->|
Called Party Number =+19195551004 |
Redirecting Number =+19195551002 |
Address Presentation =presentation restricted
Original Called Number =+19195551001 |
RedirectionInformation: |
Original Redirecting Reason = Unconditional (1111)
Redirecting Reason = User busy (0001)
Redirection Counter = 5 |
|
|--INVITE +19195551004------>
| Diversion: <tel:+19195551002>
| ;reason=user-busy
| ;privacy="full"
| ;counter=4
| Diversion: <tel:+19195551001>
| ;reason=unconditional
| ;counter=1
|
|
ISUP/SIP GW
|
|<--INVITE +19195551004------
| Diversion: <tel:+19195551002>
| ;reason=user-busy
| ;privacy="full"
| ;counter=4
| Diversion: <tel:+19195551001>
| ;reason=unconditional
| ;counter=1
|
|
|
<--IAM---------------------------------|
Called Party Number =+19195551004 |
Redirecting Number =+19195551002 |
Address Presentation =presentation restricted
Original Called Number =+19195551001 |
RedirectionInformation: |
Original Redirecting Reason = Unconditional (1111)
Redirecting Reason = User busy (0001)
Redirection Counter = 5 |
An ISDN message can contain up to two instances of a Redirecting Number information element. When a diversion occurs, an additional Redirection number information element is added. When a third (or greater) diversion occurs, the new Redirecting Number information element replaces the bottom-most Redirection number information element.
ISDNメッセージは、リダイレクト番号情報要素の最大2つのインスタンスを含めることができます。転換が発生した場合、追加のリダイレクト番号情報要素が付加されます。第三の（またはそれ以上）の転換が発生した場合、新しいリダイレクト番号情報要素は、一番下のリダイレクト番号情報要素を置き換えます。
Called Party Number The number of the party to which the call is currently being routed.
パーティの数はコールが現在ルーティングされているために着番号。
Redirecting Number information element Aggregate information element that contains Redirecting number and Reason for diversion.
転換のための番号と理由をリダイレクト含ま番号情報要素集約情報要素をリダイレクト。
Redirecting Number The number to which the call was being routed when the last diversion occurred.
最後の転換が発生したときにコールがルーティングされた先の番号数をリダイレクトします。
Reason for Diversion The reason that the last diversion occurred.
迂回最後の迂回が発生した理由の理由。
Origin of Number Indicates whether the number is user provided and screened or network provided.
数の起源は数がユーザーに提供し、スクリーニングやネットワークが提供されるかどうかを示します。
Presentation Status Indicates if presentation is allowed or prohibited.
プレゼンテーションが許可または禁止されている場合はプレゼンテーションの状態を示します。
When a SIP call transits a SIP/ISDN gateway, the following information in the ISDN message should be examined/set when translating SIP Diversion headers to ISDN diversion information:
SIPコールは、SIP / ISDNゲートウェイを通過するときISDN迂回情報をSIP迂回ヘッダを変換するとき、ISDNメッセージ内の次の情報が/セットを検討すべきです。
1) Redirecting Number of the top-most Redirecting Number information element
一番上のリダイレクト番号情報要素の1）リダイレクト数
2) Reason for diversion of the top-most Redirection number information element
一番上のリダイレクト番号情報要素の転換のための2）理由
3) Origin of Number and Presentation Status of the top-most Redirection number information element
一番上のリダイレクト番号情報要素の数やプレゼンテーションステータスの3）起源
4) Redirection number of the bottom-most Redirection number information element
一番下のリダイレクト番号情報要素の4）リダイレクト数
5) Reason for diversion of the bottom-most Redirection number information element
一番下のリダイレクト番号情報要素を流用5）理由
6) Origin of Number and Presentation Status of the bottom-most Redirection number information element
一番下のリダイレクト番号情報要素の数やプレゼンテーションステータスの6）起源
An ISDN message contains information on the first and last diversions that occurred. The top-most Redirection number information element contains information (including the Redirecting Number, Origin of Number, Presentation Status, and Reason for diversion) about the last diversion that occurred. The bottom-most Redirection number information element contains information (including the Redirecting Number, Origin of Number, Presentation Status, and Reason for diversion) about the first diversion that occurred.
ISDNメッセージが発生した最初と最後の転換に関する情報が含まれています。一番上のリダイレクト番号情報要素が発生した最後の流用について（ナンバーのリダイレクト数、起源、プレゼンテーションの状態、および転換の理由を含む）の情報が含まれています。一番下のリダイレクト番号情報要素が発生した最初の流用について（リダイレクト番号、迂回のための番号の起源、プレゼンテーションの状態、および理由を含む）の情報が含まれています。
If only one Diversion has occurred, only one Redirection number information element is present.
唯一の転換が発生した場合には、一つだけのリダイレクト番号情報要素が存在しています。
The Redirecting Number information element has the same Type of Number/Numbering Plan, and Digits as the Calling Party Number information element.
リダイレクト番号情報要素は、発呼者番号情報要素として数/番号計画、および数字の同じタイプを持っています。
There is no Redirection Counter associated with this ISDN information element.
このISDN情報要素に関連付けられたリダイレクトカウンタはありません。
Notice that the order of the Redirection number information elements in an ISDN message (top=first, bottom=last) is reversed from the order of Diversion headers in a SIP message (top=last, bottom=first).
気づくISDNメッセージにリダイレクト番号情報要素の順序が（トップ=最初、最後の底=）はSIPメッセージ（トップ=最後に、ボトム=最初）における宛先ヘッダの順序と逆になります。
The Redirecting Number of the top-most ISDN Redirecting Number information element SHOULD be used to set the value of the name-addr of the bottom-most Diversion header. The Reason for Diversion of the top-most ISDN Redirecting Number information element SHOULD be used to set the value of the diversion-reason of the bottom-most Diversion header.
最上位ISDNリダイレクト番号情報要素のリダイレクト数は、一番下の宛先ヘッダの名前-ADDRの値を設定するために使用されるべきです。最上位ISDNリダイレクト番号情報要素の迂回理由は一番下の宛先ヘッダの流用理由の値を設定するために使用されるべきです。
The Origin of Number of the top-most ISDN Redirecting Number information element SHOULD be used to set the value of the diversion-screen of the bottom-most Diversion header. The Presentation Status of the top-most ISDN Redirecting Number information element SHOULD be used to set the value of the diversion-privacy of the bottom-most Diversion header.
最上位ISDNリダイレクト番号情報要素の数の起源は、最も下の宛先ヘッダの転換画面の値を設定するために使用されるべきです。最上位ISDNリダイレクト番号情報要素のプレゼンテーション状態は一番下の宛先ヘッダの転用、プライバシーの値を設定するために使用されるべきです。
The Redirecting Number of the bottom-most ISDN Redirecting Number information element SHOULD be used to set the value of the name-addr of the top-most Diversion header. The Reason for Diversion of the bottom-most ISDN Redirecting Number information element SHOULD be used to set the value of the diversion-reason of the top-most Diversion header.
最も下のISDNリダイレクト番号情報要素のリダイレクト数は、最上位の宛先ヘッダの名前-ADDRの値を設定するために使用されるべきです。最も下のISDNリダイレクト番号情報要素の迂回理由は最上位の宛先ヘッダの流用理由の値を設定するために使用されるべきです。
The Origin of Number of the bottom-most ISDN Redirecting Number information element SHOULD be used to set the value of the diversion-screen of the top-most Diversion header. The Presentation Status of the bottom-most ISDN Redirecting Number information element SHOULD be used to set the value of the diversion-privacy of the top-most Diversion header.
最も下のISDNリダイレクト番号情報要素の数の起源は、最上位の宛先ヘッダの転換画面の値を設定するために使用されるべきです。最も下のISDNリダイレクト番号情報要素のプレゼンテーション状態は最上位の宛先ヘッダの転用、プライバシーの値を設定するために使用されるべきです。
Presence of the diversion-counter in each of the Diversion headers is optional. If present, the diversion-counter of each Diversion header SHOULD be 1.
宛先ヘッダの各々に転換カウンタの存在は任意です。存在する場合、各宛先ヘッダの転用カウンタは1であるべきです。
The name-addr of the top-most Diversion header SHOULD be used to set the Redirecting Number of the bottom-most ISDN Redirecting Number information element.
最上位の宛先ヘッダの名前-addrが最も下のISDNリダイレクト番号情報要素のリダイレクト数を設定するために使用されるべきです。
The diversion-reason of the top-most Diversion header SHOULD be used to set the Reason for Diversion of the bottom-most ISDN Redirecting Number information element.
最上位の宛先ヘッダの流用の理由は、一番下のISDNリダイレクト番号情報要素の転換の理由を設定するために使用されるべきです。
The diversion-screen of the top-most Diversion header SHOULD be used to set the Origin of Number of the bottom-most ISDN Redirecting Number information element.
最上位の宛先ヘッダの流用画面を一番下のISDNリダイレクト番号情報要素の数の原点を設定するために使用されるべきです。
The diversion-privacy of the top-most Diversion header SHOULD be used to set the Presentation Status of the bottom-most ISDN Redirecting Number information element.
最上位のDiversionヘッダーの転換 - プライバシーは一番下のISDNリダイレクト番号情報要素のプレゼンテーションステータスを設定するために使用されるべきです。
The name-addr of the bottom-most Diversion header SHOULD be used to set the Redirecting Number of the top-most ISDN Redirecting Number information element.
一番下の宛先ヘッダの名前-addrが最上位ISDNリダイレクト番号情報要素のリダイレクト数を設定するために使用されるべきです。
The diversion-reason of the bottom-most Diversion header SHOULD be used to set the Reason for Diversion of the top-most ISDN Redirecting Number information element.
一番下の宛先ヘッダの流用の理由は、最上位のISDNリダイレクト番号情報要素の転換の理由を設定するために使用されるべきです。
The diversion-screen of the bottom-most Diversion header SHOULD be used to set the Origin of Number of the top-most ISDN Redirecting Number information element.
一番下の宛先ヘッダの転用画面が最上位ISDNリダイレクト番号情報要素の数の原点を設定するために使用されるべきです。
The diversion-privacy of the bottom-most Diversion header SHOULD be used to set the Presentation Status of the top-most ISDN Redirecting Number information element.
一番下のDiversionヘッダーの転換 - プライバシーは最上位のISDNリダイレクト番号情報要素のプレゼンテーションステータスを設定するために使用されるべきです。
ISDN/SIP GW
|
--Setup------------------------------->|
Called party number =+19195551004
Redirecting Number information element:
Redirecting Number =+19195551001
Reason for redirection = Unconditional (1111)
Origin of Number = passed network screening
Presentation Status = presentation allowed
Redirecting Number information element:
Redirecting Number =+19195551002
Reason for redirection = User busy (0001)
Origin of Number = passed network screening
Presentation Status = presentation prohibited
|
|--INVITE tel:+19195551004---->
| Diversion: <tel:+19195551002>
| ;reason=user-busy
| ;screen="yes"
| ;privacy="off"
| Diversion: <tel:+19195551001>
| ;reason=unconditional
| ;screen="yes"
| ;privacy="full"
|
|
ISDN/SIP GW
|
<--Setup-------------------------------|
Called party number =+19195551004
Redirecting Number information element:
Redirecting Number =+19195551001
Reason for redirection = Unconditional (1111)
Origin of Number = passed network screening
Presentation Status = presentation allowed
Redirecting Number information element:
Redirecting Number =+19195551002
Reason for redirection = User busy (0001)
Origin of Number = passed network screening
Presentation Status = presentation prohibited
|
|<--INVITE tel:+19195551004----
| Diversion: <tel:+19195551002>
| ;reason=user-busy
| ;screen="yes"
| ;privacy="off
| Diversion: <tel:+19195551001>
| ;reason=unconditional
| ;screen="yes"
| ;privacy="full"
|
Because ISUP and ISDN only support a subset of the information in a SIP Diversion header, information loss occurs during translation at a SIP/ISUP or SIP/ISDN boundary.
ISUPとISDNのみSIP迂回ヘッダ内の情報のサブセットをサポートするので、情報の損失は、SIP / ISUP又はSIP / ISDN境界の変換時に発生します。
Because ISUP and ISDN only support a subset of URI types (specifically tel: URIs and sip:x@y;user=phone URIs), diversion information occurring for other URI types may be lost when crossing from SIP to ISDN or ISUP.
（：URIとSIP：具体TELのx @ yを、ユーザ=電話のURI）ISUPとISDNのみURIタイプのサブセットをサポートするため、SIPからISDNまたはISUPを横断するとき、他のURIタイプに対して生じる迂回情報が失われる可能性があります。
Because ISUP and ISDN only support a subset of the reason codes supported by the Diversion header, specific reason code information may be lost when crossing from SIP to ISDN or ISUP.
ISUPとISDNのみ宛先ヘッダによって支持理由コードのサブセットをサポートするため、SIPからISDNまたはISUPを横断するとき、特定の理由コード情報が失われる可能性があります。
Because ISDN does not support a counter field (indicating the number of diversions that have occurred), counter information may be lost when crossing from SIP to ISDN.
ISDNは、（発生した転換の数を示す）カウンタフィールドをサポートしていないため、SIPからISDNを横断するときの情報が失われる可能性が対抗。
Special acknowledgement to both Bryan Byerly and JR Yang. As original authors of this document, both were instrumental is getting this document written.
ブライアンByerlyとJRヤンの両方に特別承認。このドキュメントのオリジナルの作者として、両方が楽器だったが、この文書が書かれてきています。
We would like to thank David Williams, Ameet Kher, Satya Khatter, Manoj Bhatia, Shail Bhatnagar, Denise Caballero-Mccann, Kara Adams, Charles Eckel of Cisco Systems, and Bert Culpepper of InterVoice-Brite for their insights, inputs, and comments.
我々は彼らの洞察力、入力、およびコメントのためにデビッド・ウィリアムズ、Ameet Kher、サティヤKhatter、ManojさんBhatiaは、Shail Bhatnagar、デニス・キャバレロ・マッキャン、カラ・アダムス、シスコシステムズのチャールズ・Eckel氏、およびInterVoiceブライトのバートカルペッパーを感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
Authors' Addresses
著者のアドレス
Steve Levy Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA
スティーブ・レヴィシスコシステムズ7025キットクリーク道路私書箱14987リサーチトライアングルパーク、NC 27709 USA箱
EMail: stlevy@cisco.com
メールアドレス：stlevy@cisco.com
Marianne Mohali (editor) Orange Labs 38-40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France
マリアンヌモハーリ（エディタ）オレンジLabsの38-40 RUEデュ一般ルクレールイシレムリノーセデックス9、フランス92794
Phone: +33145294514 EMail: marianne.mohali@orange-ftgroup.com
電話番号：+33145294514 Eメール：marianne.mohali@orange-ftgroup.com