JP2004363941A

JP2004363941A - Relaying device with voice guidance function

Info

Publication number: JP2004363941A
Application number: JP2003159883A
Authority: JP
Inventors: Masaaki Kimura; 雅明木村
Original assignee: Nakayo Telecommunications Inc
Current assignee: Nakayo Telecommunications Inc
Priority date: 2003-06-04
Filing date: 2003-06-04
Publication date: 2004-12-24
Anticipated expiration: 2023-06-04
Also published as: JP4136798B2

Abstract

<P>PROBLEM TO BE SOLVED: To avoid unintended transfer to an unspecified person through Internet telephone. <P>SOLUTION: When protocol is SIP, a proxy server has: a function of monitoring transfer requests; and a notification function of giving notice of a transfer call to a terminal having sent out a session establishment request when the session establishment request to a transfer destination is made after a transfer request. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
本発明は、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）ネットワーク上での音声通話の転送技術に関する。
【０００２】
【従来の技術】
ＩＰネットワーク上で音声通話をはじめとするマルチメディアセッションの確立、変更、切断を実現するプロトコルとしてＨ．３２３やＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）などが知られている。これらのプロトコルは、ＩＰネットワークに接続された端末間のあらゆる種類のセッションの確立が可能であり、最近では、音声セッション、すなわち、ＶｏＩＰ（ＶｏｉｃｅｏｖｅｒＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）技術を用いたインターネット電話のネットワークにも採用されている。
【０００３】
ＶｏＩＰによるネットワークに、例えば、ＳＩＰプロトコルを用いた場合の一般的な接続例を図１０に示す。本図に示すように、ＶｏＩＰネットワークは、インターネットを介して接続されるイントラネット、端末ｘ、端末ｙなどのｐｒｏｘｙサーバとして働くＳＩＰｐｒｏｘｙサーバＣなどを備える。また、イントラネット内には、ＳＩＰｐｒｏｘｙサーバＡ、ＳＩＰｐｒｏｘｙサーバＢなどがあり、それぞれ、ＬＡＮで接続された端末ａ１、ａ２・・、および、ｂ１、ｂ２・・・のｐｒｏｘｙサーバとして処理を行なう。
【０００４】
図１０の例において、社内の内線電話などのイントラネット内では、ＳＩＰｐｒｏｘｙサーバＡと、ＳＩＰｐｒｏｘｙサーバＢとが接続され、これらを経由して、異なるＳＩＰｐｒｏｘｙサーバに接続されている端末同士も音声セッションの確立、すなわち、通話が可能となっている。
【０００５】
また、図１０の例では、イントラネット内の各端末ａ１、ａ２、・・・・、ｂ１、ｂ２、・・・・は、それぞれが接続されているＳＩＰｐｒｏｘｙサーバを経由して、インターネットを介してイントラネット外の端末ｘ、ｙ、・・・とも、ＳＩＰｐｒｏｘｙサーバＣを介して同じプロトコルを用いて直接通話が可能である。
【０００６】
ここで、ＳＩＰなどのプロトコルは、セッションの転送機能を有し、例えば図１１（ａ）に示すように、端末ａ１と端末ｂ１とが通話をしている際に、当該通話を端末ｂ１から端末ｂ２へと転送したり、また、図１１（ｂ）に示すように、端末ａ１と端末ｘとが通話をしている際に、当該通話を端末ｘから端末ｙへ転送したりすることが可能である（例えば、非特許文献１参照）。
【０００７】
【非特許文献１】
Ｒ．Ｓｐａｒｋｓ（ｄｙｎａｍｉｃｓｏｆｔ），Ａ．Ｊｏｈｎｓｔｏｎ（ＷｏｒｌｄＣｏｍ） ”ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌＣａｌｌＣｏｎｔｒｏｌＴｒａｎｓｆｅｒｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｃｃ−ｔｒａｎｓｆｅｒ−０１” ［ｏｎｌｉｎｅ］Ｆｅｂｒｕａｒｙ１１，２００３ＳＩＰＰＩＮＧＷＧＩｎｔｅｒｎｅｔ−ＤｒａｆｔＥｘｐｉｒｅｓ：Ａｕｇｕｓｔ１２，２００３、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｃｃ−ｔｒａｎｓｆｅｒ−０１．ｔｘｔ
【０００８】
【発明が解決しようとする課題】
非特許文献１に示すように、例えばＳＩＰプロトコルでは、ＲＥＦＥＲというリクエストを有し、転送の際には、転送元端末が被転送端末に転送先端末とのセッションを確立するよう指示を与える。すなわち、端末ｂ１が端末ａ１とが通話中に、その通話を端末ｂ２に転送する場合、端末ｂ１は、端末ａ１にＲＥＦＥＲを用いて転送の指示を与え、端末ａ１は端末ｂ２と新たにセッションを確立する。
【０００９】
端末ａ１内では、ＲＥＦＥＲを受信すると転送の処理、すなわち、新たに端末ｂ１とのセッションの確立を自動的に行なうため、端末ａ１のユーザはそのような転送が行なわれていることを認識しないことがある。
【００１０】
例えば、図１０の例において、イントラネット内では、ＳＩＰｐｒｏｘｙサーバにおいて、転送先として不適な端末は予め転送不能なように設定することも容易である。
【００１１】
しかし、ＳＩＰでは、インターネットを介して外部の管理状態が不明な端末ｘ、端末ｙなどとの接続も可能であるため、図１１（ｂ）に示すように、これらの端末間でも、転送は行なわれることがある。そして、端末ａ１の利用者にとって、この転送は意図しないものである場合がある。
【００１２】
上記事情に鑑み、本発明は、インターネット電話において、不特定者への意図しない転送を回避可能にすることを目的とする。
【００１３】
【課題を解決するための手段】
上記課題を解決するために、本発明は、端末間の呼を中継する装置内に音声により転送を通知する機能を組み込み、端末の利用者に転送がなされることを通知する。
【００１４】
すなわち、中継装置内に自身が管理している端末のシーケンスを監視し、転送を開始する要求がなされたことを検知すると、音声ガイダンスなどを当該端末に送信し、端末の利用者に注意を促すよう構成する。
【００１５】
具体的には、ＶｏＩＰ（ＶｏｉｃｅｏｖｅｒＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）ネットワークにおいて、端末を管理するとともに、前記自身が管理している端末が他の端末とセッションを確立、変更、および、切断する際に、要求および応答の中継を行なう中継装置であって、前記自身が管理している端末とセッションを確立している他の端末から、前記自身が管理している端末に当該セッションの転送要求がなされたかを監視する転送監視手段と、前記転送監視手段において前記転送要求が検出された後に、前記自身が管理している端末から当該転送要求の中で指示された転送先にセッションを確立する要求が送出された場合、当該自身が管理している端末に前記転送がなされていることを通知する転送通知手段と
を備えることを特徴とする中継装置を提供する。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。なお、以下の実施形態においては、端末をＩＰ電話とし、ＩＰ電話サービスを実現するＶｏＩＰ技術のうち、特に音声パスを確立するためのシグナリングプロトコル（呼制御手順）として、ＳＩＰを用いた場合を例にあげ、説明する。
【００１７】
本実施形態における、ＶｏＩＰネットワークの接続例を図１に示す。
【００１８】
イントラネット５００は、ＳＩＰ端末３００ａ１、ＳＩＰ端末３００ａ２・・・などをＬＡＮで接続するＳＩＰｐｒｏｘｙ１００Ａと、ＳＩＰ端末３００ｂ１、ＳＩＰ端末３００ｂ２・・・などをＬＡＮで接続するＳＩＰｐｒｏｘｙ１００Ｂとを備え、インターネット６００に接続している。また、インターネット６００には、端末３００ｘ、端末３００ｙのｐｒｏｘｙサーバとして動作するＳＩＰｐｒｏｘｙ１００Ｃが接続している。もちろん、インターネット６００に接続されるＳＩＰｐｒｏｘｙ、ＳＩＰｐｒｏｘｙに接続される端末の台数は、限定されない。
【００１９】
なお、以下において、各ＳＩＰｐｒｏｘｙ１００Ａ、１００Ｂ、１００Ｃは、特に区別が必要ない場合は、ＳＩＰｐｒｏｘｙ１００で代表する。
【００２０】
また、各端末も同様に、端末３００で代表する。ここで、本実施形態においては端末３００は、２つの端末３００間でメッセージを交換する際に、リクエストを送信する機能であるＵＡＣ（ＵｓｅｒＡｇｅｎｔＣｌｉｅｎｔ）と、レスポンスを返信する機能であるＵＡＳ（ＵｓｅｒＡｇｅｎｔＳｅｒｖｅｒ）とを備える。
【００２１】
次に、本実施形態におけるＳＩＰｐｒｏｘｙ１００の機能を説明する。図２は、本実施形態におけるＳＩＰｐｒｏｘｙ１００の機能構成図である。
【００２２】
本図に示すように、ＳＩＰｐｒｏｘｙ１００は、ＳＩＰロケーションサーバ機能部１１０、ＳＩＰレジストラサーバ機能部１２０、ＳＩＰｐｒｏｘｙサーバ機能部１３０、ＳＩＰｐｒｏｘｙ制御部１４０、転送手順監視部１５０、ガイダンス制御部１６０、音源１７０、ＵＤＰ／ＩＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ／ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）制御部１８０、イーサネット（Ｅｔｈｅｒｎｅｔ：登録商標）制御部１９０とを備える。
【００２３】
ＳＩＰレジストラサーバ機能部１２０は、各端末３００のロケーション情報の登録を制御するもので、端末３００から、利用者のＳＩＰ−ＵＲＩ（ＳＩＰ上のアドレス）とロケーション（ＩＰアドレスまたはＦＱＤＮ（ドメイン名））との関連を取得すると、ＳＩＰロケーションサーバ機能部１１０に管理させる。
【００２４】
ＳＩＰロケーションサーバ機能部１１０は、ＳＩＰレジストラサーバ機能部１２０から取得した、利用者のＳＩＰ−ＵＲＩをロケーションと対応させて蓄積し、要求に応じて提供するものである。後述するＳＩＰプロクシサーバ機能部１３０は、端末３００から接続要求を受信した際、ＳＩＰロケーションサーバ機能部１１０を参照し、接続先端末のロケーションを取得し、セッションを確立する。
【００２５】
ＳＩＰｐｒｏｘｙサーバ機能部１３０は、ＵＡＣに対してはＵＡＳとして動作し、ＵＡＳに対してはＵＡＣとして動作する。それぞれから発せられた要求および応答を、ＳＩＰｐｒｏｘｙ制御機能部１４０に受け渡し、ＳＩＰｐｒｏｘｙ制御機能部１４０からの指示に従い、発信する。
【００２６】
ＳＩＰｐｒｏｘｙ制御機能部１４０は、従来のＳＩＰｐｒｏｘｙ制御機能と同様、ＳＩＰｐｒｏｘｙサーバ機能部１３０のＵＡＳ、ＵＡＣ間のルート制御を行なう。すなわち、ＵＡＣから送信された要求をＵＡＳに、ＵＡＳから送信された応答をＵＡＣに、ルーティングを決定して中継し、要求に対し、必要があれば、自ら応答を返信する。
【００２７】
さらに、本実施形態のＳＩＰｐｒｏｘｙ制御機能部１４０は、ＳＩＰｐｒｏｘｙサーバ機能部１３０から受け取った要求および応答を転送手順監視部１５０に受け渡し、転送手順監視部１５０からの情報に従って、処理中の呼が転送呼である場合、ガイダンス制御部１６０を動作させる。
【００２８】
転送手順監視部１５０は、ｐｒｏｘｙ制御の過程で転送手順が行なわれているかを監視する。具体的には、ＳＩＰｐｒｏｘｙ制御機能部１４０から、ＳＩＰｐｒｏｘｙサーバ機能部１３０が受け取った要求および応答を全て受け取り、転送の要求であるＲＥＦＥＲであるか否か判別する。そして、ＲＥＦＥＲであった場合、参照先（転送先）と相手方端末とのアドレスを抽出して記憶する。
【００２９】
また、ＲＥＦＥＲを受信し、参照先および相手方端末のアドレスが記憶されている場合、後述するＩＮＶＩＴＥを受け取った際に、記憶している相手方端末のアドレスと参照先端末のアドレスとの組み合わせの中に、ＩＮＶＩＴＥに記述されている送信元端末のアドレスと接続先端末のアドレスとの組み合わせと一致するものがあるか否か判別し、一致した場合、転送呼であると判断し、ＳＩＰｐｒｏｘｙ制御機能部１４０に通知する。
【００３０】
ガイダンス制御部１６０は、ＳＩＰｐｒｏｘｙ制御機能部１４０の指示に従って、音源１７０が管理する音源データを用いて音声出力とＲＴＰ（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）制御とを行なう。
【００３１】
音源１７０は、音源データを管理するもので、ＵＡＣ、ＵＡＳに出力する音源そのものをデータとして保持していてもよいし、必要に応じて合成してもよい。
【００３２】
ＵＤＰ／ＩＰ制御部１８０、イーサネット（登録商標）制御部１９０は、それぞれ、イーサネット（登録商標）を介して受信したＶｏＩＰデータのそれぞれのレイヤ処理を行なう。なお、本実施形態では、プロトコルは、ＵＤＰではなく、ＴＣＰであってもよい。
【００３３】
また、上記の構成において、ＳＩＰロケーションサーバ機能部１１０、ＳＩＰレジストラサーバ機能部１２０、ＳＩＰｐｒｏｘｙサーバ機能部１３０は、基本的に従来のＳＩＰのそれぞれのサーバと同様の機能を有するものであるため、ここでは、詳細に説明しない。なお、ＳＩＰロケーションサーバ機能部１１０およびＳＩＰレジストラサーバ機能部１２０は、別個独立した装置としてもよい。
【００３４】
次に、本実施形態のＳＩＰｐｒｏｘｙ１００のハードウエア構成の一例を図３に示す。
【００３５】
本図に示すように、ＳＩＰｐｒｏｘｙ１００は、ＣＰＵ４１０と、メモリ４２０と、音源４３０と、イーサネット（登録商標）インタフェース４４０とを備える。
【００３６】
イーサネット（登録商標）インタフェース４４０は、イーサネット（登録商標）を介して受信したイーサフレームからパケットを取り出してＣＰＵに送出し、また、逆にＣＰＵから受け取ったパケットをイーサフレーム化してイーサネット（登録商標）上に送出する。
【００３７】
音源４３０は、音源、または、合成して音源として出力可能なデータを格納する。
【００３８】
メモリ４２０は、図２に記載の各機能を実現するプログラムおよびデータを蓄積する。そして、ＣＰＵ４１０は、メモリ４２０内に蓄積されたプログラムを実行することで、上記各機能を実現する。
【００３９】
なお、本ハードウエア構成は、ＳＩＰｐｒｏｘｙ１００をＳＩＰｐｒｏｘｙサーバとして単体として実現する場合の例であるが、これに限られない。例えば、ＣＰＵ、メモリ、イーサネット（登録商標）インタフェースを持ち、音源を内蔵しているかまたは音声入出力インタフェースを備える一般のパーソナルコンピュータなどの情報処理装置上でも実現可能である。
【００４０】
次に、本実施形態の処理シーケンスについて説明する。図４および図５を用い、通常の発信シーケンスと、本実施形態の、ＲＥＦＥＲ受信後の発信シーケンスとを説明する。
【００４１】
なお、以下において、ＩＮＶＩＴＴＥ、ＡＣＫ、ＢＹＥ、ＣＡＮＣＥＬ，ＲＥＦＥＲ、ＮＯＴＩＦＹは、ＳＩＰで定義されているリクエストで、以下の目的で用いられるものである。
ＩＮＶＩＴＥ：接続を希望する相手方端末との接続を開始する。ＩＮＶＩＴＥの送信元の端末のアドレスと、接続を希望する相手方の端末のアドレスとを備える。
ＡＣＫ：ＩＮＶＩＴＥに対する最終レスポンスを受信したことを知らせる。
ＢＹＥ：セッションを中断する。ここで、２者間通信では、片方がＢＹＥを用いて中断を申し出ると、セッションは中断する。
ＣＡＮＣＥＬ：ＩＮＶＩＴＥの中断を指示する。
ＲＥＦＥＲ：音声セッションを確立中の端末が、相手方端末に、参照先（転送先）を指示する。なお、ＲＥＦＥＲは、相手方端末のアドレスと転送先のアドレスとの情報を備える。
ＮＯＴＩＦＹ：経過情報を通知する。
【００４２】
上記のリクエストを発信する側がクライアントであり、サーバは、リクエストを受信すると、１つあるいは複数のレスポンスを発行する。レスポンスは３桁の状態コードと返信理由とからなり、リクエストに対して、経過情報として送出される中間応答と、最終的な応答として送出される最終応答とがある。本実施形態で用いられるものは、それぞれ、以下の意味を持つ。
１００Ｔｒｙｉｎｇ：試行中を示す中間応答で、例えばＩＮＶＩＴＥリクエストなどを受信した際、すぐに処理結果を返信できない場合、まず、受信したことを送信元端末に通知するために返信される。
１８０Ｒｉｎｇｉｎｇ：呼出中を示す中間応答である。
１８３ＳｅｓｓｉｏｎＰｒｏｇｒｅｓｓ：セッション状況を示す中間応答である。
２００ＯＫ：リクエストの成功を示す最終応答である。
２０２Ａｃｃｅｐｔｅｄ：リクエストを受け入れたことを示す最終応答である。
４０７ＰｒｏｘｙＡｕｔｈｅｎｔｉｃａｔｉｏｎＲｅｑｕｉｒｅｄ［４０７ｐｒｏｘｙ認証要求］：ｐｒｏｘｙ認証を要求する最終応答で、送信元端末を認証する情報とともに返信される。
４８７ＲｅｑｕｅｓｔＴｅｒｍｉｎａｔｅｄ：リクエストの終了を示す最終応答である。
【００４３】
図４は、ＳＩＰを用いてセッションを開始する際に、端末３００とＳＩＰｐｒｏｘｙ１００との間でやりとりされる、通常の要求と応答のシーケンスを説明するための図である。ＳＩＰでは、発信元端末からＩＮＶＩＴＥが出されると、ｐｒｏｘｙサーバは、認証処理後、当該ＩＮＶＩＴＥを接続先の端末に中継する。
【００４４】
まず、端末３００（ＵＡＣ）は、利用者の発信の意思を受け付けると、ＳＩＰｐｒｏｘｙ１００にＩＮＶＩＴＥを送信する（ステップ３００１）。ＳＩＰｐｒｏｘｙ制御部１４０は、ＩＮＶＩＴＥを受信すると、端末３００に対して、ＵＡＳとして動作し、発信する端末３００を認証する手順を行うため、ＳＩＰｐｒｏｘｙサーバ機能部１３０に、４０７ｐｒｏｘｙ認証要求を発信元端末３００に返信させる（ステップ３００２）。この４０７ｐｒｏｘｙ認証要求には、端末３００を認証する情報が含まれている。
【００４５】
４０７認証要求を受信すると、端末３００は、ＡＣＫをＳＩＰｐｒｏｘｙ１００に送出する（ステップ３００３）。ここでは、ＡＣＫは、ステップ３００１で送出したＩＮＶＩＴＥに対し、４０７ｐｒｏｘｙ認証要求のレスポンスを受信したことをＳＩＰｐｒｏｘｙ１００に通知するために送出される。
【００４６】
その後、端末３００は、ステップ３００２で送出された４０７ｐｒｏｘｙ認証要求に含まれている認証情報に基づいて認証の情報を付加したＩＮＶＩＴＥをＳＩＰｐｒｏｘｙ１００に送出する（ステップ３００４）。それを受け、ＳＩＰｐｒｏｘｙ１００のＳＩＰｐｒｏｘｙ制御部１４０はＳＩＰｐｒｏｘｙサーバ機能部１３０に、折り返し、１００Ｔｒｙｉｎｇレスポンスを端末３００に送出させる（ステップ３００５）とともに、ＩＮＶＩＴＥを相手先端末のＵＡＳに送出する（ステップ３００６）。
【００４７】
以上が、通常の発信の場合のＵＡＣである端末３００とＳＩＰｐｒｏｘｙ１００との間の処理シーケンスである。
【００４８】
本実施形態では、端末間にＳＩＰｐｒｏｘｙ１００を介入させ、認証を行なってから、相手先端末とセッションを確立する処理を行なう。そして、ＳＩＰｐｒｏｘｙ１００において、端末３００からＲＥＦＥＲを受信した後の最初のＩＮＶＩＴＥを受信した際、この認証手順の間に、端末３００との間に音声パスを形成し、音声信号でガイダンスを送出するよう構成したものである。
【００４９】
この場合の処理の概要を説明するためのシーケンスを図５に示す。
【００５０】
本図に示すように、ＲＥＦＥＲを中継した後、ＵＡＣである端末３００からＩＮＶＩＴＥを受け取る（ステップ４００１）と、ＳＩＰｐｒｏｘｙ制御部１４０は、４０７ｐｒｏｘｙ認証要求を送出する前に、ＳＩＰｐｒｏｘｙサーバ機能部１３０に、１８３Ｐｒｏｇｒｅｓｓを返信させる（ステップ４００２）。そして、ＳＩＰｐｒｏｘｙ制御部１４０は、端末３００とＳＩＰｐｒｏｘｙ１００間に音声パスを形成し、ガイダンス制御部１６０に、音源１７０からガイダンスを送信させる（ステップ４００３）。ガイダンスは、例えば、「転送しています」などの内容で、利用者に当該呼が転送されていることを通知できる内容のものであればよい。そして、端末３００側は、転送が不審な場合は、音声パスが確立し、ガイダンスを再生中に、切断の処理を行なうことができる。
【００５１】
音声パスが確立している最中に、端末３００にて切断の処理がなされなかった場合、ＳＩＰｐｒｏｘｙ制御部１４０は、ＳＩＰｐｒｏｘｙサーバ機能部１３０に、４０７ｐｒｏｘｙ認証要求を送出させ（ステップ４００４）、ＡＣＫとＩＮＶＩＴＥとを受け取り（ステップ４００５、４００６）、１００Ｔｒｙｉｎｇを返信させるとともに、ＵＡＳにＩＮＶＩＴＥを送出させる（ステップ４００７、４００８）。
【００５２】
ここで、以下に、ＳＩＰｐｒｏｘｙ制御部１４０の、ＲＥＦＥＲ受信後、ガイダンスを送出するまでの処理を説明する。
【００５３】
図６は、ＳＩＰｐｒｏｘｙ制御部１４０の処理フローを示す。
【００５４】
ＳＩＰｐｒｏｘｙ制御部１４０は、ＳＩＰｐｒｏｘｙサーバ機能部１３０を介してリクエストを受信する（ステップ６００１）と、受信したリクエストがＲＥＦＥＲであるか否かを、転送手順監視部１５０に判別させる（ステップ６００２）。
【００５５】
ＲＥＦＥＲであった場合、ＲＥＦＥＲに記述されている送信先（相手方）端末のアドレスと参照先端末のアドレスとを転送手順監視部１５０に保存させ（ステップ６００３）、通常のリクエスト処理に戻る。
【００５６】
ステップ６００２において、受信したリクエストがＲＥＦＥＲでない場合、そのリクエストがＩＮＶＩＴＥであるか否か確認させる（ステップ６００４）。ＩＮＶＩＴＥでなければ、通常のリクエスト処理にもどる。
【００５７】
ステップ６００４で、ＩＮＶＩＴＥであれば、当該ＩＮＶＩＴＥの送信元の端末のアドレスおよび受取先端末のアドレスが、それぞれ、ステップ６００３で保存したＲＥＦＥＲの送信先端末のアドレスおよび参照先端末のアドレスと一致するか否か、転送手順監視部１５０に確認させる（ステップ６００５）。一方でも一致しなければ、通常のリクエスト処理にもどる。
【００５８】
ステップ６００５で、両アドレスが一致した場合、すなわち、転送手順監視部１５０から転送呼であるとの返信を得た場合、ＳＩＰｐｒｏｘｙサーバ機能部１３０に１８３Ｐｒｏｇｒｅｓｓを、当該ＩＮＶＩＴＥ送信元の端末に返信させ（ステップ６００６）、ガイダンス制御部１６０に、送信元の端末にＲＴＰによりガイダンスを送出させる（ステップ６００７）。
【００５９】
ガイダンスの送信が終了すると（ステップ６００８）、ＳＩＰｐｒｏｘｙサーバ機能部１３０に、ステップ６００４で受信したＩＮＶＩＴＥの送信元端末に対して４０７ｐｒｏｘｙ認証要求を送信させ（ステップ６００９）、転送手順監視部１５０にステップ６００５で一致を確認したアドレスを削除させる（ステップ６０１０）。
【００６０】
ここで、ステップ６００３におけるＲＥＦＥＲに格納されているアドレスの組の数は限定されない。複数保存が可能である。複数の組が格納されている場合は、ステップ６００５において、格納されている全てのアドレスの組に対して一致の有無をチェックする。
【００６１】
また、ステップ６００７において、ガイダンスが送出されている間は、ＣＡＮＣＥＬの受信が可能である。この間にＣＡＮＣＥＬを受信した場合、ＳＩＰｐｒｏｘｙ制御部１４０は、ＳＩＰｐｒｏｘｙサーバ機能部１３０に、ステップ６００４で受信を判断したＩＮＶＩＴＥに対する処理を中断させる。すなわち、転送を行なわない。
【００６２】
次に、本実施形態において、図１のネットワークで、ＳＩＰｐｒｏｘｙ１００Ａを介して端末３００ａ１から、ＳＩＰｐｒｏｘｙ１００Ｃを介して端末３００ｘに発信して接続してから他の端末３００ｙへの転送に至るまでのシーケンスを図７に従って説明する。
【００６３】
端末３００ａ１とＳＩＰｐｒｏｘｙ１００Ａとの間で、ＩＮＶＩＴＥ、４０７ｐｒｏｘｙ認証要求、ＡＣＫ、ＩＮＶＩＴＥ、１００Ｔｒｙｉｎｇなどのやり取りが図４と同様のシーケンスでなされ、ＳＩＰｐｒｏｘｙ１００Ａにおいて発信元の端末３００ａ１の認証が完了すると（ステップ５００１）、ＳＩＰｐｒｏｘｙ１００Ａは、相手先のＳＩＰｐｒｏｘｙ１００Ｃを介して端末３００ｘにＩＮＶＩＴＥを送信する（ステップ５００２）。
【００６４】
ＳＩＰｐｒｏｘｙ１００Ｃでは、リンガをアクティブにするとともに、ＳＩＰｐｒｏｘｙ１００Ａに１００Ｔｒｙｉｎｇを返し、ＩＮＶＩＴＥを受け取ったことを報告する（ステップ５００３）。
【００６５】
その後、ＳＩＰｐｒｏｘｙ１００Ｃは、１８０Ｒｉｎｇｉｎｇまたは／および１８３ＰｒｏｇｒｅｓｓをＳＩＰｐｒｏｘｙ１００Ａに送出し（ステップ５００４）、受け取ったＳＩＰｐｒｏｘｙ１００Ａは、それらのレスポンスを端末３００ａ１に中継する（ステップ５００５）。
【００６６】
その後、ＳＩＰｐｒｏｘｙ１００Ａは、端末３００ｘの利用者がオフフックなどを行なうことで応答を受け付けた端末ｘからの２００ＯＫのレスポンスを受け取ると、それを端末３００ａ１に送出し（ステップ５００６、５００７）、端末３００ａ１からのＡＣＫを端末３００ｘに中継する（ステップ５００８、５００９）。
【００６７】
以上の手順を終えると、端末３００ａ１は相手先端末３００ｘに直接接続し、ＲＴＰにて端末３００ｘと通話を行なう（ステップ５０１０）。
【００６８】
その後、端末３００ｘは、ステップ５０１０で接続された通話を端末３００ｙに転送するため、転送先の端末の情報が入っているＲＥＦＥＲをＳＩＰｐｒｏｘｙ１００Ａに送出する（ステップ５０１１）。
【００６９】
ＳＩＰｐｒｏｘｙ１００Ａは、このＲＥＦＥＲを中継して端末３００ａ１に送信し（ステップ５０１２）、端末３００ａ１からの２０２Ａｃｃｅｐｔｅｄを端末３００ｘに中継する（ステップ５０１３、５０１４）。そして、ＳＩＰｐｒｏｘｙ１００Ａは、ＲＥＦＥＲに対する端末３００ａ１からのＮＯＴＩＦＹを同じく中継し、折り返し端末３００ｙから発信される２００ＯＫを端末３００ａ１に中継する（ステップ５０１５〜５０１８）。
【００７０】
ＳＩＰｐｒｏｘｙ１００Ａは、ＲＥＦＥＲに付与されている転送先の情報を管理し、端末３００ａ１から転送先端３００ｙへのＩＮＶＩＴＥを受け取ると、先ほど図５において説明したシーケンスを開始する（ステップ５０１９）。
【００７１】
そして、ＳＩＰｐｒｏｘｙ１００Ａは、端末３００ａ１からＩＮＶＩＴＥを受け付けると、１００Ｔｒｙｉｎｇを端末３００ａ１に返すとともに、ＩＮＶＩＴＥを転送先の端末３００ｙに送出し、ステップ５００３からステップ５０１０と同様の手順で端末３００ａ１と端末３００ｙとの間の通話路を確立する。
【００７２】
次に、上記のステップ５０１９内のシーケンスにおいてガイダンス再生中に端末３００ｙへの転送を止める場合のシーケンスについて説明する。
【００７３】
転送を止める場合のシーケンスを図８に示す。
【００７４】
本図に示すように、端末３００ａ１から転送呼を確立するためにＩＮＶＩＴＥが送出された後、ＳＩＰｐｒｏｘｙ１００Ａと端末３００ａ１との間に音声パスが確立し、ガイダンスが流れている間に、オンフックなどの操作により、端末３００ａ１が利用者の切断の意思を受け付ける（ステップ７００１）と、切断の意思を示すリクエストとして、端末３００ａ１のＵＡＣは、ＣＡＮＣＥＬをＳＩＰｐｒｏｘｙ１００Ａに送出する（ステップ７００２）。
【００７５】
それを受けてＳＩＰプロク１００Ａは、端末３００ａ１に、このＣＡＮＣＥＬに対する最終応答２００ＯＫを返し（ステップ７００３）、ＣＡＮＣＥＬが成功したことを通知するとともに、ＩＮＶＩＴＥに対する最終応答４８７ＲｅｑｕｅｓｔＴｅｒｍｉｎａｔｅｄを返し（ステップ７００４）、ＩＮＶＩＴＥが拒否されたことを通知する。この時点で、転送呼は終了する。
【００７６】
その後、端末３００ａ１は、端末３００ｘと接続されていた呼であるＲＴＰを切断するために、ＢＹＥをＳＩＰｐｒｏｘｙ１００Ａに送出し（ステップ７００５）、ＳＩＰｐｒｏｘｙ１００Ａはそのまま端末３００ｘにＢＹＥを中継する（ステップ７００６）。ＢＹＥを受けた端末３００ｘからＳＩＰｐｒｏｘｙ１００Ａを介し、端末３００ａ１に２００ＯＫを返すことにより、ＲＴＰは切断され、端末３００ｘとの通話が終了する（ステップ７００７、７００８）。
【００７７】
以上の実施形態においては、利用者に転送が行なわれることを通知するために、音声ガイダンスを用いる例をあげて説明したが、利用者への通知は、音声ガイダンスに限られない。例えば、所定の発信音などでもよい。
【００７８】
このように、本実施形態によれば、端末側には新たな構成を付加することなく、また、ＳＩＰプロトコルをそのまま用いて、端末に、転送が行なわれることを通知することができる。
【００７９】
これにより、端末の利用者に転送が行なわれる際に注意を促すことができ、意図しない転送を回避することが可能となる。
【００８０】
また、本実施形態によれば、認証処理時に、ＳＩＰｐｒｏｘｙから端末へ通話路を接続し、その通話路を用いてガイダンスを流す。この通話路は、転送の注意喚起以外にも用いることができる。例えば、何らかの事情で認証が失敗した場合などに、認証の失敗などを通知する音声ガイダンスを流すことができ、端末側に対処を促すことができる。
【００８１】
なお、本発明は、以上の実施形態に限られることはなく、諸々の変更が可能である。例えば、上記の実施形態では、ＳＩＰプロトコルを用いる場合を例にあげて説明したが、プロトコルはこれに限られず、Ｈ．３２３などを用いることもできる。
【００８２】
この場合の転送処理時のシーケンスの一例を図９に示す。
【００８３】
本図に示すように、Ｈ．３２３プロトコルを適用する場合は、端末ａ１に接続されているゲートキーパ（ＧＫ）が、自身が管理している端末ａ１と、接続先の端末ｘとのやりとりをモニタし、端末ｘと接続中に、端末ａ１から他の端末ｙに接続要求が出された場合、端末ａ１にガイダンスを流すよう構成する。
【００８４】
具体的には、ＧＫを介して端末ａ１と端末ｘとの通話が設定されている状態で（ステップ８００１）、端末ｘが、呼を転送するために、転送先端末ｙの情報が格納されたＦＡＣＩＬＩＴＹをＧＫに送出すると（ステップ８００２）、ＧＫは、それを端末ａ１に中継する（ステップ８００３）。
【００８５】
端末ａ１は、ＦＡＣＩＬＩＴＹを受け、転送先端末ｙと呼を接続するために、ＳＥＴＵＰをＧＫに送出する（ステップ８００４）。ＦＡＣＩＬＩＴＹの後に当該ＦＡＣＩＬＩＴＹで転送先と指定されている端末宛てにＳＥＴＵＰが送出されると、ＧＫは、ＡＬＥＲＴを送出元の端末ａ１に返し（ステップ８００５）、端末ａ１と音声パスを接続して転送呼であることを端末ａ１に通知する（ステップ８００６）。
【００８６】
所定の時間内に端末ａ１から切断の指示を受け付けない場合、ＧＫは、転送先端末ｙとの間で呼を確立するために、端末ｙに向けてＳＥＴＵＰを送出し（ステップ８００７〜８００９）、端末ａ１と端末ｙとの間の通話路を確立する（ステップ８０１０）。
【００８７】
なお、図中のリクエスト、レスポンスの名称は、一般的にＨ．３２３に定義されているものである。
【００８８】
【発明の効果】
インターネット電話において、不特定者への意図しない転送を回避可能とする。
【図面の簡単な説明】
【図１】図１は、本実施形態のＶｏＩＰネットワークの一例を説明するための図である。
【図２】図２は、本実施形態のＳＩＰｐｒｏｘｙの機能構成図である。
【図３】図３は、本実施形態のＳＩＰｐｒｏｘｙのハードウエア構成図である。
【図４】図４は、ＳＩＰでのセッション開始時の一般的なシーケンスである。
【図５】図５は、本実施形態の転送セッション開始時のシーケンスである。
【図６】図６は、本実施形態のＳＩＰｐｒｏｘｙ制御部の処理フローである。
【図７】図７は、本実施形態の転送時のシーケンスである。
【図８】図８は、本実施形態の転送中断時のシーケンスである。
【図９】図９は、Ｈ．３２３での転送時のシーケンスである。
【図１０】図１０は、従来例を説明するためのＶｏＩＰネットワークの接続例である。
【図１１】図１１は、端末間転送の例を説明するための図である。
【符号の説明】
１００・・・ＳＩＰｐｒｏｘｙ、１１０・・・ＳＩＰロケーションサーバ機能部、１２０・・・ＳＩＰレジストラサーバ機能部、１３０・・・ＳＩＰｐｒｏｘｙサーバ機能部、１４０・・・ＳＩＰｐｒｏｘｙ制御部、１５０・・・転送手順監視部、１６０・・・ガイダンス制御部１６０、１７０・・・音源データ、１８０・・・ＵＤＰ／ＩＰ制御部、１９０・・・イーサネット（登録商標）制御部、３００・・・端末、４００・・・イントラネット、５００・・・インターネット[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a technology for transferring a voice call on an IP (Internet Protocol) network.
[0002]
[Prior art]
As a protocol for establishing, changing, and disconnecting a multimedia session including a voice call on an IP network, H.264 has been proposed. H.323 and SIP (Session Initiation Protocol) are known. These protocols enable the establishment of any type of session between terminals connected to an IP network, and more recently, voice sessions, ie, Internet telephone networks using VoIP (Voice over Internet Protocol) technology. Has been adopted.
[0003]
FIG. 10 shows a general connection example in the case of using, for example, a SIP protocol in a VoIP network. As shown in the figure, the VoIP network includes an intranet connected via the Internet, a SIP proxy server C serving as a proxy server for terminals x and y, and the like. The intranet includes a SIP proxy server A, a SIP proxy server B, and the like, which perform processing as proxy servers for terminals a1, a2,..., B1, b2,.
[0004]
In the example of FIG. 10, in an intranet such as an extension phone in a company, a SIP proxy server A and a SIP proxy server B are connected, and terminals connected to different SIP proxy servers via these establish a voice session. That is, a call can be made.
[0005]
In the example of FIG. 10, each terminal a1, a2,..., B1, b2,... In the intranet is connected to the intranet via the Internet via a SIP proxy server to which each terminal is connected. The external terminals x, y,... Can directly communicate with each other using the same protocol via the SIP proxy server C.
[0006]
Here, the protocol such as SIP has a session transfer function. For example, as shown in FIG. 11A, when the terminal a1 and the terminal b1 are talking, the call is transferred from the terminal b1 to the terminal b1. b2, or, as shown in FIG. 11B, when the terminal a1 and the terminal x are talking, 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 (dynamics), A.S. Johnston (WorldCom) "Session Initiation Protocol Call Control Transfer draft-ietf-shipping-cc-transfer-01" [online] February 11th, 2003. www. ief. org / internet-drafts / draft-iet-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, a request called REFER is provided, and at the time of transfer, the transfer source terminal gives an instruction to the transferee terminal to establish a session with the transfer destination terminal. That is, when the terminal b1 transfers a call to the terminal b2 during a call with the terminal a1, 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, the transfer process, that is, the establishment of a new session with the terminal b1 is automatically performed, so that the user of the terminal a1 does not recognize that such 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 in the SIP proxy server such that an unsuitable terminal as a transfer destination cannot be transferred.
[0011]
However, in the SIP, it is possible to connect to an external terminal x, terminal y, or the like whose management status is unknown via the Internet. Therefore, as shown in FIG. 11B, transfer is performed between these terminals. May be This transfer may not be intended for the user of the terminal a1.
[0012]
In view of the above circumstances, an object of the present invention is to make it possible to avoid an unintended transfer to an unspecified person in an Internet telephone.
[0013]
[Means for Solving the Problems]
In order to solve the above problem, the present invention incorporates a function of notifying transfer by voice in a device for relaying a call between terminals, and notifies a user of the terminal that transfer is performed.
[0014]
In other words, the relay device monitors the sequence of the terminal managed by itself and, when detecting that a request to start transfer has been made, transmits voice guidance or the like to the terminal to alert the user of the terminal. The configuration is as follows.
[0015]
Specifically, in a VoIP (Voice over Internet Protocol) network, a terminal manages a terminal, and requests and responses when a terminal managed by the terminal establishes, changes, and disconnects a session with another terminal. A relay device that relays the session, and monitors whether a transfer request for the session has been made from another terminal that has established a session with the terminal managed by itself to the terminal managed by itself. A transfer monitoring unit and a request for establishing a session to a transfer destination specified in the transfer request from a terminal managed by the terminal after the transfer monitoring unit detects the transfer request. Transfer notifying means for notifying the terminal managed by itself that the transfer has been made; and
A relay device is provided.
[0016]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described. In the following embodiment, an example will be described in which the terminal is an IP telephone and SIP is used as a signaling protocol (call control procedure) for establishing a voice path among VoIP technologies for realizing an IP telephone service. I will explain it.
[0017]
FIG. 1 shows a connection example of a VoIP network in the present embodiment.
[0018]
The intranet 500 includes a SIP proxy 100A that connects the SIP terminals 300a1, 300a2, and so on via a LAN, and a SIP proxy 100B that connects the SIP terminals 300b1, 300b2, and the like via the LAN. I have. In addition, a SIP proxy 100C that operates as a proxy server for the terminal 300x and the terminal 300y is connected to the Internet 600. Of course, the SIP proxy connected to the Internet 600 and the number of terminals connected to the SIP proxy are not limited.
[0019]
In the following, each of the SIP proxies 100A, 100B, and 100C will be represented by the SIP proxy 100 unless it is particularly necessary to distinguish them.
[0020]
Similarly, each terminal is also represented by the terminal 300. Here, in the present embodiment, when exchanging a message between the two terminals 300, the terminal 300 transmits a request, a UAC (User Agent Client), and a UAS (User, a function for returning a response). Agent Server).
[0021]
Next, the function of the SIP proxy 100 according to the present embodiment will be described. FIG. 2 is a functional configuration diagram of the SIP proxy 100 according to 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, and a UDP. / IP (User Datagram Protocol / Internet Protocol) control unit 180 and an Ethernet (registered trademark) control unit 190.
[0023]
The SIP registrar server function unit 120 controls registration of the location information of each terminal 300. From the terminal 300, the user's SIP-URI (address on SIP) and location (IP address or FQDN (domain name)) When the association with the server is acquired, the SIP location server function unit 110 manages the association.
[0024]
The SIP location server function unit 110 accumulates the user's SIP-URI acquired from the SIP registrar server function unit 120 in association with the location, and provides the SIP-URI upon request. When a connection request is received from the terminal 300, a SIP proxy server function unit 130, which will be described later, 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 a UAS for the UAC, and operates as a UAC for the UAS. The request and response issued from each are transferred to the SIP proxy control function unit 140 and transmitted according to the instruction from the SIP proxy control function unit 140.
[0026]
The SIP proxy control function unit 140 controls the route between the UAS and the UAC of the SIP proxy server function unit 130, similarly to the conventional SIP proxy control function. That is, the request transmitted from the UAC is transmitted to the UAS, the response transmitted from the UAS is transmitted to the UAC, and routing is determined and relayed. If necessary, the response is returned to the request.
[0027]
Further, 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 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 during the proxy control. More specifically, all 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 a REFER that is a transfer request. If it is REFER, the address of the reference destination (transfer destination) and the address of the counterpart terminal are extracted and stored.
[0029]
Also, when REFER is received and the address of the reference destination and the counterpart terminal are stored, when the INVITE described later is received, the stored combination of the address of the counterpart terminal and the address of the reference destination terminal is included in the combination. , The combination of the address of the source terminal and the address of the connection destination described in the INVITE, and 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 sound output and RTP (Real-time Transport Protocol) control using sound source data managed by the sound source 170 according to an instruction of the SIP proxy control function unit 140.
[0031]
The sound source 170 manages sound source data, and may hold the sound source itself to be output to the UAC or UAS as data, or may combine the data as needed.
[0032]
The UDP / IP control unit 180 and the Ethernet (registered trademark) control unit 190 respectively perform layer processing of 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 the respective servers of the conventional SIP. Then, it will not be described in detail. 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 a hardware configuration of the SIP proxy 100 of the present embodiment is shown in FIG.
[0035]
As shown in the 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 Ethernet frame received via the Ethernet (registered trademark) and sends the packet to the CPU, and conversely converts the packet received from the CPU into an Ethernet frame and converts the packet into an Ethernet (registered trademark). Send up.
[0037]
The sound source 430 stores a sound source or data that can be synthesized and output as a sound source.
[0038]
The memory 420 stores programs and data for realizing the functions shown in FIG. Then, the CPU 410 executes the programs stored in the memory 420 to realize the above functions.
[0039]
Note that this hardware configuration is an example in which the SIP proxy 100 is realized as a single unit as a SIP proxy server, but is not limited thereto. For example, the present invention can be realized on an information processing device such as a general personal computer having a CPU, a memory, an Ethernet (registered trademark) interface, and having a built-in sound source or an audio input / output interface.
[0040]
Next, a processing sequence of the present embodiment will be described. The normal transmission sequence and the transmission sequence after REFER reception according to the present embodiment will be described with reference to FIGS. 4 and 5.
[0041]
In the following, INVITE, ACK, BYE, CANCEL, REFER, and NOTIFY are requests defined in SIP and are used for the following purposes.
INVITE: Starts connection with a partner terminal that desires connection. It has the address of the terminal of the source of the INVITE and the address of the terminal of the other party wishing to connect.
ACK: Notifies that a final response to INVITE has been received.
BYE: Interrupt the session. Here, in the two-party communication, the session is interrupted when one of the two offers to interrupt using BYE.
CANCEL: Instructs interruption of INVITE.
REFER: A terminal that is establishing a voice session instructs the other terminal of a reference destination (transfer destination). The REFER includes information on the address of the partner terminal and the address of the transfer destination.
NOTIFY: Notify progress information.
[0042]
The client that sends the above request is the client, and the server issues one or more responses when receiving the request. The response is made up of a three-digit status code and the reason for the response, and there are an intermediate response sent as progress information and a final response sent as a final response to the request. The components used in the present embodiment have the following meanings.
100 Trying: An intermediate response indicating that a trial is being performed. For example, when an INVITE request or the like is received, if a processing result cannot be returned immediately, a response is first sent to notify the source terminal of the reception.
180 Ringing: An intermediate response indicating that a call is being made.
183 Session Progress: An intermediate response indicating the session status.
200 OK: Final response indicating successful request.
202 Accepted: Final response indicating that the request has been accepted.
407 Proxy Authentication Required [407 proxy authentication request]: A final response requesting proxy authentication, which is returned together with information for authenticating the source terminal.
487 Request Terminated: This is 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 an INVITE is issued from a source terminal, the proxy server relays the INVITE to a connection destination terminal after performing authentication processing.
[0044]
First, when the terminal 300 (UAC) accepts the user's intention to transmit, the terminal 300 (UAC) transmits INVITE to the SIP proxy 100 (step 3001). Upon receiving the INVITE, the SIP proxy control unit 140 operates as a UAS for the terminal 300, and performs a procedure for authenticating the terminal 300 that sends the call. Thus, the SIP proxy control unit 140 sends a 407 proxy authentication request to the SIP terminal A reply is made (step 3002). The 407 proxy authentication request includes information for authenticating the terminal 300.
[0045]
Upon receiving the 407 authentication request, the terminal 300 sends an ACK to the SIP proxy 100 (step 3003). Here, the ACK is transmitted to the SIP proxy 100 to notify the INVITE transmitted in step 3001 that the response of the 407 proxy authentication request has been received.
[0046]
After that, the terminal 300 sends INVITE to which 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, send a 100 Trying response to the terminal 300 (step 3005), and send INVITE to the UAS of the other terminal (step 3006).
[0047]
The above is the processing sequence between the UAC terminal 300 and the SIP proxy 100 in the case of normal transmission.
[0048]
In the present embodiment, the SIP proxy 100 is interposed between the terminals, authentication is performed, and then processing for establishing a session with the partner terminal is performed. Then, when the SIP proxy 100 receives the first INVITE after receiving the REFER from the terminal 300, a voice path is formed between the SIP proxy 100 and the terminal 300 during the authentication procedure, and the guidance is transmitted by a voice signal. It was done.
[0049]
FIG. 5 shows a sequence for explaining the outline of the processing in this case.
[0050]
As shown in the figure, upon relaying REFER and receiving INVITE from the terminal 300 which is a UAC (step 4001), the SIP proxy control unit 140 sends to the SIP proxy server function unit 130 before transmitting the 407 proxy authentication request. 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, for example, a content such as "transferring", which can notify the user that the call is being transferred. Then, if the transfer is suspicious, the terminal 300 can establish a voice path and perform disconnection processing while reproducing the guidance.
[0051]
If the terminal 300 does not perform the disconnection process while the voice path is being established, the SIP proxy control unit 140 causes the SIP proxy server function unit 130 to send a 407 proxy authentication request (step 4004), and INVITE is received (steps 4005 and 4006), 100 Trying is returned, and the UAS is sent out INVITE (steps 4007 and 4008).
[0052]
Here, the processing of the SIP proxy control unit 140 from the reception of the REFER to the transmission of the guidance will be described below.
[0053]
FIG. 6 shows a processing flow of the SIP proxy control unit 140.
[0054]
Upon receiving the 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]
In the case of 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 the normal request processing.
[0056]
If the received request is not REFER in step 6002, it is checked whether the request is INVITE (step 6004). If it is not INVITE, the process returns to normal request processing.
[0057]
In step 6004, if it is an INVITE, does the address of the terminal of the source of the INVITE and the address of the destination terminal match the address of the destination terminal and the address of the reference terminal of the REFER stored in step 6003, respectively? The transfer procedure monitoring unit 150 is made to check whether or not it is (step 6005). If one of them does not match, the process returns to the normal request processing.
[0058]
In step 6005, when both addresses match, that is, when a reply indicating 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 causes the transmission source terminal to transmit guidance by RTP (Step 6007).
[0059]
When the transmission of the guidance is completed (step 6008), the SIP proxy server function unit 130 transmits a 407 proxy authentication request to the source terminal of the INVITE received in step 6004 (step 6009), and the transfer procedure monitoring unit 150 performs step 6005. Then, the address for which a match has been confirmed is deleted (step 6010).
[0060]
Here, the number of sets of addresses 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 all the stored sets of addresses match.
[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 interrupt the process for INVITE determined to be received in step 6004. That is, no transfer is performed.
[0062]
Next, in the present embodiment, a sequence from transmission from the terminal 300a1 via the SIP proxy 100A to the terminal 300x via the SIP proxy 100C and connection to transfer to another terminal 300y in the network of FIG. 1 is shown. 7 will be described.
[0063]
The 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. 4, and when the authentication of the source terminal 300a1 is completed in the SIP proxy 100A (step 5001). , SIP proxy 100A transmits INVITE to terminal 300x via 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 the 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 those responses to the terminal 300a1 (step 5005).
[0066]
After that, when the SIP proxy 100A receives the 200 OK response from the terminal x that has received the response by the user of the terminal 300x performing off-hook or the like, the SIP proxy 100A sends it to the terminal 300a1 (steps 5006 and 5007), and Is relayed to the terminal 300x (steps 5008 and 5009).
[0067]
After completing the above procedure, the terminal 300a1 directly connects to the destination terminal 300x and makes a call with the terminal 300x by RTP (step 5010).
[0068]
After that, the terminal 300x sends out a REFER containing information on the transfer destination terminal to the SIP proxy 100A in order to transfer the call connected in step 5010 to the terminal 300y (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 also relays NOTIFY from the terminal 300a1 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 the information of the transfer destination assigned to REFER, and upon receiving the INVITE from the terminal 300a1 to the transfer front end 300y, starts the sequence described above with reference to FIG. 5 (step 5019).
[0071]
Then, when receiving the INVITE from the terminal 300a1, the SIP proxy 100A returns 100 Trying to the terminal 300a1, sends the INVITE to the transfer destination terminal 300y, and transmits the INVITE to the terminal 300a1 in the same procedure as Steps 5003 to 5010. 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]
FIG. 8 shows a sequence for stopping the transfer.
[0074]
As shown in the figure, after INVITE is transmitted from the terminal 300a1 to establish a transfer call, a voice path is established between the SIP proxy 100A and the terminal 300a1, and operations such as on-hook operation are performed while the guidance is flowing. 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, 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). , INVITE is rejected. At this point, the transfer call ends.
[0076]
Thereafter, the terminal 300a1 sends a BYE to the SIP proxy 100A to disconnect the RTP which 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 the BYE to the terminal 300a1 via the SIP proxy 100A, the RTP is disconnected, and the communication with the terminal 300x ends (steps 7007 and 7008).
[0077]
In the above embodiment, an example has been described in which voice guidance is used to notify the user that the transfer is performed. However, the 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, the terminal can be notified that the transfer is performed without adding a new configuration to the terminal and using the SIP protocol as it is.
[0079]
Thus, the user of the terminal can be alerted when the transfer is performed, and it is possible to avoid unintended transfer.
[0080]
Further, according to the present embodiment, at the time of authentication processing, a communication path is connected from the SIP proxy to the terminal, and guidance is provided using the communication path. This communication path can be used for other than the alerting of the transfer. For example, when the authentication fails for some reason or the like, a voice guidance for notifying the failure of the authentication or the like can be provided, and the terminal can be prompted to take measures.
[0081]
It should be noted that the present invention is not limited to the above embodiment, and various changes can be made. For example, in the above-described embodiment, the case where the SIP protocol is used has been described as an example, but the protocol is not limited to this. 323 can also be used.
[0082]
FIG. 9 shows an example of a sequence at the time of transfer processing in this case.
[0083]
As shown in FIG. When the H.323 protocol is applied, the gatekeeper (GK) connected to the terminal a1 monitors the exchange between the terminal a1 managed by itself and the terminal x of the connection destination, and during connection with the terminal x, When a connection request is issued from the terminal a1 to another terminal y, guidance is provided 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 in order for the terminal x to transfer the call. When transmitting the FACILITY to the GK (step 8002), the GK relays it to the terminal a1 (step 8003).
[0085]
The terminal a1 receives the FACILITY and sends SETUP to the GK to connect the call to the transfer destination terminal y (step 8004). When the SETUP is transmitted to the terminal designated as the transfer destination in the FACILITY after the FACILITY, the GK returns ALERT to the terminal a1 of the transmission source (step 8005), and connects the terminal a1 to the voice path to transfer. The terminal a1 is notified of the call (step 8006).
[0086]
If the disconnection instruction is not received from the terminal a1 within the predetermined time, the GK sends SETUP to the terminal y 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]
Note that the names of requests and responses in the figure are generally H.264. H.323.
[0088]
【The invention's effect】
In an Internet telephone, unintended transfer to an unspecified person can be avoided.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating an example of a VoIP network according to an embodiment;
FIG. 2 is a functional configuration diagram of a SIP proxy according to the present embodiment.
FIG. 3 is a hardware configuration diagram of a 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 embodiment;
FIG. 6 is a processing flow of a SIP proxy control unit according to the embodiment;
FIG. 7 is a sequence at the time of transfer according to the embodiment;
FIG. 8 is a sequence when the transfer is interrupted in the embodiment.
FIG. 323 is a sequence at the time of transfer.
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 transfer between terminals.
[Explanation of symbols]
100: SIP proxy, 110: SIP location server function unit, 120: SIP registrar server function unit, 130: SIP proxy server function unit, 140: SIP proxy control unit, 150: Transfer procedure monitoring Unit, 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

In a VoIP (Voice over Internet Protocol) network, a terminal that manages terminals and relays a request and a response when the terminal managed by itself manages, establishes, changes, and disconnects a session with another terminal. A device,
Transfer monitoring means for monitoring whether a transfer request for the session has been made to the terminal managed by itself from another terminal that has established a session with the terminal managed by itself,
After the transfer monitoring unit detects the transfer request, if a request to establish a session to the transfer destination specified in the transfer request is sent from the terminal managed by the transfer monitoring unit, the control unit controls the transfer. A transfer notifying unit for notifying a terminal performing the transfer that the transfer has been performed.

The relay device according to claim 1,
The transfer monitoring unit manages information of a transfer destination stored in the received transfer request and information of a terminal managed by the device to which the transfer request is transmitted,
The transfer notifying means, when a request to establish a session is sent from a terminal managed by the transfer notification means, information managed by the transfer monitoring means and a counterpart stored in the request to establish the session. A relay device that compares information of a destination terminal and performs the notification when the information matches.

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

A relay device on a VoIP (Voice over Internet Protocol) network that manages a terminal and establishes, changes, and disconnects a session between the terminal managed by the terminal itself and another terminal. While establishing a session with another terminal, a session transfer method for transferring a session according to a request to transfer the session transmitted from the other terminal,
A monitoring step of monitoring whether a request to transfer to another terminal has been sent to the terminal managed by the other terminal from the other terminal side,
In the monitoring step, when it is detected that the transfer request is transmitted, the request for establishing the session transmitted from the terminal managed by the terminal itself, the destination terminal and the another terminal are separated. A comparison step to compare;
In the comparing step, when both match, an audio output step of sending audio guidance to a terminal managed by the own,
A session transfer method comprising: