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
Best Current Practices for Third Party Call Control (3pcc)
in the Session Initiation Protocol (SIP)
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
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.
サードパーティ呼制御通信が他の当事者の間で実際になっているコールを作成するために、一方のエンティティの能力を指します。サードパーティ呼制御セッション開始プロトコル（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
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
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.
従来の電話のコンテキストでは、第三者呼制御（我々はコントローラを呼び出す）一方のエンティティがセットアップされ、二つ以上の他のパーティとの間の通信関係を管理することを可能にします。 （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、だけでなく、新しいものに伝統的なものが挙げられます。クリックツーダイヤルで、彼らは顧客サービス担当者に話をしたいとき、ユーザは、Webページ上でクリックすることができます。 Webサーバは、ユーザと顧客サービス担当者との間の通話を作成します。コールは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.
サードパーティ呼制御[1] RFC 3261内で指定されたメカニズムのみを使用して可能です。実際、多くの異なるコールフローは、SIPに準拠したユーザエージェントと協力し、それぞれが、可能です。しかし、これらのフローのそれぞれに利点と欠点があります。コールの態様はSIPの拡張やSIPのオプション機能を利用する場合、サードパーティの呼制御の使用は、より複雑になります。具体的には、サードパーティ呼制御とRFC 3312の使用方法[2]（予約リソースへのシグナリングのカップリングに使用）は非自明であり、同様に、セクション9に記載されている、初期メディアの使用（セッションデータである場合コールが受け入れられる前に、サードパーティの呼制御で）交換は簡単ではありません。それらの両方は、ユーザエージェントが生成する方法を指定し、SDPへの対応、そして同時に両方を行う方法は明らかではありません。これは、8章で詳しく説明されています。
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は、第三者呼制御と[2] RFC 3312の相互作用を論じています。第8節は、第三者呼制御による早期メディアの相互作用について説明します。セクション10は、ここで推奨フローの使用を作るサンプルアプリケーションを提供します。
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"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119に記載されるように解釈されるべきである[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：他の当事者間でコールを操作する一般的な能力を指す第三者呼制御、。
Controller: A controller is a SIP User Agent that wishes to create a session between two other user agents.
コントローラ：コントローラは、2つの他のユーザエージェントとの間のセッションを作成したいSIPユーザエージェントです。
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つのコールは、コントローラが、この原始的な操作を提供するために利用することができるものと流れます。
A Controller B
|(1) INVITE no 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).
流れIのコールフローは、コントローラは、第一INVITEを送信する図1に示されている（1）。このINVITEにはセッション記述がありません。 Aの電話が鳴ると、Aの答え。これは、オファー[4]を含有する200 OK（2）になります。 [1]によって義務付けられ、コントローラは、ACKでその回答を送信する必要があります。その答えを得るためには、それはそれは中A（offer1）から得プランBにINVITEを送信する（3）。 Bの電話が鳴ります。 Bの答えは、200 OK（4）はこのオファー、ANSWER1への回答が含まれている場合。コントローラは、B（5）にACKを送信し、それに送られたACK内に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は、すぐにコールに応答しない場合があります。その結果、コントローラはすぐにAにACKを送信することができないということです。これは、定期的に200 OK応答を再送信するようになります。 RFC 3261のセクション13.3.1.4に規定されているように、200 OKは64 * T1秒のために再送信されます。 ACKは、それまでに到着しない場合、コールは失敗したと考えられています。これは、コントローラは、BはすぐにINVITEを答えることを知っているシナリオにこのフローの適用性を制限します。
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 | |
|.......................................|
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.
別のフロー、フローIIは、コントローラは、第1のユーザAにINVITEを送信する図2に示されている（1）。これは、単一の音声メディアライン、あるコーデック、ランダムなポート番号（しかしゼロでない）、および0.0.0.0の接続アドレスを提供（SDP1）を含む、INVITE標準です。これには、メディア（またはRTCPパケットが[8]）環せるAの電話をINVITE A.ザから流れないので、「黒穴あき」初期メディアストリームを生成します。
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の使用量は、RFC 3264で推奨されるものの、多くの欠点を持っていることに注意してください。将来の仕様が.invalid DNSトップレベルドメインの代わりに、0.0.0.0 IPアドレス内のドメインの使用をお勧めすることが予想されます。その結果、実装者は、それらが発生したら、このような動向を追跡することが奨励されています。
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 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.
ときの回答（2）、200 OKは、接続線で有効なアドレスで、答え、SDP2が含まれています。コントローラは、ACKを送信する（4）。これは、第2のINVITEを生成する（3）。これは、ユーザB宛てのINVITE、およびBにオファーがSDP2の役割が変化していることに注意してくださいと、それはSDP2が含まれています。 200 OK（メッセージ2）では、それが答えだったが、INVITEで、それが提供されます。幸いなことに、すべての有効な答えは、有効な初期の提供です。これは、リングに原因のBさんの携帯電話をINVITE。それが応答すると、それが答え、SDP3で200 OK（5）を生成します。次に、コントローラは、ACKを生成する（6）。次に、提供として（7）を含むSDP3に再INVITEを送信します。もう一度、役割の逆転がありました。 SDP3は答えた、と今ではオファーがあります。幸いなことに、申し出としてリキャスト答えへの答えは、順番に、有効なプランです。この再INVITE Aはこの再INVITEの結果として、セッションの任意の態様を変更することを決定しないと仮定すると、SDP2と（8）200 OKを生成します。この200 OK（9）ACKされ、その後培地は、メッセージ5を送信した後、既に流れ始める可能性がBからAへ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.
この流れは、すべての最終応答が即座にACKされるという利点があります。したがって、しかし、それはあまりにもトラブルがあり、フロー1のタイムアウトやメッセージの非効率性の問題に悩まされていません。最初のオフは、制御装置は、（それがメディア行を必要とする「ブラックホール」SDPを生成しなければならないので）コールのために使用されるメディアタイプを知ることが必要です。第二に、最初は、（1）0.0.0.0接続アドレスでメディアを含んにINVITE。コントローラは、応答がA.に有効な、非ゼロの接続アドレスが含まれていることを期待しかし、経験は、多くのUAは0.0.0.0接続アドレスを含む答えと0.0.0.0接続アドレスの提供に応じることが示されています。オファーアンサー仕様[4]は、明示的にこれを実行しないように実装を伝えますが、このドキュメントの発行時点で、多くの実装はまだなかったです。 AはSDP2で0.0.0.0接続アドレスで応答しなければならない場合、フローは動作しません。
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）に200 OKこれは当てはまらないことがあり、メッセージ2と同じSDPが含まれていることを前提とします。そうでない場合、コントローラは、次にBから200 OKに、異なるSDPの取得につながる可能性がある、そのSDPによる再INVITE B（例えば、sdp4）する必要sdp5、コントローラは、再招待する必要があります再び、というように。結果は、再のINVITEの無限ループです。本当に必要とされている再INVITEかどうかを判断するためにSDPを分析することができ、可能な限り同じSDPを返すことができ非常にスマートのUA、あるいは本当にスマートコントローラを持っていることによって、この悪循環を断ち切ることが可能です。しかし、我々は簡単なこのメカニズムを維持し、コントローラ内のSDPの意識を避けたいと思います。その結果、この流れは本当に実用的ではありません。したがって、お勧めしません。
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 | |
|.............................................|
Figure 3
図3
A third flow, Flow III, is shown in Figure 3.
第三の流れは、流れ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ことなく、ユーザA（1）INVITEを送信します。 Aの電話が鳴ります。答えは、200 OKが発生した場合（2）そのオファー、offer1を含みます。コントローラは、回答（3）を含有する即時ACKを生成します。この答えは、0.0.0.0に等しいその接続アドレスと、「ブラックホール」SDPです。
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）なしでBにINVITEを送信します。これは、リングにBの電話の原因となります。彼らは答えたとき、200 OKは彼らの申し出、offer2（5）を含む、送信されます。このSDPは、バック（6）に-INVITE再作成するために使用されます。その再INVITE offer2に基づいていますが、メディアラインを一致させるために再編成する必要があるかもしれない、またはメディアラインをトリミングします。 offer1がその順序でオーディオとビデオのラインを、含まれているが、ちょうどオーディオラインをoffer2含まれている場合たとえば、コントローラはoffer2' 作成するプラン（ゼロにそのポートを設定する）へのビデオの行を追加する必要があります。これがあるので、それは一般的なケースには迅速に完了する必要があり、再INVITE。ユーザBがACKを待って、彼らの200 OKを再送しているのでそれは、良いことです。でSDP
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.
（7）A、ANSWER2' から200 OKは、またANSWER2（8）BにACKを送信する前に、再編成またはトリミングする必要があるかもしれません。最後に、ACKは、（9）に送られ、次に媒体が流れることができます。
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を生成しなければなりません。そのメディア・ラインは、いくつかの他のSDPのものと一致し、Y.は第三に、B（offer2）からオファーがないコーデックやメディアを有していなくてもよいように、第二に、それは、SDP Xの順序を変更し、トリミングし、これは、メッセージ3のために必要とされる必要があるかもしれませんAからのオファー（オファー1）と共通するストリーム。コントローラは、この状態を検出し、通話を終了する必要があります。最後に、流れははるかに複雑シンプルでエレガントなフローI（図1）を超えています。
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 | |
|.............................................|
Figure 4
図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は、その複雑さを軽減フローIIIの変化を示しています。実際のメッセージ・フローは同じであるが、SDPの配置及び構成が異なります。最初は、INVITE（1）は、m個の行が存在しないことを意味し、全くメディアでSDPを含んでいます。これは有効であり、セッションのメディアメイク[4]再INVITEを通じて、後に確立されることを意味します。 INVITEを受信すると、利用者Aが警告されます。彼らはコールに応答すると、200 OK（2）がないか、メディアとの答えを持っています。これは、コントローラ（3）によって確認されます。この点からの流れは、以降のフローIIIと同一です。しかし、操作がANSWER2にoffer2' 、およびANSWER2' にoffer2変換するために必要な、非常に簡単です。確かに、何の情報操作は一切必要ありません。必要とされている唯一の変更は、元の行を変更することで、offer1の値に基づいて有効であるoffer2' の原点ラインように（妥当性はバージョンが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の両方は、互換性のあるメディアがあるかどうか知られている前に（すなわち、200 OKを生成する）コールに応答してしまいます。共通にはメディアが存在しない場合、呼び出しは、後にBYEで終了することができます。ただし、ユーザーがすでにユーザーの迷惑になると、おそらく課金イベントで、その結果、警告されています。
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）は、最も単純で最も効率的な流れを表します。それは、ユーザ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.
未知のエンティティへの、または人を表すことが知られているエンティティへのコールの場合、フローIV（図4）は、第三者呼制御のために使用することをお勧めします。フローIIIを用いてもよいが、それはフローIVを超える追加の利点を提供していません。しかし、フローIIは理由再のINVITEの無限ピンポンの可能性のため、使用されるべきではありません。
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 discarded. Those flows are therefore specific to IPv4. For other network or address types, an address with an equivalent property SHOULD be used.
これらのフローのいくつかは、0.0.0.0の「ブラックホール」の接続アドレスを使用します。これは、それに送られたパケットは、それらを送信したホストを離れることは決してありませんプロパティを持つIPv4アドレスです。彼らは単に破棄されます。これらの流れは、従って、IPv4のに特異的です。他のネットワークまたはアドレスタイプのために、同等の特性を有するアドレスが使用されるべきです。
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.
Bへの呼び出しが完了するまで推奨フローを含むほとんどのケースでは、利用者Aは沈黙を聞くことができます。これは、常に理想的ではないかもしれません。これは、Bへの呼び出しが行われている間の保留音のソースへの発信者を接続することによって改善することができます。
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に流れると、ある呼がAに確立され、その後、コントローラは、理由の任意の数のために、しかし、この呼び出しの試みが失敗する可能性がBに呼を確立しようと試みます。ユーザBは、（INVITEに対する486応答をもたらす）忙しいかもしれない、一般的に任意の媒体がないことが、要求はこれにタイムアウトとよいです。 Bへの呼び出しの試みが失敗した場合、コントローラがAにBYEを送信することが推奨される。このBYE [5]エラー応答からステータスコードを担持するReasonヘッダを含むべきです。これは、障害の正確な理由をお知らせします。情報は、ユーザーインターフェイスの観点から重要です。例えば、Aは、黒電話から発呼し、そしてBは486を生成した場合、BYEは486の理由コードを含むであろう、そして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 | |
|--------------------->| |
Figure 5
図5
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.
コントローラは、それがB（メッセージ4）に接触しようとする（メッセージ1-3）を用いてダイアログを確立した後に議論が図5に示されている価値は別のエラー条件。 Bを接触させることは、いくつかの時間がかかることがあります。その期間中、Aは、おそらく更新のオファーを提供し、再INVITEを試みることができます。それはそれで保留INVITEトランザクションを持っているので、コントローラは、Bの上でこのオファーを渡すことはできません。その結果、コントローラは、要求を拒否する必要があります。 491応答を使用することをお勧めします。ここでの状況は、[1]に記載のグレア条件と同様であるので、同じエラー処理が賢明です。ただし、Aは（491の結果として）、その要求を再試行する可能性があり、そしてBとの交換が完了する前に、これが起こり得ます。その場合には、コントローラは、別の491で応答することになります。
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を受信した場合、それは新しいBYEを作成し、他の参加者とハングアップすることができます。これは、図6に示されています。
A Controller B
|(1) BYE | |
|------------------>| |
|(2) 200 OK | |
|<------------------| |
| |(3) BYE |
| |------------------>|
| |(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 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.
ただし、コントローラは、「プロキシ」SIPメッセージは、当事者の一方から受信する必要はありません。それはバックツーバックユーザエージェント（B2BUA）であるので、それが適当と考えるよう、各ダイアログ上の任意のシグナリングメカニズムを呼び出すことができます。コントローラは、AからBYEを受信した場合、例えば、それは新しいを生成することができ、第三者、CにINVITEを、その代わりに、その参加者にBを接続します。このためのコールフローは、Cは、エンドユーザーではなく、オートマトンを表す場合を想定し、図7に示されています。それだけでフロー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 |
| | |................|
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メッセージ内にバージョン番号を変更する必要があります。
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).
呼び出しが使用されるためにこのセクションの処理のためにコントローラによって確立されている必要がないことを指摘することは重要です。むしろ、コントローラはBの方へ（またはその逆）によって確立された通話中B2BUAとして作用している可能性があります。
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.
アーリーメディアセッションが（オファー/アンサー交換の完了の結果として）確立され、まだコール自体は受け付けていない状態を表しています。これは通常、コールの進行状況に関するトーンまたはアナウンスを伝えるために使用されます。サードパーティのコールで初期メディアの扱いは簡単です。
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 |
| |--------------------->|
Figure 8
図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.
図8は、ユーザBが呼び出しに応答する前にアーリーメディアを生成する場合を示しています。フローは、代わりに、最終的な応答の[6]の唯一の違いは、ユーザBが信頼できる暫定的な応答を生成することである（5）図4からの流れIVとほぼ同一であり、そしてANSWER2（9）の代わりにACKのPRACKに運ばれます。パーティBが最後にコール（12）を受け入れない場合、セッションの状態に変化がないので、何のシグナリングは、コントローラは、単にダイアログを確認するために、200 OK（13）のACKユーザAで行われる必要がありません。
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 | |
|<---------------------| |
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 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).
ユーザAが初期メディアを生成する場合は、より複雑であり、フローはフローIVに基づいて、図9に示されています。コントローラには、メディアストリームを含まないオファーで、ユーザA（1）にINVITEを送信します。ユーザAは、（2）いいえメディアストリームとの回答を含む信頼できる暫定的な応答を生成します。コントローラPRACKsこの暫定応答（3）。次に、コントローラは、ユーザB（5）にSDPなしにINVITEを送信します。ユーザBの電話が鳴ると、彼らが提供、offer2と200 OK（6）が得られ、答えます。コントローラは現在、コールが応答されていないため、それは再INVITEを使用することはできません、しかし、ユーザAとのセッションパラメータを更新する必要があります。むしろ、それは（それが起点フィールドが正しい得るために変更した後）オファーを通過すると、SIP UPDATE要求（7）[7]を使用します。ユーザAは、UPDATE（8）にOK 200でその答えを生成します。この回答は、ACK（9）で、ユーザBに渡されます。場合ユーザA最後に回答（11）は、そこにセッション状態には変化がないので、単純に200 OK（12）ACKのコントローラ。
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は、おそらくPSTNゲートウェイであり、なぜならPSTN側からアーリーメディアの暫定応答を生成しました。 PSTNは、コントローラからの最初のオファーは何のメディアストリームを持っていないのでゲートウェイは、それを送信するためにどこにもありませんが、このメディアを配信します。ユーザBが応答すると、メディアが流れ始めることができます。しかし、それまでPSTNからゲートウェイに送信されたメディアが失われます。
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.
SIPの拡張は、シグナリングとリソース予約[2]のカップリングを可能にすることが指定されています。この仕様は、コールセットアップが完了する前にセッション記述の交換に依存しています。特定のSDPパラメータは、最初のINVITEに渡されたとき、これらのフローが開始されます。その結果、第三者呼制御と、このメカニズムの相互作用が明らかにされていません、そしてディテールに値します。
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節に記載のコール障害シナリオを避けるために、前提条件を使用することを希望します。具体的には、コントローラは、メディアとコーデックの共通セットがない限り、当事者が警告されることを保証するために、前提条件を使用することができます。彼らはそれを受け入れることを決定する前にそれはまた、コールの培地組成物に関する情報を、両当事者を提供することができます。
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 | |
|<------------------| |
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 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.
このシナリオの流れは、この例では図10に示されている、我々は、ユーザBがすぐにコールに応答するある種のオートマトン又は薬剤であると仮定する。そのため、流量コントローラにはSDPを含まないユーザAにINVITEを送信するが、前提条件が必要であることを示す要求ヘッダーと流れI.基づいています。この特定のシナリオでは、（オファーせず、しかし前提条件を示す要求ヘッダとINVITE）[2]に記載されていません。 UASはメディアを含め1XXでのオファーで応答すると、それはコールのために使用したい、それぞれのために、それがオプションとしてサポートしているすべての前提条件をリストアップストリームことが推奨されます。もちろん、ユーザーは、この時点で警告されていません。コントローラは、このオファーを受け取り、ユーザB（3）に渡します。ユーザBは、前提条件をサポートする、または行いますが、それらに興味を持っていないですしません。それがコールに応答するときしたがって、200 OKが記載されているすべての前提条件（4）なしで答えが含まれています。この回答は、PRACK（6）において、ユーザAに渡されます。この時点で、ユーザAは、コールのために使用されて実際には前提条件が存在しないことを知っている、したがって、それはユーザーに警告することができます。呼が応答された場合、ユーザAは、制御装置（8）に200 OKを送信し、呼は完了する。
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.
イベントでは、ユーザAにより生成されたオファーは、（例えば、コーデックやメディアを非重複のため）、ユーザBが直ちにINVITE（メッセージ3）を拒否し、ユーザBに受け入れられなかったこと。コントローラはこのような状況ではユーザAへの要求を取り下げることになる、いずれもユーザ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に渡されると、両当事者は、前提条件を満たすために必要なものは何でも対策を進めます。前提条件が満たされたまで、どちらもユーザーが警告されます。
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 |
| |<---------------------|
|(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 |
| |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 |
| |--------------------->|
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).
コントローラは、フローIVに従います。それは前提条件仕様[2]をサポートするための特別な要件はありません。したがって、それはメディア行を含まないSDPを用いて（1）INVITEを送信します。ユーザAは、支持の前提条件に興味がある、とリソースが確保されるまで、その電話を鳴らしたくありません。 INVITEにはメディアストリームが存在しないので、メディアストリームのためのリソースを予約することができず、それらは、後続の提供に搬送した後に予約されるまでそのため、携帯電話を鳴らすことができません。したがって、それは答えで183を生成し、ユーザー（2）を警告しません。コントローラPRACKsこの（3）、AはPRACK（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を持ってしようとします。これは、Bを送信AN SDPなしINVITE（5）。 Bは、この呼び出しのための前提条件を持つことに興味があります。したがって、適切なSDP属性（6）が含ま183にそのオファーを生成します。コントローラはUPDATE要求（7）におけるAにこのクーポンを渡します。コールはまだ応答されていないため、コントローラがUPDATEを使用し、そのため、それが再INVITEを使用することはできません。ユーザーAは、そのピアが前提条件をサポートすることが可能であることを見ています。それはコールのための前提条件を望んでいるので、それはUPDATEに200 OK（8）での回答を生成します。この答えは、順番に、暫定応答（9）のためにPRACKにBに渡されます。さて、両側には、リソースの予約を行います。ユーザAは、まず成功し、UPDATE要求（13）で更新されたセッション記述を渡します。コントローラは、単純にこれを渡すUPDATE（14）に（フローIVに必要に応じて原点フィールドの操作後）、及び回答（15）（16）に戻されます。同じ流れが、しかしBから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]、及び前提条件とは無関係です。
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.
私たちが議論するこの機能の最初のアプリケーションは、クリックツーダイヤルです。このサービスでは、ユーザーは、電子商取引サイトのWebページを閲覧している、と顧客サービス担当者に話をしたいと思います。ユーザーがリンクをクリックすると、コールは顧客サービス担当に配置されます。代表者は、ユーザーの机のリング上で、携帯電話を拾ったとき。ユーザーが拾うとき、顧客サービス担当者は、そこにユーザーに話をする準備ができています。
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 | | |
|.......................................| |
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.
このサービスのためのコールフローは、ユーザがリンクをクリックしたときにサービスがHTTP POST要求を介してトリガされることを除いて、図4のものと同一である図12に示されています。通常、このPOSTリクエストは、ユーザーの数や顧客サービス担当者のどちらが含まれています。ユーザーは、おそらくサーバーに必要なコンテキストを与えて、サイトにログインしているであろうから、ユーザーの数は、典型的には、バックエンドデータベースからWebアプリケーションによって得られるであろう。顧客サービスの数は、典型的には、プロビジョニングによって得られるであろう。このように、HTTP POSTは、実際に通話が要求される表示よりも多くのサーバーは何も提供されていません。
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: 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.
我々は、このサービスは、他の機構、すなわち、PINT [9]を介して提供することができることに留意されたいです。しかし、サービスがPINTにより提供される方法、およびそれがここで提供される方法の間、多くの違いがあります。PINTソリューションは2つのだけPSTNエンドポイント間のコールを可能にしますoを。ここで説明するソリューションは、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.
2つのPSTN電話間の通話に使用する場合、O、ここでのソリューションは、インターネット上でルーティングされるコールの一部になることがあります。 PINTでは、コールは常にのみPSTNを介してルーティングされます。これは、コールのインターネット部分をルーティングネットワークの使用およびQoS機能にコーデックに応じて、PINTソリューションとのより良い品質の通話、になることがあります。
o The PINT solution requires extensions to SIP (PINT is an extension to SIP), whereas the solution described here is done with baseline SIP.
ここで説明するソリューションは、ベースラインSIPで行われ、一方、PINT溶液O、（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クライアントとして動作する）は、「ステップアウト」することができます。ここで説明するソリューションは、コールの全体の持続時間、コール状態を維持するためのコントローラを必要とします。
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.
ここでは、単にクレジットカード情報を収集するために、ミッドコールダイアログを再生するためのサードパーティの呼制御の使用を検討してください。
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 | | |
|.......................................| |
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 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.
私たちは、コントローラはB2BUAとして呼び出しになるように、呼が設定されているとします。タイマー火災は、私たちは、メディアサーバーへの発信者を接続したいときに。このためのフローは、タイマーが満了すると、コントローラは、0.0.0.0の接続アドレスと被呼者を配置し、図13に示されている（1）。これは効果的と呼ばれるパーティを「切断します」。次に、コントローラは、プリペイド発呼者（4）にSDPなしにINVITEを送信します。オファーは、発信者（5）の数字を収集するメディアサーバへINVITEで使用されてから返された（6）。これは、メディアサーバーがオートマトンである、とすぐにINVITEお答えしますので、この流れは、ここでしか使用することができますフローIのインスタンス化したものです。コントローラは、他のエンドユーザとプリペイドユーザを接続した場合、フローIIIが使用される必要があるであろう。メディアサーバは、ACK（8）で呼び出し側に渡された答え、とすぐに200 OK（7）を返します。結果は、メディアサーバーおよびプリペイド呼び出し側が接続されている彼らのメディアストリームを持っているということです。
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.
メディアサーバーでハングアップした後、コントローラは、元の着信側にユーザーを再接続します。これを行うには、コントローラは、着信側（13）にSDPなしでINVITEを送信します。 200 OK（14）が提供、offer3が含まれています。コントローラは、（フローIIIに行われるように）SDPを変更し、及びプリペイドユーザ（15）にINVITEにオファーを通過します。プリペイドユーザは、コントローラは、ACK（17）内のユーザBに渡さ200 OK（16）の答を生成します。この時点で、呼び出し側と着信側が再接続されます。
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は、ここで説明されたメカニズムを用いて制御可能であるべきです。しかし、サードパーティの呼制御が実装されていない可能性がありますいくつかの機能に依存しています。そのため、我々は、ユーザエージェントサーバの実装者は、次の機能をサポートすることをお勧めします：
o Offers and answers that contain a connection line with an address of 0.0.0.0.
0.0.0.0のアドレスとの接続ラインを含み、Oオファーと回答。
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
o Re-INVITEs that add a media stream
メディアストリームを追加し再招待O
o Re-INVITEs that remove a media stream (setting its port to zero)
メディアストリームを削除再度のINVITE O（ゼロへのポートを設定します）
o Re-INVITEs that add a codec amongst the set in a media stream o SDP Connection address of zero
ゼロのSDP接続アドレスOメディアストリームにセット間でコーデックを追加O再のINVITE
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と-のINVITEを再
o The UPDATE method [7]
UPDATEメソッドO [7]
o Reliability of provisional responses [6]
暫定応答の信頼O [6]
o Integration of resource management and SIP [2].
リソース管理の統合およびSIP O [2]。
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コールを行う場合には、発信者が以前に（おそらく、ウェブサイト経由で）サインアップしていない限り、例えば、コールは拒否することができます。他の例では、コールの取り扱いポリシーは、そのような呼処理言語で記載されたもののような自動化されたスクリプトに基づいて作られています[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.
これら二つは区別がつかないように、これらの認証メカニズムは、通常のファーストパーティコールとサードパーティの呼び出しに適用されます。その結果、これらの認可ポリシーは、サードパーティの呼び出しのために正常に動作し続けることのために重要です。サードパーティのコールを開始する1 - もちろん、サードパーティの呼び出しは、新しい党を紹介します。認可ポリシーは、その第三者のアイデンティティに基づいて適用するか、または彼らは、通話の参加者に基づいて適用されていますか？理想的には、参加者が両方の他の当事者のアイデンティティを知ることができ、および認可ポリシーが適切なものに基づいている必要があります。しかし、これは既存のメカニズムを使用できません。その結果、次善の策は、第三者の身元を格納するためのINVITE要求のためです。最終的に、これは、通信を要求しているユーザーであり、それは、そのIDに基づいてされるコール認可ポリシーのために理にかなっています。
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、およびS / MIMEを使用して要求を認証するためにこのシナリオでは、それが適切であろう（参照RFC 3261 [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フィールドに表示名を使用することです。表示名は、ユーザとコントローラは、それぞれ、ユーザとコントローラのテキスト識別され、「[ユーザー]の代わりに[コントローラ]」に設定することをお勧めされています。この場合には、フィールドから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.
他の状況では、コントローラやコールの参加者の間には本当の関係はありません。これらの状況では、理想的には、コントローラは、呼が（アプリケーションに応じて、参加者の一人、あるいは第三者であり得る）特定のアイデンティティであることを主張するための手段を有するであろう、そして署名とそのアサーションを検証しますコントローラのキーを使用して。
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]内のキーイング材料の交換に基づいています。
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.
サードパーティ呼制御とこれらの機構の適切な動作は、適切に動作し、コントローラに依存します。長いので、明示的にこれらのメカニズムを無効にしようとされていないとして、プロトコルが適切であっても、コントローラは、盗聴または変更することはできません安全なメディアセッションで、その結果、参加者の間で動作します。サードパーティ呼制御をユーザーとコントローラとの間の信頼のモデルに基づいているので、行儀の方法で動作していると仮定することは合理的です。しかし、キーイング材料の初期の交換に干渉コントローラを防ぐことができない暗号化手段が存在しません。結果として、それがそう望むかどうか、メディア交換に仲介者として自分自身を挿入するコントローラの可能性が自明です。
The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric Rescorla, Allison Mankin and Sriram Parameswar for their comments.
作者は彼らのコメントのためにポールKyzivat、ロハンマーイ、エリックレスコラ、アリソンマンキンとスリラムParameswarに感謝したいと思います。
[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.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、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.ローゼンバーグ、RFC 3312、2002年10月「資源管理とセッション開始プロトコル（SIP）の統合」。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 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.キャマリロ、 "セッション開始プロトコル（SIP）理由ヘッダーフィールド"、RFC 3326、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と、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[7]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[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. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 3550、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] 2000 Petrackと、S.とL.コンロイ、 "パイントサービスプロトコル：電話コールサービスへのIPアクセスのためのSIPとSDPへの拡張"、RFC 2848、2000年6月を。
[10] Andreasen, F., Baugher, M. and D. Wing, "SDP Security Descriptions for Media Streams", Work in Progress, October 2003.
[10]アンドレア、F.、Baugher、M.とD.ウィング、 "メディアストリームのためのSDPセキュリティ記述"、進歩、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月の作業。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグdynamicsoft 600 Lanidexプラザパーシッパニー、NJ 07054米国
Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net
電話：+1 973 952-5000 Eメール：jdrosen@dynamicsoft.com URI：http://www.jdrosen.net
Jon Peterson Neustar 1800 Sutter Street Suite 570 Concord, CA 94520 US
ジョン・ピーターソンNeustar 1800サターストリートスイート570コンコード、CA 94520米国
Phone: +1 925 363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz
電話：+1 925 363-8720 Eメール：jon.peterson@neustar.biz URI：http://www.neustar.biz
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027米国
EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
電子メール：schulzrinne@cs.columbia.edu URI：http://www.cs.columbia.edu/~hgs
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。