Network Working Group G. Camarillo
Request for Comments: 5370 Ericsson
Category: Standards Track October 2008
The Session Initiation Protocol (SIP)
Conference Bridge Transcoding Model
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals.
この文書では、会議ブリッジモデルを使用してトランスコーディングサービスを起動する方法について説明します。呼び出しのこの方法では、SIPは、難聴の聴覚障害者、および音声障害者をサポートするために、トランスコーディングサービスの呼び出しについての要件を満たしています。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Caller's Invocation .............................................3
3.1. Procedures at the User Agent ...............................3
3.2. Procedures at the Transcoder ...............................3
3.3. Example ....................................................4
3.4. Unsuccessful Session Establishment .........................6
4. Callee's Invocation .............................................7
5. Security Considerations .........................................7
6. Contributors ....................................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................9
RFC 5369 [RFC5369] describes how two SIP [RFC3261] UAs (User Agents) can discover incompatibilities that prevent them from establishing a session (e.g., lack of support for a common codec or for a common media type). When such incompatibilities are found, the UAs need to invoke transcoding services to successfully establish the session. The transcoding framework introduces two models to invoke transcoding services: the 3pcc (third-party call control) model [RFC4117] and the conference bridge model. This document specifies the conference bridge model.
RFC 5369 [RFC5369]は2つのSIP [RFC3261]のUA（ユーザエージェント）がセッションを確立するのを防止する非互換性を検出する方法について説明（例えば、共通コーデックのまたは共通のメディアタイプのためのサポートの欠如）。このような非互換性が発見された場合、UAは成功し、セッションを確立するために、トランスコーディングサービスを起動する必要があります。 3PCC（サードパーティ呼制御）モデル[RFC4117]及び会議ブリッジモデル：トランスコーディング・フレームワークは、トランスコーディングサービスを呼び出すための2つのモデルを導入します。この文書では、会議ブリッジモデルを指定します。
In the conference bridge model for transcoding invocation, a transcoding server that provides a particular transcoding service (e.g., speech-to-text) behaves as a B2BUA (Back-to-Back User Agent) between both UAs and is identified by a URI. As shown in Figure 1, both UAs, A and B, exchange signalling and media with the transcoder T. The UAs do not exchange any traffic (signalling or media) directly between them.
トランスコードの呼び出し、特定のトランスコーディング・サービスを提供するトランスコーディングサーバの会議ブリッジモデルでは（例えば、スピーチ・ツー・テキスト）は、両方のUA間のB2BUA（バックツーバックユーザエージェント）として動作し、URIによって識別されます。 UAが直接それらの間のすべてのトラフィック（シグナリングまたはメディア）を交換しないトランスコーダTに図1に示すように、双方のUA、AとB、交換シグナリングおよびメディア。
+-------+
| |**
| T | **
| |\ **
+-------+ \\ **
^ * \\ **
| * \\ **
| * SIP **
SIP * \\ **
| * \\ **
| * \\ **
v * \ **
+-------+ +-------+
| | | |
| A | | B |
| | | |
+-------+ +-------+
<-SIP-> Signalling ******* Media
<-SIP-> *******メディアシグナリング
Figure 1: Conference bridge model
図1：会議ブリッジモデル
Sections 3 and 4 specify how the caller A or the callee B, respectively, can use the conference bridge model to invoke transcoding services from T.
発信者A又は被呼者Bは、それぞれ、Tからトランスコーディングサービスを呼び出すために、会議ブリッジモデルを使用する方法のセクション3と4は、指定します
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119], and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、「OPTIONAL」はBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されるべきであり、対応する実装の要求レベルを示します。
User agent A needs to perform two operations to invoke transcoding services from T for a session between user agent A and user agent B. User agent A needs to establish a session with T and provide T with user agent B's URI so that T can generate an INVITE towards user agent B.
ユーザエージェントAは、ユーザエージェントA及びAはTとのセッションを確立し、Tが生成できるようにユーザエージェントBのURIとTを提供する必要があり、ユーザエージェントBのユーザエージェントとの間のセッションのためにTからトランスコーディングサービスを呼び出すための2つの操作を実行する必要がありますユーザエージェントBの方にINVITE
User agent A uses the procedures for RFC 5366 [RFC5366] to provide T with B's URI using the same INVITE that establishes the session between A and T. That is, user agent A adds to the INVITE a body part whose disposition type is recipient-list [RFC5363]. This body part consists of a URI-list that contains a single URI: user agent B's URI.
ユーザエージェントAは、すなわちAとTとのセッションを確立するINVITE同じものを使用してBのURIとTを提供するために、RFC 5366の手順[RFC5366]を使用するユーザエージェントAは、その気質タイプrecipient-あるINVITE身体部分に追加しますリスト[RFC5363]。ユーザエージェントBのURI：この身体の部分は、単一のURIを含むURIリストで構成されています。
Note that, as described in the transcoding framework [RFC5369], the transcoding model described in this document is modeled as a two-party conference server. Consequently, this document focuses on two-party sessions that need transcoding. Multi-party sessions can be established using INVITE requests with multiple URIs in their bodies, as specified in [RFC5366].
トランスコーディング・フレームワーク[RFC5369]で説明したように、このドキュメントで説明するトランスコーディングモデルは、二大政党の会議サーバとしてモデル化されることに注意してください。したがって、この文書は、トランスコーディングを必要とする二者のセッションに焦点を当てています。マルチパーティセッションは、[RFC5366]で指定されるように、自分の体で複数のURIを持つINVITE要求を使用して確立することができます。
On receiving an INVITE with a URI-list body, the transcoder follows the procedures in [RFC5366] to generate an INVITE request towards the URI contained in the URI-list body. Note that the transcoder acts as a B2BUA, not as a proxy.
URIリスト本体とINVITEを受信すると、トランスコーダは、[RFC5366]の手順は、URIリスト本体に含まれるURIに向けてINVITEリクエストを生成するように続きます。トランスコーダがないプロキシとして、B2BUAとして動作することに注意してください。
Additionally, the transcoder MUST generate the From header field of the outgoing INVITE request using the same value as the From header field included in the incoming INVITE request, subject to the privacy requirements (see [RFC3323] and [RFC3325]) expressed in the incoming INVITE request. Note that this does not apply to the "tag" parameter.
また、トランスコーダがヘッダフィールドからプライバシー要件に従う着信INVITE要求に含まれるのと同じ値を使用して、発信INVITE要求のヘッダフィールドから発生させなければなりません（[RFC3323]及び[RFC3325]を参照）、着信中で発現INVITEリクエストを。これは、「タグ」パラメータには適用されないことに注意してください。
The session description the transcoder includes in the outgoing INVITE request depends on the type of transcoding service that particular transcoder provides. For example, a transcoder resolving audio codec incompatibilities would generate a session description listing the audio codecs the transcoder supports.
トランスコーダは、発信INVITEリクエストに含まれるセッション記述は、特定のトランスコーダが提供するトランスコーディングサービスの種類に依存します。例えば、オーディオコーデックの非互換性を解決するトランスコーダは、トランスコーダがサポートするオーディオコーデックをリストセッション記述を生成します。
When the transcoder receives a final response for the outgoing INVITE requests, it generates a new final response for the incoming INVITE request. This new final response SHOULD have the same status code as the one received in the response for the outgoing INVITE request.
トランスコーダは、発信INVITEリクエストに対する最終的な応答を受信すると、受信したINVITEリクエストのための新たな最終応答を生成します。この新しい最終的な応答は、発信INVITEリクエストに対するレスポンスで受け取ったものと同じステータスコードを持つべきである（SHOULD）。
If a transcoder receives an INVITE request with a URI-list with more than one URI, it SHOULD return a 488 (Max 1 URI allowed in URI-list) response.
トランスコーダは、複数のURIとURIリストでINVITE要求を受信した場合、それは488（最大1 URIがURIリストで許可）応答を返すべきです。
Figure 2 shows the message flow for the caller's invocation of a transcoder T. The caller A sends an INVITE (1) to the transcoder (T) to establish the session A-T. Following the procedures in [RFC5366], the caller A adds a body part whose disposition type is recipient-list [RFC5363].
図2は、発信者Aは、（1）トランスコーダ（T）にセッションA-Tを確立するためにINVITEを送信するトランスコーダTの発呼者の呼び出しのためのメッセージフローを示します。 [RFC5366]の手順に続いて、発信者Aは、その配置型受信者リスト[RFC5363]である身体部分を付加します。
A T B
| | |
|-----(1) INVITE SDP A----->| |
| | |
|<-(2) 183 Session Progress-| |
| |-----(3) INVITE SDP TB---->|
| | |
| |<-----(4) 200 OK SDP B-----|
| | |
| |---------(5) ACK---------->|
|<----(6) 200 OK SDP TA-----| |
| | |
|---------(7) ACK---------->| |
| | |
| ************************* | ************************* |
|** Media **|** Media **|
| ************************* | ************************* |
| | |
Figure 2: Successful invocation of a transcoder by the caller
図2：呼び出し側によってトランスコーダの正常な呼び出し
The following example shows an INVITE with two body parts: an SDP [RFC4566] session description and a URI-list.
SDP [RFC4566]セッション記述とURIリスト：次の例では、2つの本体部分とINVITE示します。
INVITE sip:transcoder@example.com SIP/2.0 Via: SIP/2.0/TCP client.chicago.example.com ;branch=z9hG4bKhjhs8ass83 Max-Forwards: 70 To: Transcoder <sip:transcoder@example.org> From: A <sip:A@chicago.example.com>;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 1 INVITE Contact: <sip:A@client.chicago.example.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog Accept: application/sdp, message/sipfrag Require: recipient-list-invite Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 556
INVITE SIP：transcoder@example.com SIP / 2.0経由：SIP / 2.0 / TCP client.chicago.example.com;ブランチ= z9hG4bKhjhs8ass83マックス・フォワード：70：トランスコーダ<SIP：transcoder@example.org>から< SIP：A@chicago.example.com>;タグ= 32331コールID：d432fa84b4c76e66710ののCSeq：1連絡先をINVITE：<SIP：A@client.chicago.example.com>許可：、BYE、INVITE、ACK、CANCEL、OPTIONS REFER、SUBSCRIBE、許可 - イベントをNOTIFY：ダイアログが受け入れ：アプリケーション/ SDPを、メッセージ/ sipfragを要求：受信者リスト - 招待のContent-Typeを：混合/マルチパート;境界= "boundary1" のContent-Length：556
--boundary1 Content-Type: application/sdp
--boundary1のContent-Type：アプリケーション/ SDP
v=0 o=example 2890844526 2890842807 IN IP4 chicago.example.com s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 50000 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 0 =たとえば2890844526 2890842807 IN IP4 chicago.example.com S = - C = IN IP4 192.0.2.1 T = 0、M =オーディオ50000 RTP / AVP 0 A = rtpmap：0 PCMU / 8000
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list
--boundary1のContent-Type：アプリケーション/リソース・リスト+ xmlのコンテンツディスポジション：受信者リスト
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <list> <entry uri="sip:B@example.org" /> </list> </resource-lists> --boundary1--
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：XSI = "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス "> <リスト> <エントリーのURI =" SIP：B@example.org」/> </リスト> </リソース・リスト> --boundary1--
On receiving the INVITE, the transcoder generates a new INVITE towards the callee. The transcoder acts as a B2BUA, not as a proxy. Therefore, this new INVITE (3) belongs to a different transaction than the INVITE (1) received by the transcoder.
INVITEを受信すると、トランスコーダは新しいが、呼び出し先に向けてINVITEを生成します。トランスコーダはないプロキシとして、B2BUAとして機能します。したがって、この新しい（3）（1）トランスコーダで受信されたINVITEは異なるトランザクションに属するINVITE。
When the transcoder receives a final response (4) from the callee, it generates a new final response (6) for INVITE (1). This new final response (6) has the same status code as the one received in the response from the callee (4).
トランスコーダは、被呼者から（4）最終的な応答を受信すると、（1）INVITEのための新たな最終応答（6）を生成します。一つの呼び出し先（4）からの応答で受信し、この新たな最終応答（6）が、同じステータスコードを有しています。
Figure 3 shows a similar message flow as the one in Figure 3. Nevertheless, this time the callee generates a non-2xx final response (4). Consequently, the transcoder generates a non-2xx final response (6) towards the caller as well.
図3は、それにもかかわらず、この時間は、被呼者が非2xxの最終的な応答を生成する図3のものと同様のメッセージ・フローを示している（4）。結果として、トランスコーダは、同様に、呼び出し側に向かって非2xxの最終応答（6）を生成します。
A T B
| | |
|-----(1) INVITE SDP A----->| |
| | |
|<-(2) 183 Session Progress-| |
| |-----(3) INVITE SDP TB---->|
| | |
| |<----(4) 603 Decline-------|
| | |
| |---------(5) ACK---------->|
|<----(6) 603 Decline-------| |
| | |
|---------(7) ACK---------->| |
| | |
Figure 3: Unsuccessful session establishment
図3：失敗したセッション確立
The ambiguity in this flow is that, if the provisional response (2) gets lost, the caller does not know whether the 603 (Decline) response means that the initial INVITE (1) was rejected by the transcoder or that the INVITE generated by the transcoder (4) was rejected by the callee. The use of the "History-Info" header field [RFC4244] between the transcoder and the caller resolves the previous ambiguity.
このフローの曖昧さは、暫定的な応答（2）が失われた場合、発信者が603（拒否）応答は、初期のINVITEことを意味するかどうかわからない、ということである（1）トランスコーダにより、またはによって生成されたINVITEことが拒否されました（4）トランスコーダは、呼び出し先によって拒否されました。トランスコーダと発呼者の間の「履歴-INFO」ヘッダフィールド[RFC4244]を使用することは、以前の曖昧さを解決します。
Note that this ambiguity problem could also have been resolved by having transcoders act as a pure conference bridge. The transcoder would respond with a 200 (OK) to the INVITE request from the caller, and it would generate an outgoing INVITE request towards the callee. The caller would get information about the result of the latter INVITE request by subscribing to the conference event package [RFC4575] at the transcoder. Although this flow would have resolved the ambiguity problem without requiring support for the "History-Info" header field, it is more complex, requires a higher number of messages, and introduces higher session setup delays. That is why it was not chosen to implement transcoding services.
この曖昧さの問題もトランスコーダは、純粋な会議ブリッジとして動作することによって解決されている可能性があることに注意してください。トランスコーダは、発信者からのINVITEリクエストに対する200（OK）と応答すると、それが呼び出し先に向けて、発信INVITEリクエストを生成します。呼び出し側は、トランスコーダの会議イベントパッケージ[RFC4575]に加入することにより、後者のINVITEリクエストの結果に関する情報を得るでしょう。このフローは「歴史・インフォメーション」ヘッダフィールドのサポートを必要とせず、あいまいさの問題を解決しているだろうが、それはより複雑で、メッセージの高い数を必要とし、高いセッションセットアップの遅延を導入しています。それはトランスコーディングサービスを実装するために選ばれなかった理由です。
If a UA receives an INVITE with a session description that is not acceptable, it can redirect it to the transcoder by using a 302 (Moved Temporarily) response. The Contact header field of the 302 (Moved Temporarily) response contains the URI of the transcoder plus a "?body=" parameter. This parameter contains a recipient-list body with B's URI. Note that some escaping (e.g., for Carriage Returns and Line Feeds) is needed to encode a recipient-list body in such a parameter. Figure 4 shows the message flow for this scenario.
UAが許容されないセッション記述でINVITEを受信した場合、それは302（一時的に移動）応答を使用して、トランスコーダにリダイレクトすることができます。 302（一時的に移動）応答のContactヘッダーフィールドは、パラメータ「本体=」トランスコーダプラスAのURIを含んでいます。このパラメータは、BのURIを受信者リストの体が含まれています。いくつかの（キャリッジリターンとラインフィードのために、例えば）エスケープこのようなパラメータには、受信者リストの体をエンコードするために必要であることに注意してください。図4は、このシナリオのメッセージフローを示します。
A T B
| | |
|-------------------(1) INVITE SDP A------------------->|
| | |
|<--------------(2) 302 Moved Temporarily---------------|
| | |
|-----------------------(3) ACK------------------------>|
| | |
|-----(4) INVITE SDP A----->| |
| | |
|<-(5) 183 Session Progress-| |
| |-----(6) INVITE SDP TB---->|
| | |
| |<-----(7) 200 OK SDP B-----|
| | |
| |---------(8) ACK---------->|
|<----(9) 200 OK SDP TA-----| |
| | |
|--------(10) ACK---------->| |
| | |
| ************************* | ************************* |
|** Media **|** Media **|
| ************************* | ************************* |
Figure 4: Callee's invocation of a transcoder
図4：トランスコーダの呼び出し先の呼び出し
Note that the syntax resulting from encoding a body into a URI as described earlier is quite complex. It is actually simpler for callees to invoke transcoding services using the 3pcc transcoding model [RFC4117] instead.
前述のようにURIに体をコード起因する構文は非常に複雑であることに留意されたいです。呼び出し先ではなく3PCCトランスコーディングモデル[RFC4117]を使用してトランスコーディングサービスを起動することは、実際に簡単です。
Transcoders implementing this specification behave as a URI-list service as described in [RFC5366]. Therefore, the security considerations for URI-list services discussed in [RFC5363] apply here as well.
[RFC5366]に記載されているようにURIリストサービスとして動作この仕様を実装するトランスコーダ。したがって、[RFC5363]で議論URIリストサービスのセキュリティの考慮事項はここにも適用されます。
In particular, the requirements related to list integrity and unsolicited requests are important for transcoding services. User agents SHOULD integrity protect URI-lists using mechanisms such as S/MIME [RFC3850] or TLS [RFC5246], which can also provide URI-list confidentiality if needed. Additionally, transcoders MUST authenticate and authorize users and MAY provide information about the identity of the original sender of the request in their outgoing requests by using the SIP identity mechanism [RFC4474].
具体的には、整合性と迷惑リクエストを一覧表示するには関連する要件は、トランスコーディングサービスのために重要です。ユーザエージェントは、整合性が必要な場合にも、URIリストの機密性を提供することができ、このようなS / MIMEなどのメカニズム[RFC3850]またはTLS [RFC5246]を使用して、URI-リストを保護する必要があります。さらに、トランスコーダは、ユーザを認証および認可し、SIPアイデンティティメカニズム[RFC4474]を使用して、発信要求で要求の元の送信者の身元に関する情報を提供することができる必要があります。
The requirement in [RFC5363] to use opt-in lists (e.g., using RFC 5360 [RFC5360]) deserves special discussion. The type of URI-list service implemented by transcoders following this specification does not produce amplification (only one INVITE request is generated by the transcoder on receiving an INVITE request from a user agent) and does not involve a translation to a URI that may be otherwise unknown to the caller (the caller places the callee's URI in the body of its initial INVITE request). Additionally, the identity of the caller is present in the INVITE request generated by the transcoder. Therefore, there is no requirement for transcoders implementing this specification to use opt-in lists.
[RFC5363]での要件は、オプトインリストを使用する（例えば、RFC 5360 [RFC5360]を使用して）特別な議論に値します。増幅を生じない、本明細書以下のトランスコーダにより実装URIリストサービスのタイプは、（1つのみINVITE要求は、ユーザエージェントからINVITE要求を受け取ると、トランスコーダによって生成される）と、それ以外の場合であってもよいURIへの変換を伴いません呼び出し元に未知の（呼び出し側が初期INVITEリクエストのボディに呼び出し先のURIを置きます）。また、発信者の身元は、トランスコーダによって生成されたINVITE要求内に存在します。したがって、オプトインリストを使用するには、この仕様を実装するトランスコーダのための必要はありません。
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が含まれます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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月。
[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月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[RFC3850] Ramsdell、B.、エド。、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1証明書の取扱い"、RFC 3850、2004年7月。
[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。
[RFC5369] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol", RFC 5369, October 2008.
[RFC5369]キャマリロ、G.、 "セッション開始プロトコルとトランスコーディングのための枠組み"、RFC 5369、2008年10月。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[RFC5363]キャマリロ、G.およびA.B.ローチ、RFC 5363、2008年10月「セッション開始プロトコル（SIP）URIリストサービスのためのフレームワークとセキュリティの考慮事項」。
[RFC5366] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", RFC 5366, October 2008.
[RFC5366]キャマリロ、G.とA.ジョンストン、 "会議の設立セッション開始プロトコル（SIP）に要求-含まれるリストの使用"、RFC 5366、2008年10月。
[RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244]バーンズ、M.、エド。、 "リクエスト履歴情報のためのセッション開始プロトコル（SIP）への拡張"、RFC 4244、2005年11月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[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月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]ローゼンバーグ、J.、Schulzrinneと、H.、およびO.レヴィン、エド。、 "Aセッション開始プロトコル（SIP）の会議の状態のためのイベントパッケージ"、RFC 4575、2006年8月。
[RFC5360] Rosenberg, J., "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", RFC 5360, October 2008.
[RFC5360]ローゼンバーグ、J.、 "セッション開始プロトコルに同意ベースの通信のためのフレームワーク（SIP）"、RFC 5360、2008年10月。
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に情報を記述してください。