[要約] RFC 5370は、SIP会議ブリッジのトランスコーディングモデルに関する規格です。このRFCの目的は、異なるコーデックを使用するSIPセッション間での音声トランスコーディングを効率的に行うためのモデルを提供することです。
Network Working Group G. Camarillo
Request for Comments: 5370 Ericsson
Category: Standards Track October 2008
The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model
セッション開始プロトコル（SIP）カンファレンスブリッジトランスコーディングモデル
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.
このドキュメントでは、Conference Bridgeモデルを使用してトランスコーディングサービスを呼び出す方法について説明します。この呼び出し方法は、聴覚障害者、聴覚障害、音声障害のある個人をサポートするためのトランスコーディングサービスの呼び出しに関する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] UAS（ユーザーエージェント）が、セッションの確立を妨げる非互換性を発見する方法を説明しています（たとえば、一般的なコーデックや一般的なメディアタイプのサポートの欠如）。このような非互換性が見つかった場合、UASはセッションを正常に確立するためにトランスコーディングサービスを呼び出す必要があります。トランスコーディングフレームワークでは、3PCC（サードパーティコールコントロール）モデル[RFC4117]とカンファレンスブリッジモデルのトランスコーディングサービスを呼び出す2つのモデルを紹介します。このドキュメントは、Conference Bridgeモデルを指定します。
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.
トランスコーディングの呼び出しの会議ブリッジモデルでは、特定のトランスコーディングサービス（スピーチツーテキストなど）を提供するトランスコーディングサーバーは、両方のUAS間のB2BUA（バックツーバックユーザーエージェント）として動作し、URIによって識別されます。図1に示すように、UAS、A、Bの両方、トランスコダーTとの交換シグナルとメディア。UASは、それらの間にトラフィック（シグナルまたはメディア）を直接交換しません。
+-------+
| |**
| T | **
| |\ **
+-------+ \\ **
^ * \\ **
| * \\ **
| * SIP **
SIP * \\ **
| * \\ **
| * \\ **
v * \ **
+-------+ +-------+
| | | |
| A | | B |
| | | |
+-------+ +-------+
<-SIP-> Signalling
******* Media
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.
セクション3および4では、それぞれ発信者AまたはCallee BがConference Bridgeモデルを使用してTからトランスコーディングサービスを呼び出す方法を指定します。
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.
このドキュメントでは、キーワードは「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうは思わない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、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とユーザーエージェントBの間のセッションのためにTからトランスコーディングサービスを呼び出すために2つの操作を実行する必要があります。ユーザーエージェントAは、Tでセッションを確立し、ユーザーエージェントBのURIを提供する必要があります。ユーザーエージェントBに招待します。
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は、RFC 5366 [RFC5366]の手順を使用して、AとTの間のセッションを確立するのと同じ招待状を使用してBのURIを提供します。リスト[RFC5363]。このボディの部分は、単一のURI：ユーザーエージェントBの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]で説明されているように、このドキュメントで説明されているトランスコーディングモデルは、2パーティの会議サーバーとしてモデル化されていることに注意してください。したがって、このドキュメントは、トランスコーディングが必要な2パーティのセッションに焦点を当てています。[RFC5366]で指定されているように、体内に複数のURIを含む招待リクエストを使用して、マルチパーティセッションを確立できます。
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リストボディを招待すると、トランスコダーは[RFC5366]の手順に従って、URIリスト本体に含まれるURIへの招待リクエストを生成します。トランスコダーは、プロキシとしてではなく、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.
さらに、トランスコダーは、受信要件（[RFC3323]および[RFC3325]を参照）を条件として、着信招待リクエストに含まれるヘッダーフィールドと同じ値を使用して、発信招待要求のヘッダーフィールドから生成する必要があります。リクエストを招待します。これは「タグ」パラメーターには適用されないことに注意してください。
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.
Transcoderには、発信招待リクエストに含まれるセッションの説明は、特定のTranscoderが提供するトランスコーディングサービスのタイプに依存します。たとえば、オーディオコーデックの非互換性を解決するトランスコダーの解決は、トランスコダーがサポートするオーディオコーデックをリストするセッションの説明を生成します。
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.
Transcoderが発信招待リクエストの最終応答を受信すると、着信招待リクエストの新しい最終応答が生成されます。この新しい最終応答は、発信招待リクエストの応答で受信したステータスコードと同じステータスコードを持つ必要があります。
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.
Transcoderが複数のURIを備えたURIリストを使用して招待リクエストを受信した場合、488（URI-Listで許可されている最大1 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は、発信者のトランスコダーTの呼び出しのメッセージフローを示しています。発信者Aは、セッションA-Tを確立するためにトランスコダー（T）に招待（1）を送信します。[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.
次の例は、2つの身体部分を持つ招待状を示しています。SDP[RFC4566]セッションの説明とURIリストです。
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
--boundary1
Content-Type: application/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 o =例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
--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--
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.
招待状を受け取ると、トランスコダーはカリーに向かって新しい招待状を生成します。トランスコダーは、プロキシとしてではなく、B2BUAとして機能します。したがって、この新しい招待（3）は、トランスコダーが受け取った招待（1）とは異なるトランザクションに属します。
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).
TranscoderがCalleeから最終応答（4）を受信すると、招待（1）の新しい最終応答（6）が生成されます。この新しい最終応答（6）は、Callee（4）からの応答で受け取ったものと同じステータスコードを持っています。
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は、図3のメッセージと同様のメッセージフローを示しています。それでも、今回はCalleeが非2xx最終応答を生成します（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（衰退）応答がトランスコダーによって拒否されたことを意味するかどうか、または最初の招待が拒否されたか、またはTranscoder（4）はCalleeによって拒否されました。トランスコーダーと発信者の間で「History-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.
このあいまいさの問題は、トランスコダーを純粋な会議橋として機能させることによって解決された可能性があることに注意してください。トランスコダーは、発信者からの招待リクエストに200（OK）で応答し、Calleeへの発信招待リクエストを生成します。発信者は、トランスコダーで会議イベントパッケージ[RFC4575]を購読することにより、後者の招待リクエストの結果に関する情報を取得します。このフローは、「履歴INFO」ヘッダーフィールドをサポートすることなく曖昧さの問題を解決しましたが、より複雑であり、より多くのメッセージを必要とし、セッションのセットアップの遅延が高くなります。そのため、トランスコーディングサービスを実装するために選択されていません。
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が受け入れられないセッションの説明で招待を受け取った場合、302（一時的に移動）応答を使用してトランスコダーにリダイレクトできます。302（一時的に移動）のコンタクトヘッダーフィールドには、トランスコダーのURIと「？body =」パラメーターが含まれています。このパラメーターには、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：TranscoderのCalleeの呼び出し
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にエンコードすることに起因する構文は非常に複雑であることに注意してください。実際、Calleesが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].
特に、リストの整合性と未承諾要求に関連する要件は、トランスコーディングサービスにとって重要です。ユーザーエージェントは、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-Listサービスのタイプは増幅を生成しません（ユーザーエージェントからの招待リクエストを受信する際にトランスコダーによって1つの招待要求のみが生成されます）。発信者には知られていない（発信者は、CalleeのURIを最初の招待リクエストの本体に配置します）。さらに、発信者の身元は、トランスコダーによって生成された招待要求に存在します。したがって、この仕様を実装してオプトインリストを使用するトランスコダーには要件はありません。
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.
このドキュメントは、会議デザインチームの間での議論の結果です。このチームのメンバーには、エリックバーガー、ヘニングシュルツリンヌ、アーノウドヴァンウィックが含まれます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（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.、ed。、「Secure/Multipurpose Internet Mail Extensions（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] Camarillo、G.、Burger、E.、Schulzrinne、H.、およびA. Van Wijk、「サードパーティコールコントロール（3PCC）を使用したセッション開始プロトコル（SIP）のトランスコーディングサービスの呼び出し」、RFC 4117、6月2005年。
[RFC5369] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol", RFC 5369, October 2008.
[RFC5369] Camarillo、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.Roach、「セッション開始プロトコル（SIP）URI-List Servicesのフレームワークとセキュリティ上の考慮事項」、RFC 5363、2008年10月。
[RFC5366] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", RFC 5366, October 2008.
[RFC5366] Camarillo、G。およびA. Johnston、「セッション開始プロトコル（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] Barnes、M.、ed。、「リクエスト履歴情報のセッション開始プロトコル（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] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[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月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、ed。、「Conference Stateのセッション開始プロトコル（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] Rosenberg、J。、「セッション開始プロトコル（SIP）における同意ベースのコミュニケーションのフレームワーク」、RFC 5360、2008年10月。
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への情報をお問い合わせください。