[要約] RFC 5806は、SIP（Session Initiation Protocol）における転送情報の指示を定義しています。その目的は、通話の転送や転送先の情報を明示的に示すことで、通信の品質やセキュリティを向上させることです。
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
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.
このRFCは、元々SIPワーキンググループに提出されたインターネットドラフトのテキストを含んでおり、現在、歴史的記録のために公開されており、後の情報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エディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このRFCは、元々SIPワーキンググループに提出されたインターネットドラフトのテキストを含んでおり、現在、歴史的記録のために公開されており、後の情報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.
Legacy Telephony Networkでは、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.
迂回ヘッダーは、コールが転用されたものに基づいて機能ロジックの実装を可能にします。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
リクエストの究極の宛先エンドポイントへの変更。ルーティングの決定によって引き起こされなかったリクエストのリクエスト-URIの変更。これは、たわみやリダイレクトとも呼ばれることもあります。
A diversion can occur when the "user" portion of the Request-URI is changed for a reason other than expansion or translation.
拡張や翻訳以外の理由で、リクエスト-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.
変更が非ルーティングの決定によるものである場合、リクエスト-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.
新しいリクエスト自体を分岐することにより、受信または内部で生成された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）アプリケーションなどの特定のサードパーティの機能を実装するには、呼び出し元にインテリジェントに応答できるように、転換情報を指定する第三者に提供する必要があります。これらの状況では、転用された通話を受けた当事者は、2つの質問に対して回答が必要です。
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.
この文書は、転用ヘッダーの使用法を提案して、転用された電話を受けた当事者のためにこれらの質問に答えることを提案しています。
Insertion of the previous Request-URI (before the diversion occurred) into the Diversion header answers question 1.
迂回ヘッダーへの以前の要求-RI（迂回が発生する前）の挿入質問1。
Insertion of the "reason" tag into the Diversion header (by the divertor) answers question 2.
「Reason」タグを転換ヘッダーに挿入して（ディバーターによる）質問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.
通常の通話ルーティングの変更の場合、迂回情報を追加しないでください。したがって、スピードダイヤルなどの機能がリクエスト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.
通話転送や呼び出しのたわみなどの機能がリクエスト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)]
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を返すSIPユーザーエージェントサービス（UAS）は、以前のリクエストURIと転用の理由を含む転換ヘッダーを追加する必要があります。
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を受信するSIP UACでは、3xxから生じる各下流のフォークリクエストに迂回ヘッダーをコピーする必要があります。
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.
リクエストを受信し、リクエストを別のエンドポイントに転用する連絡先を含む3XXを返すSIPリダイレクトサーバーは、着信要求からリクエスト-URIを含む転換ヘッダーと転用の理由を追加する必要があります。
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.
リクエストを受信し、リクエストを別のエンドポイントに転用するために転送要求のリクエスト-RIを変更する機能を呼び出すSIPプロキシは、着信要求からリクエスト-RIを含む転換ヘッダーを追加する必要があります。転用。
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.
リクエストを受信し、リクエストを別のエンドポイントに転用する連絡先を含む3XXを返すSIPプロキシは、着信要求からリクエスト-URIを含む転換ヘッダーと転用の理由を追加するはずです。
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.
上流3xxsを生成または転送するSIPプロキシまたはユーザーエージェントは、非回復です。受信（または内部生成された）3XXS自体を処理するSIPプロキシまたはユーザーエージェントが再発しています。
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.
このメッセージの流れでは、通常、コールはbob@bにルーティングされます。ただし、Proxy 2（P2）は、Carol@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------------------------------------------------>|
| | | | |
| | | | |
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）が非回復的に実装されています。プロキシ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------------------------------------------------>|
| | | | |
| | | | |
In this message flow, Proxy 2 (P2) non-recursively implements Call Forward Unconditional (CFUNC) to Carol@C. Proxy 1 (P1) is recursing.
このメッセージの流れでは、プロキシ2（P2）が非回復的に実装されています。プロキシ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------------------------------------------------>|
| | | | |
| | | | |
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）が非回復的に実装されています。Proxy 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.
このメッセージの流れでは、Proxy 2（P2）が再帰的にCAROL@CにBusy（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------------------------------------------------>|
| | | | |
| | | | |
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）が非回復的に実装して、carol@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）が非回復的に実装して、carol@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）が非回復的に実装されています。Proxy 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.
迂回ヘッダーの使用は、NO-ANSWERでのコールフォワードのいくつかのバリアント実装について、以下に示されています。
In this message flow, Proxy 2 (P2) recursively implements Call Forward on No Answer (CFNA) to Carol@C.
このメッセージの流れでは、Proxy 2（P2）がCarol@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------------------------------------------------>|
| | | | |
| | | | |
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）が非回復的に実装されています。プロキシ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------------------------------------------------>|
| | | | |
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）が非回復的に実装されています。プロキシ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------------------------------------------------>|
| | | | |
| | | | |
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）が非回復的に実装されています。Proxy 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）が再帰的にコールフォワードを実装しています（CFUNV）carol@c。
+------------------------+
| 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------------------------------------------------>|
| | | | |
| | | | |
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）が非回復的に実装して、Carol@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------------------------------------------------>|
| | | | |
| | | | |
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）が非回復的に実装して、Carol@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.
このメッセージの流れでは、Proxy 2（P2）がCarol@cに前方の前方の無条件（CFUNC）を実装します。Cは、Busy（CFB）で5551234@dに通話を進めます。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.
このメッセージの流れでは、Proxy 2（P2）がCarol@cに前方の前方の無条件（CFUNC）を実装します。（P2は通常、bへの呼び出しをルーティングしていました）。c次に、5551234@dに回答なし（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?
迂回ヘッダーを使用する場合、プライバシーに関する考慮事項がいくつかあります。迂回ヘッダーの使用は、迂回するUASが迂回されたUASを信頼することを意味します。SIPプロキシまたはSIPユーザーエージェントによる迂回ヘッダーの使用は、ルート情報の情報漏れを引き起こし、アップストリーム3XXSの信頼されていないSIPプロキシおよび信頼されていない発信者に情報を呼び出すことができます。この情報の漏れは、信頼できるアップストリームプロキシサーバーを繰り返すことで軽減できます。すべてのプロキシが非再帰的である必要があるSIPネットワークアーキテクチャの場合、迂回ヘッダーの隠蔽は、発信者へのルート情報の漏れを防ぐために必要とされる場合があります。迂回ヘッダーの隠れを達成するために、信頼できるアップストリームプロキシはレコードルートヘッダーを追加し、秘密キーを使用して、上流に転送される3XXSの迂回ヘッダーの内容を暗号化します。再インバイトを受け取ると、プロキシは迂回ヘッダーの内容（秘密の鍵を使用）を復号化し、招待を転送します。現在、迂回と非表示のヘッダーの定義された相互作用はありません。質問：あるべきですか？
Only the relevant headers have been included in the following examples. The contents of the Session Description Protocols (SDPs) have also been omitted.
関連するヘッダーのみが以下の例に含まれています。セッション説明プロトコル（SDP）の内容も省略されています。
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は、3番目の会社と契約して、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.
最初のフローでは、アリスはピザを呼びかけます。2番目のフローでは、アリスはバラを呼びます。どちらの場合も、同じ夜間サービス会社（および受付係、キャロル）が電話に応答します。ただし、迂回ヘッダーが使用されるため、キャロルは発信者への挨拶をカスタマイズすることができます。
+-------------------------------------+
| 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からSIPプロキシサーバー1：
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):
[2] Proxy Server 1をSIPプロキシサーバー2（wesellpizza.com）からSIPします：
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はCFTODをNightService.comに実装します。
[3] SIP proxy server 2 (WeSellPizza.com) to SIP proxy server 3 (NightService.com):
[3] Proxy Server 2（wesellpizza.com）をSIPプロキシサーバー3（nightservice.com）からSIP
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（nightservice.com）からUAS1（Carol）へ：
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.
ACDキーは転換ヘッダーからキーをキーして、キャロルのWebブラウザーでWesellpizza FAQを引き上げます。
[5] UAS1 to SIP proxy server 3:
[5] UAS1からSIPプロキシサーバー3：
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:
[6] SIPプロキシサーバー3からProxy Server 2をSIPします。
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:
[7] Proxy Server 2をSIPプロキシサーバー1にSIPします：
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
[8] SIPプロキシサーバー1からUAC
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] UACにUAS1をSIP：
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フローが始まり、キャロルは「こんにちは、ウェセルピッツァ。どうやってあなたを助けることができますか？」と答えます。
+---------------------------------------+
| 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からSIPプロキシサーバー1：
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):
[2] Proxy Server 1をSIPプロキシサーバー4（wesellflowers.com）にSIPします：
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はCFTODをNightService.comに実装します。
[3] SIP proxy server 4 (WeSellFlowers.com) to SIP proxy server 1 (NightService.com):
[3] SIP Proxy Server 4（wesellflowers.com）からProxy Server 1（nightservice.com）をSIPする：
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
[5] SIP proxy server 1 (WeSellFlowers.com) to SIP proxy server 3 (NightService.com):
[5] SIPプロキシサーバー1（wesellflowers.com）からProxy Server 3（nightservice.com）をSIPします。
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（nightservice.com）からUAS1（Carol）へ：
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.
ACDキーは転換ヘッダーからキーを外し、キャロルのWebブラウザーでWesellFlowers FAQを引き上げます。
[7] SIP UAS1 to SIP proxy server 3:
[7] SIP UAS1からSIPプロキシサーバー3：
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:
[8] Proxyサーバー3をSIPプロキシサーバー1にSIPします1：
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
[9] SIPプロキシサーバー1からUAC
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:
[10] sip uaCからsip uas1：
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-dot-disturbボタンを押しています。Bobの電話のdo-ds-disturb機能は、voicemail@isp.comにcfunc（forword undofitional）に構成されています。迂回ヘッダーが使用されるため、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からSIPプロキシサーバー1：
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:
[2] SIPプロキシサーバー1からProxy Server 2をSIPします。
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):
[3] SIPプロキシサーバー2からUAS1（ボブのSIP電話）：
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-dot-disturbボタンを押していたので、ボブの電話はボイスメールサービスへの通話を転送します。
[4] User agent server 1 (UAS1) to SIP proxy server 2 (P2)
[4] ユーザーエージェントサーバー1（UAS1）をSIPプロキシサーバー2（P2）
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):
[5] SIPプロキシサーバー2からUAS1（ボブのSIP電話）：
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] SIPプロキシサーバー2（P2）からProxy Server 1（P1）をSIPします。
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:
[7] SIPプロキシサーバー1からProxy Server 2をSIPします。
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] SIPプロキシサーバー1（P1）からUAC（Alice-PC）：
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からSIPプロキシサーバー1：
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（Alice-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):
[11] SIP UAC（Alice-PC）へのボイスメールサーバー：
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.
迂回ヘッダーが存在するため、ボイスメールサーバーはアリスのメッセージをボブのボイスメールボックスに配置できます。
Question 1:
質問1：
Why do we need the Diversion header when we can see the To: header?
To：Headerを見ることができるのに、なぜ転用ヘッダーが必要なのですか？
Answer:
答え：
a) The To: header is not guaranteed to have significance to the called party.
a) to：ヘッダーは、呼び出されたパーティーに重要性を持つことが保証されていません。
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の構成問題になり、名前空間衝突の傾向があります。
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).
迂回ヘッダーのサポートにより、ボブはボイスメールボックス（bob@uas1.isp.com）にグローバルに重要なURLを1つ添加して、サードパーティサービス（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?
Via：Headerを見ることができるのに、なぜ転用ヘッダーが必要なのですか？
Answer:
答え：
The Via header does not contain information about servers whom have deflected the call (using a 3xx).
Viaヘッダーには、呼び出しを偏向したサーバーに関する情報は含まれていません（3xxを使用）。
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（非再帰）または追加のフォークダウンストリーム要求（再帰）として実装できます。次のテキストでは、小文字の「リダイレクト」はSIPの使用量を示し、大文字の「リダイレクト」はISUPの使用法を示します。
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 Mapping of ISUP/ISDN reason codes to Diversion reason codes is performed as follows:
0000 =不明0001 =コールフォワードビジーまたはコールディスビジー0010 =コールフォワーディング0010 =返信なし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 "no-annswer" 1111 "無条件" 1010 "dedlection" 1001 "0000他のすべて
This section describes how generic ISUP diversion information elements may be translated across an ISUP/SIP gateway.
このセクションでは、ISUP/SIPゲートウェイ全体で一般的なISUP迂回情報要素をどのように翻訳するかについて説明します。
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ゲートウェイをトランジングする場合、SIP迂回ヘッダーをISUP迂回情報に変換するときに、ISUPメッセージの次の情報を調べる必要があります。
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.
1つの迂回のみが発生した場合、迂回が発生したときに通話がルーティングされていた数はリダイレクト数にあり、その迂回の理由はリダイレクトの理由で運ばれます。
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リダイレクト番号アドレスプレゼンテーションを使用して、最上位迂回ヘッダーの迂回プリバシーの価値を設定する必要があります。ISUPリダイレクト理由は、最上位迂回ヘッダーの迂回季節の価値を設定するために使用する必要があります。存在する場合、オリジナルの呼び出された番号を使用して、一番下の迂回ヘッダーの名前-ADDRを設定する必要があります。存在する場合、元のリダイレクトの理由を使用して、一番下の迂回ヘッダーの迂回季節を設定する必要があります。存在する場合、元のアドレスプレゼンテーションを使用して、一番下の迂回ヘッダーの迂回プリバシーを設定する必要があります。
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は、最上位迂回ヘッダーに関連する迂回カウンターに保存する必要があります。一番下の迂回ヘッダーの迂回カウンターの存在はオプションです。存在する場合、一番下の迂回ヘッダーの迂回カウンターは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リダイレクト理由を設定する必要があります。最上位迂回ヘッダーの迂回プリバシーを使用して、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つのインスタンスを含めることができます。迂回が発生すると、追加のリダイレクト番号情報要素が追加されます。3番目の（またはより大きな）迂回が発生すると、新しいリダイレクト番号情報要素が最下部のリダイレクト番号情報要素を置き換えます。
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ゲートウェイをトランジングする場合、SIP迂回ヘッダーをISDN迂回情報に変換するときに、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.
1つの迂回のみが発生した場合、1つのリダイレクト番号情報要素のみが存在します。
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メッセージのリダイレクト番号情報要素の順序（TOP = First、Bottom = last）は、SIPメッセージ（TOP = last、bottom = first）の迂回ヘッダーの順序から逆転していることに注意してください。
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.
最上位の迂回ヘッダーの迂回プリバシーを使用して、最小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.
一番下の迂回ヘッダーの迂回プリバシーを使用して、最上位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.
ISUPとISDNは、URIタイプのサブセットのみをサポートするため（特に電話：urisおよびsip：x@y; user = phone uris）、他のURIタイプに発生する迂回情報は、SIPからISDNまたはISUPに渡るときに失われる可能性があります。
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.
ブライアン・バイアリーとジュニア・ヤンの両方への特別な謝辞。この文書の元の著者として、どちらもインストゥルメンタルがこの文書を書かれています。
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.
デビッド・ウィリアムズ、アミート・カー、サティヤ・カー、マノジ・バティア、シェイル・バトナガル、デニス・カバレロ・マッキャン、カラ・アダムス、シスコ・システムのチャールズ・エッケル、洞察、インプット、コメントのためにインターバイス・ブライトのバート・カルペッパーに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
Authors' Addresses
著者のアドレス
Steve Levy Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA
Steve Levy Cisco Systems 7025 Kit Creek Road P.O.Box 14987 Research Triangle Park、NC 27709 USA
EMail: stlevy@cisco.com
Marianne Mohali (editor) Orange Labs 38-40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France
Marianne Mohali（編集者）Orange Labs 38-40 Rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794フランス
Phone: +33145294514
EMail: marianne.mohali@orange-ftgroup.com