JP4136798B2

JP4136798B2 - Relay device with voice guidance function

Info

Publication number: JP4136798B2
Application number: JP2003159883A
Authority: JP
Inventors: 雅明木村
Original assignee: Nakayo Telecommunications Inc
Current assignee: Nakayo Telecommunications Inc
Priority date: 2003-06-04
Filing date: 2003-06-04
Publication date: 2008-08-20
Anticipated expiration: 2023-06-04
Also published as: JP2004363941A

Description

【０００１】
【発明の属する技術分野】
本発明は、ＩＰ（Internet Protocol）ネットワーク上での音声通話の転送技術に関する。
【０００２】
【従来の技術】
ＩＰネットワーク上で音声通話をはじめとするマルチメディアセッションの確立、変更、切断を実現するプロトコルとしてＨ.323やＳＩＰ（Session Initiation Protocol）などが知られている。これらのプロトコルは、ＩＰネットワークに接続された端末間のあらゆる種類のセッションの確立が可能であり、最近では、音声セッション、すなわち、ＶｏＩＰ(Voice over Internet Protocol)技術を用いたインターネット電話のネットワークにも採用されている。
【０００３】
ＶｏＩＰによるネットワークに、例えば、ＳＩＰプロトコルを用いた場合の一般的な接続例を図１０に示す。本図に示すように、ＶｏＩＰネットワークは、インターネットを介して接続されるイントラネット、端末ｘ、端末ｙなどのｐｒｏｘｙサーバとして働くＳＩＰｐｒｏｘｙサーバＣなどを備える。また、イントラネット内には、ＳＩＰｐｒｏｘｙサーバＡ、ＳＩＰｐｒｏｘｙサーバＢなどがあり、それぞれ、ＬＡＮで接続された端末ａ１、ａ２・・、および、ｂ１、ｂ２・・・のｐｒｏｘｙサーバとして処理を行なう。
【０００４】
図１０の例において、社内の内線電話などのイントラネット内では、ＳＩＰｐｒｏｘｙサーバＡと、ＳＩＰｐｒｏｘｙサーバＢとが接続され、これらを経由して、異なるＳＩＰｐｒｏｘｙサーバに接続されている端末同士も音声セッションの確立、すなわち、通話が可能となっている。
【０００５】
また、図１０の例では、イントラネット内の各端末ａ１、ａ２、・・・・、ｂ１、ｂ２、・・・・は、それぞれが接続されているＳＩＰｐｒｏｘｙサーバを経由して、インターネットを介してイントラネット外の端末ｘ、ｙ、・・・とも、ＳＩＰｐｒｏｘｙサーバＣを介して同じプロトコルを用いて直接通話が可能である。
【０００６】
ここで、ＳＩＰなどのプロトコルは、セッションの転送機能を有し、例えば図１１（ａ）に示すように、端末ａ１と端末ｂ１とが通話をしている際に、当該通話を端末ｂ１から端末ｂ２へと転送したり、また、図１１（ｂ）に示すように、端末ａ１と端末ｘとが通話をしている際に、当該通話を端末ｘから端末ｙへ転送したりすることが可能である（例えば、非特許文献１参照）。
【０００７】
【非特許文献１】
R. Sparks (dynamicsoft), A. Johnston (WorldCom) "Session Initiation Protocol Call Control Transfer draft-ietf-sipping-cc-transfer-01" [online] February 11, 2003 SIPPING WG Internet-Draft Expires: August 12, 2003、インターネット＜ＵＲＬ：http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-01.txt
【０００８】
【発明が解決しようとする課題】
非特許文献１に示すように、例えばＳＩＰプロトコルでは、ＲＥＦＥＲというリクエストを有し、転送の際には、転送元端末が被転送端末に転送先端末とのセッションを確立するよう指示を与える。すなわち、端末ｂ１が端末ａ１とが通話中に、その通話を端末ｂ２に転送する場合、端末ｂ１は、端末ａ１にＲＥＦＥＲを用いて転送の指示を与え、端末ａ１は端末ｂ２と新たにセッションを確立する。
【０００９】
端末ａ１内では、ＲＥＦＥＲを受信すると転送の処理、すなわち、新たに端末ｂ１とのセッションの確立を自動的に行なうため、端末ａ１のユーザはそのような転送が行なわれていることを認識しないことがある。
【００１０】
例えば、図１０の例において、イントラネット内では、ＳＩＰｐｒｏｘｙサーバにおいて、転送先として不適な端末は予め転送不能なように設定することも容易である。
【００１１】
しかし、ＳＩＰでは、インターネットを介して外部の管理状態が不明な端末ｘ、端末ｙなどとの接続も可能であるため、図１１（ｂ）に示すように、これらの端末間でも、転送は行なわれることがある。そして、端末ａ１の利用者にとって、この転送は意図しないものである場合がある。
【００１２】
上記事情に鑑み、本発明は、インターネット電話において、不特定者への意図しない転送を回避可能にすることを目的とする。
【００１３】
【課題を解決するための手段】
上記課題を解決するために、本発明は、端末間の呼を中継する装置内に音声により転送を通知する機能を組み込み、端末の利用者に転送がなされることを通知する。
【００１４】
すなわち、中継装置内に自身が管理している端末のシーケンスを監視し、転送を開始する要求がなされたことを検知すると、音声ガイダンスなどを当該端末に送信し、端末の利用者に注意を促すよう構成する。
【００１５】
具体的には、ＶｏＩＰ(Voice over Internet Protocol)ネットワークにおいて、端末を管理するとともに、前記自身が管理している端末が他の端末とセッションを確立、変更、および、切断する際に、要求および応答の中継を行なう中継装置であって、前記自身が管理している端末とセッションを確立している他の端末から、前記自身が管理している端末に当該セッションの転送要求がなされたかを監視する転送監視手段と、前記転送監視手段において前記転送要求が検出された後に、前記自身が管理している端末から当該転送要求の中で指示された転送先にセッションを確立する要求が送出された場合、当該自身が管理している端末に前記転送がなされていることを通知する転送通知手段と
を備えることを特徴とする中継装置を提供する。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。なお、以下の実施形態においては、端末をＩＰ電話とし、ＩＰ電話サービスを実現するＶｏＩＰ技術のうち、特に音声パスを確立するためのシグナリングプロトコル（呼制御手順）として、ＳＩＰを用いた場合を例にあげ、説明する。
【００１７】
本実施形態における、ＶｏＩＰネットワークの接続例を図１に示す。
【００１８】
イントラネット５００は、ＳＩＰ端末３００ａ１、ＳＩＰ端末３００ａ２・・・などをＬＡＮで接続するＳＩＰｐｒｏｘｙ１００Ａと、ＳＩＰ端末３００ｂ１、ＳＩＰ端末３００ｂ２・・・などをＬＡＮで接続するＳＩＰｐｒｏｘｙ１００Ｂとを備え、インターネット６００に接続している。また、インターネット６００には、端末３００ｘ、端末３００ｙのｐｒｏｘｙサーバとして動作するＳＩＰｐｒｏｘｙ１００Ｃが接続している。もちろん、インターネット６００に接続されるＳＩＰｐｒｏｘｙ、ＳＩＰｐｒｏｘｙに接続される端末の台数は、限定されない。
【００１９】
なお、以下において、各ＳＩＰｐｒｏｘｙ１００Ａ、１００Ｂ、１００Ｃは、特に区別が必要ない場合は、ＳＩＰｐｒｏｘｙ１００で代表する。
【００２０】
また、各端末も同様に、端末３００で代表する。ここで、本実施形態においては端末３００は、２つの端末３００間でメッセージを交換する際に、リクエストを送信する機能であるＵＡＣ(User Agent Client)と、レスポンスを返信する機能であるＵＡＳ(User Agent Server)とを備える。
【００２１】
次に、本実施形態におけるＳＩＰｐｒｏｘｙ１００の機能を説明する。図２は、本実施形態におけるＳＩＰｐｒｏｘｙ１００の機能構成図である。
【００２２】
本図に示すように、ＳＩＰｐｒｏｘｙ１００は、ＳＩＰロケーションサーバ機能部１１０、ＳＩＰレジストラサーバ機能部１２０、ＳＩＰｐｒｏｘｙサーバ機能部１３０、ＳＩＰｐｒｏｘｙ制御部１４０、転送手順監視部１５０、ガイダンス制御部１６０、音源１７０、ＵＤＰ／ＩＰ（User Datagram Protocol / Internet Protocol）制御部１８０、イーサネット(Ethernet:登録商標）制御部１９０とを備える。
【００２３】
ＳＩＰレジストラサーバ機能部１２０は、各端末３００のロケーション情報の登録を制御するもので、端末３００から、利用者のSIP-URI（SIP上のアドレス）とロケーション（IPアドレスまたはFQDN（ドメイン名））との関連を取得すると、ＳＩＰロケーションサーバ機能部１１０に管理させる。
【００２４】
ＳＩＰロケーションサーバ機能部１１０は、ＳＩＰレジストラサーバ機能部１２０から取得した、利用者のSIP-URIをロケーションと対応させて蓄積し、要求に応じて提供するものである。後述するＳＩＰプロクシサーバ機能部１３０は、端末３００から接続要求を受信した際、ＳＩＰロケーションサーバ機能部１１０を参照し、接続先端末のロケーションを取得し、セッションを確立する。
【００２５】
ＳＩＰｐｒｏｘｙサーバ機能部１３０は、ＵＡＣに対してはＵＡＳとして動作し、ＵＡＳに対してはＵＡＣとして動作する。それぞれから発せられた要求および応答を、ＳＩＰｐｒｏｘｙ制御機能部１４０に受け渡し、ＳＩＰｐｒｏｘｙ制御機能部１４０からの指示に従い、発信する。
【００２６】
ＳＩＰｐｒｏｘｙ制御機能部１４０は、従来のＳＩＰｐｒｏｘｙ制御機能と同様、ＳＩＰｐｒｏｘｙサーバ機能部１３０のＵＡＳ、ＵＡＣ間のルート制御を行なう。すなわち、ＵＡＣから送信された要求をＵＡＳに、ＵＡＳから送信された応答をＵＡＣに、ルーティングを決定して中継し、要求に対し、必要があれば、自ら応答を返信する。
【００２７】
さらに、本実施形態のＳＩＰｐｒｏｘｙ制御機能部１４０は、ＳＩＰｐｒｏｘｙサーバ機能部１３０から受け取った要求および応答を転送手順監視部１５０に受け渡し、転送手順監視部１５０からの情報に従って、処理中の呼が転送呼である場合、ガイダンス制御部１６０を動作させる。
【００２８】
転送手順監視部１５０は、ｐｒｏｘｙ制御の過程で転送手順が行なわれているかを監視する。具体的には、ＳＩＰｐｒｏｘｙ制御機能部１４０から、ＳＩＰｐｒｏｘｙサーバ機能部１３０が受け取った要求および応答を全て受け取り、転送の要求であるＲＥＦＥＲであるか否か判別する。そして、ＲＥＦＥＲであった場合、参照先（転送先）と相手方端末とのアドレスを抽出して記憶する。
【００２９】
また、ＲＥＦＥＲを受信し、参照先および相手方端末のアドレスが記憶されている場合、後述するＩＮＶＩＴＥを受け取った際に、記憶している相手方端末のアドレスと参照先端末のアドレスとの組み合わせの中に、ＩＮＶＩＴＥに記述されている送信元端末のアドレスと接続先端末のアドレスとの組み合わせと一致するものがあるか否か判別し、一致した場合、転送呼であると判断し、ＳＩＰｐｒｏｘｙ制御機能部１４０に通知する。
【００３０】
ガイダンス制御部１６０は、ＳＩＰｐｒｏｘｙ制御機能部１４０の指示に従って、音源１７０が管理する音源データを用いて音声出力とＲＴＰ（Real-time Transport Protocol）制御とを行なう。
【００３１】
音源１７０は、音源データを管理するもので、ＵＡＣ、ＵＡＳに出力する音源そのものをデータとして保持していてもよいし、必要に応じて合成してもよい。
【００３２】
ＵＤＰ／ＩＰ制御部１８０、イーサネット（登録商標）制御部１９０は、それぞれ、イーサネット（登録商標）を介して受信したＶｏＩＰデータのそれぞれのレイヤ処理を行なう。なお、本実施形態では、プロトコルは、ＵＤＰではなく、ＴＣＰであってもよい。
【００３３】
また、上記の構成において、ＳＩＰロケーションサーバ機能部１１０、ＳＩＰレジストラサーバ機能部１２０、ＳＩＰｐｒｏｘｙサーバ機能部１３０は、基本的に従来のＳＩＰのそれぞれのサーバと同様の機能を有するものであるため、ここでは、詳細に説明しない。なお、ＳＩＰロケーションサーバ機能部１１０およびＳＩＰレジストラサーバ機能部１２０は、別個独立した装置としてもよい。
【００３４】
次に、本実施形態のＳＩＰｐｒｏｘｙ１００のハードウエア構成の一例を図３に示す。
【００３５】
本図に示すように、ＳＩＰｐｒｏｘｙ１００は、ＣＰＵ４１０と、メモリ４２０と、音源４３０と、イーサネット（登録商標）インタフェース４４０とを備える。
【００３６】
イーサネット（登録商標）インタフェース４４０は、イーサネット（登録商標）を介して受信したイーサフレームからパケットを取り出してＣＰＵに送出し、また、逆にＣＰＵから受け取ったパケットをイーサフレーム化してイーサネット（登録商標）上に送出する。
【００３７】
音源４３０は、音源、または、合成して音源として出力可能なデータを格納する。
【００３８】
メモリ４２０は、図２に記載の各機能を実現するプログラムおよびデータを蓄積する。そして、ＣＰＵ４１０は、メモリ４２０内に蓄積されたプログラムを実行することで、上記各機能を実現する。
【００３９】
なお、本ハードウエア構成は、ＳＩＰｐｒｏｘｙ１００をＳＩＰｐｒｏｘｙサーバとして単体として実現する場合の例であるが、これに限られない。例えば、ＣＰＵ、メモリ、イーサネット（登録商標）インタフェースを持ち、音源を内蔵しているかまたは音声入出力インタフェースを備える一般のパーソナルコンピュータなどの情報処理装置上でも実現可能である。
【００４０】
次に、本実施形態の処理シーケンスについて説明する。図４および図５を用い、通常の発信シーケンスと、本実施形態の、ＲＥＦＥＲ受信後の発信シーケンスとを説明する。
【００４１】
なお、以下において、ＩＮＶＩＴＴＥ、ＡＣＫ、ＢＹＥ、ＣＡＮＣＥＬ，ＲＥＦＥＲ、ＮＯＴＩＦＹは、ＳＩＰで定義されているリクエストで、以下の目的で用いられるものである。
ＩＮＶＩＴＥ：接続を希望する相手方端末との接続を開始する。ＩＮＶＩＴＥの送信元の端末のアドレスと、接続を希望する相手方の端末のアドレスとを備える。
ＡＣＫ：ＩＮＶＩＴＥに対する最終レスポンスを受信したことを知らせる。
ＢＹＥ：セッションを中断する。ここで、２者間通信では、片方がＢＹＥを用いて中断を申し出ると、セッションは中断する。
ＣＡＮＣＥＬ：ＩＮＶＩＴＥの中断を指示する。
ＲＥＦＥＲ：音声セッションを確立中の端末が、相手方端末に、参照先（転送先）を指示する。なお、ＲＥＦＥＲは、相手方端末のアドレスと転送先のアドレスとの情報を備える。
ＮＯＴＩＦＹ：経過情報を通知する。
【００４２】
上記のリクエストを発信する側がクライアントであり、サーバは、リクエストを受信すると、１つあるいは複数のレスポンスを発行する。レスポンスは３桁の状態コードと返信理由とからなり、リクエストに対して、経過情報として送出される中間応答と、最終的な応答として送出される最終応答とがある。本実施形態で用いられるものは、それぞれ、以下の意味を持つ。
１００ Trying：試行中を示す中間応答で、例えばＩＮＶＩＴＥリクエストなどを受信した際、すぐに処理結果を返信できない場合、まず、受信したことを送信元端末に通知するために返信される。
１８０ Ringing：呼出中を示す中間応答である。
１８３ Session Progress：セッション状況を示す中間応答である。
２００ＯＫ：リクエストの成功を示す最終応答である。
２０２ Accepted：リクエストを受け入れたことを示す最終応答である。
４０７ Proxy Authentication Required[407ｐｒｏｘｙ認証要求]：ｐｒｏｘｙ認証を要求する最終応答で、送信元端末を認証する情報とともに返信される。
４８７ Request Terminated：リクエストの終了を示す最終応答である。
【００４３】
図４は、ＳＩＰを用いてセッションを開始する際に、端末３００とＳＩＰｐｒｏｘｙ１００との間でやりとりされる、通常の要求と応答のシーケンスを説明するための図である。ＳＩＰでは、発信元端末からＩＮＶＩＴＥが出されると、ｐｒｏｘｙサーバは、認証処理後、当該ＩＮＶＩＴＥを接続先の端末に中継する。
【００４４】
まず、端末３００（ＵＡＣ）は、利用者の発信の意思を受け付けると、ＳＩＰｐｒｏｘｙ１００にＩＮＶＩＴＥを送信する（ステップ３００１）。ＳＩＰｐｒｏｘｙ制御部１４０は、ＩＮＶＩＴＥを受信すると、端末３００に対して、ＵＡＳとして動作し、発信する端末３００を認証する手順を行うため、ＳＩＰｐｒｏｘｙサーバ機能部１３０に、４０７ｐｒｏｘｙ認証要求を発信元端末３００に返信させる（ステップ３００２）。この４０７ｐｒｏｘｙ認証要求には、端末３００を認証する情報が含まれている。
【００４５】
４０７認証要求を受信すると、端末３００は、ＡＣＫをＳＩＰｐｒｏｘｙ１００に送出する（ステップ３００３）。ここでは、ＡＣＫは、ステップ３００１で送出したＩＮＶＩＴＥに対し、４０７ｐｒｏｘｙ認証要求のレスポンスを受信したことをＳＩＰｐｒｏｘｙ１００に通知するために送出される。
【００４６】
その後、端末３００は、ステップ３００２で送出された４０７ｐｒｏｘｙ認証要求に含まれている認証情報に基づいて認証の情報を付加したＩＮＶＩＴＥをＳＩＰｐｒｏｘｙ１００に送出する（ステップ３００４）。それを受け、ＳＩＰｐｒｏｘｙ１００のＳＩＰｐｒｏｘｙ制御部１４０はＳＩＰｐｒｏｘｙサーバ機能部１３０に、折り返し、１００Ｔｒｙｉｎｇレスポンスを端末３００に送出させる（ステップ３００５）とともに、ＩＮＶＩＴＥを相手先端末のＵＡＳに送出する（ステップ３００６）。
【００４７】
以上が、通常の発信の場合のＵＡＣである端末３００とＳＩＰｐｒｏｘｙ１００との間の処理シーケンスである。
【００４８】
本実施形態では、端末間にＳＩＰｐｒｏｘｙ１００を介入させ、認証を行なってから、相手先端末とセッションを確立する処理を行なう。そして、ＳＩＰｐｒｏｘｙ１００において、端末３００からＲＥＦＥＲを受信した後の最初のＩＮＶＩＴＥを受信した際、この認証手順の間に、端末３００との間に音声パスを形成し、音声信号でガイダンスを送出するよう構成したものである。
【００４９】
この場合の処理の概要を説明するためのシーケンスを図５に示す。
【００５０】
本図に示すように、ＲＥＦＥＲを中継した後、ＵＡＣである端末３００からＩＮＶＩＴＥを受け取る（ステップ４００１）と、ＳＩＰｐｒｏｘｙ制御部１４０は、４０７ｐｒｏｘｙ認証要求を送出する前に、ＳＩＰｐｒｏｘｙサーバ機能部１３０に、１８３Ｐｒｏｇｒｅｓｓを返信させる（ステップ４００２）。そして、ＳＩＰｐｒｏｘｙ制御部１４０は、端末３００とＳＩＰｐｒｏｘｙ１００間に音声パスを形成し、ガイダンス制御部１６０に、音源１７０からガイダンスを送信させる（ステップ４００３）。ガイダンスは、例えば、「転送しています」などの内容で、利用者に当該呼が転送されていることを通知できる内容のものであればよい。そして、端末３００側は、転送が不審な場合は、音声パスが確立し、ガイダンスを再生中に、切断の処理を行なうことができる。
【００５１】
音声パスが確立している最中に、端末３００にて切断の処理がなされなかった場合、ＳＩＰｐｒｏｘｙ制御部１４０は、ＳＩＰｐｒｏｘｙサーバ機能部１３０に、４０７ｐｒｏｘｙ認証要求を送出させ（ステップ４００４）、ＡＣＫとＩＮＶＩＴＥとを受け取り（ステップ４００５、４００６）、１００Ｔｒｙｉｎｇを返信させるとともに、ＵＡＳにＩＮＶＩＴＥを送出させる（ステップ４００７、４００８）。
【００５２】
ここで、以下に、ＳＩＰｐｒｏｘｙ制御部１４０の、ＲＥＦＥＲ受信後、ガイダンスを送出するまでの処理を説明する。
【００５３】
図６は、ＳＩＰｐｒｏｘｙ制御部１４０の処理フローを示す。
【００５４】
ＳＩＰｐｒｏｘｙ制御部１４０は、ＳＩＰｐｒｏｘｙサーバ機能部１３０を介してリクエストを受信する（ステップ６００１）と、受信したリクエストがＲＥＦＥＲであるか否かを、転送手順監視部１５０に判別させる（ステップ６００２）。
【００５５】
ＲＥＦＥＲであった場合、ＲＥＦＥＲに記述されている送信先（相手方）端末のアドレスと参照先端末のアドレスとを転送手順監視部１５０に保存させ（ステップ６００３）、通常のリクエスト処理に戻る。
【００５６】
ステップ６００２において、受信したリクエストがＲＥＦＥＲでない場合、そのリクエストがＩＮＶＩＴＥであるか否か確認させる（ステップ６００４）。ＩＮＶＩＴＥでなければ、通常のリクエスト処理にもどる。
【００５７】
ステップ６００４で、ＩＮＶＩＴＥであれば、当該ＩＮＶＩＴＥの送信元の端末のアドレスおよび受取先端末のアドレスが、それぞれ、ステップ６００３で保存したＲＥＦＥＲの送信先端末のアドレスおよび参照先端末のアドレスと一致するか否か、転送手順監視部１５０に確認させる（ステップ６００５）。一方でも一致しなければ、通常のリクエスト処理にもどる。
【００５８】
ステップ６００５で、両アドレスが一致した場合、すなわち、転送手順監視部１５０から転送呼であるとの返信を得た場合、ＳＩＰｐｒｏｘｙサーバ機能部１３０に１８３Ｐｒｏｇｒｅｓｓを、当該ＩＮＶＩＴＥ送信元の端末に返信させ（ステップ６００６）、ガイダンス制御部１６０に、送信元の端末にＲＴＰによりガイダンスを送出させる（ステップ６００７）。
【００５９】
ガイダンスの送信が終了すると（ステップ６００８）、ＳＩＰｐｒｏｘｙサーバ機能部１３０に、ステップ６００４で受信したＩＮＶＩＴＥの送信元端末に対して４０７ｐｒｏｘｙ認証要求を送信させ（ステップ６００９）、転送手順監視部１５０にステップ６００５で一致を確認したアドレスを削除させる（ステップ６０１０）。
【００６０】
ここで、ステップ６００３におけるＲＥＦＥＲに格納されているアドレスの組の数は限定されない。複数保存が可能である。複数の組が格納されている場合は、ステップ６００５において、格納されている全てのアドレスの組に対して一致の有無をチェックする。
【００６１】
また、ステップ６００７において、ガイダンスが送出されている間は、ＣＡＮＣＥＬの受信が可能である。この間にＣＡＮＣＥＬを受信した場合、ＳＩＰｐｒｏｘｙ制御部１４０は、ＳＩＰｐｒｏｘｙサーバ機能部１３０に、ステップ６００４で受信を判断したＩＮＶＩＴＥに対する処理を中断させる。すなわち、転送を行なわない。
【００６２】
次に、本実施形態において、図１のネットワークで、ＳＩＰｐｒｏｘｙ１００Ａを介して端末３００ａ１から、ＳＩＰｐｒｏｘｙ１００Ｃを介して端末３００ｘに発信して接続してから他の端末３００ｙへの転送に至るまでのシーケンスを図７に従って説明する。
【００６３】
端末３００ａ１とＳＩＰｐｒｏｘｙ１００Ａとの間で、ＩＮＶＩＴＥ、４０７ｐｒｏｘｙ認証要求、ＡＣＫ、ＩＮＶＩＴＥ、１００Ｔｒｙｉｎｇなどのやり取りが図４と同様のシーケンスでなされ、ＳＩＰｐｒｏｘｙ１００Ａにおいて発信元の端末３００ａ１の認証が完了すると（ステップ５００１）、ＳＩＰｐｒｏｘｙ１００Ａは、相手先のＳＩＰｐｒｏｘｙ１００Ｃを介して端末３００ｘにＩＮＶＩＴＥを送信する（ステップ５００２）。
【００６４】
ＳＩＰｐｒｏｘｙ１００Ｃでは、リンガをアクティブにするとともに、ＳＩＰｐｒｏｘｙ１００Ａに１００Ｔｒｙｉｎｇを返し、ＩＮＶＩＴＥを受け取ったことを報告する（ステップ５００３）。
【００６５】
その後、ＳＩＰｐｒｏｘｙ１００Ｃは、１８０Ｒｉｎｇｉｎｇまたは/および１８３ＰｒｏｇｒｅｓｓをＳＩＰｐｒｏｘｙ１００Ａに送出し（ステップ５００４）、受け取ったＳＩＰｐｒｏｘｙ１００Ａは、それらのレスポンスを端末３００ａ１に中継する（ステップ５００５）。
【００６６】
その後、ＳＩＰｐｒｏｘｙ１００Ａは、端末３００ｘの利用者がオフフックなどを行なうことで応答を受け付けた端末ｘからの２００ＯＫのレスポンスを受け取ると、それを端末３００ａ１に送出し（ステップ５００６、５００７）、端末３００ａ１からのＡＣＫを端末３００ｘに中継する（ステップ５００８、５００９）。
【００６７】
以上の手順を終えると、端末３００ａ１は相手先端末３００ｘに直接接続し、ＲＴＰにて端末３００ｘと通話を行なう（ステップ５０１０）。
【００６８】
その後、端末３００ｘは、ステップ５０１０で接続された通話を端末３００ｙに転送するため、転送先の端末の情報が入っているＲＥＦＥＲをＳＩＰｐｒｏｘｙ１００Ａに送出する（ステップ５０１１）。
【００６９】
ＳＩＰｐｒｏｘｙ１００Ａは、このＲＥＦＥＲを中継して端末３００ａ１に送信し（ステップ５０１２）、端末３００ａ１からの２０２Ａｃｃｅｐｔｅｄを端末３００ｘに中継する（ステップ５０１３、５０１４）。そして、ＳＩＰｐｒｏｘｙ１００Ａは、ＲＥＦＥＲに対する端末３００ａ１からのＮＯＴＩＦＹを同じく中継し、折り返し端末３００ｙから発信される２００ＯＫを端末３００ａ１に中継する（ステップ５０１５〜５０１８）。
【００７０】
ＳＩＰｐｒｏｘｙ１００Ａは、ＲＥＦＥＲに付与されている転送先の情報を管理し、端末３００ａ１から転送先端３００ｙへのＩＮＶＩＴＥを受け取ると、先ほど図５において説明したシーケンスを開始する（ステップ５０１９）。
【００７１】
そして、ＳＩＰｐｒｏｘｙ１００Ａは、端末３００ａ１からＩＮＶＩＴＥを受け付けると、１００Ｔｒｙｉｎｇを端末３００ａ１に返すとともに、ＩＮＶＩＴＥを転送先の端末３００ｙに送出し、ステップ５００３からステップ５０１０と同様の手順で端末３００ａ１と端末３００ｙとの間の通話路を確立する。
【００７２】
次に、上記のステップ５０１９内のシーケンスにおいてガイダンス再生中に端末３００ｙへの転送を止める場合のシーケンスについて説明する。
【００７３】
転送を止める場合のシーケンスを図８に示す。
【００７４】
本図に示すように、端末３００ａ１から転送呼を確立するためにＩＮＶＩＴＥが送出された後、ＳＩＰｐｒｏｘｙ１００Ａと端末３００ａ１との間に音声パスが確立し、ガイダンスが流れている間に、オンフックなどの操作により、端末３００ａ１が利用者の切断の意思を受け付ける（ステップ７００１）と、切断の意思を示すリクエストとして、端末３００ａ１のＵＡＣは、ＣＡＮＣＥＬをＳＩＰｐｒｏｘｙ１００Ａに送出する（ステップ７００２）。
【００７５】
それを受けてＳＩＰプロク１００Ａは、端末３００ａ１に、このＣＡＮＣＥＬに対する最終応答２００ＯＫを返し（ステップ７００３）、ＣＡＮＣＥＬが成功したことを通知するとともに、ＩＮＶＩＴＥに対する最終応答４８７ Request Terminatedを返し（ステップ７００４）、ＩＮＶＩＴＥが拒否されたことを通知する。この時点で、転送呼は終了する。
【００７６】
その後、端末３００ａ１は、端末３００ｘと接続されていた呼であるＲＴＰを切断するために、ＢＹＥをＳＩＰｐｒｏｘｙ１００Ａに送出し（ステップ７００５）、ＳＩＰｐｒｏｘｙ１００Ａはそのまま端末３００ｘにＢＹＥを中継する（ステップ７００６）。ＢＹＥを受けた端末３００ｘからＳＩＰｐｒｏｘｙ１００Ａを介し、端末３００ａ１に２００ＯＫを返すことにより、ＲＴＰは切断され、端末３００ｘとの通話が終了する（ステップ７００７、７００８）。
【００７７】
以上の実施形態においては、利用者に転送が行なわれることを通知するために、音声ガイダンスを用いる例をあげて説明したが、利用者への通知は、音声ガイダンスに限られない。例えば、所定の発信音などでもよい。
【００７８】
このように、本実施形態によれば、端末側には新たな構成を付加することなく、また、ＳＩＰプロトコルをそのまま用いて、端末に、転送が行なわれることを通知することができる。
【００７９】
これにより、端末の利用者に転送が行なわれる際に注意を促すことができ、意図しない転送を回避することが可能となる。
【００８０】
また、本実施形態によれば、認証処理時に、ＳＩＰｐｒｏｘｙから端末へ通話路を接続し、その通話路を用いてガイダンスを流す。この通話路は、転送の注意喚起以外にも用いることができる。例えば、何らかの事情で認証が失敗した場合などに、認証の失敗などを通知する音声ガイダンスを流すことができ、端末側に対処を促すことができる。
【００８１】
なお、本発明は、以上の実施形態に限られることはなく、諸々の変更が可能である。例えば、上記の実施形態では、ＳＩＰプロトコルを用いる場合を例にあげて説明したが、プロトコルはこれに限られず、Ｈ.３２３などを用いることもできる。
【００８２】
この場合の転送処理時のシーケンスの一例を図９に示す。
【００８３】
本図に示すように、Ｈ.３２３プロトコルを適用する場合は、端末ａ１に接続されているゲートキーパ（ＧＫ）が、自身が管理している端末ａ１と、接続先の端末ｘとのやりとりをモニタし、端末ｘと接続中に、端末ａ１から他の端末ｙに接続要求が出された場合、端末ａ１にガイダンスを流すよう構成する。
【００８４】
具体的には、ＧＫを介して端末ａ１と端末ｘとの通話が設定されている状態で（ステップ８００１）、端末ｘが、呼を転送するために、転送先端末ｙの情報が格納されたFACILITYをＧＫに送出すると（ステップ８００２）、ＧＫは、それを端末ａ１に中継する（ステップ８００３）。
【００８５】
端末ａ１は、FACILITYを受け、転送先端末yと呼を接続するために、SETUPをＧＫに送出する（ステップ８００４）。FACILITYの後に当該FACILITYで転送先と指定されている端末宛てにSETUPが送出されると、ＧＫは、ALERTを送出元の端末ａ１に返し（ステップ８００５）、端末ａ１と音声パスを接続して転送呼であることを端末ａ１に通知する（ステップ８００６）。
【００８６】
所定の時間内に端末ａ１から切断の指示を受け付けない場合、ＧＫは、転送先端末ｙとの間で呼を確立するために、端末ｙに向けてSETUPを送出し（ステップ８００７〜８００９）、端末ａ１と端末ｙとの間の通話路を確立する（ステップ８０１０）。
【００８７】
なお、図中のリクエスト、レスポンスの名称は、一般的にＨ．３２３に定義されているものである。
【００８８】
【発明の効果】
インターネット電話において、不特定者への意図しない転送を回避可能とする。
【図面の簡単な説明】
【図１】図１は、本実施形態のＶｏＩＰネットワークの一例を説明するための図である。
【図２】図２は、本実施形態のＳＩＰｐｒｏｘｙの機能構成図である。
【図３】図３は、本実施形態のＳＩＰｐｒｏｘｙのハードウエア構成図である。
【図４】図４は、ＳＩＰでのセッション開始時の一般的なシーケンスである。
【図５】図５は、本実施形態の転送セッション開始時のシーケンスである。
【図６】図６は、本実施形態のＳＩＰｐｒｏｘｙ制御部の処理フローである。
【図７】図７は、本実施形態の転送時のシーケンスである。
【図８】図８は、本実施形態の転送中断時のシーケンスである。
【図９】図９は、H.323での転送時のシーケンスである。
【図１０】図１０は、従来例を説明するためのＶｏＩＰネットワークの接続例である。
【図１１】図１１は、端末間転送の例を説明するための図である。
【符号の説明】
１００・・・ＳＩＰｐｒｏｘｙ、１１０・・・ＳＩＰロケーションサーバ機能部、１２０・・・ＳＩＰレジストラサーバ機能部、１３０・・・ＳＩＰｐｒｏｘｙサーバ機能部、１４０・・・ＳＩＰｐｒｏｘｙ制御部、１５０・・・転送手順監視部、１６０・・・ガイダンス制御部１６０、１７０・・・音源データ、１８０・・・ＵＤＰ/ＩＰ制御部、１９０・・・イーサネット（登録商標）制御部、３００・・・端末、４００・・・イントラネット、５００・・・インターネット[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a technology for transferring a voice call on an IP (Internet Protocol) network.
[0002]
[Prior art]
H.323, SIP (Session Initiation Protocol), and the like are known as protocols for establishing, changing, and disconnecting multimedia sessions including voice calls on an IP network. These protocols can establish all kinds of sessions between terminals connected to an IP network. Recently, voice protocols, that is, Internet telephone networks using VoIP (Voice over Internet Protocol) technology are also available. It has been adopted.
[0003]
FIG. 10 shows a typical connection example when, for example, the SIP protocol is used for a VoIP network. As shown in the figure, the VoIP network includes an SIP proxy server C that functions as a proxy server such as an intranet connected via the Internet, a terminal x, and a terminal y. In addition, there are SIP proxy server A, SIP proxy server B, and the like in the intranet, which perform processing as proxy servers for terminals a1, a2,..., B1, b2,.
[0004]
In the example of FIG. 10, SIP proxy server A and SIP proxy server B are connected in an intranet such as an in-house extension telephone, and terminals connected to different SIP proxy servers via these establish a voice session. That is, a call is possible.
[0005]
In the example of FIG. 10, each terminal a1, a2,..., B1, b2,... In the intranet passes through the SIP proxy server to which each terminal is connected, and the intranet via the Internet. The outside terminals x, y,... Can directly talk using the same protocol via the SIP proxy server C.
[0006]
Here, a protocol such as SIP has a session transfer function. For example, as shown in FIG. 11A, when a terminal a1 and a terminal b1 are making a call, the call is transferred from the terminal b1 to the terminal b1. It is possible to transfer the call to b2, and as shown in FIG. 11B, when the terminal a1 and the terminal x are making a call, the call can be transferred from the terminal x to the terminal y. (For example, see Non-Patent Document 1).
[0007]
[Non-Patent Document 1]
R. Sparks (dynamicsoft), A. Johnston (WorldCom) "Session Initiation Protocol Call Control Transfer draft-ietf-sipping-cc-transfer-01" [online] February 11, 2003 SIPPING WG Internet-Draft Expires: August 12, 2003 , Internet <URL: http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-01.txt
[0008]
[Problems to be solved by the invention]
As shown in Non-Patent Document 1, for example, in the SIP protocol, there is a request called REFER, and at the time of transfer, the transfer source terminal gives an instruction to the transferred terminal to establish a session with the transfer destination terminal. That is, when the terminal b1 transfers a call to the terminal b2 while the terminal a1 is in a call, the terminal b1 gives a transfer instruction to the terminal a1 using REFER, and the terminal a1 newly establishes a session with the terminal b2. Establish.
[0009]
In the terminal a1, when the REFER is received, a transfer process, that is, a new session is automatically established with the terminal b1, so that the user of the terminal a1 does not recognize that such a transfer is being performed. There is.
[0010]
For example, in the example of FIG. 10, in the intranet, it is easy to set in advance such that a terminal unsuitable as a transfer destination cannot be transferred in the SIP proxy server.
[0011]
However, in SIP, since it is possible to connect to the terminal x, terminal y, etc. whose external management state is unknown via the Internet, as shown in FIG. 11B, transfer is also performed between these terminals. May be. In some cases, this transfer is not intended for the user of the terminal a1.
[0012]
In view of the above circumstances, an object of the present invention is to enable an unintended transfer to an unspecified person to be avoided in an Internet telephone.
[0013]
[Means for Solving the Problems]
In order to solve the above-described problems, the present invention incorporates a function of notifying a transfer by voice in a device that relays a call between terminals, and notifies the user of the terminal that the transfer is made.
[0014]
In other words, the sequence of the terminal managed by itself is monitored in the relay device, and when it is detected that a request to start the transfer is made, a voice guidance or the like is transmitted to the terminal to alert the user of the terminal Configure as follows.
[0015]
Specifically, in a VoIP (Voice over Internet Protocol) network, a terminal is managed, and a request and response when the terminal managed by the terminal establishes, changes, and disconnects a session with another terminal. A relay apparatus that relays the session, and monitors whether a transfer request for the session is made to the terminal managed by the terminal managed by the terminal managed by the terminal. A request for establishing a session to a transfer destination indicated in the transfer request from the terminal managed by the transfer monitoring unit after the transfer request is detected by the transfer monitoring unit; A transfer notification means for notifying the terminal managed by the terminal that the transfer is being performed;
A relay device is provided.
[0016]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below. In the following embodiments, an example is a case where SIP is used as a signaling protocol (call control procedure) for establishing a voice path, among VoIP technologies for realizing IP telephone service, using a terminal as an IP telephone. And explain.
[0017]
A connection example of the VoIP network in this embodiment is shown in FIG.
[0018]
The intranet 500 includes a SIP proxy 100A for connecting the SIP terminal 300a1, the SIP terminal 300a2,... Etc. via a LAN, and a SIP proxy 100B for connecting the SIP terminal 300b1, the SIP terminal 300b2,. Yes. Also, connected to the Internet 600 is a SIP proxy 100C that operates as a proxy server for the terminal 300x and the terminal 300y. Of course, the number of terminals connected to the SIP proxy and SIP proxy connected to the Internet 600 is not limited.
[0019]
In the following description, the SIP proxy 100A, 100B, and 100C are represented by the SIP proxy 100 unless particularly distinguished.
[0020]
Similarly, each terminal is represented by the terminal 300. Here, in this embodiment, the terminal 300 exchanges a message between the two terminals 300, and a UAC (User Agent Client) that is a function for transmitting a request and a UAS (User Agent that is a function for returning a response). Agent Server).
[0021]
Next, functions of the SIP proxy 100 in this embodiment will be described. FIG. 2 is a functional configuration diagram of the SIP proxy 100 in the present embodiment.
[0022]
As shown in the figure, the SIP proxy 100 includes a SIP location server function unit 110, a SIP registrar server function unit 120, a SIP proxy server function unit 130, a SIP proxy control unit 140, a transfer procedure monitoring unit 150, a guidance control unit 160, a sound source 170, a UDP. / IP (User Datagram Protocol / Internet Protocol) control unit 180 and Ethernet (registered trademark) control unit 190.
[0023]
The SIP registrar server function unit 120 controls the registration of the location information of each terminal 300. From the terminal 300, the SIP-URI (address on SIP) and location (IP address or FQDN (domain name)) of the user If the association with is acquired, the SIP location server function unit 110 is managed.
[0024]
The SIP location server function unit 110 accumulates the user's SIP-URI corresponding to the location acquired from the SIP registrar server function unit 120, and provides it in response to a request. When the SIP proxy server function unit 130 described later receives a connection request from the terminal 300, the SIP proxy server function unit 130 refers to the SIP location server function unit 110, acquires the location of the connection destination terminal, and establishes a session.
[0025]
The SIP proxy server function unit 130 operates as UAS for UAC and operates as UAC for UAS. The request and response issued from each are transferred to the SIP proxy control function unit 140 and transmitted in accordance with an instruction from the SIP proxy control function unit 140.
[0026]
The SIP proxy control function unit 140 performs route control between the UAS and the UAC of the SIP proxy server function unit 130 as in the conventional SIP proxy control function. That is, the request transmitted from the UAC is relayed to the UAS, the response transmitted from the UAS is relayed to the UAC, and the response is returned to the request if necessary.
[0027]
Furthermore, the SIP proxy control function unit 140 of the present embodiment passes the request and response received from the SIP proxy server function unit 130 to the transfer procedure monitoring unit 150, and the call being processed is transferred to the transfer procedure monitoring unit 150 according to the information from the transfer procedure monitoring unit 150. If so, the guidance control unit 160 is operated.
[0028]
The transfer procedure monitoring unit 150 monitors whether a transfer procedure is being performed in the course of proxy control. Specifically, all the requests and responses received by the SIP proxy server function unit 130 are received from the SIP proxy control function unit 140, and it is determined whether or not the request is REFER. If it is REFER, the addresses of the reference destination (transfer destination) and the counterpart terminal are extracted and stored.
[0029]
When REFER is received and the address of the reference destination and the counterpart terminal is stored, when the INVITE described later is received, the stored address of the counterpart terminal and the address of the reference destination terminal are included in the combination. , It is determined whether or not there is a match with the combination of the address of the transmission source terminal and the address of the connection destination terminal described in INVITE. If they match, it is determined that the call is a transfer call, and the SIP proxy control function unit 140 Notify
[0030]
The guidance control unit 160 performs voice output and RTP (Real-time Transport Protocol) control using sound source data managed by the sound source 170 in accordance with instructions from the SIP proxy control function unit 140.
[0031]
The sound source 170 manages sound source data, and may hold the sound source itself output to the UAC and UAS as data, or may synthesize it as necessary.
[0032]
The UDP / IP control unit 180 and the Ethernet (registered trademark) control unit 190 respectively perform layer processing of the VoIP data received via the Ethernet (registered trademark). In the present embodiment, the protocol may be TCP instead of UDP.
[0033]
In the above configuration, the SIP location server function unit 110, the SIP registrar server function unit 120, and the SIP proxy server function unit 130 basically have the same functions as those of the conventional SIP servers. The details will not be described. Note that the SIP location server function unit 110 and the SIP registrar server function unit 120 may be separate and independent devices.
[0034]
Next, an example of the hardware configuration of the SIP proxy 100 of this embodiment is shown in FIG.
[0035]
As shown in this figure, the SIP proxy 100 includes a CPU 410, a memory 420, a sound source 430, and an Ethernet (registered trademark) interface 440.
[0036]
The Ethernet (registered trademark) interface 440 extracts a packet from an ether frame received via the Ethernet (registered trademark) and sends the packet to the CPU. Send it up.
[0037]
The sound source 430 stores a sound source or data that can be combined and output as a sound source.
[0038]
The memory 420 stores programs and data for realizing the functions described in FIG. The CPU 410 implements the above functions by executing programs stored in the memory 420.
[0039]
Note that this hardware configuration is an example in which the SIP proxy 100 is realized as a single SIP proxy server, but is not limited thereto. For example, the present invention can be realized on an information processing apparatus such as a general personal computer having a CPU, a memory, and an Ethernet (registered trademark) interface and having a built-in sound source or a voice input / output interface.
[0040]
Next, the processing sequence of this embodiment will be described. A normal transmission sequence and a transmission sequence after REFER reception according to the present embodiment will be described with reference to FIGS. 4 and 5.
[0041]
In the following, INVITTE, ACK, BYE, CANCEL, REFER, and NOTIFY are requests defined by SIP, and are used for the following purposes.
INVITE: Starts connection with a partner terminal that desires connection. An INVITE transmission source terminal address and a partner terminal address desired to be connected are provided.
ACK: Notifies that a final response to INVITE has been received.
BYE: Suspend the session. Here, in the two-party communication, when one party uses the BYE to offer an interruption, the session is interrupted.
CANCEL: Instructs interruption of INVITE.
REFER: A terminal that is establishing a voice session instructs a reference terminal (transfer destination) to a partner terminal. The REFER includes information on the address of the counterpart terminal and the transfer destination address.
NOTIFY: Notification of progress information.
[0042]
The client that sends the request is a client, and the server issues one or more responses when receiving the request. The response consists of a three-digit status code and a reason for reply, and there are an intermediate response sent as progress information and a final response sent as a final response to the request. Those used in the present embodiment have the following meanings.
100 Trying: An intermediate response indicating that an attempt is being made. When an INVITE request or the like is received, for example, if the processing result cannot be immediately returned, it is first returned to notify the transmission source terminal of the reception.
180 Ringing: An intermediate response indicating that a call is in progress.
183 Session Progress: an intermediate response indicating the session status.
200 OK: Final response indicating the success of the request.
202 Accepted: a final response indicating that the request has been accepted.
407 Proxy Authentication Required [407 proxy authentication request]: This is a final response for requesting proxy authentication, and is returned together with information for authenticating the transmission source terminal.
487 Request Terminated: A final response indicating the end of the request.
[0043]
FIG. 4 is a diagram for explaining a normal request and response sequence exchanged between the terminal 300 and the SIP proxy 100 when a session is started using SIP. In SIP, when INVITE is issued from a transmission source terminal, the proxy server relays the INVITE to a connection destination terminal after authentication processing.
[0044]
First, when the terminal 300 (UAC) accepts a user's intention to make a call, the terminal 300 (UAC) transmits INVITE to the SIP proxy 100 (step 3001). When the SIP proxy control unit 140 receives the INVITE, the SIP proxy control unit 140 operates as a UAS and performs a procedure for authenticating the terminal 300 to be transmitted, so that the SIP proxy server function unit 130 sends a 407 proxy authentication request to the source terminal 300 A reply is made (step 3002). This 407 proxy authentication request includes information for authenticating the terminal 300.
[0045]
When receiving the 407 authentication request, the terminal 300 sends ACK to the SIP proxy 100 (step 3003). Here, the ACK is sent to notify the SIP proxy 100 that the response to the 407 proxy authentication request has been received with respect to the INVITE sent in step 3001.
[0046]
After that, the terminal 300 sends INVITE to which the authentication information is added based on the authentication information included in the 407 proxy authentication request sent in Step 3002 to the SIP proxy 100 (Step 3004). In response to this, the SIP proxy control unit 140 of the SIP proxy 100 causes the SIP proxy server function unit 130 to return and send a 100 Trying response to the terminal 300 (step 3005), and to send INVITE to the UAS of the partner terminal (step 3006).
[0047]
The above is the processing sequence between the terminal 300 and the SIP proxy 100, which is a UAC for normal transmission.
[0048]
In the present embodiment, the SIP proxy 100 is intervened between the terminals, authentication is performed, and then processing for establishing a session with the counterpart terminal is performed. In SIP proxy 100, when the first INVITE after receiving REFER from terminal 300 is received, a voice path is formed with terminal 300 during this authentication procedure, and a guidance is transmitted as a voice signal. It is a thing.
[0049]
FIG. 5 shows a sequence for explaining the outline of the processing in this case.
[0050]
As shown in this figure, after relaying REFER and receiving INVITE from the terminal 300 which is UAC (step 4001), the SIP proxy control unit 140 sends the 407 proxy authentication request to the SIP proxy server function unit 130 before sending it out. 183 Progress is returned (step 4002). Then, the SIP proxy control unit 140 forms a voice path between the terminal 300 and the SIP proxy 100, and causes the guidance control unit 160 to transmit guidance from the sound source 170 (step 4003). The guidance may be any content that can notify the user that the call is being forwarded, such as “transferring”. When the transfer is suspicious, the terminal 300 side can perform a disconnection process while the voice path is established and the guidance is being reproduced.
[0051]
If disconnection processing is not performed in the terminal 300 while the voice path is established, the SIP proxy control unit 140 causes the SIP proxy server function unit 130 to send out a 407 proxy authentication request (step 4004). INVITE is received (steps 4005 and 4006), 100 Trying is returned, and UAS is sent to INVITE (steps 4007 and 4008).
[0052]
Here, the processing until the guidance is transmitted after the REFER is received by the SIP proxy control unit 140 will be described below.
[0053]
FIG. 6 shows a processing flow of the SIP proxy control unit 140.
[0054]
When the SIP proxy control unit 140 receives a request via the SIP proxy server function unit 130 (step 6001), the SIP proxy control unit 140 causes the transfer procedure monitoring unit 150 to determine whether the received request is REFER (step 6002).
[0055]
If it is REFER, the address of the transmission destination (counterpart) terminal and the address of the reference destination terminal described in REFER are stored in the transfer procedure monitoring unit 150 (step 6003), and the process returns to normal request processing.
[0056]
If the received request is not REFER in step 6002, it is confirmed whether or not the request is INVITE (step 6004). If it is not INVITE, the process returns to normal request processing.
[0057]
If it is INVITE in step 6004, whether the address of the terminal of the INVITE transmission source and the address of the reception destination terminal match the addresses of the REFER transmission destination terminal and the reference destination terminal stored in step 6003, respectively. No, the transfer procedure monitoring unit 150 is confirmed (step 6005). If either does not match, return to normal request processing.
[0058]
In step 6005, when both addresses match, that is, when a reply that the call is a transfer call is obtained from the transfer procedure monitoring unit 150, the SIP proxy server function unit 130 is caused to return 183 Progress to the terminal of the INVITE transmission source. (Step 6006), the guidance control unit 160 sends the guidance to the transmission source terminal by RTP (step 6007).
[0059]
When the guidance transmission ends (step 6008), the SIP proxy server function unit 130 is caused to transmit a 407 proxy authentication request to the transmission source terminal of the INVITE received in step 6004 (step 6009), and the transfer procedure monitoring unit 150 performs step 6005. In step 6010, the address confirmed to match is deleted.
[0060]
Here, the number of address pairs stored in REFER in step 6003 is not limited. Multiple saves are possible. If a plurality of sets are stored, in step 6005, it is checked whether or not there is a match for all stored address sets.
[0061]
In step 6007, CANCEL can be received while the guidance is being transmitted. If CANCEL is received during this time, the SIP proxy control unit 140 causes the SIP proxy server function unit 130 to suspend processing for INVITE determined to be received in step 6004. That is, no transfer is performed.
[0062]
Next, in the present embodiment, the sequence from the terminal 300a1 via the SIP proxy 100A to the terminal 300x via the SIP proxy 100C to the terminal 300x to the connection to the other terminal 300y in the network of FIG. 7 will be described.
[0063]
Exchange of INVITE, 407 proxy authentication request, ACK, INVITE, 100 Trying, and the like is performed between the terminal 300a1 and the SIP proxy 100A in the same sequence as in FIG. The SIP proxy 100A transmits INVITE to the terminal 300x via the SIP proxy 100C of the other party (step 5002).
[0064]
The SIP proxy 100C activates the ringer, returns 100 Trying to the SIP proxy 100A, and reports that INVITE has been received (step 5003).
[0065]
Thereafter, the SIP proxy 100C sends 180 Ringing and / or 183 Progress to the SIP proxy 100A (step 5004), and the received SIP proxy 100A relays these responses to the terminal 300a1 (step 5005).
[0066]
Thereafter, when the SIP proxy 100A receives a 200 OK response from the terminal x that has received a response by the user of the terminal 300x performing off-hook or the like, the SIP proxy 100A sends the response to the terminal 300a1 (steps 5006 and 5007). Is relayed to the terminal 300x (steps 5008 and 5009).
[0067]
When the above procedure is completed, the terminal 300a1 directly connects to the partner terminal 300x and makes a call with the terminal 300x by RTP (step 5010).
[0068]
Thereafter, in order to transfer the call connected in Step 5010 to the terminal 300y, the terminal 300x sends REFER containing information of the transfer destination terminal to the SIP proxy 100A (Step 5011).
[0069]
The SIP proxy 100A relays this REFER and transmits it to the terminal 300a1 (step 5012), and relays 202 Accepted from the terminal 300a1 to the terminal 300x (steps 5013 and 5014). Then, the SIP proxy 100A relays NOTIFY from the terminal 300a1 in response to REFER, and relays 200 OK transmitted from the return terminal 300y to the terminal 300a1 (steps 5015 to 5018).
[0070]
The SIP proxy 100A manages information on the transfer destination given to REFER, and when receiving INVITE from the terminal 300a1 to the transfer tip 300y, starts the sequence described above with reference to FIG. 5 (step 5019).
[0071]
When SIP proxy 100A receives INVITE from terminal 300a1, SIP proxy 100A returns 100 Trying to terminal 300a1, and sends INVITE to transfer destination terminal 300y. Establish a communication path between.
[0072]
Next, a sequence in the case where the transfer to the terminal 300y is stopped during the guidance reproduction in the sequence in the above step 5019 will be described.
[0073]
A sequence for stopping the transfer is shown in FIG.
[0074]
As shown in this figure, after INVITE is sent to establish a transfer call from the terminal 300a1, an operation such as on-hook is performed while a voice path is established between the SIP proxy 100A and the terminal 300a1 and guidance is flowing. Thus, when the terminal 300a1 accepts the user's intention to disconnect (step 7001), the UAC of the terminal 300a1 sends CANCEL to the SIP proxy 100A as a request indicating the disconnection intention (step 7002).
[0075]
In response to this, the SIP proxy 100A returns a final response 200 OK to the CANCEL to the terminal 300a1 (step 7003), notifies that the CANCEL was successful, and returns a final response 487 Request Terminated to the INVITE (step 7004). , Notify that INVITE is rejected. At this point, the transfer call is terminated.
[0076]
Thereafter, the terminal 300a1 sends BYE to the SIP proxy 100A in order to disconnect the RTP that is a call connected to the terminal 300x (step 7005), and the SIP proxy 100A relays the BYE to the terminal 300x as it is (step 7006). By returning 200 OK from the terminal 300x that has received BYE to the terminal 300a1 via the SIP proxy 100A, the RTP is disconnected and the call with the terminal 300x is terminated (steps 7007 and 7008).
[0077]
In the above embodiment, an example in which voice guidance is used to notify the user that transfer is performed has been described. However, notification to the user is not limited to voice guidance. For example, a predetermined dial tone may be used.
[0078]
As described above, according to the present embodiment, it is possible to notify the terminal that the transfer is performed without adding a new configuration to the terminal side and using the SIP protocol as it is.
[0079]
As a result, it is possible to alert the user of the terminal when the transfer is performed, and it is possible to avoid unintended transfer.
[0080]
Further, according to the present embodiment, during the authentication process, a call path is connected from the SIP proxy to the terminal, and guidance is played using the call path. This call path can be used for purposes other than calling for forwarding. For example, when the authentication fails for some reason, a voice guidance for notifying the authentication failure can be played, and the terminal side can be urged to deal with it.
[0081]
The present invention is not limited to the above embodiment, and various modifications can be made. For example, in the above embodiment, the case where the SIP protocol is used has been described as an example. However, the protocol is not limited to this, and H.323 or the like can also be used.
[0082]
An example of a sequence during the transfer process in this case is shown in FIG.
[0083]
As shown in this figure, when the H.323 protocol is applied, the gatekeeper (GK) connected to the terminal a1 monitors the exchange between the terminal a1 managed by the terminal a1 and the connection destination terminal x. When a connection request is issued from the terminal a1 to the other terminal y during connection with the terminal x, guidance is sent to the terminal a1.
[0084]
Specifically, in a state where a call between the terminal a1 and the terminal x is set via the GK (step 8001), the information of the transfer destination terminal y is stored for the terminal x to transfer the call. When FACILITY is sent to GK (step 8002), GK relays it to terminal a1 (step 8003).
[0085]
The terminal a1 receives FACILITY and sends SETUP to the GK in order to connect the call with the transfer destination terminal y (step 8004). When SETUP is sent to the terminal specified as the transfer destination in the FACILITY after FACILITY, the GK returns ALERT to the terminal a1 that is the transmission source (step 8005), and transfers by connecting the voice path to the terminal a1. The terminal a1 is notified of the call (step 8006).
[0086]
If the disconnection instruction is not received from the terminal a1 within a predetermined time, the GK sends SETUP to the terminal y in order to establish a call with the transfer destination terminal y (steps 8007 to 8009), A communication path between the terminal a1 and the terminal y is established (step 8010).
[0087]
The names of requests and responses in the figure are generally H.264. H.323 is defined.
[0088]
【The invention's effect】
It is possible to avoid unintended transfer to unspecified persons in Internet telephone.
[Brief description of the drawings]
FIG. 1 is a diagram for explaining an example of a VoIP network according to an embodiment.
FIG. 2 is a functional configuration diagram of the SIP proxy of the present embodiment.
FIG. 3 is a hardware configuration diagram of the SIP proxy according to the present embodiment.
FIG. 4 is a general sequence at the start of a session in SIP.
FIG. 5 is a sequence at the start of a transfer session according to the present embodiment.
FIG. 6 is a processing flow of the SIP proxy control unit of the present embodiment.
FIG. 7 is a sequence at the time of transfer according to the present embodiment;
FIG. 8 is a sequence when transfer is interrupted according to the present embodiment;
FIG. 9 is a sequence at the time of transfer in H.323.
FIG. 10 is a connection example of a VoIP network for explaining a conventional example.
FIG. 11 is a diagram for explaining an example of inter-terminal transfer;
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 100 ... SIP proxy, 110 ... SIP location server function part, 120 ... SIP registrar server function part, 130 ... SIP proxy server function part, 140 ... SIP proxy control part, 150 ... Transfer procedure monitoring 160, guidance control unit 160, 170 sound source data, 180 ... UDP / IP control unit, 190 ... Ethernet (registered trademark) control unit, 300 ... terminal, 400 ... Intranet, 500 ... Internet

Claims

A relay device that manages terminals in a VoIP (Voice over Internet Protocol) network and relays requests and responses when the managed terminal establishes, changes, or disconnects a session with another terminal. ,
From another terminal that has established a terminal session to the management, a transfer monitoring means for monitoring the transfer request for the session is made to the terminal to the management,
After the transfer request is detected by the transfer monitoring means, when a request for establishing a session is sent from the managing terminal to the transfer destination indicated in the transfer request, the transfer is transmitted to the managing terminal. And a transfer notification means for notifying that it has been made.

The relay device according to claim 1,
The transfer monitoring unit manages information on a transfer destination stored in the received transfer request and information on the terminal to be managed to which the transfer request is transmitted,
When a request for establishing a session is sent from the terminal to be managed , the transfer notification means includes information managed by the transfer monitoring means and information on a counterpart terminal stored in the request to establish the session And the notification is made when they match.

The relay device according to claim 1 or 2, wherein
The relay apparatus is characterized in that the session is established using a SIP protocol.

In a relay device on a VoIP (Voice over Internet Protocol) network for managing a terminal and establishing, changing, and disconnecting a session between the managed terminal and another terminal, the managing terminal establishes a session with the other terminal A session transfer method for transferring a session in accordance with a request to transfer the session transmitted from the other terminal,
A monitoring step of monitoring whether or not a request to transfer to another terminal is sent from the other terminal side to the managing terminal ;
In the monitoring step, when it is detected that a transfer request has been sent, a comparison step of comparing the counterpart terminal with the other terminal in a request to establish a session sent from the managing terminal When,
In the comparison step, if both match, a voice output step of sending voice guidance to the terminal to be managed ;
A session transfer method comprising: