JP2005159431A

JP2005159431A - シグナリング方法並びにサーバ及びゲートウェイ端末

Info

Publication number: JP2005159431A
Application number: JP2003390859A
Authority: JP
Inventors: Yoshikazu Kobayashi; 佳和小林
Original assignee: NEC Infrontia Corp
Current assignee: NEC Platforms Ltd
Priority date: 2003-11-20
Filing date: 2003-11-20
Publication date: 2005-06-16
Also published as: US20050111390A1

Abstract

【課題】ＩＰ網に接続された端末を公衆電話回線網に接続された電話機と接続する。
【解決手段】サーバが、公衆電話交換網に接続された電話機宛てのインバイトリクエストを受信したら、インバイトリクエストをゲートウェイ端末に転送し、ゲートウェイ端末が、インバイトリクエストを受信したら、電話機に発呼する。サーバが、電話機の電話番号をインバイトリクエストのスタートラインのうちのゲートウェイ端末のＵＲＩを記述した領域以外の領域、インバイトリクエストのスタートライン以外の領域又はインバイトリクエスト以外のメッセージに挿入する。ゲートウェイ端末が、電話機の電話番号をインバイトリクエストのスタートライン以外の領域又はインバイトリクエスト以外のメッセージから読み出し、ゲートウェイ端末は、発呼ステップにおいて、読出しステップで読み出した電話番号を用いて、電話機に発呼する。
【選択図】図３

Description

本発明は、電話回線を確立するためのシグナリング方法に関し、特に、インターネット又はイントラネット等のＩＰ(Internet Protocol)網に接続されている端末と公衆電話回線網に接続されている電話機との間で電話回線を確立するためのシグナリング方法に関する。

インターネットにおいて、ユーザを特定のセッションに招待するために開発されたＳＩＰ(Session Initiation Protocol)は、マルチメディアセッションを確立、変更又は切断するために利用されている。

ここで、インターネットに接続されている端末（ＳＩＰでいうユーザエージェント）と公衆電話回線網に接続されている電話機を接続する二種類のシグナリング方法が従来行われている。

図１は、第１のシグナリング方法を実現するためのシステムの構成及び該シグナリング方法のシーケンスを示す。

図１を参照すると、端末９０１が電話機９０４に電話をかける場合、まず、端末９０１がインバイトリクエスト(Invite Request)９１１をＳＩＰリダイレクトサーバ９０２に送信する。インバイトリクエスト９１１のヘッダーフイールドのtoラインには、電話機９０４の電話番号である「０３１２３４１２３４」並びに端末９０１、ＳＩＰリダイレクトサーバ９０２及びＳＩＰゲートウェイサーバ９０３が属するドメインの名称である「ｄｏｍｉｎ．ｃｏｍ」が結合した「０３１２３４１２３４＠ｄｏｍｉｎ．ｃｏｍ」が記述されている。

ＳＩＰリダイレクトサーバ９０２は、インバイトリクエスト９１１を受信すると、ＳＩＰゲートウェイサーバ９０３のアドレスを含む応答９１２を端末９０１に返信する。

端末９０１は、応答９１２を受信すると、インバイトリクエスト９１４をＳＩＰゲートウェイサーバ９０３に送信する。インバイトリクエスト９１１と同様に、インバイトリクエスト９１４のスタートラインには、９０３のゲートウエイサーバのURLが記載され、ヘッダーフィールドのtoには「０３１２３４１２３４＠ｄｏｍｉｎ．ｃｏｍ」が記述されている。

ＳＩＰゲートウェイサーバ９０３は、インバイトリクエスト９１４を受信すると、インバイトリクエスト９１４のヘッダフィールドに記述されている「０３１２３４１２３４＠ｄｏｍｉｎ．ｃｏｍ」から「０３１２３４１２３４」を読み出して、公衆電話回線網を捕捉し、電話番号が「０３１２３４１２３４」である電話機９０４にダイアルする（９１５）。

図２は、第２のシグナリング方法を実現するためのシステムの構成及び該シグナリング方法のシーケンスを示す。

図２を参照すると、端末９０１が電話機９０４に電話をかける場合、まず、端末９０１がインバイトリクエスト９２１をＳＩＰプロキシサーバ９０５に送信する。インバイトリクエスト９２１のヘッダフィールドのtoには、電話機９０４の電話番号である「０３１２３４１２３４」並びに端末９０１、ＳＩＰプロキシサーバ９０５及びＳＩＰゲートウェイサーバ９０３が属するドメインの名称である「ｄｏｍｉｎ．ｃｏｍ」が結合した「０３１２３４１２３４＠ｄｏｍｉｎ．ｃｏｍ」が記述されている。

ＳＩＰプロキシサーバ９０５は、インバイトリクエスト９２１を受信すると、インバイトリクエスト９２２をヘッダフイールドのtoでしめされた宛先を扱えると予想したＳＩＰゲートウェイサーバ９０３に送信する。インバイトリクエスト９２２のヘッダフイールドにも「０３１２３４１２３４＠ｄｏｍｉｎ．ｃｏｍ」が記述されている。

ＳＩＰゲートウェイサーバ９０３は、インバイトリクエスト９２２を受信すると、インバイトリクエスト９２２のヘッダーフイールドに記述されている「０３１２３４１２３４＠ｄｏｍｉｎ．ｃｏｍ」から「０３１２３４１２３４」を読み出して、公衆電話回線網を捕捉し、電話番号が「０３１２３４１２３４」である電話機９０４にダイアルする（９２３）。

なお、本発明に関連する先行技術文献として以下のものがある。非特許文献１は、ＳＩＰに関するものであり、非特許文献２はＳＩＰメッセージのボディに記述される内容に関するＳＤＰ(Session Description Protocol)に関するものであり、非特許文献３は、ＲＴＰ(Real Time Packet)の伝送を制御するためのＲＴＣＰ(Real time Control protocol)に関するものである。非特許文献４は、上記２種類のシグナリング方法に関連したものである。
ＲＦＣ３２６１規格書（http://www.ietf.org/rfc/rfc3261.txt）ＲＦＣ２３２７規格書（http://www.ietf.org/rfc/rfc2327.txt?number=2327）ＲＦＣ３５５０規格書（http://rfc3550.x42.com/） How to Add MSN Messenger Services for PC-to-Phone Functionality to Cisco Packet Voice Network(http://www.cisco.com/warp/public/cc/techno/tyvdve/sip/prodlit/mpcph_wp.htm)

上述した二種類の方法によれば、ＳＩＰゲートウェイサーバを用いなければならない。ＳＩＰゲートウェイサーバは、ＳＩＰサーバ機能とゲートウェイ機能とを有する装置であるが、特に、ＳＩＰサーバ機能部分が高価であるため、ＳＩＰゲートウェイサーバは高価となる。

そこで、本発明は、ＳＩＰゲートウェイサーバを用いなくても、ＩＰ網に接続されている端末を公衆電話回線網に接続されている電話機と接続することを可能とするシグナリング方法並びにサーバ及びゲートウェイ端末を提供することを目的とする。

本発明の第１の観点によれば、サーバが、公衆電話交換網に接続された電話機宛てのインバイトリクエストを受信したならば、該インバイトリクエストをゲートウェイ端末に転送する転送ステップと、前記ゲートウェイ端末が、少なくとも前記インバイトリクエストを受信したならば、前記電話機に発呼する発呼ステップと、を備えることを特徴とするシグナリング方法が提供される。

また、本発明の第１の観点によるシグナリング方法は、前記サーバが、受信した前記インバイトリクエストから前記電話機の電話番号を読み出す読出しステップと、前記サーバが、前記ゲートウェイ端末のＵＲＩを受信した前記インバイトリクエストのスタートラインに挿入するステップと、前記サーバが、前記電話機の前記電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのスタートラインのうちの前記ゲートウェイ端末のＵＲＩを記述した領域以外の領域、該スタートライン以外の領域又は前記ゲートウェイ端末に送信するべき前記インバイトリクエスト以外の前記ゲートウェイ端末に送信するべきメッセージに挿入する挿入ステップと、を更に備えていてもよい。

更に、本発明の第１の観点によるシグナリング方法は、前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストの前記スタートライン若しくは該スタートライン以外の領域又は前記サーバから受信した前記インバイトリクエスト以外の前記サーバから受信した前記メッセージから読み出す読出しステップを更に備え、前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼してもよい。

更に、本発明の第１の観点によるシグナリング方法は、前記サーバが、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのヘッダのスタートラインに挿入する挿入ステップを更に備えていてもよい。

更に、本発明の第１の観点によるシグナリング方法は、前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのヘッダのスタートラインから読み出す読出しステップを更に備え、前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼してもよい。

更に、本発明の第１の観点によるシグナリング方法は、前記サーバが、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのヘッダフィールドに挿入する挿入ステップを更に備えていてもよい。

更に、本発明の第１の観点によるシグナリング方法は、前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのヘッダフィールドから読み出す読出しステップを更に備え、前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼してもよい。

更に、本発明の第１の観点によるシグナリング方法は、前記サーバが、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのボディに挿入する挿入ステップを更に備えていてもよい。

更に、本発明の第１の観点によるシグナリング方法は、前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのボディから読み出す読出しステップを更に備え、前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼してもよい。

更に、本発明の第１の観点によるシグナリング方法は、前記サーバが、前記電話機の電話番号を前記ゲートウェイ端末に送信するべきアクノーレッジリクエストに挿入する挿入ステップを更に備えていてもよい。

更に、本発明の第１の観点によるシグナリング方法は、前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記アクノーレッジリクエストから読み出す読出しステップを更に備え、前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼してもよい。

更に、本発明の第１の観点によるシグナリング方法は、前記サーバが、前記電話機の電話番号を前記ゲートウェイ端末に送信するべきＲＴＣＰ(Real Time Control Protocol)パケットに挿入するステップを更に備えていてもよい。

更に、本発明の第１の観点によるシグナリング方法は、前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記ＲＴＣＰパケットから読み出す読出ステップを更に備え、前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼してもよい。

本発明の第２の観点によれば、公衆電話交換網に接続された電話機宛てのインバイトリクエストを受信したならば、該インバイトリクエストをゲートウェイ端末に転送する転送手段を備えることを特徴とするサーバが提供される。

本発明の第２の観点によるサーバは、受信した前記インバイトリクエストから前記電話機の電話番号を読み出す読出し手段と、前記ゲートウェイ端末のＵＲＩを受信した前記インバイトリクエストのスタートラインに挿入する第１の挿入手段と、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのスタートラインのうちの前記ゲートウェイ端末のＵＲＬを記述した領域以外の領域、前記スタートライン以外の領域又は前記ゲートウェイ端末に送信するべき前記インバイトリクエスト以外の前記ゲートウェイ端末に送信するべきメッセージに挿入する第２の挿入手段と、を更に備えていてもよい。

本発明の第２の観点によるサーバにおいて、前記第２の挿入手段は、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのヘッダのスタートラインに挿入してもよい。

本発明の第２の観点による記載のサーバにおいて、前記第２の挿入手段は、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのヘッダフィールドに挿入してもよい。

本発明の第２の観点によるサーバにおいて、前記第２の挿入手段は、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのボディに挿入してもよい。

本発明の第２の観点によるサーバにおいて、前記第２の挿入手段は、前記電話機の電話番号を前記ゲートウェイ端末に送信するべきアクノーレッジリクエストに挿入してもよい。

本発明の第２の観点によるサーバにおいて、前記第２の挿入手段は、前記電話機の電話番号を前記ゲートウェイ端末に送信するべきＲＴＣＰ(Real Time Control Protocol)パケットに挿入してもよい。

本発明の第３の観点によれば、公衆電話交換網に接続された電話機宛てのインバイトリクエストを少なくとも受信したならば、該インバイトリクエストを基に、前記電話機に発呼する発呼手段を備えることを特徴とするゲートウェイ端末が提供される。

本発明の第３の観点によるゲートウェイ端末は、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのスタートラインのうちの当該ゲートウェイ端末のＵＲＩを記述した領域以外の領域、該スタートライン以外の領域又は前記サーバから受信した前記インバイトリクエスト以外の前記サーバから受信した前記メッセージから読み出す読出し手段を更に備え、前記発呼手段は、前記読出し手段で読み出した前記電話番号を用いて、前記電話機に発呼してもよい。

本発明の第３の観点によるゲートウェイ端末において、前記読出し手段は、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのヘッダのスタートラインから読み出してもよい。

本発明の第３の観点によるゲートウェイ端末において、前記読出し手段は、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのヘッダフィールドから読み出してもよい。

本発明の第３の観点によるゲートウェイ端末において、前記読出し手段は、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのボディから読み出してもよい。

本発明の第３の観点によるゲートウェイ端末において、前記読出し手段は、前記電話機の電話番号を前記サーバから受信したアクノーレッジリクエストから読み出してもよい。

本発明の第３の観点によるゲートウェイ端末において、前記読出し手段は、前記電話機の電話番号を前記サーバから受信したＲＴＣＰ(Real Time Control Protocol)パケットから読み出してもよい。

本発明によれば、ゲートウェイ機能を有するＳＩＰサーバが不要となるので、ＩＰ網に接続されている端末と公衆電話回線網に接続されている電話機との接続を安価に実現することができる。

以下、図面を参照して本発明を実施するための最良の形態について詳細に説明する。

図３は、本発明の実施形態によるシグナリング方法を行うためのシステムの構成及び該シグナリング方法のシーケンスを示す図である。

図３を参照すると、端末１０１が電話機１０４に電話をかける場合、まず、端末１０１がインバイトリクエスト１１１をＳＩＰサーバ１０２に送信する。インバイトリクエスト１１１のスタートラインには、電話機１０４の電話番号である「０３１２３４１２３４」並びに端末１０１、ＳＩＰサーバ１０２及びゲートウェイ端末１０３が属するドメインの名称である「ｄｏｍｉｎ．ｃｏｍ」が結合した「０３１２３４１２３４＠ｄｏｍｉｎ．ｃｏｍ」が記述されている。

ここで、ゲートウェイ端末とは、ＳＩＰでいうところのユーザエージェントであって、ゲートウェイの機能が追加されたものである。

ＳＩＰサーバ１０２は、インバイトリクエスト１１１を受信すると、インバイトリクエスト１１２をゲートウェイ端末１０３に送信する。インバイトリクエスト１１２のスタートラインにはゲートウェイ端末１０３のＳＩＰＵＲＬである「ｇａｔｅｗａｙ−ｔｅｒｍｉｎａｌ＠ｄｏｍｉｎ．ｃｏｍ」が記述されている。

ＳＩＰサーバ１０２は、電話機１０４の電話番号を、インバイトリクエスト１１２のスタートラインから削除し、ゲートウエイ端末１０３のＵＲＩを挿入するが、その代わりに、電話機１０４の電話番号を、インバイトリクエスト１１２のスタートライン又はヘッダフィールド又はボディに挿入する。

スタートラインへの電話番号記載は、
ＳＩＰ；ゲートウエイ端末のＵＲＩＵＳＥＲ＝Ｐｈｏｎｅ＋電話番号
又は、
ＳＩＰ；ゲートウエイ端末のＵＲＩｔａｇ電話番号
とする。本記述例は、一例であり、スタートラインへの記述方法を限定するものでは無い。

ボディに挿入する場合は、ＴＯのＵＲＩで
ＳＩＰ；ゲートウエイ端末のＵＲＩＵＳＥＲ＝Ｐｈｏｎｅ＋電話番号
又は、
ＳＩＰ；ゲートウエイ端末のＵＲＩｔａｇ電話番号
とする。

ボディ内のＴｏＵＲＩはもとの
ＴＯ；電話番号＠ドメインＵＳＥＲ＝Ｐｈｏｎｅ
のままでもよい。本記述例は、一例であり、ヘッダフィールドへの記述方法を限定するものでは無い。

また、ＳＩＰサーバ１０２は、電話機１０４の電話番号をインバイトリクエスト１１２の後にゲートウェイ端末１０３に送信するメッセージに挿入しても良い。すなわち、ＳＩＰサーバ１０２は、例えば、電話機１０４の電話番号をＡＣＫリクエストに挿入しても良いし、ＲＴＣＰ(Real Time Control Protocol)パケットに挿入しても良い。

ゲートウェイ端末１０３は、インバイトリクエスト１１２を受信すると、インバイトリクエスト１１２のヘッダフィールド又はボディから電話機１０４の電話番号を読み出す。又は、ゲートウェイ端末１０３は、インバイトリクエスト１１２の後にＳＩＰサーバ１０２から受信するメッセージから電話機１０４の電話番号を読み出しても良い。すなわち、ゲートウェイ端末１０３は、例えば、ＡＣＫリクエストに挿入されている電話機１０４の電話番号を読み出しても良いし、ＲＴＣＰパケットに挿入されている電話機１０４の電話番号を読み出しても良い。そして、ゲートウェイ端末１０３は、公衆電話回線を捕捉し、電話番号が「０３１２３４１２３４」である電話機１０４にダイアルする（１１３）。

次に、実施例について説明する。

実施例１においては、インバイトリクエストのヘッダフィールドに電話機の電話番号を挿入する。

端末１０１がＳＩＰサーバ１０２に送信するインバイトリクエスト１１１は図４に示すようなものである。図４を参照すると、インバイトリクエストは、スタートライン、ヘッダフィールド、空白行及びボディを備える。スタートラインには、電話機の電話番号である「０３１２３４１２３４」及び端末１０１、ＳＩＰサーバ１０２及びゲートウェイ端末１０３が属するドメインの名称である「ｄｏｍｉｎ．ｃｏｍ」が結合した「０３１２３４１２３４＠ｄｏｍｉｎ．ｃｏｍ」が記述されている。

ＳＩＰサーバは、インバイトリクエスト１１１を受信すると、インバイトリクエスト１１２をゲートウェイ端末１０３に送信する。インバイトリクエスト１１２のスタートライン及びヘッダフィールドは、例えば、図５に示すようなものである。なお、インバイトリクエスト１１２のボディは、インバイトリクエスト１１１のボディと同一である。図５を参照すると、インバイトリクエスト１１２のスタートラインには、ゲートウェイ端末１０３のＳＩＰＵＲＬである「ｇａｔｅｗａｙ−ｔｅｒｍｉｎａｌ＠ｄｏｍｉｎ．ｃｏｍ」が記述されている。また、ヘッダフィールドの項目のうちの項目「Ｖｉａ」に電話機１０４の電話番号が挿入さている。

ＳＩＰサーバ１０２は、図５に示すように項目「Ｖｉａ」に電話機１０４の電話番号を挿入する代わりに、図６又は７に示すように項目「Ｖｉａ」に電話機１０４の電話番号を挿入しても良い。また、ＳＩＰサーバ１０２は、図８に示すように項目「Ｆｒｏｍ」に電話機１０４の電話番号を挿入しても良い。更に、ＳＩＰサーバ１０２は、図９に示すように項目「Ｆｒｏｍ」の「ｔａｇ」の２つ目の要素として電話機１０４の電話番号を挿入しても良い。更に、ＳＩＰサーバ１０２は、図１０に示すように項目「Ｆｒｏｍ」の「ｔａｇ」の要素として電話機１０４の電話番号を挿入しても良い。図１０の例では、電話番号のｔａｇであることを明確にするために電話番号「０３１２３４１２３４」の前に文字列「ｔｅｌ」を追加している。更に、ＳＩＰサーバ１０２は、図１１に示すように項目「Ｔｏ」に電話機１０４の電話番号を挿入しても良い。更に、ＳＩＰサーバ１０２は、図１２に示すように項目「Ｔｏ」の「ｔａｇ」の２つ目の要素として電話機１０４の電話番号を挿入しても良い。更に、ＳＩＰサーバ１０２は、図１３に示すように項目「Ｔｏ」の「ｔａｇ」の要素として電話機１０４の電話番号を挿入しても良い。図１３の例では、電話番号のｔａｇであることを明確にするために電話番号「０３１２３４１２３４」の前に文字列「ｔｅｌ」を追加している。更に、ＳＩＰサーバ１０２は、図１４又は１５に示すように項目「Ｃａｌｌ−ＩＤ」の「ｔａｇ」として電話機１０４の電話番号を挿入しても良い。更に、ＳＩＰサーバ１０２は、図１６又は１７に示すように項目「Ｃｓｅｑ」に電話機１０４の電話番号を挿入しても良い。図１７の例では、電話番号のｔａｇであることを明確にするために電話番号「０３１２３４１２３４」の前に文字列「ｔｅｌ」を追加している。更に、ＳＩＰサーバ１０２は、図１８、１９又は２０に示すように項目「Ｃｏｎｔａｃｔ」に電話機１０４の電話番号を挿入しても良い。図２０の例では、電話番号のｔａｇであることを明確にするために電話番号「０３１２３４１２３４」の前に文字列「ｔｅｌ」を追加している。更に、ＳＩＰサーバ１０２は、図２１、２２又は２３に示すように項目「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ」に電話機１０４の電話番号を挿入しても良い。図２２の例では、電話機のｔａｇであることを明確にするために電話番号「０３１２３４１２３４」の前に文字列「ｔｅｌ」を追加している。

ゲートウェイ端末１０３は、インバイトリクエスト１１２を受信すると、インバイトリクエスト１１２のヘッダの何れかの項目に挿入されている電話機１０４の電話番号を読み出す。その後、ゲートウェイ端末１０３は、公衆電話回線網を補足し、電話機１０４にダイアルする。

図２４は、実施例１によるメッセージ伝送手順を示すシーケンス図である。図２４を参照すると、ゲートウェイ１０３が電話機１０４にダイアルするステップまでは実施形態と同様である。

ゲートウェイ端末１０３と電話機１０４との間の回線が確立したならば（１１４）、ゲートウェイ端末１０３は、ＯＫ応答１１５をＳＩＰサーバ１０２に返信する。ＳＩＰサーバ１０２は、ＯＫ応答１１５を受信すると、ＯＫ応答１１６を端末１０１に返信する。端末１０１は、ＯＫ応答１１６を受信すると、アクノーレッジリクエスト（acknowledge request）１１７をＳＩＰサーバ１０２に送信する。ＳＩＰサーバ１０２は、アクノーレッジリクエスト１１７を受信すると、アクノーレッジリクエスト１１８をゲートウェイ端末１０３に送信する。

実施例２においては、インバイトリクエストのボディに電話機の電話番号を挿入する。

ＳＩＰサーバは、インバイトリクエスト１１１を受信すると、インバイトリクエスト１１２をゲートウェイ端末１０３に送信する。インバイトリクエスト１１２のスタートラインは、実施例１と同様に以下の通りである。

INVITE SIP:gateway-terminal@domin.com SIP/2.0
インバイトリクエスト１１２のヘッダフィールドは、インバイトリクエスト１１１のヘッダフィールドと同様に、図４に示すとおりである。

インバイトリクエスト１１２のボディは本発明に従ったものである。インバイトリクエストのボディの何れの項目にも（図４に示すｖ、ｂ、…、ｉの何れにも）電話番号を記述することができる。ここで、本来の項目値と本発明による電話番号とを区別できるようにするために、例えば、本来セッション情報を得るための電話番号を表すｐを用いるとした場合、本来の通常の電話番号を表すためには、
ｐ＝０３３４３１１８３１
と記載するべきところを、本発明による電話番号を表すためには、
ｐ＝＜ｓｉｐ：０３１２３４１２３４＠ｄｏｍｉｎ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ＞
と記載する。

ゲートウェイ端末１０３は本発明に従って設計された端末であり、同一の項目であっても、書式を判別することにより、その項目の値が本来の項目値であるのか本発明による電話番号であるのかを区別することができる。

ゲートウェイ端末１０３は、インバイトリクエスト１１２を受信すると、インバイトリクエスト１１２のボディの何れかの項目に挿入されている電話機１０４の電話番号を読み出す。その後、ゲートウェイ端末１０３は、公衆電話回線網を補足し、電話機１０４にダイアルする。

実施例３においては、アクノーレッジリクエスト（acknowledge request）のヘッダフィールドに電話機の電話番号を挿入する。

図２５は、実施例３におけるメッセージ伝送手順を表すシーケンス図である。

図２５を参照すると、端末１０１は、インバイトリクエスト１３１をＳＩＰサーバ１０２に送信する。インバイトリクエスト１３１のスタートラインには、「０３１２３４１２３４＠ｄｏｍｉｎ．ｏｃｍ」が記述されている。ＳＩＰサーバ１０２は、インバイトリクエスト１３１を受信すると、インバイトリクエスト１３２をゲートウェイ１０３に送信する。インバイトリクエスト１３２のスタートラインには、「ｇａｔｅｗａｙ−ｔｅｒｍｉｎａｌ＠ｄｏｍｉｎ．ｃｏｍ」が記述されている。実施例１及び２とは異なり、インバイトリクエスト１１２のヘッダフィールド及びボディには、電話機１０４の電話番号が挿入されることはない。ＳＩＰサーバ１０２は、インバイトリクエスト１３１を受信すると、更に、トライング応答１３３を端末１０１に返信する。ゲートウェイ端末１０３は、インバイトリクエスト１３２を受信すると、公衆電話回線網を捕捉し（１３４）、リンギング応答１３５をＳＩＰサーバ１０２に返信する。ＳＩＰサーバ１０２は、リンギング応答１３７を受信すると、リンギング応答１３６を端末１０１に返信する。その後、ゲートウェイ端末１０３はＯＫ応答１３７をＳＩＰサーバ１０２に返信する。ＳＩＰサーバ１０２は、ＯＫ応答１３７を受信すると、ＯＫ応答１３８を端末１０１に返信する。端末１０１は、ＯＫ応答１３８を受信すると、アクノーレッジリクエスト１３９をＳＩＰサーバ１０２に送信する。ＳＩＰサーバ１０２はアクノーレッジリクエスト１３９を受信すると、アクノーレッジリクエスト１４０をゲートウェイ端末１０３に送信する。アクノーレッジリクエスト１４０には、電話機１０４の電話番号である「０３１２３４１２３４」が挿入されている。ゲートウェイ端末１０３は、アクノーレッジリクエスト１４０を受信すると、アクノーレッジリクエスト１４０から電話機１０４の電話番号を読み出し、電話機１０４にダイアルをかける（１４１）。その後、ゲートウェイ端末１０３と電話機１０４との間の回線が確立される（１４２）。

回線確立に失敗した場合には、ゲートウェイ端末１０３は、リクエストエラー、サーバエラー又はグローバルエラーを端末１０１に送信する。

図２６は、実施例３における他のメッセージ伝送手順を表すシーケンス図である。

図２６を参照すると、端末１０１は、インバイトリクエスト１５１をＳＩＰサーバ１０２に送信する。インバイトリクエスト１５１のスタートラインには、「０３１２３４１２３４＠ｄｏｍｉｎ．ｃｏｍ」が記述されている。ＳＩＰサーバ１０２は、インバイトリクエスト１５１を受信すると、インバイトリクエスト１５２をゲートウェイ１０３に送信する。インバイトリクエスト１３２のスタートラインには、「ｇａｔｅｗａｙ−ｔｅｒｍｉｎａｌ＠ｄｏｍｉｎ．ｃｏｍ」が記述されている。実施例１及び２とは異なり、インバイトリクエスト１５２のヘッダフィールド及びボディには、電話機１０４の電話番号が挿入されることはない。ＳＩＰサーバ１０２は、続いて、アクノーレッジリクエスト１５３をゲートウェイ１０３に送信する。アクノーレッジリクエスト１５３には、電話機１０４の電話番号である「０３１２３４１２３４」が挿入されている。ＳＩＰサーバ１０２は、続いてトライング応答１５４を端末１０１に送信する。ゲートウェイ端末１０３は、アクノーレッジリクエスト１５３を受信すると、アクノーレッジリクエスト１５３から電話番号を読み出し、公衆電話回線網を捕捉し、電話機１０４にダイアルする（１５５）。ゲートウェイ端末１０３は、続いて、リンギング応答１５６をＳＩＰサーバ１０２に返信する。ＳＩＰサーバ１０２は、リンギング応答１５６を受信すると、リンギング応答１５７を端末１０１に返信する。その後、ゲートウェイ端末１０３と電話機１０４との間の回線が確立されると（１５８）、ゲートウェイ端末１０３は、ＯＫ応答１５９をＳＩＰサーバ１０２に返信する。ＳＩＰサーバ１０２は、ＯＫ応答１５９を受信すると、ＯＫ応答１６０を端末１０１に返信する。端末１０１は、ＯＫ応答１６０を受信すると、アクノーレッジリクエスト１６１をＳＩＰサーバ１０２に送信する。ＳＩＰサーバ１０２は、アクノーレッジリクエスト１６１を受信すると、アクノーレッジリクエスト１６２をゲートウェイ端末１０３に送信する。

回線確立に失敗した場合には、ゲートウェイ端末１０３は、ＯＫ応答１５９をＳＩＰサーバ１０２に返さない。

アクノーレッジリクエスト１４０又は１５３のヘッダフィールドに電話機の電話番号を挿入する様式は、実施例１のインバイトリクエストのヘッダフィールドに電話番号を挿入する様式と同様である。従って、アクノーレッジリクエスト１４０又は１５３のヘッダフィールドは、例えば、図５〜２３に示すようなヘッダフィールドとなる。

実施例４においては、ＲＦＣ３５５０に関する非特許文献３の６．２．４項に記載のレシーバレポートＲＴＣＰパケット(Receiver Report RTCP Packet)のプロファイルスペシフィックエクステンションズ(profile-specific extensions)の予め定めた領域に電話機１０４の電話番号を記述する。

この他、ＳＩＰサーバ１０２は、シグナリング用のメッセージ以外のメッセージを用いて、電話機１０４の電話番号をゲートウェイ端末１０３に送信しても良い。

実施例５は、ＳＩＰサーバ１０２とゲートウエイ端末１０３を同一情報機器内に構築するものである。

本発明は、ＩＰ網に接続されている端末と公衆電話回線網に接続されている電話機とを接続することに利用することができる。

また、企業電話システム専用線への接続、ＶｏＩＰキャリアサービスへの接続でもよい。通信するメディアは、電話に限定するものでなく、他のメディア、例えばビデオ会議ストリームでも、メールでもよい。

第１の従来のシグナリング方法を実現するためのシステムの構成及び該シグナリング方法のシーケンスを示す図である。第２の従来のシグナリング方法を実現するためのシステムの構成及び該シグナリング方法のシーケンスを示す図である。本発明の実施形態によるシグナリング方法を実現するためのシステムの構成及びシグナリング方法のシーケンスを示す図である。本発明の実施形態による端末がＳＩＰサーバに送信するインバイトリクエストの構成を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第１の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第２の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第３の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第４の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第５の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第６の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第７の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第８の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第９の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第１０の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第１１の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第１２の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第１３の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第１４の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第１５の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第１６の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第１７の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第１８の例を示す図である。本発明の実施例１によるＳＩＰサーバがゲートウェイ端末に送信するインバイトリクエストのスタートライン及びヘッダフィールドの第１９の例を示す図である。本発明の実施例１によるシグナリング方法を実現するためのシステムの構成及びシグナリング方法のシーケンスを示す図である。本発明の実施例２によるシグナリング方法を実現するためのシステムの構成及びシグナリング方法のシーケンスを示す図である。本発明の実施例２による他のシグナリング方法を実現するためのシステムの構成及びシグナリング方法のシーケンスを示す図である。

符号の説明

１０１端末
１０２ＳＩＰサーバ
１０３ゲートウェイ端末
１０４電話機

Claims

サーバが、公衆電話交換網に接続された電話機宛てのインバイトリクエストを受信したならば、該インバイトリクエストをゲートウェイ端末に転送する転送ステップと、
前記ゲートウェイ端末が、少なくとも前記インバイトリクエストを受信したならば、前記電話機に発呼する発呼ステップと、
を備えることを特徴とするシグナリング方法。
請求項１に記載のシグナリング方法において、
前記サーバが、受信した前記インバイトリクエストから前記電話機の電話番号を読み出す読出しステップと、
前記サーバが、前記ゲートウェイ端末のＵＲＩを受信した前記インバイトリクエストのスタートラインに挿入するステップと、
前記サーバが、前記電話機の前記電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのスタートラインのうちの前記ゲートウェイ端末のＵＲＩを記述した領域以外の領域、該スタートライン以外の領域又は前記ゲートウェイ端末に送信するべき前記インバイトリクエスト以外の前記ゲートウェイ端末に送信するべきメッセージに挿入する挿入ステップと、
を更に備えることを特徴とするシグナリング方法。
請求項２に記載のシグナリング方法において、
前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストの前記スタートライン若しくは該スタートライン以外の領域又は前記サーバから受信した前記インバイトリクエスト以外の前記サーバから受信した前記メッセージから読み出す読出しステップを更に備え、
前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼することを特徴とするシグナリング方法。
請求項１に記載のシグナリング方法において、
前記サーバが、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのヘッダのスタートラインに挿入する挿入ステップを更に備えることを特徴とするシグナリング方法。
請求項４に記載のシグナリング方法において、
前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのヘッダのスタートラインから読み出す読出しステップを更に備え、
前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼することを特徴とするシグナリング方法。
請求項１に記載のシグナリング方法において、
前記サーバが、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのヘッダフィールドに挿入する挿入ステップを更に備えることを特徴とするシグナリング方法。
請求項６に記載のシグナリング方法において、
前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのヘッダフィールドから読み出す読出しステップを更に備え、
前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼することを特徴とするシグナリング方法。
請求項１に記載のシグナリング方法において、
前記サーバが、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのボディに挿入する挿入ステップを更に備えることを特徴とするシグナリング方法。
請求項８に記載のシグナリング方法において、
前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのボディから読み出す読出しステップを更に備え、
前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼することを特徴とするシグナリング方法。
請求項１に記載のシグナリング方法において、
前記サーバが、前記電話機の電話番号を前記ゲートウェイ端末に送信するべきアクノーレッジリクエストに挿入する挿入ステップを更に備えることを特徴とするシグナリング方法。
請求項１０に記載のシグナリング方法において、
前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記アクノーレッジリクエストから読み出す読出しステップを更に備え、
前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼することを特徴とするシグナリング方法。
請求項１に記載のシグナリング方法において、
前記サーバが、前記電話機の電話番号を前記ゲートウェイ端末に送信するべきＲＴＣＰ(Real Time Control Protocol)パケットに挿入するステップを更に備えることを特徴とするシグナリング方法。
請求項１２に記載のシグナリング方法において、
前記ゲートウェイ端末が、前記電話機の電話番号を前記サーバから受信した前記ＲＴＣＰパケットから読み出す読出ステップを更に備え、
前記ゲートウェイ端末は、前記発呼ステップにおいて、前記読出しステップで読み出した前記電話番号を用いて、前記電話機に発呼することを特徴とするシグナリング方法。
公衆電話交換網に接続された電話機宛てのインバイトリクエストを受信したならば、該インバイトリクエストをゲートウェイ端末に転送する転送手段を備えることを特徴とするサーバ。
請求項１４に記載のサーバにおいて、
受信した前記インバイトリクエストから前記電話機の電話番号を読み出す読出し手段と、
前記ゲートウェイ端末のＵＲＩを受信した前記インバイトリクエストのスタートラインに挿入する第１の挿入手段と、
前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのスタートラインのうちの前記ゲートウェイ端末のＵＲＬを記述した領域以外の領域、前記スタートライン以外の領域又は前記ゲートウェイ端末に送信するべき前記インバイトリクエスト以外の前記ゲートウェイ端末に送信するべきメッセージに挿入する第２の挿入手段と、
を更に備えることを特徴とするサーバ。
請求項１５に記載のサーバにおいて、
前記第２の挿入手段は、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのヘッダのスタートラインに挿入することを特徴とするサーバ。
請求項１５に記載のサーバにおいて、
前記第２の挿入手段は、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのヘッダフィールドに挿入することを特徴とするサーバ。
請求項１５に記載のサーバにおいて、
前記第２の挿入手段は、前記電話機の電話番号を前記ゲートウェイ端末に送信するべき前記インバイトリクエストのボディに挿入することを特徴とするサーバ。
請求項１５に記載のサーバにおいて、
前記第２の挿入手段は、前記電話機の電話番号を前記ゲートウェイ端末に送信するべきアクノーレッジリクエストに挿入することを特徴とするサーバ。
請求項１５に記載のサーバにおいて、
前記第２の挿入手段は、前記電話機の電話番号を前記ゲートウェイ端末に送信するべきＲＴＣＰ(Real Time Control Protocol)パケットに挿入することを特徴とするサーバ。
公衆電話交換網に接続された電話機宛てのインバイトリクエストを少なくとも受信したならば、該インバイトリクエストを基に、前記電話機に発呼する発呼手段を備えることを特徴とするゲートウェイ端末。
請求項２１に記載のゲートウェイ端末において、
前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのスタートラインのうちの当該ゲートウェイ端末のＵＲＩを記述した領域以外の領域、該スタートライン以外の領域又は前記サーバから受信した前記インバイトリクエスト以外の前記サーバから受信した前記メッセージから読み出す読出し手段を更に備え、
前記発呼手段は、前記読出し手段で読み出した前記電話番号を用いて、前記電話機に発呼することを特徴とするゲートウェイ端末。
請求項２１に記載のゲートウェイ端末において、
前記読出し手段は、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのヘッダのスタートラインから読み出すことを特徴とするゲートウェイ端末。
請求項２２に記載のゲートウェイ端末において、
前記読出し手段は、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのヘッダフィールドから読み出すことを特徴とするゲートウェイ端末。
請求項２２に記載のゲートウェイ端末において、
前記読出し手段は、前記電話機の電話番号を前記サーバから受信した前記インバイトリクエストのボディから読み出すことを特徴とするゲートウェイ端末。
請求項２２に記載のゲートウェイ端末において、
前記読出し手段は、前記電話機の電話番号を前記サーバから受信したアクノーレッジリクエストから読み出すことを特徴とするゲートウェイ端末。
請求項２２に記載のゲートウェイ端末において、
前記読出し手段は、前記電話機の電話番号を前記サーバから受信したＲＴＣＰ(Real Time Control Protocol)パケットから読み出すことを特徴とするゲートウェイ端末。