(57)【要約】   【課題】  ＳＩＰプロキシサーバ主導でセッションの継続確認を行うことにより、その処理を平準化することができる。したがって、サーバの処理能力を高めることなく、適切にセッション監視を実現する  【解決手段】  ＳＩＰに基づいて通信するＳＩＰユーザエージェント間のセッション継続確認方法において、ＳＩＰプロキシサーバ１０において、発信側のＳＩＰユーザエージェント（発信者端末）１２に対して、リフレッシャを着信側のＳＩＰユーザエージェント（着信者端末）１４に設定するＳＩＰメッセージを送信し、その一方、着信側のＳＩＰユーザエージェント（着信者端末）１４に対して、リフレッシャを発信側のＳＩＰユーザエージェント（発信者端末）１２に設定するＳＩＰメッセージを送信する。ＳＩＰプロキシサーバ１０は、セッション継続確認のためのＳＩＰメッセージを、それぞれのＳＩＰユーザエージェントに送信する。【選択図】  図１
2005327101.tif 000002
【特許請求の範囲】
【請求項１】
ＳＩＰに基づいて通信するＳＩＰユーザエージェント間のセッション継続確認方法であって、
ＳＩＰプロキシサーバにおいて、セッション継続確認のためのＳＩＰメッセージを、前記ＳＩＰユーザエージェントに送信することを特徴とするセッション継続確認方法。
【請求項２】
ＳＩＰに基づいて通信するＳＩＰユーザエージェント間のセッション継続確認方法であって、
ＳＩＰプロキシサーバにおいて、発信側のＳＩＰユーザエージェントに対して、リフレッシャを着信側のＳＩＰユーザエージェントに設定するＳＩＰメッセージを送信し、
前記着信側のＳＩＰユーザエージェントに対して、リフレッシャを発信側のＳＩＰユーザエージェントに設定するＳＩＰメッセージを送信し、かつ、
セッション継続確認のためのＳＩＰメッセージを、それぞれのＳＩＰユーザエージェントに送信することを特徴とするセッション継続確認方法。
【請求項３】
前記ＳＩＰプロキシサーバにおいて、前記リフレッシャを着信側のＳＩＰユーザエージェントに設定する情報を、INVITEのＳＩＰメッセージのヘッダ部に格納し、かつ、
前記リフレッシャを発信側のＳＩＰユーザエージェントに設定する情報を、前記INVITEのＳＩＰメッセージの応答である、200OKのＳＩＰメッセージのヘッダ部に格納することを特徴とする請求項２に記載のセッション継続確認方法。
【請求項４】
前記ＳＩＰプロキシサーバにおいて、発信側或いは着信側の何れか一方のＳＩＰユーザエージェントから、セッション継続確認のためのＳＩＰメッセージの応答を受信した後、他方のＳＩＰユーザエージェントに対して、セッション継続確認のためのＳＩＰメッセージを送信することを特徴とする請求項１ないし３の何れか一項に記載のセッション継続確認方法。
【請求項５】
前記ＳＩＰプロキシサーバにおいて、発信側或いは着信側の何れか一方のＳＩＰユーザエージェントに、セッション継続確認のためのＳＩＰメッセージを送信し、当該ＳＩＰユーザエージェントからの応答を受信しなかった場合に、他方のユーザエージェントに対して、セッション終了を示すＳＩＰメッセージを送信することを特徴とする請求項１ないし４の何れか一項に記載のセッション継続確認方法。
【請求項６】
前記ＳＩＰプロキシサーバにおいて、セッションの単位でセッション継続確認のためのＳＩＰメッセージを送信するための時刻を含む情報を管理する管理テーブルを設け、
所定のタイミングで、前記管理テーブルを参照して、セッション継続確認のためのＳＩＰメッセージを送信すべきセッションを特定し、当該セッションを構成するＳＩＰユーザエージェントに、前記ＳＩＰメッセージを送信することを特徴とする請求項１ないし５の何れか一項に記載のセッション継続確認方法。
【請求項７】
さらに、前記管理テーブルを複数のブロックに分割し、
前記所定のタイミングで、前記複数のブロックの何れかを選択し、
選択されたブロック中、セッション継続確認のためのＳＩＰメッセージを送信すべきセッションを特定することを特徴とする請求項６に記載のセッション継続確認方法。
【請求項８】
前記セッション継続確認のためのＳＩＰメッセージが、UPDATEのセッションメッセージ或いはre-INVITEのＳＩＰメッセージであることを特徴とする請求項１ないし７の何れか一項に記載のセッション継続確認方法。
【請求項９】
ＳＩＰに基づいて通信するＳＩＰユーザエージェント間のセッション継続確認するＳＩＰプロキシサーバであって、
発信側のＳＩＰユーザエージェントに対して、リフレッシャを着信側のＳＩＰユーザエージェントに設定するＳＩＰメッセージを送信するとともに、前記着信側のＳＩＰユーザエージェントに対して、リフレッシャを発信側のＳＩＰユーザエージェントに設定するＳＩＰメッセージを送信するリフレッシャ設定手段と、
セッション継続確認のためのＳＩＰメッセージを、それぞれのＳＩＰユーザエージェントに送信するＳＩＰメッセージ送信手段とを備えたことを特徴とするＳＩＰプロキシサーバ。
【請求項１０】
前記リフレッシャ設定手段が、前記リフレッシャを着信側のＳＩＰユーザエージェントに設定する情報を、INVITEのＳＩＰメッセージのヘッダ部に格納し、かつ、前記リフレッシャを発信側のＳＩＰユーザエージェントに設定する情報を、前記INVITEのＳＩＰメッセージの応答である、200OKのＳＩＰメッセージのヘッダ部に格納することを特徴とする請求項９に記載のＳＩＰプロキシサーバ。
【請求項１１】
前記ＳＩＰメッセージ送信手段が、発信側或いは着信側の何れか一方のＳＩＰユーザエージェントから、セッション継続確認のためのＳＩＰメッセージの応答を受信した後、他方のＳＩＰユーザエージェントに対して、セッション継続確認のためのＳＩＰメッセージを送信することを特徴とする請求項９または１０に記載のＳＩＰプロキシサーバ。
【請求項１２】
前記ＳＩＰメッセージ送信手段が、発信側或いは着信側の何れか一方のＳＩＰユーザエージェントに、セッション継続確認のためのＳＩＰメッセージを送信し、当該ＳＩＰユーザエージェントからの応答を受信しなかった場合に、他方のユーザエージェントに対して、セッション終了を示すＳＩＰメッセージを送信することを特徴とする請求項９ないし１１の何れか一項に記載のＳＩＰプロキシサーバ。
【請求項１３】
さらに、セッションの単位でセッション継続確認のためのＳＩＰメッセージを送信するための時刻を含む情報を管理する管理テーブルを備え、
前記ＳＩＰメッセージ送信手段が、所定のタイミングで、前記管理テーブルを参照して、セッション継続確認のためのＳＩＰメッセージを送信すべきセッションを特定し、当該セッションを構成するＳＩＰユーザエージェントに、前記ＳＩＰメッセージを送信することを特徴とする請求項９ないし１２の何れか一項に記載のＳＩＰプロキシサーバ。
【請求項１４】
さらに、前記管理テーブルが複数のブロックに分割され、
前記ＳＩＰメッセージ送信手段が、前記所定のタイミングで、前記複数のブロックの何れかを選択し、選択されたブロック中、セッション継続確認のためのＳＩＰメッセージを送信すべきセッションを特定することを特徴とする請求項１３に記載のＳＩＰプロキシサーバ。
【請求項１５】
前記セッション継続確認のためのＳＩＰメッセージが、UPDATEのセッションメッセージ或いはre-INVITEのＳＩＰメッセージであることを特徴とする請求項９ないし１４の何れか一項に記載のＳＩＰプロキシサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＩＰ（Session Initiation Protocol）に基づく通信のセッション管理、特に、セッション継続確認方法およびＳＩＰプロキシサーバに関する。
【背景技術】
【０００２】
ＳＩＰを利用した端末間の音声パケット通信が実用化されている。端末の間のセッションを制御するために、ＳＩＰプロキシサーバが介在している。ＳＩＰプロキシサーバは、何れかの端末において、切断があったときや、ネットワークに障害があったときに、通話セッションを消滅させるための処理などを実行している。
【０００３】
非特許文献１において、発信者端末、着信者端末、および、これらの間に介在するＳＩＰプロキシサーバとの間では、図１０（ａ）に示すような、セッション監視ネゴシエーションおよびセッションタイマー監視が実施されている。
【０００４】
発信者端末からの「INVITE」が着信者端末に到達すると、着信者端末は、「180 Ringing」を発信者端末に返信し、その後、リフレッシャ(Refresher)を何れにするかを決める「REF」およびセッションタイマーの時間設定「SESSION-EXPIRES」を含む「200OK」を、着信者端末は発信者端末に送信する。なお、「SESSION-EXPIRES」とは、通話セッションの有効性を確認するために規定された一定の時間間隔をいう。また、「リフレッシャ」とは、通話セッションの有効性を確認するためのＳＩＰメッセージ（たとえば、「UPDATE」や「re-INVITE」）の送信者をいう。
【０００５】
図１０（ａ）の例では、「REF=UAS」、「SESSION-EXPIRES=200sec」を含む「200OK」が、発信者端末に返されている。これにより、着信者がリフレッシャになること、および、２００秒以内に、リフレッシャがセッションの有効性を確認する「UPDATE」信号を発信することが規定される。なお、これらの通信は、いったん、ＳＩＰプロキシサーバを経て、それぞれの端末に伝達される。
【０００６】
次いで、発信者端末から、ＳＩＰプロキシサーバを経て、着信者端末に「ACK」が伝達されると、通信セッションが開始される。通信セッションにおいて、音声のパケットは、ＳＩＰプロキシサーバを介さず、直接、発信者端末と着信者端末との間で通信される。
【０００７】
着信者端末は、たとえば、SESSION-EXPIRESの１／２にあたる１００秒ごとに、ＳＩＰプロキシサーバを介して、発信者端末に、「UPDATE」を送信し、発信者端末は、これに応答して、ＳＩＰプロキシサーバを介して、着信者端末に「200OK」を返信する。これを繰り返すことにより、発信者端末と着信者端末との間で、相互に通話セッションの有効性を確認する。
【０００８】
発信者がリフレッシャになる場合（図１０（ｂ）において、着信者端末から「REF=UAC」を含む「200OK」が送信された場合）にも、所定の時間間隔で（たとえば、１００秒ごとに）、発信者端末から「UPDATE」が、ＳＩＰプロキシサーバを介して着信者端末に送信される。
【０００９】
図１１に示すように、所定の時間間隔に、リフレッシャからの「UPDATE」の送信に対する「200OK」の返信がなかった場合には、再度、「UPDATE」が送信され、これに対しても返信がなければ、着信者端末において、切断のための処理が実行され、ＳＩＰプロキシサーバに「BYE」が送信される。
【００１０】
また、リフレッシャから規定された時間（２００秒）が経過しても、「UPDATE」が送信されなかった場合には、発信者端末において、切断のための処理が実行され、ＳＩＰプロキシサーバに「BYE」が送信される。
【００１１】
さらに、図１２に示すように、規定された時間（２００秒）が経過しても、「UPDATE」や「200OK」がＳＩＰプロキシサーバを介して、通信されず、かつ、何れの端末から「BYE」が通信されていない場合には、ＳＩＰプロキシサーバは、通話セッションが消滅したと判断する。これは、ネットワーク障害があった場合や双方の電話機が故障した場合に相当する。
【非特許文献１】「draft-ietf-session-timer-09」（S. Donovan, J.  Rosenberg）  ２００２年７月１日
【発明の開示】
【発明が解決しようとする課題】
【００１２】
たとえば、１０万人の加入者が、平均保留時間３分で通信する場合を考える。このような条件を満たすためには、ＳＩＰプロキシサーバは、５０００呼分の能力が要求される。前述したように「SESSION-EXPIRES=200秒」とした場合に、リフレッシャとなる端末からは１００秒ごとにセッション確認が行われることになる。つまり、５０００呼接続中には、ＳＩＰプロキシサーバは、「５０００÷１００＝５０呼／秒」以上の処理能力（１つの呼あたり２０ミリ秒以内で実行する処理能力）が求められる。
【００１３】
しかしながら、「電話」という不特定多数を対象とするシステムにおいて、呼が２０ミリ秒の等間隔で発生し、その結果、セッション継続確認も２０ミリ秒の等間隔で実行されることは、ほとんど起こり得ない。不特定多数を対象とする場合の単一の呼あたりの許容処理時間を考える。
【００１４】
平均到着率（λ）＝１／０．０２０＝５０
プロキシサーバ数（ｓ）：１（台）
「応用待ち行列理論（日科技連出版社刊  森本英典／大前義次共著：）」の第２１９頁に開示された「無限呼源のときの平均待ち時間の図表」を参照すると、待ち合わせ許容時間（Ｗ）は、処理時間（Ｓ）とあわせて、２０ミリ秒以内となる。
【００１５】
待ち合わせ時間（Ｗ）＝１０（＝Ｓ）×１（＝Ｗ／Ｓ）＝１０であるため、処理時間（Ｓ）は、１０ミリ秒となる。つまり、単純計算では１つの呼あたり２０ミリ秒で処理すれば足りるものの、バースト性を加味すると、その２倍の処理能力を有するＳＩＰプロキシサーバを用意する必要がある。
【００１６】
このように、「電話」というシステムの性格上、ＳＩＰプロキシサーバへの発信・着信は不等間隔になることは避けられない。その一方、ＳＩＰプロキシサーバの処理量の不足により、いったん確立した多数の通話（呼）が、通話セッション継続確認の失敗により切断されることは許されないが、単に、ＳＩＰプロキシサーバの処理能力を上げることによる解決は、コストの上昇を招くという問題点がある。
【００１７】
本発明は、サーバの処理能力を高めることなく、適切にセッション監視を実現することができるセッション継続確認方法およびＳＩＰプロキシサーバを提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明においては、ＳＩＰプロキシサーバの処理量を平準化することにより、処理能力を増大する必要なく、通話セッションの継続性を適切に確認することができる。より詳細には、本発明の目的は、ＳＩＰに基づいて通信するＳＩＰユーザエージェント間のセッション継続確認方法であって、ＳＩＰプロキシサーバにおいて、セッション継続確認のためのＳＩＰメッセージを、前記ＳＩＰユーザエージェントに送信することを特徴とするセッション継続確認方法により達成される。
【００１９】
本発明によれば、ＳＩＰプロキシサーバ主導で、セッション継続確認のためのＳＩＰメッセージを、ＳＩＰユーザエージェントに送信する。したがって、呼が集中した場合であっても、ＳＩＰプロキシサーバは、自分自身の制御で、セッション継続確認のためのＳＩＰメッセージの送受信を実行することができる。
【００２０】
ある実施態様において、ＳＩＰに基づいて通信するＳＩＰユーザエージェント間のセッション継続確認方法は、ＳＩＰプロキシサーバにおいて、発信側のＳＩＰユーザエージェントに対して、リフレッシャを着信側のＳＩＰユーザエージェントに設定するＳＩＰメッセージを送信し、前記着信側のＳＩＰユーザエージェントに対して、リフレッシャを発信側のＳＩＰユーザエージェントに設定するＳＩＰメッセージを送信し、かつ、セッション継続確認のためのＳＩＰメッセージを、それぞれのＳＩＰユーザエージェントに送信する。
【００２１】
より好ましい実施態様においては、前記ＳＩＰプロキシサーバにおいて、前記リフレッシャを着信側のＳＩＰユーザエージェントに設定する情報を、INVITEのＳＩＰメッセージのヘッダ部に格納し、かつ、前記リフレッシャを発信側のＳＩＰユーザエージェントに設定する情報を、前記INVITEのＳＩＰメッセージの応答である、200OKのＳＩＰメッセージのヘッダ部に格納する。
【００２２】
また、別の好ましい実施態様においては、前記ＳＩＰプロキシサーバにおいて、発信側或いは着信側の何れか一方のＳＩＰユーザエージェントから、セッション継続確認のためのＳＩＰメッセージの応答を受信した後、他方のＳＩＰユーザエージェントに対して、セッション継続確認のためのＳＩＰメッセージを送信する。
【００２３】
より好ましい実施態様においては、前記ＳＩＰプロキシサーバにおいて、発信側或いは着信側の何れか一方のＳＩＰユーザエージェントに、セッション継続確認のためのＳＩＰメッセージを送信し、当該ＳＩＰユーザエージェントからの応答を受信しなかった場合に、他方のユーザエージェントに対して、セッション終了を示すＳＩＰメッセージを送信する。このセッション終了を示すＳＩＰメッセージは、いわゆる「BYE」に相当する。このように、「BYE」の送信も、ＳＩＰプロキシサーバが行うことによって、サーバのセッション継続確認の主導性をより強くすることが可能となる。
【００２４】
さらに好ましい実施態様においては、前記ＳＩＰプロキシサーバにおいて、セッションの単位でセッション継続確認のためのＳＩＰメッセージを送信するための時刻を含む情報を管理する管理テーブルを設け、所定のタイミングで、前記管理テーブルを参照して、セッション継続確認のためのＳＩＰメッセージを送信すべきセッションを特定し、当該セッションを構成するＳＩＰユーザエージェントに、前記ＳＩＰメッセージを送信する。
【００２５】
より好ましくは、さらに、前記管理テーブルを複数のブロックに分割し、前記所定のタイミングで、前記複数のブロックの何れかを選択し、選択されたブロック中、セッション継続確認のためのＳＩＰメッセージを送信すべきセッションを特定する。これにより、セッション継続確認の処理をより平準化することが可能となる。
【００２６】
前記セッション継続確認のためのＳＩＰメッセージは、UPDATEのセッションメッセージであっても良いし、re-INVITEのＳＩＰメッセージであっても良い。
【００２７】
また、本発明の目的は、ＳＩＰに基づいて通信するＳＩＰユーザエージェント間のセッション継続確認するＳＩＰプロキシサーバであって、発信側のＳＩＰユーザエージェントに対して、リフレッシャを着信側のＳＩＰユーザエージェントに設定するＳＩＰメッセージを送信するとともに、前記着信側のＳＩＰユーザエージェントに対して、リフレッシャを発信側のＳＩＰユーザエージェントに設定するＳＩＰメッセージを送信するリフレッシャ設定手段と、セッション継続確認のためのＳＩＰメッセージを、それぞれのＳＩＰユーザエージェントに送信するＳＩＰメッセージ送信手段とを備えたことを特徴とするＳＩＰプロキシサーバによっても達成される。
【００２８】
好ましい実施態様においては、前記リフレッシャ設定手段が、前記リフレッシャを着信側のＳＩＰユーザエージェントに設定する情報を、INVITEのＳＩＰメッセージのヘッダ部に格納し、かつ、前記リフレッシャを発信側のＳＩＰユーザエージェントに設定する情報を、前記INVITEのＳＩＰメッセージの応答である、200OKのＳＩＰメッセージのヘッダ部に格納する。
【００２９】
また、別の好ましい実施態様においては、前記ＳＩＰメッセージ送信手段が、発信側或いは着信側の何れか一方のＳＩＰユーザエージェントから、セッション継続確認のためのＳＩＰメッセージの応答を受信した後、他方のＳＩＰユーザエージェントに対して、セッション継続確認のためのＳＩＰメッセージを送信する。
【００３０】
より好ましい実施態様においては、前記ＳＩＰメッセージ送信手段が、発信側或いは着信側の何れか一方のＳＩＰユーザエージェントに、セッション継続確認のためのＳＩＰメッセージを送信し、当該ＳＩＰユーザエージェントからの応答を受信しなかった場合に、他方のユーザエージェントに対して、セッション終了を示すＳＩＰメッセージを送信する。
【００３１】
また、好ましい実施態様においては、さらに、セッションの単位でセッション継続確認のためのＳＩＰメッセージを送信するための時刻を含む情報を管理する管理テーブルを備え、前記ＳＩＰメッセージ送信手段が、所定のタイミングで、前記管理テーブルを参照して、セッション継続確認のためのＳＩＰメッセージを送信すべきセッションを特定し、当該セッションを構成するＳＩＰユーザエージェントに、前記ＳＩＰメッセージを送信する。
【００３２】
より好ましくは、さらに、前記管理テーブルが複数のブロックに分割され、前記ＳＩＰメッセージ送信手段が、前記所定のタイミングで、前記複数のブロックの何れかを選択し、選択されたブロック中、セッション継続確認のためのＳＩＰメッセージを送信すべきセッションを特定する。
【発明の効果】
【００３３】
本発明によれば、ＳＩＰプロキシサーバ主導でセッションの継続確認を行うことにより、その処理を平準化することができる。したがって、サーバの処理能力を高めることなく、適切にセッション監視を実現することができるセッション継続確認方法およびＳＩＰプロキシサーバを提供することが可能となる。
【発明を実施するための最良の形態】
【００３４】
以下、添付図面を参照して、本発明の実施の形態について説明する。図１は、本実施の形態にかかるＳＩＰプロキシサーバを含むシステム全体の構成を示すブロックダイヤグラムである。図１に示すように、端末１２、１４は、ＩＰネットワーク１６を介して、相互に音声データ通信することができる。これら端末１２、１４の間に、本実施の形態にかかるＳＩＰプロキシサーバ１０が介在する。端末１２、１４は、それぞれ、ＶｏＩＰ(Voice over IP)電話機であり、説明の便宜上、端末１２を発信者（ＵＡＣ：User Agent Caller）が利用し、端末１４を着信者（ＵＡＳ：User
Agent Server）が利用するものとし、それぞれを、発信者端末１２、着信者端末１４と称する。本実施の形態においても、通話セッション中の音声パケットを除く情報は、一方の端末からＳＩＰプロキシサーバ１０を介して他方の端末に伝達される。
【００３５】
図２は、本実施の形態にかかるＳＩＰプロキシサーバの構成を示すブロックダイヤグラムである。図２に示すように、ＳＩＰプロキシサーバ１０は、発信者端末および着信者端末との間の通話セッション確立の際に、後述する処理を実行するセッション確立処理部２２と、通話セッション中の発信者端末および着信者端末の情報を保持する呼状態管理テーブル２４と、呼状態管理テーブル２４を参照して、処理対象となる通話セッションを抽出する呼情報抽出部２６と、抽出された呼情報を処理対象として、セッション確認処理を実行するセッション確認処理部２８と、セッション確認処理の後、次回のセッション確認処理のために準備する次回準備処理部３０とを備えている。
【００３６】
また、ＳＩＰプロキシサーバ１０は、セッション確認情報を送信するセッション確認情報送信部３２、セッション終了情報（ＢＹＥ）を送信するセッション終了情報（ＢＹＥ）送信部３４、呼情報終了処理部３６、および、ＩＰネットワーク１６と接続された通信処理部３８を備えている。
【００３７】
図３（ａ）、（ｂ）は、呼状態管理テーブルのデータ構成を示す図である。図３（ｂ）に示すように、呼状態管理テーブル２４のレコードは、項目として、「呼情報」、「応答時刻」、「セッション確認起動元」、「次回セッション確認時刻」、「発信番号ＩＰアドレス」および「着信番号ＩＰアドレス」を含む。「セッション確認起動元」は、後述するように、リフレッシャとして「UPDATE」を送信するのが、ＳＩＰプロキシサーバ１０であるか着信者端末であるかを示す情報である。また、「次回セッション確認時刻」は、呼情報抽出部２６が、処理対象となるセッションを特定するために利用される。
【００３８】
図３（ａ）に示すように、呼状態管理テーブル２４は、Ｎ個のセグメントに分割され、単一のセッション継続確認処理においては、単一のセグメントのみが処理対象となるように構成されている。本実施の形態においては、例示的に、呼状態として５０００個のレコードが、１０分割（Ｎ＝１０）されている。
【００３９】
このように構成されたＳＩＰプロキシサーバ１０を介した発信者端末および着信者端末の音声データ送受信、並びに、ＳＩＰプロキシサーバ１０の処理について説明する。図４に示すように、発信者端末１２が「INVITE」を送信すると（ステップ４０１−１）、発信者端末１２と着信者端末１４との間に介在するＳＩＰプロキシサーバ１０は、発信者端末からの「INVITE」を受信すると、「INVITE」のヘッダに、リフレッシャが発信者であることを示す情報（「REF=UAC」）を付加して、着信者端末に送信する（ステップ４０１−２）。以下に、INVITEヘッダの部分の例を示す。ここでは、ヘッダ中に、「Refresher=uac」が付加されている。
【００４０】
Session Initiation Protocol
Request line: INVITE sip:82201@cbc1jt2.co.jp SIP/2.0
Method: INVITE
Message Header
From:402<sip:403@cbc1jt2.co.jp>;tag=d00c640a-13c4-3fd345270・・・
To:<sip:82201@cbc1jt1.co.jp>
Call ID:  ・・・
：
Supported: 100rel, replaces, timer
Contact: <sip:403@ 100.100.100.100 :10010>
Session-Expires: 200; Refresher=uac
：
また、この時点で、ＳＩＰプロキシサーバ１０は、呼状態管理テーブル２４に、新たなレコードを追加し、対応する値を格納する。
【００４１】
「INVITE」が着信者端末１４に送信されると、着信者端末１４は、ＳＩＰプロキシサーバ１０を介して、送信者端末１２に「180ringing」を返信する（ステップ４０２）。また、「INVITE」において、「REF=UAC」となっているため、後述する場合を除き、基本的には、「REF=UAC」として「200OK」を返信する（ステップ４０４−１）。ＳＩＰプロキシサーバ１０は、着信者端末１４からの「200OK」を受信すると、「REF=UAS」に変更して、「200OK」を発信者端末１２に送信する（ステップ４０４−２）。発信者端末１２は、「ACK」を、ＳＩＰプロキシサーバ１０を介して着信者端末１４に送信する。これにより、発信者端末１２と着信者端末１４との間の音声パケットによる通話セッションが開始される（ステップ４１０）。
【００４２】
上記ＳＩＰプロキシサーバ１０の処理により、発信者端末は、着信者端末がリフレッシャであると判断し、その一方、着信者端末は、発信者端末がリフレッシャであると判断する。
【００４３】
発信者端末から「ACK」が受信され、通話セッションが開始されてから、約「SESSION-EXPIRES/2」の時間が経過すると、ＳＩＰプロキシサーバ１０は、発信者端末１２に対して、UAS分の（つまり、UASから擬似的に送信されたと発信者端末が解する）「UPDATE」を送信する（ステップ４１１）。発信者端末１２からセッションが継続していることを示すために「200OK」が送信され、ＳＩＰプロキシサーバ１０に受信される（ステップ４１２）。
【００４４】
次いで、ＳＩＰプロキシサーバ１０は、着信者端末１４に対して、UAC分の（つまり、UACから擬似的に送信されたと着信者端末が解する）「UPDATE」を送信する（ステップ４１３）。着信者端末１４からセッションが継続されていることを示すために「200OK」が送信され、ＳＩＰプロキシサーバ１０に受信されると（ステップ４１４）、ＳＩＰプロキシサーバ１０は、後述するように、呼状態管理テーブル２４を更新する。その後、再度、約「SESSION-EXPIRES/2」の時間が経過すると、ＳＩＰプロキシサーバ１０は、発信者端末１２に対して、UAS分の「UPDATE」を送信する（ステップ４２１）。このような処理（ステップ４１１〜４１４）が繰り返される。
【００４５】
図５および図６を参照して、発信者端末や着信者端末からの「200OK」を受信しなかった場合のＳＩＰプロキシサーバ１０の処理について説明する。図５において、ステップ５０１−１〜５１０は、それぞれ、図４のステップ４０１−１〜４１０に相当する。
【００４６】
たとえば、発信者端末１２からの「ACK」がＳＩＰプロキシサーバ１０を介して着信者端末１４に送信されて、或いは、着信者端末１４からの「200OK」がＳＩＰプロキシサーバ１０を介して発信者端末１２に送信されてから所定の時間（約SESSION-EXPIRES/2）が経過すると、ＳＩＰプロキシサーバ１０は、発信者端末１２に対して、UAS分の「UPDATE」を送信する（ステップ５１１）。ここで、発信者端末１２から「200OK」が送られてこない場合には（符号５１２参照）、発信者端末１２からのセッションが途切れていると判断して、着信者端末１４に「BYE」を送信する（ステップ５１３）。着信者端末１４から「BYE」の受信に応答した「200OK」が返信されれば（ステップ５１４）、このセッションに関する処理は終了する。
【００４７】
図６においては、ステップ６０１−１〜６１２は、図４のステップ４０１−１〜４１２に相当する。発信者端末１２に対するUAS分の「UPDATE」の送信、および、発信者端末１２からの「200OK」の返信があると、ＳＩＰプロキシサーバ１０は、着信者端末１４に対して、UAC分の「UPDATE」を送信する（ステップ６１３）。着信者端末１４から「200OK」の返信がないと（符号６１４参照）、ＳＩＰプロキシサーバ１０は、着信者端末１４のセッションが途切れていると判断して、発信者端末１２に対して「BYE」を送信する（ステップ６１５）。着信者端末１２から「BYE」の受信に応答した「200OK」が返信されれば（ステップ６１６）、このセッションに関する処理は終了する。
【００４８】
図４〜図６に示すようなＳＩＰプロキシサーバ１０が主導するセッション管理を実現するための、ＳＩＰプロキシサーバ１０によるより具体的な処理について説明する。図７は、図４のステップ４０４−１に示すように着信者端末１４から、「INVITE」に対する「200OK」を受信した際に、ＳＩＰプロキシサーバ１０にて実行される処理を示すフローチャートである。
【００４９】
図７に示すように、ＳＩＰプロキシサーバ１０は着信者端末１４から「200OK」を受信すると（ステップ７０１）。「200OK」のヘッダ中、リフレッシャが「UAC」或いは「UAS」の何れになっているかを判断する（ステップ７０２）。本実施の形態においては、発信者端末からの「INVITE」を着信者端末に転送する際に、「REF=UAC」として、あたかも発信者端末が、セッション確認のための「UPDATE」を発信するように着信者端末に通知し、その一方、着信者端末からの「200OK」を発信者端末に転送する際に、「REF＝UAS」として、あたかも着信者端末が、セッション確認のための「UPDATE」を発信するように発信者端末に通知している。
【００５０】
しかしながら、端末によっては、自身が着信者端末になった場合に、自身がリフレッシャになるように設定されているものが存在する。これは、上記IETFドラフト（draft-ietf-session-timer-09）によれば、リフレッシャを何れかにするかについて、着信者端末に選択権が与えられていることによる。したがって、着信者端末によっては、ＳＩＰプロキシサーバ１０により「REF=UAC」というヘッダ部を含む「INVEITE」を送信したにもかかわらず、「REF=UAS」というヘッダ部を含む「200OK」を返す場合がある。そこで、受信した「200OK」のヘッダ部に含まれる「REF」が「UAS」であれば、後述するように、着信者端末がリフレッシャとなる従来のセッション確認を実行すべく処理の処理を実行する（ステップ７０６〜７０７）。
【００５１】
受信した「200OK」のヘッダ部に含まれる「REF」が「UAC」であれば、ＳＩＰプロキシサーバ１０のセッション確立処理部２２は、呼状態管理テーブル２４の該当レコード中、「セッション確認起動元」の値として「サーバ」を格納し（ステップ７０３）、かつ、「次回セッション確認時刻」の値として、「セッション確認時刻＋SESSION-EXPIRES/2」を格納する（ステップ７０４）。なお、ステップ７０４において、「セッション確認時刻」は、現在時刻に相当する。そして、「200OK」のヘッダ部に、リフレッシャが着信者であることを示す情報（「REF=UAS」）を設定する（ステップ７０５）。
【００５２】
また、「200OK」のヘッダ部に含まれる「REF」が「UAS」であれば、ＳＩＰプロキシサーバ１０のセッション確立処理部２２は、呼状態管理テーブル２４の該当レコード中、「セッション確認起動元」の値として「着信者端末」を格納し（ステップ７０６）、かつ、「次回セッション確認時刻」の値として、「セッション確認時刻＋SESSION-EXPIRES」を格納する（ステップ７０７）。なお、ステップ７０７において、「セッション確認時刻」は現在時刻に相当する。
【００５３】
次に、図８および図９を参照して、ＳＩＰプロキシサーバ１０によるセッション確認の処理について詳細に説明する。本実施の形態においては、最小SESSION-EXPIRESの５／１００の時間が経過すると（ステップ８０１）、呼情報抽出部２６が、呼状態管理テーブル２４中、処理対象となるブロックを抽出する（ステップ８０２）。図３（ａ）を参照して説明した表に、本実施の形態においては、呼状態管理テーブル２４は、Ｎ個（たとえば１０個）のブロックに分割されており、１回のセッション確認の処理においては、１つのブロックに含まれる呼状態が処理対象となる。
【００５４】
また、最小SESSION-EXPIRESは２００秒であれば、端末に対しては、SESSION-EXPIRESの１／２にあたる１００秒ごとにセッション継続確認を行い、これが最小間隔となる。本実施の形態では、「５／１００×２００＝１０秒」ごとに処理が起動される。この「最小SESSION-EXPIRESの５／１００」は、「最小SESSION-EXPIRESの５／（１０×Ｎ）（ただし、Ｎ：ブロック数）」を意味している。無論、処理周期は、上述したものに限定されるものではないが、本実施の形態において、上記処理周期を採用した理由について以下に述べる。
【００５５】
Ｎはセッション確認の処理量を平準化するための起動タイミングの数に相当する。理論的には、より大きい値を使用し、分割数を増やすことにより、呼状態管理テーブルから抽出されるレコード数の偏差を少なくするのが望ましい。実際には、呼状態管理テーブルのレコード数とプロキシサーバのタイマによる起動処理能力から決められる。
【００５６】
たとえば、１０万人の加入者が、平均保留時間３分で通信する場合を考える。このような条件を満たすためには、ＳＩＰプロキシサーバ１０は、５０００呼分の能力が要求される。前述したように「SESSION-EXPIRES=200秒」とした場合に、リフレッシャとなる端末からは１００秒ごとにセッション継続確認が行われることになる。つまり、５０００呼接続中には、ＳＩＰプロキシサーバ１０は、「５０００÷１００＝５０呼／秒」以上の処理能力（１つの呼あたり２０ミリ秒以内で実行する処理能力）が求められる。
【００５７】
そこで、本実施の形態では、呼状態管理テーブル２４のブロックに収容された５００呼の呼状態全てについて、単一のセッション確認処理において、各呼状態の処理を、「１０秒／５００＝２０ミリ秒」以内で実行できれば良い。つまり、２０ミリ秒以内で、各呼状態の処理を完了できれば、１つのブロックのセッション確認処理は、１０秒以内で終了する。そうすれば、次のブロックのセッション確認処理の起動も間に合わせることが可能となる。
【００５８】
次いで、呼情報抽出部２６は、抽出されたブロックにおいて、「次回セッション確認時刻」が、現在時刻を過ぎている呼状態のレコードを抽出する（ステップ８０３）。
【００５９】
セッション確認処理部２８は、ステップ８０３において抽出されたレコードの値を読み出し（ステップ８０４）、当該レコード中、「セッション確認起動元」の値がサーバであるか着信者端末であるかを判断する（ステップ８０５）。「セッション確認起動元」の値がサーバであれば、セッション確認処理部２８は、発信者セッション確認メッセージ、つまり、発信者端末１２宛の「UPDATE」を生成する（ステップ８０６）。この確認メッセージは、セッション確認送信部３２から通信処理部３８を経て、ＩＰネットワーク１６に送出される（ステップ８０７）。セッション確認送信部３２は、「UPDATE」に対する「200OK」が返信されなかった場合、再度「UPDATE」を送信する。再送信回数は、ＩＰネットワーク１６の信頼性などを考慮して決められる。ここでＩＰネットワーク１６に送出され、発信者端末１２に伝達される「UPDATE」は、図４のステップ４１１で送信されるものに相当する。
【００６０】
発信者端末１２から「200OK」が返信され、発信側セッションが「ＯＫ」であると判断されると（ステップ８０８参照）、セッション確認処理部２８は、図９に示すように、着信側セッション確認メッセージ、つまり、着信者端末１４宛の「UPDATE」を生成する（ステップ９０１）。この確認メッセージは、セッション確認送信部３２から通信処理部３８を経て、ＩＰネットワーク１６に送出される（ステップ９０２）。ここでネットワーク１６に送出され、着信者端末１４に伝達される「UPDATE」は、図４のステップ４１３で送信されるものに相当する。
【００６１】
着信者端末１４から「200OK」が返信され、着信側セッションが「ＯＫ」であると判断されると（ステップ９０３参照）、次回準備処理部３０は、呼状態管理テーブル２４の処理対象となったレコード中、「次回セッション確認時刻」の値として、「現在時刻＋SESSION-EXPIRES/2」を格納する（ステップ９０４）。その後、ブロックにおいて抽出された全てのレコードについて処理が終了したか否かが判断される（ステップ８１１）。ステップ８１１でノー(No)と判断されれば、ステップ８０４に戻り、当該ブロック中の次のレコードに関する処理が開始される。
【００６２】
図８のステップ８０８で発信側セッションが「NG」と判断された場合には、セッション終了（ＢＹＥ）送信部３４に、着信者端末１４に対して「BYE」を送信するように指示を与える（ステップ８０９）。セッション終了（ＢＹＥ）送信部３４は、通信処理部３８を介して、着信者端末１４に向けて、「BYE」を送信する。この着信者端末１４宛の「BYE」の送信は、図５のステップ５１３にて送信されているものに相当する。
【００６３】
また、図９のステップ９０３で着信側セッションが「NG」と判断された場合には、セッション終了（ＢＹＥ）送信部３４に、発信者端末１２に対して「BYE」を送信するように指示を与える（ステップ９０５）。セッション終了（ＢＹＥ）送信部３４は、通信処理部３８を介して、発信者端末１２に向けて、「BYE」を送信する。この発信者端末１２宛の「BYE」の送信は、図６のステップ６１５にて送信されているものに相当する。
【００６４】
端末に対する「BYE」送信の後、呼情報終了処理部３６は、処理対象となった呼に関するレコードを、呼状態管理テーブル２４から削除するなどのセッションの終了に必要な処理を実行する（ステップ８１０）。このとき、セッション確認が不成功であったことを「タイムアウト」として扱い、処理対象となった呼情報とともに記録することで、統計情報として活用することができる。
【００６５】
また、ステップ８０５において、レコード中の「セッション確認起動元」の値が「着信者端末」である場合にも、必要に応じて、セッション終了に必要な処理が実行される（ステップ８１０）。ここに、セッション確認起動元の値が「着信者端末」であるレコードにおいては、従来（つまり、端末主導でセッション確認が行われる場合）と同様に、「次回セッション確認時刻」は、「セッション確認時刻＋SESSION-EXPIRES」に設定されている。このように、従来と同様の設定の場合には、ＳＩＰプロキシサーバ１０は、従来と同様に、着信者端末からの「UPDATE」を受信し、かつ、発信者端末からの「200OK」を受信すると、呼状態管理テーブル２４から該当レコードを見出し、当該レコード中、「次回セッション確認時刻」の値を、「セッション確認時刻（つまり現在時刻）＋SESSION-EXPIRES」に書き換える。このような「次回セッション確認時刻」の更新をしておくことにより、従来どおり、着信者端末主導でセッション確認が行われる場合にも、セッション確認時刻から、「SESSION-EXPIRES」経過しても着信者端末から「UPDATE」が送られない場合には、セッションが終了していると判断することができる。
【００６６】
本実施の形態による効果について以下に述べる。先に述べたように、本実施の形態においては、セッション中の呼状態の種々の情報を記憶した呼状態管理テーブル２４のレコードを、Ｎ個のブロックに分けて、１回のセッション確認処理では、単一のブロックのレコード中、セッション確認が必要なものを抽出し、抽出されたレコードについて、「UPDATE」の送信など、セッション確認処理を実行している。したがって、所定の時間間隔で処理対象となるレコードのみを順次処理すればよく、ＳＩＰプロキシサーバ１０がバースト性を加味する必要が無い。たとえば、前述したように、呼が一時に集中した場合でも、本実施の形態では、集中した呼のセッション監視の処理を全ての呼に対して集中して実行するのではなく、分散して実行することが可能となる。
【００６７】
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【００６８】
たとえば、前記実施の形態においては、通話セッションの有効性を確認するために「UPDATE」を送信しているが、これに限定されるものではなく、「re-INVITE」が利用されてもよく、その場合にも、ＳＩＰプロキシサーバ主導で、発信者端末や着信者端末に「re-INVITE」を送信することができる。
【図面の簡単な説明】
【００６９】
【図１】図１は、本実施の形態にかかるＳＩＰプロキシサーバを含むシステム全体の構成を示すブロックダイヤグラムである。
【図２】図２は、本実施の形態にかかるＳＩＰプロキシサーバの構成を示すブロックダイヤグラムである。
【図３】図３（ａ）、（ｂ）は、本実施の形態にかかる呼状態管理テーブルのデータ構成を示す図である。
【図４】図４は、本実施の形態にかかるＳＩＰプロキシサーバを介した発信者端末および着信者端末のデータ送受信、並びに、ＳＩＰプロキシサーバの処理を示すフローチャートである。
【図５】図５は、本実施の形態にかかるＳＩＰプロキシサーバを介した発信者端末および着信者端末のデータ送受信、並びに、ＳＩＰプロキシサーバの処理を示すフローチャートである。
【図６】図６は、本実施の形態にかかるＳＩＰプロキシサーバを介した発信者端末および着信者端末のデータ送受信、並びに、ＳＩＰプロキシサーバの処理を示すフローチャートである。
【図７】図７は、図４のステップ４０４−１に示すように着信者端末から、「INVITE」に対する「200OK」を受信した際に、ＳＩＰプロキシサーバにて実行される処理を示すフローチャートである。
【図８】図８は、本実施の形態にかかるＳＩＰプロキシサーバによるセッション確認の処理を寄り詳細に示すフローチャートである。
【図９】図９は、本実施の形態にかかるＳＩＰプロキシサーバによるセッション確認の処理を寄り詳細に示すフローチャートである。
【図１０】図１０は、従来のセッション確認の際に実行される処理を示すフローチャートである。
【図１１】図１１は、従来のセッション確認の際に実行される処理を示すフローチャートである。
【図１２】図１２は、従来のセッション確認の際に実行される処理を示すフローチャートである。
【符号の説明】
【００７０】
１０      ＳＩＰプロキシサーバ
１２      発信者端末
１４      着信者端末
１６      ＩＰネットワーク
２２      セッション確立処理部
２４      呼状態管理テーブル
２６      呼情報抽出部
２８      セッション確認処理部
３０      次回準備処理部
３２      セッション確認送信部
３４      セッション終了（ＢＹＥ）送信部
３６      呼情報終了処理部
３８      通信処理部
【図１】
2005327101.tif 000003
【図２】
2005327101.tif 000004
【図３】
2005327101.tif 000005
【図４】
2005327101.tif 000006
【図５】
2005327101.tif 000007
【図６】
2005327101.tif 000008
【図７】
2005327101.tif 000009
【図８】
2005327101.tif 000010
【図９】
2005327101.tif 000011
【図１０】
2005327101.tif 000012
【図１１】
2005327101.tif 000013
【図１２】
2005327101.tif 000014