Network Working Group G. Camarillo
Request for Comments: 5369 Ericsson
Category: Informational October 2008
Framework for Transcoding with the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）とトランスコーディングのためのフレームワーク
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet 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. Discovery of the Need for Transcoding Services . . . . . . . . 2
3. Transcoding Services Invocation . . . . . . . . . . . . . . . . 4
3.1. Third-Party Call Control Transcoding Model . . . . . . . . 4
3.2. Conference Bridge Transcoding Model . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Two user agents involved in a SIP [RFC3261] dialog may find it impossible to establish a media session due to a variety of incompatibilities. Assuming that both user agents understand the same session description format (e.g., SDP [RFC4566]), incompatibilities can be found at the user agent level and at the user level. At the user agent level, both terminals may not support any common codec or may not support common media types (e.g., a text-only terminal and an audio-only terminal). At the user level, a deaf person will not understand anything said over an audio stream.
SIP [RFC3261]ダイアログに関与する2つのユーザエージェントは、それが不可能に起因する非互換性の様々なメディアセッションを確立することを見つけることがあります。両方のユーザエージェントが同じセッション記述形式（例えば、SDP [RFC4566]）を理解すると仮定すると、非互換性は、ユーザ・エージェント・レベルとユーザーレベルで見つけることができます。ユーザエージェントレベルでは、両方の端末は、任意の一般的なコーデックをサポートしていなかったり、一般的なメディアタイプをサポートしないかもしれない（例えば、テキストのみの端末と音声のみの端末）。ユーザーレベルでは、聴覚障害者は、オーディオストリーム上で言った何かを理解できないだろう。
In order to make communications possible in the presence of incompatibilities, user agents need to introduce intermediaries that provide transcoding services to a session. From the SIP point of view, the introduction of a transcoder is done in the same way to resolve both user level and user agent level incompatibilities. So, the invocation mechanisms described in this document are generally applicable to any type of incompatibility related to how the information that needs to be communicated is encoded.
非互換性の存在下での通信を可能にするためには、ユーザエージェントは、セッションへのトランスコーディングサービスを提供する仲介者を導入する必要があります。ビューのSIPの観点から、トランスコーダの導入は、ユーザレベルおよびユーザ・エージェント・レベルの非互換性の両方を解決するために、同じ方法で行われます。したがって、この文書に記載され呼び出し機構は、一般的に通信される必要がある情報が符号化される方法に関連する非互換性の任意のタイプに適用可能です。
Furthermore, although this framework focuses on transcoding, the mechanisms described are applicable to media manipulation in general. It would be possible to use them, for example, to invoke a server that simply increases the volume of an audio stream.
このフレームワークは、トランスコーディングに焦点を当てているがまた、説明されたメカニズムは、一般に情報操作に適用可能です。単に、オーディオストリームの音量を増加させるサーバを呼び出すために、例えば、それらを使用することも可能です。
This document does not describe media server discovery. That is an orthogonal problem that one can address using user agent provisioning or other methods.
この文書では、メディアサーバーの発見を説明していません。すなわち、一方はユーザエージェントプロビジョニングまたは他の方法を使用して対処することができる直交する問題です。
The remainder of this document is organized as follows. Section 2 deals with the discovery of the need for transcoding services for a particular session. Section 3 introduces the third-party call control and conference bridge transcoding invocation models, which are further described in Sections 3.1 and 3.2, respectively. Both models meet the requirements regarding transcoding services invocation in RFC 3351 [RFC3351], which support deaf, hard of hearing, and speech-impaired individuals.
このドキュメントの残りは以下の通り構成されています。第特定のセッションのためのトランスコーディングサービスの必要性を発見して2扱います。セクション3は、それぞれ、さらにセクション3.1および3.2に記載されているサードパーティ呼制御と会議ブリッジトランス呼び出しモデルを導入します。両モデルは、難聴の聴覚障害者、および音声障害者をサポートするRFC 3351 [RFC3351]でトランスコーディングサービスの呼び出しに関する要件を満たしています。
According to the one-party consent model defined in RFC 3238 [RFC3238], services that involve media manipulation invocation are best invoked by one of the endpoints involved in the communication, as opposed to being invoked by an intermediary in the network. Following this principle, one of the endpoints should be the one detecting that transcoding is needed for a particular session.
RFC 3238 [RFC3238]で定義された一党同意モデルによれば、サービスは、ネットワーク内の仲介によって呼び出されているとは対照的に、最高の、通信に関わるエンドポイントの1つによって呼び出される情報操作の呼び出しを含んでいます。この原則に続いて、エンドポイントの1つは、トランスコーディングが特定のセッションのために必要であることを検知するものでなければなりません。
In order to decide whether or not transcoding is needed, a user agent needs to know the capabilities of the remote user agent. A user agent acting as an offerer [RFC3264] typically obtains this knowledge by downloading a presence document that includes media capabilities (e.g., Bob is available on a terminal that only supports audio) or by getting an SDP description of media capabilities as defined in RFC 3264 [RFC3264].
トランスコーディングが必要とされているかどうかを決定するためには、ユーザエージェントは、リモートユーザーエージェントの能力を知っている必要があります。申出[RFC3264]として作用するユーザエージェントは、典型的には、メディア機能を含むプレゼンスドキュメントをダウンロードすることによって（例えば、ボブは音声のみサポートする端末で利用可能である）、またはRFCに定義されているメディア能力のSDP記述を取得することにより、この知識を取得します3264 [RFC3264]。
Presence documents are typically received in a NOTIFY request [RFC3265] as a result of a subscription. SDP media capabilities descriptions are typically received in a 200 (OK) response to an OPTIONS request or in a 488 (Not Acceptable Here) response to an INVITE.
プレゼンス・ドキュメントは、典型的には、サブスクリプションの結果としてNOTIFYリクエスト[RFC3265]で受信されます。 SDPメディア機能の説明は、一般的に要求したり、INVITEに対する488（ここでは許容できない）応答でOPTIONSに200（OK）応答して受信されています。
In the absence of presence information, routing logic that involves parallel forking to several user agents may make it difficult (or impossible) for the caller to know which user agent will answer the next call attempt. For example, a call attempt may reach the user's voicemail while the next one may reach a SIP phone where the user is available. If both terminating user agents have different capabilities, the caller cannot know, even after the first call attempt, whether or not transcoding will be necessary for the session. This is a well-known SIP problem that is referred to as HERFP (Heterogeneous Error Response Forking Problem). Resolving HERFP is outside the scope of this document.
困難（または不可能）発信者が次の呼び出しの試みに応答する際、ユーザエージェント知るために作ることができるいくつかのユーザエージェントに平行フォークを含むプレゼンス情報、ルーティングロジックの非存在下で。次のユーザーが利用可能であるSIPフォンに達する可能性がありながら、例えば、コールの試行は、ユーザーのボイスメールに達する可能性があります。両方の終端ユーザエージェントが異なる機能を持っている場合、呼び出し側は、トランスコーディングがセッションのために必要であろうか、でも最初のコール試行の後、知ることはできません。これはHERFP（ヘテロジニアスエラー応答フォーク問題）と呼ばれている、よく知られているSIPの問題です。解決HERFPは、この文書の範囲外です。
It is recommended that an offerer does not invoke transcoding services before making sure that the answerer does not support the capabilities needed for the session. Making wrong assumptions about the answerer's capabilities can lead to situations where two transcoders are introduced (one by the offerer and one by the answerer) in a session that would not need any transcoding services at all.
オファー側は、回答がセッションのために必要な機能をサポートしていないことを確認する前に、トランスコーディングサービスを起動しないことをお勧めします。回答者の能力について間違った仮定を作ることは一切トランスコーディングサービスを必要としないセッションに2つのトランスコーダが導入されている状況（回答によって、オファーによって1つずつ）につながることができます。
An example of the situation above is a call between two GSM (Global System for Mobile Communications) phones (without using transcoding-free operation). Both phones use a GSM codec, but the speech is converted from GSM to PCM (Pulse Code Modulation) by the originating MSC (Mobile Switching Center) and from PCM back to GSM by the terminating MSC.
このような状況の例は、2つのGSM（移動通信用グローバルシステム）電話（トランスフリー操作を使用せず）との間の呼です。両方の電話機は、GSMコーデックを使用しますが、音声は発信MSC（移動通信交換局）によってと終端MSCによってバックGSMにPCMから（パルス符号変調）GSMからPCMに変換されます。
Note that transcoding services can be symmetric (e.g., speech-to-text plus text-to-speech) or asymmetric (e.g., a one-way speech-to-text transcoding for a hearing-impaired user that can talk).
そのトランスコーディングサービスが対称であることに注意（例えば、スピーチ・トゥ・テキスト・プラステキスト・ツー・スピーチ）又は非対称（例えば、話すことができる聴覚障害者のための一方向音声テキストトランスコード）。
Once the need for transcoding for a particular session has been identified as described in Section 2, one of the user agents needs to invoke transcoding services.
第2節で説明したように、特定のセッションのためのトランスコーディングの必要性が確認された後、ユーザエージェントの一つは、トランスコーディングサービスを呼び出す必要があります。
As stated earlier, transcoder location is outside the scope of this document. So, we assume that the user agent invoking transcoding services knows the URI of a server that provides them.
先に述べたように、トランスコーダの位置は、この文書の範囲外です。そこで、我々は、トランスコーディングサービスを呼び出すユーザエージェントがそれらを提供するサーバのURIを知っていることを前提としています。
Invoking transcoding services from a server (T) for a session between two user agents (A and B) involves establishing two media sessions; one between A and T and another between T and B. How to invoke T's services (i.e., how to establish both A-T and T-B sessions) depends on how we model the transcoding service. We have considered two models for invoking a transcoding service. The first is to use third-party call control [RFC3725], also referred to as 3pcc. The second is to use a (dial-in and dial-out) conference bridge that negotiates the appropriate media parameters on each individual leg (i.e., A-T and T-B).
2つのユーザエージェント（AとB）との間のセッションのためにサーバ（T）からのトランスコーディングサービスを呼び出すと、2つのメディアセッションを確立することを含みます。 AとTとTのサービスを呼び出すための方法TとBの間の別の間の1（すなわち、A-TとT-Bセッションの両方を確立する方法）我々はトランスコーディングサービスをモデル化する方法によって異なります。私たちは、トランスコーディングサービスを呼び出すための2つのモデルを検討しています。最初はまた、3PCCと呼ばれるサードパーティ呼制御[RFC3725]を使用することです。第二は、個々の脚部（すなわち、-TとT-B）に、適切なメディアパラメータをネゴシエート（インダイヤルとダイヤルアウト）会議ブリッジを使用することです。
Section 3.1 analyzes the applicability of the third-party call control model, and Section 3.2 analyzes the applicability of the conference bridge transcoding invocation model.
3.1節では、サードパーティ呼制御モデルの適用性を分析し、3.2節では、会議ブリッジ、トランスコードの呼び出しモデルの適用性を分析します。
In the 3pcc transcoding model, defined in [RFC4117], the user agent invoking the transcoding service has a signalling relationship with the transcoder and another signalling relationship with the remote user agent. There is no signalling relationship between the transcoder and the remote user agent, as shown in Figure 1.
[RFC4117]で定義された3PCCトランスコーディングモデルにおいて、トランスコーディングサービスを呼び出すユーザエージェントはトランスコーダとリモートユーザーエージェントを持つ別のシグナリング関係を有するシグナリング関係を有します。図1に示すように、トランスコーダとリモートユーザーエージェントとの間にシグナリング関係が、存在しません。
+-------+
| |
| T |**
| | **
+-------+ **
^ * **
| * **
| * **
SIP * **
| * **
| * **
v * **
+-------+ +-------+
| | | |
| A |<-----SIP----->| B |
| | | |
+-------+ +-------+
<-SIP-> Signalling ******* Media
<-SIP-> *******メディアシグナリング
Figure 1: Third-Party Call Control Model
図1：サードパーティコール制御モデル
This model is suitable for advanced endpoints that are able to perform third party call control. It allows endpoints to invoke transcoding services on a stream basis. That is, the media streams that need transcoding are routed through the transcoder while the streams that do not need it are sent directly between the endpoints. This model also allows invoking one transcoder for the sending direction and a different one for the receiving direction of the same stream.
このモデルは、サードパーティの呼制御を実行することができます高度なエンドポイントに適しています。これは、エンドポイントは、ストリームごとにトランスコーディングサービスを呼び出すことができます。それを必要としないストリームは、エンドポイント間で直接送信されている間つまり、トランスコーディングを必要とするメディアストリームは、トランスコーダを介してルーティングされます。このモデルはまた、送信方向と同じストリームの受信方向のために別のもののための1つのトランスコーダを起動可能にします。
Invoking a transcoder in the middle of an ongoing session is also quite simple. This is useful when session changes occur (e.g., an audio session is upgraded to an audio/video session) and the endpoints cannot cope with the changes (e.g., they had common audio codecs but no common video codecs).
進行中のセッションの途中でトランスコーダを呼び出すことも非常に簡単です。セッションの変更（例えば、オーディオセッションは、オーディオ/ビデオセッションにアップグレードされます）が発生し、エンドポイントが変化（例えば、彼らが持っていた一般的なオーディオコーデックが、ありません一般的なビデオコーデック）に対応できない場合に便利です。
The privacy level that is achieved using 3pcc is high, since the transcoder does not see the signalling between both endpoints. In this model, the transcoder only has access to the information that is strictly needed to perform its function.
トランスコーダは、両方のエンドポイント間のシグナリングを参照しないので、3PCCを用いて達成されるプライバシーレベルが高いです。このモデルでは、トランスコーダは厳密にその機能を実行するために必要な情報へのアクセスを持っています。
In a centralized conference, there are a number of media streams between the conference server and each participant of a conference. For a given media type (e.g., audio) the conference server sends, over each individual stream, the media received over the rest of the streams, typically performing some mixing. If the capabilities of all the endpoints participating in the conference are not the same, the conference server may have to send audio to different participants using different audio codecs.
集中型の会議では、会議サーバと会議の各参加者との間のメディアストリームの数があります。会議サーバが送信する所定のメディアタイプ（例えば、オーディオ）のために、各個々のストリーム上に、媒体は、典型的には、いくつかの混合を行うことにより、ストリームの残りの部分を介して受信しました。会議に参加しているすべてのエンドポイントの機能が同じでない場合は、会議サーバは、異なるオーディオコーデックを使用して別の参加者に音声を送信する必要があります。
Consequently, we can model a transcoding service as a two-party conference server that may change not only the codec in use, but also the format of the media (e.g., audio to text).
したがって、我々は、使用中のコーデックが、また、メディア（例えば、音声をテキストに）の形式だけでなく、変更される可能性があり、二者会議サーバとしてトランスコーディングサービスをモデル化することができます。
Using this model, T behaves as a B2BUA (Back-to-Back User Agent) and the whole A-T-B session is established as described in [RFC5370]. Figure 2 shows the signalling relationships between the endpoints and the transcoder.
[RFC5370]に記載されているように、このモデルを用いて、TはB2BUA（バックツーバックユーザエージェント）と全A-T-Bのセッションとして挙動が確立されます。図2は、エンドポイントとトランスコーダとの間のシグナリング関係を示しています。
+-------+
| |**
| T | **
| |\ **
+-------+ \\ **
^ * \\ **
| * \\ **
| * SIP **
SIP * \\ **
| * \\ **
| * \\ **
v * \ **
+-------+ +-------+
| | | |
| A | | B |
| | | |
+-------+ +-------+
<-SIP-> Signalling ******* Media
<-SIP-> *******メディアシグナリング
Figure 2: Conference Bridge Model
図2：会議ブリッジモデル
In the conferencing bridge model, the endpoint invoking the transcoder is generally involved in less signalling exchanges than in the 3pcc model. This may be an important feature for endpoints using low-bandwidth or high-delay access links (e.g., some wireless accesses).
会議ブリッジモデルでは、トランスコーダを起動エンドポイントは、3PCCモデルにおけるより少ないシグナリング交換において一般に関与しています。これは、低帯域幅または高遅延アクセスリンク（例えば、いくつかの無線アクセス）を使用してエンドポイントの重要な特徴であり得ます。
On the other hand, this model is less flexible than the 3pcc model. It is not possible to use different transcoders for different streams or for different directions of a stream.
一方、このモデルは、3PCCモデル未満柔軟です。異なるストリームまたはストリームの異なる方向に対して異なるトランスコーダを使用することはできません。
Invoking a transcoder in the middle of an ongoing session or changing from one transcoder to another requires the remote endpoint to support the Replaces [RFC3891] extension. At present, not many user agents support it.
進行中のセッションの途中でトランスコーダを起動するか、別のトランスコーダから変更することはReplaces [RFC3891]拡張をサポートするためのリモートエンドポイントを必要とします。現在では、多くのないユーザエージェントは、それをサポートしています。
Simple endpoints that cannot perform 3pcc and thus cannot use the 3pcc model, of course, need to use the conference bridge model.
3PCCを実行することはできませんので、3PCCモデルを使用することはできませんシンプルなエンドポイントは、当然のことながら、会議ブリッジモデルを使用する必要があります。
The specifications of the 3pcc and the conferencing transcoding models discuss security issues directly related to the implementation of those models. Additionally, there are some considerations that apply to transcoding in general.
3PCCと会議トランスコーディングモデルの仕様は、直接それらのモデルの実装に関連するセキュリティ上の問題を議論します。また、一般的にトランスコーディングに適用されるいくつかの考慮事項があります。
In a session, a transcoder has access to at least some of the media exchanged between the endpoints. In order to avoid rogue transcoders getting access to those media, it is recommended that endpoints authenticate the transcoder. TLS [RFC5246] and S/MIME [RFC3850] can be used for this purpose.
セッションでは、トランスコーダは、メディアの少なくとも一部へのアクセスは、エンドポイント間で交換しました。これらのメディアへのアクセスを取得し、不正なトランスコーダを避けるためには、エンドポイントはトランスコーダを認証することをお勧めします。 TLS [RFC5246]及びS / MIME [RFC3850]は、この目的のために使用することができます。
To achieve a higher degree of privacy, endpoints following the 3pcc transcoding model can use one transcoder in one direction and a different one in the other direction. This way, no single transcoder has access to all the media exchanged between the endpoints.
プライバシーの高い程度を達成するために、3PCCトランスコーディングモデル次エンドポイントは、1つの方向と逆方向の異なる1で1つのトランスコーダを使用することができます。この方法では、単一のトランスコーダは、すべてのメディアへのアクセスは、エンドポイント間で交換されていません。
The fact that transcoders need to access media exchanged between the endpoints implies that endpoints cannot use end-to-end media security mechanisms. Media encryption would not allow the transcoder to access the media, and media integrity protection would not allow the transcoder to modify the media (which is obviously necessary to perform the transcoding function). Nevertheless, endpoints can still use media security between the transcoder and themselves.
トランスコーダは、メディアにアクセスする必要があるという事実は、エンドポイント間で交換エンドポイントは、エンドツーエンドメディアのセキュリティメカニズムを使用することができないことを意味します。メディア暗号化は、トランスコーダは、メディアにアクセスすることを許可しないだろう、とメディアの完全性保護は、トランスコーダは、（トランスコーディング機能を実行することは明らかに必要である）メディアを変更することができません。それにもかかわらず、エンドポイントはまだトランスコーダと自分の間にメディアセキュリティを使用することができます。
This document is the result of discussions amongst the conferencing design team. The members of this team include Eric Burger, Henning Schulzrinne, and Arnoud van Wijk.
この文書は会議デザインチームの中での議論の結果です。このチームのメンバーはエリックバーガー、ヘニングSchulzrinneと、そしてArnoudバンWijkが含まれます。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC3351] 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.
聴覚障害、難聴および音声のサポートに[RFC3351]チャールトン、N.、Gasson、M.、Gybels、G.、スパナ、M.、およびA.バンWijk、「セッション開始プロトコル（SIP）のためのユーザ要件-impaired個人」、RFC 3351、2002年8月。
[RFC3725] 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.
[RFC3725]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[RFC3850] Ramsdell、B.は、RFC 3850、2004年7月、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1証明書の取り扱い"。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891]マーイ、R.、ビッグス、B.、およびR.ディーン、 "セッション開始プロトコル（SIP） "は、" ヘッダ" を置き換えRFC 3891、2004年9月。
[RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, "Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)", RFC 4117, June 2005.
[RFC4117]キャマリロ、G.、バーガー、E.、Schulzrinneと、H.、およびA.バンWijk、 "セッション開始プロトコル（SIP）でのトランスコーディングサービスの呼び出し第三者呼制御（3PCC）の使用" を、6月、RFC 4117を2005。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5370] Camarillo, G., "The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model", RFC 5370, October 2008.
[RFC5370]キャマリロ、G.、 "セッション開始プロトコル（SIP）会議ブリッジトランスコーディングモデル"、RFC 5370、2008年10月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
Author's Address
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。