音声認識APIのWebSocket使用時の仕様（ドキュメント）について

[すやま]

こんにちわ

音声認識APIをWebSocket使用時の仕様（ドキュメント）の記載について、

MIMI ASR WebSocet Service のページ

https://mimi.readme.io/docs/asr-websocket-service

には、あまり仕様が書かれていないようです。

WebSocketで音声認識APIを利用する際の手順は

① HTTPプロトコルで接続しWebSocketのアップグレードを要求する

　この際のHTTPヘッダに Authorizationを付加し認証を受けるのでしょうか？

② WebSocketプロトコルにアップグレード後にWebSocketが開通した後に、

　音源データ（PCM,16kHz,16bito,1ch）はどのようにWebSocketを通じて

　送信すればよいのでしょうか？何かヘッダ付与の様なものが必要なのでしょうか

　それとも、音源データを適度なチャンクに分割して、OPECODEをバイナリー

　で指定して、送付すれば良いだけでしょうか？

　また、１つのチャンク（送信単位）の大きさのバイト数制限はありますでしょうか

③ 音源データのチャンクを送信した後、何か解析を始めるきっかけのデータを

　送付する必要があるのでしょうか？

　それとも、音源チャンクを送付したら、適当なタイミングで解析結果（応答）が

　WebSocketを通じて返されてくるのでしょうか

④ 何かWebSocketに関してのドキュメントはありますでしょうか

何卒よろしくお願いしたします

[吉川哲史]

ご質問ありがとうございます。

①ご認識の通りです。mimi 認証／認可APIにて取得したアクセストークンを 以下のように　Authorizationヘッダに指定します。

Authorization: Bearer

② ご認識のとおりWebSocket仕様(RFC6455)のバイナリフレームとして送信します。1チャンクあたり最大データ長は 64 KiB です。

③　音声データの送信が終了したら、テキストフレームでrecog-breakコマンドを送信することで音声データの終了をサーバーが検知します。

{

"command": "recog-break"

}

④の回答については少々お待ちください。

[すやま]

ご回答ありがとうございます。

①②③で確認いたしました。

無事、WebSocketにて音声認識ができました。

ありがとうございました。

①～③で通信ができていますので、④については急いでいません。

それで、確認いたしましたところ、通信の手順は、

 ① HTTPプロトコル上 Authorization: Bearer xxx で 認証、WebSocketへアップグレード

 ② WebSocketハンドシェイク

 ③ PCM音源チャックをバイナリーフレームで転送（4KBチャンクで送信しました）を繰り返し

 ④ テキストフレームで、{"command": "recog-break"} を送信

 ⑤ 少し開けてサーバー側より音声認識結果が送信されてくる

 ⑥ ★サーバー側よりWebSocketのCLOSEフレーム（OPCODE=0x8）が送信されてくる

となりました。

⑤の結果受信直後に、サーバー側より⑥のCLOSEフレームが送信されてきてしまい

WebSocketのクローズ状態となってしまい、それ以降、同一WebSocketセッションを利用

しての次の音声の塊りの送信を継続することができません。

従って、次の音声を送信するためには、WebSocket切断後、①～再度行わなければなりませんでした。

WebSocket利用の利点(意味)は、

HTTP-RESTでは、一回一回の音声認識の呼び出し事にTCPセッションの構築および認証をしなければならない

（従って、ネットワーク遅延=RTTの影響 や、認証にかかる処理時間で、音声認識完了までの応答時間が長くなってしまう）

が、

WebSocketプロトコルは、一度セッションを開通し、そのセッションを維持し、データのやり取りを継続的に行うことを

目的としたプロトコル（その為、TCPセッション構築や認証が一回のみとなり、応答時間が早くできる）と認識しています。

ただし、今回のWebSocketの利用では、一回の音声認識後にWebSocketがCLOSEされてしまい、

WebSocketの利点が享受できません。

この、CLOSEフレームが送信され、連続して音声認識が１つのセッションで出来ない（仕様？）は、

回避方法（CLOSEフレームが送信されず、WebSocketが維持できる）、もしくは、仕様変更の予定等はありませんでしょうか？

何卒よろしくお願いします。

[吉川哲史]

ただし、今回のWebSocketの利用では、一回の音声認識後にWebSocketがCLOSEされてしまい、

WebSocketの利点が享受できません。

この、CLOSEフレームが送信され、連続して音声認識が１つのセッションで出来ない（仕様？）は、

回避方法（CLOSEフレームが送信されず、WebSocketが維持できる）、もしくは、仕様変更の予定等はありませんでしょうか？

申し訳ありませんが、直近では回避および仕様変更の予定はございません。

ご指摘については、今後の改善に活かしていきたいと思います。 

[すやま]

ご回答、ご検討、ありがとうございます。

承知いたしました。

WebSocketに関しては、認識依頼 ( {"command": "recog-break"} )後も継続して

セッションが維持される方向が使う側は扱いやすい（WebSocketを使う意味がある）と思います。