[要約] RFC 5369は、SIPを使用したトランスコーディングのためのフレームワークを提供します。このRFCの目的は、SIPセッション中のメディアの変換やエンコードを効果的に行うためのガイドラインを提供することです。
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を使用したトランスコーディングのフレームワークを定義します。このフレームワークには、セッションでトランスコーディングサービスの必要性を発見する方法と、それらのトランスコーディングサービスを呼び出す方法が含まれます。トランスコーディングサービスの呼び出しの2つのモデルについて説明します。カンファレンスブリッジモデルとサードパーティコールコントロールモデルです。どちらのモデルも、聴覚障害者、聴覚障害、音声障害のある個人をサポートするためのトランスコーディングサービスの呼び出しに関する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つによって最もよく呼び出されます。この原則に従って、エンドポイントの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メディア機能の説明は、通常、オプションリクエストに対する200（OK）の応答または招待に対する488（ここでは受け入れられない）応答で受信されます。
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つは提供者によって1つ、もう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コーデックを使用していますが、スピーチはGSMからPCM（Pulse Code Modulation）に変換され、MSC（モバイルスイッチングセンター）によって、および終端MSCによってPCMからGSMに戻ります。
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で説明されているように、特定のセッションのトランスコーディングの必要性が特定されると、ユーザーエージェントの1つがトランスコーディングサービスを呼び出す必要があります。
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とBの間の1つは、Tのサービスを呼び出す方法（つまり、A-TとT-Bセッションの両方を確立する方法）は、トランスコーディングサービスのモデル化方法に依存します。トランスコーディングサービスを呼び出すための2つのモデルを検討しました。1つ目は、3PCCとも呼ばれるサードパーティのコールコントロール[RFC3725]を使用することです。2つ目は、個々の脚（つまり、A-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
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).
その結果、使用中のコーデックだけでなく、メディアの形式（テキストのオーディオなど）の形式を変更する可能性のある2パーティの会議サーバーとしてトランスコーディングサービスをモデル化できます。
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.
このモデルを使用して、TはB2BUA（連続したユーザーエージェント）として動作し、[RFC5370]に記載されているようにA-T-Bセッション全体が確立されます。図2は、エンドポイントとトランスコダーの間のシグナル伝達関係を示しています。
+-------+
| |**
| T | **
| |\ **
+-------+ \\ **
^ * \\ **
| * \\ **
| * SIP **
SIP * \\ **
| * \\ **
| * \\ **
v * \ **
+-------+ +-------+
| | | |
| A | | B |
| | | |
+-------+ +-------+
<-SIP-> Signalling
******* Media
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.
進行中のセッションの途中でトランスコダーを呼び出すか、あるトランスコダーから別のトランスコダーに変更するには、[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モデルを使用できない単純なエンドポイントは、もちろん、Conference Bridgeモデルを使用する必要があります。
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.
セッションでは、トランスコダーは、エンドポイント間で交換されるメディアの少なくとも一部にアクセスできます。Rogue Transcoderがこれらのメディアにアクセスできるようにするためには、エンドポイントがトランスコダーを認証することをお勧めします。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つの方向に、別の方向に異なるトランスコーダーを使用できます。これにより、エンドポイント間で交換されるすべてのメディアにアクセスできる単一のトランスコダーはありません。
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.
このドキュメントは、会議デザインチームの間での議論の結果です。このチームのメンバーには、エリックバーガー、ヘニングシュルツリンヌ、アーノウドヴァンウィックが含まれます。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238] Floyd、S。およびL. Daigle、「Open Pluggable Edge Servicesの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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、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] Charlton、N.、Gasson、M.、Gybels、G.、Spanner、M.、およびA. Van Wijk、「聴覚障害、聴覚、スピーチをサポートするセッション開始プロトコル（SIP）のユーザー要件 - 障害のある個人」、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] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコールコントロール（3PCC）の最良の現在のプラクティス」、BCP 85、RFC 3725、2004年4月。
[RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[RFC3850] Ramsdell、B。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（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] Camarillo、G.、Burger、E.、Schulzrinne、H.、およびA. Van Wijk、「サードパーティコールコントロール（3PCC）を使用したセッション開始プロトコル（SIP）のトランスコーディングサービスの呼び出し」、RFC 4117、6月2005年。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[RFC5370] Camarillo, G., "The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model", RFC 5370, October 2008.
[RFC5370] Camarillo、G。、「セッション開始プロトコル（SIP）会議ブリッジトランスコードモデル」、RFC 5370、2008年10月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
Author's Address
著者の連絡先
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。