JP2015207924A - 呼制御装置 - Google Patents

Abstract

【課題】２つの電話端末が互いに発信し合ったときに話中とならずに通話が開始できるようにする。【解決手段】呼制御装置が呼接続要求信号受信履歴を保持し、新たに受信した呼接続要求信号の発信元と着信先が履歴から得られる接続処理中の呼の中にそれぞれ着信先と発信元として記録されていると２つの呼が互いに発信しあって呼衝突が発生していると判断し、衝突した呼が確立する区間を発信元と呼制御装置となるように呼制御し、電話端末同士が音声信号を交換させるためのセッション情報を呼制御装置を介して衝突呼間で交換させることで、通話開始が可能となる。【選択図】図１１

Description

本発明は、呼制御装置に係り、特に２人のユーザーが互いに同時に発呼することで生じる呼衝突を処理して通話を可能にする呼制御装置に関する。

電話サービス利用において、ユーザーの意図に反して接続が切断され通話が終了してしまうことがある。例えば、携帯電話端末における電波状況の悪化または保留の処理に伴う釦操作の誤りによる接続切断が挙げられる。このような場合、通話をしていた２者が互いに同時に再度発信操作を行うことが起こりうる。本明細書では、このような状況を相互発信による呼衝突と呼ぶ。現在の電話サービスシステムでは、相互発信による呼衝突が発生した場合、どちらの電話端末も発信中であるため接続要求に対してエラーメッセージを送信し合い、結果的に通話を再開するに至らない。

特許文献１は、相互発信による呼衝突と接続失敗を解決する手段として、電話端末に、発信中の呼の情報と着信した呼の情報を保存する記憶機能と、記憶機能を元に相互に発信し合っていることを判断する衝突検知機能と、衝突検知時に衝突した２つの呼における優先度を決定し優先度の高い呼の処理を続行することで通話が開始できるようにする優先呼接続機能、の３つの拡張機能を具備する技術を開示する。これは、ＩＰ電話では呼制御装置は電話端末の利用状態を把握せず、電話端末自身に接続可否の判断を行わせるという特徴を利用した技術である。

特開２０１１−２５４２２２号公報

既存の電話端末が特許文献１の機能を利用するためには、電話端末のソフトウェアアップデートが必要である。このアップデートに対応できない場合、電話端末の買い替えとなるため、いずれにしてもユーザーへの負担が発生してしまう。また、特許文献１では課題解決を電話サービス事業者ネットワークの外部で実施しており、ユーザーが前述の機能を備えた電話端末に置き換えるまでの時間と、ユーザーの前述の電話端末への移行を促すための費用と、が必要である。

本発明の目的は、相互発信による呼衝突発生時でも通話を開始できる呼制御装置を提供することにある。

上述した課題は、電話端末間の呼制御信号を中継し電話端末の接続処理を行う呼制御装置において、呼制御信号を外部通信装置より受信する呼制御信号受信部と、受信した呼制御信号の内容を解析する呼制御信号解析部と、受信した呼制御信号の送信先を検索するユーザー情報検索部と、呼制御信号解析部およびユーザー情報検索部より得られた情報をもとに呼制御信号を編集する呼制御信号編集部と、呼制御信号を外部通信装置へ送信する呼制御信号送信部と、接続処理中の呼の中に発信電話端末と着信電話端末との組み合わせが互いに逆の２つの呼の衝突が発生していることを検知する呼衝突検知部と、呼衝突検知部が呼衝突を検知したとき、当該呼の接続処理を終了させることなく通話開始させるための制御を行う衝突処理部と、を備える呼制御装置により、達成できる。

本発明によれば、相互発信による呼衝突発生時でも通話を開始できる。

呼制御装置のブロック図である。 呼の衝突形態を説明する通信システムのブロック図である。 呼の接続形態を説明する通信システムのブロック図である。 呼接続要求信号受信テーブルを説明する図である。 衝突管理テーブルを説明する図である。 呼制御装置による衝突検知までのフローチャートである。 呼制御装置による衝突呼処理のフローチャート（その１）である。 呼制御装置による衝突位置判定処理のフローチャートである。 呼制御装置による衝突呼処理のフローチャート（その２）である。 呼制御装置によるセッション切断のフローチャートである。 非衝突処理中の呼制御装置におけるセッション切断のフローチャートの１例を示す。 ２台の電話端末と呼制御装置との間の呼接続のシーケンス図である。 ２台の電話端末と２台の呼制御装置との間の呼接続のシーケンス図（その１）である。 ２台の電話端末と２台の呼制御装置との間の呼接続のシーケンス図（その２）である。 ２台の電話端末と２台の呼制御装置との間の呼接続のシーケンス図（その３）である。 ２台の電話端末と２台の呼制御装置との間の呼接続のシーケンス図（その４）である。

以下、本発明の実施の形態について、実施例を用い図面を参照しながら詳細に説明する。

図１を参照して、呼制御装置の構成を説明する。図１において、呼制御装置４００は、電話端末間の呼制御信号を中継し、電話端末間の通話を可能にする。呼制御装置４００は、呼制御信号受信部４１０と、呼制御信号解析部４２０と、ユーザー情報検索部４３０と、ルーティング表保持部４４０と、呼制御信号編集部４５０と、呼制御信号送信部４６０と、呼衝突検知部４７０と、呼衝突処理部４８０と、を含んで構成されている。

呼制御信号受信部４１０は、呼制御信号を外部通信装置より受信する。呼制御信号解析部４２０は、受信した呼制御信号の内容を解析する。ユーザー情報検索部４３０は、受信した呼制御信号の送信先を検索する。検索部４３０の参照先である着信先別ルーティング表保持部４４０は、呼制御装置４００外であって構わない。呼制御信号編集部４５０は、解析部および検索部より得られた情報をもとに呼制御信号を編集する。呼制御信号送信部４６０は、呼制御信号を外部通信装置へ送信する。呼衝突検知部４７０は、接続処理中の呼の中に発信電話端末と着信電話端末の組み合わせが互いに逆となって衝突が発生していることを検知する。呼衝突処理部４８０は、検知部により呼と呼が衝突したことを検知した場合、当該呼の接続処理を終了させることなく通話開始させる。

呼衝突処理部４８０は、衝突した呼を発信した電話端末と衝突を検知した当該呼制御装置の区間でセッションを確立させるための処理を実行する。呼衝突処理部４８０は、また、衝突した２つの呼それぞれに対する接続処理実施による２つのセッションの確立と、接続処理の過程におけるセッション間でのセッション情報の交換と、衝突を検知した呼制御装置数の特定と、を実施する。

衝突を検知した呼制御装置数が１であった（自装置のみが検知した）場合、呼制御装置４００は、接続処理を継続する。衝突を検知した呼制御装置数が２であった場合、一方の呼制御装置は、接続処理を継続する。これに対して、他方の呼制御装置は、接続処理を中止する。

衝突を検知した呼制御装置数が２における動作分岐を判定するにあたり、呼制御装置間の判定は一意的である。すなわち、他方の当該呼制御装置が継続と判断する場合は当方の当該呼制御装置は中止と判断する。一方、他方の当該呼制御装置が中止と判断する場合は当方の当該呼制御装置は継続と判断する。

衝突接続処理とセッション情報交換において、接続要求信号内のセッション情報の有無に応じた接続処理とセッション情報交換が可能であり、電話端末のセッション情報送信時期および仕様に影響されない。

呼衝突処理部４８０は、分岐要因（１）衝突位置による衝突処理の変化と、分岐要因（２）セッション情報取得状況による衝突処理の変化と、に対応した分岐処理を実施する。以下、分岐要因（１）、（２）について詳細に説明する。

図２Ａを参照して、分岐要因（１）について説明する。図２Ａにおいて、通信システム７００は、呼制御装置４００と、電話端末１００とを含んで構成されている。通信システム７００における呼衝突は、ネットワーク内衝突とネットワーク外衝突の２種類が存在する。その違いは呼が衝突する位置の差であり、衝突位置の差に伴い衝突検知可能な呼制御装置数に差がある。電話端末１００−ａと１００−ｂが相互発信すると、１００−ａからの接続要求信号はネットワーク２００に到達し、呼制御装置４００−ａを経由して呼制御装置４００−ｂに送信される。一方、電話端末１００−ｂからの接続要求信号は４００−ｂを経由して４００−ａに送信される。衝突検知を検知した呼制御装置は、自身が着信電話端末の代替として発信電話端末と接続処理を実施する。このため、呼制御装置４００−ａと４００−ｂの区間で発生したネットワーク内衝突の場合、衝突を検知する呼制御装置数は２となる。

一方、電話端末１００−ｃと電話端末１００−ｄによる相互発信では、１００−ｃからの接続要求信号と１００−ｄからの接続要求信号は、呼制御装置４００−ｂと電話端末１００−ｄの間の区間でネットワーク外衝突を起こしており、衝突を検知する呼制御装置数は１である。

ここでは、衝突を検知する呼制御装置数が２をネットワーク内衝突と呼ぶ。一方、衝突を検知する呼制御装置数が１をネットワーク外衝突と呼ぶ。ネットワーク内衝突とネットワーク外衝突では検知した呼制御装置４００−ａおよび呼制御装置４００−ｂが受信する制御信号は異なる。ネットワーク内衝突とネットワーク外衝突の発生条件の違いは電話端末から呼接続要求が送信される時期によるものであり、どちらかをユーザーおよび呼制御装置が選択できるものではない。なお、明細書および図面に於いて、電話端末１００−ａを、電話端末ａと記載することがある。呼制御装置も同様である。

図２Ｂを参照して、セッション確立において呼が経由する呼制御装置数により分類される接続形態を説明する。図２Ｂにおいて、ネットワーク２００内の呼制御装置による呼制御が実施される場合において、電話端末１００−ｅから電話端末１００−ｇ宛に接続要求信号が呼制御装置４００−ｃから呼制御装置４００−ｄの区間を経由して伝達されるとき、経由呼制御装置数は、２以上である。

一方、電話端末１００−ｆから電話端末１００−ｈ宛に接続要求信号が呼制御装置４００−ｃのみを経由して伝達されるとき、経由呼制御装置数は、１である。呼制御装置４００−ｃと呼制御装置４００−ｄの区間に複数の呼制御装置がありうる。

図２Ｂにおいて、ネットワーク内衝突は、経由呼制御装置が２以上のときにしか発生しない。しかし、ネットワーク外衝突は、経由呼制御装置が１でも２以上の場合でも発生しうる。

分岐要因（２）について説明する。衝突検知後の接続処理およびセッション同士によるセッション情報の交換において、当該の衝突呼にセッション情報が含まれているかは発信電話端末の仕様により規定されている。衝突検知時のセッション情報取得状況として、（Ａ）どちらの電話端末からもセッション情報が取得できている場合、（Ｂ）どちらかからのみ取得できている場合、（Ｃ）どちらからも取得できていない場合、がある。

ＳＩＰによる呼制御において、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＤＰ）上でオファー・アンサーモデルによるセッション情報の交渉がされる。ＩＮＶＩＴＥオファー・２００ ＯＫアンサーの場合、衝突検知時には発信電話端末からセッション情報を、取得できる。しかし、２００ ＯＫオファー・ＡＣＫアンサーの場合、セッション情報を、取得できない。

（Ａ）〜（Ｃ）のセッション情報取得状況に応じたセッション情報の取得およびセッション間のセッション情報交換をする必要がある。該当するデータが検索された場合、相互発信による呼衝突が発生したと検知する。

図１に戻って、呼衝突検知部４７０は、衝突を検知すると呼衝突管理テーブル（後述）に相互発信呼衝突中の電話端末の電話端末識別子の組とセッション情報取得状況のデータを追加する。呼接続要求信号受信以降の信号の受信の際、呼衝突検知部４７０は、呼衝突管理テーブルを参照することで衝突処理が必要な呼であるかを判断する。処理が必要な場合、呼衝突検知部４７０は、呼衝突処理部４８０へ信号を送る。

図３を参照して、ＩＮＶＩＴＥ受信履歴情報テーブルを説明する。図３において、ＩＮＶＩＴＥ受信履歴情報テーブル５００は、発信電話端末識別子５１０と、着信電話端末識別子５２０と、セッション情報の有無５３０と、を含む。

発信電話端末識別子５１０は、発信電話端末の識別子である。着信電話端末識別子５２０は、着信電話の端末識別子である。セッション情報の有無５３０は、発信電話端末と着信電話端末との間のセッション情報の有無である。

図４を参照して、衝突管理情報テーブルを説明する。図４において、衝突管理情報テーブル６００は、衝突を起こしている電話端末の組を管理するテーブルである。衝突管理情報テーブル６００は、電話端末識別子１ ６１０と、電話端末識別子２ ６２０と、セッション情報１ ６３０と、セッション情報２ ６４０と、を含む。電話端末識別子１ ６１０と電話端末識別子２ ６２０は、衝突を起こしている電話端末の組である。セッション情報１ ６３０は、電話端末識別子１ ６１０に該当する電話端末のセッション情報の有無を記載する。セッション情報２ ６４０は、電話端末識別子２ ６２０に該当する電話端末のセッション情報の有無を記載する。

図５を参照して、呼制御装置による衝突検知までの処理を説明する。図５において、フローチャート中の要求メッセージと共に記されるＡ→Ｂ、Ｂ→Ａは、そのメッセージが電話端末Ａから電話端末Ｂへ、電話端末Ｂから電話端末Ａへ向けて送信されたことを意味する。さらに、応答メッセージにおけるＡ→Ｂ、Ｂ→Ａは、要求メッセージに対する応答として電話端末Ｂから電話端末Ａへ、電話端末Ａから電話端末Ｂへ向けて送信されたメッセージであることを意味する。ここで、要求メッセージと応答メッセージとでは、矢印に対する送信元、受信先の位置が代わっている。また、フローチャート全体の前提条件として、呼制御装置４００は、電話端末Ａから送信されたＩＮＶＩＴＥを最初に受信したこととする。

図５において、先頭の待機中は、呼制御装置４００が電話端末Ａまたは電話端末ＢのいずれからもＩＮＶＩＴＥを受信していない状態を指す。呼制御装置４００は、ＩＮＶＩＴＥ（Ａ→Ｂ）を受信する（Ｓ７０１）。

呼制御装置４００は、ユーザー情報検索部４３０により送信先アドレスを判明させた後に呼衝突検知部４７０にて受信したＩＮＶＩＴＥの発信電話端末識別子５１０、着信電話端末識別子５２０、セッション情報の有無５３０をＩＮＶＩＴＥ受信履歴情報テーブル５００に新規追加する（Ｓ７０２）。呼制御装置４００は、ＩＮＶＩＴＥ受信履歴情報テーブル５００の中に電話端末Ｂの電話端末識別子が５１０でありかつ電話端末Ａの電話端末識別子が５２０であるデータを検索し、データが追加されていないことを確認する（Ｓ７０３）。呼制御装置４００は、衝突は発生していないと判断してＩＮＶＩＴＥ（Ａ→Ｂ）を次の宛先に送信する（Ｓ７０４）。ここまではＩＮＶＩＴＥ受信履歴情報テーブル５００へのデータ追加とデータ検索を除いて一般的な呼処理に同じである。

呼制御装置４００は、ＩＮＶＩＴＥ（Ｂ→Ａ）を受信する（Ｓ７０５）。ステップＳ７０１〜ステップＳ７０３と同様に、呼制御装置４００は、ＩＮＶＩＴＥ受信履歴情報テーブル５００にデータを追加する（Ｓ７０６）。呼制御装置４００は、ＩＮＶＩＴＥ受信履歴情報テーブル５００にＩＮＶＩＴＥ（Ａ→Ｂ）のデータが追加されているか検索し、存在を確認する（Ｓ７０７）。

呼衝突が発生したことを検知した呼制御装置４００は、衝突管理情報テーブル６００にＡとＢの電話端末識別子の組およびセッション情報の取得状況を示すデータを追加し（Ｓ７０８）、衝突呼処理中状態へと遷移する。
この状態のときに受信した衝突処理対象となる呼の信号は次の宛先へ送信されることはなく、呼制御装置４００は、着信電話端末として発信電話端末と接続処理を行う。

図６ないし図８を参照して、衝突呼処理を説明する。
図６において、呼制御装置４００は、着信電話端末としてＩＮＶＩＴＥ（Ａ→Ｂ）に対する応答として呼び出し中を示す１８０Ｒｉｎｇｉｎｇ（Ａ→Ｂ）を電話端末Ａ宛に送信し、ＩＮＶＩＴＥ（Ｂ→Ａ）に対しても同様に１８０Ｒｉｎｇｉｎｇ（Ｂ→Ａ）を電話端末Ｂ宛に送信する（Ｓ８０１）。この応答メッセージを受信した電話端末Ａおよび電話端末Ｂは、Ｒｉｎｇ Ｂａｃｋ Ｔｏｎｅ（ＲＢＴ）を鳴動させて各ユーザーに着信電話端末を呼び出し中であることを通知し、各ユーザーは着信電話端末のユーザーが応答するのを待つ。発信電話端末のユーザーにＲＢＴを一定時間聴取させるために、ステップＳ８０１のあとに呼制御装置４００は、ＲＢＴ鳴動タイマーＴＲＢＴを設定し、ＲＢＴ鳴動タイマーＴＲＢＴがタイムアウトするまで待機する（Ｓ８０２）。次のステップである２００ ＯＫの送信において、上記の分岐要因（２）である、電話端末の仕様ごとに決められているＳＤＰメッセージの送信タイミングの違いにより、ＩＮＶＩＴＥ（Ａ→Ｂ）とＩＮＶＩＴＥ（Ｂ→Ａ）がともにオファーである場合（パターンＡ）、どちらか片方だけがオファーの場合（パターンＢ）、どちらもオファーでない場合（パターンＣ）、の３つのパターンのいずれに該当するのかについて、呼制御装置４００は、衝突管理情報テーブル６００より判定する（Ｓ８０３）。

最初にパターンＡについて説明する。通常、ＩＮＶＩＴＥオファーによるセッション情報の交渉は電話端末同士で行われる。しかし、衝突を検知した呼制御装置４００は、ＩＮＶＩＴＥオファーを着信電話端末宛に送信しない。電話端末ＡとＢの両方のセッション情報が揃っており交渉が可能なため、呼制御装置４００は、セッション情報の交渉を実施する。呼制御装置４００は、電話端末Ａおよび電話端末Ｂに着信電話端末のセッション情報を２００ ＯＫアンサーに記載して送信する（Ｓ８０６）。

次にパターンＢの場合について説明する。パターンＢの場合、既に１つ電話端末からセッション情報を取得できているため、呼制御装置４００は、これを２００ ＯＫオファーとしてセッション情報を取得できていない電話端末に送信する（Ｓ８０５）。具体的には、電話端末Ａからセッション情報が図５のステップＳ７０１にて取得できている場合、呼制御装置４００は、２００ ＯＫ（Ｂ→Ａ）にこのセッション情報を記載する。ＩＮＶＩＴＥオファーでセッション情報を送信してきた電話端末に対する２００ ＯＫアンサーは、２００ ＯＫオファーに対するＡＣＫアンサーが得られた後に、ＡＣＫアンサーに記載されるセッション情報を利用して送信する。

最後にパターンＣの場合について説明する。パターンＣの場合、どちらからもセッション情報が取得できていないため、呼制御装置４００は、どちらか一方のセッション情報を取得するための処理を実施する。呼制御装置４００は、衝突した２つのＩＮＶＩＴＥのどちらかを選択し、選択されたＩＮＶＩＴＥを発信した電話端末のセッション情報を取得する。選択を決定するための判定条件に指定はないが、ネットワーク内衝突ではステップＳ７０８で衝突を検知する呼制御装置４００の数は２であり、どちらの呼制御装置４００が選択したＩＮＶＩＴＥも同じであることが好ましい。判定法として、具体的には、ＳＩＰの要求メッセージにおいて必須とされるＣａｌｌ‐ＩＤヘッダの文字列を指定した変換規則のもと文字列と１対１で変換可能な数値にし、その大小を比較した上で一方のＩＮＩＶＩＴＥを選択するなどの方法がある。呼制御装置４００は、選択されたＩＮＶＩＴＥに対する２００ ＯＫオファーに、ダミーセッション情報を記載して送信する（Ｓ８０４）。ダミーセッション情報とは電話端末からＡＣＫアンサーを受信してセッションを確立させるためのセッション情報であり、ユーザー同士が通話を開始させるために記載されるものではない。このため、電話端末１００からＡＣＫアンサーを得られるものであるならその内容に制限はない。

２００ ＯＫ送信すると、呼制御装置４００は、衝突位置判定とそれに応じた処理を実施する（Ｓ８０７）。呼制御装置４００は、ＡＣＫ（Ａ→Ｂ）を受信する（Ｓ８０８）。なお、ステップＳ８０８において、呼制御装置４００が、ＡＣＫ（Ｂ→Ａ）を受信することもあるが、ここではＡＣＫ（Ａ→Ｂ）を受信したとして、説明する。

図７を参照して、衝突位置判定処理を説明する。２００ ＯＫを送信した呼制御装置４００は、応答信号を受信する（Ｓ９０１）。この応答信号は、ネットワーク内衝突の場合、衝突を検知したもう１つの呼制御装置４００からであり、ネットワーク外衝突の場合、電話端末１００から受信する。そこで、呼制御装置４００は、受信した応答メッセージの違いでどちらの衝突形態であるかを判定する（Ｓ９０２）。１８０Ｒｉｎｇｉｎｇ（Ａ→Ｂ）を受信した場合、呼制御装置４００は、そのメッセージの送信元について衝突検知したもう１つの呼制御装置４００と特定でき、衝突はネットワーク内衝突であることがわかる（Ｓ９０３）。一方、ステップＳ９０２で４８６ＢｕｓｙＨｅｒｅを受信したと判定したとき、メッセージの送信元は電話端末１００であり、衝突はネットワーク外衝突であることがわかる（Ｓ９０４）。

ネットワーク内衝突の場合、呼制御装置４００は、衝突管理情報テーブル６００のセッション情報取得状況の違いによりその後の処理を３つに分岐する。パターンＢで電話端末Ａからのみセッション情報を取得していた場合、呼制御装置４００は、衝突を検知したもう１つの呼制御装置４００からＩＮＶＩＴＥを取り消すＣＡＮＣＥＬ（Ｂ→Ａ）を受信する（Ｓ９０７）。呼制御装置４００は、これに対して２００ ＯＫ（Ｂ→Ａ）を返信する（Ｓ９０８）。呼制御装置４００は、ＩＮＶＩＴＥ要求を拒否し処理を終了させたことを示す４８７ＲｅｑｕｅｓｔＴｅｒｍｉｎａｔｅｄ（Ｂ→Ａ）を送信する（Ｓ９０９）。呼制御装置４００は、４８７ＲｅｑｕｅｓｔＴｅｒｍｉｎａｔｅｄ（Ｂ→Ａ）を受信した他の呼制御装置４００から送られてくるＡＣＫ（Ｂ→Ａ）を受信する（Ｓ９１０）。この時点で呼制御装置４００と電話端末Ｂの間のＢ→Ａの接続処理は取り消されたので、呼制御装置４００は、テーブル５００から該当するデータを削除する（Ｓ９１１）。またこれ以降、呼制御装置４００は、衝突処理に関与しないため、衝突管理情報テーブル６００から電話端末Ａ・Ｂの電話端末識別子が記載されたデータを削除する（Ｓ９１２）。呼制御装置４００は、非衝突呼処理中フラグを設定して（Ｓ９１７）、リターンする。

ステップＳ９０５で電話端末Ｂからのみセッション情報を取得している場合、呼制御装置４００は、ＩＮＶＩＴＥ要求を取り消すためにＣＡＮＣＥＬ（Ａ→Ｂ）を送信する（Ｓ９１３）。ＣＡＮＣＥＬ（Ａ→Ｂ）を受信した対向の呼制御装置４００は２００ ＯＫを送信するため、呼制御装置４００は、これを受信する（Ｓ９１４）。ＩＮＶＩＴＥ要求が取り消されたことを示す４８７ＲｅｑｕｅｓｔＴｅｒｍｉｎａｔｅｄが送信されてくるので、呼制御装置４００は、これを受信する（Ｓ９１５）。呼制御装置４００は、ＡＣＫ（Ａ→Ｂ）を送信する（Ｓ９１６）。呼制御装置４００は、衝突呼処理中フラグを設定して（Ｓ９１８）、リターンする。

最後に、ステップＳ９０５において、セッション情報を両方の端末から取得済みの場合、またはどちらからも未取得の場合、呼制御装置４００は、衝突した２つの呼の情報をもとに衝突を検知した２つの呼制御装置のどちらが衝突処理を継続し、どちらが衝突処理を中止するのかを判定する（Ｓ９０６）。この判定法としては、具体的には、ステップＳ８０４にて選択されたＩＮＶＩＴＥを先に受信した呼制御装置が処理継続とする、などが考えられる。呼制御装置４００は、継続と判定された場合はステップＳ９１３へ、中止と判定された場合はステップＳ９０７へ分岐する。
ステップＳ９０２よりステップＳ９０４へと分岐した場合、呼制御装置４００は、４８６ＢｕｓｙＨｅｒｅ（Ａ→Ｂ）を受信したことを知らせるためにステップＳ９１６に遷移する。

図８を参照して、図６の続きとなる衝突呼処理を説明する。呼制御装置４００は、フラグ設定を判定する（Ｓ１００１）。非衝突呼処理中フラグの場合、呼制御装置４００は、衝突呼の処理を終え通常の呼制御処理状態に移っているため、ステップＳ８０８で受信したＡＣＫ（Ａ→Ｂ）を電話端末Ｂ宛に送信して（Ｓ１００３）、セッションが確立して電話端末Ａと電話端末Ｂが通話している状態に遷移する。ステップＳ１００１で衝突呼処理中フラグの場合、呼制御装置４００は、さらに衝突管理情報テーブル６００のセッション情報取得状況に応じて３つに処理が分岐する。電話端末Ａおよび電話端末Ｂのセッション情報取得済みの場合、この時点で衝突呼処理中状態であるならネットワーク内衝突およびネットワーク外衝突いずれの場合でも他に衝突呼処理中状態の呼制御装置４００はネットワーク内には存在しないので、あとはＡＣＫ（Ｂ→Ａ）を受信して（Ｓ１００４）、電話端末Ａと電話端末Ｂの間で通話可能な状態となる。なお、ステップＳ８０８とステップＳ１００４の受信タイミングは逆転することもある。

ステップＳ１００２において、セッション情報を電話端末Ｂからのみ取得済みの場合、ステップＳ８０８で電話端末Ａより受信したＡＣＫアンサーから取得したセッション情報について、呼制御装置４００は、２００ ＯＫ（Ｂ→Ａ）アンサーに記載し送信する（Ｓ１００５）。呼制御装置４００は、電話端末ＢよりＡＣＫ（Ｂ→Ａ）を受信して（Ｓ１００６）、これにより電話端末Ａと電話端末Ｂの間の通話が開始される。

ステップＳ１００２において、電話端末Ａおよび電話端末Ｂのどちらからもセッション情報を取得できていない場合、この時点で呼制御装置４００と電話端末Ｂの区間ではダミーセッション情報の交換により一時的にセッションが確立している。しかし、電話端末Ａおよび電話端末Ｂは、どちらも互いのセッション情報を交換していないため通話は開始できない。そこで呼制御装置４００は、電話端末Ａとして電話端末Ｂにｒｅ−ＩＮＶＩＴＥ（Ａ→Ｂ）をセッション情報を付けずに電話端末Ｂ宛に送信する（Ｓ１００７）。電話端末Ｂは、セッション情報の記載された２００ ＯＫオファーを送信してくるため、呼制御装置４００は、これを受信する（Ｓ１００８）。呼制御装置４００は、電話端末Ｂのセッション情報を２００ ＯＫ（Ａ→Ｂ）オファーに記載して電話端末Ａ宛に送信する（Ｓ１００９）。呼制御装置４００は、電話端末Ａよりセッション情報の記載されたＡＣＫアンサーを受信する（Ｓ１０１０）。呼制御装置４００は、このセッション情報を記載したＡＣＫアンサーを電話端末Ｂ宛に送信する（Ｓ１０１１）。以上にて、電話端末Ａと電話端末Ｂのセッション情報が交換され、通話が開始となる。

図９を参照して、衝突呼接続中状態の呼制御装置における呼切断処理を説明する。図９において、呼制御装置４００は、電話端末Ａまたは電話端末Ｂがオンフック状態となることで送信される切断要求信号のＢＹＥを受信する（Ｓ１１０１）。呼制御装置４００は、切断者に対して２００ ＯＫを送信する（Ｓ１１０２）。呼制御装置４００は、ＩＮＶＩＴＥ受信履歴情報テーブル５００の中にある切断者発信のＩＮＶＩＴＥデータを削除する（Ｓ１１０３）。これにより切断者と呼制御装置４００の区間のセッションが終了する。呼制御装置４００は、被切断者に対してＢＹＥを送信する（Ｓ１１０４）。呼制御装置４００は、被切断者から２００ ＯＫを受信する（Ｓ１１０５）。呼制御装置４００は、ＩＮＶＩＴＥ受信履歴情報テーブル５００から被切断者発信のＩＮＶＩＴＥのデータを削除し（Ｓ１１０６）、被切断者と呼制御装置４００のセッションを終了する。電話端末Ａおよび電話端末Ｂのセッションが終了した後に、呼制御装置４００は、衝突管理情報テーブル６００より電話端末Ａと電話端末Ｂの呼衝突データを削除し（Ｓ１１０７）、待機中に遷移する。

図１０を参照して、通常呼接続中の呼制御装置における呼切断処理を説明する。図１０において、呼制御装置４００は、切断者よりＢＹＥを受信する（Ｓ１２０１）。呼制御装置４００は、切断者に対して２００ ＯＫを送信する（Ｓ１２０２）。呼制御装置４００は、被切断者宛にＢＹＥを送信する（Ｓ１２０３）。呼制御装置４００は、被切断者より２００ ＯＫを受信する（Ｓ１２０４）。これで電話端末Ａと衝突呼処理中の呼制御装置４００との接続が切れるため、呼制御装置４００は、最後にＩＮＶＩＴＥ受信履歴情報テーブル５００のＩＮＶＩＴＥ（Ａ→Ｂ）のデータを削除し（Ｓ１２０５）、待機中へ戻る。

以下、経由呼制御装置数１かつネットワーク外衝突と、経由呼制御装置数２かつネットワーク内衝突と、のそれぞれの衝突形態における実施例をＳＩＰシーケンスを用いて説明する。

図１１を参照して、経由呼制御装置数１かつネットワーク外衝突発生時の呼制御装置の衝突処理を説明する。図１１において、電話端末１００−ａは、呼制御装置４００にＩＮＩＶＴＥ（ａ→ｂ）を送信する（Ｓ３０１）。電話端末１００−ｂは、呼制御装置４００にＩＮＩＶＴＥ（ｂ→ａ）を送信する（Ｓ３０２）。呼制御装置４００は、電話端末１００−ｂにＩＮＩＶＴＥ（ａ→ｂ）を送信する（Ｓ３０３）。呼制御装置４００は、呼衝突を検出し、電話端末１００−ｂに１８０Ｒｉｎｇｉｎｇ（ｂ→ａ）を送信する（Ｓ３０４）。呼制御装置４００は、電話端末１００−ａに１８０Ｒｉｎｇｉｎｇ（ａ→ｂ）を送信する（Ｓ３０５）。電話端末１００−ｂは、ＲＢＴを鳴動する（Ｓ３０６）。電話端末１００−ａは、ＲＢＴを鳴動する（Ｓ３０７）。電話端末１００−ｂは、その時点で発信中であるため着信に応答できず、呼制御装置４００に４８６ＢｕｓｙＨｅｒｅ（ａ→ｂ）を送信する（Ｓ３０８）。呼制御装置４００は、発信電話端末である電話端末１００−ａには送信しないまま電話端末１００−ｂにＡＣＫ（ａ→ｂ）を送信する（Ｓ３０９）。

電話端末１００−ｂがＡＣＫ（ａ→ｂ）を受信することで呼制御装置４００と電話端末１００−ｂの区間の呼制御装置４００からのＩＮＶＩＴＥ（ａ→ｂ）に始まるセッション確立処理は中止される。セッション確立処理は、電話端末１００−ａと呼制御装置４００の区間は、電話端末１００−ａからのＩＮＶＩＴＥ（ａ→ｂ）によるセッション確立処理が、電話端末１００−ａと呼制御装置４００の区間は電話端末１００−ｂからのＩＮＶＩＴＥ（ｂ→ａ）によるセッション確立処理が、それぞれ続行される。

破線で囲われた部分、Ａ、Ｂ、Ｃは、それぞれ、（Ａ）２つのＩＮＶＩＴＥがセッション情報を含む場合、（Ｂ）ＩＮＶＩＴＥ（ｂ→ａ）のみがセッション情報を含む場合、（Ｃ）２つのＩＮＶＩＴＥがどちらもセッション情報を含まない場合、による処理である。

（Ａ）において、呼制御装置４００は、電話端末１００−ａに電話端末１００−ｂのセッション情報が含まれた２００ ＯＫ（ａ→ｂ）を送信する（Ｓ３１０）。呼制御装置４００は、電話端末１００−ｂに電話端末１００−ａのセッション情報が含まれた２００ ＯＫ（ｂ→ａ）を送信する（Ｓ３１２）。電話端末１００−ａは、呼制御装置４００にＡＣＫ（ａ→ｂ）を送信する（Ｓ３１３）。電話端末１００−ｂは、呼制御装置４００にＡＣＫ（ｂ→ａ）を送信する（Ｓ３１４）。

（Ｂ）において、呼制御装置４００は、電話端末１００−ａに電話端末１００−ｂのセッション情報を含む２００ ＯＫ（ａ→ｂ）を送信する（Ｓ３２０）。電話端末１００−ａは、呼制御装置４００に電話端末１００−ａのセッション情報を記載したＡＣＫ（ａ→ｂ）を送信する（Ｓ３２１）。呼制御装置４００は、電話端末１００−ｂに２００ ＯＫ（ｂ→ａ）を送信する（Ｓ３２２）。電話端末１００−ｂは、呼制御装置４００にＡＣＫ（ｂ→ａ）を送信する（Ｓ３２３）。

（Ｃ）において、呼制御装置４００は、電話端末１００−ａにダミーのセッション情報を含む２００ ＯＫ（ａ→ｂ）を送信する（Ｓ３３０）。電話端末１００−ａは、呼制御装置４００に電話端末１００−ａのセッション情報を記載したＡＣＫ（ａ→ｂ）を送信する（Ｓ３３１）。呼制御装置４００は、電話端末１００−ａにセッション情報のないｒｅ‐ＩＮＶＩＴＥ（ｂ→ａ）を送信する（Ｓ３３２）。電話端末１００−ａは、呼制御装置４００に電話端末１００−ａのセッション情報が記載された２００ ＯＫ（ｂ→ａ）を送信する（Ｓ３３３）。呼制御装置４００は、電話端末１００−ｂに電話端末１００−ａのセッション情報が記載された２００ ＯＫ（ｂ→ａ）を送信する（Ｓ３３４）。電話端末１００−ｂは、呼制御装置４００に電話端末１００−ｂのセッション情報を記載したＡＣＫ（ｂ→ａ）を送信する（Ｓ３３５）。呼制御装置４００は、電話端末１００−ａに電話端末１００−ｂのセッション情報を記載したＡＣＫ（ｂ→ａ）を送信する（Ｓ３３６）。
ステップＳ３１４、３２３、３３６のあと、電話端末１００−ａと電話端末１００−ｂとの間の通話が開始される。

図１２を参照して、経由呼制御装置数２かつネットワーク内衝突が発生したときの呼制御装置の衝突処理を説明する。ここで、ＩＮＶＩＴＥ（ａ→ｂ）の２００ ＯＫ送信優先度が高いものとする。また衝突処理継続判定においては２００ ＯＫ送信優先度の高いＩＮＶＩＴＥを先に受信した呼制御装置が処理を停止するものとする。

図１２において、電話端末１００−ａは、呼制御装置４００−ａにＩＮＶＩＴＥ（ａ→ｂ）を送信する（Ｓ３５１）。電話端末１００−ｂは、呼制御装置４００−ｂにＩＮＶＩＴＥ（ｂ→ａ）を送信する（Ｓ３５２）。呼制御装置４００−ｂは、呼制御装置４００−ａにＩＮＶＩＴＥ（ｂ→ａ）を送信する（Ｓ３５３）。呼制御装置４００−ａは、呼制御装置４００−ｂにＩＮＶＩＴＥ（ａ→ｂ）を送信する（Ｓ３５４）。ＩＮＶＩＴＥ（ａ→ｂ）を受信した呼制御装置４００−ａは、衝突を検知し、呼制御装置４００−ｂに１８０Ｒｉｎｇｉｎｇ（ｂ→ａ）を送信する（Ｓ３５５）。呼制御装置４００−ｂは、衝突を検知し、電話端末１００−ｂに１８０Ｒｉｎｇｉｎｇ（ｂ→ａ）を送信する（Ｓ３５６）。呼制御装置４００−ａは、電話端末１００−ａに１８０Ｒｉｎｇｉｎｇ（ａ→ｂ）を送信する（Ｓ３５７）。呼制御装置４００−ｂは、呼制御装置４００−ａに１８０Ｒｉｎｇｉｎｇ（ａ→ｂ）を送信する（Ｓ３５８）。電話端末１００−ｂは、ＲＢＴを鳴動する（Ｓ３５９）。電話端末１００−ａは、ＲＢＴを鳴動する（Ｓ３６０）。

１８０Ｒｉｎｇｉｎｇ（ａ→ｂ）を受信した衝突検知後の呼制御装置４００−ａと１８０Ｒｉｎｇｉｎｇ（ｂ→ａ）を受信した衝突検知後の呼制御装置４００−ｂは、ネットワーク内衝突であると判断する。

図１３ないし図１５を参照して、図１２以降のシーケンスを説明する。ここで、図１３は、２つのＩＮＶＩＴＥにセッション情報を含む場合、図１４は、ＩＮＶＩＴＥ（ａ→ｂ）のみがセッション情報を含む場合、図１５は、２つのＩＮＶＩＴＥのどちらもセッション情報を含まない場合、の処理シーケンスである。

図１３において、呼制御装置４００−ａと呼制御装置４００−ｂは、ともに衝突検知後であり、電話端末１００−ａと電話端末１００−ｂのセッション情報を取得している。このため、呼制御装置４００−ａは、呼制御装置４００−ｂに２００ ＯＫ（ｂ→ａ）を送信する（Ｓ３８１）。呼制御装置４００−ｂは、電話端末１００−ｂに２００ ＯＫ（ｂ→ａ）を送信する（Ｓ３８２）。呼制御装置４００−ａは、電話端末１００−ａに２００ ＯＫ（ａ→ｂ）を送信する（Ｓ３８３）。呼制御装置４００−ｂは、呼制御装置４００−ａに２００ ＯＫ（ａ→ｂ）を送信する（Ｓ３８４）。

ＩＮＶＩＴＥ（ａ→ｂ）の２００ ＯＫ送信優先度が高いと判定した呼制御装置４００−ｂは、呼制御装置４００−ａにＣＡＮＣＥＬ（ｂ→ａ）を送信する（Ｓ３８５）。呼制御装置４００−ａは、呼制御装置４００−ｂに２００ ＯＫ（ｂ→ａ）を送信する（Ｓ３８６）。呼制御装置４００−ａは、呼制御装置４００−ｂに４８７ＲｅｑｕｅｓｔＴｅｒｍｉｎａｔｅｄ（ｂ→ａ）を送信する（Ｓ３８７）。呼制御装置４００−ｂは、呼制御装置４００−ａにＡＣＫ（ｂ→ａ）を送信する（Ｓ３８８）。呼制御装置４００−ａは、呼衝突処理を実施する必要がなくなったため衝突処理を停止する（Ｓ３８９）。電話端末１００−ａは、呼制御装置４００−ａにＡＣＫ（ａ→ｂ）を送信する（Ｓ３９０）。電話端末１００−ｂは、呼制御装置４００−ｂにＡＣＫ（ｂ→ａ）を送信する（Ｓ３９１）。呼制御装置４００−ａは、呼制御装置４００−ｂにＡＣＫ（ａ→ｂ）を送信する（Ｓ３９２）。以上により、電話端末１００−ａと電話端末１００−ｂ間での通話が可能となる。

図１４を参照して、電話端末１００−ａのセッション情報のみが取得できているシーケンスを説明する。図１４において、呼制御装置４００−ａと呼制御装置４００−ｂは、電話端末１００−ａのセッション情報のみを取得している。このため、呼制御装置４００−ｂは、電話端末１００−ｂに２００ ＯＫ（ｂ→ａ、ＳＤＰ）を送信する（Ｓ４０１）。呼制御装置４００−ａは、呼制御装置４００−ｂに２００ ＯＫ（ｂ→ａ、ＳＤＰ）を送信する（Ｓ４０２）。呼制御装置４００−ｂは、呼制御装置４００−ａにＣＡＮＣＥＬ（ｂ→ａ）を送信する（Ｓ４０３）。呼制御装置４００−ａは、呼制御装置４００−ｂに２００ ＯＫ（ｂ→ａ）を送信する（Ｓ４０４）。呼制御装置４００−ａは、呼制御装置４００−ｂに４８７ＲｅｑｕｅｓｔＴｅｒｍｉｎａｔｅｄ（ｂ→ａ）を送信する（Ｓ４０５）。呼制御装置４００−ｂは、呼制御装置４００−ａにＡＣＫ（ｂ→ａ）を送信する（Ｓ４０６）。呼制御装置４００−ａは、呼衝突処理を実施する必要がなくなったため衝突処理を停止する（Ｓ４０７）。電話端末１００−ｂは、呼制御装置４００−ｂにセッション情報を含んだＡＣＫ（ｂ→ａ、ＳＤＰ）を送信する（Ｓ４０８）。呼制御装置４００−ｂは、呼制御装置４００−ａに、電話端末１００−ｂのセッション情報を記載した２００ ＯＫ（ａ→ｂ、ＳＤＰ）を送信する（Ｓ４０９）。呼制御装置４００−ａは、衝突処理を中止しているのでそのまま電話端末１００−ａに２００ ＯＫ（ａ→ｂ、ＳＤＰ）を送信する（Ｓ４１０）。電話端末１００−ａは、呼制御装置４００−ａにＡＣＫ（ａ→ｂ）を送信する（Ｓ４１１）。呼制御装置４００−ａは、呼制御装置４００−ｂにＡＣＫ（ａ→ｂ）を送信する（Ｓ４１２）。以上により、電話端末１００−ａと電話端末１００−ｂ間での通話が可能となる。

図１５を参照して、２つのＩＮＶＩＴＥのどちらもセッション情報を含まない場合の処理シーケンスを説明する。図１５において、ここでは、呼制御装置４００−ａが処理を中止し、４００−ｂが処理を継続する。呼制御装置４００−ａは、電話端末１００−ａにダミーのセッション情報を含んだ２００ ＯＫ（ａ→ｂ、ダミーＳＤＰ）を送信する（Ｓ４３１）。呼制御装置４００−ｂは、呼制御装置４００−ａにダミーのセッション情報を含んだ２００ ＯＫ（ａ→ｂ、ダミーＳＤＰ）を送信する（Ｓ４３２）。呼制御装置４００−ｂは、呼制御装置４００−ａにＣＡＮＣＥＬ（ｂ→ａ）を送信する（Ｓ４３３）。呼制御装置４００−ａは、呼制御装置４００−ｂに２００ ＯＫ（ｂ→ａ）を送信する（Ｓ４３４）。呼制御装置４００−ａは、呼制御装置４００−ｂに４８７ＲｅｑｕｅｓｔＴｅｒｍｉｎａｔｅｄ（ｂ→ａ）を送信する（Ｓ４３５）。呼制御装置４００−ｂは、呼制御装置４００−ａにＡＣＫ（ｂ→ａ）を送信する（Ｓ４３６）。呼制御装置４００−ａは、衝突処理を中止する（Ｓ４３７）。電話端末１００−ａは、呼制御装置４００−ａに電話端末１００−ａのセッション情報を記載したＡＣＫ（ａ→ｂ、ＳＤＰ）を送信する（Ｓ４３８）。呼制御装置４００−ａは、呼制御装置４００−ｂにＡＣＫ（ａ→ｂ、ＳＤＰ）を送信する（Ｓ４３９）。

呼制御装置４００−ｂは、電話端末１００−ａに電話端末１００−ｂのセッション情報を伝えるために、呼制御装置４００−ａにｒｅ−ＩＮＶＩＴＥ（ｂ→ａ）を送信して（Ｓ４４０）、セッションの更新を図る。呼制御装置４００−ａは、電話端末１００−ａにｒｅ−ＩＮＶＩＴＥ（ｂ→ａ）を送信する（Ｓ４４１）。電話端末１００−ａは、呼制御装置４００−ａに、セッション情報を含む２００ ＯＫ（ｂ→ａ、ＳＤＰ）を送信する（Ｓ４４２）。呼制御装置４００−ａは、呼制御装置４００−ｂに２００ ＯＫ（ｂ→ａ、ＳＤＰ）を送信する（Ｓ４４３）。呼制御装置４００−ｂは、電話端末１００−ｂに２００ ＯＫ（ｂ→ａ、ＳＤＰ）を送信する（Ｓ４４４）。電話端末１００−ｂは、呼制御装置４００−ｂに、電話端末１００−ｂのセッション情報の記載されたＡＣＫ（ｂ→ａ、ＳＤＰ）を送信する（Ｓ４４５）。呼制御装置４００−ｂは、呼制御装置４００−ａにＡＣＫ（ｂ→ａ、ＳＤＰ）を送信する（Ｓ４４６）。呼制御装置４００−ａは、電話端末１００−ａにＡＣＫ（ｂ→ａ、ＳＤＰ）を送信する（Ｓ４４７）。以上により、電話端末１００−ａと電話端末１００−ｂ間での通話が可能となる。

本実施例によれば、相互発信による呼衝突発生時でも通話が開始できる。また、既存電話サービスシステムに適用するにあたりユーザーへの負担がない。さらに、電話端末への置き換えを促す時間および費用が不要である。

１００…電話端末、２００…ネットワーク、４００…呼制御装置、４１０…呼制御信号受信部、４２０…呼制御信号解析部、４３０…ユーザー情報検索部、４４０…ルーティング表保持部、４５０…呼制御信号編集部、４６０…呼制御信号送信部、４７０…呼衝突検知部、４８０…呼衝突処理部、５００…ＩＮＶＩＴＥ受信履歴情報テーブル、６００…衝突管理情報テーブル、７００…通信システム。

Claims (5)

1. 電話端末間の呼制御信号を中継し電話端末の接続処理を行う呼制御装置において、
   呼制御信号を外部通信装置より受信する呼制御信号受信部と、
   受信した呼制御信号の内容を解析する呼制御信号解析部と、
   受信した呼制御信号の送信先を検索するユーザー情報検索部と、
   前記呼制御信号解析部および前記ユーザー情報検索部より得られた情報をもとに呼制御信号を編集する呼制御信号編集部と、
   呼制御信号を外部通信装置へ送信する呼制御信号送信部と、
   接続処理中の呼の中に発信電話端末と着信電話端末との組み合わせが互いに逆の２つの呼の衝突が発生していることを検知する呼衝突検知部と、
   前記呼衝突検知部が呼衝突を検知したとき、当該呼の接続処理を終了させることなく通話開始させるための制御を行う衝突処理部と、
   を備える呼制御装置。
2. 請求項１に記載の呼制御装置であって、
   前記衝突処理部は、
   衝突した当該呼を発信した電話端末と衝突を検知した当該呼制御装置の区間でセッションを確立させ、
   衝突した２つの呼のそれぞれに対するセッションの確立を行い、
   前記セッションの確立の過程において２つセッション間でのセッション情報の交換を行い、
   当該衝突を検知した呼制御装置数の特定を行うことを特徴とする呼制御装置。
3. 請求項２に記載の呼制御装置であって、
   衝突を検知した呼制御装置数が１であったとき、接続処理を継続し、
   衝突を検知した呼制御装置数が２であったとき、一方の呼制御装置は、接続処理を継続し、他方の呼制御装置は、接続処理を中止することを特徴とする呼制御装置。
4. 請求項３に記載の呼制御装置であって、
   当該呼制御装置間の判定が一意的であり、他方の当該呼制御装置が継続と判断する場合は当方の当該呼制御装置は中止と判断し、他方の当該呼制御装置が中止と判断する場合は当方の当該呼制御装置は継続と判断することを特徴とする呼制御装置。
5. 請求項２に記載の呼制御装置であって、
   接続要求信号内のセッション情報の有無に応じた接続処理とセッション情報交換を行うことを特徴とする呼制御装置。

Images