[要約] RFC 3725は、SIPにおける第三者呼制御（3pcc）のためのベストカレントプラクティスを提供しています。このRFCの目的は、SIPベースの通信システムでの3pccの実装と運用のためのガイドラインを提供することです。
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)
セッション開始プロトコル（SIP）でのサードパーティコールコントロール（3PCC）の最良の現在のプラクティス
Status of this Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（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.
サードパーティのコールコントロールとは、1つのエンティティが実際に他の関係者間でコミュニケーションが行われる呼び出しを作成する能力を指します。セッション開始プロトコル（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.
従来のテレフォニーのコンテキストでは、サードパーティのコールコントロールにより、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上の従来のものが含まれますが、Click-to-Dialなどの新しいものも含まれます。クリックすると、ユーザーがカスタマーサービス担当者と話をしたいときに、ユーザーが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.
RFC 3261 [1]内で指定されたメカニズムのみを使用して、サードパーティのコールコントロールが可能です。実際、多くの異なるコールフローが可能であり、それぞれがSIP準拠のユーザーエージェントで動作します。ただし、これらのフローのそれぞれには利点と欠点があります。サードパーティのコールコントロールの使用は、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では、RFC 3312 [2]とサードパーティのコールコントロールとの相互作用について説明します。セクション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.
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "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のコールフローIを図1に示します。コントローラーは、最初に招待状を送信します。この招待状にはセッションの説明がありません。Aの電話が鳴り、答え。これにより、オファーを含む200 OK（2）が生じます[4]。コントローラーは、[1]によって義務付けられているように、ACKで回答を送信する必要があります。答えを得るために、それはb（3）への招待で（offer1）から得た申し出を送ります。Bの電話が鳴ります。Bが回答すると、200 OK（4）にはこのオファーに対する回答が含まれています。コントローラーはACKをB（5）に送信し、nesson1をAに渡します（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は定期的に200 OK応答を再送信します。RFC 3261セクション13.3.1.4で指定されているように、200 OKは64*T1秒間再送信されます。ACKがそれまでに到着しない場合、呼び出しは失敗したと見なされます。これにより、このフローの適用性が、コントローラーがBがすぐに招待に応答することをコントローラーが知っているシナリオに制限されます。
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を図2に示します。コントローラーは、最初にユーザーa（1）に招待を送信します。これは、単一のオーディオメディアライン、1つのコーデック、ランダムポート番号（ゼロではない）、および0.0.0.0の接続アドレスを備えたオファー（SDP1）を含む標準招待状です。これにより、「ブラックホール」の初期メディアストリームが作成されます。これは、Aからメディア（またはRTCPパケット[8]）が流れないため、Aの招待は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.
RFC 3264で推奨されているが、0.0.0.0の使用には多くの欠点があることに注意してください。将来の仕様では、0.0.0.0 IPアドレスではなく、.invalid DNSトップレベルドメイン内のドメインの使用を推奨することが予想されます。その結果、実装者は、そのような開発が発生したら追跡することをお勧めします。
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番目の招待状（3）を生成します。この招待状はユーザーBに宛てられており、SDP2のオファーとしてSDP2が含まれています。SDP2の役割が変更されたことに注意してください。200 OK（メッセージ2）では、それは答えでしたが、招待ではそれは申し出です。幸いなことに、すべての有効な回答は有効な初期オファーです。これにより、Bの電話が鳴ります。回答すると、回答がある200 OK（5）が生成されます。SDP3。次に、コントローラーがACKを生成します（6）。次に、SDP3を含むa（7）にオファーとして再入力を送信します。繰り返しますが、役割の逆転がありました。SDP3は答えであり、今では申し出です。幸いなことに、オファーとしての回答の回答への回答は、有効なオファーです。この再入力は、SDP2で200 OK（8）を生成します。これは、Aがこの再インバイトの結果としてセッションのいかなる側面を変更することを決定しないと仮定します。この200 OKはAcked（9）であり、メディアはAからBにBに流れます。BからAにメディアが送信されると、すでに流れ始める可能性があります。
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.
このフローには、すべての最終的な応答がすぐにアクセスされるという利点があります。したがって、フロー1のタイムアウトとメッセージの非効率性の問題には悩まされません。しかし、問題もあります。まず、コントローラーがコールに使用されるメディアタイプを知っていることを要求します（メディアラインを必要とする「ブラックホール」SDPを生成する必要があるため）。第二に、（1）への最初の招待には、0.0.0.0の接続アドレスを持つメディアが含まれています。コントローラーは、応答にAの有効な非ゼロ接続アドレスが含まれていることを期待しています。ただし、経験により、多くのUASが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.
ただし、このフローで最も深刻な欠陥は、再インバイトに対する200 OK（メッセージ8）にメッセージ2と同じSDPが含まれているという仮定です。これは当てはまらない可能性があります。そうでない場合、コントローラーはそのSDP（たとえば、SDP4）でBを再誘導する必要があります。これにより、Bから200 OKで別のSDP、SDP5を取得する可能性があります。繰り返しますが、その結果、再インバイトの無限のループが得られます。可能な限り同じSDPを返すことができる非常にスマートなUAS、またはSDPを分析してRe Inviteが本当に必要かどうかを判断できる非常にスマートなコントローラーを持つことにより、このサイクルを破ることができます。ただし、このメカニズムをシンプルに保ち、コントローラーの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.
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なしで招待（1）をユーザーAに送信します（これは、コントローラーがセッションのメディア構成について何も想定する必要がないことを意味するため）。Aの電話が鳴ります。回答の場合、200 okが生成されます（2）オファー、offer1。コントローラーは、回答を含む即時ACKを生成します（3）。この答えは「ブラックホール」SDPで、接続アドレスは0.0.0.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 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.
次に、コントローラーはSDPなしでBに招待を送信します（4）。これにより、Bの電話が鳴ります。彼らが答えると、オファーを含む200 OKが送信されます。このSDPは、A（6）に戻る再入力を作成するために使用されます。そのre inviteはoffer2に基づいています2ですが、メディアラインを一致させるか、メディアラインをトリミングするために再編成する必要がある場合があります。たとえば、offer1にはその順序でオーディオとビデオラインが含まれているが、offer2にはオーディオラインのみが含まれている場合、コントローラーはオファーにビデオラインを追加し（ポートをゼロに設定）、offer2 'を作成する必要があります。これは再入力であるため、一般的なケースでは迅速に完了するはずです。ユーザーBが200 OKを再送信し、ACKを待っているため、それは良いことです。a、Answer2 'の200 OK（7）のSDPは、ACKをb（8）に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.
このフローには多くの利点があります。第一に、それは通常、偽りの再送信やタイムアウトなしで動作します（ただし、これは、再入力が迅速に応答しない場合でも発生する可能性があります）。第二に、参加者が使用するメディアを推測する必要はありません。
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をいくつか服用し、同じメディア構成を持つ別のSDPを生成する必要がありますが、0.0.0.0に等しい接続アドレスがあります。これはメッセージ3に必要です。次に、SDP Xを並べ替えてトリミングする必要がある場合があります。これにより、メディアラインは他のSDP Yと一致するようにします。（オファー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).
Flow IVは、その複雑さを軽減するフローIIIのバリエーションを示しています。実際のメッセージフローは同一ですが、SDPの配置と構造は異なります。最初の招待（1）には、メディアがまったくないSDPが含まれています。つまり、Mラインはありません。これは有効であり、セッションのメディアの構成が後に再入力を通じて確立されることを意味します[4]。招待状を受け取ると、ユーザーAは警告されます。彼らが電話に応答するとき、200 OK（2）にもメディアなしの答えがあります。これはコントローラーによって認められます（3）。この時点以降の流れは、フローIIIと同じです。ただし、offor2 'にoffer2に変換するために必要な操作は、回答2に回答2にnecss2に変換する必要があります。実際、メディアの操作はまったく必要ありません。必要な唯一の変更は、Origin Lineを変更することです。これにより、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の両方が、互換性のあるメディアがあるかどうかがわかる前に、コールに応答する（つまり、200 OKを生成する）ことになります。共通のメディアがない場合、通話はさようならで後で終了することができます。ただし、ユーザーはすでに警告を受けているため、ユーザーはイライラし、請求イベントになります。
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よりも追加の利点は提供されません。ただし、再インバイトの無限のpingポンギングの可能性があるため、フローIIを使用しないでください。
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.
ほとんどの場合、推奨されるフローを含む、ユーザーAはBへの呼び出しが完了している間、沈黙を聞きます。これは必ずしも理想的ではないかもしれません。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のすべてのコールフローを使用すると、1回の呼び出しがAに確立され、コントローラーはBへの呼び出しを確立しようとしますが、このコールの試行は、何らかの理由で失敗する可能性があります。ユーザーBが忙しい可能性があります（招待への486の応答が発生します）、共通のメディアはなく、リクエストがタイムアウトする可能性があります。コールの試みがBに障害を失う場合、コントローラーがAにさようならを送信することをお勧めします。これは、失敗の正確な理由を通知します。情報は、ユーザーインターフェイスの観点から重要です。たとえば、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.
議論に値する別のエラー条件を図5に示します。コントローラーがA（メッセージ1-3）でダイアログを確立した後、B（メッセージ4）に連絡しようとします。Bに連絡するには時間がかかる場合があります。その間隔の間に、Aはおそらく更新されたオファーを提供する可能性があります。ただし、コントローラーはこのオファーを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.
呼び出しが確立されると、両方の参加者は、自分が1回のポイントツーポイントコールにあると考えています。ただし、コントローラーではなく、メディアを互いに直接交換しています。コントローラーは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.
コントローラーは依然としてシグナリングの中心的なポイントであるため、コールを完全に制御できます。参加者の1人からさようならを受け取った場合、新しいバイバイを作成し、他の参加者と電話を切ることができます。これを図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.
同様に、参加者の1人から再入手を受け取った場合、他の参加者に転送できます。どのフローが使用されたかに応じて、これには渡す前に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からさようならを受信した場合、代わりにサードパーティCおよびBをその参加者に接続する新しい招待状を生成できます。このためのコールフローを図7に示します。これは、Cがオートマトンではなくエンドユーザーを表す場合を想定しています。それは単なるフロー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).
このセクションの処理を使用するために、コントラがコントローラーによって確立する必要はないことを指摘することが重要です。むしろ、コントローラーは、Aに向かって確立された呼び出し中に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が早期メディアを生成する場合を示しています。フローは図4からのフローIVとほぼ同じです。唯一の違いは、ユーザーBが最終応答の代わりに信頼できる暫定応答（5）[6]を生成し、Answer2がACKの代わりにプラック（9）で運ばれることです。。パーティBが最終的にコール（12）を受け入れる場合、セッション状態に変更はありません。したがって、ユーザーAでシグナリングを行う必要はありません。コントローラーは、ダイアログを確認するために200 OK（13）を単純にAcksにする必要はありません。
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が早期メディアを生成する場合はより複雑で、図9に示されています。フローはフローIVに基づいています。コントローラーは、メディアストリームが含まれていないオファーを使用して、ユーザーA（1）に招待状を送信します。ユーザーAは、メディアストリームのない回答を含む信頼できる暫定的な対応（2）を生成します。コントローラーは、この暫定的な応答をプラックします（3）。現在、コントローラーはSDPなしで招待状をユーザーBに送信します（5）。ユーザーBの電話が鳴り、答えて、オファーを備えた200 ok（6）になります。コントローラーは、ユーザーAでセッションパラメーターを更新する必要があります。ただし、通話に応答されていないため、再viteを使用することはできません。むしろ、SIPアップデートリクエスト（7）[7]を使用して、オファーを渡します（Originフィールドを正しくするために変更した後）。ユーザーAは、アップデート（8）の200 OKでその回答を生成します。この答えは、ACKのユーザーBに渡されます（9）。ユーザーAが最終的に回答すると（11）、セッション状態に変更はありません。そのため、コントローラーは200 OK（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は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パラメーターが最初の招待で渡されると開始されます。その結果、このメカニズムとサードパーティのコールコントロールとの相互作用は明らかではなく、詳細に価値があります。
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はすぐにコールに応答する何らかのオートマトンまたはエージェントであると仮定します。したがって、フローはフローIに基づいています。コントローラーは、SDPが含まれていないaをユーザーに送信しますが、前提条件が必要であることを示すヘッダーが必要です。この特定のシナリオ（オファーのない招待状が、前提条件を示す要求ヘッダーを使用）は[2]で説明されていません。UASは、コールに使用したいメディアストリームを含む1xxのオファーで応答することをお勧めします。それぞれについて、オプションとしてサポートするすべての前提条件をリストします。もちろん、この時点でユーザーは警告を受けていません。コントローラーはこのオファーを受け取り、ユーザーB（3）に渡します。ユーザーBは、前提条件をサポートしていないか、そうではありませんが、興味がありません。したがって、コールに応答すると、200 OKには、前提条件が記載されていない回答が含まれています（4）。この答えは、プラック（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には受け入れられなかった場合（たとえば、重複していないコーデックやメディアなど）、ユーザーBは招待状をすぐに拒否します（メッセージ3）。その後、コントローラーはユーザー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では、コントローラーは、特定の目標を達成するために前提条件の使用を要求しました。また、コントローラーが前提条件について気にしない（またはおそらく知らない）可能性もありますが、コールの参加者の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).
コントローラーはFlow IVに従います。前提条件の仕様のサポートに関する特定の要件はありません[2]。したがって、メディアラインが含まれていないSDPを使用して招待（1）を送信します。ユーザーAは、前提条件のサポートに関心があり、リソースが予約されるまで電話を鳴らしたくありません。招待状にはメディアストリームがないため、メディアストリームのリソースを予約することはできないため、後続のオファーで伝達されてから予約されるまで電話を鳴らすことはできません。したがって、答えが183を生成し、ユーザーに警告しません（2）。コントローラーはこれをプラックし（3）、プラック（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なしでBを招待します（5）。Bは、この呼び出しの前提条件を持つことに興味があります。したがって、適切なSDP属性を含む183でそのオファーを生成します（6）。コントローラーは、このオファーを更新リクエスト（7）に渡します。コントローラーは、コールがまだ回答されていないため、更新を使用しているため、re inviteを使用できません。ユーザーAは、そのピアが前提条件をサポートできると考えています。通話の前提条件を望むため、200 ok（8）に更新の回答が生成されます。この答えは、暫定的な応答のためにプラックのBに渡されます（9）。現在、双方はリソース予約を実行しています。ユーザーAは最初に成功し、更新リクエストで更新されたセッションの説明に合格します（13）。コントローラーは、アップデート（14）でこれを（フローIVで要求されるオリジンフィールドの操作後）（14）に（15）に（16）に渡されます。同じフローが発生しますが、BからAまで、Bの予約が成功します（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を通過するための更新とプラックの使用です。その決定は、[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.
この機能の最初のアプリケーションは、クリックツーダイアルです。このサービスでは、ユーザーがeコマースサイトの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.
このサービスのコールフローを図12に示します。これは、ユーザーがリンクをクリックするとHTTP POSTリクエストを介してサービスがトリガーされることを除いて、図4と同じです。通常、このPOSTリクエストには、ユーザーの数もカスタマーサービス担当者の数も含まれていません。ユーザーの番号は通常、バックエンドデータベースからWebアプリケーションによって取得されます。これは、ユーザーがおそらくサイトにログインし、サーバーに必要なコンテキストを提供するためです。通常、カスタマーサービス番号はプロビジョニングを通じて取得されます。したがって、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: 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.
このサービスは、他のメカニズム、すなわちパイント[9]を通じて提供できることに注意してください。ただし、サービスがパイントで提供される方法と、ここで提供される方法との間には多くの違いがあります。Oパイントソリューションは、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 2つのPSTN電話間での呼び出しに使用される場合、ここでの解決策により、コールの一部がインターネットを介してルーティングされる場合があります。パイントでは、呼び出しは常にPSTNを介してのみルーティングされます。これにより、使用中のコーデックとコールのインターネット部分をルーティングするネットワークの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 パイントソリューションでは、SIPに拡張機能が必要です（パイントは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 パイントソリューションにより、コントローラー（パイントクライアントとして機能する）が、呼び出しが確立されると「ステップアウト」できます。ここで説明するソリューションでは、コントローラーがコールの期間中ずっとコール状態を維持する必要があります。
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として呼び出しになっているように、コールが設定されていると仮定します。タイマーが発砲したら、発信者をメディアサーバーに接続したいと思います。このフローを図13に示します。タイマーの有効期限が切れると、コントローラーは、接続アドレスが0.0.0.0（1）で呼び出されたパーティを配置します。これは、呼び出されたパーティーを効果的に「切断」します。次に、コントローラーは、SDPなしで招待状を事前賃金発信者に送信します（4）。発信者（5）から返されたオファーは、数字を収集するメディアサーバーへの招待で使用されます（6）。これはフローIのインスタンス化です。このフローは、メディアサーバーはオートマトンであり、すぐに招待に応答するため、ここでのみ使用できます。コントローラーがプリペイドユーザーを別のエンドユーザーに接続している場合、Flow 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.
メディアサーバーに電話をかけた後、コントローラーはユーザーをオリジナルの呼び出したパーティーに再接続します。これを行うために、コントローラーはSDPなしで招待状を呼び出した当事者に送信します（13）。200 OK（14）には、オファー、オファー3が含まれています3。コントローラーはSDP（Flow IIIで行われているように）を変更し、プリペイドユーザーへの招待状でオファーを渡します（15）。プリペイドユーザーは、コントローラーが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.
o 0.0.0.0のアドレスを持つ接続線を含むオファーと回答。
o Re-INVITE requests that change the port to which media should be sent
o メディアを送信するポートを変更するリクエストを再確認する
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)
o メディアストリームを削除する（ポートをゼロに設定する）再インバイト
o Re-INVITEs that add a codec amongst the set in a media stream o SDP Connection address of zero
o メディアストリーム内のセットの中にコーデックを追加する再インバイトo SDP接続アドレスのゼロ
o Initial INVITE requests with a connection address of zero
o ゼロの接続アドレスを使用した最初の招待リクエスト
o Initial INVITE requests with no SDP
o SDPのない最初の招待リクエスト
o Initial INVITE requests with SDP but no media lines
o SDPでの最初の招待リクエストは、メディアラインがありません
o Re-INVITEs with no SDP
o SDPのない再インバイト
o The UPDATE method [7]
o 更新方法[7]
o Reliability of provisional responses [6]
o 暫定的な反応の信頼性[6]
o Integration of resource management and SIP [2].
o リソース管理とSIPの統合[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コールを行う場合、発信者が以前にサインアップしていない限り（おそらくWebサイトを介して）、呼び出しが拒否される場合があります。それ以外の場合は、コール処理言語[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つは区別できないため、これらの承認メカニズムは通常の第一党の呼び出しと第三者の呼び出しに適用されます。その結果、これらの許可ポリシーがサードパーティの呼び出しに対して正しく運営され続けることが重要です。もちろん、サードパーティの電話では、新しいパーティーが導入されます。これは、サードパーティコールを開始するものです。その第三者の身元に基づいて承認ポリシーは適用されますか、それとも呼び出しの参加者に基づいて適用されますか？理想的には、参加者は他の両当事者の身元を知り、必要に応じてそれらに基づいて認可ポリシーを持つことができます。ただし、これは既存のメカニズムを使用して不可能です。その結果、次の最良のことは、招待リクエストがサードパーティの身元を封じ込めることです。最終的に、これはコミュニケーションを要求しているユーザーであり、コール認証ポリシーがそのアイデンティティに基づいていることは理にかなっています。
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つの一般的なシナリオでは、コントローラーはコールの参加者の1人に代わって行動しています。典型的な例は、コントローラーとカスタマーサービスの担当者が同じ管理ドメインによって実行されるクリックから外へのクリックです。実際、識別の目的のために、コントローラーはカスタマーサービスの代表者であると合法的に主張することができます。このシナリオでは、エンドユーザーへの招待がカスタマーサービス担当者を識別するフィールドからAを含み、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.
これには、コントローラーが実際にカスタマーサポート担当者として認証できる資格情報を実際に持っている必要があります。他の多くの場合、コントローラーは参加者の1人を表していますが、資格情報を所有していません。残念ながら、現在、ユーザーが特定のサードパーティコールコントロール操作に使用を制限する方法で、ユーザーが資格情報をコントローラーに委任できるようにする標準化されたメカニズムはありません。このようなメカニズムがない場合、できることは、FROMフィールドのディスプレイ名を使用して、呼び出しが行われているユーザーの身元を示すことです。ディスプレイ名は、[ユーザー]に代わって[[コントローラー]]に設定することをお勧めします。ここでは、ユーザーとコントローラーはそれぞれユーザーとコントローラーのテキストアイデンティティです。この場合、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.
他の状況では、コントローラーとコールの参加者との間に実際の関係はありません。これらの状況では、理想的には、コントローラーは、呼び出しが特定のID（アプリケーションに応じて参加者の1人、または第三者の1人である可能性がある）からのものであると主張し、そのアサーションを署名で検証する手段を持っているでしょう。コントローラーのキーを使用します。
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ダイアログに関する限り、コントローラーは実際には参加者の1人です。したがって、S/MIMEによって提供されるSIPメッセージの暗号化と完全性は、参加者間ではなく、参加者とコントローラー間で発生します。
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.
著者は、ポール・キジバット、ローハン・マヒー、エリック・レスコルラ、アリソン・マンキン、スリラム・パラメスワールのコメントに感謝したいと思います。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、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] Camarillo、G.、ed。、Marshall、W.、ed。J. Rosenberg、「リソース管理とセッション開始プロトコル（SIP）の統合」、RFC 3312、2002年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、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.、Oran、D。、およびG. Camarillo、「セッション開始プロトコルの理由ヘッダーフィールド（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] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[7] Rosenberg、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.、Frederick、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] Petrack、S。and L. Conroy、「The Pint Service Protocol：SIPおよびSDPへの拡張電話への電話サービスへのアクセスのための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] Andreasen、F.、Baugher、M。and D. Wing、「Media Streamsの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] Lennox、J.、Wu、X。、およびH. Schulzrinne、「CPL：インターネットテレフォニーサービスのユーザー制御のための言語」、2003年8月、進行中。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Dynamicsoft 600 Lanidex Plaza Parsippany、NJ 07054 US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Jon Peterson Neustar 1800 Sutter Street Suite 570 Concord, CA 94520 US
Jon Peterson Neustar 1800 Sutter Street Suite 570 Concord、CA 94520 US
Phone: +1 925 363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングシュルツリンコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027 US
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。