JP2006279102A - 通話システム - Google Patents

Abstract

【課題】 通話品質維持の機能、ＣＴＩの機能、監督者による音声傍受の機能を容易に実現できるＩＰ電話ソフトウェア及びシステムを実現する。
【解決手段】
ＰＣ上で動作するソフトウェア電話３００と、ＰＣに接続されるハードウェアのＩＰ電話機４００とを併用し、ＰＣ上のソフトウェア電話でＳＩＰの制御を行って発信、着信の制御を行い、音声の通話はＩＰ電話機４００で行うことにより、ＰＣ上のアプリケーション５００で、電話の発信、着信、保留、転送などの第１者呼制御を全て制御できるようにすると共に、音声のＩＰパケット送受信処理がＰＣのＣＰＵ負荷に影響されないようするＩＰ電話システムである。
【選択図】 図１

Description

本発明は、コンピュータ上で動作するソフトウェア電話を用いた通話システムに関し、例えば、パーソナルコンピュータ（以下、「ＰＣ」とする）からソフトウェアとして実現されるインターネットプロトコル（以下、インターネットプロトコルを「ＩＰ」とする）電話の機能をリモート制御するためのコールセンタ向けソフトウェア電話に関する。

近年、ＰＣを使用したＩＰ電話が登場しているが、「ＭＳ Ｗｉｎｄｏｗｓ（登録商標）」又は「Ｌｉｎｕｘ（登録商標）」など、リアルタイム制御機能を持たないオペレーティングシステム（以下、「ＯＳ」とする）が搭載されているＰＣでは、このようなＯＳ上で動作するＩＰ電話は、ＯＳのバックグラウンド処理あるいは他のアプリケーションの処理の負荷によっては、通話の音質に影響を与えることがある。そのため、ＩＰ電話を安定的に動作させるのが難しいという問題がある。
一方、ＰＣとは独立して配備される専用の電話機を用いたＩＰ電話の場合、ＰＣのアプリケーションからの制御で電話機の発信、切断、応答などの制御、あるいは、着信時の発信者情報の取得を行うためには、独自の連携機能（ＣＴＩ）を実現する必要がある。しかし、このようなＣＴＩでは、機能上の制限が多く、ＰＣのアプリケーション側から自由に制御することが難しいという問題がある。

上記のＩＰ電話では、いずれもコールセンタ機能が必要となる。コールセンタ機能は、電話オペレータと顧客との通話を所定の監視者が監視し、必要に応じてその会話を傍受し、電話オペレータの支援を行う機能である。このようなコールセンタ機能を実現する場合において、ＩＰ電話機を接続するためのネットワークがスイッチングＨＵＢを含む場合、ネットワーク上を流れる音声を傍受するためには、モニタポート付きのスイッチングＨＵＢを用意し、音声の傍受を行うためのサーバ装置を接続する必要がある。そのため、高価なシステムが必要となる。そして、監視しようとする対象の電話オペレータの端末台数が増えれば増えるほど、音声傍受のための機器が大規模になり、ネットワーク上の制限が発生するという問題がある。

音声をＬＡＮ機器上で傍受するのではなく、電話オペレータと顧客のＩＰによる通話路を、音声傍受用の機器を経由して接続し、監督者は音声傍受専用の機器に通話を接続し、ここから出力される音声を聞く方式では、音声傍受を常時可能にするためには、電話オペレータと顧客との通話を全てこの音声傍受用機器を経由して接続する必要があり、音声傍受用機器の規模が大規模となって高価になると共に、音声を分散して伝送できるというＩＰ電話のメリットをなくしてしまう。
電話オペレータと顧客との通話は、通常は音声傍受用装置を経由せず、傍受を行う時だけ逐次音声傍受装置に接続換えを行うことで、音声傍受装置を大規模にする必要がなくなるが、通話路の切替には若干の時間がかかり、通話の瞬断が発生するため、会話に支障をきたすという問題があった。
コールセンタに於いては、企業と顧客との会話を音声データで記録し、交渉内容を保全する目的で、全ての通話を録音する機能が必要になる場合があるが、音声傍受と同様に通話録音を行うための仕組みが大規模になり、ネットワーク上の制約が生じる。

電話装置によっては、同時に複数本の通話を制御でき、この通話を中継する機能を持ち、アプリケーションから制御可能なものもある。このような電話装置を利用すると、片方の通話をＰＢＸ経由でＩＰ電話機へ接続し、他方の通話を同じくＰＢＸ経由で発信先に接続し、それぞれの音声パスを中継することにより、このアプリケーションからの発信、着信制御が可能になる。この場合、ＩＰ電話への発信は、電話制御装置が電話機を遠隔利用するために接続したもので、他方の通話が実際の発信通話であるが、ＰＢＸとしては２本の通話があったと認識される。このため、ＰＢＸの通話ログでは遠隔操作のための発信と、通常の発信との区別がつかない。実際の発信履歴を把握するためには、発信制御を行った電話機から発信履歴を出力する必要があり、ＰＢＸでの監視機能やログ出力機能が役に立たない場合がある。

テレフォンバンキングなどのコールセンタにおける顧客と電話オペレータとの通話中に、相手から暗証番号を通知する手段として、口頭で番号を読み上げることは、顧客の周囲に聞こえてしまうこと、及び、オペレータが知ってしまうことから、種々の不都合が生じる。そのため、通常は、電話機のプッシュボタンを押すことで暗証番号を電話システムに入力するような仕組みが必要である。従来の電話システムでは、この機能を実現するために、通話中に通話を別途用意された自動応答装置に一旦転送し、そこで暗証番号を取得した後、再度元の電話オペレータに転送するという仕組みを構築することにより実現していた。この仕組みを実現するためには、自動応答装置を含めた電話システム全体が完全に統合されている必要がある。また、利用頻度に応じた分だけ適切な回線数を用意すること、さらには、自動応答装置が応対中に元の電話オペレータが別の通話に入ってしまい、自動応答装置からの通話を元に戻せなくなることがないよう配慮する必要がある。そのため、大掛かりで高度な電話システムの構築が必要であった。端末主導の分散制御を基本としたＩＰ電話による通話のセッション管理を行う環境では、集中制御によるシステム統合を行うようなこれらの機能をＩＰ電話に置き換えることが難しく、さらに高度なシステム構築が必要となり、ＩＰ化によってかえって構築コストが高くなる問題があった。

以上のとおり、コールセンタでＩＰ電話を利用する場合、従来のＰＢＸシステムで実現していたコールセンタで必要とされていた、通話品質維持の機能、ＣＴＩの機能、監督者による音声傍受の機能などについて、ＩＰ電話環境で実現するためには解決しなければいけない問題点が多く、ＩＰ電話のメリットを活かせないばかりか、かえって高価なシステムになることが多かった。

本発明は、上記の課題を解決することができるＩＰ電話の仕組みを提供することを主たる課題とする。

本発明によれば、コンピュータ上で動作するソフトウェア電話と、前記コンピュータの制御のもとでＳＩＰ環境で動作するハードウェア電話機とを備えており、ソフトウエア電話は、前記ハードウエア電話機のＳＩＰの制御を行うことにより発信、着信、保留、転送を含む第１者呼制御を行うものであり、前記ハードウエア電話機は、音声のＩＰパケット送受信処理を前記コンピュータのＣＰＵ負荷とは独立に行うものである、通話システムが構成される。
また、前記ソフトウエア電話は、通話の音声情報をハードウエア電話機の受話器からアナログ電気信号で取り出し、前記コンピュータのマイク入力で取得した音声データをＳＩＰ手順で通話者が通話可能なハードウエア電話機に接続して会話の傍受機能を実現する、構成とすることもできる。
また、前記ソフトウエア電話は、通話の音声情報をハードウエア電話機の受話器からアナログ電気信号で取り出し、前記コンピュータのマイク入力で取得した音声データをデータファイルに蓄積する通話録音機能を実現するものであり、ハードウエア電話機と連携することによって通話の開始及び終了のタイミング情報と、発信先の電話番号及び着信元の発信者情報等とを取得する、構成としてもよい。
また、前記ソフトウエア電話は、ハードウエア電話機との間で行う呼の接続制御を、ＳＩＰの内線発信、着信制御と区別ができるよう、ハードウエア電話機を利用するために発信する場合に、内線番号の前に特番を付加して発信し、所定のＳＩＰサーバに前記特番を解釈させ、通話の管理と履歴データの識別を可能にする、構成としてもよい。
更に、前記ソフトウエア電話は、ハードウエア電話機によるオペレータと顧客との会話を、受話器のピックアップからコンピュータのマイク入力に接続し、この音声を解析することにより、顧客が送信した電話機のプッシュボタンによるＤＴＭＦを判定し、ＰＣ上で連携するアプリケーションに渡すことを可能にする、構成としてもよい。

本発明の一形態においては、コンピュータ上のソフトウェア電話に着信があった場合、発信先が指定した音声セッション情報＝セッション・ディスクリプション・プロトコル（ＳＤＰ）を付加してＩＰ電話機を呼出し、これに対する応答で受け取ったＳＤＰで発信元に応答を行うことで、着信に対してコンピュータ上のソフトウェア電話で直接応答したことになり、ＲＴＰの音声パスは、ＩＰ電話機に接続される。
ソフトウェア電話から発信する際は、まず、ＩＰ電話機を呼出し、ＩＰ電話機からの応答に付加されたＳＤＰを指定して発信先の呼出しを行う。発信先から応答が返ってきた場合、応答情報に発信先のＳＤＰが指定されているため、これを、ＩＰ電話機に通知し、音声セッションの張替え（Ｒｅ：ＩＮＶＩＴＥ）を行うことで、発信先との音声パスはＰ電話機と接続される。これで通話の制御はコンピュータ上のソフトウェア電話で直接行いつつ、音声の送受信は、ＩＰ電話機が行っている状態になる。
着信情報をコンピュータ自身で受け取った上で、音声通話はＩＰ電話機で行う。ＩＰ電話機に着信した情報を見に行くような遠隔操作ではなく、コンピュータ上のソフトウェア電話が直接発信、着信を行い、音声パスのみがコンピュータ横のＩＰ電話機に接続されているため、着信の際のダイヤルイン情報や発信者ＩＤ、ディスプレイ情報、発信の際の発信先ダイヤル番号など第一者呼制御に関する情報は、全てコンピュータ上のソフトウェア電話が把握しており、着信時のスクリーンポップや、発信、保留、転送、切断などの操作をコンピュータアプリケーションと密接に連携して行うことができる。
通話相手に送信する音声のＲＴＰパケットへの変換、および通話先から受信したＲＴＰパケットを音声に再生する処理はコンピュータ横のＩＰ電話機が行うため、コンピュータのＣＰＵ負荷が高くなったときや、コンピュータに障害が発生した場合も、通話品質に影響を受けることはない。

コンピュータ上のソフトウェア電話としては、音声パケットの処理についても通常は十分な処理能力を持っているため、これを活用して監督者への音声情報の提供が可能になる。コンピュータ横のＩＰ電話機と通話相手の会話をＩＰで傍受するためには特殊な傍受機能が必要であるが、コンピュータ横のＩＰ電話機の受話器にアナログ電気信号で分岐を行う装置（テレフォンピックアップ）を挿入し、この電気信号をコンピュータのマイク入力に接続することにより、コンピュータでその会話を取得することができ、ここで会話を録音して通話内容の保全のための機能を提供することができる。また、通話中にＳＩＰ（Session Initiation Protocol)端末を使用している監督者に別セッションとして発信し、この会話の内容をＲＴＰパケットに変換して監督者に聞かせることにより、監督者がオペレータと顧客の会話の傍受することができ、オペレータの支援や教育のための監督を行うことができる。この場合の音声信号はコンピュータのＣＰＵ負荷に影響を受けるため、一時的に音が途切れるなどの問題が発生する可能性はあるが、オペレータと顧客との会話よりも品質を維持する必要性は高くないため、問題になる可能性は低い。オペレータと監督者の接続は、監督者主導でオペレータが感知しない状態で行うこともできる。監督者主導で通話傍受を行っている最中に、監督者からオペレータに対して文字メッセージでこのことを伝えることができる。

オペレータと顧客が会話し、監督者がこの通話を傍受している状態で、コンピュータ上のソフトウェア電話の操作により「接続先切替」を行うと、オペレータと顧客の通話を保留し、顧客に保留音を聞かせた上で、オペレータと監督者が通話をおこなうことができる。再度「接続先切替」を行うと、通話が元に戻る。また、「転送実行」の操作を行うと、顧客との通話が監督者に転送され、オペレータが通話から開放される。この「接続先切替」「転送実行」の操作は、オペレータと監督者のソフトウェア電話同士でＳＩＰのメッセージ転送機能を利用し、監督者側から遠隔操作で行うことができる。

オペレータと顧客との会話は、受話器のピックアップからコンピュータのマイク入力に接続されて録音され、通話に関する情報（開始時間、終了時間、通話相手の発信先電話番号、発信者ＩＤなど）との結びつけを行い、音声情報を保管するサーバに転送される。この際、通話が終了した時点で一旦ローカルファイルに生データで保存し、圧縮した形式のＷＡＶファイルに変換してからサーバに転送する。全通話録音のため音声の録音から圧縮、保管までを専用のサーバで行う方式に較べ、個々のコンピュータが分散して録音、圧縮処理を行うため、端末数が増えた場合でもサーバの負荷が増大することがなく、安価に大規模対応することができる。
通話録音に関しては、従来からコンピュータに録音する方式の装置が出ているが、コンピュータ側の電話制御機能がＣＴＩ機能で実現されていたのに較べ、本方式ではソフトウェア電話そのものであるため、ＣＴＩよりも密接な連携が可能になる。

コンピュータ上のソフトウェア電話と、通常はコンピュータ横に配置されるＩＰ電話機との間で行う呼の接続制御は、通常のＳＩＰの内線発信、着信制御と区別がつかないが、コンピュータ上のソフトウェア電話からＩＰ電話機を利用するために発信する場合、相手の内線番号を直接指定して発信するのではなく、内線番号の前に、通常の内線発信と区別するための特番を付加して発信することで、通話のログ上も区別して出力すると共に、リアルタイムステータスでも区別し、リアルタイムな集計表示、および履歴の集計で区別することができるようにする。

コンピュータ上のソフトウェア電話では、オペレータと顧客との会話が、受話器のピックアップからコンピュータのマイク入力に接続されて録音されているため、音声を解析する機能を持つことが出来る。コンピュータで受信している音声信号は、通話中は通常音声ファイルへの録音処理を行っているのみであるが、オペレータの操作によりアプリケーションからの指示を受けると、その音声信号をリアルタイムに解析し、顧客が送信した電話機のプッシュボタンによるＤＴＭＦを判定し、指示を行ったアプリケーションに返すことができる。ＤＴＭＦの取得完了後は通常の会話の録音のみの処理に戻ることで、コンピュータのＣＰＵ負荷を減らす。この方法により、顧客との通話中のＤＴＭＦの取得を各端末での処理に分散することが出来、端末側のアプリケーションが、直接接続されているソフトウェア電話との連携のみで直接情報の取得ができるようになる。システム全体を統合する必要のあった従来の方法と比較して、分散された端末内のアプリケーションとソフトウェア電話とが直接連携することで実現できるため、容易にに実現できる上、必要なリソースの過不足を考慮する必要がなく、効率的なシステム構築が可能になる。

以上のように、本発明では、端末であるソフトウェア電話自身でも交換機能を持つので、端末自身が発信、着信する際の音声の接続制御を、別の端末にプロキシしてそのような制御を行わせる。
このように、本発明では、交換機能を端末に分散し、各端末が独自に他の端末に接続先を変えている。
従来知られている、音声をコンピュータ同士でピア・ツー・ピアで接続するための交換サーバ技術においては、「どの端末をどの端末と接続する」という情報の配信は、センターで集中的に行っている。従って、このような従来技術では、基本的には「交換制御を集中し、音声接続の制御は端末に分散して端末同士で行う」というIP電話の考え方を実現した形態となっている。
従って、本発明においては、「端末自身でも交換機能を持つ」という点において、このような従来技術とは異なるものとなっている。

以下、図面を参照して本発明の一実施形態を説明する。なお、各図において、同一部には同一の符号を付した。
図１（ａ）は、本発明に係るソフトウェア電話を用いたＩＰ電話システムの構成の全体を示す機能説明図である。図１（ａ）において、ＳＩＰサーバ１００には、公衆交換電話網ゲートウェイ（ＰＳＴＮＧＷ）[あるいはインターネット電話サービスプロバイダゲートウェイ（ＩＴＳＰＧＷ）]２００、ソフトウェア電話３００、ＩＰ電話機４００がそれぞれ接続されている。また、ソフトウェア電話３００は、アプリケーション５００に接続されている。
ソフトウェア電話３００は、ＳＩＰサーバ１００に対しては、ＳＩＰサーバ１００の端末として動作する一方で、自分が使用する呼を外部のＳＩＰ端末にプロキシし、実際にはＩＰ電話機４００がこの呼を受けるようにする。従って、ＳＩＰサーバ１００は、ソフトウェア電話３００が端末として認識されるが、実際の通話は、ソフトウェア電話３００からプロキシされたＩＰ電話機４００を通じてなされる。
従って、この実施形態では、ＰＢＸのプロキシ機能が分散配置され（本実施形態ではＰＣ（パーソナルコンピュータ）のデスクトップであるが、分散配置されるのであれば、特にＰＣやデスクトップである必要はなく、専用端末やその他のコンピュータに分散配置してもよい）、ソフトウェア電話３００が端末でありながら、裏で他のＳＩＰ端末に呼を転送して外部のＳＩＰ端末をコントロールする構成となっている。従って、ＰＢＸにプロキシ機能が集中している構成に比較して、このようにプロキシ機能が分散配置されるので、負荷が大きくなっても、負荷が一極集中するのではなく、分散されることから、負荷が大きくなることによる影響を小さく抑えることができ、通話品質を維持しやすくなっている。

ソフトウェア電話３００は、セッション部３１０、メイン部３２０と、インタフェース部３３０と、ＧＵＩ部３４０と、をそれぞれ備え、セッション部３１０には、図１（ａ）に示されるように、ＳＩＰ−ＵＡ（ＳＩＰユーザエージェント）３１１、３１２，３１３という３つのセッションが含まれる。そのうち二つは、従来のＳＩＰ端末と同様に発着信用セッション、転送用セッションであり、残りの一つが、呼を別のＳＩＰ端末にプロキシするためのリモート接続用セッションとなっている。これらのセッションは、メイン部３２０によりその動作が制御され、このメイン部３２０は、インタフェース部３３０を通じて、アプリケーション５００とＣＴＩ（Computer Telephony Integration）によりデータやコマンドの入出力を行う構成となっている。また、インタフェース部３３０は、ＧＵＩ３４０を通じて、ユーザからのコマンドを受け付けることができるようになっている。

本実施形態に係るＩＰ電話システムの概略図を図２に示す。ソフトウェア電話３００は、ＳＩＰサーバ１００、レジスタサーバ１１０に接続され、これらＳＩＰサーバ１００及びレジスタサーバ１１０は呼制御サーバ１２０に接続される。また、メディアサーバ１３０（ＩＶＲ、ＡＣＤ）は、ＳＩＰサーバ１００に接続される。また、設定テーブル及び状態テーブルのデータベースＤＢ１が呼制御サーバ１２０及びメディアサーバ１３０からアクセス可能に設けられ、プレゼンス参照ルーティング用のデータベースＤＢ２が呼び制御サーバ１２０、メディアサーバ１３０、プレゼンスサーバ５２０からそれぞれアクセス可能に設けられている。
また、ソフトウェア電話３００は、SIP Phoneの遠隔制御により、アプリケーションからの第一者呼制御を実現する。更に、ソフトウェア電話３００は、アプリケーション５００に接続され、ＣＴＩコマンド・レスポンス・イベントにより、呼制御で発信、切断、応答、保留、再接続、コンサルト転送、接続先切替、転送中止、転送実行、リモート接続開始／中止、イベントで内線状態通知発信、着信、通話開始、空き、保留、被保留、その他DTMF取得を行う。
ソフトウェア電話３００は、リモートフォン管理サーバ５１０と接続され、プレゼンスクライアン（ブラウザ）により、プレゼンスサーバ５２０との間で、ログイン（電話番号、ID、パスワード）、ログアウト、ACDエージェントステータス（受信可、後処理、離席）、スキル登録（スキルID、スキルレベル、希望レベル）、理由コード（外出、会議中、等）、コンタクト手段（電話可否、メール可否、ショートメッセージ可否等）等がなされる。

図３に、ソフトウェア電話３００の接続構成の説明図を示す。なお、ソフトウェア電話３００は、専用の内線番号を持つが、単体で通話を行うことはなく、IP電話機や他のSIP端末とセットにして使用する。
このように、050からはじまるIP電話をリモートフォンの接続先として利用すれば、リモートフォンの利用者がインターネットVPN等により社外からセンターのSIPサーバに接続している場合でも、音声信号（RTP)はVoIP網を通ってGWに接続されるため、音声の通話品質はインターネットの負荷変動に影響を受けることはない。

図４に、このＩＰ電話システムにおける着信時の動作概要説明図を示す。この例では、ソフトウェア電話３００には内線５００１が割り当てられ、ソフトウェア電話３００からは、内線２０１が割り当てられたＳＩＰ端末に、呼がプロキシされるものとした。また、動作の流れを明確化するため、着信、着信通知等のイベントの発生順を図中において（１）、（２）で示す。

公衆交換電話網（ＰＳＴＮ）から公衆交換電話網ゲートウェイ（ＰＳＴＮＧＷ）の着信では、（１）IncomingがＰＳＴＮＧＷに通知される。
これを受けて、ＰＳＴＮＧＷからＳＩＰサーバ１００に着信通知（２）INVITEがなされる。この場合、ゲートウェイの受信ポートはＳＤＰ（Session Description Protocol）で指定される。ＳＩＰサーバ１００は、内線５００１が割り当てられたソフトウェア電話３００に着信の通知（３）INVITEfromＧＷを行なう。
ソフトウェア電話３００は、着信イベント（４）Deliveredをアプリケーション５００に対して通知する。更に、ソフトウェア電話３００は、ＳＩＰサーバ１００に暫定応答（５）Tryingを送信する。ＳＩＰサーバ１００は、ソフトウェア電話３００からの暫定応答（６）Tryingを公衆交換電話網ゲートウェイに中継する。ソフトウェア電話３００では、公衆交換電話網ゲートウェイからの着信で通知されたＳＤＰを指定しての内線２０１の呼び出し（７）INVITE２０１withＳＤＰＧＷがなされる。

ＳＩＰサーバ１００は、内線２０１が割り当てられたＩＰ電話機４００の呼び出し（８）INVITEwithＳＤＰＧＷがなされる。内線２０１が割り当てられたＩＰ電話機４００では、暫定応答と鳴動中通知の返信（９）Trying/ringingを、ＳＩＰサーバ１００に対して行う。ＳＩＰサーバ１００は、内線２０１が割り当てられたＩＰ電話機４００からの暫定応答と鳴動中通知のソフトウェア電話３００への返信（１０）Trying/ringingを行う。ソフトウェア電話３００は、公衆交換電話網ゲートウェイ２００からの着信に対しての（１１）ringingをＳＩＰサーバ１００に送信する。
ＳＩＰサーバ１００は、鳴動中通知を公衆交換電話網ゲートウェイ２００に中継（１２）ringingする。この際、公衆交換電話網ゲートウェイは、公衆交換電話網に対して呼び出し中の通知を行う。
その後、内線２０１が割り当てられたＩＰ電話機４００で、受話器が上げられて（１３）OffHook状態になると、この内線２０１が割り当てられたＩＰ電話機４００から（この際、内線２０１の受信ポートがＳＤＰで指定される）応答通知（１４）OKwithSDP201がＳＩＰサーバ１００に返される。同時に、ソフトウェア電話３００から指定されたＳＤＰ（公衆交換電話網ゲートウェイ２００の受信ポート）にＲＴＰ（Real-time Transport Protocol）で音声が送信される。ソフトウェア電話３００は、内線２０１が割り当てられたＩＰ電話機４００からの応答の受信（１５）OKwithSDP201を行ない、かつ、公衆交換電話網ゲートウェイ２００からの着信に対する応答として、内線２０１が割り当てられたＩＰ電話機４００から指定された受信ポートを指定して公衆交換電話網ゲートウェイ２００に対して応答通知（１６）OKwithSDP201を行う。更に、ソフトウェア電話３００は、通話が確立したというイベント送信（１７）Establishedをアプリケーション５００に対して行う。
ＳＩＰサーバ１００は、ソフトウェア電話３００からの応答通知（１８）OKwithSDP201を公衆交換電話網ゲートウェイ２００へと中継し、公衆交換電話網ゲートウェイ２００では、応答通知で指定された受信ポートにＲＴＰで音声を送信する。これにより、公衆交換電話網ゲートウェイ２００と、内線２０１が割り当てられたＩＰ電話機４００と、の間で、ＲＴＰセッションが双方向で確立（１９）RTP Establishedされる。

図５に、ソフトウェア電話３００の着信時のより詳細な説明図を示す。なお、この図では、簡略化のために、図４におけるＩＰ電話機４００を、単に「内線」と表記する。同様に、公衆交換電話網ゲートウェイ２００をＧＷ、公衆交換電話網をＰＳＴＮ、ソフトウェア電話３００をＲと略記する。
図５（ａ）に示されるように、公衆交換電話網ゲートウェイ２００からソフトウェア電話３００に内線に着信があると、その際のＳＤＰによって内線を呼び出す。その後、図５（ｂ）に示されるように、内線が応答したら、内線のＳＤＰを指定してソフトウェア電話３００から公衆交換電話網ゲートウェイ２００に応答を返す。これにより、通話が確立される。内線側受話器を置かない限りは、内線とソフトウェア電話３００とが接続されたままの状態にする。
確立された通話を切断する場合であって、内線側から切断するか、又はソフトウェア電話３００の操作で切断し、内線をオンフックしなかった場合は、図５（ｃ）に示されるように、内線のＳＤＰをソフトウェア電話３００に切り替え、内線とソフトウェア電話３００とが接続された状態にする。
内線がオンフックした場合、図５（ｄ）に示されるように、次に発信、又は着信するときに再度内線をリングダウンする。以上のように、公衆交換電話網ゲートウェイ２００からＩＰ電話機４００への接続確立、切断が行われる。

次に、図６を参照して、発信時の動作概要を説明する。なお、この場合の発信動作においては、アプリケーション５００から発信指示がソフトウェア電話３００に対してだされ、これを受けて、内線２０１が割り当てられたＩＰ電話機４００と、公衆交換電話網に接続される電話機との間で通信が確立される。
図６において、まず、アプリケーション５００では、ソフトウェア電話３００に対して発信指示（１）MakeCallを送信する。ソフトウェア電話３００は、これを受けて、内線２０１が割り当てられたＩＰ電話機４００に対しての呼び出しをＳＩＰサーバ１００に通知（２）Inviteする。ＳＩＰサーバ１００は、内線２０１が割り当てられたＩＰ電話機４００の呼びだし（３）Inviteを行う。内線２０１が割り当てられたＩＰ電話機４００では、暫定応答と鳴動中通知（４）Trying/RingingをＳＩＰサーバ１００に対して返信する。ＳＩＰサーバ１００は、受信した暫定応答と鳴動中通知をソフトウェア電話３００に中継（５）Trying/Ringingする。

その後、内線２０１が割り当てられたＩＰ電話機４００で、受話器が上げられて（６）OffHook状態になると、この内線２０１が割り当てられたＩＰ電話機４００から（この際、内線２０１の受信ポートがＳＤＰで指定される）応答通知（７）OKwithSDP201がＳＩＰサーバ１００に返される。ソフトウェア電話３００は、内線２０１が割り当てられたＩＰ電話機４００からの応答の受信（８）OKwithSDP201を行なう。更に、ソフトウェア電話３００は、内線２０１が割り当てられたＩＰ電話機４００から指定されたＳＤＰを付加してＳＩＰサーバ１００への発信指示（９）INVITEGWwithＳＤＰ201を送信する。ソフトウェア電話３００では、アプリケーション５００に対して、発信開始（１０）originatedを通知する。

ＳＩＰサーバ１００は、公衆交換電話網ゲートウェイ２００に対して発信指示（１１）Inviteを行う。公衆交換電話網ゲートウェイ２００は、これに対して暫定応答（１２）Tryingを返信し、一方でこの公衆交換電話網ゲートウェイ２００から公衆交換電話網（外線）に発信（１３）outboundがなされる。
ＳＩＰサーバ１００は、公衆交換電話網ゲートウェイ２００からの暫定応答をリモートフォンに返信（１４）Tryingする。公衆交換電話網ゲートウェイ２００は、外線からの「呼び出し中」を受信すると、公衆交換電話網ゲートウェイ２００の受信ポートをＳＤＰで指定して、ＳＩＰサーバ１００に対して（１５）Ringingの送信を行う。

ソフトウェア電話３００は、公衆交換電話網ゲートウェイ２００からのＳＤＰ付呼び出し（１６）RingingwithSDPGWを受信し、これに応答して、アプリケーション５００に対して発信経過表示（１７）CallProgress(ringing)を通知する。また、ソフトウェア電話３００は、公衆交換電話網ゲートウェイ２００から受信したＳＤＰで内線２０１に対して（１８）Re:InvitewithSDPGWを行う。
内線２０１が割り当てられたＩＰ電話機４００では、ソフトウェア電話３００からのRe:InvitewithSDPGWにより、ＲＴＰの張り替え指示を受け、これに対しての承諾（２０）OKを行う。これにより、内線２０１が割り当てられたＩＰ電話機４００は、ソフトウェア電話３００から指定された公衆交換電話網ゲートウェイ２００のＳＤＰにＲＴＰを張り替えこれにより公衆交換電話網ゲートウェイ２００と、内線２０１が割り当てられたＩＰ電話機４００と、の間でＲＴＰセッションが双方向で確立（２１）ＲＴＰEstablishedされる。その後、内線２０１が割り当てられたＩＰ電話機４００からの承諾（２２）OKがソフトウェア電話３００に中継される。

その後、外線の発信先が応答すると、公衆交換電話網ゲートウェイ２００からＳＩＰサーバ１００に対して応答通知（２３）OKが通知される。
ＳＩＰサーバ１００では、公衆交換電話網ゲートウェイ２００からの応答通知をソフトウェア電話３００に中継（２４）OKする。そして、ソフトウェア電話３００は、接続完了（２５）Establishedをアプリケーション５００に通知する。

図７に、ソフトウェア電話３００の発信時のより詳細な説明図を示す。なお、図５と同様、この図では、簡略化のために図６におけるＩＰ電話機４００を単に「内線」と表記する。同様に、公衆交換電話網ゲートウェイ２００をＧＷ、公衆交換電話網をＰＳＴＮ、ソフトウェア電話３００をＲと略記する。
図７の例では、発信要求（この例ではアプリケーション５００からの発信要求）によってＩＰ電話機４００を公衆交換電話網を介して顧客等の電話機に接続する場合を示す。図７（ａ）に示されるように、ソフトウェア電話３００は、発信要求を受けると、内線を呼び出す。その後、内線が応答したら、図７（ｂ）に示されるように、内線のＳＤＰを指定してソフトウェア電話３００から公衆交換電話網ゲートウェイ２００を呼び出す。また、発信要求元、この場合にはアプリケーション５００、には、発信開始を通知する。
図７（ｃ）に示されるように、公衆交換電話網ゲートウェイ２００からＳＤＰ付セッションプログレスがソフトウェア電話３００に返信されると、ソフトウェア電話３００は、内線の受信ポートをこのＳＤＰにRe:Invitewithし、双方向で通信可能な状態とする。また、ソフトウェア電話３００は、呼び出し中であることをアプリケーション５００に伝える。
図７（ｄ）に示されるように、発信先が応答すると、公衆交換電話網ゲートウェイ２００からソフトウェア電話３００にＯＫの通知がなされ、ソフトウェア電話３００は、アプリケーション５００に対して、相手が応答したことを通知する。

次に、本実施形態に係るソフトウェア電話３００の付加機能を図８を参照して説明する。本実施形態に係るソフトウェア電話３００の付加機能として、通常の通話の発信、保留、転送着信応答機能の他に、一般的なコールセンターで必要とされる各種機能を提供する。以下の例では、ＳＩＰ電話機４００をオペレータが操作し、公衆交換電話網を介して外線を通じて接続が確立された電話機を通じて顧客と通話を行い、かつ、ＳＩＰ電話機４００とは異なるとともにソフトウェア電話３００により転送が可能であるＳＩＰ電話機を通じてスーパーバイザと通話若しくは文字メッセージ送信等を行う例を示す。このような構成により、オペレータが顧客と通話しているときに、そのオペレータでは対処しきれない状況になった場合に、スーパーバイザに対して指示を仰ぐことや、又はオペレータに代えて直接スーパーバイザが顧客と通話すること等が可能となる。

図８に示されるように、ソフトウェア電話３００には、サウンドカード３５０が備えられており、また、録音部３２１、音生成部３２２、管理情報取得及びメッセージ通信部３２３、プレゼンス登録及び参照部３２４がソフト的に又はハードとして備えられている。
ＳＩＰ−ＵＡ３１１〜３１３には、音生成部３２２で生成される保留音、ＲＢＴ、リンガー音等が入力され、それぞれ通話先、スーパーバイザ、ＳＩＰ電話機４００に、これらの保留音等を送ることができる。
一方、ＳＩＰ電話機４００の受話器端子は、話者の音声等の音声信号をピックアップしてソフトウェア電話３００のサウンドカード３５０に入力する構成となっている。

サウンドカード３５０は、受信した音声信号を録音部３２１に送り、録音部３２１では録音を行うことで、通話録音がなされる。この通話録音は、通話開始、終了をトリガとして行われる。この実施形態では、通話開始、終了をトリガとして通話内容をwavファイル形式（変換形式は特に制限はなく、適宜設定して良い）に変換し、通話先情報及びタイムスタンプ等の通話情報と共に管理サーバにＦＴＰ送信して保存する。また、録音部３２１は、ＤＴＭＦ（Dial Tone Multi Frequency）の検出も行なう。これにより、電話機のプッシュボタンを押すことで暗証番号入力が行われた場合、ＳＩＰ電話機４００の受話器からＤＴＭＦをピックアップすることにより、入力された暗証番号を検出することができる。

この実施形態では、公衆交換電話網を通じて接続された顧客（通話先）と、ＳＩＰ電話機４００により通話を行うオペレータと、の通話中に、アプリケーション５００からのリクエストにより、顧客に対して暗証番号入力を依頼し、入力された暗証番号を受信することができる。
この場合、通話中に、通話先をソフトウェア電話３００のＳＩＰからＲＴＰに切り替え、暗証番号入力を促す音声が録音された音声ファイルを再生して顧客に対して暗証番号入力を依頼する。顧客が電話機のプッシュボタンを押して入力したＤＴＭＦを受信して、暗証番号を検出し、検出された番号をアプリケーション５００内の管理サーバ５１０に送信する。その後、通話を元のＳＩＰに戻す。なお、この実施形態では、録音部でＤＴＭＦの検出を行うようにしたが、ＤＴＭＦの検出を独立した機能部で行っても、あるいは他の機能部で行うようにしてもよい。

また、サウンドカード３５０は、ＳＩＰ電話機４００の受話器端子からの音声信号をＳＩＰ−ＵＡ３１２に送ることで、この音声信号をＳＩＰ−ＵＡ３１２からスーパーバイザに送信可能となっている。
管理情報取得及びメッセージ通信部３２３は、アプリケーション５００内の管理サーバ５１０とＳＩＰにより通信して、管理情報取得及びメッセージ通信を行う。また、プレゼンス登録及び参照部３２４は、アプリケーション５００内のプレゼンスサーバ５２０とＳＩＰにより通信してプレゼンス登録、参照を行う。これにより、プレゼンスサーバへのステータス登録機能、例えば、エージェントログイン／ログアウト、受信可能、後処理、離籍、理由表示、スキル設定等を行うことができる。

次に、上記図８の例における転送処理の詳細を図９、図１０に示す。
図９（ａ）は、ソフトウェア電話３００が発着信用のＳＩＰ−ＵＡ３１１によって内線１（オペレータ通話用）のＲＴＰを使用して公衆交換電話網ゲートウェイ２００を介して電話（顧客の通話用）との通話が確立されている状態を示す。この状態から転送を行う場合、図９（ｂ）に示されるように、公衆交換電話網ゲートウェイ２００を保留状態として内線１に保留音を送信する。図示されるように、ソフトウェア電話３００から内線１にはSDP-Rが送られ、一方、公衆交換電話網ゲートウェイ２００にはソフトウェア電話３００から保留Inviteが送られてソフトウェア電話３００と公衆交換電話網ゲートウェイ２００とが切断された状態となる。
図９（ｃ）に示されるように、ソフトウェア電話３００では、転送用のＳＩＰ−ＵＡ３１２で内線１のＳＤＰを指定して内線２に発信しRingingが帰ってきたら内線１にＲＢＴを送出する。公衆交換電話網ゲートウェイ２００は、図９（ｂ）の保留状態のままである。

図１０（ａ）に示されるように、内線２が応答して、内線２をＳＤＰを指定してOKがソフトウェア電話３００に返信されると、ソフトウェア電話３００は、内線２からのＳＤＰで内線１をRe:Inviteし、内線１と内線２が双方向通信できるようにする。公衆交換電話網ゲートウェイ２００は、保留状態のままである。
図１０（ｂ）に示されるように、ソフトウェア電話３００は、内線１に公衆交換電話網ゲートウェイ２００のＳＤＰを送り、公衆交換電話網ゲートウェイ２００にはRe:Inviteを送信する。公衆交換電話網ゲートウェイ２００からOKがソフトウェア電話３００に返信され、また、ソフトウェア電話３００から内線２に保留Inviteが送信されることで、接続先切替の操作が行われる。これにより、内線２は保留状態となる。
図１０（ｃ）に示されるように、転送実行の操作により、公衆交換電話網ゲートウェイ２００を内線２にreferすることで、ソフトウェア電話３００と公衆交換電話網ゲートウェイ２００間のＳＩＰセッションと、ソフトウェア電話３００と内線２間のＳＩＰセッションと、が解放される。一方、公衆交換電話網ゲートウェイ２００にはソフトウェア電話３００からreferが送信され、これにより、公衆交換電話網ゲートウェイ２００と内線２との間で双方向通話が可能となる。
なお、本実施形態では、スーパーバイザとオペレータ間の文字メッセージ送受信を行うこともできる。

一方、通話中のオペレータにスーパーバイザから発信を行ない、オペレータと顧客との会話（スピーカ入力で受信している音声）をモニタするようにしてもよい。この場合、通話先（顧客）と通信を行っているＳＩＰ−ＵＡ３１１、ＳＩＰ−ＵＡ３１３からの通話内容を、スーパーバイサと通信を行うＳＩＰ−ＵＡ３１２を通じて転送開始、終了することで上述のようなモニタを行うことが可能である。
オペレータからスーパーバイザへのヘルプ機能も提供される。ヘルプ機能により、オペレータからメッセージの送信が可能となり、プッシュボタンをキーボード代わりにしたメッセージ入力、または複数の固定文字メッセージから特定のプッシュボタン入力に対応したメッセージの選択がなされ、スーパーバイザにメッセージが送られる。メッセージを受けとったスーパーバイザは、発信元のオペレータのＳＩＰ電話機４００を選択して呼び出すことで、オペレータと顧客との会話（スピーカ入力で受信している音声）をサイレントモニタすることができる。この例では、モニタ中にメッセージを送信し、オペレータの画面に「モニタ中」と表示してスーパーバイザがサポートに入ったことを通知する。この状態で、「接続先切り替え」を行うと、顧客との会話が保留され、スーパーバイザと通話を行うことができる。そのまま「転送実行」を行うと、顧客との通話をスーパーバイザに転送することができる。

スーパーバイザがモニタ中の状態で、オペレータが「接続先切替」の操作を行うと、オペレータと顧客との通話を保留し、スーパーバイザとの通話に切り替わる。再度「接続先切替」の操作を行うことで、元の状態に戻る。そのまま「転送実行」の操作を行うと、顧客の通話がスーパーバイザに転送される。この転送操作は、スーパーバイザからのピックアップ操作としても実行できる。この場合、事前に文字メッセージでオペレータに対して、スーパーバイザへの転送を知らせるようにする。
なお、スーパーバイザとオペレータとの間の通信は以下のように確立される。まず、オペレータが通話中に他の端末から着信があると、ソフトウェア電話３００には新規の着信イベントであることを示すSIPメッセージが到着する。このとき、一般の発信先からの新規着信であれば、現在すでに通話中なのので、このイベントに対して「BUSY」であることを示すメッセージを返信し、相手は話中になり、電話がつながることはない。

この実施形態では、新規着信の着信情報の中に、相手がスーパーバイザであり、通話のモニタを要求することを示す情報が含ませることができるようにし、転送用と同じSIP−UAを使用して新たなSIPセッションでこの着信に対して応答することが可能としている。転送の際は、1つのSIPセッションを保留状態として保持しつつ、転送用SIP−UAで発信するが、この場合、１つのSIPセッションを通話中のままにし、転送用SIP-UAで着信動作を行うことになる。オペレータと顧客の通話は、通話に使用している電話機の受話器にオーディオのテレフォンピックアップを取り付けることで、オペレータの送受話の音声をPCのマイク入力に接続し、リモートフォンの稼動しているPCのマイク入力音声としてPCのソフトウェアで受信することができる。ソフトウェア電話３００では、この音声情報を、転送用SIP-UAで接続した音声セッションに対して送出することで、スーパーバイザに通話モニタの音声が聞こえるようになる。
従って、IPのみで通話のモニタを行おうとすると、LAN上での音声情報を外部から受信するために大掛かりな仕組みが必要になるが電話機とPCをアナログ信号で接続することで、簡単に通話のモニタ音声をPCに取り込み、スーパーバイザに聞かせることができる。

次に、ソフトウェア電話３００への入力を説明する。
ソフトウェア電話３００は、自発的にＳＩＰサーバに対してレジストを行うが、それ以外は外部からの入力により、そのときの状態に応じた動作を行う。入力元は、ＳＩＰメッセージ（rfc3261に従う）、ＧＵＩ、ＣＴＩ（ＧＵＩで発生したイベントと同じものとみなす）である。
なお、本実施形態におけるＧＵＩとＣＴＩからの入力は以下のとおりである。
・リモート接続開始（使用する内線はコンフィグで設定）
・リモート接続中止
・発信（発信先の電話番号を指定する。この例では、発信先電話番号に関して外線、内線の区別はしない）
・切断（発信中止）
・応答（リモート接続中に着信したときのみ有効）
・保留、再接続
・コンサル転送（転送先の電話番号を指定する。この例では、転送先電話番号に関して外線、内線の区別はしない）
・転送中止（コンサル転送中のみ有効）
・転送実行（コンサル転送通話中のみ有効）
・接続先切替（コンサル転送通話中のみ有効）
・文字メッセージ送信（送信先のソフトウェア電話３００の電話番号を指定）
・通話モニタ発信（スーパーバイザからオペレータの送信先のソフトウェア電話番号を指定）
・通話モニタ中止
・ＤＴＭＦ信号取得（接続中のみ有効）

入力元からの入力に対するソフトウェア電話３００における基本発着信時での状態遷移の内容を図１１の状態遷移図に示す。
図１１において、ラインｙより下の状態で内線をオンフックにすると、空状態に戻る。
また、保留、転送、通話モニタ時における状態遷移の内容を図の状態遷移図に示す。なお、図１２中のラインＬの左側の状態で内線をオンフックした場合、内線を呼び出し状態にし、応答したら元の状態に戻すようにする。

本発明に係るＩＰ電話システムの構成の全体を示す機能説明図。 本実施形態に係るＩＰ電話システムの概略図。 ソフトウェア電話３００の接続構成の説明図。 ＩＰ電話システムにおける着信時の動作概要説明図。 ソフトウェア電話３００の着信時のより詳細な説明図。 発信時の動作概要の説明図。 ソフトウェア電話３００の発信時のより詳細な説明図。 本実施形態に係るソフトウェア電話３００の付加機能の説明図。 転送処理の詳細の説明図。 転送処理の詳細の説明図。 ソフトウェア電話３００における基本発着信時での状態遷移図。 ソフトウェア電話３００における保留、転送、通話モニタ時における状態遷移。

符号の説明

１００ ＳＩＰサーバ
１１０ レジスタサーバ
１２０ 呼制御サーバ
１３０ メディアサーバ
２００ 公衆交換電話網ゲートウェイ
３００ ソフトウェア電話
３１０ セッション部
３２０ メイン部
３２１ 録音部
３２２ 音生成部
３２３ 管理情報取得及びメッセージ通信部
３２４ プレゼンス登録及び参照部
３３０ インタフェース部
３４０ ＧＵＩ部
３５０ サウンドカード
４００ ＳＩＰ電話機
５００ アプリケーション
５１０ リモートフォン管理サーバ
５２０ プレゼンスサーバ

Claims (5)

1. コンピュータ上で動作するソフトウェア電話と、前記コンピュータの制御のもとでＳＩＰ環境で動作するハードウェア電話機とを備えており、
   前記ソフトウエア電話は、前記ハードウエア電話機のＳＩＰの制御を行うことにより発信、着信、保留、転送を含む第１者呼制御を行うものであり、
   前記ハードウエア電話機は、音声のＩＰパケット送受信処理を前記コンピュータのＣＰＵ負荷とは独立に行うものである、
   通話システム。
2. 前記ソフトウエア電話は、通話の音声情報をハードウエア電話機の受話器からアナログ電気信号で取り出し、前記コンピュータのマイク入力で取得した音声データをＳＩＰ手順で通話者が通話可能なハードウエア電話機に接続して会話の傍受機能を実現する、
   請求項１記載の通話システム。
3. 前記ソフトウエア電話は、通話の音声情報をハードウエア電話機の受話器からアナログ電気信号で取り出し、前記コンピュータのマイク入力で取得した音声データをデータファイルに蓄積する通話録音機能を実現するものであり、
   ハードウエア電話機と連携することによって通話の開始及び終了のタイミング情報と、発信先の電話番号及び着信元の発信者情報等とを取得する、
   請求項１記載の通話システム。
4. 前記ソフトウエア電話は、ハードウエア電話機との間で行う呼の接続制御を、ＳＩＰの内線発信、着信制御と区別ができるよう、ハードウエア電話機を利用するために発信する場合に、内線番号の前に特番を付加して発信し、所定のＳＩＰサーバに前記特番を解釈させ、通話の管理と履歴データの識別を可能にする、
   請求項１記載の通話システム。
5. 前記ソフトウエア電話は、ハードウエア電話機によるオペレータと顧客との会話を、受話器のピックアップからコンピュータのマイク入力に接続し、この音声を解析することにより、顧客が送信した電話機のプッシュボタンによるＤＴＭＦを判定し、ＰＣ上で連携するアプリケーションに渡すことを可能にする、
   請求項１記載の通話システム。

Images