いただいた質問に答えていると、自分でもとても勉強になるものです。今週はHFP-AGとして使う際の動作について質問を受けたのですが、自分の使っているヘッドセット(MW600)では経験したことのない問題が、使用する機種や設定によっては発生することを確認することができました。
HFP-AGとしての使用例については、もう2年ほど前にこの記事で触れています。MW600を使ううえでは、この設定で何の問題もないのですが、一般的にはこれでは2点ほど設定が足りません。
まずひとつは、statusコマンドによる網側サービスの状態通知です。WT32のHFP-AGが接続された状態では、WT32はHFPユニット側に対して何のネットワーク状態通知も出しません。そのため、ヘッドセットによっては網側サービスは利用できない状態であると解釈し、着呼や発呼の制御を受け付けないようです。この問題を避けるためには、HFP-AGの接続後HFP-AG側で
status service 1
コマンドを実行することで、明示的に網側サービスが利用可能であることをヘッドセット側に通知してやります。
もうひとつの問題は、呼び出し音の制御です。HFP-AG側でringコマンドを実行すると、WT32はすぐにHFPユニット側にSCOリンクを張りにいきます。これはHFP-AG側で生成する呼び出し音をHFPユニット側に送出することを可能とするためです。しかしながら、ユニット側では自分で呼び出し音を生成する機能をもっており、SCOリンクからの呼び出し音を流さないかもしれません。WM600ではそのように動作しました。これは、HFP-AG側が呼び出し音を生成することを明示的にユニット側に通知していないために生じます。呼び出し音送出を明示的に通知するためには、
+BSIR:1
コマンドをHFP-AG側で実行してやります。逆にインバンドでの呼び出し音送出ができない場合には、
+BSIR:0
を送出してやります。実際に+BSIR:1を実行してやるとWM600は自機での呼び出し音生成をしなくなりました。
ちなみにBluegigaのAP Noteでは、この通知は++BSIRとして説明されていますが、間違いです。元資料であるHFP 1.5を確認してみると、そちらでもタイポになっていましたので、そのままコピペしたために間違っているようです。ちなみに、HFP 1.6ではこのタイポは修正されていました。
HFP-AGとしての使用例については、もう2年ほど前にこの記事で触れています。MW600を使ううえでは、この設定で何の問題もないのですが、一般的にはこれでは2点ほど設定が足りません。
まずひとつは、statusコマンドによる網側サービスの状態通知です。WT32のHFP-AGが接続された状態では、WT32はHFPユニット側に対して何のネットワーク状態通知も出しません。そのため、ヘッドセットによっては網側サービスは利用できない状態であると解釈し、着呼や発呼の制御を受け付けないようです。この問題を避けるためには、HFP-AGの接続後HFP-AG側で
status service 1
コマンドを実行することで、明示的に網側サービスが利用可能であることをヘッドセット側に通知してやります。
もうひとつの問題は、呼び出し音の制御です。HFP-AG側でringコマンドを実行すると、WT32はすぐにHFPユニット側にSCOリンクを張りにいきます。これはHFP-AG側で生成する呼び出し音をHFPユニット側に送出することを可能とするためです。しかしながら、ユニット側では自分で呼び出し音を生成する機能をもっており、SCOリンクからの呼び出し音を流さないかもしれません。WM600ではそのように動作しました。これは、HFP-AG側が呼び出し音を生成することを明示的にユニット側に通知していないために生じます。呼び出し音送出を明示的に通知するためには、
+BSIR:1
コマンドをHFP-AG側で実行してやります。逆にインバンドでの呼び出し音送出ができない場合には、
+BSIR:0
を送出してやります。実際に+BSIR:1を実行してやるとWM600は自機での呼び出し音生成をしなくなりました。
ちなみにBluegigaのAP Noteでは、この通知は++BSIRとして説明されていますが、間違いです。元資料であるHFP 1.5を確認してみると、そちらでもタイポになっていましたので、そのままコピペしたために間違っているようです。ちなみに、HFP 1.6ではこのタイポは修正されていました。