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
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).
著作権（C）インターネット協会（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.
この文書では、オーディオストリームの分散音声処理を制御するためのプロトコルのためのニーズと必要条件を概説します。及びテキスト・ツー・スピーチ（TTS） - 話者識別（SI）と話者照合（SV）の両方を含む - 音声処理によって、この文書は、具体的には自動音声認識（ASR）、話者認識を意味します。そのようなSIPおよびリアルタイムストリーミングプロトコル（RTSP）、一般メディアストリームのアドレスランデブーや制御などの他のIETFプロトコル、。しかし、音声処理は、現存する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.
そこメディアセッションの確立及び終了のための複数のIETFプロトコル（SIP [6]）、低レベルのメディア制御されている（メディアゲートウェイ制御プロトコル（MGCP）の[7]とメディアゲートウェイコントローラ（MEGACO）[8]）、及びメディア・レコードそして再生（RTSP [9]）。また、このドキュメントでは、テキスト音声として知られている自動音声認識（ASR）を実行するネットワーク要素の制御をサポートするために、1つのまたは複数のプロトコルのための要件、話者の識別や検証（SI / SV）、およびオーディオにテキストを描画する、に焦点を当てて（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電話、メディアサーバー、およびネットワーク上のサーバを経由して音声サービスを受ける無線モバイル機器をスイッチに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.
現在までに、独自のASRおよびTTSの多数のAPIと同様に、この問題に対処する2つのIETFドキュメント[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].
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" [3] RFC 2119に記載されるように解釈されるべきです。
Figure 1 below shows the SPEECHSC framework for speech processing.
図1は、以下音声処理用SPEECHSCフレームワークを示します。
+-------------+
| 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サーバは、」バックエンド音声処理を行うネットワーク要素です。これは、テキスト入力（TTS）に基づいて、出力としてRTPストリームを生成又は入力（ASR、SI / SV）などのRTPストリームに応答して、認識結果を返すことができます。 「Application Serverは、」メディア・ストリームに対して行うものを変換にメディア処理エンティティを指示するネットワーク要素です。これらの命令は、SIPのようなセッション・プロトコルを介して確立された、またはそのようなVoiceXMLのようなクライアント/サーバ交換を介して提供することができます。フレームワークは、メディア処理エンティティまたはApplication Serverのどちらかが、図に二回登場するSPEECHSCプロトコルを占める制御プロトコルとしてSPEECHSCを使用してASRやTTSサーバを制御することができます。
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]ゲートウェイは、メディア処理エンティティと同じプラットフォーム上にASRおよびTTS機能を組み合わせることができます。 VoiceXMLの自身がこのプロトコルの範囲外であるゲートウェイことに注意してください。同様に、1は、対話型音声応答（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の範囲に再び直交しています。以下のサブセクションではSPEECHSC、TTS、ASR、およびSI / SVのための1つのそれぞれの例示的なユースケースの数を提供します。これらは、単に例示であること、およびフレームワークの範囲に何ら制限を暗示する、または例に示すものに分解または構成を限定するものではないことを意図しています。
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.
この例では、テキスト形式のエラーメッセージの表示なしで電話で、ユーザーへの告知を再生するためのテキスト読み上げサービスを提供するSPEECHSCの簡単な使用方法を示しています。例示的なシナリオは、VoIPゲートウェイは、メディア処理エンティティと、図1におけるSPEECHSCフレームワークのアプリケーションサーバの両方として機能する、同図において図2に以下に示されています。
+---------+
_| 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）電話電話をかけるために、左の試みで。 VoIPゲートウェイは、SIP UAとして動作する、コールを完了するためにSIPセッションを確立しようとしますが、そのようなSIP「486ここで忙しい」応答として、エラーを取得します。 SPEECHSCがなければ、ゲートウェイのPOTS電話に最も可能性が高いだけで出力ビジー信号だろう。しかし、TTSサーバへSPEECHSCアクセスして、それが話されたエラーメッセージを提供することができます。 VoIPゲートウェイは、したがって、そのような「と呼ばれるパーティがビジー状態だったので、978-555-1212までお使いのコールが通過しませんでした」などのSIPメッセージからの情報を使用して、テキストエラー文字列を、構築します。その後、SPEECHSCサーバとの関連付けを確立するためにSPEECHSCを使用して自分自身とサーバ間のRTPストリームを開き、POTS電話上のユーザに再生されるエラーメッセージのための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.
この例では、対話型音声応答（IVR）システムを介してASRベースのユーザインタフェースを供給するSPEECHSCフレームワークを使用して、VXML対応メディア処理エンティティと関連付けられているアプリケーションサーバを示す図です。例示的なシナリオは、IVRアプリケーション・サーバは、図1のSPEECHSCフレームワークの「アプリケーションサーバ」に相当するVXMLクライアントは、「メディア処理エンティティ」に相当し、図3で以下に示されています。
+------------+
| 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サーバへのユーザのメディアストリームを指示し、ASRサーバを制御するためにSPEECHSCを使用しています。
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に以下に示され、「メディア処理エンティティ」と図1のSPEECHSCフレームワークの「アプリケーションサーバ」の両方としてIP電話機能します。
+-----------+ +---------+
| | 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 SI / SVサーバ間のRTPストリームを設定し、検証を要求するSPEECHSCフレームワークを使用しています。 SVサーバーは、ユーザーの身元を確認し、SPEECHSCを経由して携帯電話に、必要なログイン資格情報を含め、結果を返します。 IP電話は、構成サーバーからユーザーの好みを取得するために、または任意の組み合わせでの認証からの許可、認可、アカウンティング（AAA）のサーバを、要求するために、発信コールでユーザーを識別するために、直接IDを使用することができます。この例では、セキュリティ関連の機能を実行するために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
可能な限り、SPEECHSCは、既存のプロトコルの機能を複製することはできません。例えば、SIP [12]およびRTSPを使用してネットワークアナウンス[9]既にオーディオの再生を要求する方法を定義します。 SPEECHSCの焦点は、プロトコルを、既存または要件の狭窄における内の既存のプロトコルを拡張することで対処できない新しい機能であります
Section 3.2. Where an existing protocol can be gracefully extended to support SPEECHSC requirements, such extensions are acceptable alternatives for meeting the requirements.
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は、（メディアストリームをリダイレクトする、または機能を発見するように）容易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セッション間の転送接続の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オープンプラガブルエッジサービス（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
セッション及びRTPチャネル間のNマッピング：SPEECHSCフレームワークは、1を許可する必要があります。メディアリソース上の異なる要素によって処理される場合、例えば、単一のセッションはTTS、ASRの着信の発信RTPチャネル、およびSI / SV（例えば、のために異なる着信を含んでいてもよいです
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".
素子）。注意：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のいくつかの相互作用の様式は、不都合な、または無効なユーザーのために、単純に不適切であることを認識していることも重要です。聴覚障害者は、限られたユーティリティのTTSを見つけることができます。音声障害のあるユーザーは、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フレームワークは、RTPストリームに音声などのテキストを再生するTTSサーバを要求するために、制御プロトコルを使用して、メディア処理エンティティまたはApplication Serverを許容しなければなりません。
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]基本を<話す>、およびその他の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フレームワークは、すべてのサーバーがRTP接続を介して読み取るためのSPEECHSC接続を介してテキストを受け入れTTSを前提としています。フレームワークは、サーバのいずれか（プロトコルに埋め込まれた）「値で」または「参照によって」（例えば、プロトコルに埋め込まれたデ参照のURI（Uniform Resource Identifier）により）テキストを受け付けることができる前提。
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、等）からシンクMAY。
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.
SPEECHSCフレームワークはSPEECHSC処理からメディア出力をストリーミング再生を制御するための「VCRコントロール」をサポートしなければならない、そのようなコントロールを収容するために変化させる機能を持つサーバーを可能にしなければなりません。プロトコルは、クライアントが使用したい制御するもので述べることを許可する必要があり、そしてサーバーに対して、彼らは名誉どれ報告します。これらの機能は次のとおりです。特定のマーカーの場所にタイムジャンプする能力oを。 O能力は、時間の所定量だけ前方または後方に、時間的にジャンプします。有効な時間単位は秒、単語、段落、文、およびマーカーを含まなければなりません。再生速度を増減させる能力、O。 O能力は早送りすると、サーバーが時間内に前後に移動すると、オーディオの断片が再生された音声を、高速巻き戻し。 O能力が一時停止と再生を再開します。再生音量を増減させる能力、O。
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フレームワークはSPEECHSC以上の結果を返し、RTPストリーム上で自動音声認識を実行するためにASRサーバを要求するメディア処理エンティティまたはApplication Serverを許容しなければなりません。
The SPEECHSC framework assumes that all ASR servers support the VoiceXML speech recognition grammar specification (SRGS) for speech recognition [2].
SPEECHSCフレームワークは、すべてのASRサーバが音声認識のためのVoiceXML音声認識文法仕様（SRGS）をサポートすることを前提としていた[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フレームワークはSPEECHSC上で結果を返し、RTPストリーム上で話者の識別や検証を実行するためにSI / SVサーバーを要求するメディア処理エンティティを許容しなければなりません。
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フレームワークは、各検証リソースの識別子を収容し、声紋フォーマット及び内容はベンダ固有であるため、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タイムスタンプに対応する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つの非常に重要な要件は、相互作用の品質のユーザーの認識が音声でプロンプトまたはレンダリングされたTTSを中断し、ユーザの能力に強く依存していることです。中断、または割り込む、音声出力は、ユーザの方向からエネルギー検出以上のものが必要。多くの先進的なシステムは、例えば、咳とは対照的に、発声が、本当の話である可能性が高いかどうかを判断するために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.
その後、ASR、TTS、または話者認識エンジンの入力または出力に作用することができるエンジンの直列Oコンビネーション。コントロールは、その後、他のオーディオ入力と出力処理と自然言語処理を含むように、そのようなエンジンを越えて延びていてもよいです。エンジン間の中間の交流と協調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）オーロラプロジェクトで例示されるようなワーキンググループは、分散型音声認識（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は、非常に多くのファイルを再生するように見えます。 1が話されるテキストにVCRコントロールまたはマーカーを必要とするときRTSPを拡張するための有望に見えます。一つは、VCRコントロールを必要としない場合、そのようなネットワークアナウンスとして枠組みにおけるSIP [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は、特性の完全に異なるセットを有します。バージ・インのサポートについては、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プロトコル自体を確保するプロトコルを実行するサーバーを実装し、展開、およびセキュリティ機能を提供するための技術の利用が適切であることを保証します。以下のサブセクションで説明してこれらの側面のそれぞれ。これらの考慮事項の一部であるが、厳密には、プロトコル自体のスコープ外に、彼らは慎重に検討して収容されたプロトコルの設計の際、およびプロトコル仕様（複数可）を伴う適用文の一部として呼び出されますされます。プライバシーの配慮も同様に説明されています。
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
すべての場合においてSPEECHSCプロトコルMUSTは認証、許可、および整合性をサポートし、機密性をサポートする必要があります。プライバシーに敏感なアプリケーションでは、プロトコルは、機密性をサポートしなければなりません。我々は、むしろSPEECHSC自体にプロトコル固有のセキュリティメカニズムを提供するよりも、得られたプロトコルが含むプロトコルまたはそれが実行されているトランスポートのいずれかのセキュリティ機構を使用することを想定します。たとえば、私たちは、このような制御チャネルを確保するためのトランスポート層セキュリティ（TLS）を使用するなどの解決策を検討し、リアルタイム交通を確保します
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.
メディアチャネルを確保するためのプロトコル（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クライアントとサーバは話さ形式にしてから、データとその変換の機密性と整合性を確保するための措置をとる必要があります。これらの一般的な考慮事項に加えて、このような話者照合や識別などの特定のSPEECHSC機能は、そのプライバシー、機密性、および完全性を維持しなければならない声紋を採用。ユーザ発話が記録され、明らかに又は不適切に再生することができるいずれかのために同様に、分析およびチューニングのためのインプットキャプチャをサポートするための要件は、プライバシーの脆弱性を表すことができます。実装は、声紋が由来し得る任意集中声紋データベースおよび記録物の悪用を防ぐために注意しなければなりません。これらの脅威を最小限に抑えるために推奨されている特定のアクションは、次のとおりです。
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.
このデータの不適切な開示はない、この文書の日付の時点で行い、将来的に悪用可能な脅威を表しますが、非常に可能性があります。実現可能になるかもしれない特定の脆弱性は、次のサブセクションで説明されています。このような声紋データベースを暗号化し、唯一の十分な権限付与機械を強制プログラミングインターフェイスを介してアクセスを許可するなどの対策を取ることが賢明です。
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:
どちらの話者の識別や検証は認証技術として直接使用することができます。承認の決定は、アクセス制御リストや他のIDベースの認証メカニズムを使用してチャレンジ・レスポンス・プロトコルを通じて直接的な方法で話者検証と相まって、または間接的に話者識別とすることができます。これを採用する場合、クライアントとサーバのプロトコルのセキュリティメカニズムを使用して対処する必要のある追加のセキュリティ上の問題があります。例えば、上記の推奨のように不適切に、適切に制御とデータの両方のチャンネルを確保することは重要で行う、ノイズ注入を介して、偽装、または単純な文字化けに基づいてアクセスを許可または拒否する可能性が話者検証要求のメディアストリームを操作する能力。認証のための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盗難は、バイオメトリクス認証技術として、話者識別/検証の使用に対する将来の脅威を表します。もっともらしい攻撃ベクトル（現実的ではない、今日は）声紋を一致させるために十分正確にユーザーの声を模倣することができ、テキスト音声合成システムにパラメトリック入力として声紋情報を使用することです。それはこっそり音声サンプルの合理的に大規模なコーパスを記録することは非常に難しいことではありませんので、この攻撃への入力のための声紋を構築する能力も、非常に脆弱高度なチャレンジ・レスポンス技術を用いて、音声ベースの生体認証のセキュリティをレンダリングします。認証のための話者照合のユーザーは、このような将来の脆弱性（他の認証技術のユーザーとして多くが非対称キーシステムを破る方法として、ファクタリングの進歩を監視する必要があります）のために密接にこの分野での技術開発を監視する必要があります。 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]ウォーカー、M.、バーネット、D.、およびA. Huntの、 "音声合成マークアップ言語（SSML）バージョン1.0"、W3C REC-REC音声合成-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.ハント、 "音声認識文法仕様バージョン1.0"、W3C REC REC-音声文法-20040316、2004年3月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[4]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのための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]チャールトン、N.、Gasson、M.、Gybels、G.、スパナ、M.、およびA.バンWijk、「セッション開始プロトコル（SIP）のためのユーザ要件ろう、難聴や音声のサポートに-impaired個人」、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[7] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[7]アンドレア、F.およびB.フォスター、 "メディアゲートウェイコントロールプロトコル（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]グローブ、C.、パンタレオ、M.、エリクソン、LM。、アンダーソン、T.、およびT.テイラー、 "ゲートウェイ制御プロトコルバージョン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.とラオと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.、モナコ、P.、およびB. Eberman、 "MRCP：メディアリソース制御プロトコル" が進行中で働いています。
[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]ワールド・ワイド・ウェブ・コンソーシアム、 "ボイス拡張マークアップ言語（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]バーガー、E.編、ヴァン・ダイク、J.、およびA.スピッツァー、 "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]ガットマン、E.、パーキンス、C.、Veizades、J.、およびM.日、 "サービスロケーションプロトコル、バージョン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のSRV）サービスの位置を特定するためのDNS RR"、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）、2003年、<のhttp：//www.nap。 EDU /カタログ/ 10656.html />。
Author's Address
著者のアドレス
David R. Oran Cisco Systems, Inc. 7 Ladyslipper Lane Acton, MA USA
デヴィッド・R.オランシスコシステムズ、株式会社7 Ladyslipperレーンアクトン、MA USA
EMail: oran@cisco.com
メールアドレス：oran@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。