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
        

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.

このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

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.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者(複数可)材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者(単数または複数)から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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拡張REFERとはReplacesがブラインド転送、打診転送、および在席転送などの転送サービスの数を提供するために使用されています。この作品は、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
        
1. Overview
1。概要

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.

この文書では、REFERメソッド[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]をREFERサポートし、RFC 3261 [RFC3261]に加えて、[RFC3891]に置き換え。ユーザーエージェントは、準拠したユーザエージェントは、ターゲット対話ヘッダフィールド[RFC4538]をサポートしているRFC 3261のセクション8.1.1.8での要件を満たしている連絡先URIを使用する必要があります。

2. Actors and Roles
2.アクターと役割

There are three actors in a given transfer event, each playing one of the following roles:

3人の与えられた転送イベント中の俳優、次の各ロール遊ん1があります。

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.

発信:受信者への呼び出しを置きたいと思っています。この俳優は、最初のファシリテーターやクリーナーのいずれかに、セッション中にINVITEの源です。

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.

受信者:オリジネータが最終的に接続されているパーティ。

3. Terminology
3.用語

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。

4. Requirements
4.要件

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.
        

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.
        
5. Using REFER to Achieve Call Transfer
5.使用したコールの転送を実現するためにREFER

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]の転送先にINVITEを発行する譲渡先を引き起こすために譲渡人によって発行することができます参照してください。成功したREFERトランザクションが譲渡人と譲受人の間でセッションを終了しないことに注意してください。これらの当事者が自分のセッションを終了したい場合、彼らはそれに続くBYE要求を行う必要があります。転勤と転送先の間でネゴシエートされたメディアは、譲渡人と譲受人との間で交渉されていたメディアの影響を受けません。特に、譲受人が独自にINVITEをその開始した場合、それが持っているのと同じセッション記述プロトコル(SDP)の体を持っています譲受人によって発行されたINVITE。さらに、転送元と譲受間のメディアストリームの配置は、REFERメソッドによって変更されません。

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ホールドの使用会議フレームワーク[RFC4353]に記載の再INVITE [RFC3261]または会議拡張することができます。

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].

転送を実行するには、譲渡人と譲受人がREFER送信するために、INVITEによって確立された既存のダイアログを再利用することができます。招待用法とサブスクリプションの使用 - これは、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.転送に関与する特定のエンドポイントに到達する新しいダイアログで参照することを確実にする方法はありませんでした。 INVITEとREFER間のプロキシルーティングでの実装や変更の詳細を含む多くの要因が、REFERが間違った場所に送信される可能性があります。ダウンREFER送信既存のダイアログは、我々はすでに話していたし、それが終点に着い確保しました。

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.既存のREFER REFERがINVITE使用状況のダイアログに来たとき会合が何であったか、完全には明らかだった新しいダイアログ、に到着して使用状況を招待を関連付ける方法不明でした。

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.アウトオブダイアログ参照許可との懸念がありました。ほとんどの実装でREFERのための承認ポリシーは、(単に、「私はこのコールを置いたり答え」に基づいて、ほとんどの場合、ある)INVITEの認可ポリシーに便乗します。

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のURI(GRUUs)[SIP-GRUUは] 2 [RFC4538]で定義されたターゲット対話ヘッダフィールドを使用して取り組むことができる問題1.問題に対処するために使用することができます。即時の用語では、問題2に、このソリューションは、既存のREFER認可ポリシーを再利用することができます。

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はダイアログ外でルーティング可能であることを知っている場合、結果として、REFERは新しいダイアログに送ってください。連絡先URIの性質が知られているか、ターゲット・ダイアログの拡張のサポートは知られていない場合は、既存のダイアログ内送ってくださいREFERされていない場合。譲受人は、ダイアログの内側または外側REFERを受けるために準備しなければなりません。譲渡人が連絡先URIダイアログ外部ルーティング可能であることを知ることができることを一つの方法は、検証することにより(例えば、OPTIONSを送信し、応答を受信する)か、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コンセンサスに従ってベストたしなみあるREFERと転送を実現するために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ドメインです。

6. Basic Transfer
6.基本転送

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.

基本転送の参加者は招待しOK INVITEでAllowヘッダーフィールドでREFERおよびNOTIFYメソッド、200、およびOPTIONSメッセージのサポートを示す必要があります。また、参加者は、サポートされているヘッダフィールドにターゲット対話のためのサポートを示すべきです。

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.

以下の図は、各メッセージの最初のラインを示しています。図の最初の列は、その特定のメッセージに使用されるダイアログを示します。これらの図では、メディアが再INVITEを介して管理されている保持し、他の機構(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".

以下のフローの各々は、転送元とREFER処理中(保留)に接続したまま譲渡先との間の対話を示しています。これは、障害からの回復のための最大の柔軟性を提供していますが、それは必要ありません。譲渡人代理人は、REFER残りのプロセスに参加することを希望すると転写不良からの回復を支援する意思がないていない場合は、できるだけ早くREFERトランザクションが完了すると譲渡先にBYEを発することができました。この流れは、時々「無人転送」または「ブラインド転送」として知られています。

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.

譲受人がGRUUを利用して、ターゲット・ダイアログの拡張をサポートし、譲渡人にこのことを示している場合、図1は転送を示しています。その結果、譲渡人は、INVITEダイアログ外でREFERを送信します。譲受人が、これは既存のダイアログを参照している参照にターゲット対話ヘッダフィールドを使用して、既存のダイアログを参照して一致させることができます。

6.1. Successful Transfer
6.1. 成功した転送
             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

図1:基本転送コールフロー

F1 INVITE Transferee -> Transferor

F1譲渡先をINVITE - >譲渡人

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: ...

一口にINVITE:transferor@atlanta.example.com SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;ブランチ= z9hG4bKnas432マックス・フォワード:70:<一口:transferor@atlanta.example.com>から<一口: transferee@biloxi.example.com>;タグ= 7553452のCall-ID:090459243588173445のCSeq:29887 INVITE許可:REFER、BYE、OPTIONS、ACKは、CANCEL、INVITE、サポートされているNOTIFY:置き換え、GRUU、tdialogとの接触:<一口を:3ld812adkjw @ biloxi.example.com; GR = 3413kj2ha>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

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: ...

SIP / 2.0 200 OK経由:SIP / 2.0 / TLS 192.0.2.4;ブランチ= z9hG4bKnas432へ:<一口:transferor@atlanta.example.com>;タグ= 31kdl4i3kから:<一口:transferee@biloxi.example.com>。タグ= 7553452のCall-ID:090459243588173445のCSeq:29887 INVITE許可:REFER、BYE、ACKは、CANCEL、OPTIONSをINVITE、サポートされているNOTIFY:置き換え、GRUU、tdialogとの接触:<一口を:4889445d8kjtk3@atlanta.example.com; GR = 723jd2d >のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

F3 REFER Transferor -> Transferee

F3は、譲渡人のREFER - >転勤

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

SIPを参照してください3ld812adkjw@biloxi.example.com; GR = 3413kj2ha SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bKna9最大フォワード:70:<一口:3ld812adkjw@biloxi.example .COM; GR = 3413kj2ha>から<一口:transferor@atlanta.example.com>;タグ= 1928301774のCall-ID:a84b4c76e66710のCSeq:314159を許可REFER:サポートされているNOTIFY、REFER、BYE、OPTIONS、ACKは、CANCEL、INVITE: GRUUは、置き換え、tdialogが必要:参照してください-にtdialog:<一口:transfertarget@chicago.example.com>-Dialogをターゲット:090459243588173445;ローカルタグ= 7553452;リモートタグ= 31kdl4i3k連絡先:<一口:4889445d8kjtk3@atlanta.example .COM; GR = 723jd2d>のContent-Length:0

F4 NOTIFY Transferee -> Transferor

F4譲渡先をNOTIFY - >譲渡人

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をNOTIFY:4889445d8kjtk3@atlanta.example.com; GR = 723jd2d SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;分岐= z9hG4bKnas432最大フォワード:70:<一口:transferor@atlanta.example.com>。タグ= 1928301774から:<一口:3ld812adkjw@biloxi.example.com;グラム= 3413kj2ha>;タグ= a6c85cfのC​​all-ID:のCSeq a84b4c76e66710:73連絡先をNOTIFY:<一口:3ld812adkjw@biloxi.example.com;グラム= 3413kj2ha>許可:REFER、BYE、OPTIONSを、ACK、INVITE、CANCEL、サポートされているNOTIFY:置き換え、tdialogイベント:サブスクリプションのステートを参照してください:アクティブ; = 60 Content-Typeの有効期限が切れる:メッセージ/ sipfragのコンテンツ長を:...

SIP/2.0 100 Trying

SIP / 2.0 100試行

F5 INVITE Transferee -> Transfer Target

F5譲渡先をINVITE - >転送対象

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: ...

一口にINVITE:transfertarget@chicago.example.com SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;ブランチ= z9hG4bKnas41234マックス・フォワード:70:<一口:transfertarget@chicago.example.com>から<一口: transferee@biloxi.example.com>;タグ=コールIDをj3kso3iqhq:90422f3sd23m4g56832034のCSeq:521 REFER許可:BYE、OPTIONS、ACK、INVITE、CANCEL、REFER、サポートされているNOTIFY:置き換え、GRUU、tdialogとの接触:<一口:3ld812adkjw @ biloxi.example.com; GR = 3413kj2ha>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

F6 NOTIFY Transferee -> Transferor

F6譲渡先をNOTIFY - >譲渡人

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をNOTIFY:4889445d8kjtk3@atlanta.example.com; GR = 723jd2d SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;分岐= z9hG4bKnas432最大フォワード:70:<一口:transferor@atlanta.example.com>。タグ= 1928301774から:<一口:3ld812adkjw@biloxi.example.com;グラム= 3413kj2ha>;タグ= a6c85cfのC​​all-ID:のCSeq a84b4c76e66710:74連絡先をNOTIFY:<一口:3ld812adkjw@biloxi.example.com;グラム= 3413kj2ha>許可:、ACKは、CANCEL INVITE、OPTIONSは、BYE、NOTIFY、REFERサポート:置き換え、tdialogイベント:サブスクリプションのステートを参照してください:終了;理由= NORESOURCEのコンテンツタイプ:メッセージ/ sipfragのコンテンツの長さ:...

SIP/2.0 200 OK

SIP / 2.0 200 OK

6.2. Transfer with Dialog Reuse
6.2. ダイアログの再利用と転送

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の性質を知っていないか、譲受人がターゲット対話ヘッダフィールドをサポートしていることを知りません。その結果、INVITEダイアログ内で送信されます参照してください。

             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

図2:ダイアログを再利用して転送します

F1 INVITE Transferee -> Transferor

F1譲渡先をINVITE - >譲渡人

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: ...

一口にINVITE:transferor@atlanta.example.com SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;ブランチ= z9hG4bKnas432マックス・フォワード:70:<一口:transferor@atlanta.example.com>から<一口: transferee@biloxi.example.com>;タグ= 7553452のCall-ID:090459243588173445のCSeq:サポートされている、INVITE ACK、CANCEL、OPTIONS、BYE、REFER、NOTIFY:連絡先を置き換える:<一口:transferee@192.0.2.4> 29887を許可INVITEコンテンツタイプ:アプリケーション/ SDPコンテンツの長さ:...

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: ...

SIP / 2.0 200 OK経由:SIP / 2.0 / TLS 192.0.2.4;ブランチ= z9hG4bKnas432へ:<一口:transferor@atlanta.example.com>;タグ= 31kdl4i3kから:<一口:transferee@biloxi.example.com>。タグ= 7553452のCall-ID:090459243588173445のCSeq:29887許可INVITE:、BYE、REFER、OPTIONS、CANCEL、ACKをINVITE NOTIFYサポート:GRUU、連絡先を置き換える:<一口:4889445d8kjtk3@atlanta.example.com;グラム= 723jd2d>コンテンツ - タイプ:アプリケーション/ SDPコンテンツの長さ:...

F3 REFER Transferor -> Transferee

F3は、譲渡人のREFER - >転勤

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

SIPを参照してくださいtransferee@192.0.2.4 SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bKna9最大フォワード:70:<一口:transferee@biloxi.example.com>;タグ= 7553452:<一口:transferor@atlanta.example.com>;タグ=コールIDを31kdl4i3k:090459243588173445のCSeq:サポートされている、INVITE ACK、CANCEL、OPTIONS、BYE、REFER、NOTIFY:参照してください-に置き換えます。<314159を許可REFER一口:transfertarget@chicago.example.com>連絡先:<すする:4889445d8kjtk3@atlanta.example.com;グラム= 723jd2d>のContent-Length:0

F4 NOTIFY Transferee -> Transferor

F4譲渡先をNOTIFY - >譲渡人

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をNOTIFY:4889445d8kjtk3@atlanta.example.com; GR = 723jd2d SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;分岐= z9hG4bKnas432最大フォワード:70:<一口:transferor@atlanta.example.com>。 090459243588173445はのCSeq:29888連絡先をINVITE:タグ= 7553452のCall-ID <一口:3ld812adkjw@biloxi.example.com; GR = 3413kj2ha>許可:INVITE、<transferee@biloxi.example.com一口:>からタグ= 31kdl4i3kイベントを置き換えます:ACKは、CANCEL、OPTIONSは、BYE、サポートされているNOTIFY、REFERサブスクリプションのステートを参照してください:アクティブ; = 60 Content-Typeの有効期限が切れる:メッセージ/ sipfragのコンテンツ長を:...

SIP/2.0 100 Trying

SIP / 2.0 100試行

F5 INVITE Transferee -> Transfer Target

F5譲渡先をINVITE - >転送対象

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: ...

一口にINVITE:transfertarget@chicago.example.com SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;ブランチ= z9hG4bKnas41234マックス・フォワード:70:<一口:transfertarget@chicago.example.com>から<一口: transferee@biloxi.example.com>;タグ=コールIDをj3kso3iqhq:90422f3sd23m4g56832034のCSeq:521 REFER許可:BYE、REFER、サポートされているNOTIFY、OPTIONS、ACK、INVITEをCANCEL:置き換え連絡先:<一口:transferee@192.0.2.4>コンテンツタイプ:アプリケーション/ SDPコンテンツの長さ:...

F6 NOTIFY Transferee -> Transferor

F6譲渡先をNOTIFY - >譲渡人

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をNOTIFY:4889445d8kjtk3@atlanta.example.com; GR = 723jd2d SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;分岐= z9hG4bKnas432最大フォワード:70:<一口:transferor@atlanta.example.com>。 090459243588173445はのCSeq:29889連絡先をINVITE:タグ= 7553452のCall-ID <一口:3ld812adkjw@biloxi.example.com; GR = 3413kj2ha>許可:INVITE、<transferee@biloxi.example.com一口:>からタグ= 31kdl4i3k ACKは、CANCEL、OPTIONSは、BYE、サポートされているNOTIFY、REFER:イベントを置き換える:サブスクリプション・ステートを参照してください:終了;理由= NORESOURCEのコンテンツタイプ:メッセージ/ sipfragのコンテンツの長さ:...

SIP/2.0 200 OK

SIP / 2.0 200 OK

6.3. Failed Transfer
6.3. 失敗した転送

This section shows examples of failed transfer attempts. After the transfer failure occurs, the Transferor takes the Transferee off hold and resumes the session.

このセクションでは、失敗した転送の試みの例を示しています。転写不良が発生した後、譲渡人は、ホールドオフ譲渡先をとり、セッションを再開します。

6.3.1. Target Busy
6.3.1. 忙しいターゲット
             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:失敗した転送 - ビジーターゲット

6.3.2. Transfer Target Does Not Answer
6.3.2. 転送先が応答しません
             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:転送に失敗しました - ターゲットは応答しません

7. Transfer with Consultation Hold
相談ホールド7.転送

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.

便利な機能は、ターゲットが、セッションが意図譲渡に関連していることを知らせる譲渡人のためです。多くのUAがユーザにヘッダーフィールドからの表示名をレンダリングするので、相談は、譲渡人と譲受人の表示名がに含まれている、「譲受を転送する目的で転送元から受信相談」などの文字列を含むことができるINVITE文字列。

7.1. Exposing Transfer Target
7.1. 転送対象を公開

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とセントレックスユーザーが期待するものに似たような経験を提供するために使用することができます。

To (hopefully) improve clarity, non-REFER transactions have been collapsed into one indicator with the arrow showing the direction of the request.

(たぶん)透明性を向上させるために、非REFERトランザクション要求の方向を示す矢印を有する一つの指標に折りたたまれています。

             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:ホールド相談して転送 - 転送対象の公開

7.2. Protecting Transfer Target
7.2. 転送対象の保護

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ヘッダのパラメータとして直接提供することができます。 Replaces機構[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.

以下の流れのために、Dialog1のダイアログ識別子1を意味し、[RFC3891]でダイアログ1のReplacesヘッダーのパラメータからなり、これは、Call-ID、TO-タグからタグです。

Note that the Transferee's agent emits a BYE to the Transferor's agent as an immediate consequence of processing the Replaces header.

譲受人の薬剤はReplacesヘッダーを処理する直接の結果として、転送元のエージェントにBYEを放出することに留意されたいです。

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応答に含まれる置き換えヘッダー:譲渡人は、譲渡先と転送先の両方がサポートされているからReplacesヘッダーをサポートしていることを知っています。

In this scenario, the Transferee utilizes a GRUU as a Contact URI for reasons discussed in Section 6.3.

このシナリオでは、譲受人は6.3節で述べた理由のために連絡先URIとしてGRUUを利用しています。

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

図6:転送保護転送対象

F1 INVITE Transferee -> Transferor

F1譲渡先をINVITE - >譲渡人

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: ...

一口にINVITE:transferor@atlanta.example.com SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;ブランチ= z9hG4bKnas432マックス・フォワード:70:<一口:transferor@atlanta.example.com>から<一口: transferee@biloxi.example.com>;タグ= 7553452のCall-ID:090459243588173445のCSeq:29887 INVITE許可:サポートされているNOTIFY、OPTIONSは、BYE、REFER、ACKは、CANCEL、INVITE:置き換え、GRUU連絡先:<一口:3ld812adkjwをビロクシー@。 example.com; GR = 3413kj2ha>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

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: ...

SIP / 2.0 200 OK経由:SIP / 2.0 / TLS 192.0.2.4;ブランチ= z9hG4bKnas432へ:<一口:transferor@atlanta.example.com>;タグ= 31431から:<一口:transferee@biloxi.example.com>。タグ= 7553452のCall-ID:090459243588173445のCSeq:29887 INVITE許可:REFER、BYE、ACKは、CANCEL、OPTIONSをINVITE、サポートされているNOTIFY:置き換え、GRUU、tdialogとの接触:<一口を:4889445d8kjtk3@atlanta.example.com; GR = 723jd2d >のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

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: ...

一口にINVITE:transfertarget@chicago.example.com SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;ブランチ= z9hG4bKnas432マックス・フォワード:70:<一口:transfertarget@chicago.example.com>から<一口:transferor@atlanta.example.com>;タグは= 763231コールID:592435881734450904のCSeq:tdialogが必要、GRUUは、置き換え:置き換え、ACKをINVITE、CANCEL、OPTIONS、BYE、REFER、サポートされているNOTIFY:29887を許可INVITE連絡先:<一口:4889445d8kjtk3@atlanta.example.com;グラム= 384i32lw3>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

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: ...

SIP / 2.0 200 OK経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bKnas432は、受信= 192.0.2.1に<一口:transfertarget@chicago.example.com>;タグ= 9m2n3wqから<SIPS :transferor@atlanta.example.com>;タグ= 763231コールID:592435881734450904のCSeq:サポートされている、ACKをINVITE、CANCEL、OPTIONS、BYE、REFER、NOTIFY:29887を許可INVITE置き換え、GRUU、tdialog連絡先:<一口:482n4z24kdg @ chicago.example.com; GR = 8594958>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

F5 REFER Transferor -> Transfer Target

F5譲渡人のREFER - >転送対象

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

SIPを参照してください482n4z24kdg@chicago.example.com; GR = 8594958 SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bKnashds9最大転送します。<一口:70 482n4z24kdg@chicago.example .COM; GR = 8594958>から<一口:transferor@atlanta.example.com>;タグ= 1928301774のCall-ID:a84b4c76e66710のCSeq:314159を許可REFER:サポートされているNOTIFY、REFER、BYE、OPTIONS、ACKは、CANCEL、INVITE: GRUU、置き換え、tdialogが必要:tdialog <allOneLine>参照の-た:<SIPS:3ld812adkjw@biloxi.example.com; GR = 3413kj2haが置き換え= 090459243588173445% 3Btoタグ%3D7553452%3Bfromタグ%3D31431> </ allOneLine>ターゲット対話:592435881734450904;ローカルタグ= 9m2n3wq;リモートタグ= 763231連絡先:<一口:4889445d8kjtk3@atlanta.example.com;グラム= 723jd2d>のContent-Length:0

F6 INVITE Transfer Target -> Transferee

F6転送対象のINVITE - >転勤

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: ...

SIPをINVITE:3ld812adkjw@biloxi.example.com; GR = 3413kj2ha SIP / 2.0経由:SIP / 2.0 / TLS client.chicago.example.com;分岐= z9hG4bKnaslu84最大フォワード:70:<一口:3ld812adkjw@biloxi.example .COM; GR = 3413kj2ha>から<一口:transfertarget@chicago.example.com>; = 341234のCall-IDタグ:kmzwdle3dl3d08のCSeq:サポートされているNOTIFY、REFER、BYE、、、ACKをINVITE、CANCEL、OPTIONS:41は、許可INVITE: GRUU、置き換え、tdialog連絡先:<一口:482n4z24kdg@chicago.example.com;グラム= 8594958>置き換え:090459243588173445を;にタグ= 7553452;からタグ= 31431のContent-Type:アプリケーション/ SDPコンテンツ長.. 。

7.3. Attended Transfer
7.3. 在席転送

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.

譲渡人が差し迫った転送にそれらを警告するための転送先との通話を確立し、保留にターゲットを置き、保留に譲渡先を置き、その後、エスケープ使用して転送して進める参照してください-Toヘッダーにヘッダフィールドを置き換えます。これは、現在のPBXとセントレックスユーザーが期待するもう一つの共通のサービスです。

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は、参照の対URIとして転送元によって使用されるべきです。それ以外の場合は、転送対象のレコード(AOR)のアドレスを使用する必要があります。それは、譲渡人が使用されるべき転送先とのセッションを確立するために使用されるのと同じURI、です。ケースでトリガINVITEは、転送対象とは異なるユーザエージェントにルーティングされる必要:フィールドがINVITEトリガで使用されるべきヘッダ置き換えます。 (これのように置き換えを無視して、ダイアログが一致せずにINVITE答えるからはReplacesをサポートしていない不正なユーザーエージェントを防ぐためです。)

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.

プロキシ/サービスルーティングがトリガー同じユーザエージェントに到達するのINVITEを防ぐことが可能です。この問題が発生した場合、招待トリガタイムアウト、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

図7:在席転送のコールフロー

F1 INVITE Transferee -> Transferor

F1譲渡先をINVITE - >譲渡人

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: ...

一口にINVITE:transferor@atlanta.example.com SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;ブランチ= z9hG4bKnas432マックス・フォワード:70:<一口:transferor@atlanta.example.com>から<一口: transferee@biloxi.example.com>;タグ= 7553452のCall-ID:090459243588173445のCSeq:29887 INVITE許可:REFER、BYE、OPTIONS、ACKは、CANCEL、INVITE、サポートされているNOTIFY:置き換え、GRUU、tdialogとの接触:<一口を:3ld812adkjw @ biloxi.example.com; GR = 3413kj2ha>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

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: ...

SIP / 2.0 200 OK経由:SIP / 2.0 / TLS 192.0.2.4;ブランチ= z9hG4bKnas432へ:<一口:transferor@atlanta.example.com>;タグ= 31431から:<一口:transferee@biloxi.example.com>。タグ= 7553452のCall-ID:090459243588173445のCSeq:29887 INVITE許可:REFER、BYE、ACKは、CANCEL、OPTIONSをINVITE、サポートされているNOTIFY:置き換え、GRUU、tdialogとの接触:<一口を:4889445d8kjtk3@atlanta.example.com; GR = 723jd2d >のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

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: ...

一口にINVITE:transfertarget@chicago.example.com SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;ブランチ= z9hG4bKnas432マックス・フォワード:70:<一口:transfertarget@chicago.example.com>から<一口:transferor@atlanta.example.com>;タグは= 763231コールID:592435881734450904のCSeq:tdialogが必要、GRUUは、置き換え:置き換え、ACKをINVITE、CANCEL、OPTIONS、BYE、REFER、サポートされているNOTIFY:29887を許可INVITE連絡先:<一口:4889445d8kjtk3@atlanta.example.com;グラム= 384i32lw3>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

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: ...

SIP / 2.0 200 OK経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bKnas432は、受信= 192.0.2.1に<一口:transfertarget@chicago.example.com>;タグ= 9m2n3wqから<SIPS :transferor@atlanta.example.com>;タグ= 763231コールID:592435881734450904のCSeq:29887 INVITE許可:REFER、BYE、OPTIONS、ACKは、CANCEL、INVITE、サポートされているNOTIFY:置き換え、GRUU接触:<一口:482n4z24kdgシカゴ@ .example.comと、GR = 8594958>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

F5 REFER Transferor -> Transferee

F5は、譲渡人のREFER - >転勤

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

SIPを参照してください3ld812adkjw@biloxi.example.com; GR = 3413kj2ha SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bKnashds9最大フォワード:70:<一口:3ld812adkjw@biloxi.example .COM; GR = 3413kj2ha>から<一口:transferor@atlanta.example.com>; = 1928301774のCall-IDタグ:のCSeq a84b4c76e66710:314159が必要REFER:tdialog <allOneLine>参照してください-TO:<一口:シカゴ@ 482n4z24kdg。 example.com; GR = 8594958?置き換え= 592435881734450904% 3Btoタグ%3D9m2n3wq%3Bfrom-tag3D763231> </ allOneLine>ターゲットダイアログ:592435881734450904、ローカルタグ= 9m2n3wq;リモートタグ= 763231連絡先:<一口:4889445d8kjtk3@atlanta.example.com; GR = 723jd2d>のContent-Length:0

F6 INVITE Transferee -> Transfer Target

F6譲渡先をINVITE - >転送対象

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: ...

SIPをINVITE:482n4z24kdg@chicago.example.com; GR = 8594958 SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;分岐= z9hG4bKnaslu82最大転送します。<一口:70 482n4z24kdg@chicago.example.com; GR = 8594958>から<一口:transferee@biloxi.example.com>;タグ= 954コールID:kmzwdle3dl3d08のCSeq:、、GRUU置き換え:サポートされているNOTIFY、REFER、BYE、、、ACKをINVITE、CANCEL、OPTIONS:41を許可INVITE tdialog連絡先:<一口:3ld812adkjw@biloxi.example.com;グラム= 3413kj2ha>置き換え:592435881734450904;にタグ= 9m2n3wqを;からタグ= 763231のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

7.4. Recovery When One Party Does Not Support REFER
7.4. 復旧一方の当事者がREFERをサポートしていません

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.

保護または転送先を暴露する懸念がない場合には、それだけで譲渡し、一つの他のパーティのサポートを参照するときに相談保留と転送を完了することが可能です。許可されていない405の方法は、代わりに501実装されていません応答で返されるかもしれないことに注意してください。

             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:回復は一方の当事者がサポートしていない場合にはREFER

7.5. Attended Transfer When Contact URI Is Not Known to Route to a Unique User Agent

7.5. 連絡先URIがユニークユーザエージェントにルーティングすることが知られていない在席転送

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.

これは、連絡先URIもダイアログ外のグローバルルーティング可能であるRFC 3261の要件です。しかし、ユーザエージェントといくつかのアーキテクチャRFC 2543に(NAT /ファイアウォールトラバーサルは、スクリーニングプロキシは、アプリケーションレイヤゲートウェイ(ALG)、など)これは常にそうではありません。結果として、在席転送の方法は、図6、図7に示されており、連絡先URIがダイアログ外部ルーティング可能であることが知られている場合は8にのみ使用されるべきです。

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に示すがトリガがINVITEに転送対象の接触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

図9:グローバルにルーティング可能なことは知られていない連絡先URIと在席転送のコールフロー

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: ...

一口にINVITE:transfertarget@chicago.example.com SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;ブランチ= z9hG4bK76マックス・フォワード:70:<一口:transfertarget@chicago.example.com>から<一口:transferor@atlanta.example.com>;タグ= 763231コールID:090459243588173445のCSeq:29887 INVITE許可:REFER、サポートされているNOTIFY、BYE、OPTIONS、ACKは、CANCEL、INVITE:<一口:連絡先置き換え譲渡@ pc33.atlanta.example.com>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

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: ...

SIP / 2.0 200 OK経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bKnas432は、受信= 192.0.2.1に<一口:transfertarget@chicago.example.com>;タグ= 9m2n3wqから<SIPS :transferor@atlanta.example.com>;タグは= 763231コールID:090459243588173445のCSeq:29887許可INVITE:、INVITE ACK、CANCEL、OPTIONS、BYE、REFER、サポートされているNOTIFY:連絡先を置き換える:<一口:transfertarget@client.chicago .example.comと>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

F3 REFER Transferor -> Transferee

F3は、譲渡人のREFER - >転勤

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

SIPを参照してくださいtransferee@192.0.2.4 SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bKnashds9最大フォワード:70:<一口:transferee@biloxi.example.com>;タグ= a6c85cfから:<一口:transferor@atlanta.example.com>;タグは= 1928301774コールID:?のCSeq a84b4c76e66710:314160 REFER <allOneLine>参照してください-た:<一口:transfertarget@chicago.example.com = 090459243588173445% 3Btoを置き換え-tag%3D9m2n3wq%3Bfromタグ%3D763231&必要=置き換え> <allOneLine>連絡先:<一口:transferor@pc33.atlanta.example.com>のContent-Length:0

F4 INVITE Transferee -> Transfer Target

F4譲渡先をINVITE - >転送対象

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: ...

一口にINVITE:transfertarget@chicago.example.com SIP / 2.0経由:SIP / 2.0 / TLS 192.0.2.4;ブランチ= z9hG4bKnaslu82マックス・フォワード:70:<一口:transfertarget@chicago.example.com>から<一口: transferee@biloxi.example.com>;タグ= 954コールID:20482817324945934422930のCSeq:サポートされているNOTIFY、REFER、BYE、、、ACKをINVITE、CANCEL、OPTIONS:連絡先を置き換える:<一口:transferee@192.0.2.4> 42を許可INVITE置き換え:090459243588173445;へのタグ= 9m2n3wq;からタグ= 763231が必要:コンテンツタイプを置き換える:アプリケーション/ SDPコンテンツの長さ:...

F5 NOTIFY Transferee -> Transferor

F5譲渡先をNOTIFY - >譲渡人

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をNOTIFY:transferor@pc33.atlanta.com SIP / 2.0経由:SIP / 2.0 / TLSの192.0.2.4;分岐= z9hG4bKnas432最大フォワード:70:<一口:transferor@atlanta.example.com>;タグ= 1928301774から<一口:transferee@biloxi.example.com>;タグ= a6c85cfコールID:a84b4c76e66710のCSeq:76連絡先をNOTIFY:<一口:3ld812adkjw@biloxi.example.com;グラム= 3413kj2ha>許可:INVITE、ACKは、CANCEL OPTIONSは、BYE、サポートされているNOTIFY、REFER:イベントを置き換えます参照してください; ID = 98873867購読-状態:終了し、理由= NORESOURCEのコンテンツタイプ:メッセージ/ sipfragのコンテンツの長さ:...

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.

まだ正しいエンドポイントに到達するという保証、およびこの第二の結果も失敗かもしれREFERがないことに注意してください。その場合には、譲渡人は、無人の転送にフォールバック可能性があり、または完全移転をあきらめ。二つは二つの別個のサブスクリプションを作成ダイアログ内で送信される指すので、譲受人は2つのサブスクリプションの通知を区別するイベントヘッダフィールドに「ID」パラメータを使用します。

          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: ...

一口にINVITE:transfertarget@chicago.example.com SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;ブランチ= z9hG4bK76マックス・フォワード:70:<一口:transfertarget@chicago.example.com>から<一口:transferor@atlanta.example.com>;タグ= 763231コールID:090459243588173445のCSeq:29887 INVITE許可:REFER、サポートされているNOTIFY、BYE、OPTIONS、ACKは、CANCEL、INVITE:<一口:連絡先置き換え譲渡@ pc33.atlanta.example.com>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

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: ...

SIP / 2.0 200 OK経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bKnas432は、受信= 192.0.2.1に<一口:transfertarget@chicago.example.com>;タグ= 9m2n3wqから<SIPS :transferor@atlanta.example.com>;タグは= 763231コールID:090459243588173445のCSeq:29887許可INVITE:、INVITE ACK、CANCEL、OPTIONS、BYE、REFER、サポートされているNOTIFY:連絡先を置き換える:<一口:transfertarget@client.chicago .example.comと>のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

F3 REFER Transferor -> Transferee

F3は、譲渡人のREFER - >転勤

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

SIPを参照してくださいtransferee@192.0.2.4 SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bKnashds9最大フォワード:70:<一口:transferee@biloxi.example.com>;タグ= a6c85cfから:<一口:transferor@atlanta.example.com>;タグは= 1928301774コールID:?のCSeq a84b4c76e66710:314159 REFER <allOneLine>参照してください-た:<一口:transfertarget@chicago.example.com = 090459243588173445% 3Btoを置き換え-tag%3D9m2n3wq%3Bfromタグ%3D763231&必要=置き換え> </ allOneLine>連絡先:<一口:transferor@pc33.atlanta.example.com>のContent-Length:0

F4 NOTIFY Transferee -> Transferor

F4譲渡先をNOTIFY - >譲渡人

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をNOTIFY:transferor@pc33.atlanta.com SIP / 2.0経由:SIP / 2.0 / TLSの192.0.2.4;分岐= z9hG4bKnas432最大フォワード:70:<一口:transferor@atlanta.example.com>;タグ= 1928301774から<一口:transferee@biloxi.example.com>;タグ= a6c85cfコールID:a84b4c76e66710のCSeq:74連絡先をNOTIFY:<一口:3ld812adkjw@biloxi.example.com;グラム= 3413kj2ha>許可:INVITE、ACKは、CANCEL OPTIONSは、BYE、サポートされているNOTIFY、REFER:イベントを置き換えます参照してください; ID = 314159サブスクリ-状態:終了し、理由= NORESOURCEのコンテンツタイプ:メッセージ/ sipfragのコンテンツの長さ:...

SIP/2.0 403 Forbidden

SIP / 2.0 403禁止

F5 REFER Transferor -> Transferee

F5は、譲渡人のREFER - >転勤

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

SIPを参照してくださいtransferee@192.0.2.4 SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bKnashds9最大フォワード:70:<一口:transferee@biloxi.example.com>;タグ= a6c85cfから:<一口:transferor@atlanta.example.com>;タグは= 1928301774コールID:?のCSeq a84b4c76e66710:314160 REFER <allOneLine>参照してください-た:<一口:transfertarget@client.chicago.example.com置き換え= 090459243588173445 %3Btoタグ%3D9m2n3wq%3Bfromタグ%3D763231> </ allOneLine>連絡先:<一口:transferor@pc33.atlanta.example.com>のContent-Length:0

F6 INVITE Transferee -> Transfer Target

F6譲渡先をINVITE - >転送対象

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: ...

一口にINVITE:transfertarget@client.chicago.example.com SIP / 2.0経由:SIP / 2.0 / TLSの192.0.2.4;ブランチ= z9hG4bKnaslu82マックス・フォワード:70:<一口:transfertarget@chicago.example.com>から<一口:;:20482817324945934422930のCSeq:42を許可INVITE:サポートされているNOTIFY、REFER、BYE、INVITE、ACK、CANCEL、OPTIONS:transferee@biloxi.example.com> = 954のCall-IDタグは、<一口:transferee@192.0連絡先を置き換えます。 2.4>置き換え:090459243588173445;にタグ= 9m2n3wqを;からタグ= 763231のContent-Type:アプリケーション/ SDPコンテンツの長さ:...

F7 NOTIFY Transferee -> Transferor

F7譲渡先をNOTIFY - >譲渡人

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をNOTIFY:transferor@pc33.atlanta.com SIP / 2.0経由:SIP / 2.0 / TLSの192.0.2.4;分岐= z9hG4bKnas432最大フォワード:70:<一口:transferor@atlanta.example.com>;タグ= 1928301774から<一口:transferee@biloxi.example.com>;タグ= a6c85cfコールID:a84b4c76e66710のCSeq:76連絡先をNOTIFY:<一口:3ld812adkjw@biloxi.example.com;グラム= 3413kj2ha>許可:INVITE、ACKは、CANCEL OPTIONSは、BYE、サポートされているNOTIFY、REFER:イベントを置き換えます参照してください; ID = 314160サブスクリ-状態:終了し、理由= NORESOURCEのコンテンツタイプ:メッセージ/ sipfragのコンテンツの長さ:...

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.

起きてからこのシナリオを回避するには、転送対象は、図7のコールフローになりますダイアログ、外部のルーティング可能である連絡先URIを使用すべきです。

7.6. Semi-Attended Transfer
7.6. 半在席転送

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)).

二つの他の可能な半在席転送コールフローは、しかしながら、図12および図13に示されているが、これらのコールフローを伴う競合状態に推奨されません。譲渡人がハングアップしたときにこれらのフローの両方において、転送元がターゲットにCANCEL送信することによって、無人の転送に復帰しようとします。これは、二つの競合状態になることができます。一つは、CANCELにもかかわらず、目標の回答、そして得られた無人の転送が失敗したということです。この競合状態は、ターゲットからの487応答が返されるまでREFER送信するために待機している譲渡人によって排除することができます。代わりに487の、200 OKは、ターゲットが打診コールに答えたことを示す返されることがあります。この場合、図13のコールフローは従わなければなりません。このフローでは、譲渡人がハングアップからのターゲットを防ぐために、ターゲットへのメディアのいくつかの種類を果たさなければならない、または転送が失敗します。これは、転送先の人間は、彼らは、転送が完了するまで(一部のメディアは、(F2)に再生されない限り、F3、彼らは譲渡先に話している)(メッセージF1)に答えるときから沈黙を聞くだろう、です。

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.

転送先がキャンセルした後、「オフフック」を受信し、487が返されます行く場合は、2番目の競合状態は、図12に起こります。これは、無人の転送に486ここでビジー応答をもたらすことができます。

The recommended call flow of Figure 11 does not utilize a CANCEL and does not suffer from these race conditions.

図11の推奨コールフローはCANCEL利用していないと、これらの競合状態に罹患していません。

             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:在席転送コールフローなどの半在席転送(推奨されません)

7.7. Attended Transfer Fallback to Basic Transfer
7.7. 基本転送に出席転送フォールバック

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のコールフローは、要求の使用を示しています。転送先にINVITEを送信する際の譲渡人の意思が出席した転送を完了することがあることが知られた転送先へ譲渡人によって送られたINVITEに置き換えます。ターゲット取って代わるをサポートしていないので、420悪い拡張応答で拒否されたINVITE、および譲渡人はすぐに基本的な転送に出席した転送から切り替わります。

             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:要求使用した基本的な転送に在席転送のフォールバックは:置き換え

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.

譲渡先と転送先が明示的にREFERメソッドのサポートを示すし、許可のヘッダーフィールドとSupportedヘッダーフィールドを置き換え、譲渡人がときにINVITE在席転送を実行する意思を持っていなかったしていないとき、図15は、OPTIONSの使用を示しターゲットが送信されました。 Dialog1のでは、譲渡人は譲受人がサポートしていないことを、OPTIONSを使用して、決定しREFERと置き換えます。その結果、譲渡人が保留に譲渡先を配置し、転送先を呼び出すことで、在席転送を開始します。 dialog2のオプションを使用して、譲渡人は、ターゲットが在席転送ができなくなる、のいずれかを参照するか、または置き換えをサポートしていないことを決定します。譲渡人がその後、BYEを送信することにより、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:基本転送に在席転送のフォールバック

8. Transfer with Referred-By
呼ばバイ8.転送

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.

最も簡単で最も安全なアプローチは、ちょうどそのINVITEトリガにコピーされるREFERにおいて参照することにより、ヘッダフィールドの包含を伴います。しかし、関与より安全機構呼ば-によって生成され、転送元によって署名され、転送対象にその後譲受人にメッセージボディに渡されるセキュリティトークン。

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のコールフローは、REFER F5のヘッダフィールドと身体による換算およびF6をINVITEトリガー示します。セキュア/多目的インターネットメール拡張(S / MIME)署名は、以下の例に示されていないことに留意されたいです。 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: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

図16:呼ば・バイと在席転送のコールフロー

F5 REFER Transferor -> Transferee

F5は、譲渡人のREFER - >転勤

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: ...

SIPを参照してください3ld812adkjw@biloxi.example.com; GR = 3413kj2ha SIP / 2.0経由:SIP / 2.0 / TLS pc33.atlanta.example.com;分岐= z9hG4bK392039842最大フォワード:70:<一口:3ld812adkjw@biloxi.example .COM; GR = 3413kj2ha>から<一口:transferor@atlanta.example.com>;タグ= 1928301774のCall-ID:a84b4c76e66710のCSeq:314160 REFER <allOneLine>参照の-TO:<一口:482n4z24kdg@chicago.example.com ?必要tdialog、GRUU、置き換えます:; GR = 8594958は= 090459243588173445% 3Btoタグ%3D9m2n3wq%の3Bfromタグ%3D763231&が必要=置き換え> </ allOneLine>サポートを置き換えるtdialog呼ばバイ:<一口:transferor@atlanta.example。コム>; CID = "20398823.2UWQFN309shb3@atlanta.example.com" ターゲット対話:592435881734450904;ローカルタグ= 9m2n3wq;リモートタグ= 763231連絡先:<一口:4889445d8kjtk3@atlanta.example.com;グラム= 723jd2d>コンテンツ-Type:混合/マルチ。 =境界ユニーク-境界-1コンテンツの長さ:...

--unique-boundary-1 Content-ID: <20398823.2UWQFN309shb3@atlanta.example.com>

--unique境界-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"

日付:木、2003年9月18日午後一時07分43秒は、GMT <allOneLine>参照してください-TO:<一口:?482n4z24kdg@chicago.example.com;グラム= 8594958にタグ= 090459243588173445%の3B%3D9m2n3wq%3Bfromタグ%を置き換えCID = "20398823.2UWQFN309shb3@atlanta.example.com"; transferor@atlanta.example.com>:<一口:3D763231&必要は=> </ allOneLine>と呼ばバイ置き換え

   ------590F24D439B31E08745DEF0CD9397189
   Content-Type: application/pkcs-7-signature; name="smime.p7s"
        

Content-Transfer-Encoding: binary Content-Disposition: attachment; filename="smime.p7s"

コンテンツ転送エンコード:バイナリコンテンツディスポジション:添付ファイル;ファイル名= "smime.p7s"

<hex>3082088806092A86 4886F70D010702A082087930820875020101310B300906052B0E03021A050030

<六角> 3082088806092A86 4886F70D010702A082087930820875020101310B300906052B0E03021A050030

. . . (Signature not shown)

。 。 。 (署名図示せず)

8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 79089AAD95767F</hex>

8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 79089AAD95767F </六角>

   ------590F24D439B31E08745DEF0CD9397189--
        

--unique_boundary-1

--unique_boundary-1

F6 INVITE Transferee -> Transfer Target

F6譲渡先をINVITE - >転送対象

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: ...

一口にINVITE:482n4z24kdg@chicago.example.com; GR = 8594958 SIP / 2.0経由:SIP / 2.0 / TLSのreferee.example;ブランチ= z9hG4bKffe209934aacへ:<一口:482n4z24kdg@chicago.example.com;グラム= 8594958>から: <一口:transferee@biloxi.example.com>;タグ= 2909034023のCall-ID:889823409マックス-前方にINVITE:fe9023940-a3465@referee.exampleのCSeq 70連絡先:<一口:3ld812adkjw@biloxi.example.com; GR = 3413kj2ha>呼ばバイ<一口:transferor@atlanta.example.com>; CID = "20398823.2UWQFN309shb3@atlanta.example.com" 置換:090459243588173445と、にタグ= 9m2n3wq;からタグ= 76323は、要求:サポートされて置き換えられます。 GRUU、tdialogのContent-Typeを置き換える:multipart / mixedの。境界=私の境界-9のContent-Length:...

--my-boundary-9 Content-Type: application/sdp

境界--my-9のContent-Type:アプリケーション/ 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 0 = IP4のreferee.example S =セッションSDP cで審判2890844526 2890844526 = IP4 IN referee.exampleさt = 0、M =オーディオ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

日付:木、2003年9月18日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"

<allOneLine>参照してください-TO:<一口:transfertarget@chicago.example.com。置き換え= 090459243588173445% 3Bにタグ%3D9m2n3wq%の3Bfromタグ%3D763231&要求=置き換え> </ allOneLine>呼ばバイ<一口: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

<六角> 3082088806092A86 4886F70D010702A082087930820875020101310B300906052B0E03021A050030

. . . (Signature not shown)

。 。 。 (署名図示せず)

8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 79089AAD95767F</hex>

8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B428388966 79089AAD95767F </六角>

   ------590F24D439B31E08745DEF0CD9397189--
        

--my-boundary-9--

--my-境界9--

9. Transfer as an Ad Hoc Conference
アドホック会議など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).

このコール・フローは、参照するパッケージに関連するメッセージとして表示されるNOTIFY第4の要件6を満たすコンファレンス情報パッケージに関連のNOTIFYをNOTIFY(研究会-INFO)として示されているが、(参照)NOTIFY。

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:アドホック会議などに出席転送

10. Transfer with Multiple Parties
複数の締約国と10の転送

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に示すように、発信者はスクリーナを通じて受信者に到達ファシリテーターに電話をかけます。受信者の連絡先情報は、ファシリテーターと発信にさらされています。この例のみREFERメソッドの意味の明確化のために提供され、それは実装の設計として使用すべきではありません。

       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:複数の当事者例で転送

11. Gateway Transfer Issues
11.ゲートウェイ転送の問題

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ゲートウェイなど他のゲートウェイ、のために存在します。

11.1. Coerce Gateway Hairpins to the Same Gateway
11.1. 同じゲートウェイへのゲートウェイヘアピンを強要

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.

だから、問題は、それが同じゲートウェイにコールをルーティングすることを知っているように、プロキシに十分な情報を提供する方法です。そのヘアピン簡単な1回の呼び出しで、着信と発信の脚が同じダイアログを持っています。プロキシは、ルーティングを最適化するのに十分な情報を持っている必要があります。

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強制することが望ましいです。しかし、元のコールとの協議に関連する方法はありません。協議場合には、対象呼

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相談にそれを関連付けるために使用することができるダイアログ情報が含まReplacesヘッダーを含みます。しかし、元のターゲットのコールに関する情報がありません。

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に新しい拡張機能を含むことができます。

11.2. Consultative Turned Blind Gateway Glare
11.2. 諮問なっブラインドゲートウェイグレア

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.

ブラインドになっ打診転送の場合には、グレアのような問題があります。譲渡人は、譲渡人がせっかち取得し、ブラインド転送にこれを移行、ハングアップ、相談がINVITEを開始します。リング(単線又はダムアナログ電話にPSTNスイッチを介して接続されている)ゲートウェイに転送対象。ユーザーはCANCELを転送対象によって受信された直後に電話に応答します。 REFERとターゲット・コールのためのINVITEが送信されます。譲受人は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節で説明したアプローチを使用することです。

12. Security Considerations
12.セキュリティの考慮事項

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の呼制御プリミティブを置き換えを使用して実装されています。そのため、REFER [RFC3515]とはReplaces [RFC3891]の文書に詳述されたセキュリティ上の考慮事項は、簡単に次の段落にまとめられており、続いなければなりません。この文書は、セクション7.1および7.2に転送先の記録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.

任意REFER要求を適切に認証され、認可標準SIPメカニズムを使用して、あるいはハイジャックすることができるコールしなければなりません。ユーザーエージェントは、REFERを受け入れるかどうかを決定する際にローカルポリシーや人間の介入を使用することができます。トリガーされたリクエストの結果に基づいて応答を生成するNOTIFYでは、ケアには、個人情報が漏洩していないことを確認するために、メッセージ/ 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.

Replacesヘッダーフィールドを含むINVITEは、それが適切に認証され、標準のSIPメカニズムを使用して許可された場合にのみ受け入れられるべきであり、リクエスタは、ダイアログ置換を実行することを許可されています。置き換えダイアログが元のダイアログに比べて追加のメディアストリームを利用した場合に特別な注意が必要とされています。この場合、ユーザーは、ダイアログの交換で新しいメディアストリームの追加を許可する必要があります。例えば、RE-INVITEにおけるメディアストリームの追加を許可するために使用されるのと同じメカニズムを使用することができます。

13. Acknowledgments
13.謝辞

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ワーキンググループのコラボレーティブな製品です。転送中はReplacesの使用上の彼の入力のためのロハンマーイに感謝します。

14. References
14.参考文献
14.1. Normative References
14.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP:セッション開始プロトコル" 、RFC 3261、2002年6月。

[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.

[RFC3515]スパークス、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]マーイ、R.、ビッグス、B.、およびR.ディーン、 "セッション開始プロトコル(SIP) "は、" ヘッダ" を置き換えRFC 3891、2004年9月。

[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.

[RFC3892]スパークス、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]、RFC 4538、2006年6月ローゼンバーグ、J.、 "セッション開始プロトコル(SIP)におけるダイアログ識別介して要求承認"。

14.2. Informative References
14.2. 参考文献

[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]マーイ、R.、スパークス、R.、ローゼンバーグ、J.、ペトリ、D.、およびA.ジョンストン、 "セッション開始プロトコル(SIP)のための呼制御とマルチパーティ利用フレームワーク"、進歩、2009年3月に働いています。

[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.

[RFC4353]ローゼンバーグ、J.、RFC 4353、2006年2月 "セッション開始プロトコル(SIP)との会議のためのフレームワーク"。

[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.

[RFC4475]スパークス、R.、Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、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]ローゼンバーグ、J.、Schulzrinneと、H.、およびO.レヴィン、 "Aセッション開始プロトコル(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]スパークス、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]ローゼンバーグ、J.、進歩、2007年10月の作業 "セッション開始プロトコル(SIP)でグローバルにルーティング可能なユーザエージェント(UA)のURI(GRUU)の取得と使用" を参照してください。

Authors' Addresses

著者のアドレス

Robert Sparks Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75252 USA

ロバート・スパークスTekelec 17210キャンベル道スイート250、ダラス、テキサス州75252 USA

EMail: RjS@nostrum.com

メールアドレス:RjS@nostrum.com

Alan Johnston (editor) Avaya St. Louis, MO

アラン・ジョンストン(エディタ)アバイアセントルイス、MO

EMail: alan@sipstation.com

メールアドレス:alan@sipstation.com

Daniel Petrie SIPez LLC Arlington, MA 02476 US

ダニエル・ペトリーSIPez LLCアーリントン、MA 02476米国

Phone: +1 617 273 4000 EMail: dan.ietf@SIPez.com URI: http://www.SIPez.com/

電話:+1 617 273 4000 Eメール:dan.ietf@SIPez.com URI:http://www.SIPez.com/