Network Working Group G. Camarillo Request for Comments: 4117 Ericsson Category: Informational E. Burger Brooktrout H. Schulzrinne Columbia University A. van Wijk Viataal June 2005 サードパーティ呼制御(3pcc)を使用した セッション開始プロトコル(SIP)における トランスコーディングサービスの呼び出し Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc) 本文書の位置付け 本文書は、インターネットコミュニティに情報を提供するためのものであ る。いかなるインターネット標準も規定しない。本文書の配信は無制限で ある。 著作権表記 Copyright (C) The Internet Society (2005). 概要 本文書は、セッション開始プロトコル(Session Initiation Protocol/SIP)と サードパーティ呼制御を使用してトランスコーディングサービスを呼び出す 方法について説明する。この呼び出し方法は、トランスコーディングサービ スに関して、SIPが失聴者、難聴者、言語障害者を支援するための要件を満 たしている。 目次 1. はじめに ..................................................... 2 2. 概要 ......................................................... 2 3. サードパーティ呼制御フロー ................................... 2 3.1. 用語 ..................................................... 3 3.2. 着呼側による呼び出し ..................................... 3 3.3. 発呼側による呼び出し ..................................... 8 3.4. 元のストリームの受信 ..................................... 8 3.5. 並行するトランスコーディングサービス .................... 10 3.6. 連続するトランスコーディングサービス .................... 14 4. セキュリティの考慮事項 ...................................... 16 5. 規範となる参考文献 .......................................... 17 6. 有益な参考文献 .............................................. 17 Camarillo, et al. Informational [Page 1] RFC 4117 3pcc Transcoding in SIP June 2005 1. はじめに SIPを使用したトランスコーディングのフレームワーク[4]には、2つのSIP [1] UA (User Agent)が、セッションの確立を邪魔する不適合を検出する方 法について説明している。このような不適合が見つかった場合、セッション を正常に確立するにす、UAはトランスコーディングサービスを呼び出す必要 がある。3pcc (third party call control/サードパーティ呼制御) [2]は、 このような呼び出しを実行する1つの方法である。 2. 概要 トランスコーディングを呼び出す3pccモデルでは、特定のトランスコーディ ングサービス(音声からテキストへの変換など)を提供するトランスコーディ ングサーバーは、URIによって識別される。そのサービスを呼び出したいUA は、INVITEリクエストをそのURIに送信して、複数のメディアストリームを 確立する。トランスコーダがメディアストリームのコンテンツを操作および 管理する方法(たとえば、テキストストリームで受信したテキストを音声に 変換し音声ストリームで送信するなど)は、サービスによって異なる。 本文書のすべてのコールフローにはSDPを使用している。同様のセッション 記述機能を提供する別のセッション記述プロトコルに、同じコールフローを 使用できることもある。 3. サードパーティ呼制御フロー 2つのUA (AとB)、トランスコーディングサーバー(T)があり、トランスコー ディングサービスの呼び出しは、A-T間、T-B間という2セッションの確立で 構成される。このようなセッションを確立する方法は、どちらのパーティ (発呼側(A)または着呼側(B))がトランスコーディングサービスを呼び出すか によって変わる。セクション3.2では着呼側による呼び出し、セクション3.3 では発呼側による呼び出しについて扱っている。 本文書の3pccフローはすべて、着呼側に接続する前にトランスコーディン グサービスから200 (OK)応答を受信しなければならない、という一般的な原 則に従っている。ここでは、着呼側がセッションを受け入れたときに、トラ ンスコーディングサービスが利用できるように試みている。 それでも、着呼側がセッションを受け入れるまで、トランスコーディング サービスは実行するトランスコーディングの具体的な種類を認識していな い。そのため、着呼側がセッションを受け入れた後に、トランスコーディン グサービスの提供に失敗する可能性は常にある。より厳密な要件があるシス テムの場合、前提条件を使用してこのような状況を回避する可能性がある。 事前条件を使用する場合、セッションの準備がすべて整うまで、着呼側には 通知されない。 Camarillo, et al. Informational [Page 2] RFC 4117 3pcc Transcoding in SIP June 2005 3.1. 用語 本文書のすべてのフローは、以下の命名規則に従う。 SDP A: Aが生成したセッション記述。特に、Aが各特定ストリームのメ ディアを受信するトランスポートアドレス(IPアドレスとポート 番号、複数の場合もあり)などである。 SDP B: Bが生成したセッション記述。特に、Bが各特定ストリームのメ ディアを受信するトランスポートアドレス(複数の場合もあり) などである。 SDP A+B: 特に、Aがメディアを受信するトランスポートアドレス(複数の 場合もあり)とBがメディアを受信するトランスポートアドレス (複数の場合もあり)を含むセッション記述。 SDP TA: Tが生成し、Aを対象とするセッション記述。 特に、TがAからのメディアを受信するトランスポートアドレス (複数の場合もあり)などである。 SDP TB: Tが生成し、Bを対象とするセッション記述。 特に、TがBからのメディアを受信するトランスポートアドレス (複数の場合もあり)などである。 SDP TA+TB: 特に、TがAからのメディアを受信するトランスポートアドレ ス(複数の場合もあり)と、TがBからのがメディアを受信するト ランスポートアドレス(複数の場合もあり)を含む、Tが生成した セッション記述。 3.2. 着呼側による呼び出し このシナリオでは、BはAからのINVITEを受信し、BはセッションにTを招待す ることを決定する。図1は、このシナリオのコールフローである。 図1では、Aは聴覚と発声の両方が可能だが、Bは言語障害がある失聴者であ る。Aは、音声ストリームを構成するセッションを確立することを提案す る(1)。Bは、テキストのみを送受信することを希望しているため、トラン スコーディングサービスTを呼び出す。このTは音声からテキストへの変換と テキストから音声への変換を実行する(2)。図1のセッション記述の一部を以 下に示す。 Camarillo, et al. Informational [Page 3] RFC 4117 3pcc Transcoding in SIP June 2005 A T B | | | |--------------------(1) INVITE SDP A-------------------->| | | | | |<---(2) INVITE SDP A+B------| | | | | |---(3) 200 OK SDP TA+TB---->| | | | | |<---------(4) ACK-----------| | | | |<-------------------(5) 200 OK SDP TA--------------------| | | | |------------------------(6) ACK------------------------->| | | | | ************************** | ************************** | |* MEDIA *|* MEDIA *| | ************************** | ************************** | | | | 図1: トランスコーディングサービスの着呼側による呼び出し (1) INVITE SDP A m=audio 20000 RTP/AVP 0 c=IN IP4 A.example.com (2) INVITE SDP A+B m=audio 20000 RTP/AVP 0 c=IN IP4 A.example.com m=text 40000 RTP/AVP 96 c=IN IP4 B.example.com a=rtpmap:96 t140/1000 (3) 200 OK SDP TA+TB m=audio 30000 RTP/AVP 0 c=IN IP4 T.example.com m=text 30002 RTP/AVP 96 c=IN IP4 T.example.com a=rtpmap:96 t140/1000 (5) 200 OK SDP TA m=audio 30000 RTP/AVP 0 c=IN IP4 T.example.com Camarillo, et al. Informational [Page 4] RFC 4117 3pcc Transcoding in SIP June 2005 以下の4つのメディアストリーム(つまり2つの双方向ストリーム)がこの時点 で確立された。 1. AからT.example.com:30000に対する音声 2. TからB.example.com:40000へのテキスト 3. BからT.example.com:30002へのテキスト 4. TからA.example.com:20000へのテキスト AまたはBがセッションの終了を決定した場合、セッションが終了したことを 示すBYEを送信する。 Bが受信する最初のINVITE (1)が空の(セッション記述がない)場合、この コールフローは少し変わる。図2に、関連するメッセージを示す。 Bには、Aのセッション記述を知る前にTを呼び出す理由が別にある可能性が ある。Bはネイティブ機能がないことを隠したいために、Bが対応するすべて のコーデック、およびTが対応するすべてのコーデックを指定したセッション 記述を返す場合がある。また、Tが(トランスコーディングとは別に)記録サー ビスを提供したり、BがTに対して、トランスコーディングが必要かどうかに かかわらず、会話を記録するように求めたりする場合がある。 このシナリオ(図2)は、前のシナリオよりもやや複雑である。 INVITE (2)では、BはSDP Aをまだ持っていないため、Tにその情報を提供で きない。最終的にBがSDP Aを受信すると(6)、Tにそれを送信する。Bは空の INVITEをTに送信し(7)、SDP TA+TBを含む200 OKを受け取る(8)。一般的に、 このSDP TA+TBは(3)で送信されたものとは異なる。これは、Bは更新したSDP TAをAに送信する(9)必要があるためである。次に、Aは更新された可能性が あるSDP Aを送信し(10)、BはそれをTに送信する(12)。一方、Tが偶然に(3) と同じSDP TA+TBを返した場合(8)、Bはメッセージ(9)、(10)、(11)をスキッ プすることができる。そのため、トランスコーディングサービスの実装者 は、このようなシナリオでは(3)と同じセッション記述を返す(8)ことが推奨 される。このフローのセッション記述を以下に示す。 Camarillo, et al. Informational [Page 5] RFC 4117 3pcc Transcoding in SIP June 2005 A T B | | | |----------------------(1) INVITE------------------------>| | | | | |<-----(2) INVITE SDP B------| | | | | |---(3) 200 OK SDP TA+TB---->| | | | | |<---------(4) ACK-----------| | | | |<-------------------(5) 200 OK SDP TA--------------------| | | | |-----------------------(6) ACK SDP A-------------------->| | | | | |<-------(7) INVITE----------| | | | | |---(8) 200 OK SDP TA+TB---->| | | | |<-----------------(9) INVITE SDP TA----------------------| | | | |------------------(10) 200 OK SDP A--------------------->| | | | |<-----------------------(11) ACK-------------------------| | | | | |<-----(12) ACK SDP A+B------| | | | | ************************** | ************************** | |* MEDIA *|* MEDIA *| | ************************** | ************************** | 図2: SDPなしの最初のINVITE後の着呼側による呼び出し (2) INVITE SDP A+B m=audio 20000 RTP/AVP 0 c=IN IP4 0.0.0.0 m=text 40000 RTP/AVP 96 c=IN IP4 B.example.com a=rtpmap:96 t140/1000 (3) 200 OK SDP TA+TB m=audio 30000 RTP/AVP 0 c=IN IP4 T.example.com m=text 30002 RTP/AVP 96 c=IN IP4 T.example.com a=rtpmap:96 t140/1000 Camarillo, et al. Informational [Page 6] RFC 4117 3pcc Transcoding in SIP June 2005 (5) 200 OK SDP TA m=audio 30000 RTP/AVP 0 c=IN IP4 T.example.com (6) ACK SDP A m=audio 20000 RTP/AVP 0 c=IN IP4 A.example.com (8) 200 OK SDP TA+TB m=audio 30004 RTP/AVP 0 c=IN IP4 T.example.com m=text 30006 RTP/AVP 96 c=IN IP4 T.example.com a=rtpmap:96 t140/1000 (9) INVITE SDP TA m=audio 30004 RTP/AVP 0 c=IN IP4 T.example.com (10) 200 OK SDP A m=audio 20002 RTP/AVP 0 c=IN IP4 A.example.com (12) ACK SDP A+B m=audio 20002 RTP/AVP 0 c=IN IP4 A.example.com m=text 40000 RTP/AVP 96 c=IN IP4 B.example.com a=rtpmap:96 t140/1000 Camarillo, et al. Informational [Page 7] RFC 4117 3pcc Transcoding in SIP June 2005 以下の4つのメディアストリーム(つまり2つの双方向ストリーム)がこの時点 で確立された。 1. AからT.example.com:30004に対する音声 2. TからB.example.com:40000へのテキスト 3. BからT.example.com:30006へのテキスト 4. TからA.example.com:20002へのテキスト 3.3. 発呼側による呼び出し このシナリオでは、Aは、トランスコーディングサービスを使用して、Bとの セッションを確立する。Aは、3pccを使用してTとB間のセッションを確立 する。このコールフローは、[2]のコールフローとはやや異なる。[2]では、 コントローラが2つのユーザーエージェント間のセッションを確立する。こ のとき、一方がストリームの特性を決定する。本文書の場合、AがTとB間の セッションを確立しようとしているが、ストリームの数や種類はAが決定し たいと考えている。これは、Aがセッション記述を最初のINVITE (1)でTに送 信するためである。一方、[2]では、メディアなしで最初のINVITEを送信す ることが推奨されている。 図3は、このシナリオのコールフローである。 図2のセッション記述と非常に似ているので、ここではフローのセッション 記述は記載していない。このフローでは、Tが(2)と同じSDP TA+TBを返す(8) 場合、メッセージ(9)、(10)、(10)はスキップすることができる。 3.4. 元のストリームの受信 失聴者、難聴者、言語障害者を支援するSIPの要件[5]で指摘されているよう に、元のストリーム(音声など)とトランスコードされたストリーム(音声か らテキストへの変換の出力など)の両方を受信することをユーザーが望む場 合もある。この問題にた多様な解決策がある。 解決策の1つは、SDPグループ属性とフロー識別(Flow Identification/FID) のセマンティクス[3]の使用で構成される。FIDを使用すると、ストリームを 2つの異なるトランスポートアドレスに同時に送信するように要求すること ができる(下図参照)。 Camarillo, et al. Informational [Page 8] RFC 4117 3pcc Transcoding in SIP June 2005 A T B | | | |-------(1) INVITE SDP A---->| | | | | |<----(2) 200 OK SDP TA+TB---| | | | | |----------(3) ACK---------->| | | | | |--------------------(4) INVITE SDP TA------------------->| | | | |<--------------------(5) 200 OK SDP B--------------------| | | | |-------------------------(6) ACK------------------------>| | | | |--------(7) INVITE--------->| | | | | |<---(8) 200 OK SDP TA+TB --| | | | | |--------------------(9) INVITE SDP TA------------------->| | | | |<-------------------(10) 200 OK SDP B--------------------| | | | |-------------------------(11) ACK----------------------->| | | | |------(12) ACK SDP A+B----->| | | | | | ************************** | ************************** | |* MEDIA *|* MEDIA *| | ************************** | ************************** | | | | 図3: トランスコーディングサービスの発呼側による呼び出し a=group:FID 1 2 m=audio 20000 RTP/AVP 0 c=IN IP4 A.example.com a=mid:1 m=audio 30000 RTP/AVP 0 c=IN IP4 T.example.com a=mid:2 この解決策の問題は、SIPユーザーエージェントの大部分はFIDに対応してい ないということである。さらに、FIDに対応する数少ないUAのうち、同じメ ディアストリームのコピーを同時に送信する機能に対応しているものはほん のわずかである。また、FIDは、同じコーデックを使用するために、ストリー ムの両方のコピーを強制する。 Camarillo, et al. Informational [Page 9] RFC 4117 3pcc Transcoding in SIP June 2005 したがって、Tは(ユーザーエージェントの代わりに)メディアストリームを 複製することが推奨される。以下のセッション記述を受信するトランスコー ダTは、最初の音声ストリームとテキストストリームの間に、音声からテキ ストへの変換、およびテキストから音声への変換を実行する。また、Tは最 初の音声ストリームを2番目の音声ストリームにコピーし、それをAに送信 する。 m=audio 40000 RTP/AVP 0 c=IN IP4 B.example.com m=audio 20000 RTP/AVP 0 c=IN IP4 A.example.com a=recvonly m=text 20002 RTP/AVP 96 c=IN IP4 A.example.com a=rtpmap:96 t140/1000 3.5. 並行するトランスコーディングサービス 場合によって、トランスコーディングサービスに、人間の中継者(たとえば、 あるセッションについて音声からテキストへの変換とテキストから音声への 変換を実行する人物)が含まれることがある。この人物が両方の変換に関与 する場合(つまりAからBとBからA)、その人物はすべての会話にアクセス権を 持つ。ある程度のプライバシを提供するために、2人の異なる人物がその仕 事に割り当てられることがある(つまり、1人がAからB方向を処理し、もう1 人がBからA方向を処理する)。このような処理は、自動トランスコーディン グサービスにも有効である。この場合、1台のマシンがテキストから合成音 声へ変換し(テキストから音声への変換)、もう1台が音声認識を実行する(音 声からテキストへの変換)。 上記のシナリオには、A-T1、T1-B、B-T2、T2-Aという4つの異なるセッショ ンが関与する。AがT1とT2を呼び出すコールフローを図4に示す。 この例では、一方向のメディアストリーム(つまり、sendonlyまたは recvonly)を使用して、トランスコーダがどの方向でどのメディアを処理す るかを明確に特定している。それでも、このシナリオで双方向ストリームの 使用を排除するものはない。双方向ストリームも使用することができる。た とえば、人間の中継者が、メディアを受信しているパーティに対して、説明 を求める(「聞き取れませんでした。繰り返していただけますか。」など)場 合などである。 Camarillo, et al. Informational [Page 10] RFC 4117 3pcc Transcoding in SIP June 2005 (1) INVITE SDP AT1 m=text 20000 RTP/AVP 96 c=IN IP4 A.example.com a=rtpmap:96 t140/1000 a=sendonly m=audio 20000 RTP/AVP 0 c=IN IP4 0.0.0.0 a=recvonly (2) INVITE SDP AT2 m=text 20002 RTP/AVP 96 c=IN IP4 A.example.com a=rtpmap:96 t140/1000 a=recvonly m=audio 20000 RTP/AVP 0 c=IN IP4 0.0.0.0 a=sendonly (3) 200 OK SDP T1A+T1B m=text 30000 RTP/AVP 96 c=IN IP4 T1.example.com a=rtpmap:96 t140/1000 a=recvonly m=audio 30002 RTP/AVP 0 c=IN IP4 T1.example.com a=sendonly (5) 200 OK SDP T2A+T2B m=text 40000 RTP/AVP 96 c=IN IP4 T2.example.com a=rtpmap:96 t140/1000 a=sendonly m=audio 40002 RTP/AVP 0 c=IN IP4 T2.example.com a=recvonly (7) INVITE SDP T1B+T2B m=audio 30002 RTP/AVP 0 c=IN IP4 T1.example.com a=sendonly m=audio 40002 RTP/AVP 0 c=IN IP4 T2.example.com a=recvonly Camarillo, et al. Informational [Page 11] RFC 4117 3pcc Transcoding in SIP June 2005 A T1 T2 B | | | | |----(1) INVITE SDP AT1--->| | | | | | | |----------------(2) INVITE SDP AT2-------------->| | | | | | |<-(3) 200 OK SDP T1A+T1B--| | | | | | | |---------(4) ACK--------->| | | | | | | |<---------------(5) 200 OK SDP T2A+T2B-----------| | | | | | |----------------------(6) ACK------------------->| | | | | | |-----------------------(7) INVITE SDP T1B+T2B----------------->| | | | | |<----------------------(8) 200 OK SDP BT1+BT2------------------| | | | | |------(9) INVITE--------->| | | | | | | |-------------------(10) INVITE------------------>| | | | | | |<-(11) 200 OK SDP T1A+T1B-| | | | | | | |<------------(12) 200 OK SDP T2A+T2B-------------| | | | | | |------------------(13) INVITE SDP T1B+T2B--------------------->| | | | | |<-----------------(14) 200 OK SDP BT1+BT2----------------------| | | | | |--------------------------(15) ACK---------------------------->| | | | | |---(16) ACK SDP AT1+BT1-->| | | | | | | |------------(17) ACK SDP AT2+BT2---------------->| | | | | | | ************************ | ********************************** | |* MEDIA *|* MEDIA *| | ************************ | ********************************** | | | | | | *********************************************** *********** |* MEDIA *|* MEDIA *| | *********************************************** | *********** | | | | | 図4: 並行するトランスコーディングサービス Camarillo, et al. Informational [Page 12] RFC 4117 3pcc Transcoding in SIP June 2005 (8) 200 OK SDP BT1+BT2 m=audio 50000 RTP/AVP 0 c=IN IP4 B.example.com a=recvonly m=audio 50002 RTP/AVP 0 c=IN IP4 B.example.com a=sendonly (11) 200 OK SDP T1A+T1B m=text 30000 RTP/AVP 96 c=IN IP4 T1.example.com a=rtpmap:96 t140/1000 a=recvonly m=audio 30002 RTP/AVP 0 c=IN IP4 T1.example.com a=sendonly (12) 200 OK SDP T2A+T2B m=text 40000 RTP/AVP 96 c=IN IP4 T2.example.com a=rtpmap:96 t140/1000 a=sendonly m=audio 40002 RTP/AVP 0 c=IN IP4 T2.example.com a=recvonly T1は(3)と同じセッション記述を返し(11)、T2は(5)と同じセッション記述を 返す(12)ため、(13)、(14)、(15)はスキップすることができる。 (16) ACK SDP AT1+BT1 m=text 20000 RTP/AVP 96 c=IN IP4 A.example.com a=rtpmap:96 t140/1000 a=sendonly m=audio 50000 RTP/AVP 0 c=IN IP4 B.example.com a=recvonly Camarillo, et al. Informational [Page 13] RFC 4117 3pcc Transcoding in SIP June 2005 (17) ACK SDP AT2+BT2 m=text 20002 RTP/AVP 96 c=IN IP4 A.example.com a=rtpmap:96 t140/1000 a=recvonly m=audio 50002 RTP/AVP 0 c=IN IP4 B.example.com a=sendonly この時点で、以下の4つのメディアストリームが確立された。 1. AからT1.example.com:30000へのテキスト 2. T1からB.example.com:50000に対する音声 3. BからT2.example.com:40002への音声 4. T2からA.example.com:20002へのテキスト B (ユーザーエージェントサーバー)は、sendonlyとrecvonlyという2つのメ ディアストリームに対応する必要があることに注意。現時点で、一部の ユーザーエージェントは、単一のsendrecvメディアストリームに対応してい るが、各方向の異なるメディア回線には対応していない。実装者には、この 機能への対応を構築することが推奨される。 3.6. 連続するトランスコーディングサービス 分散環境では、複数のサーバーが複雑なトランスコーディングサービス(英 語テキストからスペイン語音声への変換など)を提供することがよくある。 たとえば、あるサーバーは英語テキストをスペイン語テキストへの翻訳を実 行し、テキストから音声への変換を実行するサーバーにその出力が提供さ れる。AがT1とT2を呼び出す方法を図5のコールフローに示す。 Camarillo, et al. Informational [Page 14] RFC 4117 3pcc Transcoding in SIP June 2005 A T1 T2 B | | | | |----(1) INVITE SDP A-----> | | | | | | | |<-(2) 200 OK SDP T1A+T1T2- | | | | | | | |----------(3) ACK--------> | | | | | | | |-----------(4) INVITE SDP T1T2------------------>| | | | | | |<-----------(5) 200 OK SDP T2T1+T2B--------------| | | | | | |---------------------(6) ACK-------------------->| | | | | | |---------------------------(7) INVITE SDP T2B----------------->| | | | | |<--------------------------(8) 200 OK SDP B--------------------| | | | | |--------------------------------(9) ACK----------------------->| | | | | |---(10) INVITE-----------> | | | | | | | |------------------(11) INVITE------------------->| | | | | | |<-(12) 200 OK SDP T1A+T1T2-| | | | | | | |<-------------(13) 200 OK SDP T2T1+T2B-----------| | | | | | |---(14) ACK SDP T1T2+B---> | | | | | | | |-----------------------(15) INVITE SDP T2B-------------------->| | | | | |<----------------------(16) 200 OK SDP B-----------------------| | | | | |----------------(17) ACK SDP T1T2+B------------->| | | | | | |----------------------------(18) ACK-------------------------->| | | | | | ************************* | ******************* *********** | |* MEDIA *|* MEDIA *|* MEDIA *| | ************************* | ******************* | *********** | | | | | 図5: 連続するトランスコーディングサービス Camarillo, et al. Informational [Page 15] RFC 4117 3pcc Transcoding in SIP June 2005 4. セキュリティの考慮事項 RFC 3725 [2]では、SIPでサードパーティ呼制御を使用する場合に関連する セキュリティの考慮事項について論じている。RFC 3725には、サードパー ティ呼制御を使用してトランスコーディングサービスを呼び出す方法につい ても記載されているため、同じ考慮事項が本文書にも適用される。 特に、RFC 3725は、エンドツーエンドのメディアセキュリティは、SDP内の キーイング素材の交換に基づき、コントローラが正しく動作するかどうかに 依存する。つまり、コントローラは、他パーティから提供されるセキュリ ティメカニズムを無効にしようとすべきではない。 結果的に、コントローラが自分自身をメディア交換の仲介者として挿入する ことは、コントローラがそう希望したとしても不可能である、ということは 自明である。 本文書では、コントローラとはトランスコーダを呼び出すUAであり、リモー トUAとトランスコーダ間に、サードパーティ呼制御を使用して確立したメ ディアセッションがある。結果として、RFC 3725に記載されている攻撃は脅 威にならない。というのも、コントローラはトランスコーディングサービス を呼び出すUAであり、いずれにせよ定義によってメディアへのアクセス権を 持っているためである。したがって、UAがトランスコーダとリモートUA間の セキュリティを無効にすることで、自分のセッションに対して攻撃をしかけ ようとすることは可能性が低いと考えられる。 UAの観点によるエンドツーエンドのメディアセキュリティについては、トラ ンスコーダは機能を実行するためにメディアへアクセスする必要がある。そ のため、定義によってトランスコーダは仲介者として動作する。UA間で交換 されるすべてのメディアに対するアクセス権を、特定のトランスコーダに持 たせたくない場合、UAは各方向で異なるトランスコーダを使用できる。さら に、UAはメディアの種類によって異なるトランスコーダを使用できる。 Camarillo, et al. Informational [Page 16] RFC 4117 3pcc Transcoding in SIP June 2005 5. 規範となる参考文献 [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] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [3] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. 6. Informative References [4] Camarillo, G., "Framework for transcoding with the session initiation protocol", August 2003, Work in Progress. [5] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002. Camarillo, et al. Informational [Page 17] RFC 4117 3pcc Transcoding in SIP June 2005 著者の連絡先 Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Eric Burger Brooktrout Technology, Inc. 18 Keewaydin Way Salem, NH 03079 USA EMail: eburger@brooktrout.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA EMail: schulzrinne@cs.columbia.edu Arnoud van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands EMail: a.vwijk@viataal.nl Camarillo, et al. Informational [Page 18] RFC 4117 3pcc Transcoding in SIP June 2005 完全な著作権表記 Copyright (C) The Internet Society (2005). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イ ンターネット協会およびIETFは、この情報がいかなる権利も侵害していない という保証、商用利用および特定目的への適合性への保証を含め、また、こ れらだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行 われない。 知的所有権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79 に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情 報は、IETF (ietf-ipr@ietf.org)宛てに送信していただきたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2007年 ----------------------------------------------------------------------- Camarillo, et al. Informational [Page 19]