RFC3725 日本語訳
3725 Best Current Practices for Third Party Call Control (3pcc) in theSession Initiation Protocol (SIP). J. Rosenberg, J. Peterson, H.Schulzrinne, G. Camarillo. April 2004. (Format: TXT=77308 bytes) (Also BCP0085) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg
Request for Comments: 3725 dynamicsoft
BCP: 85 J. Peterson
Category: Best Current Practice Neustar
H. Schulzrinne
Columbia University
G. Camarillo
Ericsson
April 2004
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 3725dynamicsoft BCP: 85J.ピーターソンカテゴリ: 最も良い現在の練習のH.Schulzrinneコロンビア大学G.キャマリロエリクソンNeustar2004年4月
Best Current Practices for Third Party Call Control (3pcc)
in the Session Initiation Protocol (SIP)
セッション開始プロトコルの第三者呼び出しコントロール(3pcc)のための最も良い現在の実務(一口)
Status of this Memo
この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) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control.
第三者呼び出しコントロールは1つの実体が実際に相手の間にコミュニケーションがある呼び出しを作成する能力について言及します。 第三者呼び出しコントロールは、Session Initiationプロトコル(SIP)の中で指定されたメカニズムを使用することで可能です。 しかしながら、それぞれ異なった利益と欠点に関するいくつかの可能なアプローチがあります。 このドキュメントは第三者呼び出しコントロールのためのSIPの使用法のために最も良い現在の実務について議論します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 3
4.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Flow II. . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Flow IV. . . . . . . . . . . . . . . . . . . . . . . . 8
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 9
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10
7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11
8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 13
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . 3 3。 定義. . . . . . . . . . . . . . . . . . . . . . . . 3 4。 3pcc呼び出し設立. . . . . . . . . . . . . . . . . . 3 4.1。 I.44.2に流れてください。 流れII。 . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. III.74.4に流れてください。 流れIV。 . . . . . . . . . . . . . . . . . . . . . . . 8 5. 推薦. . . . . . . . . . . . . . . . . . . . . . 9 6。 エラー処理. . . . . . . . . . . . . . . . . . . . . . . 10 7。 継続的な処理. . . . . . . . . . . . . . . . . . . . 11 8。 3pccと早めのメディア. . . . . . . . . . . . . . . . . . . . 13
Rosenberg, et al. Best Current Practice [Page 1] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[1ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
9. Third Party Call Control and SDP Preconditions . . . . . . . 16
9.1. Controller Initiates . . . . . . . . . . . . . . . . . 16
9.2. Party A Initiates. . . . . . . . . . . . . . . . . . . 18
10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21
10.1. Click-to-Dial. . . . . . . . . . . . . . . . . . . . . 21
10.2. Mid-Call Announcement Capability . . . . . . . . . . . 23
11. Implementation Recommendations . . . . . . . . . . . . . . . 25
12. Security Considerations. . . . . . . . . . . . . . . . . . . 26
12.1. Authorization and Authentication . . . . . . . . . . . 26
12.2. End-to-End Encryption and Integrity. . . . . . . . . . 27
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . 29
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
16. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
9. 第三者呼び出しコントロールとSDP前提条件. . . . . . . 16 9.1。 コントローラは.169.2を開始します。 パーティA開始。 . . . . . . . . . . . . . . . . . . 18 10. 例の呼び出し流れ. . . . . . . . . . . . . . . . . . . . . 21 10.1。 ダイヤルにクリックしてください。 . . . . . . . . . . . . . . . . . . . . 21 10.2. 中間の呼び出し発表能力. . . . . . . . . . . 23 11。 実現推薦. . . . . . . . . . . . . . . 25 12。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . 26 12.1. 認可と認証. . . . . . . . . . . 26 12.2。 終端間暗号化と保全。 . . . . . . . . . 27 13. 承認. . . . . . . . . . . . . . . . . . . . . . 28 14。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 28 14.1。 引用規格. . . . . . . . . . . . . . . . . 28 14.2。 有益な参照. . . . . . . . . . . . . . . . 29 15。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 30 16。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 31
1. Introduction
1. 序論
In the traditional telephony context, third party call control allows one entity (which we call the controller) to set up and manage a communications relationship between two or more other parties. Third party call control (referred to as 3pcc) is often used for operator services (where an operator creates a call that connects two participants together) and conferencing.
伝統的な電話背景では、第三者呼び出しコントロールで、1つの実体(私たちがコントローラを呼ぶ)が、2人以上の相手の間のコミュニケーション関係をセットアップして、管理します。 第三者呼び出しコントロール(3pccと呼ばれる)はオペレータサービス(オペレータが2人の関係者に一緒に接する呼び出しを作成するところ)と会議にしばしば使用されます。
Similarly, many SIP services are possible through third party call control. These include the traditional ones on the PSTN, but also new ones such as click-to-dial. Click-to-dial allows a user to click on a web page when they wish to speak to a customer service representative. The web server then creates a call between the user and a customer service representative. The call can be between two phones, a phone and an IP host, or two IP hosts.
同様に、多くのSIPサービスが第三者呼び出しコントロールで可能です。 これらはダイヤルするクリックなどのPSTNの、しかし、新しいも1つの伝統的なものを含んでいます。 彼らがお客様相談窓口と話したがっているとき、ダイヤルするクリックで、ユーザはウェブページをクリックできます。 そして、ウェブサーバーはユーザとお客様相談窓口の間で呼び出しを作成します。 2個の電話か電話とIPホストか、2人のIPホストの間には、呼び出しがあることができます。
Third party call control is possible using only the mechanisms specified within RFC 3261 [1]. Indeed, many different call flows are possible, each of which will work with SIP compliant user agents. However, there are benefits and drawbacks to each of these flows. The usage of third party call control also becomes more complex when aspects of the call utilize SIP extensions or optional features of SIP. In particular, the usage of RFC 3312 [2] (used for coupling of signaling to resource reservation) with third party call control is non-trivial, and is discussed in Section 9. Similarly, the usage of early media (where session data is exchanged before the call is accepted) with third party call control is not trivial; both of them specify the way in which user agents generate and respond to SDP, and it is not clear how to do both at the same time. This is discussed further in Section 8.
第三者呼び出しコントロールは、RFC3261[1]の中で指定されたメカニズムだけを使用することで可能です。 本当に、流れがそれぞれ可能であるというそれの異なった要求がSIP対応することのユーザエージェントと共に働いている多く。 しかしながら、それぞれのこれらの流れへの利益と欠点があります。 また、呼び出しの局面がSIPに関するSIP拡張子かオプション機能を利用するとき、第三者呼び出しコントロールの使用法は、より複雑になります。 第三者呼び出しコントロールがあるRFC3312[2](資源予約に合図するカップリングのために、使用される)の用法について、特に、重要であり、セクション9で議論します。 同様に、第三者呼び出しコントロールがある早めのメディア(呼び出しを受け入れる前にそこでセッションデータを交換する)の使用法は些細ではありません。 それらの両方がユーザエージェントがSDPに発生して、反応させる入口を指定します、そして、ともに同時にどのようにするかは明確ではありません。 セクション8で、より詳しくこれについて議論します。
Rosenberg, et al. Best Current Practice [Page 2] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[2ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
This document serves as a best current practice for implementing third party call control without usage of any extensions specifically designed for that purpose. Section 4 presents the known call flows that can be used to achieve third party call control, and provides guidelines on their usage. Section 9 discusses the interactions of RFC 3312 [2] with third party call control. Section 8 discusses the interactions of early media with third party call control. Section 10 provides example applications that make usage of the flows recommended here.
このドキュメントは明確にそのために設計されたどんな拡大の用法なしでも第三者呼び出しコントロールを実行するための最も良い現在の習慣として機能します。 セクション4は、第三者呼び出しコントロールを達成するのに使用できる知られている呼び出し流れを提示して、それらの用法に関するガイドラインを提供します。 セクション9は第三者呼び出しコントロールとのRFC3312[2]の相互作用について論じます。 セクション8は第三者呼び出しコントロールとの早めのメディアの相互作用について論じます。 セクション10はここのお勧めの流れの用法を作る例の利用を提供します。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[3]について説明して、対応する実現のために要件レベルを示すとき解釈されることであるべきですか?
3. Definitions
3. 定義
The following terms are used throughout this document:
次の用語はこのドキュメント中で使用されます:
3pcc: Third Party Call Control, which refers to the general ability
to manipulate calls between other parties.
3pcc: 第3パーティCall Control、どれが操る一般的な能力について言及するかは相手の間に呼びます。
Controller: A controller is a SIP User Agent that wishes to create a
session between two other user agents.
コントローラ: コントローラは他の2人のユーザエージェントの間のセッションを作成したがっているSIP Userエージェントです。
4. 3pcc Call Establishment
4. 3pcc呼び出し設立
The primary primitive operation of third party call control is the establishment of a session between participants A and B. Establishment of this session is orchestrated by a third party, referred to as the controller.
第三者呼び出しコントロールの第一の原始の操作は関係者Aの間のセッションの設立です、そして、このセッションのB.特権階級はコントローラに差し向けられた第三者によって調整されます。
This section documents three call flows that the controller can utilize in order to provide this primitive operation.
このセクションはコントローラがこの原始の操作を提供するのに利用できる3回の呼び出し流れを記録します。
Rosenberg, et al. Best Current Practice [Page 3] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[3ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
4.1. Flow I
4.1. 流れI
A Controller B
|(1) INVITE no SDP | |
|<------------------| |
|(2) 200 offer1 | |
|------------------>| |
| |(3) INVITE offer1 |
| |------------------>|
| |(4) 200 OK answer1 |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) ACK answer1 | |
|<------------------| |
|(7) RTP | |
|.......................................|
コントローラB|(1) INVITEノーSDP| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(2) 200 offer1| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(3) INVITE offer1| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(4) 200 OK answer1| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(5) ACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(6) ACK answer1| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(7) RTP| | |.......................................|
Figure 1
図1
The call flow for Flow I is shown in Figure 1. The controller first sends an INVITE A (1). This INVITE has no session description. A's phone rings, and A answers. This results in a 200 OK (2) that contains an offer [4]. The controller needs to send its answer in the ACK, as mandated by [1]. To obtain the answer, it sends the offer it got from A (offer1) in an INVITE to B (3). B's phone rings. When B answers, the 200 OK (4) contains the answer to this offer, answer1. The controller sends an ACK to B (5), and then passes answer1 to A in an ACK sent to it (6). Because the offer was generated by A, and the answer generated by B, the actual media session is between A and B. Therefore, media flows between them (7).
私が図1で見せられるFlowのための呼び出し流動。 コントローラは最初に、INVITE A(1)を送ります。 このINVITEには、セッション記述が全くありません。 Aの電話リング、およびAに答えます。 これは申し出[4]を含む200OK(2)をもたらします。 コントローラは、[1]によって強制されるようにACKで答えを送る必要があります。 答えを得るために、それはINVITEのA(offer1)からB(3)まで得た申し出を送ります。 ビーズはリングに電話をします。 Bに答えるとき、200OK(4)はこの申し出、answer1の答えを含んでいます。 コントローラはB(5)にACKを送ります、そして、次に、ACKのAへのパスanswer1は(6)をそれに送りました。 申し出がA、およびBで発生する答えで発生したので、したがって、AとB.の間には、実際のメディアセッションがあって、それらの間のメディア流れは(7)です。
This flow is simple, requires no manipulation of the SDP by the controller, and works for any media types supported by both endpoints. However, it has a serious timeout problem. User B may not answer the call immediately. The result is that the controller cannot send the ACK to A right away. This causes A to retransmit the 200 OK response periodically. As specified in RFC 3261 Section 13.3.1.4, the 200 OK will be retransmitted for 64*T1 seconds. If an ACK does not arrive by then, the call is considered to have failed. This limits the applicability of this flow to scenarios where the controller knows that B will answer the INVITE immediately.
この流れは、簡単であり、コントローラでSDPの操作を全く必要としないで、両方の終点によって支持されたどんなメディアタイプのためにも働いています。 しかしながら、それには、重大なタイムアウト問題があります。 ユーザBはすぐに、電話口に出ないかもしれません。 結果はコントローラがすぐACKをAに送ることができないということです。 これで、Aは定期的に200OK応答を再送します。 RFC3261セクション13.3.1で指定されるように、.4、200OKは64*T1秒の間、再送されるでしょう。 ACKがその時までに到着しないなら、呼び出しが失敗したと考えられます。 これはこの流れの適用性をコントローラが、BがすぐにINVITEに答えるのを知っているシナリオに制限します。
Rosenberg, et al. Best Current Practice [Page 4] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[4ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
4.2. Flow II
4.2. 流れII
A Controller B
|(1) INVITE bh sdp1 | |
|<------------------| |
|(2) 200 sdp2 | |
|------------------>| |
| |(3) INVITE sdp2 |
| |------------------>|
|(4) ACK | |
|<------------------| |
| |(5) 200 OK sdp3 |
| |<------------------|
| |(6) ACK |
| |------------------>|
|(7) INVITE sdp3 | |
|<------------------| |
|(8) 200 OK sdp2 | |
|------------------>| |
|(9) ACK | |
|<------------------| |
|(10) RTP | |
|.......................................|
コントローラB|(1) INVITE bh sdp1| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(2) 200 sdp2| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(3) INVITE sdp2| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(4) ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(5) 200 OK sdp3| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(6) ACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(7) INVITE sdp3| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(8) 200 OK sdp2| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(9) ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(10) RTP| | |.......................................|
Figure 2
図2
An alternative flow, Flow II, is shown in Figure 2. The controller first sends an INVITE to user A (1). This is a standard INVITE, containing an offer (sdp1) with a single audio media line, one codec, a random port number (but not zero), and a connection address of 0.0.0.0. This creates an initial media stream that is "black holed", since no media (or RTCP packets [8]) will flow from A. The INVITE causes A's phone to ring.
代替の流れ(Flow II)は図2に示されます。 コントローラは最初に、ユーザA(1)にINVITEを送ります。 これは標準のINVITEです、0.0のただ一つのオーディオメディア線による申し出(sdp1)、1つのコーデック、無作為のポートナンバー(しかし、ゼロでない)、および接続アドレスを含んでいて。.0 .0。 これは初期のメディアの流れを作成します、すなわち、「黒は掘りました」、どんなメディア以来も、そうしません。(または、[8])が鳴らすためにA. INVITE原因Aの電話から流れるRTCPパケット。
Note that the usage of 0.0.0.0, though recommended by RFC 3264,
has numerous drawbacks. It is anticipated that a future
specification will recommend usage of a domain within the .invalid
DNS top level domain instead of the 0.0.0.0 IP address. As a
result, implementors are encouraged to track such developments
once they arise.
それに注意してください、用法、0.0 .0 .0 RFC3264によって推薦されますが、多数の欠点を持っています。 将来の仕様が0.0の代わりに.invalid DNSトップ・レベル・ドメインの中のドメインの用法に.0.0IPアドレスを推薦すると予期されます。 その結果、いったん起こると作成者がそのような開発を追跡するよう奨励されます。
When A answers (2), the 200 OK contains an answer, sdp2, with a valid address in the connection line. The controller sends an ACK (4). It then generates a second INVITE (3). This INVITE is addressed to user B, and it contains sdp2 as the offer to B. Note that the role of sdp2 has changed. In the 200 OK (message 2), it was an answer, but in the INVITE, it is an offer. Fortunately, all valid answers are valid
Aが(2)に答えるとき、200OKは有効なアドレスで接続線に答え、sdp2を含んでいます。 コントローラはACK(4)を送ります。 そして、それは第2のINVITE(3)を発生させます。 このINVITEはユーザBに記述されます、そして、それは申し出としてsdp2の役割が変えたB.Noteにsdp2を含んでいます。 200OK(メッセージ2)では、答えでしたが、INVITEでは、それは申し出です。 幸い、すべての有効な答えが有効です。
Rosenberg, et al. Best Current Practice [Page 5] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[5ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
initial offers. This INVITE causes B's phone to ring. When it answers, it generates a 200 OK (5) with an answer, sdp3. The controller then generates an ACK (6). Next, it sends a re-INVITE to A (7) containing sdp3 as the offer. Once again, there has been a reversal of roles. sdp3 was an answer, and now it is an offer. Fortunately, an answer to an answer recast as an offer is, in turn, a valid offer. This re-INVITE generates a 200 OK (8) with sdp2, assuming that A doesn't decide to change any aspects of the session as a result of this re-INVITE. This 200 OK is ACKed (9), and then media can flow from A to B. Media from B to A could already start flowing once message 5 was sent.
申し出に頭文字をつけてください。 このINVITEはビーズ電話を鳴らせます。 答えるとき、それは答え、sdp3で200OK(5)を発生させます。 そして、コントローラはACK(6)を発生させます。 次に、それは申し出としてsdp3を含むA(7)に再INVITEを送ります。 もう一度、役割の逆転がありました。sdp3は答えでした、そして、現在、それは申し出です。 幸い、答えの答えは、申し出が順番に有効な申し出であるので、書き直します。 この再INVITEはsdp2で200OK(8)を発生させます、Aが、この再INVITEの結果、セッションのどんな局面も変えると決めないと仮定して。 この200OKはACKed(9)です、そして、次に、メディアはAからBからAまでのメディアが既にいったんメッセージ5を送ると流れ始めることができたB.まで流れることができます。
This flow has the advantage that all final responses are immediately ACKed. It therefore does not suffer from the timeout and message inefficiency problems of flow 1. However, it too has troubles. First off, it requires that the controller know the media types to be used for the call (since it must generate a "blackhole" SDP, which requires media lines). Secondly, the first INVITE to A (1) contains media with a 0.0.0.0 connection address. The controller expects that the response contains a valid, non-zero connection address for A. However, experience has shown that many UAs respond to an offer of a 0.0.0.0 connection address with an answer containing a 0.0.0.0 connection address. The offer-answer specification [4] explicitly tells implementors not to do this, but at the time of publication of this document, many implementations still did. If A should respond with a 0.0.0.0 connection address in sdp2, the flow will not work.
この流れには、すぐに、すべての最終的な応答がそうである利点があります。ACKed。 したがって、それは流れ1のタイムアウトとメッセージ非能率問題に苦しみません。 しかしながら、それも苦労します。 まず最初に、オフです、呼び出しに使用されるのがコントローラがメディアタイプを知っているのを必要とします("blackhole"SDPを発生させなければならないので)。SDPはメディア線を必要とします。 第二に、A(1)への最初のINVITEは0.0.0.0接続アドレスがあるメディアを含んでいます。 コントローラは、応答がA.Howeverのための有効な非ゼロ接続アドレスを含むと予想して、経験は、多くのUAsが答えが0.0.0.0接続アドレスを含んでいる0.0.0.0接続アドレスの申し出に応じるのを示しました。 申し出答え仕様[4]は、これをしないように明らかに作成者に言いますが、このドキュメントの公表時点で、多くの実現がまだしていました。 0.0.0.0接続アドレスがsdp2にある状態でAが応じると、流れは働かないでしょう。
However, the most serious flaw in this flow is the assumption that the 200 OK to the re-INVITE (message 8) contains the same SDP as in message 2. This may not be the case. If it is not, the controller needs to re-INVITE B with that SDP (say, sdp4), which may result in getting a different SDP, sdp5, in the 200 OK from B. Then, the controller needs to re-INVITE A again, and so on. The result is an infinite loop of re-INVITEs. It is possible to break this cycle by having very smart UAs which can return the same SDP whenever possible, or really smart controllers that can analyze the SDP to determine if a re-INVITE is really needed. However, we wish to keep this mechanism simple, and avoid SDP awareness in the controller. As a result, this flow is not really workable. It is therefore NOT RECOMMENDED.
しかしながら、この流れにおける最も多くの重大な欠陥が再INVITE(メッセージ8)への200OKがメッセージ2に同じSDPを含む仮定です。 これはそうでないかもしれません。 それがそうでないなら、異なったSDPを手に入れるのに結果になるかもしれないそのSDP(たとえば、sdp4)がある再INVITE Bへのコントローラの必要性(sdp5)はB.Then、コントローラから再び、などに再INVITE Aに必要性を200で承認します。 結果は再INVITEsの無限ループです。 このサイクルに再INVITEが本当に必要であるかどうか決定するためにSDPを分析できる可能であるときはいつも、同じSDPを返すことができる非常に賢いUAsを持っているか、または本当に賢いコントローラで壊れるのは可能です。 しかしながら、このメカニズムを簡単に保って、コントローラでSDP認識を避けたいと思います。 その結果、この流れは本当に実行可能ではありません。 したがって、それはNOT RECOMMENDEDです。
Rosenberg, et al. Best Current Practice [Page 6] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[6ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
4.3. Flow III
4.3. 流れIII
A Controller B
|(1) INVITE no SDP | |
|<---------------------| |
|(2) 200 offer1 | |
|--------------------->| |
|(3) ACK answer1 (bh) | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 200 OK offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
| |(8) ACK answer2 |
| |--------------------->|
|(9) ACK | |
|<---------------------| |
|(10) RTP | |
|.............................................|
コントローラB|(1) INVITEノーSDP| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(2) 200 offer1| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(3) ACK answer1(bh)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(4) INVITEノーSDP| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(5) 200 OK offer2| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(6) 'INVITE offer2'| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(7) '200answer2'| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(8) ACK answer2| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(9) ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(10) RTP| | |.............................................|
Figure 3
図3
A third flow, Flow III, is shown in Figure 3.
3番目の流れ(Flow III)は図3に示されます。
First, the controller sends an INVITE (1) to user A without any SDP (which is good, since it means that the controller doesn't need to assume anything about the media composition of the session). A's phone rings. When A answers, a 200 OK is generated (2) containing its offer, offer1. The controller generates an immediate ACK containing an answer (3). This answer is a "black hole" SDP, with its connection address equal to 0.0.0.0.
まず最初に、コントローラは少しもSDP(コントローラがセッションのメディア構成に関して何も仮定する必要はないことを意味するので、良い)なしでINVITE(1)をユーザAに送ります。 Aの電話は鳴ります。 Aに答えるとき、(2) 申し出、offer1を含んでいて、200OKは発生します。 コントローラは答え(3)を含む即座のACKを発生させます。 この解答は.0に0.0への接続アドレス同輩がいるSDP「ブラックホール」.0です。
The controller then sends an INVITE to B without SDP (4). This causes B's phone to ring. When they answer, a 200 OK is sent, containing their offer, offer2 (5). This SDP is used to create a re-INVITE back to A (6). That re-INVITE is based on offer2, but may need to be reorganized to match up media lines, or to trim media lines. For example, if offer1 contained an audio and a video line, in that order, but offer2 contained just an audio line, the controller would need to add a video line to the offer (setting its port to zero) to create offer2'. Since this is a re-INVITE, it should complete quickly in the general case. That's good, since user B is retransmitting their 200 OK, waiting for an ACK. The SDP in the
そしてコントローラはSDP(4)なしでINVITEをBに送ります。 これで、ビーズ電話は鳴ります。 彼らが答えるとき、彼らの申し出、offer2(5)を含んでいて、200OKを送ります。 このSDPは、再INVITEをA(6)に作成して戻すのに使用されます。 メディア線を合わせるか、またはメディア線を整えるために再編成されるのが必要であるかもしれないのを除いて、その再INVITEはoffer2に基づいています。 '例えば、offer1がそのオーダーにオーディオとビデオ線を含みましたが、offer2がまさしく音声回線を含んでいるなら、コントローラは、offer2を作成するという申し出(ゼロにポートを設定する)にビデオ線を加える必要があるでしょうに'。 これが再INVITEであるので、それは司令官ですぐにケースを終了するべきです。 ACKを待って、ユーザBがそれらの200OKを再送しているので、それは良いです。 中のSDP
Rosenberg, et al. Best Current Practice [Page 7] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[7ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
200 OK (7) from A, answer2', may also need to be reorganized or trimmed before sending it an the ACK to B (8) as answer2. Finally, an ACK is sent to A (9), and then media can flow.
また、'200はAからの(7)を承認します、answer2'は、ACKをそれに送る前にanswer2としてB(8)に再編成されるか、または整えられる必要があるかもしれません。 最終的に、A(9)にACKを送ります、そして、次に、メディアは流れることができます。
This flow has many benefits. First, it will usually operate without any spurious retransmissions or timeouts (although this may still happen if a re-INVITE is not responded to quickly). Secondly, it does not require the controller to guess the media that will be used by the participants.
この流れには、多くの利益があります。 まず最初に、通常、それは少しも偽物の「再-トランスミッション」やタイムアウトなしで作動するでしょう(すばやく再INVITEに応じないなら、これがまだ起こっているかもしれませんが)。 第二に、関係者によって使用されるメディアを推測するのがコントローラを必要としません。
There are some drawbacks. The controller does need to perform SDP manipulations. Specifically, it must take some SDP, and generate another SDP which has the same media composition, but has connection addresses equal to 0.0.0.0. This is needed for message 3. Secondly, it may need to reorder and trim SDP X, so that its media lines match up with those in some other SDP, Y. Thirdly, the offer from B (offer2) may have no codecs or media streams in common with the offer from A (offer 1). The controller will need to detect this condition, and terminate the call. Finally, the flow is far more complicated than the simple and elegant Flow I (Figure 1).
いくつかの欠点があります。 コントローラは、SDP操作を実行する必要があります。 明確に、それは、いくらかのSDPを取って、.0に同じメディア構成を持っていますが、接続アドレスが.0を0.0との等しさにする別のSDPを発生させなければなりません。 これがメッセージ3に必要です。 第二に、追加注文とトリムにSDP Xを必要とするかもしれません、メディア線がある他のSDPでそれらに合うように、Y.。Thirdly、B(offer2)からの申し出には、Aからの申し出と共用してどんなコーデックもメディアの流れもないかもしれません(1を提供してください)。 コントローラは、この状態を検出して、呼び出しを終える必要があるでしょう。 最終的に、流れは簡単で上品なFlowよりはるかに複雑な私(図1)です。
4.4. Flow IV
4.4. 流れIV
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 200 OK offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
| |(8) ACK answer2 |
| |--------------------->|
|(9) ACK | |
|<---------------------| |
|(10) RTP | |
|.............................................|
コントローラB|(1) INVITE offer1| | |メディアがありません。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(2) 200 answer1| | |メディアがありません。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(3) ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(4) INVITEノーSDP| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(5) 200 OK offer2| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(6) 'INVITE offer2'| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(7) '200answer2'| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(8) ACK answer2| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(9) ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(10) RTP| | |.............................................|
Figure 4
図4
Rosenberg, et al. Best Current Practice [Page 8] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[8ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
Flow IV shows a variation on Flow III that reduces its complexity. The actual message flow is identical, but the SDP placement and construction differs. The initial INVITE (1) contains SDP with no media at all, meaning that there are no m lines. This is valid, and implies that the media makeup of the session will be established later through a re-INVITE [4]. Once the INVITE is received, user A is alerted. When they answer the call, the 200 OK (2) has an answer with no media either. This is acknowledged by the controller (3). The flow from this point onwards is identical to Flow III. However, the manipulations required to convert offer2 to offer2', and answer2' to answer2, are much simpler. Indeed, no media manipulations are needed at all. The only change that is needed is to modify the origin lines, so that the origin line in offer2' is valid based on the value in offer1 (validity requires that the version increments by one, and that the other parameters remain unchanged).
流れIVは複雑さを減少させるFlow IIIの変化を示しています。 実際のメッセージ流動は同じですが、SDPプレースメントと工事は異なります。 初期のINVITE(1)は全くメディアなしでSDPを含んでいて、あることを意味して、mは全く立ち並んでいません。 これは、有効であり、セッションのメディア構成が後で再INVITE[4]を通して確立されるのを含意します。 INVITEがいったん受け取られているようになると、ユーザAは警告されます。 彼らが電話口に出るとき、200OK(2)には、答えがメディアなしであります。 これはコントローラ(3)によって承認されます。 このポイントからの流れは前方へそうです。Flow IIIと同じです。 'しかしながら、offer2と、'answer2'へのoffer2をanswer2に変換するのに必要である操作ははるかに簡単です。 本当に、メディア操作は全く必要ではありません。 '必要である唯一の変化が起源線を変更することになっています、起源がoffer2に立ち並ぶように'はそうです。offer1(正当性は変わりがない状態でそれをバージョンが1つ増加して、もう片方のパラメタが残っている必要とする)の値に基づいて、有効です。
There are some limitations associated with this flow. First, user A will be alerted without any media having been established yet. This means that user A will not be able to reject or accept the call based on its media composition. Secondly, both A and B will end up answering the call (i.e., generating a 200 OK) before it is known whether there is compatible media. If there is no media in common, the call can be terminated later with a BYE. However, the users will have already been alerted, resulting in user annoyance and possibly resulting in billing events.
この流れに関連しているいくつかの制限があります。 まず最初に、ユーザAはまだ確立されている少しもメディアなしで警告されるでしょう。 これは、ユーザAがメディア構成に基づく呼び出しを拒絶できませんし、受け入れることができないことを意味します。 第二に、コンパチブルメディアがあるかどうかが知られている前にAとBの両方が結局、電話口に出るでしょう(すなわち、200OKを発生させます)。 メディアが全く一般的になければ、後でBYEと共に呼び出しを終えることができます。 しかしながら、ユーザいらだちをもたらして、ことによると支払いイベントをもたらして、ユーザは既に警告されてしまうでしょう。
5. Recommendations
5. 推薦
Flow I (Figure 1) represents the simplest and the most efficient flow. This flow SHOULD be used by a controller if it knows with certainty that user B is actually an automata that will answer the call immediately. This is the case for devices such as media servers, conferencing servers, and messaging servers, for example. Since we expect a great deal of third party call control to be to automata, special casing in this scenario is reasonable.
流れI(図1)は最も簡単で最も効率的な流れを表します。 この流れSHOULD、ユーザBが実際にそうであるという確実性で望んでいるオートマトンがすぐに電話口に出るのを知っているなら、コントローラによって使用されてください。 これは例えば、メディアサーバや、会議サーバや、メッセージングサーバなどの装置のためのそうです。 私たちが、オートマトンには大きな第三者呼び出しコントロールがあると予想するので、このシナリオの特別なケーシングは妥当です。
For calls to unknown entities, or to entities known to represent people, it is RECOMMENDED that Flow IV (Figure 4) be used for third party call control. Flow III MAY be used instead, but it provides no additional benefits over Flow IV. However, Flow II SHOULD NOT be used, because of the potential for infinite ping-ponging of re- INVITEs.
未知の存在、または、人々の代理をするのが知られている実体への呼び出しのために、Flow IV(図4)が第三者呼び出しコントロールに使用されるのは、RECOMMENDEDです。 流れIIIは代わりに使用されるかもしれませんが、それはFlow IVの上に付加的な利益を全く供給しません。 しかしながら、Flow II SHOULD NOT、再INVITEsの無限のピング悪臭の可能性のために、使用されてください。
Several of these flows use a "black hole" connection address of 0.0.0.0. This is an IPv4 address with the property that packets sent to it will never leave the host which sent them; they are just
これらの流れの数個が.0に接続が記述する0.0の「ブラックホール」.0を使用します。 これによるパケットがそれに送った資産があるIPv4アドレスがホストを決して置き去りにしないということです(それらを送りました)。 それらは正当です。
Rosenberg, et al. Best Current Practice [Page 9] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[9ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
discarded. Those flows are therefore specific to IPv4. For other network or address types, an address with an equivalent property SHOULD be used.
捨てられる。 したがって、それらの流れはIPv4に特定です。 他のネットワークかアドレスタイプ、同等な特性のSHOULDとのアドレスには、使用されてください。
In most cases, including the recommended flows, user A will hear silence while the call to B completes. This may not always be ideal. It can be remedied by connecting the caller to a music-on-hold source while the call to B occurs.
多くの場合お勧めの流れ、Aが呼び出しである間の沈黙を聞くユーザをBが完成する含んでいること。 これはいつも理想的であるかもしれないというわけではありません。 Bへの呼び出しが起こっている間、保持に関する音楽ソースに訪問者を接続することによって、それを治すことができます。
6. Error Handling
6. エラー処理
There are numerous error cases which merit discussion.
議論に値する多数の誤り事件があります。
With all of the call flows in Section 4, one call is established to A, and then the controller attempts to establish a call to B. However, this call attempt may fail, for any number of reasons. User B might be busy (resulting in a 486 response to the INVITE), there may not be any media in common, the request may time out, and so on. If the call attempt to B should fail, it is RECOMMENDED that the controller send a BYE to A. This BYE SHOULD include a Reason header [5] which carries the status code from the error response. This will inform A of the precise reason for the failure. The information is important from a user interface perspective. For example, if A was calling from a black phone, and B generated a 486, the BYE will contain a Reason code of 486, and this could be used to generate a local busy signal so that A knows that B is busy.
セクション4の呼び出し流れのすべてで、1つの呼び出しがAに確立されます、そして、次に、コントローラは、B.Howeverに呼び出しを確立するのを試みます、そして、この呼び出し試みは失敗するかもしれません、いろいろな理由で。 ユーザBが忙しいかもしれない(INVITEへの486応答をもたらして)、どんなメディアも一般的にないかもしれなくて、要求はタイムアウトなどがそうするかもしれません。 Bへの試みは呼び出しであるなら失敗するべきであり、コントローラがBYEをA.に送るのは、RECOMMENDEDです。This BYE SHOULDは誤り応答からステータスコードを運ぶReasonヘッダー[5]を含んでいます。 これは失敗の正確な理由のAを知らせるでしょう。 情報はユーザーインタフェース見解から重要です。 例えば、Aが黒い電話から呼んでいて、Bが486を発生させたなら、BYEが486のReasonコードを含んで、地方の話中音を発生させるのにこれは使用できたので、Aは、Bが忙しいのを知っています。
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 180 |
| |<---------------------|
|(6) INVITE offer2 | |
|--------------------->| |
|(7) 491 | |
|<---------------------| |
|(8) ACK | |
|--------------------->| |
コントローラB|(1) INVITE offer1| | |メディアがありません。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(2) 200 answer1| | |メディアがありません。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(3) ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(4) INVITEノーSDP| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(5) 180 | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(6) INVITE offer2| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(7) 491 | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(8) ACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|
Figure 5
図5
Rosenberg, et al. Best Current Practice [Page 10] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[10ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
Another error condition worth discussion is shown in Figure 5. After the controller establishes the dialog with A (messages 1-3) it attempts to contact B (message 4). Contacting B may take some time. During that interval, A could possibly attempt a re-INVITE, providing an updated offer. However, the controller cannot pass this offer on to B, since it has an INVITE transaction pending with it. As a result, the controller needs to reject the request. It is RECOMMENDED that a 491 response be used. The situation here is similar to the glare condition described in [1], and thus the same error handling is sensible. However, A is likely to retry its request (as a result of the 491), and this may occur before the exchange with B is completed. In that case, the controller would respond with another 491.
議論の価値がある別のエラー条件は図5に示されます。 コントローラがA(メッセージ1-3)と共に対話を確立した後に、それは、B(メッセージ4)に連絡するのを試みます。 Bに連絡するのはある程度時間がかかるかもしれません。 その間隔の間、アップデートされた申し出を提供して、Aは再INVITEを試みることができました。 しかしながら、それにはそれで未定のINVITE取引があるので、コントローラはこの申し出をBに通過できません。 その結果、コントローラは、要求を拒絶する必要があります。 491応答が使用されるのは、RECOMMENDEDです。 ここの状況は[1]で説明されたギラギラと眩しい光状態と同様です、そして、その結果、同じエラー処理は賢明です。 しかしながら、Aは要求(491の結果、)を再試行しそうです、そして、Bとの交換が終了する前にこれは起こるかもしれません。 その場合、コントローラは別の491で応じるでしょう。
7. Continued Processing
7. 継続的な処理
Once the calls are established, both participants believe they are in a single point-to-point call. However, they are exchanging media directly with each other, rather than with the controller. The controller is involved in two dialogs, yet sees no media.
呼び出しがいったん確立されると、両方の関係者は、彼らがただ一つの二地点間呼び出しでいると信じています。 しかしながら、彼らはコントローラと共にというよりむしろ直接互いと共にメディアを交換しています。 コントローラは、2つの対話にかかわりますが、メディアを全く見ません。
Since the controller is still a central point for signaling, it now has complete control over the call. If it receives a BYE from one of the participants, it can create a new BYE and hang up with the other participant. This is shown in Figure 6.
それでも、コントローラがシグナリングのための主要なポイントであるので、それには、現在、呼び出しの完全なコントロールがあります。 関係者のひとりから不戦勝を得るなら、それは、新しいBYEを作成して、もう片方の関係者と共にハングアップできます。 これは図6に示されます。
A Controller B
|(1) BYE | |
|------------------>| |
|(2) 200 OK | |
|<------------------| |
| |(3) BYE |
| |------------------>|
| |(4) 200 OK |
| |<------------------|
コントローラB|(1) さようなら| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(2) 200 OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(3) さようなら| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(4) 200 OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|
Figure 6
図6
Similarly, if it receives a re-INVITE from one of the participants, it can forward it to the other participant. Depending on which flow was used, this may require some manipulation on the SDP before passing it on.
同様に、関係者のひとりから再INVITEを受けるなら、それはもう片方の関係者にそれを送ることができます。 どの流れが使用されたかによって、それを伝える前に、これはSDPにおける何らかの操作を必要とするかもしれません。
However, the controller need not "proxy" the SIP messages received from one of the parties. Since it is a Back-to-Back User Agent (B2BUA), it can invoke any signaling mechanism on each dialog, as it sees fit. For example, if the controller receives a BYE from A, it can generate a new INVITE to a third party, C, and connect B to that
しかしながら、コントローラはSIPメッセージがパーティーのひとりから受けたどんな「プロキシ」も必要としません。 Backから後部へのUserエージェント(B2BUA)であるので、各対話のどんなシグナル伝達機構も呼び出すことができます、適していると決めるように。 例えば、コントローラがAから不戦勝を得るなら、それは、第三者への新しいINVITE、Cを発生させて、Bをそれに接続できます。
Rosenberg, et al. Best Current Practice [Page 11] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[11ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
participant instead. A call flow for this is shown in Figure 7, assuming the case where C represents an end user, not an automata. Note that it is just Flow IV.
代わりに関係者。 これのための呼び出し流動は図7に示されます、Cがオートマトンではなく、エンドユーザの代理をするケースを仮定して。 それがただFlow IVであることに注意してください。
A Controller B C
|(1) BYE | | |
|--------------->| | |
|(2) 200 OK | | |
|<---------------| | |
| |(3) INV no media| |
| |-------------------------------->|
| |(4) 200 no media| |
| |<--------------------------------|
| |(5) ACK | |
| |-------------------------------->|
| |(6) INV no SDP | |
| |--------------->| |
| |(7) 200 offer3 | |
| |<---------------| |
| |(8) INV offer3' | |
| |-------------------------------->|
| |(9) 200 answer3'| |
| |<--------------------------------|
| |(10) ACK | |
| |-------------------------------->|
| |(11) ACK answer3| |
| |--------------->| |
| | |(12) RTP |
| | |................|
コントローラB C|(1) さようなら| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(2) 200 OK| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| |(3) INVはメディアではありません。| | | |-------------------------------->| | |(4) 200 メディアがありません。| | | |<--------------------------------| | |(5) ACK| | | |-------------------------------->| | |(6) INVノーSDP| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(7) 200 offer3| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(8) 'INV offer3'| | | |-------------------------------->| | |(9) '200answer3'| | | |<--------------------------------| | |(10) ACK| | | |-------------------------------->| | |(11) ACK answer3| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(12) RTP| | | |................|
Figure 7
図7
From here, new parties can be added, removed, transferred, and so on, as the controller sees fit. In many cases, the controller will be required to modify the SDP exchanged between the participants in order to affect these changes. In particular, the version number in the SDP will need to be changed by the controller in certain cases. If the controller should issue an SDP offer on its own (for example, to place a call on hold), it will need to increment the version number in the SDP offer. The other participant in the call will not know that the controller has done this, and any subsequent offer it generates will have the wrong version number as far as its peer is concerned. As a result, the controller will be required to modify the version number in SDP messages to match what the recipient is expecting.
ここから、コントローラが適していると決めるように、新しいパーティーは、加えられて、取り除かれて、わたって、とても進行中である場合があります。 多くの場合、コントローラはこれらの変化に影響するように関係者の間で交換されたSDPを変更しなければならないでしょう。 特に、SDPのバージョン番号は、ある場合には、コントローラによって変えられる必要があるでしょう。 コントローラがそれ自身のところ(例えば電話を保持にする)でSDP申し出を発行すると、それは、SDP申し出におけるバージョン番号を増加する必要があるでしょう。 呼び出しのもう片方の関係者は、コントローラがこれをしたのを知らないでしょう、そして、同輩に関する限り、それが発生させるどんなその後の申し出も間違ったバージョン番号を持つでしょう。 その結果、コントローラは受取人が予想していることを合わせるSDPメッセージのバージョン番号を変更しなければならないでしょう。
Rosenberg, et al. Best Current Practice [Page 12] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[12ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
It is important to point out that the call need not have been established by the controller in order for the processing of this section to be used. Rather, the controller could have acted as a B2BUA during a call established by A towards B (or vice versa).
呼び出しがこのセクションの処理が使用されるためにコントローラによって確立される必要はなかったと指摘するのは重要です。 むしろ、呼び出しの間のB2BUAがAでB(逆もまた同様である)に向かって設立したようにコントローラは行動したかもしれません。
8. 3pcc and Early Media
8. 3pccと早めのメディア
Early media represents the condition where the session is established (as a result of the completion of an offer/answer exchange), yet the call itself has not been accepted. This is usually used to convey tones or announcements regarding progress of the call. Handling of early media in a third party call is straightforward.
早めのメディアはセッションが確立されて(申し出/答え交換の完成の結果、)、しかし、呼び出し自体が受け入れられていない状態を表します。 通常、これは、呼び出しの進歩に関してトーンか発表を伝えるのに使用されます。 第三者呼び出しにおける早めのメディアの取り扱いは簡単です。
Rosenberg, et al. Best Current Practice [Page 13] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[13ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
A Controller B
| | |
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
| | |
|<ring> | |
| | |
|<answer> | |
| | |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| | |<ring>
| |(5) 183 offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
|(8) ACK | |
|<---------------------| |
| |(9) PRACK answer2 |
| |--------------------->|
| |(10) 200 PRACK |
| |<---------------------|
|(11) RTP | |
|.............................................|
| | |<answer>
| |(12) 200 OK |
| |<---------------------|
| |(13) ACK |
| |--------------------->|
コントローラB| | | |(1) INVITE offer1| | |メディアがありません。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| |<リング>。| | | | | |<答え>。| | | | | |(2) 200 answer1| | |メディアがありません。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(3) ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(4) INVITEノーSDP| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |<リング>。| |(5) 183 offer2| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(6) 'INVITE offer2'| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(7) '200answer2'| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(8) ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(9) PRACK answer2| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(10) 200 PRACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(11) RTP| | |.............................................| | | |<答え>。| |(12) 200 OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(13) ACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|
Figure 8
エイト環
Figure 8 shows the case where user B generates early media before answering the call. The flow is almost identical to Flow IV from Figure 4. The only difference is that user B generates a reliable provisional response (5) [6] instead of a final response, and answer2 is carried in a PRACK (9) instead of an ACK. When party B finally does accept the call (12), there is no change in the session state, and therefore, no signaling needs to be done with user A. The controller simply ACKs the 200 OK (13) to confirm the dialog.
エイト環は、ユーザBが電話口に出る前にどこで早めのメディアを作るかをケースに示します。 流れは図4からのFlow IVとほとんど同じです。 唯一の違いはユーザBが最終的な応答の代わりに信頼できる暫定的な応答(5)[6]を発生させるということです、そして、answer2はACKの代わりにPRACK(9)で運ばれます。 パーティーBが最終的に呼び出し(12)を受け入れるとき、変化が全くセッション状態にありません、そして、したがって、合図はユーザA.と共にする必要がありません。対話を確認する単にコントローラACKs200OK(13)。
Rosenberg, et al. Best Current Practice [Page 14] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[14ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
A Controller B
| | |
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
| | |
|ring | |
| | |
|(2) 183 answer1 | |
|no media | |
|--------------------->| |
|(3) PRACK | |
|<---------------------| |
|(4) 200 PRACK | |
|--------------------->| |
| |(5) INVITE no SDP |
| |--------------------->|
| | |ring
| | |
| | |answer
| | |
| |(6) 200 OK offer2 |
| |<---------------------|
|(7) UPDATE offer2' | |
|<---------------------| |
| | |
|(8) 200 answer2' | |
|--------------------->| |
| |(9) ACK answer2 |
| |--------------------->|
|(10) RTP | |
|.............................................|
| | |
|answer | |
| | |
|(11) 200 OK | |
|--------------------->| |
|(12) ACK | |
|<---------------------| |
コントローラB| | | |(1) INVITE offer1| | |メディアがありません。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| |リング| | | | | |(2) 183 answer1| | |メディアがありません。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(3) PRACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(4) 200 PRACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(5) INVITEノーSDP| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |リング| | | | | |答え| | | | |(6) 200 OK offer2| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(7) 'UPDATE offer2'| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| |(8) '200answer2'| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(9) ACK answer2| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(10) RTP| | |.............................................| | | | |答え| | | | | |(11) 200 OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(12) ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure 9
図9
The case where user A generates early media is more complicated, and is shown in Figure 9. The flow is based on Flow IV. The controller sends an INVITE to user A (1), with an offer containing no media streams. User A generates a reliable provisional response (2) containing an answer with no media streams. The controller PRACKs this provisional response (3). Now, the controller sends an INVITE
ユーザAが早めのメディアを作るケースは、より複雑であり、図9で見せられます。 流れはFlow IVに基づいています。 コントローラはユーザA(1)(申し出が流れユーザAが作らないメディアを全く含んでいるメディアの流れなしで答えを含む信頼できる暫定的な応答(2))コントローラPRACKsへのこの暫定的な応答(3)をINVITEに送ります。 今、コントローラはINVITEを送ります。
Rosenberg, et al. Best Current Practice [Page 15] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[15ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
without SDP to user B (5). User B's phone rings, and they answer, resulting in a 200 OK (6) with an offer, offer2. The controller now needs to update the session parameters with user A. However, since the call has not been answered, it cannot use a re-INVITE. Rather, it uses a SIP UPDATE request (7) [7], passing the offer (after modifying it to get the origin field correct). User A generates its answer in the 200 OK to the UPDATE (8). This answer is passed to user B in the ACK (9). When user A finally answers (11), there is no change in session state, so the controller simply ACKs the 200 OK (12).
ユーザB(5)へのSDPなしで。 ユーザビーズはリングに電話をします、そして、申し出、offer2で200OK(6)をもたらして、彼らは答えます。 コントローラは、現在ユーザA.Howeverと共にセッションパラメタをアップデートする必要があります、呼び出しが答えられていないのでそれは再INVITEを使用できません。 むしろ、SIP UPDATE要求(7)[7]を使用します、申し出(起源野原が正しくなるようにそれを変更した後の)を通過して。 ユーザAは200OKにおける答えをUPDATE(8)に発生させます。 この答えはACK(9)でユーザBに渡されます。 ユーザAが最終的に(11)に答えるとき、変化が全くセッション状態(単にそのように、コントローラACKs200OK(12))にありません。
Note that it is likely that there will be clipping of media in this call flow. User A is likely a PSTN gateway, and has generated a provisional response because of early media from the PSTN side. The PSTN will deliver this media even though the gateway does not have anywhere to send it, since the initial offer from the controller had no media streams. When user B answers, media can begin to flow. However, any media sent to the gateway from the PSTN up to that point will be lost.
この呼び出し流動にはメディアの切り取りがありそうに注意してください。 ユーザAは、ありそうなa PSTNゲートウェイであり、早めのメディアのためにPSTN側から暫定的な応答を発生させました。 ゲートウェイには、それを送る場所がありませんが、PSTNはこのメディアを渡すでしょう、コントローラからの初期の申し出にメディアの流れが全くなかったので。ユーザBが答えるとき、メディアは流れ始めることができます。 しかしながら、そのポイントまでのPSTNからのゲートウェイに送られたどんなメディアも失われるでしょう。
9. Third Party Call Control and SDP Preconditions
9. 第三者呼び出しコントロールとSDP前提条件
A SIP extension has been specified that allows for the coupling of signaling and resource reservation [2]. This specification relies on exchanges of session descriptions before completion of the call setup. These flows are initiated when certain SDP parameters are passed in the initial INVITE. As a result, the interaction of this mechanism with third party call control is not obvious, and worth detailing.
シグナリングと資源予約[2]のカップリングを考慮するSIP拡張子は指定されました。 この仕様は呼び出しセットアップの完成の前にセッション記述の交換に依存します。 あるSDPパラメタが初期のINVITEで通過されるとき、これらの流れは起こされます。 その結果、第三者呼び出しコントロールとのこのメカニズムの相互作用は、明白でなくて、詳しく述べる価値があります。
9.1. Controller Initiates
9.1. コントローラ開始
In one usage scenario, the controller wishes to make use of preconditions in order to avoid the call failure scenarios documented in Section 4.4. Specifically, the controller can use preconditions in order to guarantee that neither party is alerted unless there is a common set of media and codecs. It can also provide both parties with information on the media composition of the call before they decide to accept it.
1つの用法シナリオでは、コントローラは、セクション4.4に記録された呼び出し失敗シナリオを避けるのに前提条件を利用したがっています。 明確に、コントローラは、一般的なセットのメディアとコーデックがない場合どちらのパーティーも警告されないのを保証するのに前提条件を使用できます。 また、それを受け入れると決める前にそれは呼び出しのメディア構成の情報を双方に提供できます。
Rosenberg, et al. Best Current Practice [Page 16] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[16ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
User A Controller Customer Service
(User B)
| | |
|(1) INVITE no SDP | |
|require precon | |
|<------------------| |
|(2) 183 offer1 | |
|optional precon | |
|------------------>| |
| | |
| |(3) INVITE offer1 |
| |------------------>|
| | |
| | |
| | |<answer>
| |(4) 200 OK answer1 |
| |no precon |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) PRACK answer1 | |
|<------------------| |
|<ring> | |
| | |
|(7) 200 PRACK | |
|------------------>| |
|<answer> | |
| | |
|(8) 200 INVITE | |
|------------------>| |
|(9) ACK | |
|<------------------| |
コントローラ顧客がサービスを提供するユーザ(ユーザB)| | | |(1) INVITEノーSDP| | |preconを必要としてください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(2) 183 offer1| | |任意のprecon| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| |(3) INVITE offer1| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、| |<答え>。| |(4) 200 OK answer1| | |preconがありません。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(5) ACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(6) PRACK answer1| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |<リング>。| | | | | |(7) 200 PRACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |<答え>。| | | | | |(8) 200 招待| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(9) ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure 10
図10
The flow for this scenario is shown in Figure 10. In this example, we assume that user B is an automata or agent of some sort which will answer the call immediately. Therefore, the flow is based on Flow I. The controller sends an INVITE to user A containing no SDP, but with a Require header indicating that preconditions are required. This specific scenario (an INVITE without an offer, but with a Require header indicating preconditions) is not described in [2]. It is RECOMMENDED that the UAS respond with an offer in a 1xx including the media streams it wishes to use for the call, and for each, list all preconditions it supports as optional. Of course, the user is not alerted at this time. The controller takes this offer and passes it to user B (3). User B does not support preconditions, or does, but
このシナリオのための流れは図10に示されます。 この例では、私たちは、ユーザBがすぐに電話口に出るある種のオートマトンかエージェントであると思います。 したがって、流れはコントローラがSDPを全く含んでいませんが、Requireヘッダーと共に前提条件が必要であることを示すユーザAへのINVITEを送るFlow I.に基づいています。 この特定のシナリオ(申し出のはない、Requireヘッダーが前提条件を示しているINVITE)は[2]で説明されません。 UASが1xxのそれが呼び出しに使用したがっているメディアの流れを含んでいる申し出、およびそれぞれリストのためにそれが任意であるとして支持するすべての前提条件を反応させるのは、RECOMMENDEDです。 もちろん、ユーザはこのとき、警告されません。 コントローラは、この申し出を取って、ユーザB(3)にそれを通過します。 しかし、ユーザBは、前提条件を支持しないか、またはします。
Rosenberg, et al. Best Current Practice [Page 17] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[17ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
is not interested in them. Therefore, when it answers the call, the 200 OK contains an answer without any preconditions listed (4). This answer is passed to user A in the PRACK (6). At this point, user A knows that there are no preconditions actually in use for the call, and therefore, it can alert the user. When the call is answered, user A sends a 200 OK to the controller (8) and the call is complete.
それらに関心がありません。 したがって、少しも前提条件なしで含んでいるそれが呼び出し、200OKに答えに答えるいつが(4)を記載したか。 この答えはPRACK(6)でユーザAに渡されます。 ここに、ユーザAは、呼び出しには、実際に使用中のどんな前提条件もないのを知っています、そして、したがって、それはユーザを警告できます。 呼び出しが答えられるとき、ユーザAは200OKをコントローラ(8)に送ります、そして、呼び出しは完全です。
In the event that the offer generated by user A was not acceptable to user B (because of non-overlapping codecs or media, for example), user B would immediately reject the INVITE (message 3). The controller would then CANCEL the request to user A. In this situation, neither user A nor user B would have been alerted, achieving the desired effect. It is interesting to note that this property is achieved using preconditions even though it doesn't matter what specific types of preconditions are supported by user A.
ユーザB(例えば非重なっているコーデックかメディアのために)にとって、ユーザAによって発生した申し出が許容できない場合、ユーザBはすぐに、INVITE(メッセージ3)を拒絶するでしょうに。 コントローラがそしてそうするだろう、キャンセル、警告されて、期待される効果を発揮するユーザA.Inへのこの状況、どちらもユーザAかユーザBがそうする要求。 この特性がどんな特定のタイプの前提条件がユーザAによって支持されるかが重要ではありませんが、前提条件を使用することで獲得されることに注意するのはおもしろいです。
It is also entirely possible that user B does actually desire preconditions. In that case, it might generate a 1xx of its own with an answer containing preconditions. That answer would still be passed to user A, and both parties would proceed with whatever measures are necessary to meet the preconditions. Neither user would be alerted until the preconditions were met.
また、ユーザBが実際に願望前提条件をするのも、完全に可能です。 その場合、それは答えが前提条件を含んでいるそれ自身の1xxを発生させるかもしれません。 その答えはまだユーザAに渡されているでしょう、そして、双方はどんな前提条件を満たすのに必要な測定も続けるでしょう。 前提条件が満たされるまで、どちらのユーザも警告されないでしょう。
9.2. Party A Initiates
9.2. パーティは開始です。
In Section 9.1, the controller requested the use of preconditions to achieve a specific goal. It is also possible that the controller doesn't care (or perhaps doesn't even know) about preconditions, but one of the participants in the call does care. A call flow for this case is shown in Figure 11.
セクション9.1では、コントローラは、明確な目標を達成するよう前提条件の使用に要求しました。 また、コントローラが前提条件について気にかけないのも(または、恐らく、知ってさえいません)、可能ですが、呼び出しの関係者のひとりは気にかけます。 呼び出し流動はこのような場合図11に示されます。
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 183 answer1 | |
|no media | |
|--------------------->| |
|(3) PRACK | |
|<---------------------| |
|(4) 200 OK | |
|--------------------->| |
| |(5) INVITE no SDP |
| |--------------------->|
| |(6) 183 offer2 |
| |des=sendrecv |
| |conf=recv |
| |cur=none |
コントローラB|(1) INVITE offer1| | |メディアがありません。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(2) 183 answer1| | |メディアがありません。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(3) PRACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(4) 200 OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(5) INVITEノーSDP| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(6) 183 offer2| | |des=sendrecv| | |conf=recv| | |野良犬はなにもと等しくはありません。|
Rosenberg, et al. Best Current Practice [Page 18] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[18ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
| |<---------------------|
|(7) UPDATE offer2' | |
|des=sendrecv | |
|conf=recv | |
|cur=none | |
|<---------------------| |
|(8) 200 UPDATE | |
|answer2' | |
|des=sendrecv | |
|conf=recv | |
|cur=none | |
|--------------------->| |
| |(9) PRACK answer2 |
| |des=sendrecv |
| |conf=recv |
| |cur=none |
| |--------------------->|
| |(10) 200 PRACK |
| |<---------------------|
|(11) reservation | |
|-------------------------------------------->|
|(12) reservation | |
|<--------------------------------------------|
|(13) UPDATE offer3 | |
|des=sendrecv | |
|conf=recv | |
|cur=recv | |
|--------------------->| |
| |(14) UPDATE offer3' |
| |des=sendrecv |
| |conf=recv |
| |cur=recv |
| |--------------------->|
| |(15) 200 UPDATE |
| |answer3' |
| |des=sendrecv |
| |conf=recv |
| |cur=send |
| |<---------------------|
|(16) 200 UPDATE | |
|answer3 | |
|des=sendrecv | |
|conf=recv | |
|cur=send | |
|<---------------------| |
| | |<ring>
| |(17) UPDATE offer4 |
| |des=sendrecv |
| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(7) 'UPDATE offer2'| | |des=sendrecv| | |conf=recv| | |野良犬はなにもと等しくはありません。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(8) 200アップデート| | |'answer2'| | |des=sendrecv| | |conf=recv| | |野良犬はなにもと等しくはありません。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(9) PRACK answer2| | |des=sendrecv| | |conf=recv| | |野良犬はなにもと等しくはありません。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(10) 200 PRACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(11) 予約| | |-------------------------------------------->| |(12) 予約| | |<--------------------------------------------| |(13) UPDATE offer3| | |des=sendrecv| | |conf=recv| | |野良犬=recv| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(14) 'UPDATE offer3'| | |des=sendrecv| | |conf=recv| | |野良犬=recv| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(15) 200アップデート| | |'answer3'| | |des=sendrecv| | |conf=recv| | |野良犬=は発信します。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(16) 200アップデート| | |answer3| | |des=sendrecv| | |conf=recv| | |野良犬=は発信します。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| |<リング>。| |(17) UPDATE offer4| | |des=sendrecv|
Rosenberg, et al. Best Current Practice [Page 19] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[19ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
| |conf=recv |
| |cur=sendrecv |
| |<---------------------|
|(18) UPDATE offer4' | |
|des=sendrecv | |
|conf=recv | |
|cur=sendrecv | |
|<---------------------| |
|<ring> | |
|(19) 200 UPDATE | |
|answer4' | |
|des=sendrecv | |
|conf=recv | |
|cur=sendrecv | |
|--------------------->| |
| |(20) 200 UPDATE |
| |answer4 |
| |des=sendrecv |
| |conf=recv |
| |cur=sendrecv |
| |--------------------->|
|(21) 180 INVITE | |
|--------------------->| |
| |(22) 180 INVITE |
| |<---------------------|
|<answer> | |
|(23) 200 INVITE | |
|--------------------->| |
|(24) ACK | |
|<---------------------| |
| | |<answer>
| |(25) 200 INVITE |
| |<---------------------|
| |(26) ACK |
| |--------------------->|
| |conf=recv| | |野良犬=sendrecv| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(18) 'UPDATE offer4'| | |des=sendrecv| | |conf=recv| | |野良犬=sendrecv| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |<リング>。| | |(19) 200アップデート| | |'answer4'| | |des=sendrecv| | |conf=recv| | |野良犬=sendrecv| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(20) 200アップデート| | |answer4| | |des=sendrecv| | |conf=recv| | |野良犬=sendrecv| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(21) 180 招待| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(22) 180 招待| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |<答え>。| | |(23) 200 招待| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(24) ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| |<答え>。| |(25) 200 招待| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(26) ACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|
Figure 11
図11
The controller follows Flow IV; it has no specific requirements for support of the preconditions specification [2]. Therefore, it sends an INVITE (1) with SDP that contains no media lines. User A is interested in supporting preconditions, and does not want to ring its phone until resources are reserved. Since there are no media streams in the INVITE, it can't reserve resources for media streams, and therefore it can't ring the phone until they are conveyed in a subsequent offer and then reserved. Therefore, it generates a 183 with the answer, and doesn't alert the user (2). The controller PRACKs this (3) and A responds to the PRACK (4).
コントローラはFlow IVに続きます。 それには、前提条件仕様[2]のサポートのための決められた一定の要求が全くありません。 したがって、それはメディア線を全く含まないSDPと共にINVITE(1)を送ります。 ユーザAは、前提条件を支持するのに興味を持っていて、リソースが予約されるまで、電話を鳴らしたがっていません。 メディアの流れが全くINVITEにないので、メディアの流れのためのリソースを予約できないで、したがって、それらがその後の申し出で運ばれて、次に、予約されるまで、電話を鳴らすことができません。 したがって、それは、答えで183を発生させて、ユーザ(2)を警告しません。 コントローラPRACKsこの(3)とAはPRACK(4)に応じます。
Rosenberg, et al. Best Current Practice [Page 20] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[20ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
At this point, the controller attempts to bring B into the call. It sends B an INVITE without SDP (5). B is interested in having preconditions for this call. Therefore, it generates its offer in a 183 that contains the appropriate SDP attributes (6). The controller passes this offer to A in an UPDATE request (7). The controller uses UPDATE because the call has not been answered yet, and therefore, it cannot use a re-INVITE. User A sees that its peer is capable of supporting preconditions. Since it desires preconditions for the call, it generates an answer in the 200 OK (8) to the UPDATE. This answer, in turn, is passed to B in the PRACK for the provisional response (9). Now, both sides perform resource reservation. User A succeeds first, and passes an updated session description in an UPDATE request (13). The controller simply passes this to A (after the manipulation of the origin field, as required in Flow IV) in an UPDATE (14), and the answer (15) is passed back to A (16). The same flow happens, but from B to A, when B's reservation succeeds (17-20). Since the preconditions have been met, both sides ring (21 and 22), and then both answer (23 and 25), completing the call.
ここに、コントローラは、Bを呼び出しに運び込むのを試みます。 それはSDP(5)なしでINVITEをBに送ります。 Bはこの呼び出しのための前提条件が欲しいです。 したがって、それは183における適切なSDP属性(6)を含む申し出を発生させます。 コントローラはUPDATE要求(7)でこの申し出をAに通過します。 呼び出しがまだ答えられていないので、コントローラはUPDATEを使用します、そして、したがって、それは再INVITEを使用できません。 ユーザAは、同輩が前提条件を支持できるのがわかります。 呼び出しのために前提条件を望んでいて、それは200OK(8)で答えをUPDATEに発生させます。 この答えは暫定的な応答(9)のためにPRACKで順番にBに通過されます。 今、両側は資源予約を実行します。 ユーザAは、UPDATE要求(13)でアップデートされたセッション記述を最初に引き継いで、通過します。 コントローラは単にこれをAに通過します。(起源分野の操作の後に、必要に応じて、Flowでは、UPDATE(14)、および答え(15)のIV)はA(16)に戻されます。 同じ流れは起こりますが、ビーズであるときに、BからAまで、予約は(17-20)を引き継ぎます。 前提条件を満たしてあるので、両側は、(21と22)を鳴らして、次に、ともに(23と25)に答えます、呼び出しを終了して。
What is important about this flow is that the controller doesn't know anything about preconditions. It merely passes the SDP back and forth as needed. The trick is the usage of UPDATE and PRACK to pass the SDP when needed. That determination is made entirely based on the offer/answer rules described in [6] and [7], and is independent of preconditions.
この流れに関して重要なことはコントローラが前提条件に関して何も知らないということです。 それは必要に応じて単にSDPを前後に渡します。 必要であると、トリックはSDPを渡すUPDATEとPRACKの使用法です。 その決断は、完全に[6]と[7]で説明された申し出/答え規則に基づいて作られていて、前提条件から独立しています。
10. Example Call Flows
10. 例の呼び出し流れ
10.1. Click-to-Dial
10.1. ダイヤルするクリック
The first application of this capability we discuss is click-to-dial. In this service, a user is browsing the web page of an e-commerce site, and would like to speak to a customer service representative. The user clicks on a link, and a call is placed to a customer service representative. When the representative picks up, the phone on the user's desk rings. When the user pick up, the customer service representative is there, ready to talk to the user.
私たちが議論するこの能力の最初のアプリケーションはダイヤルするクリックです。 このサービスでは、ユーザは、電子商取引サイトのウェブページをブラウズしていて、お客様相談窓口と話したがっています。 ユーザはリンク先をクリックします、そして、電話はお客様相談窓口に出されます。 代表が回復すると、ユーザの机の上の電話は鳴ります。 ユーザの選択であるときに、上に、ユーザへの話にはお客様相談窓口がそこに準備しています。
Rosenberg, et al. Best Current Practice [Page 21] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[21ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
Customer Service Controller User's Phone User's Browser
| |(1) HTTP POST | |
| |<--------------------------------------|
| |(2) HTTP 200 OK | |
| |-------------------------------------->|
|(3) INVITE offer1 | | |
|no media | | |
|<------------------| | |
|(4) 200 answer1 | | |
|no media | | |
|------------------>| | |
|(5) ACK | | |
|<------------------| | |
| |(6) INVITE no SDP | |
| |------------------>| |
| |(7) 200 OK offer2 | |
| |<------------------| |
|(8) INVITE offer2' | | |
|<------------------| | |
|(9) 200 answer2' | | |
|------------------>| | |
| |(10) ACK answer2 | |
| |------------------>| |
|(11) ACK | | |
|<------------------| | |
|(12) RTP | | |
|.......................................| |
顧客サービスコントローラユーザの電話ユーザのブラウザ| |(1) HTTPポスト| | | |<--------------------------------------| | |(2) HTTP200OK| | | |-------------------------------------->| |(3) INVITE offer1| | | |メディアがありません。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(4) 200 answer1| | | |メディアがありません。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(5) ACK| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| |(6) INVITEノーSDP| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(7) 200 OK offer2| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(8) 'INVITE offer2'| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(9) '200answer2'| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(10) ACK answer2| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(11) ACK| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(12) RTP| | | |.......................................| |
Figure 12
図12
The call flow for this service is given in Figure 12. It is identical to that of Figure 4, with the exception that the service is triggered through an HTTP POST request when the user clicks on the link. Normally, this POST request would contain neither the number of the user or of the customer service representative. The user's number would typically be obtained by the web application from back- end databases, since the user would have presumably logged into the site, giving the server the needed context. The customer service number would typically be obtained through provisioning. Thus, the HTTP POST is actually providing the server nothing more than an indication that a call is desired.
図12でこのサービスのための呼び出し流動を与えます。 それが図4のものと同じである、例外で、ユーザであるときに、サービスがHTTPポストの要求で引き起こされるのがリンクをクリックします。 通常、このポストの要求はどちらもユーザかお客様相談窓口の数を含んでいないでしょう。 逆終わりのデータベースからのウェブアプリケーションでユーザの番号を通常得るでしょう、おそらく、ユーザはサイトにログインしたでしょう、したがって、必要な文脈をサーバに与えて。 食糧を供給することで顧客認識番号を通常得るでしょう。 したがって、HTTPポストは実際に、呼び出しが望まれているというただ指示をサーバに提供しています。
We note that this service can be provided through other mechanisms, namely PINT [9]. However, there are numerous differences between the way in which the service is provided by PINT, and the way in which it is provided here:
私たちは、すなわち、他のメカニズム、PINT[9]を通してこのサービスを提供できることに注意します。 しかしながら、サービスがPINTによって提供される方法と、それがここに提供される方法の間には、多数の違いがあります:
Rosenberg, et al. Best Current Practice [Page 22] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[22ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
o The PINT solution enables calls only between two PSTN endpoints.
The solution described here allows calls between PSTN phones
(through SIP enabled gateways) and native IP phones.
o 解決策が有効にするPINTは2つのPSTN終点だけの間に呼びます。 ここで説明された解決策はPSTN電話(SIPを通してゲートウェイを可能にする)とネイティブのIP電話の間の呼び出しを許します。
o When used for calls between two PSTN phones, the solution here may
result in a portion of the call being routed over the Internet.
In PINT, the call is always routed only over the PSTN. This may
result in better quality calls with the PINT solution, depending
on the codec in use and QoS capabilities of the network routing
the Internet portion of the call.
o PSTNが電話をする2の間の呼び出しに使用されると、ここの解決策はインターネットの上に発送される呼び出しの部分をもたらすかもしれません。 PINTでは、呼び出しはいつもPSTNだけの上に発送されます。 これはPINT解決策で、より良質の呼び出しをもたらすかもしれません、使用中のコーデックとネットワークが呼び出しのインターネット部分を発送するQoS能力によって。
o The PINT solution requires extensions to SIP (PINT is an extension
to SIP), whereas the solution described here is done with baseline
SIP.
o PINT解決策はSIPに拡大を必要としますが(PINTはSIPへの拡大です)、基線SIPと共にここで説明された解決策をします。
o The PINT solution allows the controller (acting as a PINT client)
to "step out" once the call is established. The solution
described here requires the controller to maintain call state for
the entire duration of the call.
o 呼び出しがいったん確立されると、PINT解決策は、コントローラ(PINTクライアントとして、機能する)が「威勢良く歩くこと」を許容します。 ここで説明された解決策は、コントローラが、全体のための状態を呼び出しの持続時間と呼ぶように主張するのを必要とします。
10.2. Mid-Call Announcement Capability
10.2. 中間の呼び出し発表能力
The third party call control mechanism described here can also be used to enable mid-call announcements. Consider a service for pre- paid calling cards. Once the pre-paid call is established, the system needs to set a timer to fire when they run out of minutes. When this timer fires, we would like the user to hear an announcement which tells them to enter a credit card to continue. Once they enter the credit card info, more money is added to the pre-paid card, and the user is reconnected to the destination party.
また、中間の呼び出し発表を可能にするのにここで説明された第三者呼び出し制御機構は使用できます。 あらかじめ支払われたテレホンカードのためのサービスを考えてください。 プレ料金発信人払通話がいったん確立されると、システムは、タイマに彼らが数分を使い果たすときには発火するように設定する必要があります。 このタイマが撃たれるとき、私たちは、ユーザに続くようにクレジットカードを入れるように彼らに言う発表を聞いて欲しいと思います。 彼らがいったんクレジットカードインフォメーションを入力すると、より多くのお金があらかじめ支払われたカードに加えられます、そして、ユーザは目的地パーティーに再接続されます。
We consider here the usage of third party call control just for playing the mid-call dialog to collect the credit card information.
私たちは、ここでただ集める中間の呼び出し対話をプレーするための第三者呼び出しコントロールの使用法がクレジットカード情報であると考えます。
Rosenberg, et al. Best Current Practice [Page 23] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[23ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
Pre-Paid User Controller Called Party Media Server
| |(1) INV SDP c=bh | |
| |------------------>| |
| |(2) 200 answer1 | |
| |<------------------| |
| |(3) ACK | |
| |------------------>| |
|(4) INV no SDP | | |
|<------------------| | |
|(5) 200 offer2 | | |
|------------------>| | |
| |(6) INV offer2 | |
| |-------------------------------------->|
| |(7) 200 answer2 | |
| |<--------------------------------------|
|(8) ACK answer2 | | |
|<------------------| | |
| |(9) ACK | |
| |-------------------------------------->|
|(10) RTP | | |
|...........................................................|
| |(11) BYE | |
| |-------------------------------------->|
| |(12) 200 OK | |
| |<--------------------------------------|
| |(13) INV no SDP | |
| |------------------>| |
| |(14) 200 offer3 | |
| |<------------------| |
|(15) INV offer3' | | |
|<------------------| | |
|(16) 200 answer3' | | |
|------------------>| | |
| |(17) ACK answer3' | |
| |------------------>| |
|(18) ACK | | |
|<------------------| | |
|(19) RTP | | |
|.......................................| |
あらかじめ支払われたユーザコントローラ被呼者メディアサーバ| |(1) INV SDP c=bh| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(2) 200 answer1| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(3) ACK| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(4) INVノーSDP| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(5) 200 offer2| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(6) INV offer2| | | |-------------------------------------->| | |(7) 200 answer2| | | |<--------------------------------------| |(8) ACK answer2| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| |(9) ACK| | | |-------------------------------------->| |(10) RTP| | | |...........................................................| | |(11) さようなら| | | |-------------------------------------->| | |(12) 200 OK| | | |<--------------------------------------| | |(13) INVノーSDP| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(14) 200 offer3| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(15) 'INV offer3'| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(16) '200answer3'| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(17) 'ACK answer3'| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(18) ACK| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(19) RTP| | | |.......................................| |
Figure 13
図13
We assume the call is set up so that the controller is in the call as a B2BUA. When the timer fires, we wish to connect the caller to a media server. The flow for this is shown in Figure 13. When the timer expires, the controller places the called party with a connection address of 0.0.0.0 (1). This effectively "disconnects" the called party. The controller then sends an INVITE without SDP to
私たちは、呼び出しがコントローラが呼び出しB2BUAとして中であるようにセットアップされると思います。 タイマが撃たれるとき、メディアサーバに訪問者を接続したいと思います。これのための流れは図13に示されます。 タイマが期限が切れると、コントローラは0.0.0.0(1)の接続アドレスに被呼者を任命します。 事実上、これは被呼者を「外します」。 その時がSDPのないINVITEを送るコントローラ
Rosenberg, et al. Best Current Practice [Page 24] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[24ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
the pre-paid caller (4). The offer returned from the caller (5) is used in an INVITE to the media server which will be collecting digits (6). This is an instantiation of Flow I. This flow can only be used here because the media server is an automata, and will answer the INVITE immediately. If the controller was connecting the pre-paid user with another end user, Flow III would need to be used. The media server returns an immediate 200 OK (7) with an answer, which is passed to the caller in an ACK (8). The result is that the media server and the pre-paid caller have their media streams connected.
あらかじめ支払われた訪問者(4)。 訪問者(5)から返された申し出はメディアサーバへのケタ(6)を集めるINVITEで使用されます。 これは、メディアサーバがオートマトンであるのでここでFlow I.This流動の具体化を使用できるだけであるということであり、すぐに、INVITEに答えるでしょう。 コントローラがあらかじめ支払われたユーザに別のエンドユーザに接しているなら、Flow IIIは、使用される必要があるでしょうに。 メディアサーバは答えと共に即座の200OK(7)を返します。(それは、ACK(8)の訪問者に渡されます)。 結果はメディアサーバとあらかじめ支払われた訪問者が彼らのメディアの流れを接続させるということです。
The media server plays an announcement, and prompts the user to enter a credit card number. After collecting the number, the card number is validated. The media server then passes the card number to the controller (using some means outside the scope of this specification), and then hangs up the call (11).
メディアサーバは、発表をプレーして、ユーザがクレジットカード番号を入れるようにうながします。 数を集めた後に、カードナンバーは有効にされます。 次に、メディアサーバは、呼び出し(11)でコントローラ(この仕様の範囲の外のいくつかの手段を使用する)へのカードナンバーを通過して、次に、ハングを通過します。
After hanging up with the media server, the controller reconnects the user to the original called party. To do this, the controller sends an INVITE without SDP to the called party (13). The 200 OK (14) contains an offer, offer3. The controller modifies the SDP (as is done in Flow III), and passes the offer in an INVITE to the pre-paid user (15). The pre-paid user generates an answer in a 200 OK (16) which the controller passes to user B in the ACK (17). At this point, the caller and called party are reconnected.
メディアサーバでハングアップした後に、コントローラはオリジナルの被呼者にユーザを再接続します。 これをするために、コントローラはSDPなしで被呼者(13)にINVITEを送ります。 200OK(14)は申し出、offer3を含んでいます。 コントローラは、SDP(Flow IIIでするように)を変更して、INVITEであらかじめ支払われたユーザ(15)に申し出を渡します。 あらかじめ支払われたユーザはコントローラがACK(17)でユーザBに渡す200OK(16)で答えを発生させます。 ここに、訪問者と被呼者は再接続されます。
11. Implementation Recommendations
11. 実現推薦
Most of the work involved in supporting third party call control is within the controller. A standard SIP UA should be controllable using the mechanisms described here. However, third party call control relies on a few features that might not be implemented. As such, we RECOMMEND that implementors of user agent servers support the following:
コントローラの中に第三者呼び出しコントロールを支持するのにかかわる仕事の大部分があります。 標準のSIP UAはここで説明されたメカニズムを使用するのにおいて制御可能であるべきです。 しかしながら、第三者呼び出しコントロールは実行されないかもしれないいくつかの特徴を当てにします。 そういうものとして私たち、RECOMMEND、ユーザエージェントサーバの作成者は以下を支持します:
o Offers and answers that contain a connection line with an address
of 0.0.0.0.
o 接続を含む申し出と答えが0.0のアドレスで.0を.0に裏打ちします。
o Re-INVITE requests that change the port to which media should be
sent
o メディアが送られるべきであるポートを変える再INVITE要求
o Re-INVITEs that change the connection address
o 接続アドレスを変える再INVITEs
o Re-INVITEs that add a media stream
o メディアの流れを加える再INVITEs
o Re-INVITEs that remove a media stream (setting its port to zero)
o メディアの流れを取り除く再INVITEs(ゼロにポートを設定します)
o Re-INVITEs that add a codec amongst the set in a media stream
o セットの中でメディアの流れでコーデックを加える再INVITEs
Rosenberg, et al. Best Current Practice [Page 25] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[25ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
o SDP Connection address of zero
o ゼロのSDP Connectionアドレス
o Initial INVITE requests with a connection address of zero
o ゼロの接続アドレスによる初期のINVITE要求
o Initial INVITE requests with no SDP
o SDPのない初期のINVITE要求
o Initial INVITE requests with SDP but no media lines
o SDPとの初期のINVITE要求にもかかわらず、メディア線がありません。
o Re-INVITEs with no SDP
o SDPのない再INVITEs
o The UPDATE method [7]
o UPDATE方法[7]
o Reliability of provisional responses [6]
o 暫定的な応答の信頼性[6]
o Integration of resource management and SIP [2].
o 資源管理とSIP[2]の統合。
12. Security Considerations
12. セキュリティ問題
12.1. Authorization and Authentication
12.1. 認可と認証
In most uses of SIP INVITE, whether or not a call is accepted is based on a decision made by a human when presented information about the call, such as the identity of the caller. In other cases, automata answer the calls, and whether or not they do so may depend on the particular application to which SIP is applied. For example, if a caller makes a SIP call to a voice portal service, the call may be rejected unless the caller has previously signed up (perhaps via a web site). In other cases, call handling policies are made based on automated scripts, such as those described by the Call Processing Language [11]. Frequently, those decisions are also made based on the identity of the caller.
SIP INVITEのほとんどの用途で、呼び出しを受け入れるかどうかが訪問者のアイデンティティなどの呼び出しの情報が提示されるとき人間によってされた決定に基づいています。 他の場合では、オートマトンは電話口に出ます、そして、それらがそうするかどうかがSIPが適用されている特定用途によるかもしれません。 例えば、訪問者がボイス・ポータルサービスにSIP電話をかけて、訪問者が以前に申し込みをしていない場合(恐らくウェブサイトを通って)、呼び出しは拒絶されるかもしれません。 他の場合では、Call Processing Language[11]によって説明されたものなどの自動化スクリプトに基づいて呼び出し取り扱い方針は作られています。 また、訪問者のアイデンティティに基づいて頻繁に、それらの決定をします。
These authorization mechanisms would be applied to normal first party calls and third party calls, as these two are indistinguishable. As a result, it is important for these authorization policies to continue to operate correctly for third party calls. Of course, third party calls introduce a new party - the one initiating the third party call. Do the authorization policies apply based on the identity of that third party, or do they apply based on the participants in the call? Ideally, the participants would be able to know the identities of both other parties, and have authorization policies be based on those, as appropriate. However, this is not possible using existing mechanisms. As a result, the next best thing is for the INVITE requests to contain the identity of the third party. Ultimately, this is the user who is requesting communication, and it makes sense for call authorization policies to be based on that identity.
これらの2が区別がつかないときに、これらの認可メカニズムは通常の最初のパーティー呼び出しと第三者呼び出しに適用されるでしょう。 その結果、これらの認可方針が、第三者呼び出しのために正しく作動し続けているのは、重要です。 もちろん、第三者呼び出しは新しいパーティーを紹介します--第三者呼び出しを開始するもの。 認可方針がその第三者のアイデンティティに基づいて適用されますか、またはそれらは呼び出しの関係者に基づいて適用しますか? 理想的に、関係者は、両方の相手のアイデンティティを知って、認可方針をそれらに基礎づけさせることができるでしょう、適宜。 しかしながら、これは、既存のメカニズムを使用することで可能ではありません。その結果、次善の策は第三者のアイデンティティを含むというINVITE要求のためのものです。 結局、これはコミュニケーションを要求しているユーザです、そして、呼び出し認可方針のために、そのアイデンティティに基づくのは理解できます。
Rosenberg, et al. Best Current Practice [Page 26] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[26ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
This requires, in turn, that the controller authenticate itself as that third party. This can be challenging, and the appropriate mechanism depends on the specific application scenario.
これは、コントローラがその第三者としてそれ自体を認証するのを順番に必要とします。 これはやりがいがある場合があります、そして、適切な手段は特定のアプリケーションシナリオによります。
In one common scenario, the controller is acting on behalf of one of the participants in the call. A typical example is click-to-dial, where the controller and the customer service representative are run by the same administrative domain. Indeed, for the purposes of identification, the controller can legitimately claim to be the customer service representative. In this scenario, it would be appropriate for the INVITE to the end user to contain a From field identifying the customer service rep, and authenticate the request using S/MIME (see RFC 3261 [1], Section 23) signed by the key of the customer service rep (which is held by the controller).
1つの共通したシナリオでは、コントローラは呼び出しの関係者のひとりを代表して行動しています。 典型的な例はコントローラとお客様相談窓口が同じ管理ドメインによって車で送られるところのダイヤルするクリックです。 本当に、識別の目的のために、コントローラはお客様相談窓口であると合法的に主張できます。 このシナリオでは、エンドユーザへのINVITEが顧客サービスレップを特定するFrom分野を含んで、顧客サービスレップ(コントローラによって保持される)のキーによってサインされたS/MIME(RFC3261[1]を見てください、セクション23)を使用する要求を認証するのは、適切でしょう。
This requires the controller to actually have credentials with which it can authenticate itself as the customer support representative. In many other cases, the controller is representing one of the participants, but does not possess their credentials. Unfortunately, there are currently no standardized mechanisms that allow a user to delegate credentials to the controller in a way that limits their usage to specific third party call control operations. In the absence of such a mechanisms, the best that can be done is to use the display name in the From field to indicate the identity of the user on whose behalf the call is being made. It is RECOMMENDED that the display name be set to "[controller] on behalf of [user]", where user and controller are textual identities of the user and controller, respectively. In this case, the URI in the From field would identify the controller.
これは、コントローラにはそれが顧客サポート代表としてそれ自体を認証できる信任状が実際にあるのを必要とします。 他の多くの場合では、コントローラは、関係者のひとりを表していますが、彼らの信任状を持っていません。 残念ながら、ユーザがそれらの用法を特定の第三者呼び出し制御機能に制限する方法で信任状をコントローラへ代表として派遣することができる現在標準化されなかったメカニズムがあります。 そのようなメカニズムがないとき、尽くすことができるベストはだれの代理に電話をかけるかに関してユーザのアイデンティティを示すのにFrom分野で表示名を使用することです。 存在という表示名がユーザとコントローラがユーザとコントローラの原文のアイデンティティである「[ユーザ]を代表した[コントローラ]」にセットしたのは、それぞれRECOMMENDEDです。 この場合、From分野のURIはコントローラを特定するでしょう。
In other situations, there is no real relationship between the controller and the participants in the call. In these situations, ideally the controller would have a means to assert that the call is from a particular identity (which could be one of the participants, or even a third party, depending on the application), and to validate that assertion with a signature using the key of the controller.
他の状況に、呼び出しのコントローラと関係者とのどんな本当の関係もありません。 これらの状況で、理想的に、コントローラは、コントローラのキーを使用することで呼び出しが特定のアイデンティティ(アプリケーションによって、関係者のひとり、または第三者でさえあるかもしれない)から来ていると断言して、署名でその主張を有効にする手段を持っているでしょう。
12.2. End-to-End Encryption and Integrity
12.2. 終端間暗号化と保全
With third party call control, the controller is actually one of the participants as far as the SIP dialog is concerned. Therefore, encryption and integrity of the SIP messages, as provided by S/MIME, will occur between participants and the controller, rather than directly between participants.
第三者呼び出しコントロールで、SIP対話に関する限り、コントローラは実際に関係者のひとりです。 したがって、SIPメッセージの暗号化と保全はS/MIMEで提供するように関係者と関係者の直接間でというよりむしろコントローラの間に起こるでしょう。
However, integrity, authenticity and confidentiality of the media sessions can be provided through a controller. End-to-end media security is based on the exchange of keying material within SDP [10].
しかしながら、コントローラを通してメディアセッションの保全、信憑性、および秘密性を提供できます。 終わりから終わりへのメディアセキュリティはSDP[10]の中で合わせることの材料の交換に基づいています。
Rosenberg, et al. Best Current Practice [Page 27] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[27ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
The proper operation of these mechanisms with third party call control depends on the controller behaving properly. So long as it is not attempting to explicitly disable these mechanisms, the protocols will properly operate between the participants, resulting in a secure media session that even the controller cannot eavesdrop or modify. Since third party call control is based on a model of trust between the users and the controller, it is reasonable to assume it is operating in a well-behaved manner. However, there is no cryptographic means that can prevent the controller from interfering with the initial exchanges of keying materials. As a result, it is trivially possibly for the controller to insert itself as an intermediary on the media exchange, if it should so desire.
第三者呼び出しコントロールによるこれらのメカニズムの適切な操作は礼儀正しく振る舞うコントローラに頼っています。 明らかにこれらのメカニズムを無効にするのを試みていない限り、プロトコルは関係者の間で適切に作動するでしょう、コントローラさえ盗み聞くことができませんし、変更できない安全なメディアセッションのときになって。 第三者呼び出しコントロールがユーザとコントローラの間の信用のモデルに基づいているので、それが品行方正の態度で作動していると仮定するのは妥当です。 しかしながら、コントローラが合わせることの材料の初期の交換を妨げることができないどんな暗号の手段もありません。 その結果、ことによるとメディア交換のときに仲介者としてそれ自体を挿入するコントローラのために、些細なことに、それであるならそう望むべきであるということです。
13. Acknowledgements
13. 承認
The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric Rescorla, Allison Mankin and Sriram Parameswar for their comments.
作者は彼らのコメントについてポールKyzivat、Rohanマーイ、エリック・レスコラ、アリソン・マンキン、およびSriram Parameswarに感謝したがっています。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Camarillo, G., Ed., Marshall, W., Ed. and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[2] キャマリロ、G.(エド)とマーシャル、W.(エド)とJ.ローゼンバーグ、「資源管理とセッション開始プロトコル(一口)の統合」RFC3312(2002年10月)。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[5] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326,
December 2002.
[5]SchulzrinneとH.とオランとD.とG.キャマリロ、「セッション開始プロトコル(一口)のための理由ヘッダーフィールド」、RFC3326、2002年12月。
[6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[6] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
[7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[7] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデート方法」、RFC3311、2002年10月。
Rosenberg, et al. Best Current Practice [Page 28] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[28ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
14.2. Informative References
14.2. 有益な参照
[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[8]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、2003年7月。
[9] Petrack, S. and L. Conroy, "The PINT Service Protocol:
Extensions to SIP and SDP for IP Access to Telephone Call
Services", RFC 2848, June 2000.
[9] Petrack、S.、およびL.コンロイ、「パイントサービスは議定書を作ります」。 「通話サービスへのIPアクセスのための一口とSDPへの拡大」、RFC2848、2000年6月。
[10] Andreasen, F., Baugher, M. and D. Wing, "SDP Security
Descriptions for Media Streams", Work in Progress, October 2003.
[10] 「メディアの流れのためのSDPセキュリティ記述」というAndreasen、F.、Baugher、M.、およびD.翼は進歩、2003年10月に機能します。
[11] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for User
Control of Internet Telephony Services", Work in Progress,
August 2003.
[11] レノックス、J.、ウー、X.、およびH.Schulzrinne、「CPL:」 「インターネット電話サービスのユーザコントロールのための言語」、処理中の作業、2003年8月。
Rosenberg, et al. Best Current Practice [Page 29] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[29ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
15. Authors' Addresses
15. 作者のアドレス
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグdynamicsoft600Lanidex Plazaニュージャージー07054パーシッパニー(米国)
Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net
以下に電話をしてください。 +1 973 952-5000 メールしてください: jdrosen@dynamicsoft.com ユリ: http://www.jdrosen.net
Jon Peterson Neustar 1800 Sutter Street Suite 570 Concord, CA 94520 US
ジョンピーターソンNeustar1800サター通りスイート570一致、カリフォルニア94520米国
Phone: +1 925 363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz
以下に電話をしてください。 +1 925 363-8720 メールしてください: jon.peterson@neustar.biz ユリ: http://www.neustar.biz
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングSchulzrinneコロンビア大学M/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027米国
EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
メール: schulzrinne@cs.columbia.edu ユリ: http://www.cs.columbia.edu/~hgs
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Rosenberg, et al. Best Current Practice [Page 30] RFC 3725 SIP 3pcc April 2004
ローゼンバーグ、他 最も良い現在の習慣[30ページ]RFC3725は3pcc2004年4月にちびちび飲みます。
16. Full Copyright Statement
16. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg, et al. Best Current Practice [Page 31]
ローゼンバーグ、他 最も良い現在の習慣[31ページ]
一覧
スポンサーリンク
