[要約] 要約：RFC 4313は、自動音声認識（ASR）、話者識別/話者検証（SI/SV）、テキスト読み上げ（TTS）のリソースの分散制御に関する要件を定義しています。目的：このRFCの目的は、ASR、SI/SV、TTSのリソースを効果的に分散制御するための要件を提供することです。
Network Working Group D. Oran
Request for Comments: 4313 Cisco Systems, Inc.
Category: Informational December 2005
Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources
自動音声認識（ASR）、スピーカー識別/スピーカー検証（SI/SV）、およびテキストツースピーチ（TTS）リソースの分散制御の要件
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS). Other IETF protocols, such as SIP and Real Time Streaming Protocol (RTSP), address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address.
このドキュメントでは、オーディオストリームの分散音声処理を制御するためのプロトコルのニーズと要件の概要を説明しています。音声処理により、このドキュメントは、特に自動音声認識（ASR）、スピーカーの認識（スピーカー識別（SI）とスピーカー検証（SV）の両方を含むスピーカー認識）、およびテキストツースピーチ（TTS）を意味します。SIPやリアルタイムストリーミングプロトコル（RTSP）などのその他のIETFプロトコルは、一般化されたメディアストリームのRendezvousとコントロールに対処します。ただし、音声処理には、現存するIETFプロトコルがいずれもアドレスしていない追加の要件が示されています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Document Conventions .......................................3
2. SPEECHSC Framework ..............................................4
2.1. TTS Example ................................................5
2.2. Automatic Speech Recognition Example .......................6
2.3. Speaker Identification example .............................6
3. General Requirements ............................................7
3.1. Reuse Existing Protocols ...................................7
3.2. Maintain Existing Protocol Integrity .......................7
3.3. Avoid Duplicating Existing Protocols .......................7
3.4. Efficiency .................................................8
3.5. Invocation of Services .....................................8
3.6. Location and Load Balancing ................................8
3.7. Multiple Services ..........................................8
3.8. Multiple Media Sessions ....................................8
3.9. Users with Disabilities ....................................9
3.10. Identification of Process That Produced Media or
Control Output ............................................9
4. TTS Requirements ................................................9
4.1. Requesting Text Playback ...................................9
4.2. Text Formats ...............................................9
4.2.1. Plain Text ..........................................9
4.2.2. SSML ................................................9
4.2.3. Text in Control Channel ............................10
4.2.4. Document Type Indication ...........................10
4.3. Control Channel ...........................................10
4.4. Media Origination/Termination by Control Elements .........10
4.5. Playback Controls .........................................10
4.6. Session Parameters ........................................11
4.7. Speech Markers ............................................11
5. ASR Requirements ...............................................11
5.1. Requesting Automatic Speech Recognition ...................11
5.2. XML .......................................................11
5.3. Grammar Requirements ......................................12
5.3.1. Grammar Specification ..............................12
5.3.2. Explicit Indication of Grammar Format ..............12
5.3.3. Grammar Sharing ....................................12
5.4. Session Parameters ........................................12
5.5. Input Capture .............................................12
6. Speaker Identification and Verification Requirements ...........13
6.1. Requesting SI/SV ..........................................13
6.2. Identifiers for SI/SV .....................................13
6.3. State for Multiple Utterances .............................13
6.4. Input Capture .............................................13
6.5. SI/SV Functional Extensibility ............................13
7. Duplexing and Parallel Operation Requirements ..................13
7.1. Full Duplex Operation .....................................14
7.2. Multiple Services in Parallel .............................14
7.3. Combination of Services ...................................14
8. Additional Considerations (Non-Normative) ......................14
9. Security Considerations ........................................15
9.1. SPEECHSC Protocol Security ................................15
9.2. Client and Server Implementation and Deployment ...........16
9.3. Use of SPEECHSC for Security Functions ....................16
10. Acknowledgements ..............................................17
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................18
There are multiple IETF protocols for establishment and termination of media sessions (SIP [6]), low-level media control (Media Gateway Control Protocol (MGCP) [7] and Media Gateway Controller (MEGACO) [8]), and media record and playback (RTSP [9]). This document focuses on requirements for one or more protocols to support the control of network elements that perform Automated Speech Recognition (ASR), speaker identification or verification (SI/SV), and rendering text into audio, also known as Text-to-Speech (TTS). Many multimedia applications can benefit from having automatic speech recognition (ASR) and text-to-speech (TTS) processing available as a distributed, network resource. This requirements document limits its focus to the distributed control of ASR, SI/SV, and TTS servers.
メディアセッション（SIP [6]）、低レベルのメディアコントロール（メディアゲートウェイコントロールプロトコル（MGCP）[7]およびメディアゲートウェイコントローラー（Megaco）[8]）、およびメディアレコードの確立と終了のための複数のIETFプロトコルがあります。および再生（RTSP [9]）。このドキュメントでは、自動化された音声認識（ASR）、スピーカーの識別または検証（SI/SV）を実行するネットワーク要素の制御をサポートする1つ以上のプロトコルの要件に焦点を当てています。（TTS）。多くのマルチメディアアプリケーションは、分散型ネットワークリソースとして利用可能な自動音声認識（ASR）とテキストからスピーチ（TTS）処理を行うことから利益を得ることができます。この要件は、ASR、SI/SV、およびTTSサーバーの分散制御に焦点を制限しています。
There is a broad range of systems that can benefit from a unified approach to control of TTS, ASR, and SI/SV. These include environments such as Voice over IP (VoIP) gateways to the Public Switched Telephone Network (PSTN), IP telephones, media servers, and wireless mobile devices that obtain speech services via servers on the network.
TTS、ASR、およびSI/SVの制御への統一アプローチから恩恵を受けることができる幅広いシステムがあります。これらには、ネットワーク上のサーバーを介してスピーチサービスを取得する公開された電話ネットワーク（PSTN）、IP電話、メディアサーバー、ワイヤレスモバイルデバイスへのVoice Over IP（VoIP）ゲートウェイなどの環境が含まれます。
To date, there are a number of proprietary ASR and TTS APIs, as well as two IETF documents that address this problem [13], [14]. However, there are serious deficiencies to the existing documents. In particular, they mix the semantics of existing protocols yet are close enough to other protocols as to be confusing to the implementer.
現在までに、この問題に対処する2つのIETFドキュメントと同様に、多くの独自のASRおよびTTS APIがあります[13]、[14]があります。ただし、既存のドキュメントには重大な欠陥があります。特に、既存のプロトコルのセマンティクスを組み合わせていますが、実装者と混同するほど他のプロトコルに十分近いです。
This document sets forth requirements for protocols to support distributed speech processing of audio streams. For simplicity, and to remove confusion with existing protocol proposals, this document presents the requirements as being for a "framework" that addresses the distributed control of speech resources. It refers to such a framework as "SPEECHSC", for Speech Services Control.
このドキュメントは、オーディオストリームの分散音声処理をサポートするためのプロトコルの要件を示しています。簡単にし、既存のプロトコル提案との混乱を取り除くために、このドキュメントは、音声リソースの分散制御に対処する「フレームワーク」の要件を提示します。このようなフレームワークは、「SpeechSC」など、音声サービス制御のためです。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3].
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "RFC 2119 [3]に記載されているように解釈されるべきです。
Figure 1 below shows the SPEECHSC framework for speech processing.
以下の図1は、音声処理の音声フレームワークを示しています。
+-------------+
| Application |
| Server |\
+-------------+ \ SPEECHSC
SIP, VoiceXML, / \
etc. / \
+------------+ / \ +-------------+
| Media |/ SPEECHSC \---| ASR, SI/SV, |
| Processing |-------------------------| and/or TTS |
RTP | Entity | RTP | Server |
=====| |=========================| |
+------------+ +-------------+
Figure 1: SPEECHSC Framework
図1：SpeechSCフレームワーク
The "Media Processing Entity" is a network element that processes media. It may be a pure media handler, or it may also have an associated SIP user agent, VoiceXML browser, or other control entity. The "ASR, SI/SV, and/or TTS Server" is a network element that performs the back-end speech processing. It may generate an RTP stream as output based on text input (TTS) or return recognition results in response to an RTP stream as input (ASR, SI/SV). The "Application Server" is a network element that instructs the Media Processing Entity on what transformations to make to the media stream. Those instructions may be established via a session protocol such as SIP, or provided via a client/server exchange such as VoiceXML. The framework allows either the Media Processing Entity or the Application Server to control the ASR or TTS Server using SPEECHSC as a control protocol, which accounts for the SPEECHSC protocol appearing twice in the diagram.
「メディア処理エンティティ」は、メディアを処理するネットワーク要素です。純粋なメディアハンドラーである場合もあれば、関連するSIPユーザーエージェント、VoiceXMLブラウザー、またはその他の制御エンティティもある場合があります。「ASR、SI/SV、および/またはTTSサーバー」は、バックエンドの音声処理を実行するネットワーク要素です。入力としてのRTPストリーム（ASR、SI/SV）に応じて、テキスト入力（TTS）に基づいて出力として出力としてRTPストリームを生成する場合があります。「アプリケーションサーバー」は、メディアストリームにどのような変換を行うかについて、メディア処理エンティティに指示するネットワーク要素です。これらの命令は、SIPなどのセッションプロトコルを介して確立されるか、VoiceXMLなどのクライアント/サーバー交換を介して提供される場合があります。このフレームワークにより、メディア処理エンティティまたはアプリケーションサーバーのいずれかが、SpeechSCを制御プロトコルとして使用してASRまたはTTSサーバーを制御できます。これは、図に2回表示されるSpeekSCプロトコルを説明します。
Physical embodiments of the entities can reside in one physical instance per entity, or some combination of entities. For example, a VoiceXML [11] gateway may combine the ASR and TTS functions on the same platform as the Media Processing Entity. Note that VoiceXML gateways themselves are outside the scope of this protocol. Likewise, one can combine the Application Server and Media Processing Entity, as would be the case in an interactive voice response (IVR) platform.
エンティティの物理的実施形態は、エンティティごとに1つの物理的インスタンス、またはエンティティの何らかの組み合わせに存在する可能性があります。たとえば、VoiceXML [11] Gatewayは、メディア処理エンティティと同じプラットフォーム上のASRおよびTTS関数を組み合わせる場合があります。VoiceXMLゲートウェイ自体は、このプロトコルの範囲外であることに注意してください。同様に、Interactive Voice Response（IVR）プラットフォームの場合と同様に、アプリケーションサーバーとメディア処理エンティティを組み合わせることができます。
One can also decompose the Media Processing Entity into an entity that controls media endpoints and entities that process media directly. Such would be the case with a decomposed gateway using MGCP or MEGACO. However, this decomposition is again orthogonal to the scope of SPEECHSC. The following subsections provide a number of example use cases of the SPEECHSC, one each for TTS, ASR, and SI/SV. They are intended to be illustrative only, and not to imply any restriction on the scope of the framework or to limit the decomposition or configuration to that shown in the example.
メディア処理エンティティを、メディアのエンドポイントとメディアを直接処理するエンティティを制御するエンティティに分解することもできます。MGCPまたはMegacoを使用した分解されたゲートウェイの場合はそうです。ただし、この分解は再びSpeechSCの範囲に直交します。以下のサブセクションは、TTS、ASR、およびSI/SV用のそれぞれ1つのSpeechSCのユースケースの多くの例を提供します。それらは実例のみを目的としており、フレームワークの範囲の制限を暗示したり、分解または構成を例に示すものに制限することを意図していません。
This example illustrates a simple usage of SPEECHSC to provide a Text-to-Speech service for playing announcements to a user on a phone with no display for textual error messages. The example scenario is shown below in Figure 2. In the figure, the VoIP gateway acts as both the Media Processing Entity and the Application Server of the SPEECHSC framework in Figure 1.
この例は、Textualエラーメッセージの表示がない電話でユーザーにアナウンスをプレイするためのテキストからスピーチサービスを提供するためのSpeechSCの単純な使用法を示しています。例のシナリオを図2に示します。図では、VoIPゲートウェイは、図1のSpeechSCフレームワークのメディア処理エンティティとApplication Serverの両方として機能します。
+---------+
_| SIP |
_/ | Server |
+-----------+ SIP/ +---------+
| | _/
+-------+ | VoIP |_/
| POTS |___| Gateway | RTP +---------+
| Phone | | (SIP UA) |=========| |
+-------+ | |\_ | SPEECHSC|
+-----------+ \ | TTS |
\__ | Server |
SPEECHSC | |
\_| |
+---------+
Figure 2: Text-to-Speech Example of SPEECHSC
図2：Speechscのテキストからスピーチの例
The Plain Old Telephone Service (POTS) phone on the left attempts to make a phone call. The VoIP gateway, acting as a SIP UA, tries to establish a SIP session to complete the call, but gets an error, such as a SIP "486 Busy Here" response. Without SPEECHSC, the gateway would most likely just output a busy signal to the POTS phone. However, with SPEECHSC access to a TTS server, it can provide a spoken error message. The VoIP gateway therefore constructs a text error string using information from the SIP messages, such as "Your call to 978-555-1212 did not go through because the called party was busy". It then can use SPEECHSC to establish an association with a SPEECHSC server, open an RTP stream between itself and the server, and issue a TTS request for the error message, which will be played to the user on the POTS phone.
左側のプレーンな古い電話サービス（POTS）電話は、電話をかけようとします。SIP UAとして機能するVoIP Gatewayは、SIPセッションを確立してコールを完了しようとしますが、SIP「486 Busy」応答などのエラーが発生します。SpeechSCがなければ、ゲートウェイはおそらくPOTS電話にビジー信号を出力するだけです。ただし、TTSサーバーへのSpeechSCアクセスを使用すると、音声エラーメッセージを提供できます。したがって、VoIPゲートウェイは、「978-555-1212への呼び出しは、呼ばれたパーティーが忙しかったため、通過しなかった」など、SIPメッセージからの情報を使用してテキストエラー文字列を構築します。その後、SpeechSCを使用してSpeechSCサーバーとの関連を確立し、それ自体とサーバーの間にRTPストリームを開き、ポット電話でユーザーに再生されるエラーメッセージのTTSリクエストを発行できます。
This example illustrates a VXML-enabled media processing entity and associated application server using the SPEECHSC framework to supply an ASR-based user interface through an Interactive Voice Response (IVR) system. The example scenario is shown below in Figure 3. The VXML-client corresponds to the "media processing entity", while the IVR application server corresponds to the "application server" of the SPEECHSC framework of Figure 1.
この例は、SpeekSCフレームワークを使用してVXML対応メディア処理エンティティと関連するアプリケーションサーバーを、インタラクティブな音声応答（IVR）システムを介してASRベースのユーザーインターフェイスを提供することを示しています。例のシナリオを図3に示します。VXML-Clientは「メディア処理エンティティ」に対応し、IVRアプリケーションサーバーは図1のSpeechSCフレームワークの「アプリケーションサーバー」に対応します。
+------------+
| IVR |
_|Application |
VXML_/ +------------+
+-----------+ __/
| |_/ +------------+
PSTN Trunk | VoIP | SPEECHSC| |
=============| Gateway |---------| SPEECHSC |
|(VXML voice| | ASR |
| browser) |=========| Server |
+-----------+ RTP +------------+
Figure 3: Automatic Speech Recognition Example
図3：自動音声認識の例
In this example, users call into the service in order to obtain stock quotes. The VoIP gateway answers their PSTN call. An IVR application feeds VXML scripts to the gateway to drive the user interaction. The VXML interpreter on the gateway directs the user's media stream to the SPEECHSC ASR server and uses SPEECHSC to control the ASR server.
この例では、ユーザーは在庫の見積もりを取得するためにサービスを呼び出します。VoIPゲートウェイは、PSTNコールに応答します。IVRアプリケーションは、VXMLスクリプトをゲートウェイにフィードして、ユーザーインタラクションを駆動します。ゲートウェイ上のVXMLインタープリターは、ユーザーのメディアストリームをSpeechSC ASRサーバーに向け、SpeechSCを使用してASRサーバーを制御します。
When, for example, the user speaks the name of a stock in response to an IVR prompt, the SPEECHSC ASR server attempts recognition of the name, and returns the results to the VXML gateway. The VXML gateway, following standard VXML mechanisms, informs the IVR Application of the recognized result. The IVR Application can then do the appropriate information lookup. The answer, of course, can be sent back to the user using text-to-speech. This example does not show this scenario, but it would work analogously to the scenario shown in section Section 2.1.
たとえば、ユーザーがIVRプロンプトに応じて在庫の名前を話すと、SpeechSC ASRサーバーは名前の認識を試み、結果をVXMLゲートウェイに返します。VXMLゲートウェイは、標準のVXMLメカニズムに従って、認識された結果のIVRアプリケーションを通知します。IVRアプリケーションは、適切な情報検索を行うことができます。もちろん、答えはテキストからスピーチを使用してユーザーに送り返すことができます。この例はこのシナリオを示していませんが、セクション2.1に示すシナリオと同様に機能します。
This example illustrates using speaker identification to allow voice-actuated login to an IP phone. The example scenario is shown below in Figure 4. In the figure, the IP Phone acts as both the "Media Processing Entity" and the "Application Server" of the SPEECHSC framework in Figure 1.
この例は、スピーカーの識別を使用して、音声作動型のログインをIP電話に可能にすることを示しています。例のシナリオを図4に示します。図では、IP電話は図1のSpeechSCフレームワークの「メディア処理エンティティ」と「アプリケーションサーバー」の両方として機能します。
+-----------+ +---------+
| | RTP | |
| IP |=========| SPEECHSC|
| Phone | | TTS |
| |_________| Server |
| | SPEECHSC| |
+-----------+ +---------+
Figure 4: Speaker Identification Example
図4：スピーカー識別の例
In this example, a user speaks into a SIP phone in order to get "logged in" to that phone to make and receive phone calls using his identity and preferences. The IP phone uses the SPEECHSC framework to set up an RTP stream between the phone and the SPEECHSC SI/SV server and to request verification. The SV server verifies the user's identity and returns the result, including the necessary login credentials, to the phone via SPEECHSC. The IP Phone may use the identity directly to identify the user in outgoing calls, to fetch the user's preferences from a configuration server, or to request authorization from an Authentication, Authorization, and Accounting (AAA) server, in any combination. Since this example uses SPEECHSC to perform a security-related function, be sure to note the associated material in Section 9.
この例では、ユーザーは、その電話に「ログイン」するために、自分の身元と好みを使用して電話をかけて受け取るために、SIP電話に話しかけます。IP電話は、SpeechSCフレームワークを使用して、電話とSpeechSC SI/SVサーバーの間にRTPストリームを設定し、確認を要求します。SVサーバーはユーザーのIDを検証し、必要なログイン資格情報を含む結果をSpeechSCを介して電話に返します。IP電話は、IDを直接使用して、発信コールでユーザーを識別したり、Configuration Serverからユーザーの設定を取得したり、任意の組み合わせで認証、承認、会計（AAA）サーバーから認証を要求したりできます。この例ではSpeechSCを使用してセキュリティ関連の関数を実行するため、セクション9の関連資料に注意してください。
To the extent feasible, the SPEECHSC framework SHOULD use existing protocols.
実行可能な限り、SpeechSCフレームワークは既存のプロトコルを使用する必要があります。
In meeting the requirement of Section 3.1, the SPEECHSC framework MUST NOT redefine the semantics of an existing protocol. Said differently, we will not break existing protocols or cause backward-compatibility problems.
セクション3.1の要件を満たす際、SpeechSCフレームワークは既存のプロトコルのセマンティクスを再定義してはなりません。別の言い方をすれば、既存のプロトコルを破ることも、後方互換性の問題を引き起こしません。
To the extent feasible, SPEECHSC SHOULD NOT duplicate the functionality of existing protocols. For example, network announcements using SIP [12] and RTSP [9] already define how to request playback of audio. The focus of SPEECHSC is new functionality not addressed by existing protocols or extending existing protocols within the strictures of the requirement in Section 3.2. Where an existing protocol can be gracefully extended to support SPEECHSC requirements, such extensions are acceptable alternatives for meeting the requirements.
実行可能な限り、SpeechSCは既存のプロトコルの機能を複製してはなりません。たとえば、SIP [12]とRTSP [9]を使用したネットワークアナウンスは、オーディオの再生をリクエストする方法を既に定義しています。SpeechSCの焦点は、既存のプロトコルによって対処されていない新しい機能、またはセクション3.2の要件の制限内で既存のプロトコルを拡張しないことです。既存のプロトコルをSpeechSC要件をサポートするために優雅に拡張できる場合、そのような拡張は要件を満たすための許容できる代替手段です。
As a corollary to this, the SPEECHSC should not require a separate protocol to perform functions that could be easily added into the SPEECHSC protocol (like redirecting media streams, or discovering capabilities), unless it is similarly easy to embed that protocol directly into the SPEECHSC framework.
これに対する結果として、SpeechSCは、SpeechSCプロトコルに簡単に追加できる関数を実行するために個別のプロトコルを必要としないはずです（メディアストリームのリダイレクトや機能の発見など）。フレームワーク。
The SPEECHSC framework SHOULD employ protocol elements known to result in efficient operation. Techniques to be considered include:
SpeechSCフレームワークは、効率的な動作をもたらすことが知られているプロトコル要素を使用する必要があります。考慮すべきテクニックには次のものがあります。
o Re-use of transport connections across sessions o Piggybacking of responses on requests in the reverse direction o Caching of state across requests
o セッション間の輸送接続の再利用o逆方向にリクエストに応じて応答のけど
The SPEECHSC framework MUST be compliant with the IAB Open Pluggable Edge Services (OPES) [4] framework. The applicability of the SPEECHSC protocol will therefore be specified as occurring between clients and servers at least one of which is operating directly on behalf of the user requesting the service.
SpeechSCフレームワークは、IAB Open Pluggable Edge Services（OPES）[4]フレームワークに準拠する必要があります。したがって、SpeechSCプロトコルの適用性は、クライアントとサーバー間で発生するものとして指定されます。そのうちの少なくとも1つは、サービスを要求するユーザーに代わって直接動作します。
To the extent feasible, the SPEECHSC framework SHOULD exploit existing schemes for supporting service location and load balancing, such as the Service Location Protocol [13] or DNS SRV records [14]. Where such facilities are not deemed adequate, the SPEECHSC framework MAY define additional load balancing techniques.
実行可能な限り、SpeechSCフレームワークは、サービスロケーションプロトコル[13]やDNS SRVレコード[14]など、サービスの場所と負荷分散をサポートするために既存のスキームを活用する必要があります。そのような施設が適切であると見なされない場合、SpeechSCフレームワークは追加の負荷分散技術を定義する場合があります。
The SPEECHSC framework MUST permit multiple services to operate on a single media stream so that either the same or different servers may be performing speech recognition, speaker identification or verification, etc., in parallel.
SpeechSCフレームワークでは、複数のサービスが単一のメディアストリームで操作できるようにする必要があります。そうすることで、同じまたは異なるサーバーが音声認識、スピーカーの識別または検証などを並行して実行できるようにする必要があります。
The SPEECHSC framework MUST allow a 1:N mapping between session and RTP channels. For example, a single session may include an outbound RTP channel for TTS, an inbound for ASR, and a different inbound for SI/SV (e.g., if processed by different elements on the Media Resource Element). Note: All of these can be described via SDP, so if SDP is utilized for media channel description, this requirement is met "for free".
SpeechSCフレームワークでは、セッションチャネルとRTPチャネル間の1：nマッピングを許可する必要があります。たとえば、単一のセッションには、TTS用のアウトバウンドRTPチャネル、ASRのインバウンド、およびSI/SVの異なるインバウンドが含まれます（たとえば、メディアリソース要素の異なる要素によって処理された場合）。注：これらはすべてSDPを介して説明できます。そのため、SDPがメディアチャネルの説明に使用される場合、この要件は「無料」で満たされます。
The SPEECHSC framework must have sufficient capabilities to address the critical needs of people with disabilities. In particular, the set of requirements set forth in RFC 3351 [5] MUST be taken into account by the framework. It is also important that implementers of SPEECHSC clients and servers be cognizant that some interaction modalities of SPEECHSC may be inconvenient or simply inappropriate for disabled users. Hearing-impaired individuals may find TTS of limited utility. Speech-impaired users may be unable to make use of ASR or SI/SV capabilities. Therefore, systems employing SPEECHSC MUST provide alternative interaction modes or avoid the use of speech processing entirely.
SpeechSCフレームワークには、障害のある人々の重要なニーズに対処するための十分な能力が必要です。特に、RFC 3351 [5]に記載されている一連の要件を、フレームワークによって考慮する必要があります。また、SpeechSCクライアントとサーバーの実装者が、SpeechSCのいくつかの相互作用モダリティが不便または単に障害者ユーザーにとって不適切である可能性があることを認識することも重要です。聴覚障害者は、限られたユーティリティのTTを見つける可能性があります。音声障害のあるユーザーは、ASRまたはSI/SV機能を使用できない場合があります。したがって、SpeechSCを使用するシステムは、代替の相互作用モードを提供するか、音声処理の使用を完全に回避する必要があります。
The client of a SPEECHSC operation SHOULD be able to ascertain via the SPEECHSC framework what speech process produced the output. For example, an RTP stream containing the spoken output of TTS should be identifiable as TTS output, and the recognized utterance of ASR should be identifiable as having been produced by ASR processing.
SpeechSC操作のクライアントは、SpeechSCフレームワークを介して、出力を生成した音声プロセスを確認できる必要があります。たとえば、TTSの音声出力を含むRTPストリームはTTS出力として識別できる必要があり、ASRの認識された発話はASR処理によって生成されたと識別可能です。
The SPEECHSC framework MUST allow a Media Processing Entity or Application Server, using a control protocol, to request the TTS Server to play back text as voice in an RTP stream.
SpeechSCフレームワークでは、コントロールプロトコルを使用してメディア処理エンティティまたはアプリケーションサーバーを使用して、TTSサーバーにRTPストリームの音声としてテキストを再生するように要求する必要があります。
The SPEECHSC framework MAY assume that all TTS servers are capable of reading plain text. For reading plain text, framework MUST allow the language and voicing to be indicated via session parameters. For finer control over such properties, see [1].
SpeechSCフレームワークでは、すべてのTTSサーバーがプレーンテキストを読み取ることができると想定する場合があります。プレーンテキストを読むには、フレームワークがセッションパラメーターを介して言語と声を示すことを許可する必要があります。このような特性をより細かく制御するには、[1]を参照してください。
The SPEECHSC framework MUST support Speech Synthesis Markup Language (SSML)[1] <speak> basics, and SHOULD support other SSML tags. The framework assumes all TTS servers are capable of reading SSML formatted text. Internationalization of TTS in the SPEECHSC framework, including multi-lingual output within a single utterance, is accomplished via SSML xml:lang tags.
SpeechSCフレームワークは、音声統合マークアップ言語（SSML）[1] <Speak>基本をサポートする必要があり、他のSSMLタグをサポートする必要があります。フレームワークは、すべてのTTSサーバーがSSMLフォーマットされたテキストを読み取ることができると想定しています。単一の発話内の多言語出力を含むSpeechSCフレームワークにおけるTTSの国際化は、SSML XML：Langタグを介して達成されます。
The SPEECHSC framework assumes all TTS servers accept text over the SPEECHSC connection for reading over the RTP connection. The framework assumes the server can accept text either "by value" (embedded in the protocol) or "by reference" (e.g., by de-referencing a Uniform Resource Identifier (URI) embedded in the protocol).
SpeechSCフレームワークでは、すべてのTTSサーバーがRTP接続を読むためにSpeechSC接続を介してテキストを受け入れると想定しています。フレームワークは、サーバーが「値によって」（プロトコルに埋め込まれている）または「参照」（たとえば、プロトコルに埋め込まれた均一なリソース識別子（URI）を参照することにより）のいずれかを受け入れることができると想定しています。
A document type specifies the syntax in which the text to be read is encoded. The SPEECHSC framework MUST be capable of explicitly indicating the document type of the text to be processed, as opposed to forcing the server to infer the content by other means.
ドキュメントタイプは、読み取るテキストがエンコードされる構文を指定します。SpeechSCフレームワークは、サーバーに他の手段でコンテンツを推測することを強制するのではなく、処理するテキストのドキュメントタイプを明示的に示すことができなければなりません。
The SPEECHSC framework MUST be capable of establishing the control channel between the client and server on a per-session basis, where a session is loosely defined to be associated with a single "call" or "dialog". The protocol SHOULD be capable of maintaining a long-lived control channel for multiple sessions serially, and MAY be capable of shorter time horizons as well, including as short as for the processing of a single utterance.
SpeechSCフレームワークは、セッションごとにクライアントとサーバーの間で制御チャネルを確立できる必要があります。セッションは、単一の「呼び出し」または「ダイアログ」に関連付けられるようにセッションがゆるく定義されています。このプロトコルは、複数のセッションに連続的に長寿命の制御チャネルを維持できる必要があり、単一の発話の処理と同じように、時間の視野も短い場合があります。
The SPEECHSC framework MUST NOT require the controlling element (application server, media processing entity) to accept or originate media streams. Media streams MAY source & sink from the controlled element (ASR, TTS, etc.).
SpeechSCフレームワークでは、メディアストリームを受け入れるか発生させるために、制御要素（アプリケーションサーバー、メディア処理エンティティ）を必要としてはなりません。メディアストリームは、制御された要素（ASR、TTSなど）から調達および沈むことがあります。
The SPEECHSC framework MUST support "VCR controls" for controlling
the playout of streaming media output from SPEECHSC processing, and
MUST allow for servers with varying capabilities to accommodate such
controls. The protocol SHOULD allow clients to state what controls
they wish to use, and for servers to report which ones they honor.
These capabilities include:
o The ability to jump in time to the location of a specific marker.
o The ability to jump in time, forwards or backwards, by a specified
amount of time. Valid time units MUST include seconds, words,
paragraphs, sentences, and markers.
o The ability to increase and decrease playout speed.
o The ability to fast-forward and fast-rewind the audio, where
snippets of audio are played as the server moves forwards or
backwards in time.
o The ability to pause and resume playout.
o The ability to increase and decrease playout volume.
These controls SHOULD be made easily available to users through the client user interface and through per-user customization capabilities of the client. This is particularly important for hearing-impaired users, who will likely desire settings and control regimes different from those that would be acceptable for non-impaired users.
これらのコントロールは、クライアントユーザーインターフェイスおよびクライアントのユーザーごとのカスタマイズ機能を介して、ユーザーが簡単に利用できるようにする必要があります。これは、聴覚障害のあるユーザーにとって特に重要です。聴覚障害のあるユーザーは、障害のないユーザーに受け入れられるものとは異なる設定と制御体制を希望する可能性があります。
The SPEECHSC framework MUST support the specification of session parameters, such as language, prosody, and voicing.
SpeechSCフレームワークは、言語、韻律、発声などのセッションパラメーターの仕様をサポートする必要があります。
The SPEECHSC framework MUST accommodate speech markers, with capability at least as flexible as that provided in SSML [1]. The framework MUST further provide an efficient mechanism for reporting that a marker has been reached during playout.
SpeechSCフレームワークは、少なくともSSMLで提供されているものと同じくらい柔軟な機能を備えた音声マーカーに対応する必要があります[1]。このフレームワークは、プレイアウト中にマーカーに到達したことを報告するための効率的なメカニズムをさらに提供する必要があります。
The SPEECHSC framework MUST allow a Media Processing Entity or Application Server to request the ASR Server to perform automatic speech recognition on an RTP stream, returning the results over SPEECHSC.
SpeechSCフレームワークでは、メディア処理エンティティまたはアプリケーションサーバーがASRサーバーにRTPストリームで自動音声認識を実行するように要求し、SpeechSCを介して結果を返すようにする必要があります。
The SPEECHSC framework assumes that all ASR servers support the VoiceXML speech recognition grammar specification (SRGS) for speech recognition [2].
SpeechSCフレームワークは、すべてのASRサーバーが音声認識のためにVoiceXML音声認識文法仕様（SRG）をサポートすることを前提としています[2]。
The SPEECHSC framework assumes all ASR servers are capable of accepting grammar specifications either "by value" (embedded in the protocol) or "by reference" (e.g., by de-referencing a URI embedded in the protocol). The latter MUST allow the indication of a grammar already known to, or otherwise "built in" to, the server. The framework and protocol further SHOULD exploit the ability to store and later retrieve by reference large grammars that were originally supplied by the client.
SpeechSCフレームワークでは、すべてのASRサーバーが、「値」（プロトコルに埋め込まれた）または「参照」（たとえば、プロトコルに埋め込まれたURIを解除することにより）のいずれかの文法仕様を受け入れることができると想定しています。後者は、サーバーに既に知られている、または「組み込まれている」文法の兆候を許可する必要があります。フレームワークとプロトコルはさらに、クライアントが元々供給されていた大規模な文法を参照して、保存して後で取得する能力を活用する必要があります。
The SPEECHSC framework protocol MUST be able to explicitly convey the grammar format in which the grammar is encoded and MUST be extensible to allow for conveying new grammar formats as they are defined.
SpeechSCフレームワークプロトコルは、文法がエンコードされている文法形式を明示的に伝えることができ、定義された新しい文法形式を伝えるために拡張可能でなければなりません。
The SPEECHSC framework SHOULD exploit sharing grammars across sessions for servers that are capable of doing so. This supports applications with large grammars for which it is unrealistic to dynamically load. An example is a city-country grammar for a weather service.
SpeechSCフレームワークは、そうすることができるサーバーのセッション全体で文法を共有することを活用する必要があります。これは、動的に負荷をかけることが非現実的な大きな文法でのアプリケーションをサポートします。例は、気象サービスのための都市国の文法です。
The SPEECHSC framework MUST accommodate at a minimum all of the protocol parameters currently defined in Media Resource Control Protocol (MRCP) [10] In addition, there SHOULD be a capability to reset parameters within a session.
SpeechSCフレームワークは、メディアリソースコントロールプロトコル（MRCP）[10]で現在定義されているすべてのプロトコルパラメーターに最低限対応する必要があります。さらに、セッション内でパラメーターをリセットする機能が必要です。
The SPEECHSC framework MUST support a method directing the ASR Server to capture the input media stream for later analysis and tuning of the ASR engine.
SpeechSCフレームワークは、ASRサーバーを指示するメソッドをサポートする必要があります。ASRエンジンの後の分析とチューニングのために、入力メディアストリームをキャプチャする必要があります。
The SPEECHSC framework MUST allow a Media Processing Entity to request the SI/SV Server to perform speaker identification or verification on an RTP stream, returning the results over SPEECHSC.
SpeechSCフレームワークでは、メディア処理エンティティがSI/SVサーバーにRTPストリームでスピーカーの識別または検証を実行するように要求し、SpeechSCを介して結果を返すようにする必要があります。
The SPEECHSC framework MUST accommodate an identifier for each verification resource and permit control of that resource by ID, because voiceprint format and contents are vendor specific.
SpeechSCフレームワークは、VoicePrint形式とコンテンツがベンダー固有であるため、検証リソースごとに識別子に対応し、IDでそのリソースの制御を許可する必要があります。
The SPEECHSC framework MUST work with SI/SV servers that maintain state to handle multi-utterance verification.
SpeechSCフレームワークは、多発性検証を処理するために状態を維持するSi/SVサーバーで動作する必要があります。
The SPEECHSC framework MUST support a method for capturing the input media stream for later analysis and tuning of the SI/SV engine. The framework may assume all servers are capable of doing so. In addition, the framework assumes that the captured stream contains enough timestamp context (e.g., the NTP time range from the RTP Control Protocol (RTCP) packets, which corresponds to the RTP timestamps of the captured input) to ascertain after the fact exactly when the verification was requested.
SpeechSCフレームワークは、SI/SVエンジンの後の分析とチューニングのために、入力メディアストリームをキャプチャする方法をサポートする必要があります。フレームワークは、すべてのサーバーがそうすることができると想定する場合があります。さらに、フレームワークは、キャプチャされたストリームに十分なタイムスタンプコンテキスト（たとえば、RTP制御プロトコル（RTCP）パケットからのNTP時間範囲）が含まれていることを前提としています。検証が要求されました。
The SPEECHSC framework SHOULD be extensible to additional functions associated with SI/SV, such as prompting, utterance verification, and retraining.
SpeechSCフレームワークは、プロンプト、発話検証、再訓練など、SI/SVに関連付けられた追加の機能に拡張可能である必要があります。
One very important requirement for an interactive speech-driven system is that user perception of the quality of the interaction depends strongly on the ability of the user to interrupt a prompt or rendered TTS with speech. Interrupting, or barging, the speech output requires more than energy detection from the user's direction. Many advanced systems halt the media towards the user by employing the ASR engine to decide if an utterance is likely to be real speech, as opposed to a cough, for example.
インタラクティブな音声駆動型システムの非常に重要な要件の1つは、インタラクションの品質に対するユーザー認識が、ユーザーがスピーチでプロンプトまたはレンダリングされたTTを中断またはレンダリングする能力に強く依存することです。スピーチの出力を中断するか、バージするには、ユーザーの方向からのエネルギー検出以上のものが必要です。多くの高度なシステムは、ASRエンジンを使用して、たとえば咳とは対照的に、発話が実際のスピーチである可能性があるかどうかを判断することにより、ユーザーに対するメディアを停止します。
To achieve low latency between utterance detection and halting of playback, many implementations combine the speaking and ASR functions. The SPEECHSC framework MUST support such full-duplex implementations.
発話検出と再生の停止の間の低レイテンシを達成するために、多くの実装がスピーキングとASR関数を組み合わせています。SpeechSCフレームワークは、このような全二重実装をサポートする必要があります。
Good spoken user interfaces typically depend upon the ease with which the user can accomplish his or her task. When making use of speaker identification or verification technologies, user interface improvements often come from the combination of the different technologies: simultaneous identity claim and verification (on the same utterance), simultaneous knowledge and voice verification (using ASR and verification simultaneously). Using ASR and verification on the same utterance is in fact the only way to support rolling or dynamically-generated challenge phrases (e.g., "say 51723"). The SPEECHSC framework MUST support such parallel service implementations.
よく話されているユーザーインターフェイスは、通常、ユーザーがタスクを容易にすることができることに依存します。スピーカーの識別または検証テクノロジーを使用する場合、ユーザーインターフェイスの改善は、異なるテクノロジーの組み合わせからしばしば発生します。同時のアイデンティティの主張と検証（同じ発話）、同時の知識と音声検証（ASRを使用して、検証を同時に使用します）。ASRと同じ発話での検証を使用することは、実際には、ローリングまたは動的に生成されたチャレンジフレーズをサポートする唯一の方法です（たとえば、「51723」など）。SpeechSCフレームワークは、このような並列サービスの実装をサポートする必要があります。
It is optionally of interest that the SPEECHSC framework support more complex remote combination and controls of speech engines:
SpeechSCフレームワークが、より複雑なリモートの組み合わせと音声エンジンのコントロールをサポートすることはオプションです。
o Combination in series of engines that may then act on the input or output of ASR, TTS, or Speaker recognition engines. The control MAY then extend beyond such engines to include other audio input and output processing and natural language processing. o Intermediate exchanges and coordination between engines. o Remote specification of flows between engines.
o ASR、TTS、またはスピーカー認識エンジンの入力または出力に作用する可能性のある一連のエンジンの組み合わせ。その後、制御はそのようなエンジンを超えて拡張して、他のオーディオ入力と出力処理と自然言語処理を含めることができます。oエンジン間の中間交換と調整。oエンジン間のフローのリモート仕様。
These capabilities MAY benefit from service discovery mechanisms (e.g., engines, properties, and states discovery).
これらの機能は、サービスの発見メカニズム（エンジン、プロパティ、および州の発見など）の恩恵を受ける可能性があります。
The framework assumes that Session Description Protocol (SDP) will be used to describe media sessions and streams. The framework further assumes RTP carriage of media. However, since SDP can be used to describe other media transport schemes (e.g., ATM) these could be used if they provide the necessary elements (e.g., explicit timestamps).
フレームワークは、セッション説明プロトコル（SDP）を使用して、メディアセッションとストリームを説明することを前提としています。フレームワークはさらに、メディアのRTPキャリッジを想定しています。ただし、SDPを使用して他のメディアトランスポートスキーム（ATMなど）を記述できるため、必要な要素（明示的なタイムスタンプなど）を提供する場合は使用できます。
The working group will not be defining distributed speech recognition (DSR) methods, as exemplified by the European Telecommunications Standards Institute (ETSI) Aurora project. The working group will not be recreating functionality available in other protocols, such as SIP or SDP.
ワーキンググループは、欧州通信基準研究所（ETSI）Auroraプロジェクトで例示されるように、分散型音声認識（DSR）メソッドを定義しません。ワーキンググループは、SIPやSDPなどの他のプロトコルで利用可能な機能を再現しません。
TTS looks very much like playing back a file. Extending RTSP looks promising for when one requires VCR controls or markers in the text to be spoken. When one does not require VCR controls, SIP in a framework such as Network Announcements [12] works directly without modification.
TTSは、ファイルを再生することに非常によく似ています。RTSPを拡張すると、テキスト内のVCRコントロールまたはマーカーが話される必要がある場合に有望に見えます。VCRコントロールを必要としない場合、ネットワークアナウンス[12]などのフレームワークを修正せずに直接動作します。
ASR has an entirely different set of characteristics. For barge-in support, ASR requires real-time return of intermediate results. Barring the discovery of a good reuse model for an existing protocol, this will most likely become the focus of SPEECHSC.
ASRには、まったく異なる特性セットがあります。Barge-in Supportのために、ASRは中間結果をリアルタイムで返す必要があります。既存のプロトコルの優れた再利用モデルの発見を除けば、これはおそらくSpeechSCの焦点になるでしょう。
Protocols relating to speech processing must take security and privacy into account. Many applications of speech technology deal with sensitive information, such as the use of Text-to-Speech to read financial information. Likewise, popular uses for automatic speech recognition include executing financial transactions and shopping.
音声処理に関連するプロトコルは、セキュリティとプライバシーを考慮する必要があります。音声技術の多くのアプリケーションは、財務情報を読むためのテキストからスピーチの使用など、機密情報を扱います。同様に、自動音声認識のための一般的な用途には、金融取引の実行やショッピングが含まれます。
There are at least three aspects of speech processing security that intersect with the SPEECHSC requirements -- securing the SPEECHSC protocol itself, implementing and deploying the servers that run the protocol, and ensuring that utilization of the technology for providing security functions is appropriate. Each of these aspects in discussed in the following subsections. While some of these considerations are, strictly speaking, out of scope of the protocol itself, they will be carefully considered and accommodated during protocol design, and will be called out as part of the applicability statement accompanying the protocol specification(s). Privacy considerations are discussed as well.
SpeechSCプロトコル自体を確保し、プロトコルを実行するサーバーの実装と展開、セキュリティ機能を提供するためのテクノロジーの利用が適切であることを、SpeechSC要件と交差する音声処理セキュリティには少なくとも3つの側面があります。これらの側面のそれぞれは、以下のサブセクションで説明します。これらの考慮事項のいくつかは、厳密に言えば、プロトコル自体の範囲外ではありませんが、プロトコル設計中に慎重に検討および収容され、プロトコル仕様に付随する適用性ステートメントの一部として呼び出されます。プライバシーに関する考慮事項についても議論されています。
The SPEECHSC protocol MUST in all cases support authentication, authorization, and integrity, and SHOULD support confidentiality. For privacy-sensitive applications, the protocol MUST support confidentiality. We envision that rather than providing protocol-specific security mechanisms in SPEECHSC itself, the resulting protocol will employ security machinery of either a containing protocol or the transport on which it runs. For example, we will consider solutions such as using Transport Layer Security (TLS) for securing the control channel, and Secure Realtime Transport Protocol (SRTP) for securing the media channel. Third-party dependencies necessitating transitive trust will be minimized or explicitly dealt with through the authentication and authorization aspects of the protocol design.
SpeechSCプロトコルは、すべての場合において、認証、承認、および整合性をサポートする必要があり、機密性をサポートする必要があります。プライバシーに敏感なアプリケーションの場合、プロトコルは機密性をサポートする必要があります。SpeechSC自体にプロトコル固有のセキュリティメカニズムを提供するのではなく、結果として得られるプロトコルは、含有プロトコルまたはそれが実行される輸送のセキュリティ機械を採用することを想定しています。たとえば、コントロールチャネルを保護するために輸送層セキュリティ（TLS）を使用したり、メディアチャネルを保護するためにリアルタイムトランスポートプロトコル（SRTP）を保護するなどのソリューションを検討します。推移的信頼を必要とするサードパーティの依存関係は、プロトコル設計の認証と承認の側面を通じて、最小化または明示的に対処されます。
Given the possibly sensitive nature of the information carried, SPEECHSC clients and servers need to take steps to ensure confidentiality and integrity of the data and its transformations to and from spoken form. In addition to these general considerations, certain SPEECHSC functions, such as speaker verification and identification, employ voiceprints whose privacy, confidentiality, and integrity must be maintained. Similarly, the requirement to support input capture for analysis and tuning can represent a privacy vulnerability because user utterances are recorded and could be either revealed or replayed inappropriately. Implementers must take care to prevent the exploitation of any centralized voiceprint database and the recorded material from which such voiceprints may be derived. Specific actions that are recommended to minimize these threats include:
運ばれる情報の繊細な性質を考えると、SpeechSCクライアントとサーバーは、データの機密性と完全性とその変換と話し言葉への変換を確保するための措置を講じる必要があります。これらの一般的な考慮事項に加えて、スピーカーの検証や識別などの特定の音声関数は、プライバシー、機密性、整合性を維持する必要があるボイスプリントを採用しています。同様に、ユーザーの発話が記録され、不適切に公開または再生される可能性があるため、分析とチューニングの入力キャプチャをサポートする要件はプライバシーの脆弱性を表すことができます。実装者は、集中化されたVoicePrintデータベースと、そのようなVoicePrintが導出される可能性のある記録された資料の搾取を防ぐように注意する必要があります。これらの脅威を最小限に抑えるために推奨される特定のアクションは次のとおりです。
o End-to-end authentication, confidentiality, and integrity protection (like TLS) of access to the database to minimize the exposure to external attack. o Database protection measures such as read/write access control and local login authentication to minimize the exposure to insider threats. o Copies of the database, especially ones that are maintained at off-site locations, need the same protection as the operational database.
o データベースへのアクセスのエンドツーエンドの認証、機密性、および完全性保護（TLSなど）外部攻撃への露出を最小限に抑えます。o読み取り/書き込みアクセスコントロールやローカルログイン認証などのデータベース保護測定により、インサイダーの脅威への露出を最小限に抑えます。oデータベースのコピー、特にオフサイトの場所に維持されているコピーには、運用データベースと同じ保護が必要です。
Inappropriate disclosure of this data does not as of the date of this document represent an exploitable threat, but quite possibly might in the future. Specific vulnerabilities that might become feasible are discussed in the next subsection. It is prudent to take measures such as encrypting the voiceprint database and permitting access only through programming interfaces enforcing adequate authorization machinery.
このデータの不適切な開示は、このドキュメントの日付時点では搾取可能な脅威を表していませんが、将来的には可能性があります。実行可能になる可能性のある特定の脆弱性については、次のサブセクションで説明します。VoicePrintデータベースを暗号化したり、適切な承認機械を強制するプログラミングインターフェイスを介してアクセスを許可するなどの措置を講じることは賢明です。
Either speaker identification or verification can be used directly as an authentication technology. Authorization decisions can be coupled with speaker verification in a direct fashion through challenge-response protocols, or indirectly with speaker identification through the use of access control lists or other identity-based authorization mechanisms. When so employed, there are additional security concerns that need to be addressed through the use of protocol security mechanisms for clients and servers. For example, the ability to manipulate the media stream of a speaker verification request could inappropriately permit or deny access based on impersonation, or simple garbling via noise injection, making it critical to properly secure both the control and data channels, as recommended above. The following issues specific to the use of SI/SV for authentication should be carefully considered:
スピーカーの識別または検証は、認証技術として直接使用できます。承認の決定は、チャレンジ応答プロトコルを通じて直接的な方法でスピーカーの検証と結合すること、またはアクセス制御リストまたはその他のアイデンティティベースの承認メカニズムの使用によるスピーカーの識別と間接的に結合することができます。そのように雇用されている場合、クライアントとサーバーにプロトコルセキュリティメカニズムを使用して対処する必要がある追加のセキュリティ上の懸念があります。たとえば、スピーカー検証リクエストのメディアストリームを操作する機能は、なりすましに基づいてアクセスを不適切に許可または拒否したり、ノイズインジェクションを介して簡単なガーリングを行い、上記のようにコントロールチャネルとデータチャネルの両方を適切に保護することが重要になります。認証のためにSI/SVの使用に固有の以下の問題は、慎重に考慮する必要があります。
1. Theft of voiceprints or the recorded samples used to construct them represents a future threat against the use of speaker identification/verification as a biometric authentication technology. A plausible attack vector (not feasible today) is to use the voiceprint information as parametric input to a text-to-speech synthesis system that could mimic the user's voice accurately enough to match the voiceprint. Since it is not very difficult to surreptitiously record reasonably large corpuses of voice samples, the ability to construct voiceprints for input to this attack would render the security of voice-based biometric authentication, even using advanced challenge-response techniques, highly vulnerable. Users of speaker verification for authentication should monitor technological developments in this area closely for such future vulnerabilities (much as users of other authentication technologies should monitor advances in factoring as a way to break asymmetric keying systems). 2. As with other biometric authentication technologies, a downside to the use of speech identification is that revocation is not possible. Once compromised, the biometric information can be used in identification and authentication to other independent systems. 3. Enrollment procedures can be vulnerable to impersonation if not protected both by protocol security mechanisms and some independent proof of identity. (Proof of identity may not be needed in systems that only need to verify continuity of identity since enrollment, as opposed to association with a particular individual.
1. VoicePrintsまたはそれらを構築するために使用される記録されたサンプルの盗難は、生体認証技術としてのスピーカーの識別/検証の使用に対する将来の脅威を表しています。もっともらしい攻撃ベクトル（今日は不可能）は、VoicePrint情報をテキストからスピーチ合成システムへのパラメトリック入力として使用することです。正しく大きな音声サンプルのコーパスをひそかに記録することはそれほど難しくないため、この攻撃への入力の音声プリントを構築する能力は、高度なチャレンジ応答技術を使用しても、音声ベースの生体認証のセキュリティを提供します。認証のためのスピーカー検証のユーザーは、このような将来の脆弱性のためにこの分野の技術開発を綿密に監視する必要があります（他の認証技術のユーザーは、非対称キーインシステムを破る方法として、因数分解の進歩を監視する必要があります）。2.他の生体認証テクノロジーと同様に、音声識別の使用のマイナス面は、取り消しは不可能であるということです。侵害されると、生体認証情報は、他の独立したシステムの識別と認証に使用できます。3.登録手順は、プロトコルセキュリティメカニズムと独立したアイデンティティの証明の両方によって保護されていない場合、なりすましに対して脆弱です。（特定の個人との関連性とは対照的に、登録以来のアイデンティティの継続性を検証するだけであるシステムでは、アイデンティティの証明は必要ない場合があります。
Further discussion of the use of SI/SV as an authentication technology, and some recommendations concerning advantages and vulnerabilities, can be found in Chapter 5 of [15].
認証技術としてのSI/SVの使用に関するさらなる議論、および利点と脆弱性に関するいくつかの推奨事項は、[15]の第5章に記載されています。
Eric Burger wrote the original version of these requirements and has continued to contribute actively throughout their development. He is a co-author in all but formal authorship, and is instead acknowledged here as it is preferable that working group co-chairs have non-conflicting roles with respect to the progression of documents.
エリック・バーガーは、これらの要件の元のバージョンを書き、開発を通じて積極的に貢献し続けています。彼は、正式な著者を除くすべての共著者であり、代わりに、ワーキンググループの共同議長がドキュメントの進行に関して非紛争の役割を持っていることが望ましいため、ここで認められています。
[1] Walker, M., Burnett, D., and A. Hunt, "Speech Synthesis Markup Language (SSML) Version 1.0", W3C REC REC-speech-synthesis-20040907, September 2004.
[1] Walker、M.、Burnett、D。、およびA. Hunt、「音声合成マークアップ言語（SSML）バージョン1.0」、W3C Rec Rec-Speech-Synthesis-20040907、2004年9月。
[2] McGlashan, S. and A. Hunt, "Speech Recognition Grammar Specification Version 1.0", W3C REC REC-speech-grammar-20040316, March 2004.
[2] McGlashan、S。およびA. Hunt、「音声認識文法仕様バージョン1.0」、W3C Rec Rec-Speech-Grammar-20040316、2004年3月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[4] Floyd、S。and L. Daigle、「Open Pluggable Edge ServicesのIAB建築および政策上の考慮事項」、RFC 3238、2002年1月。
[5] 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.
[5] Charlton、N.、Gasson、M.、Gybels、G.、Spanner、M。、およびA. Van Wijk、「聴覚障害、聴覚障害、言語障害者をサポートするセッション開始プロトコル（SIP）のユーザー要件"、RFC 3351、2002年8月。
[6] 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.
[6] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[7] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[7] Andreasen、F。およびB. Foster、「Media Gateway Control Protocol（MGCP）バージョン1.0」、RFC 3435、2003年1月。
[8] Groves, C., Pantaleo, M., Ericsson, LM., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[8] Groves、C.、Pantaleo、M.、Ericsson、Lm。、Anderson、T.、およびT. Taylor、「Gateway Control Protocolバージョン1」、RFC 3525、2003年6月。
[9] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[9] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[10] Shanmugham, S., Monaco, P., and B. Eberman, "MRCP: Media Resource Control Protocol", Work in Progress.
[10] Shanmugham、S.、Monaco、P。、およびB. Eberman、「MRCP：Media Resource Control Protocol」、Work in Progress。
[11] World Wide Web Consortium, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C Working Draft , April 2002, <http://www.w3.org/TR/2002/WD-voicexml20-20020424/>.
[11] World Wide Webコンソーシアム、「Voice Extensible Markup Language（VoiceXML）バージョン2.0」、W3Cワーキングドラフト、2002年4月、<http://www.w3.org/tr/2002/wd-voicexml20-20020424/>。
[12] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[12] Burger、E.、ed。、van Dyke、J。、およびA. Spitzer、「SIP付き基本ネットワークメディアサービス」、RFC 4240、2005年12月。
[13] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[13] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「Service Location Protocol、Version 2」、RFC 2608、1999年6月。
[14] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[14] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[15] Committee on Authentication Technologies and Their Privacy Implications, National Research Council, "Who Goes There?: Authentication Through the Lens of Privacy", Computer Science and Telecommunications Board (CSTB) , 2003, <http://www.nap.edu/catalog/10656.html/ >.
[15] 認証技術委員会とそのプライバシーへの影響、国家研究評議会、「誰がそこに行くのか？：プライバシーのレンズによる認証」、コンピューターサイエンスと電気通信委員会（CSTB）、<http://www.nap.edu/catalog/10656.html/>。
Author's Address
著者の連絡先
David R. Oran Cisco Systems, Inc. 7 Ladyslipper Lane Acton, MA USA
David R. Oran Cisco Systems、Inc。
EMail: oran@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。