[要約] RFC 6567は、SIPでユーザー間の通話制御情報を転送するための問題と要件を定義しています。このRFCの目的は、SIPベースの通信システムでユーザー間の通話制御情報を効果的に転送するためのソリューションを提供することです。
Internet Engineering Task Force (IETF) A. Johnston
Request for Comments: 6567 Avaya
Category: Informational L. Liess
ISSN: 2070-1721 Deutsche Telekom AG
April 2012
Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP
SIPでユーザー間通話制御情報を転送するための問題ステートメントと要件
Abstract
概要
This document introduces the transport of call control User-to-User Information (UUI) using the Session Initiation Protocol (SIP) and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the Integrated Services Digital Network (ISDN) UUI Service, this extension will also be used for native SIP endpoints requiring application UUI.
このドキュメントでは、セッション開始プロトコル（SIP）を使用した呼制御のユーザー間情報（UUI）のトランスポートを紹介し、新しいSIPメカニズムの要件をいくつか開発します。一部のSIPセッションは、SIP以外のアプリケーションによって確立されるか、関連します。このアプリケーションには、セッションの確立中にSIPユーザーエージェント間で転送する必要のある情報が含まれている場合があります。統合デジタルサービス通信網（ISDN）UUIサービスとの相互作用に加えて、この拡張機能は、アプリケーションUUIを必要とするネイティブSIPエンドポイントにも使用されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6567.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6567で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Overview ........................................................2
2. Use Cases .......................................................3
2.1. User Agent to User Agent ...................................3
2.2. Proxy Retargeting ..........................................4
2.3. Redirection ................................................4
2.4. Referral ...................................................5
3. Requirements ....................................................6
4. Security Considerations .........................................8
5. Acknowledgements ...............................................10
6. Informative References .........................................10
This document describes the transport of User-to-User Information (UUI) during SIP [RFC3261] session setup. This section introduces UUI and explains how it relates to SIP.
このドキュメントでは、SIP [RFC3261]セッションのセットアップ中のユーザー間情報（UUI）の転送について説明します。このセクションでは、UUIを紹介し、それがSIPとどのように関連するかを説明します。
We define SIP UUI data as application-specific information that is related to a session being established using SIP. It is assumed that the application is running in both endpoints in a two-party session. That is, the application interacts with both the User Agents in a SIP session. In order to function properly, the application needs a small piece of information, the UUI, to be transported at the time of session establishment. This information is essentially opaque data to SIP -- it is unrelated to SIP routing, authentication, or any other SIP function. This application can be considered to be operating at a higher layer on the protocol stack. As a result, SIP should not interpret, understand, or perform any operations on the UUI. Should this not be the case, then the information being transported is not considered UUI, and another SIP-specific mechanism will be needed to transport the information (such as a new header field). In particular, this mechanism creates no requirements on intermediaries such as proxies, Back-to-Back User Agents, and Session Border Controllers.
SIP UUIデータは、SIPを使用して確立されているセッションに関連するアプリケーション固有の情報として定義されます。アプリケーションは、2パーティセッションの両方のエンドポイントで実行されていると想定されています。つまり、アプリケーションはSIPセッションで両方のユーザーエージェントと対話します。アプリケーションが適切に機能するためには、セッションの確立時にアプリケーションがUUIという小さな情報を転送する必要があります。この情報は、SIPに対して本質的に不透明なデータです。SIPルーティング、認証、またはその他のSIP機能とは無関係です。このアプリケーションは、プロトコルスタックの上位層で動作していると見なすことができます。その結果、SIPはUUIの操作を解釈、理解、または実行してはなりません。そうでない場合、転送される情報はUUIとは見なされず、情報を転送するために別のSIP固有のメカニズム（新しいヘッダーフィールドなど）が必要になります。特に、このメカニズムは、プロキシ、バックツーバックユーザーエージェント、セッションボーダーコントローラーなどの仲介者に対する要件を作成しません。
UUI is defined this way for two reasons. First, this definition supports a strict layering of protocols and data. Providing information and understanding of the UUI to the transport layer (SIP in this case) would not provide any benefits and instead could create cross-layer coupling. Second, it is neither feasible nor desirable for a SIP User Agent (UA) to understand the information; instead, the goal is for the UA to simply pass the information as efficiently as possible to the application that does understand the information.
UUIがこのように定義されている理由は2つあります。まず、この定義は、プロトコルとデータの厳密な階層化をサポートしています。 UUIに関する情報と理解をトランスポート層（この場合はSIP）に提供しても、何の利点も得られず、クロスレイヤーカップリングが作成される可能性があります。第2に、SIPユーザーエージェント（UA）が情報を理解することは現実的でも望ましくもありません。代わりに、UAが情報を理解できるアプリケーションにできるだけ効率的に情報を渡すだけです。
An important application is the interworking with User-to-User Information (UUI) in ISDN, specifically the transport of the call-control-related ITU-T Q.931 User-to-User Information Element (UUIE) [Q931] and ITU-T Q.763 User-to-User Information Parameter [Q763] data in SIP. ISDN UUI is widely used in the Public Switched Telephone Network (PSTN) today in contact centers and call centers. These applications are currently transitioning away from using ISDN for session establishment to using SIP. Native SIP endpoints will need to implement a similar service and be able to interwork with this ISDN service.
重要なアプリケーションは、ISDNでのユーザー間情報（UUI）との相互作用、特に、呼制御関連のITU-T Q.931ユーザー間情報要素（UUIE）[Q931]とITUの転送です。 -T Q.763 SIPのユーザー間情報パラメーター[Q763]データ。 ISDN UUIは、今日のコンタクトセンターおよびコールセンターの公衆交換電話網（PSTN）で広く使用されています。これらのアプリケーションは現在、セッション確立にISDNを使用することからSIPを使用することに移行しています。ネイティブSIPエンドポイントは、同様のサービスを実装し、このISDNサービスと相互運用できる必要があります。
Note that the distinction between call control UUI and non-call-control UUI is very important. SIP already has a mechanism for sending arbitrary UUI data between UAs during a session or dialog -- the SIP INFO [RFC6086] method. Call control UUI, in contrast, must be exchanged at the time of setup and needs to be carried in the INVITE and a few other methods and responses. Applications that exchange UUI but do not have a requirement that it be transported and processed during call setup can simply use SIP INFO and do not need a new SIP extension.
通話制御UUIと非通話制御UUIの違いは非常に重要です。 SIPには、セッションまたはダイアログ中にUA間で任意のUUIデータを送信するメカニズム、つまりSIP INFO [RFC6086]メソッドがすでにあります。対照的に、コール制御UUIはセットアップ時に交換する必要があり、INVITEといくつかの他のメソッドおよび応答で伝送する必要があります。 UUIを交換するが、コールセットアップ中に転送および処理する必要がないアプリケーションは、単にSIP INFOを使用でき、新しいSIP拡張は必要ありません。
In this document, four different use case call flows are discussed. Next, the requirements for call control UUI transport are discussed.
このドキュメントでは、4つの異なるユースケースコールフローについて説明します。次に、呼制御UUIトランスポートの要件について説明します。
This section discusses four use cases for the transport of call control User-to-User Information. These use cases will help motivate the requirements for SIP call control UUI.
このセクションでは、呼制御のユーザー間情報の転送に関する4つの使用例について説明します。これらの使用例は、SIPコール制御UUIの要件を動機付けるのに役立ちます。
In this scenario, the originating UA includes UUI in the INVITE sent through a proxy to the terminating UA. The terminating UA can use the UUI in any way. If it is an ISDN gateway, it could map the UUI into the appropriate DSS1 [Q933] information element, QSIG [QSIG] information element, or ISDN User Part (ISUP) parameter. Alternatively, the using application might render the information to the user or use it during alerting or as a lookup for a screen pop. In this case, the proxy does not need to understand the UUI mechanism, but normal proxy rules should result in the UUI being forwarded without modification. This call flow is shown in Figure 1.
このシナリオでは、発信側UAは、プロキシを介して着信側UAに送信されるINVITEにUUIを含めます。終端UAは、どのような方法でもUUIを使用できます。 ISDNゲートウェイの場合、UUIを適切なDSS1 [Q933]情報要素、QSIG [QSIG]情報要素、またはISDNユーザーパーツ（ISUP）パラメーターにマップできます。あるいは、アプリケーションを使用して、情報をユーザーに表示したり、アラート中に、またはスクリーンポップのルックアップとして使用したりできます。この場合、プロキシはUUIメカニズムを理解する必要はありませんが、通常のプロキシルールにより、UUIが変更されずに転送されるはずです。このコールフローを図1に示します。
Originating UA Proxy Terminating UA
| | |
| INVITE (UUI) F1 | |
|------------------->| INVITE (UUI) F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
Figure 1: Call Flow with UUI Exchanged between Originating and Terminating UAs
図1：発信UAと着信UAの間でUUIが交換されたコールフロー
In this scenario, the originating UA includes UUI in the INVITE request sent through a proxy to the terminating UA. The proxy retargets the INVITE request, changing its Request-URI to a URI that addresses the terminating UA. The UUI data is then received and processed by the terminating UA. This call flow is identical to Figure 1 except that the proxy retargets the request, i.e., changes the Request-URI as directed by some unspecified process. The UUI in the INVITE request needs to be passed unchanged through this proxy retargeting operation. Note that the contents of the UUI is not used by the proxy for routing, as the UUI has only end-to-end significance between UAs.
このシナリオでは、発信側UAは、プロキシを介して着信側UAに送信されるINVITE要求にUUIを含めます。プロキシはINVITE要求を再ターゲットし、そのRequest-URIを、終了UAをアドレス指定するURIに変更します。次に、UUIデータが着信側UAによって受信および処理されます。このコールフローは図1と同じですが、プロキシがリクエストのターゲットを変更すること、つまり、指定されていないプロセスの指示に従ってRequest-URIを変更する点が異なります。 INVITEリクエストのUUIは、このプロキシの再ターゲット操作を通じて変更せずに渡す必要があります。 UUIにはUA間のエンドツーエンドの意味しかないので、UUIの内容はプロキシによってルーティングに使用されないことに注意してください。
In this scenario, UUI is inserted by an application that utilizes a SIP Redirect Server. The UUI is then included in the INVITE request sent by the originating UA to the terminating UA. In this case, the originating UA does not necessarily need to support the UUI mechanism but does need to support the SIP redirection mechanism used to include the UUI data. Two examples of UUI with redirection (transfer and diversion) are defined in [ANSI] and [ETSI].
このシナリオでは、SIPリダイレクトサーバーを利用するアプリケーションによってUUIが挿入されます。次に、UUIは、発信側UAから着信側UAに送信されるINVITE要求に含まれます。この場合、元のUAは必ずしもUUIメカニズムをサポートする必要はありませんが、UUIデータを含めるために使用されるSIPリダイレクションメカニズムをサポートする必要があります。リダイレクトを伴うUUIの2つの例（転送と転送）は、[ANSI]と[ETSI]で定義されています。
Note that this case may not precisely map to an equivalent ISDN service use case. This is because there is no one-to-one mapping between elements in a SIP network and elements in an ISDN network. Also, there is not an exact one-to-one mapping between SIP call control and ISDN call control. However, this should not prevent the usage of SIP call control UUI in these cases. Instead, these slight differences between the SIP UUI mechanism and the ISDN service need to be carefully noted and discussed in an interworking specification.
このケースは、同等のISDNサービスのユースケースに正確に対応しない場合があることに注意してください。これは、SIPネットワークの要素とISDNネットワークの要素の間に1対1のマッピングがないためです。また、SIP呼制御とISDN呼制御の間には厳密な1対1のマッピングはありません。ただし、これにより、これらの場合にSIPコール制御UUIの使用が妨げられることはありません。代わりに、SIP UUIメカニズムとISDNサービスの間のこれらのわずかな違いは、注意深く記述し、インターワーキング仕様で説明する必要があります。
Figure 2 shows this scenario, with the Redirect Server inserting UUI that is then included in the INVITE request F4 sent to the terminating UA.
図2はこのシナリオを示しており、リダイレクトサーバーがUUIを挿入します。このUUIは、終端のUAに送信されるINVITE要求F4に含まれます。
Originating UA Redirect Server Terminating UA
| | |
| INVITE F1 | |
|------------------->| |
| 302 Moved (UUI) F2 | |
|<-------------------| |
| ACK F3 | |
|------------------->| |
| INVITE (UUI) F4 | |
|---------------------------------------->|
| 200 OK F5 |
|<----------------------------------------|
| ACK F6 |
|---------------------------------------->|
Figure 2: Call Flow with UUI Exchanged between Redirect Server and Terminating UA
図2：リダイレクトサーバーと終端UAの間でUUIが交換されたコールフロー
A common example application of this call flow is an Automatic Call Distributer (ACD) in a PSTN contact center. The originator would be a PSTN gateway. The ACD would act as a Redirect Server, inserting UUI based on called number, calling number, time of day, and other information. The resulting UUI would be passed to the agent's handset which acts as the terminating UA. The UUI could be used to lookup information for rendering to the agent at the time of call answering.
このコールフローの一般的なアプリケーション例は、PSTNコンタクトセンターの自動コールディストリビューター（ACD）です。発信者はPSTNゲートウェイです。 ACDはリダイレクトサーバーとして機能し、着信番号、発信番号、時刻、その他の情報に基づいてUUIを挿入します。結果のUUIは、終了UAとして機能するエージェントのハンドセットに渡されます。 UUIは、通話応答時にエージェントにレンダリングするための情報を検索するために使用できます。
This redirection scenario and the referral scenario in the next section are the most important scenarios for contact center applications. Incoming calls to a contact center almost always are redirected or referred to a final destination, sometimes multiple times, based on collected information and business logic. The ability to pass along UUI in these call redirection scenarios is critical.
このリダイレクトシナリオと次のセクションの紹介シナリオは、コンタクトセンターアプリケーションの最も重要なシナリオです。コンタクトセンターへの着信は、ほとんどの場合、収集された情報とビジネスロジックに基づいて、最終的に宛先にリダイレクトまたは参照されます。これらのコールリダイレクションシナリオでUUIを渡す機能は重要です。
In this scenario, the application uses a UA to initiate a referral, which causes an INVITE request to be generated between the originating UA and terminating UA with UUI data inserted by the referrer UA. Note that this REFER method [RFC3515] could be part of a transfer operation, or it might be unrelated to an existing call, such as out-of-dialog REFER request. In some cases, this call flow is used in place of the redirection call flow: the referrer immediately answers the call and then sends the REFER request. This scenario is shown in Figure 3.
このシナリオでは、アプリケーションはUAを使用して紹介を開始します。これにより、参照元UAによって挿入されたUUIデータを使用して、元のUAと終了UAの間にINVITE要求が生成されます。このREFERメソッド[RFC3515]は転送操作の一部である可能性があるか、ダイアログ外のREFER要求などの既存の呼び出しとは無関係である可能性があることに注意してください。場合によっては、このコールフローがリダイレクトコールフローの代わりに使用されます。リファラーはすぐにコールに応答してから、REFER要求を送信します。このシナリオを図3に示します。
Originating UA Referrer Terminating UA
| | |
| REFER (UUI) F1 | |
|<-------------------| |
| 202 Accepted F2 | |
|------------------->| |
| INVITE (UUI) F3 | |
|---------------------------------------->|
| NOTIFY (100 Trying) F4 |
|------------------->| |
| 200 OK F5 | |
|<-------------------| |
| 200 OK F6 |
|<----------------------------------------|
| ACK F7 |
|---------------------------------------->|
| NOTIFY (200 OK) F8 | |
|------------------->| |
| 200 OK F9 | |
|<-------------------| |
Figure 3: Call Flow with Referral and UUI
図3：紹介とUUIを使用したコールフロー
This section states the requirements for the transport of call control User-to-User Information (UUI).
このセクションでは、呼制御のユーザー間情報（UUI）のトランスポートの要件について説明します。
REQ-1: The mechanism will allow UAs to insert and receive UUI data in SIP call setup requests and responses.
REQ-1：このメカニズムにより、UAはSIPコールセットアップ要求および応答でUUIデータを挿入および受信できます。
SIP messages covered by this include INVITE requests and end-to-end responses to the INVITE, i.e., 18x and 200 responses. UUI data may also be inserted in 3xx responses to an INVITE. However, if a 3xx response is recursed on by an intermediary proxy, the resulting INVITE will not contain the UUI data from the 3xx response. In a scenario where a proxy forks an INVITE to multiple UAS who include UUI data in 3xx responses, if a 3xx response is the best response sent upstream by the proxy, it will contain the UUI data from only one 3xx response.
これでカバーされるSIPメッセージには、INVITEリクエストと、INVITEへのエンドツーエンドレスポンス、つまり18xおよび200レスポンスが含まれます。 UUIデータは、INVITEへの3xx応答にも挿入できます。ただし、3xx応答が中間プロキシによって再帰される場合、結果のINVITEには3xx応答からのUUIデータが含まれません。プロキシが3xx応答にUUIデータを含む複数のUASへのINVITEをフォークするシナリオで、3xx応答がプロキシによってアップストリームに送信される最良の応答である場合、1xxのみからのUUIデータが含まれます。
REQ-2: The mechanism will allow UAs to insert and receive UUI data in SIP dialog terminating requests and responses.
REQ-2：このメカニズムにより、UAはSIPダイアログでリクエストと応答を終了するUUIデータを挿入および受信できます。
Q.931 UUI supports inclusion in release and release completion messages. SIP messages covered by this include BYE and 200 OK responses to a BYE.
Q.931 UUIは、リリースへの組み込みおよびリリース完了メッセージをサポートしています。これでカバーされるSIPメッセージには、BYEとBYEに対する200 OK応答が含まれます。
REQ-3: The mechanism will allow UUI to be inserted and retrieved in SIP redirects and referrals.
REQ-3：このメカニズムにより、UUIをSIPリダイレクトおよび紹介に挿入および取得できます。
SIP messages covered by this include REFER requests and 3xx responses to INVITE requests.
これでカバーされるSIPメッセージには、REFER要求とINVITE要求に対する3xx応答が含まれます。
REQ-4: The mechanism will allow UUI to be able to survive proxy retargeting or redirection of the request.
REQ-4：このメカニズムにより、UUIはリクエストのプロキシリターゲティングまたはリダイレクトに耐えることができます。
Retargeting is a common method of call routing in SIP and must not result in the loss of User-to-User Information.
リターゲッティングはSIPでのコールルーティングの一般的な方法であり、ユーザー間の情報が失われることがあってはなりません。
REQ-5: The mechanism should not require processing entities to dereference a URL in order to retrieve the UUI data.
REQ-5：このメカニズムでは、UUIデータを取得するために、処理エンティティがURLを逆参照する必要はありません。
Passing a pointer or link to the UUI data will not meet the real-time processing considerations and would complicate interworking with the PSTN.
UUIデータへのポインターまたはリンクを渡すと、リアルタイム処理の考慮事項が満たされず、PSTNとのインターワーキングが複雑になります。
REQ-6: The mechanism will support interworking with call-control-related DSS1 information elements or QSIG information elements and ISUP parameters.
REQ-6：このメカニズムは、呼制御関連のDSS1情報要素またはQSIG情報要素およびISUPパラメータとの相互作用をサポートします。
REQ-7: The mechanism will allow a UAC to learn that a UAS understands the UUI mechanism.
REQ-7：このメカニズムにより、UACはUASがUUIメカニズムを理解していることを知ることができます。
REQ-8: The mechanism will allow a UAC to require that a UAS understands the call control UUI mechanism and have a request routed based on this information. If the request cannot be routed to a UAS that understands the UUI mechanism, the request will fail.
REQ-8：このメカニズムにより、UACは、UASが呼制御UUIメカニズムを理解し、この情報に基づいて要求をルーティングすることを要求できます。 UUIメカニズムを理解するUASに要求をルーティングできない場合、要求は失敗します。
This could be useful in ensuring that a request destined for the PSTN is routed to a gateway that supports the UUI mechanism rather than an otherwise equivalent PSTN gateway that does not support the ISDN mechanism. Note that support of the UUI mechanism does not, by itself, imply that a particular application is supported (see REQ-10).
これは、PSTN宛ての要求が、ISDNメカニズムをサポートしない同等のPSTNゲートウェイではなく、UUIメカニズムをサポートするゲートウェイにルーティングされるようにするのに役立ちます。 UUIメカニズムのサポート自体は、特定のアプリケーションがサポートされていることを意味するわけではないことに注意してください（REQ-10を参照）。
REQ-9: The mechanism will allow proxies to remove a particular application usage of UUI data from a request or response.
REQ-9：このメカニズムにより、プロキシはUUIデータの特定のアプリケーション使用を要求または応答から削除できます。
This is a common security function provided by border elements to header fields such as Alert-Info or Call-Info URIs. There is no requirement for UAs to be able to determine if a particular usage of UUI data has been removed from a request or response.
これは、境界要素がAlert-InfoやCall-Info URIなどのヘッダーフィールドに提供する一般的なセキュリティ機能です。 UAが要求または応答からUUIデータの特定の使用法が削除されたかどうかを判断できる必要はありません。
REQ-10: The mechanism will provide the ability for a UA to discover which application usages of UUI another UA understands or supports.
REQ-10：このメカニズムは、UAが別のUAが理解またはサポートしているUUIのアプリケーション使用を検出する機能を提供します。
The creation of a registry of application usages for the UUI mechanism is implied by this requirement. The ISDN service utilizes a field known as the protocol discriminator, which is the first octet of the ISDN UUI data, for this purpose.
UUIメカニズムのアプリケーション使用状況のレジストリの作成は、この要件によって暗示されます。 ISDNサービスは、この目的のために、ISDN UUIデータの最初のオクテットであるプロトコル識別子と呼ばれるフィールドを利用します。
REQ-11: The UUI is a sequence of octets. The solution will provide a mechanism of transporting at least 128 octets of user data and a one-octet protocol discriminator, i.e., 129 octets in total.
REQ-11：UUIはオクテットのシーケンスです。このソリューションは、少なくとも128オクテットのユーザーデータと1オクテットのプロトコル識別子、つまり合計129オクテットを転送するメカニズムを提供します。
There is the potential for non-ISDN services to allow UUI to be larger than 128 octets. However, users of the mechanism will need be cognizant of the size of SIP messages and the ability of parsers to handle extremely large values.
ISDN以外のサービスでは、UUIを128オクテットより大きくできる可能性があります。ただし、このメカニズムのユーザーは、SIPメッセージのサイズと、非常に大きな値を処理するパーサーの機能を認識する必要があります。
REQ-12: The recipient of UUI will be able to determine the entity that inserted the UUI. It is acceptable that this is performed implicitly where it is known that there is only one other end UA involved in the dialog. Where that does not exist, some other mechanism will need to be provided. The UUI mechanism does not introduce stronger authorization requirements for SIP; instead, the mechanism needs to be able to utilize existing SIP approaches for request and response identity.
REQ-12：UUIの受信者は、UUIを挿入したエンティティを判別できます。これは、ダイアログに関与している他のエンドUAが1つだけであることがわかっている場合に暗黙的に実行されることは許容されます。それが存在しない場合は、他のメカニズムを提供する必要があります。 UUIメカニズムでは、SIPに対するより強力な承認要件は導入されていません。代わりに、メカニズムは既存のSIPアプローチを要求と応答のIDに利用できる必要があります。
This requirement comes into play during redirection, retargeting, and referral scenarios.
この要件は、リダイレクト、再ターゲット、および紹介シナリオで有効になります。
The security requirements for the UUI mechanism are described in this section. It is important to note that UUI security is jointly provided at the application layer and at the SIP layer. As such, is important for application users of the UUI mechanism to know the level of security used and deployed in their particular SIP environments and not to assume that a standardized (but perhaps rarely deployed) security mechanism is in place.
このセクションでは、UUIメカニズムのセキュリティ要件について説明します。 UUIセキュリティは、アプリケーション層とSIP層で共同で提供されることに注意することが重要です。そのため、UUIメカニズムのアプリケーションユーザーは、特定のSIP環境で使用および展開されているセキュリティのレベルを把握し、標準化された（ただし、ほとんど展開されていない）セキュリティメカニズムが導入されていると想定しないことが重要です。
There are three main security models that need to be addressed by the UUI mechanism. One model treats the SIP layer as untrusted and requires end-to-end integrity protection and/or encryption. This model can be achieved by providing these security services at a layer above SIP. In this case, the application integrity protects and/or encrypts the UUI data before passing it to the SIP layer. This method has two advantages: it does not assume or rely on end-to-end security mechanisms in SIP, which have virtually no deployment, and it allows an application that understands the contents of the UUI to apply a proper level of security.
UUIメカニズムで対処する必要のある主なセキュリティモデルは3つあります。 1つのモデルはSIP層を信頼できないものとして扱い、エンドツーエンドの整合性保護や暗号化を必要とします。このモデルは、SIPの上のレイヤーでこれらのセキュリティサービスを提供することで実現できます。この場合、アプリケーションの整合性は、UUIデータをSIP層に渡す前に保護または暗号化します。この方法には2つの利点があります。SIPのエンドツーエンドのセキュリティメカニズムを想定しておらず、実質的に展開されていないため、UUIの内容を理解するアプリケーションが適切なレベルのセキュリティを適用できます。
The second approach is for the application to pass the UUI without any protection to the SIP layer and require the SIP layer to provide this security. This approach is possible in theory, although its practical use would be extremely limited.
2番目の方法は、アプリケーションがSIP層を保護せずにUUIを渡し、SIP層がこのセキュリティを提供することを要求することです。このアプローチは理論的には可能ですが、実際の使用は非常に限られています。
The third model utilizes a trust domain and relies on perimeter security at the SIP layer. This is the security model of the PSTN and ISDN where UUI is commonly used today. This approach uses hop-by-hop security mechanisms and relies on border elements for filtering and application of policy. This approach is used today in UUI deployments. Within this approach, there is a requirement that intermediary elements can detect and remove a UUI element based on policy, but there is no requirement that an intermediary element be able to read or interpret the UUI (as the UUI contents only have end-to-end significance).
3番目のモデルは、信頼ドメインを利用し、SIPレイヤーの境界セキュリティに依存しています。これは、現在UUIが一般的に使用されているPSTNおよびISDNのセキュリティモデルです。このアプローチは、ホップバイホップのセキュリティメカニズムを使用し、ポリシーのフィルタリングと適用を境界要素に依存しています。このアプローチは、UUI展開で現在使用されています。このアプローチでは、中間要素がポリシーに基づいてUUI要素を検出および削除できるという要件がありますが、中間要素がUUIを読み取ったり解釈したりできるという要件はありません（UUIコンテンツにはエンドツーエンドのみがあるため）最終的な意味）。
The next three requirements capture the UUI security requirements.
次の3つの要件は、UUIのセキュリティ要件を示しています。
REQ-13: The mechanism will allow integrity protection of the UUI.
REQ-13：このメカニズムにより、UUIの整合性保護が可能になります。
This allows the UAS to be able to know that the UUI has not been modified or tampered with by intermediaries. Note that there are tradeoffs between this requirement and requirement REQ-9 for proxies and border elements to remove UUI. One possible way to satisfy both of these requirements is to utilize hop-by-hop protection. This property is not guaranteed by the protocol in the ISDN application.
これにより、UASは、UUIが変更されていないか、仲介者によって改ざんされていないことを認識できます。この要件と要件REQ-9の間には、UUIを削除するためのプロキシと境界要素のトレードオフがあることに注意してください。これらの両方の要件を満たす1つの可能な方法は、ホップバイホップ保護を利用することです。このプロパティは、ISDNアプリケーションのプロトコルでは保証されていません。
REQ-14: The mechanism will allow end-to-end privacy of the UUI.
REQ-14：このメカニズムは、UUIのエンドツーエンドのプライバシーを許可します。
Some UUI may contain private or sensitive information and may require different security handling from the rest of the SIP message. Note that this property is not available in the ISDN application.
一部のUUIには、個人情報または機密情報が含まれている場合があり、残りのSIPメッセージとは異なるセキュリティ処理が必要になる場合があります。このプロパティはISDNアプリケーションでは使用できないことに注意してください。
REQ-15: The mechanism will allow both end-to-end and hop-by-hop security models.
REQ-15：このメカニズムは、エンドツーエンドとホップバイホップの両方のセキュリティモデルを許可します。
The hop-by-hop model is required by the ISDN UUI service.
ISDN UUIサービスには、ホップバイホップモデルが必要です。
Thanks to Joanne McMillen, who was a co-author of earlier draft versions of this specification. Thanks to Spencer Dawkins, Keith Drage, Dale Worley, and Vijay Gurbani for their review of earlier draft versions of this document. The authors wish to thank Christer Holmberg, Frederique Forestie, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for their comments on this topic.
この仕様の以前のドラフトバージョンの共著者であったJoanne McMillenに感謝します。このドキュメントの以前のドラフトバージョンをレビューしてくれたSpencer Dawkins、Keith Drage、Dale Worley、Vijay Gurbaniに感謝します。このトピックに関するコメントを提供してくれたChrister Holmberg、Frederique Forestie、Francois Audet、Denis Alexeitsev、Paul Kyzivat、Cullen Jennings、およびMahalingam Maniに感謝します。
[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 Initiation Protocol」 、RFC 3261、2002年6月。
[Q931] ITU-T, "ISDN user-network interface layer 3 specification for basic call control", ITU-T Recommendation Q.931, <http://www.itu.int/rec/T-REC-Q.931-199805-I/en>.
[Q931] ITU-T、「ISDN user-network interface layer 3 specification for basic call control」、ITU-T Recommendation Q.931、<http://www.itu.int/rec/T-REC-Q.931 -199805-I / en>。
[Q763] ITU-T, "Signalling System No. 7 - ISDN User Part formats and codes", ITU-T Recommendation Q.763, <http://www.itu.int/rec/T-REC-Q.763-199912-I/en>.
[Q763] ITU-T、「Signalling System No. 7-ISDN User Part format and codes」、ITU-T Recommendation Q.763、<http://www.itu.int/rec/T-REC-Q.763 -199912-I / en>。
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, January 2011.
[RFC6086] Holmberg、C.、Berger、E。、およびH. Kaplan、「Session Initiation Protocol（SIP）INFO Method and Package Framework」、RFC 6086、2011年1月。
[Q933] ITU-T, "ISDN Digital Subscriber Signalling System No. 1 (DSS1) - Signalling specifications for frame mode switched and permanent virtual connection control and status monitoring", ITU-T Recommendation Q.933, <http://www.itu.int/rec/T-REC-Q.933/en>.
[Q933] ITU-T、「ISDN Digital Subscriber Signaling System No. 1（DSS1）-Signaling Specifications for Frame Mode Switched and Permanent Virtual Connection Control and Status Monitoring」、ITU-T Recommendation Q.933、<http：// www .itu.int / rec / T-REC-Q.933 / en>。
[QSIG] ECMA, "Private Integrated Services Network (PISN) - Circuit Mode Bearer Services - Inter-Exchange Signalling Procedures and Protocol (QSIG-BC)", Standard ECMA-143, December 2001.
[QSIG] ECMA、「Private Integrated Services Network（PISN）-Circuit Mode Bearer Services-Inter-Exchange Signaling Procedures and Protocol（QSIG-BC）」、Standard ECMA-143、2001年12月。
[ANSI] ANSI, "Telecommunications-Integrated Services Digital Network (ISDN)-Explicit Call Transfer Supplementary Service", ANSI T1.643-1995.
[ANSI] ANSI、「Telecommunications-Integrated Services Digital Network（ISDN）-Explicit Call Transfer Supplementary Service」、ANSI T1.643-1995。
[ETSI] ETSI, "Integrated Services Digital Network (ISDN); Diversion supplementary services", ETSI ETS 300 207-1, Ed. 1, 1994.
[ETSI] ETSI、「統合サービスデジタルネットワーク（ISDN）;迂回補足サービス」、ETSI ETS 300 207-1、エド。 1、1994。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「Session Initiation Protocol（SIP）Refer Method」、RFC 3515、2003年4月。
Authors' Addresses
著者のアドレス
Alan Johnston Avaya St. Louis, MO 63124
あぁん じょｈんｓとん あゔぁや Ｓｔ。 ぉういｓ、 も ６３１２４
EMail: alan.b.johnston@gmail.com
Laura Liess Deutsche Telekom AG
Laura Liess Deutsche Telekom AG
EMail: laura.liess.dt@gmail.com