[要約] RFC 5589は、SIP通話制御の転送に関する仕様です。このRFCの目的は、SIPセッションの転送に関する標準化と、転送の手順や動作の詳細を提供することです。
Network Working Group R. Sparks
Request for Comments: 5589 Tekelec
BCP: 149 A. Johnston, Ed.
Category: Best Current Practice Avaya
D. Petrie
SIPez LLC
June 2009
Session Initiation Protocol (SIP) Call Control - Transfer
セッション開始プロトコル（SIP）コールコントロール - 転送
Status of This Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework.
このドキュメントでは、セッション開始プロトコル（SIP）でコール転送機能を提供することについて説明します。紹介や交換などのSIP拡張機能は、ブラインド転送、協議譲渡、出席移転など、多くの移籍サービスを提供するために使用されます。この作業は、SIPマルチパーティコールコントロールフレームワークの一部です。
Table of Contents
目次
1. Overview ........................................................3
2. Actors and Roles ................................................3
3. Terminology .....................................................4
4. Requirements ....................................................4
5. Using REFER to Achieve Call Transfer ............................5
6. Basic Transfer ..................................................6
6.1. Successful Transfer ........................................8
6.2. Transfer with Dialog Reuse ................................11
6.3. Failed Transfer ...........................................15
6.3.1. Target Busy ........................................16
6.3.2. Transfer Target Does Not Answer ....................17
7. Transfer with Consultation Hold ................................18
7.1. Exposing Transfer Target ..................................18
7.2. Protecting Transfer Target ................................19
7.3. Attended Transfer .........................................24
7.4. Recovery When One Party Does Not Support REFER ............28
7.5. Attended Transfer When Contact URI Is Not Known to
Route to a User Agent .....................................29
7.6. Semi-Attended Transfer ....................................37
7.7. Attended Transfer Fallback to Basic Transfer ..............42
8. Transfer with Referred-By ......................................45
9. Transfer as an Ad Hoc Conference ...............................49
10. Transfer with Multiple Parties ................................52
11. Gateway Transfer Issues .......................................54
11.1. Coerce Gateway Hairpins to the Same Gateway ..............54
11.2. Consultative Turned Blind Gateway Glare ..................55
12. Security Considerations .......................................55
13. Acknowledgments ...............................................56
14. References ....................................................56
14.1. Normative References .....................................56
14.2. Informative References ...................................57
This document describes providing Call Transfer capabilities and requirements in SIP [RFC3261]. This work is part of the multiparty call control framework [CC-FRMWRK].
このドキュメントでは、SIP [RFC3261]のコール転送機能と要件を提供することについて説明しています。この作業は、マルチパーティコールコントロールフレームワーク[CC-FRMWRK]の一部です。
The mechanisms discussed here are most closely related to traditional, basic, and consultation hold transfers.
ここで説明するメカニズムは、従来の、基本的、協議の保留に最も密接に関連しています。
This document details the use of the REFER method [RFC3515] and Replaces [RFC3891] header field to achieve call transfer.
このドキュメントは、参照方法[RFC3515]の使用を詳しく説明し、[RFC3891]ヘッダーフィールドを置き換えて、コール転送を達成します。
A User Agent (UA) that fully supports the transfer mechanisms described in this document supports REFER [RFC3515] and Replaces [RFC3891] in addition to RFC 3261 [RFC3261]. A User Agent should use a Contact URI that meets the requirements in Section 8.1.1.8 of RFC 3261. A compliant User Agent supports the Target-Dialog header field [RFC4538].
このドキュメントで説明されている転送メカニズムを完全にサポートするユーザーエージェント（UA）は、[RFC3515]を参照し、RFC 3261 [RFC3261]に加えて[RFC3891]を置き換えます。ユーザーエージェントは、RFC 3261のセクション8.1.1.8の要件を満たす連絡先URIを使用する必要があります。準拠したユーザーエージェントは、ターゲットダイアログヘッダーフィールド[RFC4538]をサポートします。
There are three actors in a given transfer event, each playing one of the following roles:
特定の転送イベントには3人の俳優がいます。それぞれが次の役割のいずれかを演奏しています。
Transferee: the party being transferred to the Transfer Target.
譲受人：譲渡ターゲットに転送される当事者。
Transferor: the party initiating the transfer.
譲渡人：譲渡を開始する当事者。
Transfer Target: the new party being introduced into a call with the Transferee.
転送ターゲット：新しい当事者が譲受人との電話に導入されています。
The following roles are used to describe transfer requirements and scenarios:
次の役割は、転送要件とシナリオを説明するために使用されます。
Originator: wishes to place a call to the Recipient. This actor is the source of the first INVITE in a session, to either a Facilitator or a Screener.
オリジネーター：受信者に電話をかけたい。この俳優は、ファシリテーターまたはスクリーナーのいずれかのセッションでの最初の招待のソースです。
Facilitator: receives a call or out-of-band request from the Originator, establishes a call to the Recipient through the Screener, and connects the Originator to the Recipient. Typically, a Facilitator acts on behalf of the Originator.
ファシリテーター：オリジネーターからのコールまたはバンド外のリクエストを受信し、スクリーナーを介して受信者への電話を確立し、オリジネーターを受信者に接続します。通常、ファシリテーターは発信者に代わって行動します。
Screener: receives a call ultimately intended for the Recipient and transfers the calling party to the Recipient if appropriate. Typically, a Screener acts on behalf of the Recipient.
スクリーナー：最終的に受信者向けのコールを受信し、必要に応じてレシピエントに発信者を転送します。通常、スクリーナーは受信者に代わって行動します。
Recipient: the party to which the Originator is ultimately connected.
受信者：オリジネーターが最終的に接続されている当事者。
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 BCP 14, RFC 2119 [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
1. Any party in a SIP session must be able to transfer any other party in that session at any point in that session.
1. SIPセッションの当事者は、そのセッションの任意の時点でそのセッションの他の当事者を転送できる必要があります。
2. The Transferor and the Transferee must not be removed from a session as part of a transfer transaction.
2. 譲渡人と譲受人は、転送取引の一部としてセッションから削除されてはなりません。
At first glance, requirement 2 may seem to indicate that the user experience in a transfer must be significantly different from what a current Private Branch Exchange (PBX) or Centrex user expects. As the call flows in this document show, this is not the case. A client may preserve the current experience. In fact, without this requirement, some forms of the current experience (ringback on transfer failure, for instance) will be lost.
一見すると、要件2は、転送でのユーザーエクスペリエンスが、現在のプライベートブランチエクスチェンジ（PBX）またはCentrexユーザーが期待するものとは大きく異なる必要があることを示しているように見えるかもしれません。このドキュメントでコールが流れるように、これはそうではありません。クライアントは現在のエクスペリエンスを保存する場合があります。実際、この要件がなければ、いくつかの形式の現在の経験（たとえば、転送障害に関するリングバック）は失われます。
3. The Transferor must know whether or not the transfer was successful.
3. 譲渡人は、転送が成功したかどうかを知る必要があります。
4. The Transferee must be able to replace an existing dialog with a new dialog.
4. 譲受人は、既存のダイアログを新しいダイアログに置き換えることができる必要があります。
5. The Transferor and Transferee should indicate their support for the primitives required to achieve transfer.
5. 譲渡人と譲受人は、譲渡を達成するために必要なプリミティブに対する支援を示す必要があります。
6. The Transferor should provide the Transfer Target and Transferee with information about the nature and progress of the transfer operation being attempted.
6. 譲渡人は、転送ターゲットと譲受人に試みられている転送操作の性質と進行に関する情報を提供する必要があります。
To meet this requirement, the transfer operation can be modeled as an ad hoc conference between three parties, as discussed in Section 9.
この要件を満たすために、セクション9で説明したように、3つの政党間のアドホック会議として転送操作をモデル化できます。
A REFER [RFC3515] can be issued by the Transferor to cause the Transferee to issue an INVITE to the Transfer Target. Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request. The media negotiated between the transferee and the Transfer Target is not affected by the media that had been negotiated between the Transferor and the Transferee. In particular, the INVITE issued by the Transferee will have the same Session Description Protocol (SDP) body it would have if the Transferee had initiated that INVITE on its own. Further, the disposition of the media streams between the Transferor and the Transferee is not altered by the REFER method.
紹介[RFC3515]は、譲受人が譲受人に転送ターゲットへの招待を発行するように発行することができます。成功した紹介トランザクションは、譲渡人と譲受人の間のセッションを終了しないことに注意してください。これらの当事者がセッションを終了したい場合、その後のさようならリクエストでそうしなければなりません。譲受人と譲渡ターゲットの間で交渉されたメディアは、譲渡人と譲受人の間で交渉されたメディアの影響を受けません。特に、譲受人によって発行された招待は、譲受人がその招待状を独自に開始した場合に同じセッション説明プロトコル（SDP）ボディを持つことになります。さらに、譲渡人と譲受人の間のメディアストリームの処分は、紹介方法によって変更されません。
Agents may alter a session's media through additional signaling. For example, they may make use of the SIP hold re-INVITE [RFC3261] or conferencing extensions described in the conferencing framework [RFC4353].
エージェントは、追加のシグナリングを通じてセッションのメディアを変更する場合があります。たとえば、SIP Hold Re-Invite [RFC3261]または会議フレームワーク[RFC4353]に記載されている拡張機能を授与する場合があります。
To perform the transfer, the Transferor and Transferee could reuse an existing dialog established by an INVITE to send the REFER. This would result in a single dialog shared by two uses -- an invite usage and a subscription usage. The call flows for this are shown in detail in Section 6.2. However, the approach described in this document is to avoid dialog reuse. The issues and difficulties associated with dialog reuse are described in [RFC5057].
転送を実行するために、譲渡人と譲受人は、紹介を送信する招待によって確立された既存のダイアログを再利用できます。これにより、2つの用途で共有される単一のダイアログが発生します。招待状の使用法とサブスクリプションの使用です。これのコールフローは、セクション6.2に詳細に示されています。ただし、このドキュメントで説明されているアプローチは、ダイアログの再利用を避けることです。ダイアログの再利用に関連する問題と困難は、[RFC5057]に記載されています。
Motivations for reusing the existing dialog include:
既存のダイアログを再利用する動機は次のとおりです。
1. There was no way to ensure that a REFER on a new dialog would reach the particular endpoint involved in a transfer. Many factors, including details of implementations and changes in proxy routing between an INVITE and a REFER could cause the REFER to be sent to the wrong place. Sending the REFER down the existing dialog ensured it got to the endpoint to which we were already talking.
1. 新しいダイアログに関する参照が、転送に関連する特定のエンドポイントに到達することを保証する方法はありませんでした。実装の詳細や招待状と紹介の間のプロキシルーティングの変更など、多くの要因により、紹介が間違った場所に送られる可能性があります。既存のダイアログを参照すると、既に話しているエンドポイントに到達したことが確認されました。
2. It was unclear how to associate an existing invite usage with a REFER arriving on a new dialog, where it was completely obvious what the association was when the REFER came on the INVITE usage's dialog.
2. 既存の招待状の使用法を新しいダイアログに到着する紹介に関連付ける方法は不明でした。ここでは、紹介が招待状の使用法のダイアログで紹介されたときに協会が何であるかが完全に明らかでした。
3. There were concerns with authorizing out-of-dialog REFERs. The authorization policy for REFER in most implementations piggybacks on the authorization policy for INVITE (which is, in most cases, based simply on "I placed or answered this call").
3. 外れている言及の許可に懸念がありました。ほとんどの実装での紹介の認可ポリシーは、招待のための承認ポリシーに関するピギーバック（ほとんどの場合、単に「この呼び出しを配置または回答した」に基づいています）。
Globally Routable UA URIs (GRUUs) [SIP-GRUU] can be used to address problem 1. Problem 2 can be addressed using the Target-Dialog header field defined in [RFC4538]. In the immediate term, this solution to problem 2 allows the existing REFER authorization policy to be reused.
グローバルにルーティング可能なua uris（gruus）[sip-gruu]は、問題1に対処するために使用できます。問題2は、[RFC4538]で定義されたターゲットダイアログヘッダーフィールドを使用して対処できます。直接的に、問題2のこのソリューションにより、既存の紹介承認ポリシーを再利用できます。
As a result, if the Transferee supports the target-dialog extension and the Transferor knows the Contact URI is routable outside the dialog, the REFER SHOULD be sent in a new dialog. If the nature of the Contact URI is not known or if support for the target-dialog extension is not known, the REFER SHOULD be sent inside the existing dialog. A Transferee MUST be prepared to receive a REFER either inside or outside a dialog. One way that a Transferor could know that a Contact URI is routable outside a dialog is by validation (e.g., sending an OPTIONS and receiving a response) or if it satisfies the properties described in the GRUU specification [SIP-GRUU].
その結果、譲受人がターゲットダイアログ拡張をサポートし、譲渡人がダイアログの外側でルーティング可能な連絡先を知っている場合、紹介は新しいダイアログで送信する必要があります。接触URIの性質が不明な場合、またはターゲットダイアログ拡張のサポートが不明な場合は、既存のダイアログ内に紹介を送信する必要があります。譲受人は、ダイアログ内または外側のいずれかの紹介を受ける準備をする必要があります。譲渡人がダイアログの外部でuriをルーティングできることを転送者が知ることができる1つの方法は、検証（たとえば、オプションを送信して応答を受信する）、またはGruu仕様[SIP-Gruu]に記載されているプロパティを満たしている場合です。
This document does not prescribe the flows and examples precisely as they are shown, but rather the flows illustrate the principles for best practice for the transfer feature. The call flows represent well-reviewed examples of SIP usage to implement transfer with REFER, which are Best Common Practice according to IETF consensus.
このドキュメントでは、フローと例を示すように正確に規定するのではなく、流れが転送機能のベストプラクティスの原則を示しています。コールフローは、IETFコンセンサスに従って最も一般的な慣行である紹介で転送を実装するために、SIP使用量のよくレビューされた例を表しています。
In most of the following examples, the Transferor is in the atlanta.example.com domain, the Transferee is in the biloxi.example.com, and the Transfer Target is in the chicago.example.com domain.
次のほとんどの例では、譲渡者はatlanta.example.comドメインにあり、譲受人はbiloxi.example.comにあり、転送ターゲットはchicago.example.comドメインにあります。
Basic Transfer consists of the Transferor providing the Transfer Target's contact to the Transferee. The Transferee attempts to establish a session using that contact and reports the results of that attempt to the Transferor. The signaling relationship between the Transferor and Transferee is not terminated, so the call is recoverable if the Transfer Target cannot be reached. Note that the Transfer Target's contact information has been exposed to the Transferee. The provided contact can be used to make new calls in the future.
基本的な転送は、譲受人への転送ターゲットの接触を提供する転送者で構成されています。譲受人は、その連絡先を使用してセッションを確立しようとし、その試みの結果を譲渡人に報告します。譲渡人と譲受人の間の信号関係は終了しないため、転送ターゲットに到達できない場合、コールは回復可能です。転送ターゲットの連絡先情報が譲受人にさらされていることに注意してください。提供された連絡先は、将来的に新しい電話をかけるために使用できます。
The participants in a basic transfer SHOULD indicate support for the REFER and NOTIFY methods in Allow header fields in INVITE, 200 OK to INVITE, and OPTIONS messages. Participants SHOULD also indicate support for Target-Dialog in the Supported header field.
基本的な転送の参加者は、招待状のヘッダーフィールドを許可する紹介および通知方法のサポートを示し、招待する200 OK、およびオプションメッセージを示している必要があります。参加者は、サポートされているヘッダーフィールドのターゲットダイアログのサポートも示す必要があります。
The diagrams below show the first line of each message. The first column of the figure shows the dialog used in that particular message. In these diagrams, media is managed through re-INVITE holds, but other mechanisms (mixing multiple media streams at the UA or using the conferencing extensions, for example) are valid. Selected message details are shown labeled as message F1, F2, etc.
以下の図は、各メッセージの最初の行を示しています。図の最初の列は、その特定のメッセージで使用されているダイアログを示しています。これらの図では、メディアはRe-Invite Holdsを通じて管理されていますが、他のメカニズム（UAで複数のメディアストリームを混合したり、拡張機能を使用したりするなど）が有効です。選択したメッセージの詳細は、メッセージF1、F2などとしてラベル付けされています。
Each of the flows below shows the dialog between the Transferor and the Transferee remaining connected (on hold) during the REFER process. While this provides the greatest flexibility for recovery from failure, it is not necessary. If the Transferor's agent does not wish to participate in the remainder of the REFER process and has no intention of assisting with recovery from transfer failure, it could emit a BYE to the Transferee as soon as the REFER transaction completes. This flow is sometimes known as "unattended transfer" or "blind transfer".
以下の各フローは、紹介プロセス中に（保留中）接続されたままになっている譲受人と譲受人の間の対話を示しています。これにより、障害からの回復のための最大の柔軟性が得られますが、必要ありません。譲渡人のエージェントが紹介プロセスの残りの部分に参加することを望まず、転送障害からの回復を支援する意図がない場合、紹介トランザクションが完了するとすぐに、譲受人へのさようならを発する可能性があります。このフローは、「無人の転送」または「ブラインドトランスファー」として知られている場合があります。
Figure 1 shows transfer when the Transferee utilizes a GRUU and supports the target-dialog extension and indicates this to the Transferor. As a result, the Transferor sends the REFER outside the INVITE dialog. The Transferee is able to match this REFER to the existing dialog using the Target-Dialog header field in the refer which references the existing dialog.
図1は、譲受人がgruuを利用し、ターゲットダイアログ拡張をサポートし、これを譲渡者に示すときの転送を示しています。その結果、転送者は招待ダイアログの外側に紹介を送信します。譲受人は、既存のダイアログを参照する紹介のターゲットダイアログヘッダーフィールドを使用して、既存のダイアログを参照することができます。
Transferor Transferee Transfer
| | Target
| INVITE F1 | |
dialog1 |<-------------------| |
| 200 OK F2 | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER F3 (Target-Dialog:1) |
dialog2 |------------------->| |
| 202 Accepted | |
dialog2 |<-------------------| |
| NOTIFY (100 Trying) F4 |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| | INVITE F5 |
dialog3 | |------------------->|
| | 200 OK |
dialog3 | |<-------------------|
| | ACK |
dialog3 | |------------------->|
| NOTIFY (200 OK) F6| |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| | BYE |
dialog3 | |<-------------------|
| | 200 OK |
dialog3 | |------------------->|
Figure 1: Basic Transfer Call Flow
F1 INVITE Transferee -> Transferor
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transferor -> Transferee
F2 200 OK転送者 - >譲受人
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
f3譲渡者を紹介 - >譲受人
REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: tdialog
Refer-To: <sips:transfertarget@chicago.example.com>
Target-Dialog: 090459243588173445;local-tag=7553452
;remote-tag=31kdl4i3k
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0
F4 NOTIFY Transferee -> Transferor
NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 73 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 100 Trying
SIP/2.0 100試行
F5 INVITE Transferee -> Transfer Target
F5譲受人を招待します - >ターゲットを転送します
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=j3kso3iqhq
Call-ID: 90422f3sd23m4g56832034
CSeq: 521 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
F6 NOTIFY Transferee -> Transferor
f6譲受人に通知 - >譲渡者
NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 74 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 200 OK
SIP/2.0 200 OK
In this scenario, the Transferor does not know the properties of the Transferee's Contact URI or does not know that the Transferee supports the Target-Dialog header field. As a result, the REFER is sent inside the INVITE dialog.
このシナリオでは、譲渡人は譲受人の接触URIの特性を知らないか、譲受人がターゲットダイアログヘッダーフィールドをサポートしていることを知らない。その結果、紹介は招待ダイアログ内に送信されます。
Transferor Transferee Transfer
| | Target
| INVITE F1 | |
dialog1 |<-------------------| |
| 200 OK F2 | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER F3 | |
dialog1 |------------------->| |
| 202 Accepted | |
dialog1 |<-------------------| |
| NOTIFY (100 Trying) F4 |
dialog1 |<-------------------| |
| 200 OK | |
dialog1 |------------------->| |
| | INVITE F5 |
dialog2 | |------------------->|
| | 200 OK |
dialog2 | |<-------------------|
| | ACK |
dialog2 | |------------------->|
| NOTIFY (200 OK) F6| |
dialog1 |<-------------------| |
| 200 OK | |
dialog1 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| | BYE |
dialog2 | |<-------------------|
| | 200 OK |
dialog2 | |------------------->|
Figure 2: Transfer with Dialog Reuse
F1 INVITE Transferee -> Transferor
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transferor -> Transferee
F2 200 OK転送者 - >譲受人
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
f3譲渡者を紹介 - >譲受人
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9
Max-Forwards: 70
To: <sips:transferee@biloxi.example.com>;tag=7553452
From: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
Call-ID: 090459243588173445
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Refer-To: <sips:transfertarget@chicago.example.com>
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0
F4 NOTIFY Transferee -> Transferor
NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29888 INVITE
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 100 Trying
SIP/2.0 100試行
F5 INVITE Transferee -> Transfer Target
F5譲受人を招待します - >ターゲットを転送します
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=j3kso3iqhq
Call-ID: 90422f3sd23m4g56832034
CSeq: 521 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Content-Type: application/sdp
Content-Length: ...
F6 NOTIFY Transferee -> Transferor
f6譲受人に通知 - >譲渡者
NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29889 INVITE
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 200 OK
SIP/2.0 200 OK
This section shows examples of failed transfer attempts. After the transfer failure occurs, the Transferor takes the Transferee off hold and resumes the session.
このセクションでは、転送の障害の例を示します。転送の故障が発生した後、譲渡人は譲受人を排除し、セッションを再開します。
Transferor Transferee Transfer
| | Target
| | |
| INVITE | |
dialog1 |<-------------------| |
| 200 OK | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER (Target-Dialog:1) |
dialog2 |------------------->| |
| 202 Accepted | |
dialog2 |<-------------------| |
| NOTIFY (100 Trying)| |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| | INVITE |
dialog3 | |------------------->|
| | 486 Busy Here |
dialog3 | |<-------------------|
| | ACK |
dialog3 | |------------------->|
| NOTIFY (486 Busy Here) |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| INVITE (unhold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
Figure 3: Failed Transfer - Target Busy
図3：転送の失敗 - ターゲットビジー
Transferor Transferee Transfer
| | Target
| INVITE | |
dialog1 |<-------------------| |
| 200 OK | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER | |
dialog2 |------------------->| |
| 202 Accepted | |
dialog2 |<-------------------| |
| NOTIFY (100 Trying)| |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| | INVITE |
dialog3 | |------------------->|
| | 180 Ringing |
dialog3 | |<-------------------|
| (Transferee gets tired of waiting)
| | CANCEL |
dialog3 | |------------------->|
| | 200 OK (CANCEL) |
dialog3 | |<-------------------|
| 487 Request Cancelled (INVITE)
dialog3 | |<-------------------|
| | ACK |
dialog3 | |------------------->|
| NOTIFY (487 Request Cancelled) |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| INVITE (unhold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
Figure 4: Failed Transfer - Target Does Not Answer
図4：転送の失敗 - ターゲットは答えません
Transfer with consultation hold involves a session between the Transferor and the Transfer Target before the transfer actually takes place. This is implemented with SIP Hold and Transfer as described above.
協議ホールドとの譲渡には、譲渡が実際に行われる前の譲渡人と転送ターゲットの間のセッションが含まれます。これは、上記のようにSIPホールドと転送で実装されます。
A nice feature is for the Transferor to let the target know that the session relates to an intended transfer. Since many UAs render the display name in the From header field to the user, a consultation INVITE could contain a string such as "Incoming consultation from Transferor with intent to transfer Transferee", where the display names of the transferor and transferee are included in the string.
素晴らしい機能は、譲渡人がセッションが意図した転送に関連していることをターゲットに知らせることです。多くのUASがHeaderフィールドのディスプレイ名をユーザーにレンダリングするため、相談の招待状には、「譲受人の譲渡を意図した転送者からの受信協議」などの文字列が含まれています。弦。
The Transferor places the Transferee on hold, establishes a call with the Transfer Target to alert them to the impending transfer, terminates the connection with the Transfer Target, then proceeds with transfer as above. This variation can be used to provide an experience similar to that expected by current PBX and Centrex users.
譲渡人は譲受人を保留にし、転送ターゲットとの呼び出しを確立して、差し迫った転送に警告し、転送ターゲットとの接続を終了し、上記のように転送を進みます。このバリエーションを使用して、現在のPBXおよびCentrexユーザーが予想しているエクスペリエンスと同様のエクスペリエンスを提供できます。
To (hopefully) improve clarity, non-REFER transactions have been collapsed into one indicator with the arrow showing the direction of the request.
（できれば）明確さを改善するには、非参照トランザクションが1つのインジケータに崩壊し、矢印がリクエストの方向を示しています。
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK | |
|---------------------------------------->|
dialog2 | BYE/200 OK | |
|---------------------------------------->|
dialog3 | REFER | |
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | | INVITE/200 OK/ACK |
| |------------------->|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Figure 5: Transfer with Consultation Hold - Exposing Transfer Target
図5：コンサルティングホールドとともに転送 - 転送ターゲットの公開
The Transferor places the Transferee on hold, establishes a call with the Transfer Target and then reverses their roles, transferring the original Transfer Target to the original Transferee. This has the advantage of hiding information about the original Transfer Target from the original Transferee. On the other hand, the Transferee's experience is different than in current systems. The Transferee is effectively "called back" by the Transfer Target.
譲渡人は譲受人を保留にし、転送ターゲットとの呼び出しを確立し、その役割を逆転させ、元の転送ターゲットを元の譲受人に転送します。これには、元の譲受人からの元の転送ターゲットに関する情報を隠すという利点があります。一方、譲受人の経験は、現在のシステムとは異なります。譲受人は、転送ターゲットによって事実上「コールバック」されます。
One of the problems with this simplest implementation of a target protecting transfer is that the Transferee is receiving a new call from the Transfer Target. Unless the Transferee's agent has a reliable way to associate this new call with the call it already has with the Transferor, it will have to alert the new call on another appearance. If this, or some other call-waiting-like UI were not available, the Transferee might be stuck returning a Busy-Here to the Transfer Target, effectively preventing the transfer. There are many ways that correlation could be provided. The dialog parameters could be provided directly as header parameters in the Refer-To URI, for example. The Replaces mechanism [RFC3891] uses this approach and solves this problem nicely.
ターゲット保護転送のこの最も単純な実装に関する問題の1つは、譲受人が転送ターゲットから新しい呼び出しを受けていることです。譲受人のエージェントが、この新しい呼び出しを既に譲渡人と既に持っているコールに関連付ける信頼できる方法を持っていない限り、別の外観で新しい呼び出しに警告する必要があります。これ、または他のコールウェイティングのようなUIが利用できなかった場合、譲受人は移籍ターゲットに忙しい状態を返し、譲渡を効果的に防止している可能性があります。相関を提供する方法はたくさんあります。ダイアログパラメーターは、たとえば、紹介URIのヘッダーパラメーターとして直接提供できます。交換メカニズム[RFC3891]はこのアプローチを使用し、この問題をうまく解決します。
For the flow below, dialog1 means dialog identifier 1, and consists of the parameters of the Replaces header for dialog 1. In [RFC3891], this is the Call-ID, To-tag, and From-tag.
以下のフローの場合、ダイアログ1はダイアログ識別子1を意味し、ダイアログ1の交換ヘッダーのパラメーターで構成されています。
Note that the Transferee's agent emits a BYE to the Transferor's agent as an immediate consequence of processing the Replaces header.
交換ヘッダーの処理の即時の結果として、譲受人のエージェントが譲渡人のエージェントにさようならを放出することに注意してください。
The Transferor knows that both the Transferee and the Transfer Target support the Replaces header from the Supported: replaces header contained in the 200 OK responses from both.
転送者は、譲受人と転送ターゲットの両方が、サポートされているヘッダーの交換ヘッダーをサポートすることを知っています。両方からの200のOK応答に含まれるヘッダーを交換します。
In this scenario, the Transferee utilizes a GRUU as a Contact URI for reasons discussed in Section 6.3.
このシナリオでは、譲受人はセクション6.3で説明されている理由でGruuを接触URIとして利用します。
Note that the conventions used in the SIP Torture Test Messages [RFC4475] document are reused, specifically the <allOneLine> tag.
SIP拷問テストメッセージ[RFC4475]ドキュメントで使用される規則は、特に<Alloneline>タグで再利用されることに注意してください。
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK F1 F2 |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK F3 F4 |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:2, |
| Refer-To:sips:Transferee?Replaces=1) F5|
|---------------------------------------->|
dialog3 | 202 Accepted | |
|<----------------------------------------|
dialog3 | NOTIFY (100 Trying)| |
|<----------------------------------------|
dialog3 | | 200 OK |
|---------------------------------------->|
dialog4 | INVITE (Replaces:dialog1)/200 OK/ACK F6
| |<-------------------|
dialog1 | BYE/200 OK | |
|<-------------------| |
dialog3 | NOTIFY (200 OK) | |
|<----------------------------------------|
dialog3 | | 200 OK |
|---------------------------------------->|
dialog2 | BYE/200 OK | |
|---------------------------------------->|
| (Transferee and target converse)
dialog4 | | BYE/200 OK |
| |------------------->|
Figure 6: Transfer Protecting Transfer Target
F1 INVITE Transferee -> Transferor
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transferor -> Transferee
F2 200 OK転送者 - >譲受人
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31431
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...
F3 INVITE Transferor -> Transfer Target
F3招待転送者 - >ターゲットを転送します
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: replaces
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=384i32lw3>
Content-Type: application/sdp
Content-Length: ...
F4 200 OK Transfer Target -> Transferor
F4 200 OK転送ターゲット - >転送者
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
;received=192.0.2.1
To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
Content-Type: application/sdp
Content-Length: ...
F5 REFER Transferor -> Transfer Target
f5紹介転送者 - >転送ターゲット
REFER sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: tdialog
<allOneLine>
Refer-To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha
?Replaces=090459243588173445%3Bto-tag%3D7553452%3Bfrom-tag%3D31431>
</allOneLine>
Target-Dialog: 592435881734450904;local-tag=9m2n3wq
;remote-tag=763231
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0
F6 INVITE Transfer Target -> Transferee
INVITE sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS client.chicago.example.com;branch=z9hG4bKnaslu84
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transfertarget@chicago.example.com>;tag=341234
Call-ID: kmzwdle3dl3d08
CSeq: 41 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Contact: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
Replaces: 090459243588173445;to-tag=7553452;from-tag=31431
Content-Type: application/sdp
Content-Length: ...
The Transferor places the Transferee on hold, establishes a call with the Transfer Target to alert them to the impending transfer, places the target on hold, then proceeds with transfer using an escaped Replaces header field in the Refer-To header. This is another common service expected by current PBX and Centrex users.
譲渡人は譲受人を保留にし、転送ターゲットとのコールを確立して差し迫った転送に警告し、ターゲットを保留にしてから、紹介ヘッダーのエスケープ交換ヘッダーフィールドを使用して転送を進めます。これは、現在のPBXおよびCentrexユーザーが期待するもう1つの一般的なサービスです。
The Contact URI of the Transfer Target SHOULD be used by the Transferor as the Refer-To URI, unless the URI is suspected or known to not be routable outside the dialog. Otherwise, the Address of Record (AOR) of the Transfer Target SHOULD be used. That is, the same URI that the Transferor used to establish the session with the Transfer Target should be used. In case the triggered INVITE is routed to a different User Agent than the Transfer Target, the Require: replaces header field SHOULD be used in the triggered INVITE. (This is to prevent an incorrect User Agent that does not support Replaces from ignoring the Replaces and answering the INVITE without a dialog match.)
転送ターゲットの接触URIは、URIがダイアログの外側でルーティングできないと疑われるか、知られていると知られている場合を除き、紹介者として紹介者として使用する必要があります。それ以外の場合、転送ターゲットの記録（AOR）のアドレスを使用する必要があります。つまり、転送者が転送ターゲットでセッションを確立するために使用したのと同じURIを使用する必要があります。トリガーされた招待が転送ターゲットとは異なるユーザーエージェントにルーティングされた場合、必要なのは次のとおりです。（これは、交換が交換を無視してダイアログマッチなしで招待に答えることをサポートしない誤ったユーザーエージェントを防ぐためです。）
It is possible that proxy/service routing may prevent the triggered INVITE from reaching the same User Agent. If this occurs, the triggered invite will fail with a timeout, 403, 404, etc. error. The Transferee MAY then retry the transfer with the Refer-To URI set to the Contact URI.
プロキシ/サービスルーティングにより、トリガーされた招待が同じユーザーエージェントに到達するのを防ぐ可能性があります。これが発生した場合、トリガーされた招待は、タイムアウト、403、404などで失敗します。エラー。譲受人は、紹介URIセットを連絡先URIに紹介することで転送を再試行することができます。
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK F1 F2 |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK F3 F4 |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:1, |
| Refer-To:sips:TransferTarget?Replaces=2) F5
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6
| |------------------->|
dialog2 | BYE/200 OK | |
|<----------------------------------------|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Figure 7: Attended Transfer Call Flow
F1 INVITE Transferee -> Transferor
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transferor -> Transferee
F2 200 OK転送者 - >譲受人
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31431
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...
F3 INVITE Transferor -> Transfer Target
F3招待転送者 - >ターゲットを転送します
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: replaces
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=384i32lw3>
Content-Type: application/sdp
Content-Length: ...
F4 200 OK Transfer Target -> Transferor
F4 200 OK転送ターゲット - >転送者
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
;received=192.0.2.1
To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Contact: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
Content-Type: application/sdp
Content-Length: ...
F5 REFER Transferor -> Transferee
f5譲渡人 - >譲受人を紹介します
REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Require: tdialog
<allOneLine>
Refer-To: <sips:482n4z24kdg@chicago.example.com;gr=8594958?
Replaces=592435881734450904%3Bto-tag%3D9m2n3wq%3Bfrom-tag3D763231>
</allOneLine>
Target-Dialog: 592435881734450904;local-tag=9m2n3wq
;remote-tag=763231
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0
F6 INVITE Transferee -> Transfer Target
INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82
Max-Forwards: 70
To: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
From: <sips:transferee@biloxi.example.com>;tag=954
Call-ID: kmzwdle3dl3d08
CSeq: 41 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Replaces: 592435881734450904;to-tag=9m2n3wq;from-tag=763231
Content-Type: application/sdp
Content-Length: ...
If protecting or exposing the Transfer Target is not a concern, it is possible to complete a transfer with consultation hold when only the transferor and one other party support REFER. Note that a 405 Method Not Allowed might be returned instead of the 501 Not Implemented response.
転送ターゲットを保護または暴露することは懸念事項ではない場合、譲渡人と他の1人のサポートのみが参照した場合、協議ホールドで転送を完了することができます。許可されていない405メソッドが、実装されていない応答の代わりに返される場合があることに注意してください。
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK | |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:1, |
| Refer-To:sips:TransferTarget?Replaces=2)
|------------------->| |
dialog3 | 501 Not Implemented |
|<-------------------| |
dialog4 | REFER (Refer-To:sips:Transferee?Replaces=dialog1)
|---------------------------------------->|
dialog4 | 202 Accepted | |
|<----------------------------------------|
dialog4 | NOTIFY (100 Trying)| |
|<----------------------------------------|
dialog4 | | 200 OK |
|---------------------------------------->|
dialog5 | INVITE (Replaces:dialog1)/200 OK/ACK
| |<-------------------|
dialog4 | NOTIFY (200 OK) | |
|<----------------------------------------|
dialog4 | | 200 OK |
|---------------------------------------->|
dialog1 | BYE/200 OK | |
|<-------------------| |
dialog2 | BYE/200 OK | |
|---------------------------------------->|
dialog5 | | BYE/200 OK |
| |------------------->|
Figure 8: Recovery When One Party Does Not Support REFER
図8：一方の当事者が参照をサポートしていない場合の回復
It is a requirement of RFC 3261 that a Contact URI be globally routable even outside the dialog. However, due to RFC 2543 User Agents and some architectures (NAT/Firewall traversal, screening proxies, Application Layer Gateways (ALGs), etc.) this will not always be the case. As a result, the method of attended transfer shown in Figures 6, 7, and 8 SHOULD only be used if the Contact URI is known to be routable outside the dialog.
RFC 3261の要件は、ダイアログの外側でも接触URIがグローバルにルーティング可能であることを要求しています。ただし、RFC 2543ユーザーエージェントといくつかのアーキテクチャ（NAT/ファイアウォールトラバーサル、スクリーニングプロキシ、アプリケーションレイヤーゲートウェイ（ALG）など）により、これは必ずしもそうではありません。その結果、図6、7、および8に示されている出席した転送の方法は、接触URIがダイアログの外側でルーティング可能であることが知られている場合にのみ使用する必要があります。
Figure 9 shows such a scenario where the Transfer Target Contact URI is not routable outside the dialog, so the triggered INVITE is sent to the AOR of the Transfer Target.
図9は、転送ターゲットの接触URIがダイアログの外側でルーティングできないようなシナリオを示しているため、トリガーされた招待が転送ターゲットのAORに送信されます。
Transferor Transferee Screening Transfer
| | Proxy Target
| | | |
dialog1 | INVITE/200 OK/ACK| | |
|<-----------------| | |
dialog1 | INVITE (hold)/200 OK/ACK | |
|----------------->| | |
dialog2 | INVITE/200 OK/ACK F1 F2 | |
|--------------------------------|------------>|
dialog2 | INVITE (hold)/200 OK/ACK |
|--------------------------------|------------>|
dialog1 | REFER (Refer-To:sips:TargetAOR |
| ?Replaces=dialog2&Require=replaces) F3
|----------------->| | |
dialog1 | 202 Accepted | | |
|<-----------------| | |
dialog1 | NOTIFY (100 Trying) | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog4 |INVITE (Replaces:dialog2,Require:replaces)/200 OK/ACK F6
| |------------>|------------>|
dialog2 | BYE/200 OK | | |
|<-------------------------------|<------------|
dialog1 | NOTIFY (200 OK) F7 | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog1 | BYE/200 OK | | |
|----------------->| | |
dialog3 | | | BYE/200 OK |
| |<------------|-------------|
Figure 9: Attended Transfer Call Flow with a Contact URI Not Known to Be Globally Routable F1 INVITE Transferor -> Transfer Target
図9：グローバルにルーティング可能であることが知られていない連絡先URIを使用した転送コールフローに参加しましたF1招待転送者 - >転送ターゲット
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferor@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transfer Target -> Transferee
F2 200 OK転送ターゲット - >譲受人
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
;received=192.0.2.1
To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transfertarget@client.chicago.example.com>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
f3譲渡者を紹介 - >譲受人
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:transferee@biloxi.example.com>;tag=a6c85cf
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
<allOneLine>
Refer-To: <sips:transfertarget@chicago.example.com?Replaces=
090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231
&Require=replaces>
<allOneLine>
Contact: <sips:transferor@pc33.atlanta.example.com>
Content-Length: 0
F4 INVITE Transferee -> Transfer Target
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=954
Call-ID: 20482817324945934422930
CSeq: 42 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231
Require: replaces
Content-Type: application/sdp
Content-Length: ...
F5 NOTIFY Transferee -> Transferor
F5譲受人に通知 - >譲渡人
NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:transferee@biloxi.example.com>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 76 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer;id=98873867
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 200 OK
SIP/2.0 200 OK
Figure 10 shows a failure case in which the AOR URI fails to reach the Transfer Target. As a result, the transfer is retried with the Contact URI, at which point it succeeds.
図10は、AOR URIが転送ターゲットに到達できない障害ケースを示しています。その結果、転送は接触URIで再試行され、その時点で成功します。
Note that there is still no guarantee that the correct endpoint will be reached, and the result of this second REFER may also be a failure. In that case, the Transferor could fall back to unattended transfer or give up on the transfer entirely. Since two REFERs are sent within the dialog creating two distinct subscriptions, the Transferee uses the 'id' parameter in the Event header field to distinguish notifications for the two subscriptions.
正しいエンドポイントに到達するという保証はまだないことに注意してください。また、この2番目の紹介の結果も障害である可能性があります。その場合、譲渡人は無人の転送に戻ったり、転送をgiveめたりする可能性があります。2つの参照がダイアログ内で2つの異なるサブスクリプションを作成するため、Transfereeはイベントヘッダーフィールドの「ID」パラメーターを使用して、2つのサブスクリプションの通知を区別します。
Transferor Transferee Screening Transfer
| | Proxy Target
| | | |
dialog1 | INVITE/200 OK/ACK| | |
|<-----------------| | |
dialog1 | INVITE (hold)/200 OK/ACK | |
|----------------->| | |
dialog2 | INVITE/200 OK/ACK F1 F2 | |
|--------------------------------|------------>|
dialog2 | INVITE (hold)/200 OK/ACK |
|--------------------------------|------------>|
dialog1 | REFER (Refer-To:sips:TargetAOR? |
| Replaces=dialog2&Require=replaces) F3 |
|----------------->| | |
dialog1 | 202 Accepted | | |
|<-----------------| | |
dialog1 | NOTIFY (100 Trying) | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog3 | |INVITE (Replaces:dialog2, |
| | Require:replaces)/403/ACK |
| |------------>| |
dialog1 | NOTIFY (403 Forbidden) F4 | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog1 |REFER(Refer-To:sips:TargetContact?Replaces=dialog2) F5
|----------------->| | |
dialog1 | 202 Accepted | | |
|<-----------------| | |
dialog1 | NOTIFY (100 Trying) | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6
| |------------>|------------>|
dialog2 | BYE/200 OK | | |
|<-------------------------------|<------------|
dialog1 | NOTIFY (200 OK) F7 | |
|<-----------------| | |
dialog1 | 200 OK | | |
|----------------->| | |
dialog1 | BYE/200 OK | | |
|----------------->| | |
dialog3 | | | BYE/200 OK |
| |<------------|-------------|
Figure 10: Attended Transfer Call Flow with Non-Routable Contact URI and AOR Failure
図10：不可能な連絡先URIおよびAOR障害を伴う転送コールフローに出席しました
F1 INVITE Transferor -> Transfer Target
F1招待転送者 - >ターゲットを転送します
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK76
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferor@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: ...
F2 200 OK Transfer Target -> Transferee
F2 200 OK転送ターゲット - >譲受人
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnas432
;received=192.0.2.1
To: <sips:transfertarget@chicago.example.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.example.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transfertarget@client.chicago.example.com>
Content-Type: application/sdp
Content-Length: ...
F3 REFER Transferor -> Transferee
f3譲渡者を紹介 - >譲受人
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:transferee@biloxi.example.com>;tag=a6c85cf
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
<allOneLine>
Refer-To: <sips:transfertarget@chicago.example.com?Replaces=
090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231
&Require=replaces>
</allOneLine>
Contact: <sips:transferor@pc33.atlanta.example.com>
Content-Length: 0
F4 NOTIFY Transferee -> Transferor
f4譲受人に通知 - >譲渡者
NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:transferee@biloxi.example.com>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 74 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer;id=314159
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 403 Forbidden F5 REFER Transferor -> Transferee
SIP/2.0 403 FORBIDDEN F5紹介譲渡 - >譲受人
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:transferee@biloxi.example.com>;tag=a6c85cf
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
<allOneLine>
Refer-To: <sips:transfertarget@client.chicago.example.com
?Replaces=090459243588173445%3Bto-tag%3D9m2n3wq
%3Bfrom-tag%3D763231>
</allOneLine>
Contact: <sips:transferor@pc33.atlanta.example.com>
Content-Length: 0
F6 INVITE Transferee -> Transfer Target
F6譲受人を招待します - >ターゲットを転送します
INVITE sips:transfertarget@client.chicago.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=954
Call-ID: 20482817324945934422930
CSeq: 42 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231
Content-Type: application/sdp
Content-Length: ...
F7 NOTIFY Transferee -> Transferor
f7譲受人に通知 - >譲渡人
NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:transferee@biloxi.example.com>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 76 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer;id=314160
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 200 OK
SIP/2.0 200 OK
To prevent this scenario from happening, the Transfer Target SHOULD use a Contact URI that is routable outside the dialog, which will result in the call flow of Figure 7.
このシナリオが発生するのを防ぐために、転送ターゲットはダイアログの外側でルーティング可能な連絡先URIを使用する必要があります。これにより、図7の呼び出し流が行われます。
In any of the consultation hold flows above, the Transferor may decide to terminate its attempt to contact the Transfer Target before that session is established. Most frequently, that will be the end of the scenario, but in some circumstances, the Transferor may wish to proceed with the transfer action. For example, the Transferor may wish to complete the transfer knowing that the Transferee will end up eventually talking to the Transfer Target's voicemail service. Some PBX systems support this feature, sometimes called "semi-attended transfer", that is effectively a hybrid between a fully attended transfer and an unattended transfer. A call flow is shown in Figure 11. In this flow, the Transferor's User Agent continues the transfer as an attended transfer even after the Transferor hangs up. Note that media must be played to the Transfer Target upon answer -- otherwise, the Target may hang up and the resulting transfer operation will fail.
上記の協議ホールドフローのいずれかで、譲渡人は、そのセッションが確立される前に転送目標に接触する試みを終了することを決定する場合があります。最も頻繁に、それがシナリオの終わりになりますが、状況によっては、譲渡人は転送措置を進めたいと思うかもしれません。たとえば、譲渡人は、譲受人が最終的に転送ターゲットのボイスメールサービスと話すことになることを知って転送を完了したい場合があります。一部のPBXシステムは、「セミアテンダム転送」と呼ばれるこの機能をサポートしています。これは、完全に参加した転送と無人の転送の間のハイブリッドです。コールフローを図11に示します。このフローでは、転送者のユーザーエージェントは、転送者が切れた後も参加した転送として転送を継続します。回答時にメディアを転送ターゲットに再生する必要があることに注意してください。そうしないと、ターゲットが切れる可能性があり、結果の転送操作が失敗する可能性があります。
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK F1 F2 |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE | |
|---------------------------------------->|
dialog2 | | 180 Ringing |
|<----------------------------------------|
Transferor hangs up but wants transfer to continue
| | |
| User Agent continues transfer operation |
| | |
dialog2 | | 200 OK |
|<----------------------------------------|
dialog2 | ACK | |
|---------------------------------------->|
dialog2 | Media Played to keep Target from hanging up
|========================================>|
dialog3 | REFER (Target-Dialog:1, |
| Refer-To:sips:TransferTarget?Replaces=2)
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK
| |------------------->|
dialog2 | BYE/200 OK | |
|<----------------------------------------|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Figure 11: Recommended Semi-Attended Transfer Call Flow
図11：推奨されるセミアテンダム転送コールフロー
Two other possible semi-attended transfer call flows are shown in Figures 12 and 13. However, these call flows are NOT RECOMMENDED due to race conditions. In both of these flows, when the Transferor hangs up, the Transferor attempts to revert to unattended transfer by sending a CANCEL to the target. This can result in two race conditions. One is that the target answers despite the CANCEL and the resulting unattended transfer fails. This race condition can be eliminated by the Transferor waiting to send the REFER until the 487 response from the target is returned. Instead of a 487, a 200 OK may be returned indicating that the target has answered the consultation call. In this case, the call flow in Figure 13 must be followed. In this flow, the Transferor must play some kind of media to the Target to prevent the Target from hanging up, or the transfer will fail. That is, the human at the Transfer Target will hear silence from when they answer (message F1) until the transfer completes (F3 and they are talking to the Transferee unless some media is played (F2)).
他の2つの可能なセミアテンダム転送コールフローを図12および13に示します。ただし、これらのコールフローは、人種条件のために推奨されません。これらの両方のフローにおいて、譲渡人が切れると、譲渡人はキャンセルをターゲットに送信することにより、無人の転送に戻ろうとします。これにより、2つのレース条件が生じる可能性があります。1つは、キャンセルにもかかわらず、ターゲットが回答し、結果として生じる無人の転送が失敗することです。このレースの状態は、ターゲットからの487の応答が返されるまで、紹介を送信するのを待っている譲渡人によって排除できます。487の代わりに、ターゲットが相談コールに応答したことを示す200 OKが返される場合があります。この場合、図13のコールフローに従う必要があります。このフローでは、譲渡人はターゲットが切れるのを防ぐために、何らかの種類のメディアをターゲットにプレイする必要があります。そうしないと、転送が失敗します。つまり、転送ターゲットの人間は、転送が完了するまで（メッセージF1）と回答すると沈黙を聞きます（F3と、一部のメディアが再生されない限り、譲受人と話しています（F2））。
The second race condition occurs in Figure 12 if the Transfer Target goes "off hook" after the CANCEL is received and the 487 returned. This may result in a 486 Busy Here response to the unattended transfer.
2番目のレース条件は、キャンセルを受け取り、487が返された後に転送ターゲットが「フックから外れた」場合に図12に発生します。これにより、ここで486の忙しいここで、無人の転送に対する応答が生じる可能性があります。
The recommended call flow of Figure 11 does not utilize a CANCEL and does not suffer from these race conditions.
図11の推奨コールフローは、キャンセルを利用せず、これらのレース条件に悩まされません。
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE |
|---------------------------------------->|
dialog2 | 180 Ringing |
|<----------------------------------------|
| |
| Transferor gives up waiting |
| |
dialog2 | CANCEL |
|---------------------------------------->|
dialog2 | 200 OK |
|<----------------------------------------|
dialog2 | 487 Request Terminated |
|<----------------------------------------|
dialog2 | ACK |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:1) F3 |
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | INVITE/200 OK/ACK |
| |------------------->|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Figure 12: Semi-Attended Transfer as Blind Transfer Call Flow (Not Recommended)
図12：ブラインドトランスファーコールフローとしてのセミアテンデッド転送（推奨されません）
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE |
|---------------------------------------->|
dialog2 | 180 Ringing |
|<----------------------------------------|
| |
|Transferor gives up waiting but Target answers
| |
dialog2 | CANCEL |
|---------------------------------------->|
dialog2 | 200 OK (CANCEL) |
|<----------------------------------------|
dialog2 | 200 OK (INVITE) F1 |
|<----------------------------------------|
dialog2 | ACK |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
| Tones or media played avoid silence F2 |
|========================================>|
dialog1 |REFER (Refer-To:sips:TransferTarget |
| ?Replaces=dialog2) |
|------------------->| |
dialog1 | 202 Accepted | |
|<-------------------| |
dialog1 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog1 | 200 OK | |
|------------------->| |
dialog3 | INVITE (Replaces:dialog2)/200 OK/ACK F3
| |------------------->|
dialog2 | BYE/200 OK | |
|<----------------------------------------|
dialog1 | NOTIFY (200 OK) | |
|<-------------------| |
dialog1 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog3 | | BYE/200 OK |
| |<-------------------|
Figure 13: Semi-Attended Transfer as Attended Transfer Call Flow (Not Recommended)
図13：出席した転送コールフローとしてのセミアテンデッド転送（推奨されません）
In this flow, an attempted attended transfer fails so the Transferor falls back to basic transfer.
このフローでは、出席した転送未遂が失敗するため、譲渡人は基本的な転送に戻ります。
The call flow in Figure 14 shows the use of Require: replaces in the INVITE sent by the Transferor to the Transfer Target in which the Transferor's intention at the time of sending the INVITE to the Transfer Target was known to be to complete an attended transfer. Since the Target does not support Replaces, the INVITE is rejected with a 420 Bad Extension response, and the Transferor switches from attended transfer to basic transfer immediately.
図14のコールフローは、要件の使用を示しています。転送ターゲットへの転送者の意図が転送ターゲットに送信されたときの招待者から送信された招待状の交換は、招待者を転送ターゲットに送信した時点で、参加者の転送を完了するためであることが知られていました。ターゲットは交代をサポートしていないため、招待状は420の悪い拡張応答で拒否され、転送者は参加から基本転送に直ちに基本転送に切り替わります。
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | OPTIONS/200 OK | |
|------------------->| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE (Require:replaces) |
|---------------------------------------->|
dialog2 | 420 Bad Extension |
|<----------------------------------------|
dialog2 | ACK |
|---------------------------------------->|
dialog1 | REFER (Refer-To:sips:TransferTarget) |
|------------------->| |
dialog1 | 202 Accepted | |
|<-------------------| |
dialog1 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog1 | 200 OK | |
|------------------->| |
dialog3 | | INVITE/200 OK/ACK |
| |------------------->|
dialog1 | NOTIFY (200 OK) | |
|<-------------------| |
dialog1 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog3 | | BYE/200 OK |
| |<-------------------|
Figure 14: Attended Transfer Fallback to Basic Transfer Using Require:replaces
図14：require：交換を使用した基本転送への転送転送フォールバック
Figure 15 shows the use of OPTIONS when the Transferee and Transfer Target do not explicitly indicate support for the REFER method and Replaces header fields in Allow and Supported header fields and the Transferor did not have the intention of performing an attended transfer when the INVITE to the Target was sent. In dialog1, the Transferor determines, using OPTIONS, that the Transferee does support REFER and Replaces. As a result, the Transferor begins the attended transfer by placing the Transferee on hold and calling the Transfer Target. Using an OPTIONS in dialog2, the Transferor determines that the target does not support either REFER or Replaces, making attended transfer impossible. The Transferor then ends dialog2 by sending a BYE then sends a REFER to the Transferee using the AOR URI of the Transfer Target.
図15は、譲受人と転送ターゲットが紹介方法のサポートを明示的に示しておらず、許可およびサポートされたヘッダーフィールドでヘッダーフィールドを置き換える場合のオプションの使用を示しており、譲渡人は、招待が招待されたときに出席した転送を実行する意図がありませんでした。ターゲットが送信されました。Dialog1では、譲渡人はオプションを使用して、譲受人が紹介と交換をサポートしていることを決定します。その結果、譲渡人は、譲受人を保留にして転送ターゲットを呼び出すことにより、出席した転送を開始します。Dialog2のオプションを使用して、転送者は、ターゲットが参照または交換のいずれをサポートしていないと判断し、参加者の転送を不可能にします。その後、転送者は、さようならを送信してDialog2を終了し、転送ターゲットのAOR URIを使用して譲受人に紹介を送信します。
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK | |
|<-------------------| |
dialog1 | OPTIONS/200 OK | |
|------------------->| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK | |
|---------------------------------------->|
dialog2 | OPTIONS/200 OK | |
|---------------------------------------->|
dialog2 | BYE/200 OK | |
|---------------------------------------->|
dialog3 |REFER (Target-Dialog:1, |
| Refer-To:sips:TransferTarget) |
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | | INVITE/200 OK/ACK |
| |------------------->|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Figure 15: Attended Transfer Fallback to Basic Transfer
図15：基本転送への転送の転送に参加しました
In the previous examples, the Transfer Target does not have definitive information about what party initiated the transfer, or, in some cases, even that transfer is taking place. The Referred-By mechanism [RFC3892] provides a way for the Transferor to provide the Transferee with a way to let the Transfer Target know what party initiated the transfer.
以前の例では、転送ターゲットには、どの当事者が転送を開始したか、または場合によってはその転送も行われていることについての決定的な情報がありません。紹介されたメカニズム[RFC3892]は、譲渡人が譲受人に転送ターゲットに譲渡を開始したかをターゲットに知らせる方法を提供する方法を提供します。
The simplest and least secure approach just involves the inclusion of the Referred-By header field in the REFER, which is then copied into the triggered INVITE. However, a more secure mechanism involving the Referred-By security token, which is generated and signed by the Transferor and passed in a message body to the Transferee then to the Transfer Target.
最もシンプルで最も安全なアプローチには、参照に紹介されたヘッダーフィールドを含めることが含まれます。これは、トリガーされた招待状にコピーされます。ただし、紹介されたセキュリティトークンを含むより安全なメカニズムは、譲渡人によって生成および署名され、メッセージ本体に渡されて譲受人に渡され、その後転送ターゲットに渡されます。
The call flow in Figure 16 shows the Referred-By header field and body in the REFER F5 and triggered INVITE F6. Note that the Secure/ Multipurpose Internet Mail Extensions (S/MIME) signature is not shown in the example below. The conventions used in the SIP Torture Test Messages [RFC4475] document are reused, specifically the <hex> and <allOneLine> tags.
図16のコールフローは、参照F5の参照ヘッダーフィールドとボディを示し、招待された招待F6をトリガーしています。Secure/ Multipurposeインターネットメール拡張機能（S/ MIME）の署名は、以下の例には示されていないことに注意してください。SIP拷問テストメッセージ[RFC4475]ドキュメントで使用される規則は、特に<hex>および<AlloneLine>タグで再利用されます。
Transferor Transferee Transfer
| | Target
| | |
dialog1 | INVITE/200 OK/ACK F1 F2 |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK F3 F4 |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:1, Referred-By:Transferor,
| Refer-To:sips:TransferTarget?Replaces=2) F5
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | INVITE (Replaces:dialog2, |
| Referred-By:Transferor )/200 OK/ACK F6
| |------------------->|
dialog2 | BYE/200 OK | |
|<----------------------------------------|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|
Figure 16: Attended Transfer Call Flow with Referred-By
F5 REFER Transferor -> Transferee
REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK392039842
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
<allOneLine>
Refer-To: <sips:482n4z24kdg@chicago.example.com;gr=8594958
?Replaces=090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag
%3D763231&Require=replaces>
</allOneLine>
Supported: gruu, replaces, tdialog
Require: tdialog
Referred-By: <sips:transferor@atlanta.example.com>
;cid="20398823.2UWQFN309shb3@atlanta.example.com"
Target-Dialog: 592435881734450904;local-tag=9m2n3wq;remote-tag=763231
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: ...
--unique-boundary-1
Content-ID: <20398823.2UWQFN309shb3@atlanta.example.com>
Content-Length: 2961
Content-Type: multipart/signed;
protocol="application/pkcs-7-signature";
micalg=sha1;
boundary="----590F24D439B31E08745DEF0CD9397189"
------590F24D439B31E08745DEF0CD9397189
Content-Type: message/sipfrag
Date: Thu, 18 Sep 2003 13:07:43 GMT
<allOneLine>
Refer-To: <sips:482n4z24kdg@chicago.example.com;gr=8594958
?Replaces=090459243588173445%3B
to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
</allOneLine>
Referred-By: <sips:transferor@atlanta.example.com>
;cid="20398823.2UWQFN309shb3@atlanta.example.com"
------590F24D439B31E08745DEF0CD9397189
Content-Type: application/pkcs-7-signature; name="smime.p7s"
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="smime.p7s"
<hex>3082088806092A86
4886F70D010702A082087930820875020101310B300906052B0E03021A050030
. . . (Signature not shown)
。。。（署名が表示されていません）
8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 79089AAD95767F</hex>
8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B4283888966 79089AAD95767F </hex>
------590F24D439B31E08745DEF0CD9397189--
--unique_boundary-1
-unique_boundary-1
F6 INVITE Transferee -> Transfer Target
F6譲受人を招待します - >ターゲットを転送します
INVITE sips:482n4z24kdg@chicago.example.com;gr=8594958 SIP/2.0
Via: SIP/2.0/TLS referee.example;branch=z9hG4bKffe209934aac
To: <sips:482n4z24kdg@chicago.example.com;gr=8594958>
From: <sips:transferee@biloxi.example.com>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Max-Forwards: 70
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Referred-By: <sips:transferor@atlanta.example.com>
;cid="20398823.2UWQFN309shb3@atlanta.example.com"
Replaces:090459243588173445;to-tag=9m2n3wq;from-
tag=76323
Require: replaces
Supported: gruu, replaces, tdialog
Content-Type: multipart/mixed; boundary=my-boundary-9
Content-Length: ...
--my-boundary-9
Content-Type: application/sdp
Content-Length: 156
コンテンツレングス：156
v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 O =審判2890844526 2890844526 IN IP4 referee.example s = session sdp c = in ip4 referee.example t = 0 0 m = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000
--my-boundary-9
Content-Length: 2961
Content-Type: multipart/signed;
protocol="application/pkcs-7-signature";
micalg=sha1;
boundary="----590F24D439B31E08745DEF0CD9397189"
------590F24D439B31E08745DEF0CD9397189
Content-Type: message/sipfrag
Date: Thu, 18 Sep 2003 13:07:43 GMT
<allOneLine>
Refer-To: <sips:transfertarget@chicago.example.com;
Replaces=090459243588173445%3B
to-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
</allOneLine>
Referred-By: <sips:transferor@atlanta.example.com>
;cid="20398823.2UWQFN309shb3@atlanta.example.com"
------590F24D439B31E08745DEF0CD9397189
Content-Type: application/pkcs-7-signature; name="smime.p7s"
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="smime.p7s"
<hex>3082088806092A86
4886F70D010702A082087930820875020101310B300906052B0E03021A050030
. . . (Signature not shown)
。。。（署名が表示されていません）
8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 79089AAD95767F</hex>
8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B4283888966 79089AAD95767F </hex>
------590F24D439B31E08745DEF0CD9397189--
--my-boundary-9--
- 私のバウンドリー-9----
In this flow, shown in Figure 17, Bob does an attended transfer of Alice to Carol. In order to keep both Alice and Carol fully informed of the nature and state of the transfer operation, Bob acts as a focus [RFC4579] and hosts an ad hoc conference involving Alice, Bob, and Carol. Alice and Carol subscribe to the conference package [RFC4575] of Bob's focus, which allows them to know the exact status of the operation. After the transfer operation is complete, Bob deletes the conference.
この流れでは、図17に示すように、ボブはアリスからキャロルへの移籍に出席しました。アリスとキャロルの両方を転送作戦の性質と状態について完全に知らせるために、ボブはフォーカス[RFC4579]として行動し、アリス、ボブ、キャロルを含むアドホック会議を開催します。アリスとキャロルは、ボブの焦点のカンファレンスパッケージ[RFC4575]を購読しています。これにより、操作の正確なステータスを知ることができます。転送操作が完了した後、ボブは会議を削除します。
This call flow meets requirement 6 of Section 4. NOTIFY messages related to the refer package are indicated as NOTIFY (refer), while NOTIFYs related to the Conference Info package are indicated as NOTIFY (Conf-Info).
このコールフローは、セクション4の要件6を満たしています。参照パッケージに関連するメッセージは、通知（参照）として示され、会議情報パッケージに関連する通知はNotify（conf-info）として示されます。
Note that any type of semi-attended transfer in which media mixing or relaying could be implemented using this model. In addition to simply mixing, the focus could introduce additional media signals such as simulated ring tone or on hold announcements to improve the user experience.
このモデルを使用して、メディアの混合または中継を実装できるあらゆるタイプのセミアテンダム転送に注意してください。単に混合することに加えて、フォーカスは、シミュレートされたリングトーンや、ユーザーエクスペリエンスを向上させるためのホールドアナウンスなどの追加のメディア信号を導入できます。
Alice Bob Carol
| | |
| INVITE | |
|------------------->| |
| 180 Ringing | |
|<-------------------| |
| 200 OK | |
|<-------------------| |
| ACK | |
|------------------->| |
| RTP | |
|<==================>| |
| | |
Bob places Alice on hold and begins acting like a focus
| | |
| INVITE (hold) Contact:Conf-ID;isfocus |
|<-------------------| |
| 200 OK | |
|------------------->| |
| ACK | |
|<-------------------| |
| | |
| Alice subscribes to the conference package
| | |
| SUBSCRIBE sip:Conf-ID |
|------------------->| |
| 200 OK | |
|<-------------------| |
| NOTIFY (Conf-Info) | |
|<-------------------| |
| 200 OK | |
|------------------->| |
| | |
| Bob begins consultation operation |
| | |
|INVITE Require:replaces Contact:Conf-ID;isfocus
| |------------------->|
| | 180 Ringing |
| |<-------------------|
| | 200 OK |
| |<-------------------|
| | ACK |
| |------------------->|
| | RTP |
| |<==================>|
| | |
|Carol subscribes to the conference package
| - learns Bob is on hold |
| | |
| |SUBSCRIBE sip:Conf-ID
| |<-------------------|
| | 200 OK |
| |------------------->|
| | NOTIFY (Conf-Info) |
| |------------------->|
| | 200 OK |
| |<-------------------|
| | |
| Alice learns that Bob is talking to Carol
| | |
| NOTIFY (Conf-Info) | |
|<-------------------| |
| 200 OK | |
|------------------->| |
| | INVITE (hold) |
| |------------------->|
| | 200 OK |
| |<-------------------|
| | ACK |
| |------------------->|
| | |
| Alice learns that Carol is now on hold |
| | |
| NOTIFY (Conf-Info) | |
|<-------------------| |
| 200 OK | |
|------------------->| |
| | |
| Bob begins transfer operation |
| | |
| REFER Refer-To: Carol |
|<-------------------| |
| 202 Accepted | |
|------------------->| |
| NOTIFY (Refer) | |
|------------------->| |
| 200 OK | |
|<-------------------| |
| INVITE Replaces:B-C Contact:Alice |
|---------------------------------------->|
| 200 OK |
|<----------------------------------------|
| ACK |
|---------------------------------------->|
| RTP |
|<=======================================>|
| | BYE |
| |<-------------------|
| | 200 OK |
| |------------------->|
| NOTIFY (Refer) | |
|------------------->| |
| 200 OK | |
|<-------------------| |
| | |
| Bob terminates the ad-hoc conference |
| | |
| BYE | |
|<-------------------| |
| 200 OK | |
|------------------->| |
| | NOTIFY (Conf-Info) |
| |------------------->|
| | 200 OK |
| |<-------------------|
| NOTIFY (Conf-Info) | |
|<-------------------| |
| 200 OK | |
|------------------->| |
Figure 17: Attended Transfer as an Ad Hoc Conference
図17：アドホックカンファレンスとしての移籍に参加しました
In this example, shown in Figure 18, the Originator places a call to the Facilitator who reaches the Recipient through the Screener. The Recipient's contact information is exposed to the Facilitator and the Originator. This example is provided for clarification of the semantics of the REFER method only, and it should not be used as the design of an implementation.
この例では、図18に示すように、オリジネーターは、スクリーナーを介して受信者に到達するファシリテーターに呼び出しを行います。受信者の連絡先情報は、ファシリテーターとオリジネーターにさらされます。この例は、紹介方法のセマンティクスのみを明確にするために提供されており、実装の設計として使用しないでください。
Originator Facilitator Screener Recipient
| | | |
1 |INVITE/200 OK/ACK | |"Get Fred for me!"
|----------->| | | "Right away!"
2 |INVITE (hold)/200 OK/ACK | |
|<-----------| | |
2 | |INVITE/200 OK/ACK |"I have a call
| |----------->| |from Mary for Fred"
2 | |INVITE (hold)/200 OK/ACK "Hold please"
| |<-----------| |
3 | | |INVITE/200 OK/ACK
| | |--------->|"You have a call
| | | |from Mary"
| | | | "Put her through"
3 | | |INVITE (hold)/200 OK/ACK
| | |--------->|
4 | |REFER | |
| |<-----------| |
4 | |202 Accepted| |
| |----------->| |
4 | |NOTIFY (100 Trying) |
| |----------->| |
4 | |200 OK | |
| |<-----------| |
5 | |INVITE/200 OK/ACK |
| |---------------------->|"This is Fred"
4 | |NOTIFY (200 OK) | "Please hold for
| |----------->| | Mary"
4 | |200 OK | |
| |<-----------| |
2 | |BYE/200 OK | |
| |<-----------| |
3 | | |BYE/200 OK|
| | |--------->|
5 | |INVITE (hold)/200 OK/ACK
| |---------------------->|
6 |REFER | | |
|<-----------| | |
6 |202 Accepted| | |
|----------->| | |
6 |NOTIFY (100 Trying) | |
|----------->| | |
6 |200 OK | | |
|<-----------| | |
7 |INVITE/200 OK/ACK | |
|----------------------------------->| "Hey Fred"
6 |NOTIFY (200 OK) | | "Hello Mary"
|----------->| | |
6 |200 OK | | |
|<-----------| | |
1 |BYE/200 OK | | |
|<-----------| | |
5 | |BYE/200 OK | |
| |---------------------->|
7 |BYE/200 OK | | |
|<-----------------------------------| "See you later"
Figure 18: Transfer with Multiple Parties Example
図18：複数のパーティーの例を使用して転送します
A gateway in SIP acts as a User Agent. As a result, the entire preceding discussion and call flows apply equally well to gateways as native SIP endpoints. However, there are some gateway-specific issues that are documented in this section. While this discussion focuses on the common cases involving Public Switched Telephone Network (PSTN) gateways, similar situations exist for other gateways, such as H.323/SIP gateways.
SIPのゲートウェイは、ユーザーエージェントとして機能します。その結果、先行する議論とコールフロー全体が、ネイティブSIPエンドポイントとしてゲートウェイに等しく適用されます。ただし、このセクションで文書化されているゲートウェイ固有の問題がいくつかあります。この議論は、公共の切り替えた電話ネットワーク（PSTN）ゲートウェイを含む一般的なケースに焦点を当てていますが、H.323/SIPゲートウェイなど、他のゲートウェイにも同様の状況が存在します。
To illustrate how a hairpin situation can occur in transfer, consider this example. The original call dialog is setup with the Transferee residing on the PSTN side of a SIP gateway. The Transferor is a SIP phone purely in the IP space. The Transfer Target is on the PSTN side of a SIP gateway as well. After completing the transfer, (regardless of consultative or blind) the Transferee is in a call with the Transfer Target (both on the PSTN side of a gateway). It is often desirable to remove the gateway(s) out of the loop. This is likely to only be possible if both legs of the target call are on the same gateway. With both legs on the same gateway, it may be able to invoke the analogous transfer on the PSTN side. Then the target call would not involve the gateway.
転送でヘアピンの状況がどのように発生するかを説明するために、この例を考慮してください。元のコールダイアログは、SIPゲートウェイのPSTN側にある譲受人が設定されています。転送者は、純粋にIPスペースにあるSIP電話です。転送ターゲットは、SIPゲートウェイのPSTN側にもあります。譲渡を完了した後、（コンサルティブまたはブラインドに関係なく）譲受人は、移籍ターゲット（両方ともゲートウェイのPSTN側）と呼ばれます。多くの場合、ループからゲートウェイを取り外すことが望ましいです。これは、ターゲットコールの両脚が同じゲートウェイにある場合にのみ可能になる可能性があります。同じゲートウェイに両脚を使用すると、PSTN側の類似の転送を呼び出すことができる場合があります。ターゲットコールにはゲートウェイが含まれません。
So the problem is how to give the proxy enough information so that it knows to route the call to the same gateway. With a simple single call that hairpins, the incoming and outgoing leg have the same dialog. The proxy should have enough information to optimize the routing.
したがって、問題は、同じゲートウェイへの通話をルーティングすることを知っているように、プロキシに十分な情報を与える方法です。ヘアピンという単純なシングルコールで、着信と発信の脚には同じダイアログがあります。プロキシには、ルーティングを最適化するのに十分な情報が必要です。
In the consultative transfer scenario, it is desirable to coerce the consultative INVITE out the same gateway as the original call to be transferred. However, there is no way to relate the consultation with the original call. In the consultative case, the target call INVITE includes the Replaces header, which contains dialog information that can be used to relate it to the consultation. However, there is no information that relates the target call to the original.
コンサルティブ転送シナリオでは、譲渡される元の呼び出しと同じゲートウェイを招待して招待されることが望ましいです。ただし、相談を元の呼び出しと関連付ける方法はありません。コンサルティブケースでは、ターゲットコールInviteには、それをコンサルテーションに関連付けるために使用できるダイアログ情報が含まれる交換ヘッダーが含まれています。ただし、ターゲットコールをオリジナルに関連付ける情報はありません。
In the blind transfer scenario, it is desirable to coerce the target call onto the same gateway as the original call. However, the same problem exists in that the target-dialog cannot be related to the original dialog.
ブラインドトランスファーシナリオでは、元の呼び出しと同じゲートウェイにターゲットコールを強制することが望ましいです。ただし、ターゲットダイアログが元のダイアログに関連することができないという点で同じ問題が存在します。
In either transfer scenario, it may be desirable to push the transfer operation onto the non-SIP side of the gateway. Presumably, this is not possible unless all of the legs go out the same gateway. If the gateway supports more than one trunk group, it might also be necessary to get all of the legs on the same trunk group in order to perform the transfer on the non-SIP side of the gateway.
いずれかの転送シナリオでは、転送操作をゲートウェイの非SIP側にプッシュすることが望ましい場合があります。おそらく、これはすべての脚が同じゲートウェイから外れない限り不可能です。ゲートウェイが複数のトランクグループをサポートする場合、ゲートウェイの非SIP側で転送を実行するために、同じトランクグループにすべての脚を取得する必要もあります。
Solutions to these gateway specific issues may involve new extensions to SIP in the future.
これらのゲートウェイ固有の問題のソリューションには、将来的にSIPする新しい拡張機能が含まれる場合があります。
In the consultative transfer case turned blind, there is a glare-like problem. The Transferor initiates the consultation INVITE, the Transferor gets impatient and hangs up, transitioning this to a blind transfer. The Transfer Target on the gateway (connected through a PSTN switch to a single line or dumb analog phone) rings. The user answers the phone just after the CANCEL is received by the Transfer Target. The REFER and INVITE for the target call are sent. The Transferee attempts to set up the call on the PSTN side, but gets either a busy response or lands in the users voicemail as the user has the handset in hand and off hook.
協議の移籍ケースが盲目になった場合、まぶしさのような問題があります。譲渡人は協議の招待を開始し、譲渡人は焦りを感じてハングアップし、これをブラインド転送に移行します。ゲートウェイの転送ターゲット（PSTNスイッチを介して単一のラインまたはダムアナログ電話に接続）が鳴ります。キャンセルが転送ターゲットによって受信された直後に、ユーザーは電話に応答します。ターゲットコールの紹介と招待が送信されます。譲受人は、PSTN側でコールを設定しようとしますが、ユーザーがハンドセットを手とオフフックにしているため、忙しい応答またはユーザーのボイスメールに着地します。
This is another example of a race condition that this call flow can cause. The recommended behavior is to use the approach described in Section 7.6.
これは、このコールフローが引き起こす可能性のある人種条件の別の例です。推奨される動作は、セクション7.6で説明されているアプローチを使用することです。
The call transfer flows shown in this document are implemented using the REFER and Replaces call control primitives in SIP. As such, the security considerations detailed in the REFER [RFC3515] and Replaces [RFC3891] documents MUST be followed, which are briefly summarized in the following paragraphs. This document addresses the issue of protecting the Address of Record URI of a Transfer Target in Sections 7.1 and 7.2.
このドキュメントに示されているコール転送フローは、参照を使用して実装され、SIPのコールコントロールプリミティブを置き換えます。そのため、参照[RFC3515]および[RFC3891]の置換ドキュメントで詳述されているセキュリティ上の考慮事項に従う必要があります。これは、次の段落に簡単に要約されています。このドキュメントは、セクション7.1および7.2の転送ターゲットのRecord URIのアドレスを保護する問題に対処しています。
Any REFER request MUST be appropriately authenticated and authorized using standard SIP mechanisms or else calls may be hijacked. A User Agent may use local policy or human intervention in deciding whether or not to accept a REFER. In generating NOTIFY responses based on the outcome of the triggered request, care should be taken in constructing the message/sipfrag body to ensure that no private information is leaked.
紹介要求は、標準のSIPメカニズムを使用して適切に認証および承認されている必要があります。そうしないと、呼び出しがハイジャックされる場合があります。ユーザーエージェントは、紹介を受け入れるかどうかを決定する際に、ローカルポリシーまたは人間の介入を使用する場合があります。トリガーされた要求の結果に基づいて通知回答を生成する際に、個人情報が漏れないようにメッセージ/sipfrag本体を構築することに注意する必要があります。
An INVITE containing a Replaces header field SHOULD only be accepted if it has been properly authenticated and authorized using standard SIP mechanisms, and the requestor is authorized to perform dialog replacement. Special care is needed if the replaced dialog utilizes additional media streams compared to the original dialog. In this case, the user MUST authorize the addition of new media streams in a dialog replacement. For example, the same mechanism used to authorize the addition of a media stream in a re-INVITE could be used.
交換ヘッダーフィールドを含む招待状は、標準のSIPメカニズムを使用して適切に認証および承認されている場合にのみ受け入れられる必要があり、リクエスタはダイアログの交換を実行することを許可されます。交換されたダイアログが元のダイアログと比較して追加のメディアストリームを利用する場合、特別な注意が必要です。この場合、ユーザーはダイアログの置換に新しいメディアストリームの追加を承認する必要があります。たとえば、再入札型にメディアストリームの追加を承認するために使用される同じメカニズムを使用できます。
This document is a collaborative product of the SIP working group. Thanks to Rohan Mahy for his input on the use of Replaces in transfer.
このドキュメントは、SIPワーキンググループの共同製品です。Rohan Mahyに、転送中の交換の使用に関する意見に感謝します。
[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月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（SIP）」は「ヘッダー」、RFC 3891、2004年9月に置き換えられます。
[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[RFC3892] Sparks、R。、「セッション開始プロトコル（SIP）メカニズムを参照」、RFC 3892、2004年9月。
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[RFC4538] Rosenberg、J。、「セッション開始プロトコル（SIP）でのダイアログ識別による認可を要求する」、RFC 4538、2006年6月。
[CC-FRMWRK] Mahy, R., Sparks, R., Rosenberg, J., Petrie, D., and A. Johnston, "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, March 2009.
[CC-FRMWRK] Mahy、R.、Sparks、R.、Rosenberg、J.、Petrie、D.、およびA. Johnston、「セッション開始プロトコル（SIP）のコールコントロールとマルチパーティの使用フレームワーク」、2009年3月、進行中の作業。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のためのフレームワーク」、RFC 4353、2006年2月。
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[RFC4475] Sparks、R.、Hawrylyshen、A.、Johnston、A.、Rosenberg、J。、およびH. Schulzrinne、「セッション開始プロトコル（SIP）拷問テストメッセージ」、RFC 4475、2006年5月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、「会議状態のセッション開始プロトコル（SIP）イベントパッケージ」、RFC 4575、2006年8月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579]ジョンストン、A。およびO.レビン、「セッション開始プロトコル（SIP）コールコントロール - ユーザーエージェントの会議」、BCP 119、RFC 4579、2006年8月。
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007.
[RFC5057] Sparks、R。、「セッション開始プロトコルでの複数のダイアログ使用」、RFC 5057、2007年11月。
[SIP-GRUU] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2007.
[SIP-Gruu] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェント（UA）URIS（GRUU）の取得と使用」、2007年10月の作業。
Authors' Addresses
著者のアドレス
Robert Sparks Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75252 USA
ロバートスパークステケレック17210キャンベルロードスイート250ダラス、テキサス75252 USA
EMail: RjS@nostrum.com
Alan Johnston (editor) Avaya St. Louis, MO
アラン・ジョンストン（編集者）アヴァヤ・セントルイス、ミズーリ
EMail: alan@sipstation.com
Daniel Petrie SIPez LLC Arlington, MA 02476 US
ダニエル・ペトリー・シペスLLCアーリントン、マサチューセッツ州02476 US
Phone: +1 617 273 4000
EMail: dan.ietf@SIPez.com
URI: http://www.SIPez.com/