JP2012015568A - サーバ装置及びそのｄｔｍｆ通知方法 - Google Patents

Abstract

【課題】通信パケットとＤＴＭＦ信号とをミキシングするための信号処理器を使用することなく、通信品質を悪化させることなくＤＴＭＦ信号を端末に送信し得るサーバ装置を提供する。
【解決手段】呼制御サーバＳＶ１において、通信相手側の呼制御サーバＳＶ２からＲＴＰパケットと別にＩＮＦＯメッセージにより送られるＤＴＭＦ通知イベントを検出した場合に、ＲＴＰパケットのペイロードに入れるＤＴＭＦデータを生成し、呼制御サーバＳＶ２から受信したＲＴＰパケットのペイロードのデータをＤＴＭＦデータに入れ替え、さらにＲＴＰパケットのペイロードタイプをＩＰ電話端末Ｔ１１で使用されるペイロードタイプ［１０２］に書き替えてＩＰ電話端末Ｔ１１に送信する。
【選択図】 図５

Description

本発明の実施形態は、電話端末間における通話中にＤＴＭＦ（Dual Tone Multi Frequency）音を通知するサーバ装置及びこのサーバ装置で用いられるＤＴＭＦ通知方法に関する。

近年、ＩＰ(Internet Protocol)網を介して双方向に画像や音声をＲＴＰ（Real-time Transport Protocol）パケットとして、リアルタイムに送受信するＩＰ電話システムが普及し始めている。このＩＰ電話システムでは、ＩＰ網に接続される各通信サーバごとに内線間通信や外線発着信を行なえることは勿論のこと、ＩＰ網を経由した通信サーバ間での内線通信や外線発着信を行なうことができる。

ところで、上記ＩＰ電話システムにおいても、オートアテンダントやボイスメール装置を使用することが考えられる。オートアテンダントを使用したシステムでは、例えば外線着信が到来した場合に、この外線をオートアテンダントに接続して、このオートアテンダントから外線に対し例えば再配達を希望する日時に対応する番号の入力を促すガイダンスメッセージを送出する。そして、発呼者がダイヤル操作によりＤＴＭＦ信号からなる電話番号を送出すると、オートアテンダントにてこのＤＴＭＦ信号を検出して再配達の受付を可能とするものである。

また、ボイスメール装置を使用したシステムでは、メールボックスに録音された音声メッセージを聴取したい場合に、通信サーバに収容される電話端末のユーザがダイヤル操作によりＤＴＭＦ信号からなる再生要求を送出し、ボイスメール装置にてこのＤＴＭＦ信号を検出してメールボックス中の音声メッセージを再生可能とするものである。

特開２００６−１８６９６２号公報

ところで、上記ＩＰ電話システムでは、ＤＴＭＦ信号をオートアテンダントやボイスメール装置といった端末に出力する場合、通信サーバにて生成したＤＴＭＦ信号を受信したＲＴＰパケットにミキシングして端末に送信しているため、ＤＳＰが必要となり、ＤＳＰリソースの制約で同時使用数が制限されてしまう。また、ＲＦＣ２８３３（ＲＦＣ４７３３）等のＤＴＭＦイベントパケットをＲＴＰパケットに挿入する場合、パケットロス、パケット到着タイミングの遅延等が発生し、ＱＯＳデータが悪くなる。さらに、通信サーバ間で、ペイロードが異なる場合、ＲＦＣ２８３３（ＲＦＣ４７３３）によるパケット通信ができない。

そこで、本発明の目的は、通信パケットとＤＴＭＦ信号とをミキシングするための信号処理器を使用することなく、通信品質を悪化させることなくＤＴＭＦ信号を端末に送信し得るサーバ装置及びそのＤＴＭＦ通知方法を提供することにある。

上記目的を達成するために、実施形態のサーバ装置は、ヘッダ及びペイロードを備える通信パケットを伝送する通信ネットワークに接続され、電話端末を収容するサーバ装置において、電話端末間で複数のサーバ装置間を経由して音声通信を行なっている状態で、通信相手側のサーバ装置から通知されるＤＴＭＦ（Dual Tone Multi Frequency）通知イベントを検出する検出手段と、この検出手段による検出結果に基づいて、受信する通信パケットのヘッダに含まれるペイロードタイプの変更、通信パケットのペイロードのデータをＤＴＭＦデータに入れ替えの少なくとも１つを実行する制御手段とを備えるようにした。

この構成によれば、電話端末間で複数のサーバ装置間を経由して音声通信を行なっている状態で、通信相手側の電話端末にてＤＴＭＦデータを発生する要求操作がなされた場合に、通信相手側のサーバ装置からＤＴＭＦ通知イベントが到来することになるので、このＤＴＭＦ通知イベントを検出することで、受信する通信パケットのヘッダに含まれるペイロードタイプの変更、通信パケットのペイロードのデータをＤＴＭＦデータに入れ替えの少なくとも１つが実行されることになる。

従って、通信パケットのヘッダに含まれるペイロードタイプ、通信パケットのペイロードを利用することで、通信パケットとＤＴＭＦデータとをミキシングするためのＤＳＰを必要とすることなく、ＤＴＭＦイベントパケットを電話端末に送信することができ、これによりＤＳＰリソースによる同時使用数の制限がなくなる。また、通信パケットのペイロードタイプの変更、ペイロードのデータの差し替えであるため、シーケンス番号、タイムスタンプ等がずれず、パケットロス、パケット遅延が発生しないため、通信品質を悪化させなくて済む。

本第１の実施形態に係わるＩＰ電話システムを示す概略構成図。 上記図１に示した呼制御サーバの機能を示すブロック図。 上記図２に示したＤＴＭＦ能力テーブルの記憶内容の一例を示す図。 同第１の実施形態におけるＤＴＭＦ信号を通知する場合のシーケンス図。 同第１の実施形態で取り扱うＲＴＰパケットの構造を示す図。 同第１の実施形態における複数の呼制御サーバを経由したＩＰ電話端末間の通信接続を行なうためのシーケンス図。 本第２の実施形態におけるＤＴＭＦ信号を通知する場合のシーケンス図。 同第２の実施形態で取り扱うＲＴＰパケットの構造を示す図。

以下、本発明の実施形態について図面を参照して詳細に説明する。
（第１の実施形態）
第１の実施形態で取り扱うＤＴＭＦ信号をＩＰ網上で送信する方式として、ＲＦＣ２８３３方式がある。ＲＦＣ２８３３方式はＤＴＭＦ信号をＧ．７２２，Ｇ．７２３、Ｇ．７２８及びＧ．７２９といったコーデックに従って符号化し、この符号化したＤＴＭＦデータをＲＴＰパケットのペイロードに挿入する方式である。ところで、ＩＰ電話システムには、ＲＦＣ２８３３方式をサポートしていないＩＰ電話端末やサーバ装置が存在する。この場合、例えばＲＦＣ２８３３方式をサポートしていないＩＰ電話端末からＲＦＣ２８３３方式をサポートしているＩＰ電話端末へ符号化ＤＴＭＦ情報が送信されるとする。そうすると、受信側のＩＰ電話端末では自分宛の符号化ＤＴＭＦ情報がＲＴＰパケット形式でないため、ＤＴＭＦを認識できない。

そこで、本第１の実施形態は、ＲＦＣ２８３３サポートのサーバ装置に接続されるＩＰ電話端末とＲＦＣ２８３３未サポートのサーバ装置に接続されるＩＰ電話端末との間で音声通信を行なっている状態で、未サポートのＩＰ電話端末からＤＴＭＦ信号を送信した場合に、ＲＦＣ２８３３サポートのサーバ装置で受信した符号化ＤＴＭＦ情報をＲＴＰパケット形式に生成して、宛先のＩＰ電話端末に送信し、宛先のＩＰ電話端末にてＤＴＭＦを再生できるようにしたものである。

図１は、本第１の実施形態に係わるＩＰ電話システムを示す概略構成図である。
このシステムは、通信ネットワークとしてパケット通信用のＩＰ網１を有する。ＩＰ網１には、複数の呼制御サーバＳＶ１〜ＳＶｎ（ｎは自然数）が接続されている。また、呼制御サーバＳＶ１〜ＳＶｎには、ＩＰ電話端末Ｔ１１〜Ｔ１ｉ（ｉは自然数），Ｔ２１〜Ｔ２ｍ（ｍは自然数），Ｔ３１〜Ｔ３ｐ（ｐは自然数），Ｔｎ１〜Ｔｎｋ（ｋは自然数）が接続されている。なお、ＩＰ電話端末Ｔ１１〜Ｔ１ｉ，Ｔ２１〜Ｔ２ｍ，Ｔ３１〜Ｔ３ｐ，Ｔｎ１〜Ｔｎｋは、通話処理機能と映像等のメディア情報処理機能とを備えている。

また、呼制御サーバＳＶ１は、ファイアウォールＦＷ１を介してＩＰ網１に接続される。呼制御サーバＳＶ２は、ファイアウォールＦＷ２を介してＩＰ網１に接続される。さらに、呼制御サーバＳＶ３〜ＳＶｎもそれぞれファイアウォールＦＷ３〜ＦＷｎを介してＩＰ網１に接続される。

また、呼制御サーバＳＶ１には、ゲートウェイＧＷ１が接続される。ゲートウェイＧＷ１は、公衆網ＮＷ１とＩＰ網１との間を接続するもので、公衆網ＮＷ１とＩＰ網１との間における通信プロトコル及び信号フォーマットの変換機能を備えている。

また、呼制御サーバＳＶｎには、ゲートウェイＧＷ２が接続される。ゲートウェイＧＷ２は、公衆網ＮＷ２とＩＰ網１との間を接続するもので、公衆網ＮＷ２とＩＰ網１との間における通信プロトコル及び信号フォーマットの変換機能を備えている。

呼制御サーバＳＶ１〜ＳＶｎは、複数のＩＰ電話端末Ｔ１１〜Ｔ１ｉ，Ｔ２１〜Ｔ２ｍ，Ｔ３１〜Ｔ３ｐ，Ｔｎ１〜Ｔｎｋ間または呼制御サーバＳＶ１〜ＳＶｎ間またはＩＰ電話端末Ｔ１１〜Ｔ１ｉ，Ｔ２１〜Ｔ２ｍ，Ｔ３１〜Ｔ３ｐ，Ｔｎ１〜Ｔｎｋと公衆網ＮＷ１，ＮＷ２との間で、例えばＩＰ−ＱＳＩＧに従ってセッションを確立する交換制御機能を備える。そして、セッション確立後は、発信側と着信側の電話端末間でピアツーピア接続でＲＴＰパケットを送受信することで、音声通信を行なう。

ところで、上記呼制御サーバＳＶ１〜ＳＶｎは、本第１の実施形態に係わる機能として次のような機能を有している。図２はその構成を示すブロック図である。ここでは、呼制御サーバＳＶ１を代表して説明する。

すなわち、呼制御サーバＳＶ１は、ＩＰ制御部１１と、中継処理部１２と、呼制御部１３と、記憶部１４とを備えている。これらＩＰ制御部１１と、中継処理部１２と、呼制御部１３と、記憶部１４は、データハイウェイ１５を介して互いに接続されている。

ＩＰ制御部１１には、ＩＰ網１が必要に応じて接続される。ＩＰ制御部１１は、接続されたＩＰ網１との間でインタフェース処理を行う。また、ＩＰ制御部１１は、上記インタフェース処理に係わる種々の制御情報の授受を、データハイウェイ１５を介して呼制御部１３との間で行う。

中継処理部１２は、ＩＰ制御部１１で受信した制御メッセージ及びＲＴＰパケットを処理する。

呼制御部１３は、ＣＰＵ、ＲＯＭ、ＲＡＭなどを有して構成され、ソフトウェア処理により呼制御サーバＳＶ１の各部の制御を行う。

記憶部１４は、呼制御部１３の接続制御に必要なルーティング情報等を格納している。ルーティング情報は、ＩＰ電話端末Ｔ１１〜Ｔ１ｉ及びゲートウェイＧＷ１に予め割り当てられている識別情報としての電話番号と、固定ネットワークアドレスとしてのＭＡＣ（Media Access Control）アドレスと、可変ネットワークアドレスとしてのＩＰアドレスとを対応付けた情報である。

ところで、記憶部１４には、ＤＴＭＦ能力テーブル１４１が設けられている。ＤＴＭＦ能力テーブル１４１は、図３に示すように、ＩＰ電話端末Ｔ１１〜Ｔ１ｉ及びゲートウェイＧＷ１のＤＴＭＦ信号の送受信能力を管理するためのテーブルで、呼制御サーバＳＶ１に接続されるＩＰ電話端末Ｔ１１〜Ｔ１ｉ及びゲートウェイＧＷ１に予め割り当ててある端末ＩＤとしての端末番号と、ＤＴＭＦ能力と、ＤＴＭＦデータを含めたＲＴＰパケットのヘッダに位置するペイロードタイプとの対応関係を表すテーブルが記憶されている。ＤＴＭＦ能力を示す情報は、ＲＦＣ２８３３方式であるかＩｎｂａｎｄ方式であるかを示す情報である。Ｉｎｂａｎｄ方式は例えばＧ．７１１といったコーデックに従って符号化されたＤＴＭＦデータをＲＴＰパケットのペイロードに挿入する方式である。

なお、呼制御サーバＳＶ１に所属するＩＰ電話端末Ｔ１１〜Ｔ１ｉ及びゲートウェイＧＷ１については、予めＤＴＭＦ能力テーブル１４１にＲＦＣ２８３３であるかＩｎｂａｎｄであるかを示すＤＴＭＦ能力情報と、そのペイロードタイプとを登録しているものとする。

一方、呼制御部１３は、ＤＴＭＦ通知イベント検出部１３１と、ＤＴＭＦデータ生成部１３２と、ペイロード入替部１３３と、ペイロードタイプ更新部１３４とを備えている。ＤＴＭＦ通知イベント検出部１３１は、例えばＩＰ電話端末Ｔ１１と呼制御サーバＳＶ２に収容されるＩＰ電話端末Ｔ２１との間でセッションが確立し、ＲＴＰパケットを送受信している状態で、呼制御サーバＳＶ２から送られてくるＤＴＭＦ通知イベントを検出する。

ＤＴＭＦデータ生成部１３２は、上記ＤＴＭＦ通知イベント検出部１３１にてＩＰ−ＱＳＩＧで規定されるＩＮＦＯメッセージにより送られたＤＴＭＦ通知イベントを検出した場合に、ＩＮＦＯメッセージに含まれダイヤル番号からなるＤＴＭＦデータを生成する。

ペイロード入替部１３３は、上記ＤＴＭＦデータ生成部１３２により生成されたＤＴＭＦデータを例えば呼制御サーバＳＶ２から受信したＲＴＰパケットのペイロードのデータと入れ替える。

ペイロードタイプ更新部１３４は、ＲＴＰパケットのヘッダに位置するペイロードタイプを上記ペイロード入替部１３３により入れ替えたＤＴＭＦデータのペイロードタイプに書き替える。また、ペイロードタイプ更新部１３４は、上記ＤＴＭＦ通知イベント検出部１３１にてＲＴＰパケットのペイロードに含まれるＤＴＭＦデータを検出した場合に、そのＲＴＰパケットのペイロードタイプの書き換えを行なう。

次に、上記構成による動作について説明する。
図４は、ＩＰ電話端末Ｔ２１からＩＰ電話端末Ｔ１１へＤＴＭＦ信号を通知する場合のシーケンスを示すものである。

いま、ＩＰ電話端末Ｔ１１，Ｔ２１間で通信リンクが確立しているものとする。ここでは、例えばＩＰ電話端末Ｔ１１がオートアテンダントで、ＩＰ電話端末Ｔ２１に対しアナウンスメッセージをＲＴＰパケットとして送出するものとする。

なお、アナウンスメッセージの内容は、例えば「はい。こちら○○会社です。再配達を希望の場合はダイヤル［１］を押してください。」が使用される。

この状態で、ＩＰ電話端末Ｔ２１においてユーザがダイヤル［１］を押下したとする（図４（１））。そうするとＩＰ電話端末Ｔ２１はダイヤル［１］に対応するＤＴＭＦ信号をＲＴＰパケットに乗せて呼制御サーバＳＶ２に送信する（図４（２））。

呼制御サーバＳＶ２では、ＤＳＰ等により、ＤＴＭＦ信号を検出し（図４（３））、ＩＰ−ＱｓｉｇのＩＮＦＯメッセージにより、ＤＴＭＦ信号をＩＰ電話端末Ｔ１１に出力するよう呼制御サーバＳＶ１に通知する（図４（４））。

呼制御サーバＳＶ１は、ＩＮＦＯメッセージに従い、ＲＦＣ２８３３で規定されるＤＴＭＦデータを生成する（図４（５））。

呼制御サーバＳＶ１は、呼制御サーバＳＶ２から受信したＲＴＰパケットに対し、図５に示す変換ルールに従い、ペイロードのデータをＤＴＭＦデータに入れ替え、ＲＴＰパケットのヘッダに位置するペイロードタイプをＤＴＭＦデータのペイロードタイプに書き替える（図４（６））。

書き替えられたパケットは、ＩＰ電話端末Ｔ１１に転送される（図４（７））。これにより、ＩＰ電話端末Ｔ１１は、ＲＦＣ２８３３で規定されるＲＴＰパケットを検出し、ＤＴＭＦ信号が通知されたことを認識する。ここでは、例えばＩＰ電話端末Ｔ２１のユーザによる再配達希望の受付を行う。

図５は、ＲＴＰパケットの構造を示すものである。ＲＴＰパケットはヘッダとペイロードとからなる。ヘッダにはパケットの種類を示すバージョン情報、パディングデータの有無を示す情報（Ｐ）、拡張ヘッダの有無を示す情報（Ｘ）、２者通話、３者通話といった通話形態を示す情報（ＣＣ）、マーカの有無を示す情報、ペイロードタイプが含まれる。さらに、ヘッダには、ＲＴＰパケットの送信順位を表すシーケンス番号、ＲＴＰパケットの送信時刻を表すタイムスタンプ、送信元であるＩＰ電話端末Ｔ２１を識別する送信元識別子（ＳＳＲＣ）が備えられる。

ペイロードには、例えばＧ．７２２，Ｇ．７２３、Ｇ．７２９及びＧ．７２９といったコーデックに従って符号化されたデジタル音声データが存在する。

ここで、上記ＩＰ電話端末Ｔ１１，Ｔ２１間で通信リンクを形成する動作について説明する。図６は、上記ＩＰ電話端末Ｔ１１，Ｔ２１間で通信リンクを形成する動作を示すシーケンス図である。

図６に示すように、呼制御サーバＳＶ２に収容されたＩＰ電話端末Ｔ２１にて呼制御サーバＳＶ１に収容されるＩＰ電話端末Ｔ１１への発信操作が行われたとする（図６（１））。そうすると、ＩＰ電話端末Ｔ２１は、呼制御サーバＳＶ２へ発信要求を送信する（図６（２））。呼制御サーバＳＶ２は、上記発信要求を受信すると、ＩＰ−ＱＳＩＧで規定されるＳＥＴＵＰメッセージを生成する。このＳＥＴＵＰメッセージには、発信元識別情報や着信先識別情報、ＩＰ電話端末Ｔ２１で使用される例えばＧ．７１１／Ｇ．７２９を示すコーデックや、ＤＴＭＦ信号の送受信能力としてのＲＦＣ２８３３を示す情報が含まれる。このＳＥＴＵＰメッセージは、呼制御サーバＳＶ２からＩＰ網１を介して呼制御サーバＳＶ１へ送信される（図６（３））。

呼制御サーバＳＶ１は、ＳＥＴＵＰメッセージを受信すると、このＳＥＴＵＰメッセージから発信側の能力としてＲＦＣ２８３３に対応しているか否かを判定し、続いてＤＴＭＦ能力テーブル１４１を参照して、着信先のＩＰ電話端末Ｔ１１の能力としてＲＦＣ２８３３に対応しているか否かを判定する。同時に、呼制御サーバＳＶ１は、ＩＰ電話端末Ｔ１１に対し呼び出しを行ない（図６（４））、呼制御サーバＳＶ２に対しＳＥＴＵＰメッセージを正しく受信した旨を示すメッセージ（ＣＡＬＬ ＰＲＯＣ，ＡＬＥＲＴ）を送信する（図６（５））。

呼び出しに応答したＩＰ電話端末Ｔ１１は応答信号を呼制御サーバＳＶ１へ送信する（図６（６））。

応答信号を受信した呼制御サーバＳＶ１は、上記判定結果から発信側のＤＴＭＦ能力がＲＦＣ２８３３に対応せず、着信先のＩＰ電話端末Ｔ１１のみＲＦＣ２８３３に対応すると認識する。すなわち、呼制御サーバＳＶ２に接続されるＩＰ電話端末Ｔ２１はＲＦＣ２８３３をサポートしていないため、ＳＥＴＵＰメッセージ中にＲＦＣ２８３３を示す情報を含めずに呼制御サーバＳＶ１に送信することになる。そうすると、呼制御サーバＳＶ１では、受信したＳＥＴＵＰメッセージ中にＲＦＣ２８３３を示す情報が含まれていないことを認識し、呼制御サーバＳＶ２をＲＦＣ２８３３未サポートのサーバと認識する。

そして、呼制御サーバＳＶ１は、着信先のＩＰ電話端末Ｔ１１との間に通信リンクを確立し、さらにＩＰ電話端末Ｔ１１を呼制御サーバＳＶ１に接続した旨を示す情報を応答メッセージ（ＣＯＮＮ）に乗せて呼制御サーバＳＶ２に通知する（図６（７））。

そして、応答メッセージを受信した呼制御サーバＳＶ２は、ＣＯＮＮ ＡＣＫを呼制御サーバＳＶ１へ返送する（図６（８））。そして、呼制御サーバＳＶ２は、ＩＰ電話端末Ｔ２１との間に通信リンクを形成する。かくして、発信元のＩＰ電話Ｔ２１と着信先のＩＰ電話端末Ｔ１１との間には呼制御サーバＳＶ１，ＳＶ２を経由した通信リンクが形成され、以後通話が可能となる。

以上の説明では、発信元のＩＰ電話Ｔ２１と着信先のＩＰ電話端末Ｔ１１との間を呼制御サーバＳＶ１，ＳＶ２を経由させて接続する例について説明したが、その他に、呼制御サーバＳＶ１，ＳＶを経由させず、発信元のＩＰ電話端末Ｔ２１と着信先のＩＰ電話端末Ｔ１１との間をダイレクトに接続するピアツーピア接続がある。

ピアツーピア接続を行なうためには、発信元のＩＰ電話端末Ｔ２１で使用するコーデックと着信先のＩＰ電話端末Ｔ１１で使用するコーデックが一致しなければならない。しかし、両者のコーデックが一致していたとしても、途中のファイアウォールＦＷ１，ＦＷ２を経由する場合には、ＩＰ電話端末Ｔ１１，Ｔ１２間でピアツーピアにより接続されない。

以上のように上記第１の実施形態では、呼制御サーバＳＶ１において、通信相手側の呼制御サーバＳＶ２からＲＴＰパケットと別にＩＮＦＯメッセージにより送られるＤＴＭＦ通知イベントを検出した場合に、ＲＴＰパケットのペイロードに入れるＤＴＭＦデータを生成し、呼制御サーバＳＶ２から受信したＲＴＰパケットのペイロードのデータをＤＴＭＦデータに入れ替え、さらにＲＴＰパケットのペイロードタイプをＩＰ電話端末Ｔ１１で使用されるペイロードタイプ［１０２］に書き替えてＩＰ電話端末Ｔ１１に送信するようにしている。

従って、ＲＦＣ２８３３未サポートの呼制御サーバＳＶ２とＲＦＣ２８３３サポートの呼制御サーバＳＶ１とを経由してＩＰ電話端末Ｔ１１，Ｔ２１間で通話が行なわれていても、ＩＰ電話端末Ｔ２１にてＤＴＭＦデータを発生する操作がなされた場合に、通知先のＩＰ電話端末Ｔ１１に対し確実にＤＴＭＦデータパケットを送信することができる。

また、上記第１の実施形態によれば、ＲＴＰパケットのヘッダに含まれるペイロードタイプ、ＲＴＰパケットのペイロードを利用して通知先のＩＰ電話端末Ｔ１１にＤＴＭＦイベントパケットを通知することで、ＲＴＰパケットとＤＴＭＦデータとをミキシングするためのＤＳＰを必要とすることなく、ＤＴＭＦイベントパケットをＩＰ電話端末Ｔ１１に送信することができ、これによりＤＳＰリソースによる同時使用数の制限がなくなる。さらに、ＲＴＰパケットのペイロードタイプの変更、ペイロードのデータの差し替えであるため、シーケンス番号、タイムスタンプ等がずれず、パケットロス、パケット遅延が発生しないため、ＱＯＳを悪化させなくて済む。

（第２の実施形態）
第２の実施形態は、ＲＦＣ２８３３サポートのサーバ装置に接続されるＩＰ電話端末とＲＦＣ２８３３未サポートのサーバ装置に接続されるＩＰ電話端末との間で音声通信を行なう第１の実施形態とは異なり、ＲＦＣ２８３３サポートのサーバ装置に接続されるＩＰ電話端末とＲＦＣ２８３３サポートのサーバ装置に接続されるＩＰ電話端末との間で音声通信を行なう場合の実施形態である。

例えばＩＰ電話端末において、通信相手側からＲＦＣ２８３３で規定されるＲＴＰパケットを受信したとする。この場合、自端末で認識可能なヘッダーのペイロードタイプに従って受信したＲＴＰパケットのペイロードに挿入されるＤＴＭＦデータを抽出し、ＤＴＭＦ再生を行う。ところで、ＩＰ電話端末において、受信したＲＴＰパケットのペイロードタイプが自端末で認識可能なペイロードタイプと異なると、ＲＴＰパケットのペイロードを認識できず、これによりＤＴＭＦを認識できない。

そこで、本第２の実施形態は、ＲＦＣ２８３３サポートのサーバ装置において、通信相手側からＲＦＣ２８３３で規定されるＲＴＰパケットを受信した場合に、受信したＲＴＰパケットのペイロードタイプを宛先のＩＰ電話端末で認識可能なペイロードタイプに書き替えて宛先に送信するようにしたものである。

図７は、本第２の実施形態として、ＩＰ電話端末Ｔ３１からＩＰ電話端末Ｔ１３へＤＴＭＦ信号を通知する場合のシーケンスを示すものである。ここでは、ＲＦＣ２８３３で使用するペイロードタイプが以下のように異なる場合を示す。

「呼制御サーバＳＶ３」と「ＩＰ電話端末Ｔ３１」間のペイロードタイプ＝100
「呼制御サーバＳＶ３」と「呼制御サーバＳＶ１」間のペイロードタイプ＝101
「呼制御サーバＳＶ１」と「ＩＰ電話端末Ｔ１３」間のペイロードタイプ＝102
ペイロードタイプが異なる場合、そのままでは、ＩＰ電話端末Ｔ３１からＩＰ電話端末Ｔ１３へＤＴＭＦ信号を通知することができないため、以下の処理を行うことにより、ＤＴＭＦ信号の通知を実現する。

いま、ＩＰ電話端末Ｔ１３，Ｔ３１間で通信リンクが確立しているものとする。ここでは、例えばＩＰ電話端末Ｔ１３がオートアテンダントで、ＩＰ電話端末Ｔ３１に対しアナウンスメッセージをＲＴＰパケットとして送出するものとする。

なお、アナウンスメッセージの内容は、例えば「はい。こちら○○会社です。△△商品の購入予約を希望の場合はダイヤル［２］を押してください。」が使用される。

この状態で、ＩＰ電話端末Ｔ３１においてユーザがダイヤル［２］を押下したとする（図７（１））。そうするとＩＰ電話端末Ｔ３１はダイヤル［２］に対応するＤＴＭＦ信号を「ペイロードタイプ＝100」のＲＦＣ２８３３パケットにより、呼制御サーバＳＶ３に通知する（図７（２））。

呼制御サーバＳＶ３は、中継処理部１２で、ＲＦＣ２８３３規定のＲＴＰパケットを検出すると（図７（３））、図８に示すＲＴＰパケットのペイロードタイプを参照する。ここで、呼制御サーバＳＶ３は、宛先となる呼制御サーバＳＶ１へ送信するＲＴＰパケットのペイロードタイプを示す情報「１０１」を予め記憶しており、受信したＲＴＰパケットのペイロードタイプ「１００」と予め記憶しているペイロードタイプ「１０１」とが一致するか否かを判定する。

ここでは、ペイロードタイプが異なるので、呼制御サーバＳＶ３は受信したＲＴＰパケットのペイロードタイプを「１００」から「１０１」に書き替え、その他のシーケンス番号、タイムスタンプ、ＳＳＲＣ等を含むヘッダーの情報及びペイロードのデータはそのまま残すものとする（図７（４））。

このペイロードタイプが書き替えられたＲＴＰパケットは、呼制御サーバＳＶ１へ送信される。
呼制御サーバＳＶ１は、ＤＴＭＦ通知イベント検出部１３１で、ＲＦＣ２８３３規定のＲＴＰパケットを検出すると（図７（５））、ペイロードタイプの変換処理を行う。呼制御サーバＳＶ１とＩＰ電話端末Ｔ１３間のペイロードタイプは102であるため、ペイロードタイプは、101から102に変換される（図７（６））。

変換されたＲＦＣ２８３３規定のＲＴＰパケットは、ＩＰ電話端末Ｔ１３へ送信される（図７（７））。これにより、ＩＰ電話端末Ｔ１３は、ペイロードタイプ=102のＲＦＣ２８３３パケットを検出し、ＤＴＭＦ信号が通知されたことを認識する。

以上のように上記第２の実施形態では、呼制御サーバＳＶ１において、通信相手側の呼制御サーバＳＶ３からＲＦＣ２８３３規定のＲＴＰパケットが送られた場合に、ＲＴＰパケットのペイロードタイプが通知先のＩＰ電話端末Ｔ１３で処理可能なペイロードタイプと同一か否かを判定し、異なる場合に、ペイロードタイプの書き換えを行なうようにしている。

従って、ペイロードタイプの変更のみといった簡単な手順により、ＤＴＭＦイベントパケットを通知先のＩＰ電話端末Ｔ１３に送信することができる。

（その他の実施形態）
本発明は、上記各実施形態に限定されるものではない。例えば、ＩＰ−ＱＳＩＧに従って、通信接続やＤＴＭＦ信号の通知を行なう例について説明したが、例えばＳＩＰ等を用いるものであってもよい。

また、上記第１の実施形態では、ダイヤル番号に相当するＤＴＭＦデータをペイロードに挿入するものについて説明したが、例えば無音または予め決められた音声データを生成して、受信したＲＴＰパケットのペイロードのデータを無音または予め決められた音声データに差し替えるものであってもよい。

その他の実施形態であっても、電話端末間で複数のサーバ装置間を経由して通話を行なっている状態で、通話相手側の電話端末にてＤＴＭＦデータを発生する要求操作がなされた場合に、通信相手側のサーバ装置からＤＴＭＦ通知イベントが到来することになるので、このＤＴＭＦ通知イベントを検出することで、受信するＲＴＰパケットのヘッダに含まれるペイロードタイプの変更、通信パケットのペイロードのデータをＤＴＭＦデータに入れ替えの少なくとも１つが実行されることになる。

従って、ＲＴＰパケットとＤＴＭＦデータとをミキシングするためのＤＳＰを必要とすることなく、ＤＴＭＦイベントパケットをＩＰ電話端末に送信することができ、これによりＤＳＰリソースによる同時使用数の制限がなくなる。さらに、ＲＴＰパケットのペイロードタイプの変更、ペイロードのデータの差し替えであるため、シーケンス番号、タイムスタンプ等がずれず、パケットロス、パケット遅延が発生しないため、ＱＯＳを悪化させなくて済む。

その他、システム構成、呼制御サーバの機能構成、電話端末の種類、ＤＴＭＦ信号の通知方法等についてもこの発明の要旨を逸脱しない範囲で種々変形して実施できる。

１…ＩＰ網、１１…ＩＰ制御部、１２…中継処理部、１３…呼制御部、１４…記憶部、１５…データハイウェイ、１３１…ＤＴＭＦ通知イベント検出部、１３２…ＤＴＭＦデータ生成部、１３３…ペイロード入替部、１３４…ペイロードタイプ更新部、１４１…ＤＴＭＦ能力テーブル、ＳＶ１〜ＳＶｎ…呼制御サーバ、Ｔ１１〜Ｔ１ｉ，Ｔ２１〜Ｔ２ｍ，Ｔ３１〜Ｔ３ｐ，Ｔｎ１〜Ｔｎｋ…ＩＰ電話端末、ＧＷ１ゲートウェイ、ＮＷ１，ＮＷ２…公衆網、ＦＷ１〜ＦＷｎ…ファイアウォール。

Claims (5)

1. ヘッダ及びペイロードを備える通信パケットを伝送する通信ネットワークに接続され、電話端末を収容するサーバ装置において、
   電話端末間で前記複数のサーバ装置間を経由して音声通信を行なっている状態で、通信相手側のサーバ装置から通知されるＤＴＭＦ（Dual Tone Multi Frequency）通知イベントを検出する検出手段と、
   この検出手段による検出結果に基づいて、受信する通信パケットのヘッダに含まれるペイロードタイプの変更、前記通信パケットのペイロードのデータをＤＴＭＦデータに入れ替えの少なくとも１つを実行する制御手段とを備えたことを特徴とするサーバ装置。
2. 前記検出手段は、通信相手側の電話端末を収容するサーバ装置から前記通信パケットと別に送られる前記ＤＴＭＦ通知イベントを検出し、
   前記制御手段は、
   前記検出手段により前記ＤＴＭＦ通知イベントを検出した場合に、前記ＤＴＭＦデータを生成する生成手段と、
   この生成手段により生成したＤＴＭＦデータを通信中の通信パケットのペイロードのデータと入れ替える入れ替え手段と、
   この入れ替え手段により入れ替えられたＤＴＭＦデータのペイロードタイプに従って、前記通信パケットのヘッダに位置するペイロードタイプを変更する変更手段とを備えるようにしたことを特徴とする請求項１記載のサーバ装置。
3. 前記検出手段は、前記通信相手側の電話端末を収容するサーバ装置から送られペイロードにＤＴＭＦデータを含めた前記通信パケットを検出し、
   前記制御手段は、前記検出手段により検出したＤＴＭＦデータを含む通信パケットのペイロードタイプが収容した電話端末へ送信する通信パケットのペイロードタイプと異なる場合に、受信した通信パケットのペイロードタイプを前記電話端末用のペイロードタイプに書き替えて前記電話端末に送信することを特徴とする請求項１記載のサーバ装置。
4. 前記生成手段は、前記ＤＴＭＦデータとして、無音データまたは予め決められた音データを生成し、
   前記入れ替え手段は、前記生成手段により生成した無音データまたは予め決められた音データを通信中の通信パケットのペイロードのデータと入れ替えることを特徴とする請求項２記載のサーバ装置。
5. ヘッダ及びペイロードを備える通信パケットを伝送する通信ネットワークに接続され、電話端末を収容するサーバ装置で使用されるＤＴＭＦ通知方法において、
   電話端末間で前記複数のサーバ装置間を経由して音声通信を行なっている状態で、通信相手側のサーバ装置から通知されるＤＴＭＦ通知イベントを検出し、
   この検出結果に基づいて、受信する通信パケットのヘッダに含まれるペイロードタイプの変更、前記通信パケットのペイロードのデータをＤＴＭＦデータに入れ替えの少なくとも１つを実行するようにしたことを特徴とするＤＴＭＦ通知方法。

Images