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 セッション開始プロトコルにおけるサードパーティ呼制御(3pcc)の 現時点でのベストプラクティス Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) 本文書の位置付け この文書は、インターネットコミュニティのために、現段階でのインターネッ トのベストプラクティス(Internet Best Current Practices)を提示し、改善 のための議論や提案を依頼するものである。この文書の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). All Rights Reserved. 概要 サードパーティ呼制御は、1つのエンティティが、実際は他のパーティ間で行 われている通信で、呼を作成する機能を指す。サードパーティ呼制御は、セッ ション開始プロトコル(Session Initiation Protocol/SIP)内で規定されてい るメカニズムを使用して実現することができる。ただし、アプローチは複数あ り、それぞれ、異なる利点と欠点がある。本文書では、サードパーティ呼制御 に関するSIPの用法における、現段階でのベストプラクティスについて論ず る。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. 3pccの呼確立 . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. フローI . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. フローII . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. フローIII . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. フローIV . . . . . . . . . . . . . . . . . . . . . . . 8 5. 推奨 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. エラー制御 . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. 継続処理 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. 3pccと初期メディア . . . . . . . . . . . . . . . . . . . . 13 Rosenberg, et al. Best Current Practice [Page 1] RFC 3725 SIP 3pcc April 2004 9. サードパーティ呼制御とSDPの前提条件 . . . . . . . . . . . 16 9.1. コントローラが初期化 . . . . . . . . . . . . . . . . . 16 9.2. パーティAが初期化 . . . . . . . . . . . . . . . . . . . 18 10. コールフロー例 . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. クリックトゥダイヤル . . . . . . . . . . . . . . . . . 21 10.2. 通話中のアナウンス機能 . . . . . . . . . . . . . . . . 23 11. 実装上の推奨 . . . . . . . . . . . . . . . . . . . . . . . 25 12. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . 26 12.1. 認可と認証 . . . . . . . . . . . . . . . . . . . . . . 26 12.2. エンドトゥエンドの暗号化と整合性 . . . . . . . . . . . 27 13. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 14. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 14.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . 28 14.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . 29 15. 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . 30 16. 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . 31 1. はじめに 従来の電話について背景を説明すると、サードパーティ呼制御によって、1つ のエンティティ(本文書ではコントローラと呼ぶ)が、2つ以上の別のパーティ 間で結ばれる通信関係について、セットアップと管理を行うことができるよう になる。サードパーティ呼制御(3pccと呼ばれる)は、オペレータサービス(オ ペレータが2人の参加者間を接続する呼を作成する場合)や会議によく使用され る。 同様に、多くのSIPサービスが、サードパーティ呼制御によって実現してい る。PSTN上の3pccのように従来からあるものも含まれるが、クリックトゥダイ ヤルのように、新しいものもある。クリックトゥダイヤルによって、ユーザー は、カスタマサービスの代表へ電話をかけたいときに、Webページをクリック することができる。Webサーバーは、ユーザーとカスタマサービスの代表との 間に呼を作成する。呼は、2つの電話間、1つの電話と1つのIPホスト、2つのIP ホスト間で行われる可能性がある。 サードパーティ呼制御は、RFC3261(参考文献［1］)内で規定されているメカニ ズムのみを使用して、実現することができる。実に多彩なコールフローが考え られ、それぞれがSIP準拠のユーザーエージェントで機能する。ただし、各フ ローには利点と欠点がある。また、サードパーティ呼制御の用法は、呼のアス ペクトがSIP拡張やSIPのオプション機能を使用する場合、より複雑になる。特 に、サードパーティ呼制御とともに、RFC3312(参考文献［2］)(シグナリング をリソース予約と結びつけるために使用)を使用する場合は重要なので、セク ション9で説明する。同様に、サードパーティ呼制御とともに、初期メディア (early media/呼が承認される前に交換されるセッションデータ)を使用する場 合も、重要である。両方がユーザーエージェントのSDP生成方法とSDPへの応答 方法を指定するが、両方を同時に処理する方法も明確ではない。この問題につ いては、セクション8で説明する。 Rosenberg, et al. Best Current Practice [Page 2] RFC 3725 SIP 3pcc April 2004 本文書は、サードパーティ呼制御を実行する上で、独自に設計した拡張を使用 することなく実現できる、現段階でのベストプラクティスとして役立つ。セク ション4は、サードパーティ呼制御を実現するために使用できる既知のコール フローを示し、その用法についてガイドラインを示す。セクション9では、 サードパーティ呼制御とRFC3312(参考文献[2])との相互作用について論ずる。 セクション8では、サードパーティ呼制御と初期メディアとの相互作用につい て論ずる。セクション10では、本文書で推奨されるフローを利用したアプリ ケーション例を示す。 2. 用語 本文書では、以下のキーワードはRFC2119(参考文献[3])に記述されている通り に解釈されるべきであり、準拠する実装に対する要求レベルを示すものであ る。「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」 3. 定義 以下の用語が本文書全体で使用される。 3pcc: サードパーティ呼制御(Third Party Call Control)。他のパーティ間の 呼を操作する一般的な機能を指す。 コントローラ(Controller): コントローラは、他の2つのユーザーエージェン ト間で、セッションを作成しようとしているSIPユーザーエージェント である。 4. 3pccの呼確立 サードパーティ呼制御の主要で初期の操作は、参加者AとB間にセッションを確 立することである。このセッションの確立は、サードパーティ(コントローラ と呼ぶ)によって指揮される。 このセクションでは、この初期操作を行う上で、コントローラが利用できる3 つのコールフローについて説明する。 Rosenberg, et al. Best Current Practice [Page 3] RFC 3725 SIP 3pcc April 2004 4.1. フローI A コントローラ B |(1) INVITE no SDP | | |<------------------| | |(2) 200 offer1 | | |------------------>| | | |(3) INVITE offer1 | | |------------------>| | |(4) 200 OK answer1 | | |<------------------| | |(5) ACK | | |------------------>| |(6) ACK answer1 | | |<------------------| | |(7) RTP | | |.......................................| 図1 フローIのコールフローを図1に示す。コントローラは、最初に、AへINVITEを 送信する(1)。このINVITEにはセッション記述が含まれない。Aの電話が鳴り、 Aが答える。これは、オファー(参考文献［4］)を含む200 OK(2)という結果に なる。コントローラは、参考文献［1］で必須とされているとおり、ACKでアン サーを送信する必要がある。アンサーを取得するには、Aから取得したオ ファー(オファー1)を、BへINVITEで送信する(3)。Bの電話が鳴る。Bが答える と、200 OK (4)には、このオファーに対するアンサー(answer1)が含まれる。 コントローラがBに対するACK(5)を送信し、送信されたAckでAにanswer1を渡す (6)。オファーはAによって生成され、アンサーはBによって生成されるため、 実際のメディアセッションは、AとB間で行われる。したがって、メディアは、 AとB間で流れる(7)。 このフローはシンプルで、コントローラによるSDPの操作は必要とせず、双方 のエンドポイントで対応するすべてのメディアタイプで機能する。ただし、重 大なタイムアウト問題がある。ユーザーBは、すぐに呼に答えない可能性があ る。結果として、コントローラがAにACKをすぐに送信できない。したがって、 Aは200 OK応答を定期的に再送信することになる。RFC3261セクション13.3.1.4 で既定されるように、64*T1秒の間、200 OKが再送信される。Ackがその期間内 に届かない場合、呼は失敗したと見なされる。そのため、このフローを適用で きるのは、BがすぐにINVITEへアンサーすると、コントローラがわかっている 場合に限られる。 Rosenberg, et al. Best Current Practice [Page 4] RFC 3725 SIP 3pcc April 2004 4.2. フローII A コントローラ 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 | | |.......................................| 図2 フロー案のフローIIを図2に示す。コントローラは、最初に、ユーザーAへ INVITEを送信する(1)。これは標準的なINVITEであり、audio media行が1行、 コーデックが1つ、ランダムなポート番号が1つ(ただし、0以外)、「0.0.0.0」 の接続アドレス1つが指定されたオファー(sdp1)を含んでいる。この結果、Aか らは何のメディア(またはRTCPパケット(参考文献[8]))も流れないため、「ブ ラックホール(black holed)」となる最初のメディアストリームが作成され る。INVITEによって、Aの電話が鳴る。 0.0.0.0の使用は、RFC3264では推奨されているが、多くの欠点があるので 注意すること。将来的な仕様では、「0.0.0.0」のIPアドレスではなく、 .invalidのDNSトップレベルドメインのドメインを使用することが推奨され る、と予想される。したがって、実装者には、このような開発が発生した ときに追跡調査することを推奨する。 Aがアンサーすると(2)、200 OKには、接続行に有効なアドレスが指定されたア ンサー(sdp2)が含まれる。コントローラは、ACKを送信する(4)。次に、2つ目 のINVITEを生成する(3)。このINVITEの宛先はユーザーBであり、Bへのオ ファーとしてsdp2を含む。sdp2の役割が変わっていることに注意すること。 200 OK(メッセージ2)ではアンサーだったが、INVITEではオファーになってい る。幸運にも、すべての有効なアンサーは、有効な最初のオファーである。こ Rosenberg, et al. Best Current Practice [Page 5] RFC 3725 SIP 3pcc April 2004 のINVITEによって、Bの電話が鳴る。Bが電話に出ると、アンサー(sdp3)付きの 200 OK(5)が生成される。次に、コントローラは、ACKを生成する(6)。次に、 コントローラは、Aに対し、オファーとしてsdp3を含むre-INVITEを送信する。 ここでもう一度、役割の逆転があった。sdp3はアンサーだったが、今回はオ ファーである。幸運にも、オファーへの役割が変わったアンサーに対するアン サーは、言い替えると、有効なオファーである。このre-INVITEは、sdp2が指 定された200 OK(8)を生成する。これは、re-INVITEの結果、Aは、セッション のどの特性も変更するように判断しない、と仮定したものである。この200 OK がACKされると(9)、AからBにメディアを流すことができる。BからAへのメディ アは、メッセージ5が送信されたときにすぐ流すことができる。 このフローには、すべての最終応答がただちにACKされるという利点がある。 したがって、フロー1のタイムアウトやメッセージの非効率という問題で悩む ことはない。ただし、トラブルが多すぎる。まず、コントローラは、呼に使用 されるメディアタイプを把握している必要がある(理由は、メディア行を必要 とする「ブラックホール」のSDPを必ず生成するため)。第2に、Aに対する最初 のINVITE(1)には、0.0.0.0の接続アドレス付きのメディアが含まれる。コント ローラは、応答に、A宛ての有効でゼロ以外の接続アドレスが含まれているこ とを期待している。ただし、経験上、多くのUAは、0.0.0.0接続アドレスのオ ファーに対して、0.0.0.0接続アドレスを含むアンサーで応答している。オ ファー-アンサー仕様(参考文献[4])では、実装者に対して、このようなことは 実行しないように明示的に指示しているが、本文書の発行時点では、多くの実 装で未だに実行されていた。万が一、Aがsdp2で0.0.0.0接続アドレスで応答す ると、フローは機能しない。 ただし、このフローの最も重大な欠陥は、re-INVITEに対する200 OK(メッセー ジ8)には、メッセージ2と同じSDPが含まれているという前提である。この前提 が当てはまらない場合がある。前提が成立しない場合、コントローラは、その SDP(たとえばsdp4)を指定してBをre-INVITEする必要がある。また、この結 果、Bからの200 OKで、異なるSDP(sdp5)を取得する可能性があるさらに、コン トローラは、Aをre-INVITEする必要がある、などと続く。結果として、re- INVITEの永久ループとなる。可能な場合は常に同じSDPを返すことができる高 性能のUAか、SDPを分析してre-INVITEが本当に必要かどうかを判断できる高性 能のコントローラがあれば、このサイクルを止めることができる。ただし、本 書では、このメカニズムをシンプルにし、コントローラでSDPを意識しないよ うにしたい。結果として、このフローは真に実行可能とは言えない。したがっ て、このフローは推奨されない[NOT RECOMMENDED]。 Rosenberg, et al. Best Current Practice [Page 6] RFC 3725 SIP 3pcc April 2004 4.3. フローIII A コントローラ 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 | | |.............................................| 図3 3番目のフロー、フローIIIを図3に示す。 第1に、コントローラは、ユーザーAに対して、SDPのないINVITE(1)を送信する (これが良い理由は、コントローラが、セッションのメディア構成について 何も仮定する必要がないためである)。Aの電話が鳴る。Aが電話に出ると、オ ファー(offer1)を含む200 OKが生成される(2)。コントローラは、すぐにア ンサーを含むACKを生成する(3)。このアンサーは、0.0.0.0の接続アドレスを 指定した「ブラックホール」SDPである。 次に、コントローラは、BへSDPなしのINVITEを送信する(4)。これによって、B の電話が鳴る。電話に出ると、オファー(offer2)を含む200 OKが送信される (5)。このSDPは、Aに対するre-INVITE(6)を作成するために使用される。この re-INVITEはoffer3に基づいているが、メディア行とマッチすると認識される 必要がある、またはメディア行を削除する必要がある、とされる場合がある。 たとえば、offer1に音声行とビデオ行がこの順で含まれているが、offer2には 音声行だけが含まれていた場合、コントローラは、offer2'を作成すると きに、オファーにビデオ行を(ポートをゼロに設定して)追加する必要がある。 これはre-INVITEのため、一般的な場合、速やかに完了すべきである。ユー ザーBは200 OKを送信して、ACKを待つため、これは良いことである。また、A Rosenberg, et al. Best Current Practice [Page 7] RFC 3725 SIP 3pcc April 2004 からの200 OK(7)にあるSDP(answer2')は、Bに対するACKをanswer2として送信 する前に、認識または削除することが必要な場合もある。最後に、ACKがAに送 信されると(9)、メディアを流すことができる。 このフローには多くの利点がある。第1に、このフローは、一般的に擬似再伝 送(spurious retransmissions)やタイムアウト(ただし、re-INVITEに対してす ぐに応答がない場合は発生する場合はある)が発生せずに機能する。第2に、参 加者が使用するメディアについてコントローラが推測する必要がない。 欠点がいくつかある。コントローラは、SDPの操作を実行する必要がある。具 体的に言うと、一部のSDPを受けて、同じメディアで構成されているが、 0.0.0.0の接続アドレスが指定された別のSDPを生成する必要がある。これは、 メッセージ3で必要である。第2に、SDP Xを並べ替えたり、削除して、メディ ア行が他のSDP Yとマッチするようにすることが必要な場合がある。第3に、B からのオファー(offer2)には、Aからのオファーと同様に、コーデックまたは メディアストリームがない可能性がある。コントローラは、この条件を検出し て、呼を終了する必要が出てくる。最後に、このフローは、シンプルで洗練さ れたフローI(図1)よりも、はるかに複雑である。 4.4. フローIV A コントローラ 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 | | |.............................................| 図4 Rosenberg, et al. Best Current Practice [Page 8] RFC 3725 SIP 3pcc April 2004 フローIVは、複雑さを軽減した、フローIIIのバリエーションである。実際の メッセージフローは同じだが、SDPの配列と構文が異なる。最初のINVITE(1)に は、まったくメディアが指定されていない(つまりm行がない)SDPが含まれる。 これは有効であり、セッションのメディア構成は、後でre-INVITEによって確 立されることを意味する(参考文献[4])。INVITEを受信すると、ユーザーAにア ラートされる。電話に出ると、200 OK(2)には、メディアも指定されていない アンサーが含まれる。これは、コントローラによってACKされる(3)。これ以降 のフローは、フローIIIと同一である。ただし、offer2からoffer2'への変換と answer2'からanswer2への変換に必要な操作は、はるかにシンプルである。 実際、メディアの操作はまったく必要ない。必要な変更は、offer2'のオリジ ン行がoffer1の値に基づいて有効になるようにする、オリジン行の修正のみで ある(有効にするには、バージョンを1つずつインクリメントし、他のパラメー タはそのまま変更しないようにする必要がある)。 このフローに関連付けられる制限がいくつかある。第1に、確立されたメディ アがなければ、ユーザーAにアラートされる。つまり、ユーザーAは、メディア 構成に基づいて呼を拒否することも承認することもできない。第2に、AとBの 両方が、互換メディアがあるかどうかを知る前に、電話に出る(つまり、200 OKを生成する)結果となる。共通するメディアがなければ、呼は後にBYEで終了 できる。ただし、ユーザーはすでにアラートされているため、結果としてユー ザーの迷惑になったり、課金イベントが発生する可能性がある。 5. 推奨 フローI(図1)は、最もシンプルで最も効率的なフローである。コントローラ は、ユーザーBが実質的なオートマタ(呼に対して迅速にアンサーする)である とわかっている場合、このフローを使用すべきである[SHOULD]。これは、たと えば、メディアサーバー、カンファレンスサーバー、メッセージングサーバー などのデバイスの場合に当てはまる。本書では、多くのサードパーティ呼制御 がオートマタになると予想しているため、このシナリオを特別扱いすることは 妥当である。 未知のエンティティに対する呼の場合、または人を示すことがわかっているエ ンティティに対する呼の場合、フローIV(図4)をサードパーティ呼制御に使用 することが推奨される[RECOMMENDED]。代わりにフローIIIを使用してもよい [MAY]が、フローIVを超える利点はない。一方で、フローIIは使用すべきでは ない[SHOULD NOT]。これは、re-INVITEを永久にやり取りする可能性があるた めである。 これらのフローの一部では、0.0.0.0という「ブラックホール」の接続アドレ スを使用する。これは、送信されたパケットが送信元のホストを離れない (never leave)、というプロパティが指定されたIPv4アドレスである。このア Rosenberg, et al. Best Current Practice [Page 9] RFC 3725 SIP 3pcc April 2004 ドレスは、破棄されるだけである。そのため、これらのフローはIPv4固有のも のである。他のネットワークタイプやアドレスタイプの場合、同一のプロパ ティを持つアドレスを使用すべきである[SHOULD]。 推奨したフローを含め、ほとんどの場合、ユーザーAは、Bへの発呼が完了する 間に、何も聞こえなくなる。これは常に理想的とは言えない。これは、Bへの 発呼中に、発呼側を保留音のソースへ接続することで改善できる。 6. エラー制御 議論に値するエラー例は数多くある。 セクション4のすべてのコールフローで、Aに対して1つの呼が確立されてか ら、コントローラはBに対する呼を確立しようとする。ただし、この呼の試行 は、数多くの理由によって失敗する場合がある。ユーザーBが通話中の場合 (INVITEに対する486応答という結果)、共通するメディアが存在しない場合、 リクエストがタイムアウトする場合などである。Bに対する呼の試行が万が一 失敗した場合は、コントローラはAに対してBYEを送信することが推奨される [RECOMMENDED]。このBYEには、エラー応答にあったステータスコードを指定し た、Reasonヘッダー(参考文献[5])を含めるべきである[SHOULD]。これによ り、Aに対して、エラーの正確な理由を通知する。この情報は、ユーザーイン ターフェースの観点から重要である。たとえば、Aが黒電話から発呼してBが 486を生成した場合、BYEには486の理由コードが含まれる。これはローカルの ビジー信号を生成するときに使用できるため、AはBが通話中であることがわか る。 A コントローラ 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 | | |--------------------->| | 図5 Rosenberg, et al. Best Current Practice [Page 10] RFC 3725 SIP 3pcc April 2004 議論に値する別のエラー条件を、図5に示す。コントローラは、Aとのダイアロ グを確立した後に(メッセージ1〜3)、Bとのコンタクトを試みる(メッセージ 4)。Bとのコンタクトには、いくらか時間がかかる可能性がある。その間に、A が、オファーを更新して、re-INVITEを試行する可能性がある。ただし、コン トローラは、保留中のINVITEトランザクションがあるため、このオファーをB に渡すことはできない。結果として、コントローラはこのリクエストを拒否す る必要がある。491応答の使用が推奨される[RECOMMENDED]。この状況は、参考 文献[1]に記載されているにらみ合い(glare)条件と似ているため、同じエラー 制御が理にかなっている。ただし、Aは、(491の結果として)このリクエストを 再試行する可能性が高く、また、Bとのやり取りが完了する前に再試行される 可能性がある。この場合、コントローラは、もう1度、491で応答する。 7. 継続処理 呼が確立すると、両方の参加者は、1つのポイントツーポイントの通話中であ ると思っている。ただし、メディアは、コントローラ経由ではなく、互いと直 接に交換している。コントローラは、2つのダイアログ ボックスに関わるが、 メディアは確認しない。 それでも、コントローラはシグナリングの中心点なので、呼全体を完全に制御 している。コントローラは参加者の一方からBYEを受信すると、新規のBYEを作 成してもう一方の参加者との呼を切断することができる。これは、図6に示さ れる。 A コントローラ B |(1) BYE | | |------------------>| | |(2) 200 OK | | |<------------------| | | |(3) BYE | | |------------------>| | |(4) 200 OK | | |<------------------| 図6 同様に、re-INVITEを参加者の一方から受信すると、それをもう一方の参加者 に転送できる。使用するフローによっては、SDPを渡す前に、何らかの操作を 行う必要がある。 ただし、コントローラは、参加者の一方から受信したSIPメッセージを「プロ キシ」する必要はない。これはバックトゥバックユーザーエージェント(Back- to-Back User Agent/B2BUA)なので、適切であれば、各ダイアログごとに任意 のシグナリングメカニズムを呼び出すことができる。たとえば、コントローラ は、AからBYEを受信すると、新規のINVITEをサードパーティCに対して生成 Rosenberg, et al. Best Current Practice [Page 11] RFC 3725 SIP 3pcc April 2004 し、Aの代わりにBをその参加者に接続することができる。このコールフローは 図7に示す。ここでは、Cがオートマタではなくエンドユーザーであると想定す る。これは、単なるフローIVであることに注意。 A コントローラ 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 | | | |................| 図7 ここから、コントローラで適切と思われれば、新規のパーティの追加、削除、 転送などが可能になる。多くの場合、このような変更に影響を与えるために、 コントローラは、参加者間で交換されるSDPを修正する必要が出てくる。特 に、SDPのバージョン番号は、特定のケースで、コントローラが変更する必要 がある。万が一、コントローラがSDPオファーを独自に発行する場合(たとえ ば、呼を保留する目的で)、SDPオファーのバージョン番号をインクリメント する必要がある。呼のもう一方の参加者は、コントローラがこれを実行したこ とがわからず、以降に生成するオファーには、相手側から見ると誤ったバー ジョン番号が含まれる。結果として、コントローラは、受信側が期待する値と 一致するように、SDPメッセージのバージョン番号を修正する必要が出てく る。 Rosenberg, et al. Best Current Practice [Page 12] RFC 3725 SIP 3pcc April 2004 このセクションの処理を使用するために、コントローラによって呼を確立する 必要はない、という点に注目することが重要である。より正確に言うと、AがB に対する(または逆方向で)呼を確立する間、コントローラは、B2BUAとして動 作することができる。 8. 3pccと初期メディア 初期メディア(early media)では、(オファー/アンサーの交換が完了した結果 として)セッションを確立する条件を示すが、呼自体は承認されていない。初 期メディアは、通常、呼の進度に関する発信音や告知を伝達するために使用さ れる。サードパーティの呼における初期メディアの処理方法は単純である。 Rosenberg, et al. Best Current Practice [Page 13] RFC 3725 SIP 3pcc April 2004 A コントローラ B | | | |(1) INVITE offer1 | | |no media | | |<---------------------| | | | | | | | | | | | | | | | | |(2) 200 answer1 | | |no media | | |--------------------->| | |(3) ACK | | |<---------------------| | | |(4) INVITE no SDP | | |--------------------->| | | | | |(5) 183 offer2 | | |<---------------------| |(6) INVITE offer2' | | |<---------------------| | |(7) 200 answer2' | | |--------------------->| | |(8) ACK | | |<---------------------| | | |(9) PRACK answer2 | | |--------------------->| | |(10) 200 PRACK | | |<---------------------| |(11) RTP | | |.............................................| | | | | |(12) 200 OK | | |<---------------------| | |(13) ACK | | |--------------------->| 図8 図8は、電話に出る前に、ユーザーBが初期メディアを生成する場合を示す。フ ローは、図4のフローIVとほとんど同じである。唯一の違いは、ユーザーBが、 最終応答ではなく信頼性のある暫定応答(参考文献[6])を生成する(6)点と、 answer2がACKではなくPRACKで伝達される(9)点である。最終的に、パーティB が呼を受け入れた(12)とき、セッションステートに変更はなく、また、した がって、ユーザーAに関して実行する実行が必要なシグナリングはない。コン トローラは、200 OKをACKし(13)、ダイアログを確認するだけである。 Rosenberg, et al. Best Current Practice [Page 14] RFC 3725 SIP 3pcc April 2004 A コントローラ 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 | | |<---------------------| | 図9 ユーザーAが初期メディアを生成する場合は、より複雑になるが、図9に示す。 フローは、フローIVに基づく。コントローラは、何もメディアストリームを含 まないINVITEを、ユーザーAへを送信する(1)。ユーザーAは、メディアスト リームを含まないアンサーが指定された、信頼性のある暫定応答を送信する (2)。コントローラは、この暫定応答をPRACKする(3)。ここで、コントローラ Rosenberg, et al. Best Current Practice [Page 15] RFC 3725 SIP 3pcc April 2004 は、ユーザーBへSDPなしのINVITEを送信する(5)。ユーザーBの電話が鳴り、B が電話に出ると、オファー(offer2)が指定された200 OK(6)という結果にな る。ここで、コントローラは、ユーザーAのセッションパラメータを更新する 必要がある。ただし、電話にはまだ出ていないため、コントローラはre- INVITEを使用できない。代わりに、コントローラは、SIPのUPDATEリクエスト (参考文献[7])を使用して(7)、(origin-fieldを正しく修正した後で)オファー を渡す。ユーザーAは、UPDATEに対して、200 OKのアンサーを生成する(8)。こ のアンサーは、ACKでユーザーBに渡される(9)。ユーザーAが最終的にアンサー (11)したとき、セッションステートに変更はないため、コントローラでは、単 純に200 OKをACKするだけである(12)。 このコールフローでは、メディアの省略が発生する可能性が高いということに 注意。ユーザーAは、PSTNゲートウェイである可能性が高く、また、PSTN側か らの初期メディアのために、暫定応答を生成した。PSTNは、ゲートウェイがど こにも送信しなくても、このメディアを配信する。これは、コントローラから の最初のオファーにメディアストリームがないためである。ユーザーBが電話 に出ると、メディアを流しはじめることができる。ただし、この時点までに PSTNからゲートウェイに送信されたメディアは、失われる。 9. サードパーティ呼制御とSDPの前提条件 シグナリングのカップリングとリソース予約(参考文献[2])が可能なSIP拡張が 指定されていること。この仕様は、呼の確立が完了する前に、セッション記述 がされることに依存している。このようなフローは、特定のSDPパラメータが 最初のINVITEで渡されると、初期化される。そのため、このメカニズムとサー ドパーティ呼制御との相互作用は明確ではなく、詳しく指定することが望まし い。 9.1. コントローラが初期化 ある使用例で、セクション4.4で説明されている呼のエラーシナリオを防ぐた めに、コントローラで前提条件を使用したいと考えている。特に、共通するメ ディアとコーデックがなければ、どちらのパーティも確実にアラートされない ようにする目的で、コントローラは前提条件を使用できる。また、コントロー ラは、両パーティが呼を受け入れる前に、呼のメディア構成に関する情報を両 パーティに提供することもできる。 Rosenberg, et al. Best Current Practice [Page 16] RFC 3725 SIP 3pcc April 2004 ユーザーA コントローラ カスタマサービス (ユーザーB) | | | |(1) INVITE no SDP | | |require precon | | |<------------------| | |(2) 183 offer1 | | |optional precon | | |------------------>| | | | | | |(3) INVITE offer1 | | |------------------>| | | | | | | | | | | |(4) 200 OK answer1 | | |no precon | | |<------------------| | |(5) ACK | | |------------------>| |(6) PRACK answer1 | | |<------------------| | | | | | | | |(7) 200 PRACK | | |------------------>| | | | | | | | |(8) 200 INVITE | | |------------------>| | |(9) ACK | | |<------------------| | 図10 このシナリオのフローを図10に示す。この例では、ユーザーBを、呼に直ちに 応答するオートマタまたは何らかのエージェントであると想定している。した がって、このフローは、フローIに基づく。コントローラは、SDPを含まない が、この前提条件を示すRequireヘッダーを必要とする、INVITEをユーザーAに 送信する。この具体的なシナリオ(オファーなしだが、前提条件を示すRequire ヘッダーを含むINVITE)については、参考文献[2]では説明されていない。UAS は、呼に使用すること、および、それぞれに対して、オプションとして対応す る前提条件すべてを一覧することを望むメディアストリームを、1xxに含めた オファーで応答することが推奨される[RECOMMENDED]。当然ながら、この時点 では、ユーザーにアラートしない。コントローラは、このオファーを受けて、 ユーザーBに渡す(3)。ユーザーBは、前提条件をサポートしてもしなくても、 Rosenberg, et al. Best Current Practice [Page 17] RFC 3725 SIP 3pcc April 2004 その点については関与しない。したがって、ユーザーBが呼に応答するとき は、200 OKに前提条件が列挙されていないアンサーを含める(4)。このアン サーは、PRACKでユーザーAに渡される(6)。この時点で、Aは、呼で実際に使用 される前提条件がないため、ユーザーにアラートできる、ということがわか る。電話に出るとき、ユーザーAは200 OKをコントローラに送信(8)し、呼が確 立する。 ユーザーBは、ユーザーAが生成したオファーを受け入れられなかった場合(た とえば、共通するコーデックやメディアがない場合など)、ユーザーBは直ちに INVITEを拒否する(メッセージ3)。コントローラは、ユーザーに対し、リクエ ストをCANCELする。この場合、ユーザーAにもユーザーBにもアラートされない が、これは意図した結果通りである。どのような種類の前提条件をユーザーA がサポートしていなくても、前提条件を使用してこの特性が達成されるという 点は興味深い。 また、当然ながら、ユーザーBは実際に前提条件を希望しているという可能性 もある。その場合、ユーザーBは、自身で前提条件をアンサーに含めて1xxを生 成する可能性がある。このアンサーはユーザーAに渡され、両パーティは、前 提条件に適合するために必要な手段が何であろうと、それを進める。前提条件 に適合するまで、どちらのユーザーもアラートされない。 9.2. パーティAが初期化 セクション9.1では、コントローラが、特定の目標を達成する前提条件の使用 をリクエストした。コントローラが前提条件に配慮しなくても(おそらく、知 らなくても)、呼の一方のパーティが配慮することも可能である。この場合の コールフローを図11に示す。 A コントローラ 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 | Rosenberg, et al. Best Current Practice [Page 18] RFC 3725 SIP 3pcc April 2004 | |<---------------------| |(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 | | |<---------------------| | | | | | |(17) UPDATE offer4 | | |des=sendrecv | Rosenberg, et al. Best Current Practice [Page 19] RFC 3725 SIP 3pcc April 2004 | |conf=recv | | |cur=sendrecv | | |<---------------------| |(18) UPDATE offer4' | | |des=sendrecv | | |conf=recv | | |cur=sendrecv | | |<---------------------| | | | | |(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 | | |<---------------------| | | | |(23) 200 INVITE | | |--------------------->| | |(24) ACK | | |<---------------------| | | | | | |(25) 200 INVITE | | |<---------------------| | |(26) ACK | | |--------------------->| 図11 コントローラは、フローIVに従う。つまり、コントローラには、前提条件仕様 のサポートについて、特定の要件はない(参考文献[2])。したがって、コント ローラはメディア行を含まないSDPを指定したINVITEを送信する。ユーザーA は、前提条件をサポートすることに関心があり、リソースが予約されるまで電 話を鳴らしたくない。INVITEにメディアストリームがないため、メディアスト リーム用のリソースを予約できず、以降のオファーでメディアストリームが伝 達されて予約されるまで、電話を鳴らせない。したがって、ユーザーAはアン サー付きの183を生成し、ユーザーにアラートしない(2)。コントローラは、こ れをPRACKし(3)、AはPRACKに応答する(4)。 Rosenberg, et al. Best Current Practice [Page 20] RFC 3725 SIP 3pcc April 2004 この時点で、コントローラは、Bを呼に参加させようとする。コントローラはB に、SDPなしのINVITEを送信する(5)。Bは、この呼に前提条件を持つことに関 心がある。したがって、ユーザーBは、適切なSDP属性を含む183に、オファー を生成する(6)。コントローラは、ユーザーAに、UPDATEリクエストでこのオ ファーを渡す(7)。コントローラがUPDATEを使用するのは、まだ呼に応答され ていないので、re-INVITEを使用できないためである。ユーザーAは、相手が前 提条件をサポート可能であることがわかる。ユーザーAは、呼の前提条件を希 望しているため、UPDATEに対して、200 OKのアンサーを生成する(8)。このア ンサーは、暫定応答のPRACKで同様にユーザーBへ渡される(9)。ここで、両 パーティがリソースの予約を実行する。ユーザーAが最初に成功し、UPDATEリ クエストで更新されたセッション記述を渡す(13)。コントローラは、(フロー IVで必要とされているように、オリジンフィールドを操作した後に)これを UPDATEでB(※)にそのまま渡し、そのアンサー(3)をAに渡す(16)[※訳注: 原文 はAですが、フロー図はBなのでフロー図に合わせました]。Bの予約が成功する と、BからAへ同じフローが発生する(17〜20)。前提条件が適合したため、両 パーティは電話を鳴らし(21と22)、両パーティが電話に出ると(23と25)、通話 が確立する。 このフローで重要な点は、コントローラが前提条件のことを何も知らない、と いうことである。コントローラは、必要に応じて両方向にSDPをそのまま渡す だけである。このフローが機能するのは、必要なときにSDPを渡すUPDATEと PRACKの用法である。この判断は、参考文献[6]と[7]に記載されているオ ファー/アンサー規則にのみ基づいて行われ、前提条件からは独立している。 10. コールフロー例 10.1. クリックトゥダイヤル まず、本書で論ずる機能を持つアプリケーションとして、クリックトゥダイヤ ル(click-to-dial)を挙げる。このサービスでは、ユーザーはeコマースサイト のWebページを閲覧しており、カスタマサービスの代表に電話をかけたいと考 えている。ユーザーがリンクをクリックすると、カスタマサービスの代表に発 呼される。代表が応答すると、ユーザーの机にある電話が鳴る。ユーザーが電 話に出ると、カスタマサービスの担当者がユーザーと通話するために待機して いる。 Rosenberg, et al. Best Current Practice [Page 21] RFC 3725 SIP 3pcc April 2004 カスタマサービス コントローラ ユーザーの電話 ユーザーのブラウザ | |(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 | | | |.......................................| | 図12 このサービスのコールフローを図12に示す。このフローは、ユーザーがリンク をクリックしたときに、HTTPのPOSTリクエストによってサービスがトリガされ る、という部分を以外は、図4と同一である。通常、このPOSTリクエストに は、ユーザーの番号またはカスタマサービスの代表番号が含まれる。ユーザー の番号は、一般的に、Webアプリケーションによってバックエンドデータベー スから取得される。これは、ユーザーが、必要な情報をサーバーに指定して、 サイトにログインしていると推定されるためである。カスタマサービスの番号 は、一般的に、格納していた情報から取得される。そのため、HTTP POSTで は、実際のところ、サーバーに対して発呼希望を示す以外に何も提供していな い。 このサービスは、PINT(参考文献[9])など、他のメカニズムを使用しても実現 できるということに注意すること。ただし、PINTがサービスを提供する方法 と、本書で提供する方法とには、数々の違いがある。 Rosenberg, et al. Best Current Practice [Page 22] RFC 3725 SIP 3pcc April 2004 o PINTソリューションは、2つのPSTNエンドポイント間でのみ、呼を有効にす る。本書で説明するソリューションでは、PSTN電話(SIP対応のゲートウェ イ経由)とネイティブIP電話との通話が可能である。 o 2つのPSTN電話間の通話で使用される場合、本書のソリューションは、呼の 一部がインターネット上でルートされる結果になる可能性がある。PINTで は、呼は常にPSTN上でのみルートされる。使用するコーデックと、呼のイ ンターネット部分をルーティングするネットワークのQoS能力に左右される ため、PINTソリューションを使用する方が通話品質が高くなる場合があ る。 o PINTソリューションには、SIPの拡張が必要である(PINTはSIPの拡張であ る)。一方で、本書で説明しているソリューションは、基本のSIPで実行で きる。 o PINTソリューションでは、呼が確立した後は、コントローラ(PINTクライア ントとして動作)は「手を引く」ことができる。本書で説明するソリュー ションでは、呼の継続時間全体で、コントローラが呼の状態を維持する必 要がある。 10.2. 通話中のアナウンス機能 本書で説明するサードパーティ呼制御メカニズムは、通話中のアナウンスを有 効にするために使用することもできる。プリペイド通話カードのサービスを例 に説明する。プリペイド通話が確立すると、システムでは、分数がなくなった ときにタイマーで合図するように設定する必要がある。このタイマーで合図さ れたときに、ここでは、ユーザーに対して、通話を続けるにはクレジットカー ド番号の入力が必要であると通知するアナウンスを流したい。クレジットカー ド番号が入力されると、プリペイドカードの残金が追加され、ユーザーは通話 相手に再接続される。 ここでは、サードパーティ呼制御を、クレジットカード番号を収集するための 通話中ダイアログを機能させるためにだけ使用している。 Rosenberg, et al. Best Current Practice [Page 23] RFC 3725 SIP 3pcc April 2004 プリペイドユーザー コントローラ 着呼側 メディアサーバー | |(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 | | | |.......................................| | 図13 ここでは、コントローラをB2BUAとして呼に参加するように、呼を確立したと 想定する。タイマーから合図があった場合、発呼側をメディアサーバーに接続 させたい。このフローを図13に示す。タイマーの有効期限が切れると、コント ローラは、着呼側を0.0.0.0の接続アドレスにする(1)。これは、実質的に、着 呼側の「切断」である。次に、コントローラは、プリペイドユーザーにSDPな Rosenberg, et al. Best Current Practice [Page 24] RFC 3725 SIP 3pcc April 2004 しのINVITEを送信する(4)。発呼側から帰ってくるオファー(5)は、数値を収集 するメディアサーバーに対するINVITE(6)で使用される。これは、フローIのイ ンスタンス化である。このフローは、ここでのみ使用できる。その理由は、メ ディアサーバーがオートマタであり、INVITEに対して直ちに応答するためであ る。コントローラが、プリペイドユーザーを別のエンドユーザーと接続してい た場合、フローIIIを使用する必要がある。メディアサーバーは、アンサーを を含む200 OK(7)を直ちに返し、発呼側にACK(8)で渡される。結果として、メ ディアサーバーとプリペイドの発呼側は、メディアストリームが接続される。 メディアサーバーはアナウンスを再生し、ユーザーにクレジットカード番号を 入力するように指示する。番号を収集すると、カード番号が検証される。次 に、メディアサーバーは、(本仕様の範囲外の手段を使用して)カード番号をコ ントローラに渡し、電話を切る(11)。 メディアサーバーの電話が切れると、コントローラはユーザーを元の着呼側と 再接続する。これを実行するには、コントローラは、着呼側へSDPなしの INVITEを送信する(13)。200 OK(14)には、オファー(offer3)が含まれる。コン トローラはSDPを修正し(フローIIIと同様)、INVITEのオファーをプリペイド ユーザーに渡す(15)。プリペイドユーザーは200 OKでアンサーを生成し(16)、 コントローラはそれをACKでユーザーBに渡す(17)。この時点で、発呼側と着呼 側が再接続される。 11. 実装上の推奨 サードパーティ呼制御への対応に関係する作業のほとんどは、コントローラの ものである。標準的なSIP UAは、本書で説明するメカニズムを使用して制御可 能であるべきである。ただし、サードパーティ呼制御は、実装されない可能性 のあるいくつかの機能に依存する。したがって、ユーザーエージェントサー バーの実装者は、以下に対応することが推奨される[RECOMMENDED]。 o 0.0.0.0のアドレスを指定した接続行を含むオファーとアンサー o ポートについて、メディアを送信すべき場所に変更したre-INVITEリクエス ト o 接続アドレスが変更されたre-INVITE o メディアストリームが追加されたre-INVITE o メディアストリームが削除されたre-INVITE(ポートが0に設定されている) o メディアストリームのセットにコーデックが追加されたre-INVITE Rosenberg, et al. Best Current Practice [Page 25] RFC 3725 SIP 3pcc April 2004 o 0のSDP接続アドレス o 0の接続アドレスが指定された最初のINVITEリクエスト o SDPが指定されていない最初のINVITEリクエスト o SDPは指定されているがメディア行がない最初のINVITEリクエスト o SDPが指定されていないre-INVITE o UPDATEメソッド(参考文献[7]) o 信頼性のある暫定応答(参考文献[6]) o リソース管理とSIPの統合(参考文献[2]) 12. セキュリティの考慮 12.1. 認可と認証 SIP INVITEのほとんどの用法では、呼が受け入れられるかどうかは、呼に関す る情報(発呼側の身元など)が提示されたときに、人間が判断を下す。他の場 合、オートマタが呼に応答することになるが、そうするかどうかは、SIPを適 用する具体的なアプリケーションに依存する可能性がある。たとえば、発呼側 が、ボイスポータルサービスに対してSIPで発呼する場合、発呼側があらか じめ(おそらくWebサイト経由で)サインアップしていないと、呼が拒否される 可能性がある。他の場合、CPL(Call Processing Language/(参考文献[11]))な どで記述された自動スクリプトに基づいて、呼の操作ポリシーが作成される。 このような判断は、発呼側の身元に基づいて行われることが多い。 この認可メカニズムは、通常の第1パーティによる呼とサードパーティによる 呼に適用される(この2つは区別できないため)。結果として、サードパーティ による呼を正しく操作し続けるには、この認可ポリシーが重要である。当然な がら、サードパーティによる呼で、新規のパーティ(サードパーティの呼を開 始するパーティ)が導入される。このサードパーティの身元に基づいて認可ポ リシーを適用するか、それとも呼の参加者に基づいて認可ポリシーを適用する か。参加者は、両パーティの身元を知ることができ、その身元に基づく適切な 認可ポリシーを持っていることが理想である。ただし、これは既存のメカニズ ムを使用しても可能ではない。結果として、次善の方法は、INVITEリクエスト にサードパーティの身元を含めることである。最終的に、サードパーティが通 信をリクエストをしているユーザーであるため、その身元に基づく呼の認可ポ リシーは筋が通っている。 Rosenberg, et al. Best Current Practice [Page 26] RFC 3725 SIP 3pcc April 2004 言い替えると、コントローラは、自分自身をサードパーティとして認証する必 要がある。これは困難な場合があり、適切なメカニズムはアプリケーション独 自のシナリオに依存する。 一般的なシナリオを1つ挙げると、コントローラが、呼の参加者の1つの代わり に動作している場合である。一般的な例は、クリックトゥダイヤルである。ク リックトゥダイヤルでは、コントローラとカスタマサービスの代表は、同じ管 理ドメインで実行されている。実際、身元特定の目的では、コントローラは、 カスタマサービスの代表であると正当に主張することができる。このシナリオ では、エンドユーザーに対するINVITEにカスタマサービスの代表を示すFrom フィールドを含め、さらに、カスタマサービスの代表のキー(コントローラが 保持)で署名されたS/MIME(RFC3261[1]のセクション23を参照)を使用してリク エストを認証するのが適切である。 これには、コントローラが、自分自身をカスタマサポートの代表として認証で きる資格情報(credential)を実際に保持している必要がある。その他の多くの 場合、コントローラは、参加者のいずれかを代表しているが、参加者の資格情 報を所有してはいない。残念ながら、用法を特定のサードパーティ呼制御の操 作に限定して、ユーザーが資格情報をコントローラに委任できる標準的なメカ ニズムは、現在のところ存在しない。このようなメカニズムがない場合、最善 の方法は、Fromフィールドに表示名を使用して、発呼を代理しているユーザー の身元を示すことである。表示名は、「[user]を代理する[controller]」 ([controller] on behalf of [user])と設定することが推奨される [RECOMMENDED](この「user」と「controller」は、それぞれユーザーとコント ローラを示すテキスト)。この場合、FromフィールドのURIは、コントローラを 示す。 他の場合、コントローラと呼の参加者間に実際の関係は何もない。このような 状況では、特定の身元(アプリケーションによって、これは参加者の1つか、 サードパーティの可能性がある)からの呼であるとコントローラが主張し、コ ントローラのキーを使用した署名付きでその主張をコントローラが検証する手 段があるのが理想である。 12.2. エンドトゥエンドの暗号化と整合性 サードパーティ呼制御を使用する場合、SIPダイアログが関わる限り、実際の ところ、コントローラは参加者の1つである。したがって、SIPメッセージの暗 号化と整合性(S/MIMEによる)は、参加者間で直接実現するのではなく、参加者 とコントローラ間で実現する。 ただし、メディアセッションの整合性、認証、信頼性は、コントローラによっ て実現できる。エンドトゥーエンドのメディアセキュリティは、SDP内のキー 材料の交換に基づく(参考文献[10])。 Rosenberg, et al. Best Current Practice [Page 27] RFC 3725 SIP 3pcc April 2004 このようなメカニズムをサードパーティ呼制御で正しく操作するには、コント ローラが適切に動作する必要がある。このようなメカニズムを明示的に無効に しようとしない限り、プロトコルは参加者間で正しく機能し、結果として、コ ントローラが盗聴(eavesdrop)や修正できなくても、メディアセッションのセ キュリティが保護される。サードパーティ呼制御は、ユーザーとコントローラ 間の信頼モデルに基づいているため、仕様に従った方法で機能していると推定 するのが妥当である。ただし、コントローラがキー材料の最初の交換を邪魔す るのを防ぐことができる暗号化方法はない。結果的に、コントローラが望む 場合、自身をメディア交換の仲介者として挿入することは容易である。 13. 謝辞 Paul Kyzivat、Rohan Mahy、Eric Rescorla、Allison Mankin、Sriram Parameswarの各氏からいただいたコメントに感謝を述べたい。 14. 参考文献 14.1. 規範となる参考文献 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Camarillo, G., Ed., Marshall, W., Ed. and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [5] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. Rosenberg, et al. Best Current Practice [Page 28] RFC 3725 SIP 3pcc April 2004 14.2. 有益な参考文献 [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [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. [10] Andreasen, F., Baugher, M. and D. Wing, "SDP Security Descriptions for Media Streams", Work in Progress, October 2003. [11] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services", Work in Progress, August 2003. Rosenberg, et al. Best Current Practice [Page 29] RFC 3725 SIP 3pcc April 2004 15. 著者の連絡先 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 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 EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Rosenberg, et al. Best Current Practice [Page 30] RFC 3725 SIP 3pcc April 2004 16. 完全な著作権表示 Copyright (C) The Internet Society (2004). 本文書は、BCP 78に含まれる 権利、ライセンス、制限を前提としており、BCP 78に記載されている事項を除 き、本書の著者はすべての権利を有する。 本文書と含まれる情報は、「保証なし(AS IS)」原則で提供される。また、寄 稿者、寄稿者が代表する組織、または(存在する場合)寄稿者のスポンサーであ る組織、インターネット協会(Internet Society)およびIETF(Internet Engineering Task Force)は、本書の情報の使用が、特定用途に関する商品適 格性または適合性の何らかの権利または暗示される保証を侵害しない、という 保証をはじめとして、すべての保証(明示または暗示)を放棄する。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書に関する手順の情報は、BCP78とBCP79を参照のこと。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ る。 IETFは、本規格の実装に必要になる可能性がある技術の範囲に及ぶ可能性があ る、任意の著作権、特許、特許アプリケーション、その他の所有権への配慮 を、関係者に依頼している。情報については、IETFの ietf-ipr@ietf.org ま で連絡されたい。 謝辞 RFC編集者職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2004年 ----------------------------------------------------------------------- Rosenberg, et al. Best Current Practice [Page 31]