RFC5369 日本語訳
5369 Framework for Transcoding with the Session Initiation Protocol(SIP). G. Camarillo. October 2008. (Format: TXT=20428 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Camarillo Request for Comments: 5369 Ericsson Category: Informational October 2008
コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 5369年のエリクソンカテゴリ: 情報の2008年10月
Framework for Transcoding with the Session Initiation Protocol (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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 コード変換サービス. . . . . . . . 2 3の必要性の発見。 コード変換サービス実施. . . . . . . . . . . . . . . . 4 3.1 第三者呼び出し規制コード変換モデル. . . . . . . . 4 3.2。 カンフェレンス・ブリッジコード変換モデル. . . . . . . . . . . . 6 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 7 5。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 8 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1。 引用規格. . . . . . . . . . . . . . . . . . . 8 6.2。 有益な参照. . . . . . . . . . . . . . . . . . 9
Camarillo Informational [Page 1] RFC 5369 Transcoding Framework October 2008
[1ページ]RFC5369コード変換フレームワーク2008年10月の情報のキャマリロ
1. Introduction
1. 序論
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.
このドキュメントはメディアサーバ発見について説明しません。 それは1つがユーザエージェントの食糧を供給することを使用するか、他のメソッドを扱うことができるという直交した問題です。
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でさらにそれぞれ説明されます)。 両方のモデルはRFC3351[RFC3351]でコード変換サービス実施に関して条件を満たします。(RFCは聴覚障害の、そして、耳が遠くて、スピーチによって損なわれた個人をサポートします)。
2. Discovery of the Need for Transcoding Services
2. コード変換サービスの必要性の発見
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.
RFC3238[RFC3238]で定義された1パーティーの同意モデルに従ってコミュニケーションにかかわる終点の1つでメディア操作実施にかかわるサービスを呼び出すのが最も良い、ネットワークにおける仲介者によって呼び出されることと対照的に。 この原則に従って、終点の1つはそのコード変換を検出するものが特定のセッションに必要であるということであるべきです。
Camarillo Informational [Page 2] RFC 5369 Transcoding Framework October 2008
[2ページ]RFC5369コード変換フレームワーク2008年10月の情報のキャマリロ
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]として務めているユーザエージェントは、メディア能力(例えば、ボブはオーディオを支えるだけである端末に手があいている)を含んでいる存在ドキュメントをダウンロードするか、またはRFC3264[RFC3264]で定義されるようにメディア能力のSDP記述を得ることによって、この知識を通常得ます。
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]に存在ドキュメントを通常受け取ります。 OPTIONS要求への200(OK)応答かINVITEへの488(Acceptable Hereでない)応答でSDPメディア能力記述を通常受けます。
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(異種のError Response Forking Problem)と呼ばれるよく知られる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.
申出人がanswererがセッションに必要である能力をサポートしないのを確実にする前にコード変換サービスを呼び出さないのは、お勧めです。 answererの能力に関する間違った仮定をするのは全く少しのコード変換サービスも必要としないセッションのときに2つのトランスコーダが導入される状況(申出人による1とanswererによる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.
上の状況に関する例はGSM(汎欧州デジタルセルラーシステム)が電話をする(無コード変換の操作を使用しないで)2の間の呼び出しです。 両方の電話はGSMコーデックを使用しますが、スピーチはGSMからPCM(パルスコードの変調)まで終わっているMSCによって起因するMSC(モバイルSwitchingセンター)と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).
コード変換サービスが左右対称であるか(例えば、スピーチからテキストとテキストからスピーチ)、または非対称である場合があることに(例えば、話すことができる聴覚障害のユーザのためのスピーチからテキストへの一方向コード変換)注意してください。
Camarillo Informational [Page 3] RFC 5369 Transcoding Framework October 2008
[3ページ]RFC5369コード変換フレームワーク2008年10月の情報のキャマリロ
3. Transcoding Services Invocation
3. コード変換サービス実施
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のサービスを呼び出すTとB.Howの間の別のもの(すなわち、どうA-TとT-Bセッションの両方を確立する)は私たちがどうコード変換サービスをモデル化するかに頼っています。 私たちは、コード変換サービスを呼び出すために2つのモデルを考えました。 1番目はまた、3pccと呼ばれた第三者呼び出しコントロール[RFC3725]を使用することです。 2番目がaを使用することである、(ダイヤルイン、ダイヤルアウト) そして、それぞれの個々の脚(すなわち、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はカンフェレンス・ブリッジコード変換実施のモデルの適用性を分析します。
3.1. Third-Party Call Control Transcoding Model
3.1. 第三者呼び出し規制コード変換モデル
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に示されるようにありません。
Camarillo Informational [Page 4] RFC 5369 Transcoding Framework October 2008
[4ページ]RFC5369コード変換フレームワーク2008年10月の情報のキャマリロ
+-------+
| |
| T |**
| | **
+-------+ **
^ * **
| * **
| * **
SIP * **
| * **
| * **
v * **
+-------+ +-------+
| | | |
| A |<-----SIP----->| B |
| | | |
+-------+ +-------+
+-------+ | | | T|** | | ** +-------+ ** ^ * ** | * ** | * ** 一口***| * ** | * ** ***+に対して-------+ +-------+ | | | | | A| <、-、-、-、--一口----->| 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を使用することで達成されるプライバシーレベルは高いです、トランスコーダが両方の終点の間の合図を見ないので。 このモデルでは、トランスコーダは機能を実行するのに厳密に必要である情報に近づく手段を持っているだけです。
3.2. Conference Bridge Transcoding Model
3.2. カンフェレンス・ブリッジコード変換モデル
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,
集結された会議には、会議サーバと会議の各関係者の間には、多くのメディアストリームがあります。 与えられたメディアタイプ(例えば、オーディオ)のために、会議サーバは発信します。
Camarillo Informational [Page 5] RFC 5369 Transcoding Framework October 2008
[5ページ]RFC5369コード変換フレームワーク2008年10月の情報のキャマリロ
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(支持するために戻っているUserエージェント)として振る舞います、そして、全体のA-T-Bセッションは[RFC5370]で説明されるように確立されます。 図2は終点とトランスコーダとの合図関係を示しています。
+-------+
| |**
| T | **
| |\ **
+-------+ \\ **
^ * \\ **
| * \\ **
| * SIP **
SIP * \\ **
| * \\ **
| * \\ **
v * \ **
+-------+ +-------+
| | | |
| A | | B |
| | | |
+-------+ +-------+
+-------+ | |** | T| ** | |\ ** +-------+ \\ ** ^ * \\ ** | * \\ ** | * 一口**一口*\\**| * \\ ** | * \\**対*\**+-------+ +-------+ | | | | | 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モデルほどフレキシブルではありません。 異なったストリームかストリームの異なった方向に異なったトランスコーダを使用するのは可能ではありません。
Camarillo Informational [Page 6] RFC 5369 Transcoding Framework October 2008
[6ページ]RFC5369コード変換フレームワーク2008年10月の情報のキャマリロ
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.
進行中のセッションの途中にトランスコーダを呼び出すか、または1つのトランスコーダから別のものに変化するのが、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モデルを使用できない簡単な終点は、カンフェレンス・ブリッジモデルを使用する必要があります。
4. Security Considerations
4. セキュリティ問題
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つのトランスコーダと異なったものをもう片方の方向に使用できます。 この道には、どんな単一のトランスコーダも終点の間で交換されたすべてのメディアに近づく手段を持っていません。
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.
トランスコーダが、終点の間で交換されたメディアにアクセスする必要があるという事実は、終点が終わりから終わりへのメディアセキュリティー対策を使用できないのを含意します。トランスコーダはメディア暗号化からメディアにアクセスできないでしょう、そして、メディア保全保護はトランスコーダがメディアを変更するのを許容しないでしょう(コード変換機能を実行するのに明らかに必要です)。 それにもかかわらず、終点はまだトランスコーダと自分たちの間のメディアセキュリティを使用できます。
5. Contributors
5. 貢献者
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.
このドキュメントは会議デザインチームでの議論の結果です。 このチームのメンバーはエリックBurger、ヘニングSchulzrinne、およびArnoudバンウェイクを入れます。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services",
RFC 3238, January 2002.
[RFC3238] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
Camarillo Informational [Page 7] RFC 5369 Transcoding Framework October 2008
[7ページ]RFC5369コード変換フレームワーク2008年10月の情報のキャマリロ
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、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.、Spanner、M.、およびA.はウェイク、「聴覚障害の、そして、耳が遠くてスピーチによって損なわれた個人を支持したセッション開始プロトコル(一口)のためのユーザ要件」をバンに積みます、RFC3351、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.キャマリロ、「セッション開始という第三者呼び出しコントロール(3pcc)のための最も良い現在の実務は(一口)について議定書の中で述べます」、BCP85、RFC3725、2004年4月。
[RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, July 2004.
[RFC3850] Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1証明書取り扱い」、RFC3850、2004年7月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
[RFC3891] マーイ、R.、ビッグズ、B.、およびR.ディーン、RFC3891、「セッション開始プロトコル(一口)はヘッダーを「取り替え」であっ」て、9月は2004です。
[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.、Burger、E.、Schulzrinne、H.、およびA.はウェイクをバンに積みます、「セッション開始プロトコル(一口)のコード変換サービス実施は第三者呼び出しコントロール(3pcc)を使用し」て、RFC4117、2005年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2008年8月にバージョン1.2インチ、RFC5246について議定書の中で述べます」。
[RFC5370] Camarillo, G., "The Session Initiation Protocol (SIP)
Conference Bridge Transcoding Model", RFC 5370,
October 2008.
G.、「セッション開始プロトコル(一口)カンフェレンス・ブリッジコード変換モデル」(RFC5370)2008年10月の[RFC5370]キャマリロ。
6.2. Informative References
6.2. 有益な参照
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
Camarillo Informational [Page 8] RFC 5369 Transcoding Framework October 2008
[8ページ]RFC5369コード変換フレームワーク2008年10月の情報のキャマリロ
Author's Address
作者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Camarillo Informational [Page 9] RFC 5369 Transcoding Framework October 2008
[9ページ]RFC5369コード変換フレームワーク2008年10月の情報のキャマリロ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Camarillo Informational [Page 10]
キャマリロ情報です。[10ページ]
一覧
スポンサーリンク
