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
Transcoding Services Invocation in
the Session Initiation Protocol (SIP)
Using Third Party Call Control (3pcc)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals.
この文書では、セッション開始プロトコル（SIP）およびサードパーティの呼制御を使用してトランスコーディングサービスを起動する方法について説明します。呼び出しのこの方法では、SIPは、難聴や音声障害者の、聴覚障害者をサポートするために、トランスコーディングサービスの呼び出しについての要件を満たしています。
Table of Contents
目次
1. Introduction ....................................................2
2. General Overview ................................................2
3. Third Party Call Control Flows ..................................2
3.1. Terminology ................................................3
3.2. Callee's Invocation ........................................3
3.3. Caller's Invocation ........................................8
3.4. Receiving the Original Stream ..............................8
3.5. Transcoding Services in Parallel ..........................10
3.6. Multiple Transcoding Services in Series ...................14
4. Security Considerations ........................................16
5. Normative References ...........................................17
6. Informative References .........................................17
The framework for transcoding with SIP [4] describes how two SIP [1] UAs (User Agents) can discover incompatibilities that prevent them from establishing a session (e.g., lack of support for a common codec or common media type). When such incompatibilities are found, the UAs need to invoke transcoding services to successfully establish the session. 3pcc (third party call control) [2] is one way to perform such invocation.
[4] SIPとトランスコードするためのフレームワークは、2つのSIP [1]のUA（ユーザエージェント）がセッションを確立するのを防止する非互換性を検出する方法について説明（例えば、一般的なコーデックまたは共通のメディアタイプのためのサポートの欠如）。このような非互換性が発見された場合、UAは成功し、セッションを確立するために、トランスコーディングサービスを起動する必要があります。 3PCC（サードパーティ呼制御）[2]このような呼び出しを行うための一つの方法です。
In the 3pcc model for transcoding invocation, a transcoding server that provides a particular transcoding service (e.g., speech-to-text) is identified by a URI. A UA that wishes to invoke that service sends an INVITE request to that URI establishing a number of media streams. The way the transcoder manipulates and manages the contents of those media streams (e.g., the text received over the text stream is transformed into speech and sent over the audio stream) is service specific.
トランスコード呼び出しの3PCCモデルでは、特定のトランスコーディングサービスを提供するトランスコーディングサーバは、（例えば、スピーチ・ツー・テキスト）はURIによって識別されます。そのサービスを呼び出すことを望むUAは、メディアストリームの数を確立し、そのURIにINVITE要求を送ります。トランスコーダを操作し、それらのメディアストリームの内容を管理する方法は、サービス固有である（例えば、テキストは、テキストストリームを介して受信し、音声に変換されたオーディオストリームを介して送信されます）。
All the call flows in this document use SDP. The same call flows could be used with another session description protocol that provides similar session description capabilities.
このドキュメントのすべてのコールフローは、SDPを使用しています。同一のコールフローは、同様のセッション記述の機能を提供する別のセッション記述プロトコルで使用することができます。
Given two UAs (A and B) and a transcoding server (T), the invocation of a transcoding service consists of establishing two sessions; A-T and T-B. How these sessions are established depends on which party, the caller (A) or the callee (B), invokes the transcoding services. Section 3.2 deals with callee invocation and Section 3.3 deals with caller invocation.
2つのUA（A及びB）とトランスコーディングサーバ（T）指定された、トランスコーディングサービスの呼び出しは、二つのセッションを確立することから成ります。 -TとT-B。どのようにこれらのセッションが確立されていることはどの党に依存して、呼び出し側（A）または呼び出し先（B）は、トランスコーディングサービスを起動します。セクション呼び出し先の呼び出しとセクションの呼び出し元の呼び出しと3.3取引で3.2扱っています。
In all our 3pcc flows we have followed the general principle that a 200 (OK) response from the transcoding service has to be received before contacting the callee. This tries to ensure that the transcoding service will be available when the callee accepts the session.
すべての私たちの3PCC・フローでは、トランスコーディングサービスから200（OK）応答が呼び出し先に連絡する前に受信する必要があるという一般的な原則に従っています。これは、呼び出し先がセッションを受け入れたときにトランスコーディングサービスが利用可能になることを保証しようとします。
Still, the transcoding service does not know the exact type of transcoding it will be performing until the callee accepts the session. So, there is always the chance of failing to provide transcoding services after the callee has accepted the session. A system with more stringent requirements could use preconditions to avoid this situation. When preconditions are used, the callee is not alerted until everything is ready for the session.
それでも、トランスコーディングサービスは、呼び出し先がセッションを受け入れるまで、それが実行されるトランスコードのタイプを正確に把握していません。だから、呼び出し先がセッションを受け入れた後にトランスコーディングサービスを提供するために、失敗の可能性は常にあります。より厳格な要件を持つシステムは、このような状況を回避するための前提条件を使用することができます。前提条件が使用される場合、すべてがセッションのための準備ができるまで、呼び出し先が警告されていません。
All the flows in this document follow the naming convention below:
このドキュメントのすべてのフローは、以下の命名規則に従います。
SDP A: A session description generated by A. It contains, among other things, the transport address/es (IP address and port number) where A wants to receive media for each particular stream.
SDP A：A.によって生成されたセッション記述は、とりわけ、Aはそれぞれ特定のストリームのメディアを受信したいトランスポート・アドレス/エス（IPアドレスとポート番号）が含まれています。
SDP B: A session description generated by B. It contains, among other things, the transport address/es where B wants to receive media for each particular stream.
SDP B：Bによって生成されたセッション記述それが含まれ、とりわけ、Bはそれぞれ特定のストリームのメディアを受信したいトランスポート・アドレス/ ES。
SDP A+B: A session description that contains, among other things, the transport address/es where A wants to receive media and the transport address/es where B wants to receive media.
SDP A + B：含まれているセッション記述、とりわけ、Aは、メディアとBがメディアを受信したいトランスポート・アドレス/ ESを受信したいトランスポート・アドレス/ ES。
SDP TA: A session description generated by T and intended for A. It contains, among other things, the transport address/es where T wants to receive media from A.
SDP TA：セッション記述Tによって生成され、A.するためのものそれは、とりわけ、TはAからメディアを受信したいトランスポート・アドレス/ ESを含んでいます
SDP TB: A session description generated by T and intended for B. It contains, among other things, the transport address/es where T wants to receive media from B.
SDP TB：セッション記述Tによって生成され、Bの意図それは、とりわけ、トランスポートアドレスが含まれている/ ES TがBからメディアを受信したいところ
SDP TA+TB: A session description generated by T that contains, among other things, the transport address/es where T wants to receive media from A and the transport address/es where T wants to receive media from B.
T AおよびTがBからメディアを受信したいトランスポートアドレス/ ESからメディアを受信したい含まTにより生成されたセッション記述、とりわけ、トランスポートアドレス/ ES：SDP TA +のTB
In this scenario, B receives an INVITE from A, and B decides to introduce T in the session. Figure 1 shows the call flow for this scenario.
このシナリオでは、Bは、AからINVITEを受信し、BはセッションでTを導入することを決定します。図1は、このシナリオのための呼フローを示します。
In Figure 1, A can both hear and speak, and B is a deaf user with a speech impairment. A proposes to establish a session that consists of an audio stream (1). B wants to send and receive only text, so it invokes a transcoding service T that will perform both speech-to-text and text-to-speech conversions (2). The session descriptions of Figure 1 are partially shown below.
図1では、Aは両方聞くと話し、Bは言語障害と聴覚障害者の利用者であることができます。 Aは、オーディオストリーム（1）で構成されたセッションを確立することを提案しています。それがテキスト音声及びテキスト・ツー・スピーチ変換（2）の両方を実行するトランスコーディングサービスTを呼び出すようにBは、テキストのみを送受信することを望みます。図1のセッション記述は、部分的に以下に示します。
A T B
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 *|
| ************************** | ************************** |
| | |
Figure 1: Callee's Invocation of a Transcoding Service
図1：トランスコーディングサービスの呼び出し先の呼び出し
(1) INVITE SDP A
（1）SDPは、INVITE
m=audio 20000 RTP/AVP 0
c=IN IP4 A.example.com
(2) INVITE SDP A+B
（2）SDP A + BをINVITE
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
TB（3）200 OK + SDP
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
（5）SDP 200 OK
m=audio 30000 RTP/AVP 0
c=IN IP4 T.example.com
Four media streams (i.e., two bi-directional streams) have been established at this point:
4つのメディアストリーム（すなわち2つの双方向ストリーム）は、この時点で確立されています。
1. Audio from A to T.example.com:30000
1.オーディオAからT.example.com:30000へ
2. Text from T to B.example.com:40000
TからB.example.com:40000 2.テキスト
3. Text from B to T.example.com:30002
BからT.example.com:30002 3.テキスト
4. Audio from T to A.example.com:20000
4.オーディオTからA.example.com:20000へ
When either A or B decides to terminate the session, it sends a BYE indicating that the session is over.
A又はBのいずれかがセッションを終了することを決定する場合、それはセッションが終わったことを示すBYEを送信します。
If the first INVITE (1) received by B is empty (no session description), the call flow is slightly different. Figure 2 shows the messages involved.
最初は、（1）Bで受信されたINVITE場合（NOセッション記述）空で、コールフローはわずかに異なっています。図2は、関連するメッセージが表示されます。
B may have different reasons for invoking T before knowing A's session description. B may want to hide its lack of native capabilities, and therefore wants to return a session description with all the codecs that B supports, plus all the codecs that T supports. Or T may provide recording services (besides transcoding), and B wants T to record the conversation, regardless of whether transcoding is needed.
BはAのセッション記述を知る前に、Tを呼び出すためのさまざまな理由であってもよいです。 Bは、ネイティブ機能の欠如を非表示にするので、Bがサポートしているすべてのコーデックに加え、Tがサポートするすべてのコーデックとのセッション記述を返すように望んでいることがあります。またはTは、（トランスコーディング以外の）記録サービスを提供することができ、そしてBはTに関係なく、トランスコーディングが必要かどうかの、会話を記録したいです。
This scenario (Figure 2) is a bit more complex than the previous one. In INVITE (2), B still does not have SDP A, so it cannot provide T with that information. When B finally receives SDP A in (6), it has to send it to T. B sends an empty INVITE to T (7) and gets a 200 OK with SDP TA+TB (8). In general, this SDP TA+TB can be different than the one sent in (3). That is why B needs to send the updated SDP TA to A in (9). A then sends a possibly updated SDP A (10) and B sends it to T in (12). On the other hand, if T happens to return the same SDP TA+TB in (8) as in (3), B can skip messages (9), (10), and (11). So, implementors of transcoding services are encouraged to return the same session description in (8) as in (3) in this type of scenario. The session descriptions of this flow are shown below:
このシナリオ（図2）は、もう少し複雑な以前のものよりもあります。 INVITE（2）において、Bは、依然としてSDP Aを持っていないので、その情報を用いてTを提供することができません。 Bは、最終的に（6）にSDP Aを受信すると、（7）TにINVITE空を送信し、SDP TA + TB（8）との200 OKを取得T. Bに送信しなければなりません。一般に、このSDP TA + TB（3）で送信されたものとは異なることができます。 Bは、（9）に更新されたSDP TAを送信する必要がある理由です。その後、おそらく更新SDP A（10）を送信し、Bは（12）でTに送信します。一方、Tは、同じSDP TA + TBを返すために起こる（8）（3）、Bがメッセージをスキップすることができるように（9）、（10）、及び（11）。だから、トランスコーディングサービスの実装者は、このタイプのシナリオでは（3）のように（8）で同じセッション記述を返すように奨励されています。このフローのセッション記述は以下の通りです：
A T B
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 *|
| ************************** | ************************** |
Figure 2: Callee's invocation after initial INVITE without SDP
図2：SDPなしで初期INVITE後に呼び出し先の呼び出し
(2) INVITE SDP A+B
（2）SDP A + BをINVITE
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
TB（3）200 OK + SDP
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
（5）SDP 200 OK
m=audio 30000 RTP/AVP 0
c=IN IP4 T.example.com
(6) ACK SDP A
（6）ACK SDP A
m=audio 20000 RTP/AVP 0
c=IN IP4 A.example.com
(8) 200 OK SDP TA+TB
TB（8）200 OK + SDP
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
（9）SDP OF INVITE
m=audio 30004 RTP/AVP 0
c=IN IP4 T.example.com
(10) 200 OK SDP A
（10）SDP 200 OK
m=audio 20002 RTP/AVP 0
c=IN IP4 A.example.com
(12) ACK SDP A+B
（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
Four media streams (i.e., two bi-directional streams) have been established at this point:
4つのメディアストリーム（すなわち2つの双方向ストリーム）は、この時点で確立されています。
1. Audio from A to T.example.com:30004
1.オーディオAからT.example.com:30004へ
2. Text from T to B.example.com:40000
TからB.example.com:40000 2.テキスト
3. Text from B to T.example.com:30006
BからT.example.com:30006 3.テキスト
4. Audio from T to A.example.com:20002
4.オーディオTからA.example.com:20002へ
In this scenario, A wishes to establish a session with B using a transcoding service. A uses 3pcc to set up the session between T and B. The call flow we provide here is slightly different than the ones in [2]. In [2], the controller establishes a session between two user agents, which are the ones deciding the characteristics of the streams. Here, A wants to establish a session between T and B, but A wants to decide how many and which types of streams are established. That is why A sends its session description in the first INVITE (1) to T, as opposed to the media-less initial INVITE recommended by [2]. Figure 3 shows the call flow for this scenario.
このシナリオでは、Aは、トランスコーディングサービスを使用して、Bとのセッションを確立することを望みます。私たちはここに提供コールフローが中のものよりもわずかに異なっているTとBの間のセッションを設定する3PCCを使用しています[2]。 [2]において、コントローラは、ストリームの特性を決定するものである2つのユーザエージェントとの間のセッションを確立します。ここで、AはTとBの間のセッションを確立することを望んでいるが、Aは、ストリームの種類が確立されているどのように多くの、どの決定したいと考えています。 Aは、メディアレス初期[2]によって推奨INVITEとは対照的に、最初にそのセッション記述は、T（1）INVITEを送信する理由です。図3は、このシナリオのための呼フローを示します。
We do not include the session descriptions of this flow, since they are very similar to those in Figure 2. In this flow, if T returns the same SDP TA+TB in (8) as in (2), messages (9), (10), and (11) can be skipped.
Tは、同じSDP TA + TBを返した場合、彼らは、このフローでは、図2のものと非常に似ているので、我々は、このフローのセッション記述が含まれていない（8）のように（2）、メッセージ（9）、 （10）、及び（11）は省略することができます。
Sometimes, as pointed out in the requirements for SIP in support of deaf, hard of hearing, and speech-impaired individuals [5], a user wants to receive both the original stream (e.g., audio) and the transcoded stream (e.g., the output of the speech-to-text conversion). There are various possible solutions for this problem. One solution consists of using the SDP group attribute with Flow Identification (FID) semantics [3]. FID allows requesting that a stream is sent to two different transport addresses in parallel, as shown below:
難聴の聴覚障害者を支援するSIPの要件、および音声障害者に指摘したように時々、[5]、使用者は、元のストリーム（例えば、オーディオ）とトランスコードストリーム（例えば、両方を受信したいです音声テキスト変換の出力）。この問題に対する様々な解決策があります。一つの解決策は、[3]フロー識別（FID）のセマンティクスとSDPグループ属性を使用することからなります。 FIDは、以下に示すように、ストリームは、並列に二つの異なるトランスポートアドレスに送信されることを要求できます。
A T B
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 *|
| ************************** | ************************** |
| | |
Figure 3: Caller's invocation of a transcoding service
図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
=グループ：FID 1 2 M =オーディオ20000 RTP / AVP 0 C = IN IP4 A.example.com A =ミッド：1 M =オーディオ30000 RTP / AVP 0 C = IN IP4 T.example.com A =ミッド： 2
The problem with this solution is that the majority of the SIP user agents do not support FID. Moreover, only a small fraction of the few UAs that support FID, also support sending simultaneous copies of the same media stream at the same time. In addition, FID forces both copies of the stream to use the same codec.
この解決策の問題は、SIPユーザエージェントの大半はFIDをサポートしていないということです。また、FIDをサポートするいくつかのUAのごく一部、同時に同じメディアストリームの同時コピーの送信をサポート。また、FIDは同じコーデックを使用するストリームの両方のコピーを強制します。
Therefore, we recommend that T (instead of a user agent) replicates the media stream. The transcoder T receiving the following session description performs speech-to-text and text-to-speech conversions between the first audio stream and the text stream. In addition, T copies the first audio stream to the second audio stream and sends it to A.
したがって、我々はT（代わりのユーザーエージェント）は、メディアストリームを複製することをお勧めします。以下のセッション記述を受信したトランスコーダTは、スピーチ・ツー・テキスト最初のオーディオストリーム及びテキストストリーム間及びテキスト - 音声変換を行います。また、Tは、コピー第二の音声ストリームへの最初のオーディオストリームおよび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
Transcoding services sometimes consist of human relays (e.g., a person performing speech-to-text and text-to-speech conversions for a session). If the same person is involved in both conversions (i.e., from A to B and from B to A), he or she has access to all of the conversation. In order to provide some degree of privacy, sometimes two different persons are allocated to do the job (i.e., one person handles A->B and the other B->A). This type of disposition is also useful for automated transcoding services, where one machine converts text to synthetic speech (text-to-speech) and another performs voice recognition (speech-to-text).
トランスコーディングサービスは、時々、ヒトリレー（例えば、セッションのためにスピーチ・ツー・テキストおよびテキスト - 音声変換を行う人）から成ります。同じ人が両方の変換（すなわち、からBへとBからAへ）に関与している場合は、彼または彼女は、会話のすべてにアクセスできます。プライバシーをある程度提供するために、時には二つの異なる人がジョブ（即ち、一人ハンドルA-> Bおよび他のB-> A）を行うために割り当てられています。配置のこのタイプはまた、1台のマシンが合成音声（テキスト・ツー・スピーチ）と他行う音声認識（音声テキスト）にテキストを変換する自動化されたトランスコーディングサービス、のために有用です。
The scenario described above involves four different sessions: A-T1, T1-B, B-T2 and T2-A. Figure 4 shows the call flow where A invokes T1 and T2.
A-T1、T1-B、B-T2及びT2-A：上記のシナリオは、4つの異なるセッションを含みます。図4は、AがT1およびT2を起動するコールフローを示します。
Note this example uses unidirectional media streams (i.e., sendonly or recvonly) to clearly identify which transcoder handles media in which direction. Nevertheless, nothing precludes the use of bidirectional streams in this scenario. They could be used, for example, by a human relay to ask for clarifications (e.g., I did not get that, could you repeat, please?) to the party he or she is receiving media from.
この例では明らかにどの方向にメディアを処理するトランスコーダを識別するために（すなわち、sendonlyで又はがrecvonly）一方向メディアストリームを使用します。それにもかかわらず、何もこのシナリオでは、双方向ストリームの使用を排除しません。彼らは、彼または彼女はからメディアを受信している当事者に（例えば、私は、あなたが繰り返しでき、それをしてください取得していない？）の明確化を求めるために、人間の中継により、例えば、使用することができます。
(1) INVITE SDP AT1
（1）SDP AT1をINVITE
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
（2）SDP AT2をINVITE
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
（3）200 OK T1A + T1B SDP
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
（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
（7）SDP T1B + T2BをINVITE
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
A T1 T2 B
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 *|
| *********************************************** | *********** |
| | | |
Figure 4: Transcoding services in parallel
図4：並列にトランスコーディングサービス
(8) 200 OK SDP BT1+BT2
（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
（11）200 OK T1A + T1B SDP
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
（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
Since T1 have returned the same SDP in (11) as in (3), and T2 has returned the same SDP in (12) as in (5), messages (13), (14) and (15) can be skipped.
T1は、のように（12）（3）、及びT2は、戻ってきた同じSDPのように（11）に同じSDPを返したので（5）、メッセージが（13）、（14）及び（15）は省略することができます。
(16) ACK SDP AT1+BT1
（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
(17) ACK SDP AT2+BT2
（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
Four media streams have been established at this point:
4つのメディアストリームは、この時点で確立されています：
1. Text from A to T1.example.com:30000
AからT1.example.com:30000 1.テキスト
2. Audio from T1 to B.example.com:50000
2.オーディオT1からB.example.com:50000へ
3. Audio from B to T2.example.com:40002
3.オーディオBからT2.example.com:40002へ
4. Text from T2 to A.example.com:20002
T2からA.example.com:20002 4.テキスト
Note that B, the user agent server, needs to support two media streams: sendonly and recvonly. At present, some user agents, although they support a single sendrecv media stream, do not support a different media line per direction. Implementers are encouraged to build support for this feature.
sendonlyのがrecvonly：B、ユーザエージェントサーバは、2つのメディアストリームをサポートする必要があることに注意してください。彼らは、単一のsendrecvメディアストリームをサポートするが、現時点では、一部のユーザーエージェントは、方向ごとに異なるメディアラインをサポートしていません。実装者は、この機能のサポートを構築することをお勧めします。
In a distributed environment, a complex transcoding service (e.g., English text to Spanish speech) is often provided by several servers. For example, one server performs English text to Spanish text translation, and its output is fed into a server that performs text-to-speech conversion. The flow in Figure 5 shows how A invokes T1 and T2.
分散環境では、複雑なトランスコーディングサービス（スペイン語スピーチに、例えば、英語のテキスト）は、多くの場合、複数のサーバによって提供されます。例えば、1台のサーバがスペイン語のテキスト翻訳に英語のテキストを実行し、その出力は、テキストから音声への変換を実行するサーバーに送られます。図5のフローは、AがT1およびT2を起動する方法を示しています。
A T1 T2 B
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 *|
| ************************* | ******************* | *********** |
| | | |
Figure 5: Transcoding services in serial
図5：シリアルでのトランスコーディングサービス
RFC 3725 [2] discusses security considerations which relate to the use of third party call control in SIP. These considerations apply to this document, since it describes how to use third party call control to invoke transcoding service.
RFC 3725 [2] SIP第三者呼制御の使用に関連するセキュリティ問題を論じています。それはトランスコーディングサービスを呼び出すために、第三者呼制御を使用する方法について説明しますので、これらの考慮事項は、この文書に適用されます。
In particular, RFC 3725 states that end-to-end media security is based on the exchange of keying material within SDP and depends on the controller behaving properly. That is, the controller should not try to disable the security mechanisms offered by the other parties. As a result, it is trivially possible for the controller to insert itself as an intermediary on the media exchange, if it should so desire.
特に、RFC 3725は、エンドツーエンドメディアセキュリティがSDP内鍵材料の交換に基づいて、適切に動作コントローラに依存していることを述べています。つまり、コントローラは、他の当事者によって提供されるセキュリティメカニズムを無効にしようではないはずです。結果として、そう望むかどうコントローラは、メディア交換に仲介者として自分自身を挿入するための些細なことが可能です。
In this document, the controller is the UA invoking the transcoder, and there is a media session established using third party call control between the remote UA and the transcoder. Consequently, the attack described in RFC 3725 does not constitute a threat because the controller is the UA invoking the transcoding service and it has access to the media anyway by definition. So, it seems unlikely that a UA would attempt to launch an attack against its own session by disabling security between the transcoder and the remote UA.
この文書では、コントローラは、UAは、トランスコーダを起動し、リモートUAとトランスコーダとの間の第三者呼制御を使用して確立されたメディアセッションがあります。コントローラは、UAは、トランスコーディングサービスを呼び出していると、それは定義によってとにかくメディアへのアクセスを持っているので、結果的に、RFC 3725で説明した攻撃は脅威を構成するものではありません。だから、UAは、トランスコーダとリモートUA間のセキュリティを無効にすることで独自のセッションに対して攻撃を開始しようとするだろうとは考えにくいです。
Regarding end-to-end media security from the UAs' point of view, the transcoder needs access to the media in order to perform its function. So, by definition, the transcoder behaves as a man in the middle. UAs that do not want a particular transcoder to have access to all the media exchanged between them can use a different transcoder for each direction. In addition, UAs can use different transcoders for different media types.
ビューのUAのポイントからエンドツーエンドメディアのセキュリティに関しては、トランスコーダは、その機能を実行するためにメディアにアクセスする必要があります。だから、定義によって、トランスコーダは、中間者として振る舞います。特定のトランスコーダは、すべてのメディアへのアクセスを持ってしたくないUAは、各方向に異なるトランスコーダを使用することができ、それらの間で交換しました。また、UAは異なるメディアタイプごとに異なるトランスコーダを使用することができます。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] 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.
[2]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロを、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[3] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[3]キャマリロ、G.、エリクソン、G.、大声、J.、およびH. Schulzrinneと、 "セッション記述プロトコル（SDP）におけるメディア行のグループ化"、RFC 3388、2002年12月。
[4] Camarillo, G., "Framework for transcoding with the session initiation protocol", August 2003, Work in Progress.
[4]カマリロ、G.、「セッション開始プロトコルとトランスコーディングのための枠組み」、2003年8月には、進行中の作業します。
[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.
[5]チャールトン、N.、Gasson、M.、Gybels、G.、スパナ、M.、およびA.バンWijk、「セッション開始プロトコル（SIP）のためのユーザ要件ろう、難聴や音声のサポートに-impaired個人」、RFC 3351、2002年8月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
ゴンサロ・カマリロエリクソン高度なシグナリング研究所。 FIN-02420 Jorvasフィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Eric Burger Brooktrout Technology, Inc. 18 Keewaydin Way Salem, NH 03079 USA
エリックバーガーブルックトラウト・テクノロジー社18 Keewaydinウェイセーラム、NH 03079 USA
EMail: eburger@brooktrout.com
メールアドレス：eburger@brooktrout.com
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenue、MC 0401ニューヨークのヘニングSchulzrinneと部長、NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
Arnoud van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands
ArnoudバンWijk Viataal研究開発部門RDS Theerestraat 42 5271 GDシントMichielsgestelオランダ
EMail: a.vwijk@viataal.nl
メールアドレス：a.vwijk@viataal.nl
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。