JP2014207709A - 端末 - Google Patents

Abstract

【課題】３ＰＣＣサービスでは、通信する２者（第１接続端末と第２接続端末）が通信開始元（発信元）の接続端末を特定できないという課題がある。【解決手段】Ｗｅｂサーバに、第１通信端末及び第２通信端末の端末情報を格納する第１メモリと、その少なくともいずれかの発信履歴情報を格納する第２メモリと、その少なくともいずれかの着信履歴情報を格納する第３メモリと、その少なくともいずれかと通信装置との接続設定のとき、通信装置からの通知に含まれる情報に基づいて、第１メモリから情報を読み出し、第２メモリ及び第３メモリの少なくともいずれかの情報を制御する処理部とを備える。【選択図】図１

Description

本発明は、次世代ネットワークにおける対拠点間接続方式についての端末に関する。

近年、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）技術を利用した通信事業者による次世代の通信網に関する検討が盛んに行われている。この種の次世代通信網をＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）と呼んでいる。ＮＧＮでは、通信をしようとするサーバとクライアントの間にセッションを確立し、そのセッション毎に帯域を管理する方法が採られることが多い。また、ＮＧＮにて、帯域の確保に用いられるセッション制御プロトコルは例えばＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）がある。

また、帯域確保用セッションの制御プロトコルを実装しないクライアント装置が帯域保障型網で通信するとき、セッション代行装置がクライアント装置に代わって帯域保障型網内に帯域確保用セッションを確立する技術が開示されている（例えば、特許文献１）。

また、アプリケーション間で情報交換を行うためのＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）が知られている。

また、通信品質が保証されたＮＧＮにおいて、通信させる２者間のデータを転送する技術が開示されている（例えば、特許文献２）。

特開２００８−７８８７８号公報 特開２０１０−２１３０２７号公報

ＮＧＮにおいては、シグナリングチャネルとデータチャネルを確立するＩＰアドレスが同一であることが必要である。そのため、従来の３ＰＣＣ（３ｒｄ Ｐａｒｔｙ Ｃａｌｌ Ｃｏｎｔｒｏｌ）サービスフローのように通信させる２者間（第１接続端末と第２接続端末間）のデータチャネルの確立代行が不可能となる。また、３ＰＣＣサービスフローにおいて、まず３ＰＣＣを実装する装置と第１接続端末とのセッションを確立し、次に３ＰＣＣを実装する装置と第２接続端末とのセッションを確立して、第１接続端末と第２接続端末間で通話する場合、第１接続端末とのセッションの確立が完了し、第２接続端末とのセッションの確立を開始する。ここで、３ＰＣＣサービスでは、通信する２者（第１接続端末と第２接続端末）とは違う第三者がその２者に対し発呼をするため、第１接続端末または第２接続端末が不在着信をするときに、通知される電話番号は通信開始元（発信元）の接続端末の情報ではなく第三者の情報となる。そのため、第１接続端末または第２接続端末が通信開始元（発信元）の接続端末を特定することができず、例えば折返しの電話もできないという課題がある。

上述の課題を解決するために、本発明に係る端末は、複数の通信端末とセッション接続処理をする通信装置と通信する接続装置と、ネットワークを介して接続され、前記接続装置にユーザ識別子を用いてログインし、前記通信端末を所有するユーザのユーザ識別子と対応づけて、呼の着信が前記接続装置により管理される着信履歴情報のうち、前記ログインに用いたユーザ識別子に対応する着信履歴情報を参照することを特徴とする。

また、本発明に係る端末は、前記通信装置において、前記接続装置から前記通信端末間の接続要求が受信されると、通信端末間のセッションを確立するセッション接続処理がなされ、前記接続装置において、発信先となる通信端末における呼の着信が、前記発信先の通信端末を所有するユーザのユーザ識別子と対応づけて着信履歴情報として管理されてもよい。そして、本発明に係る端末は、前記接続装置において前記発信先の通信端末から前記通信装置へ送信された接続成功通知に基づく接続応答通知が前記通信装置から受信されると、前記接続応答通知に基づいて前記発信先の通信端末に対応するユーザ識別子の着信履歴に含まれる不在着信情報が着信状態とされる前記着信履歴情報を参照してもよい。

３ＰＣＣサービスにおいて、通信開始元（発信元）の接続端末を特定することができる。また、接続端末のユーザごとに発着信履歴情報を管理する場合には、特定の接続端末以外からも各ユーザに対応した発着信履歴情報を抽出することができる。

第１の実施の形態の通信網の構成例を示す説明図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２の構成例を示す説明図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２におけるセッション情報テーブル２０１０の構成の一例を示す説明図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼参加者情報テーブル２０２０の構成の一例を示す説明図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における端末情報テーブル２０３０の構成の一例を示す説明図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２におけるメディアストリーム制御情報テーブル２０４０の構成の一例を示す説明図である。 ｗｅｂサーバ１の構成図である。 第１の実施の形態のｗｅｂサーバ１における端末情報テーブル２４００の構成の一例を示す説明図である。 第１の実施の形態のｗｅｂサーバ１における電話帳テーブル２４１０の構成の一例を示す説明図である。 第１の実施の形態のｗｅｂサーバ１における発信履歴情報テーブル２４２０の構成の一例を示す説明図である。 第１の実施の形態のｗｅｂサーバ１における着信履歴情報テーブル２４３０の構成の一例を示す説明図である。 ３ＰＣＣサービスにおける発着信履歴情報の作成手順を説明するシーケンス図である。 ＳＯＡＰ−ＳＩＰアダプタにおけるｓｅｓｓｉｏｎＩＤ／ｃｏｎｎｅｃｔｉｏｎＩＤ生成を説明するフローチャートである。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼開始要求受信時の動作を説明するフローチャートである。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼情報（セッション情報）要求受信時の動作を説明するフローチャートである。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼参加者情報要求受信時の動作を説明するフローチャートである。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼終了要求受信時の動作を説明するフローチャートである。 第１の実施の形態のメディアストリーム転送を説明するシーケンス図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼情報（セッション情報）要求受信の手順を説明するシーケンス図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼参加者情報要求受信時の手順を説明するシーケンス図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼終了要求受信時の手順を説明するシーケンス図である。 ｗｅｂサーバ１における発信履歴作成の動作を説明するフローチャートである。 ｗｅｂサーバ１における着信履歴作成の動作を説明するフローチャートである。 ｗｅｂサーバ１における着信履歴作成の動作を説明するフローチャートである。 ｗｅｂサーバ１により、電話帳、発信履歴、着信履歴の各々のデータを参照させる動作を説明するフローチャートである。 電話帳データ表示の例である。 発信履歴データ表示の例である。 着信履歴データ表示の例である。

（ネットワーク構成）
図１は、第１の実施の形態の通信網の構成例を示す説明図である。

本通信網（システム）は、Ｗｅｂサーバ１と、ＳＯＡＰ−ＳＩＰアダプタ（通信装置）２と、ＳＩＰサーバ３と、ＨＧＷ（Ｈｏｍｅ Ｇａｔｅｗａｙ）４ａ及び４ｂとを備える。ＳＩＰサーバ３は、例えばＮＧＮ Ｎ２に設置される。

Ｗｅｂサーバ１は、ＳＯＡＰ−ＳＩＰアダプタ２と通信する。また、Ｗｅｂサーバ１は、インターネットＮ１等のネットワークを介して端末５ａと通信する。さらに、Ｗｅｂサーバ１は、ＮＧＮ Ｎ２とＨＧＷ４ａを介し、かつ、インターネットＮ１等のネットワークを介して端末Ａ５ｂと、ＮＧＮ Ｎ２とＨＧＷ４ｂを介し、かつ、インターネットＮ１等のネットワークを介して端末Ａ５ｃと、各々通信する。ＳＯＡＰ−ＳＩＰアダプタ２は、ＮＧＮ Ｎ２とＨＧＷ４ａを介して端末Ａ５ｂと通信する。ＳＯＡＰ−ＳＩＰアダプタ２と端末Ｂ５ｃについても同様である。

図２は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２の構成例を示す説明図である。

ＳＯＡＰ−ＳＩＰアダプタ２は、例えば、プロセッサ（以下、ＣＰＵ）２００１と、インタフェース（以下、ＩＦ）２００３ａ及び２００３ｂと、メモリ２００４とを備える。メモリ２００４は、ＳＯＡＰ制御部２１０１と、３ＰＣＣモジュール部２１０２と、メディアストリーム制御部２１０３と、ＳＩＰ制御部２１０４とを有する。３ＰＣＣモジュール部２１０２は、セッション情報テーブル２０１０を有し、メディアストリーム制御部２１０３は、メディアストリーム制御情報テーブル２０４０を有する。セッション情報テーブル２０１０は、呼参加者情報テーブル２０２０と、端末情報テーブル２０３０とを有する。

ＣＰＵ２００１は、ＳＯＡＰ−ＳＩＰアダプタ２における各処理を実行する。メモリ２００４上のＳＯＡＰ制御部２１０１、３ＰＣＣモジュール部２１０２、メディアストリーム制御部２１０３及びＳＩＰ制御部２１０４は、ＣＰＵ２００１により実行される。ＩＦ２００３は、回線２００２を介してＷｅｂサーバ１やＮＧＮ Ｎ２と通信するためのインタフェースである。

図３−１は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２におけるセッション情報テーブル２０１０の構成の一例を示す説明図である。

セッション情報テーブル２０１０は、例えば、ｓｅｓｓｉｏｎＩＤ２０１１に対応して、セッション状態２０１２と、呼参加者状態２０２０と、端末情報２０３０とを記憶する。

ｓｅｓｓｉｏｎＩＤ２０１１は、Ｗｅｂサーバ１からの接続要求に対応するセッション識別子である。ｓｅｓｓｉｏｎＩＤ２０１１は、端末Ａ５ｂと端末Ｂ５ｃとの通信を識別する。セッション状態２０１２は、ｓｅｓｓｉｏｎＩＤ２０１１が示すセッションの状態を示す。セッション状態２０１２は、例えば、「Ｉｎｉｔｉａｌ（初期状態）」、「Ｃｏｎｎｅｃｔｅｄ（接続状態）」、「Ｔｅｒｍｉｎａｔｅｄ（終了状態）」等が記憶される。呼参加者状態２０２０は、呼参加者情報テーブル２０２０に相当する。呼参加者情報テーブル２０２０の詳細については、後述する。端末情報２０３０は、端末情報テーブル２０３０に相当する。端末情報２０３０は、端末毎にそれぞれ記憶される。図示の例では、端末Ａ５ｂに対応する端末情報（Ｃｌｉｅｎｔ Ａ用）２０３０＿Ａと、端末Ｂ５ｃに対応する端末情報（Ｃｌｉｅｎｔ Ｂ用）２０３０＿Ｂとが記憶される。端末情報テーブル２０３０の詳細については、後述する。

図３−２は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼参加者情報テーブル２０２０の構成の一例を示す説明図である。

呼参加者情報テーブル２０２０は、例えば、端末毎に、ＵＲＩ２０２１と呼状態２０２２と開始時間（時刻）２０２３とを記憶する。

ＵＲＩ２０２１は、各ユーザに対応するＳＩＰ−ＵＲＩを示す。呼状態２０２２は、ＳＯＡＰ−ＳＩＰアダプタ２と各端末５ｂ、５ｃとの間のＳＩＰのセッションの状態を示す。呼状態２０２２は、例えば、「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＩｎｉｔｉａｌ（初期状態）」、「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＣｏｎｎｅｃｔｅｄ（接続状態）」、「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＴｅｒｍｉｎａｔｅｄ（終了状態）」等が記憶される。開始時間２０２３は、ＳＯＡＰ−ＳＩＰアダプタ２が各端末５ｂ、５ｃに対して、ＳＩＰのセッションを確立したときの時刻を示す。

図３−３は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における端末情報テーブル２０３０の構成の一例を示す説明図である。

端末情報テーブル２０３０は、例えば、ＳＩＰで用いるパラメータ等が記憶される。端末情報テーブル２０３０は、例えば、ハンドル値２０３１と、ｓｅｓｓｉｏｎＩＤ２０３２と、端末状態２０３３と、Ｒｏｌｅ２０３４と、ｓｅｎｄ ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）情報２０３５と、ｒｅｃｖ ＳＤＰ情報２０３６と、Ｆｒｏｍ ＵＲＩ２０３７と、Ｔｏ ＵＲＩ２０３８とを記憶する。

ハンドル値２０３１は、ＳＯＡＰ−ＳＩＰアダプタ２と端末５ｂとの間のＳＩＰのセッション、及び、ＳＯＡＰ−ＳＩＰアダプタ２と端末Ｂ５ｃとの間のＳＩＰのセッションをそれぞれ識別する情報である。ｓｅｓｓｉｏｎＩＤ２０３２は、上述のセッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１に対応する。端末状態２０３３は、ＳＯＡＰ−ＳＩＰアダプタ２と各端末５ｂ、５ｃとのセッション確立に至るまでの状態を示す。端末状態２０３３は、例えば、「Ｉｎｉｔｉａｌ（初期状態）」、「ＣｏｎｎｅｃｔＷａｉｔ（「応答」を待っている状態）」、「ＣａｌｌＣｏｍｐｌｅｔｅ（「応答」を受け付け、ＵＡとのセッションが確立している状態）」、「ＣｌｏｓｅＷａｉｔ（「切断完了通知」を待っている状態）」、「Ｃｌｏｓｅｄ（終了状態）」等が記憶される。なお、「Ｉｎｉｔｉａｌ」、「ＣｏｎｎｅｃｔＷａｉｔ」は、呼参加者情報テーブル２０２０に記憶される呼状態２０２２の「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＩｎｉｔｉａｌ」に対応する。また、「ＣａｌｌＣｏｍｐｌｅｔｅ」、「ＣｌｏｓｅＷａｉｔ」は、呼参加者情報テーブル２０２０に記憶される呼状態２０２２の「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＣｏｎｎｅｃｔｅｄ」に対応する。「ＣｌｏｓｅＷａｉｔ」は、呼状態２０２２の「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＴｅｒｍｉｎａｔｅｄ」に対応する。

Ｒｏｌｅ２０３４は、発信側又は着信側を示す情報である。ｓｅｎｄ ＳＤＰ情報２０３５は、例えば、ＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を含む。ｒｅｃｖ ＳＤＰ情報２０３６は、例えば、端末Ａ５ｂ又は端末Ｂ５ｃのＩＰアドレスとポート番号を含む。Ｆｒｏｍ ＵＲＩ２０３７は、ＳＯＡＰ−ＳＩＰアダプタ２が送信するＳＩＰメッセージの送信元ＵＲＩを示す。Ｆｒｏｍ ＵＲＩ２０３７は、例えばＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ−ＵＲＩである。Ｔｏ ＵＲＩ２０３８は、ＳＯＡＰ−ＳＩＰアダプタ２が送信するＳＩＰメッセージの送信先ＵＲＩを示す。Ｔｏ ＵＲＩ２０３８は、例えば、端末Ａ５ｂ又は端末Ｂ５ｃのＳＩＰ−ＵＲＩである。

図３−４は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２におけるメディアストリーム制御情報テーブル２０４０の構成の一例を示す説明図である。

メディアストリーム制御情報テーブル２０４０は、例えば、ｓｅｓｓｉｏｎＩＤ２０４１に対応して、メディアストリーム送受信用ＩＰアドレス２０４２と、メディアストリーム送受信用ポート番号２０４３と、相手先ＩＰアドレス（１）２０４４と、相手先ポート番号（１）２０４５と、相手先ＩＰアドレス（２）２０４６と、相手先ポート番号（２）２０４７とを記憶する。

ｓｅｓｓｉｏｎＩＤ２０４１は、セッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１と対応する。メディアストリーム送受信用ＩＰアドレス２０４２及びメディアストリーム送受信用ポート番号２０４３は、ＳＯＡＰ−ＳＩＰアダプタ２がメディアストリームを転送する際に用いるＩＦ２００３のＩＰアドレス及びポート番号である。相手先ＩＰアドレス（１）２０４４及び相手先ポート番号（１）２０４５と、相手先ＩＰアドレス（２）２０４６及び相手先ポート番号（２）２０４７の対は、メディアストリームの転送先を示す。例えば、メディアストリームの送信元が相手先ＩＰアドレス（１）２０４４及び相手先ポート番号（１）２０４５に該当する場合、対応する相手先ＩＰアドレス（２）２０４６及び相手先ポート番号（２）２０４７を転送先としてメディアストリームを転送する。メディアストリームの送信元が相手先ＩＰアドレス（２）２０４６及び相手先ポート番号（２）２０４７の場合も同様に、対応する相手先ＩＰアドレス（１）２０４４及び相手先ポート番号（１）２０４５を転送先としてメディアストリームを転送する。図示の例では、相手先ＩＰアドレス（１）２０４４及び相手先ポート番号（１）２０４５は、端末Ａ５ｂのＩＰアドレス及びポート番号を示し、相手先ＩＰアドレス（２）２０４６及び相手先ポート番号（２）２０４７は、端末Ｂ５ｃのＩＰアドレス及びポート番号を示す。

図４は、ｗｅｂサーバ１の構成図である。

ｗｅｂサーバ１は、例えば、処理部１００と、入力部１１０と、表示部１２０と、記憶部１３０と、通信インタフェース１４０を備える。入力部１１０は、例えば、ＳｅｓｓｉｏｎＩＤの入力やユーザ識別子の入力を受け付ける。表示部１２０は、ユーザ識別子、ＳＩＰ−ＵＲＩを表示する。記憶部１３０は、端末情報テーブル（メモリ）２４００と、電話帳テーブル（メモリ）２４１０と、発信履歴情報テーブル（メモリ）２４２０と、着信履歴情報テーブル（メモリ）２４３０を有する。通信インタフェース１４０は、例えばＳＯＡＰ−ＳＩＰアダプタ２と通信するためのインタフェースである。処理部１００は、ｗｅｂサーバ１での各種処理を実行する。後述する端末情報テーブル２４００と、電話帳テーブル２４１０と、発信履歴情報テーブル２４２０の制御（読み出し、情報の格納、更新などの制御）は、処理部が行う。

図５−１は、第１の実施の形態のｗｅｂサーバ１における端末情報テーブル２４００の構成の一例を示す説明図である。端末情報テーブル２４００は、少なくともユーザＩＤと端末ＩＤと電話番号とを対応させ、個々の端末に関する情報を格納するものである。なお、テーブルに記憶する情報は下記する全ての組合せでも良いが、必要とする任意の情報の組合せであっても良い。

例えば、ユーザＩＤ２４０１に対応して、端末ＩＤ２４０２と、端末名称２４０３と、電話番号２４０４と、ｃｏｒｒｅｌａｔｏｒ２４０５と、端末登録状態２４０６とを記憶する。

ユーザＩＤ２４０１は、３ＰＣＣサービスを利用するユーザに対する識別子である。端末ＩＤ２４０２は、あるユーザが所有する通信端末に対する識別子である。ここで、一のユーザＩＤは複数の端末（複数の端末ＩＤ）と対応してもよい。図５-１では、ユーザＩＤ0001に対し、「固定端末」の端末ＩＤ０１と「携帯端末」の端末ＩＤ０２とが対応する。端末名称２４０３は、通信端末に対する名称である。電話番号２４０４は、ユーザ所有の通信端末の端末ＩＤに対応する電話番号を示す。ｃｏｒｒｅｌａｔｏｒ２４０５は、ＳＯＡＰ−ＳＩＰアダプタ２からのイベント通知における関連性を示す識別子である。イベント通知とは、ＳＯＡＰ−ＳＩＰアダプタ２による呼設定における通知であり、このイベント通知との関連性とは、イベント通知への対応要否を決めるパラメータである。端末登録状態２４０６は、ＳＯＡＰ−ＳＩＰアダプタ２へイベント通知対象として登録済みであるかの状態を示す。

図５−２は、第１の実施の形態のｗｅｂサーバ１における電話帳テーブル２４１０の構成の一例を示す説明図である。電話帳テーブル２４１０は、少なくともユーザＩＤと接続先指定アドレス（例えばＳＩＰ−ＵＲＩ）と表示アドレス（例えば電話番号）とを対応させ、個々のユーザに関する情報を格納するものである。ここでのユーザＩＤとは、名前２４１３に括りついたものではなく、名前２４１３、ふりがな２４１４、アドレス２４１５、表示アドレス２４１６の情報を電話帳に保持しているユーザのユーザＩＤのことである。

例えば、ＩＤ２４１１に対応して、ユーザＩＤ２４１２と、名前２４１３と、ふりがな２４１４と、アドレス２４１５と、表示アドレス２４１６とを記憶する。

ＩＤ２４１１は、データ管理のための識別子である。ユーザＩＤ２４１２は、上述の端末情報テーブル２４００のユーザＩＤ２４０１に対応する。名前２４１３は、３ＰＣＣサービスを利用するユーザの名前であり、ユーザＩＤ２４１２に１対１に対応する情報である。ふりがな２４１４は、名前２４１３に１対１に対応する情報であり、電話帳表示の際のソートで使用することができる。アドレス２４１５は、各ユーザのＳＩＰ−ＵＲＩを示す。表示アドレスは、アドレス２４１５のうち、電話帳を参照する端末へ表示させる情報、例えば、電話番号である。

図５−３は、第１の実施の形態のｗｅｂサーバ１における発信履歴情報テーブル２４２０の構成の一例を示す説明図である。発信履歴情報テーブル２４２０は、少なくともユーザＩＤとセッションＩＤと発信先情報と発信元情報と発信時間情報とを対応させ、個々の呼（Ｃａｌｌｉｎｇ）の発信に関する情報を格納するものである。なお、テーブルに記憶する情報は下記する全ての組合せでも良いが、必要とする任意の情報の組合せであっても良い。

例えば、ＩＤ２４２１に対応して、ユーザＩＤ２４２２と、セッションＩＤ２４２３と、発信先アドレス２４２４と、発信先アドレス表示名２４２５と、発信先名２４２６と、発信元アドレス２４２７と、発信日時２４２８とを記憶する。

ＩＤ２４２１は、データ管理のための識別子である。ユーザＩＤ２４２２は、上述の端末情報テーブル２４００のユーザＩＤ２４０１に対応する。セッションＩＤ２４２３は、上述のセッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１に対応する。発信先アドレス２４２４は、着信側となる端末、例えば、端末Ｂ５ｃのＳＩＰ−ＵＲＩである。発信先アドレス表示名２４２５は、発信先アドレス２４２４のうち、発信履歴を参照する端末へ表示させる情報、例えば、電話番号である。発信先名２４２６は、上述の電話帳テーブル２４１０の名前２４１３に対応する。発信元アドレス２４２７は、発信側となる端末、例えば、端末Ａ５ｂのＳＩＰ−ＵＲＩである。発信日時２４２８は、電話を発信した時間情報である。

図５−４は、第１の実施の形態のｗｅｂサーバ１における着信履歴情報テーブル２４３０の構成の一例を示す説明図である。着信履歴情報テーブル２４３０は、少なくともユーザＩＤとセッションＩＤと発信元情報と着信時間情報とを対応させ、個々の呼の（Ｃａｌｌｉｎｇ）の着信に関する情報を格納するものである。なお、テーブルに記憶する情報は下記する全ての組合せでも良いが、必要とする任意の情報の組合せであっても良い。

例えば、ＩＤ２４３１に対応して、ユーザＩＤ２４３２と、セッションＩＤ２４３３と、発信元アドレス２４３４と、発信元アドレス表示名２４３５と、発信元名２４３６と、不在着信２４３７と、着信日時２４３８とを記憶する。

ＩＤ２４３１は、データ管理のための識別子である。ユーザＩＤ２４３２は、上述の端末情報テーブル２４００のユーザＩＤ２４０１に対応する。セッションＩＤ２４３３は、上述のセッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１に対応する。発信元アドレス２４３４は、発信側となる端末、例えば、端末Ａ５ｂのＳＩＰ−ＵＲＩである。発信元アドレス表示名２４３５は、発信元アドレス２４３４のうち、着信履歴を参照する端末へ表示させる情報、例えば、電話番号である。発信元名２４３６は、上述の電話帳テーブル２４１０の名前２４１３に対応する。不在着信２４３７は、発呼時における、相手端末の着信への応答の状態を示す。着信日時２４３８は、電話を着信した時間情報である。
（動作）
図７は、ＳＯＡＰ−ＳＩＰアダプタにおけるｓｅｓｓｉｏｎＩＤ／ｃｏｎｎｅｃｔｉｏｎＩＤ生成を説明するフローチャートである。なお、ｃｏｎｎｅｃｔｉｏｎＩＤは、接続を３ＰＣＣではなくＮＧＮ接続とするときに使用できるパラーメータである。図８は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼開始要求受信時の動作を説明するフローチャートである。また、図６は、３ＰＣＣサービスにおける発着信履歴情報の作成手順を説明するシーケンス図である。図１６は、ｗｅｂサーバ１における発信履歴作成の動作を説明するフローチャートである。図１７、図１８は、ｗｅｂサーバ１における着信履歴作成の動作を説明するフローチャートである。

本実施の形態によると、３ＰＣＣサービスにおいて、通信開始元（発信元）の接続端末を特定することができる。また、接続端末のユーザごとに発着信履歴情報を管理する場合には、特定の接続端末以外からも各ユーザに対応した発着信履歴情報を抽出することができる。さらには、ｗｅｂ管理の電話帳を提供することも可能となる。

発着信履歴情報の作成を含む３ＰＣＣサービスまでの流れは、以下の（ａ）〜（ｅ）となる。（ａ）ｗｅｂサーバ１からＳＯＡＰ−ＳＩＰアダプタ２へ発着信履歴作成対象ユーザのＳＩＰ−ＵＲＩなどを登録。（ｂ）ＳＯＡＰ−ＳＩＰアダプタ２と第１接続端末Ａ５ｂとのセッション確立。（ｃ）ｗｅｂサーバ１にて第１接続端末Ａ５ｂの発信履歴情報を作成。（ｄ）ＳＯＡＰ−ＳＩＰアダプタ２と第２接続端末Ｂ５ｃとのセッション確立。（ｅ）ｗｅｂサーバ１にて第２接続端末Ｂ５ｃの着信履歴情報を作成。（ｆ）第１接続端末Ａ５ｂと第２接続端末Ｂ５ｃ間で通話。しかし、（ｂ）が完了し、（ｄ）を開始している段階で、第１接続端末Ａ５ｂでは無音状態となる。この点については、ＳＯＡＰ−ＳＩＰアダプタ２から擬似的にＲＢＴ（Ｒｉｎｇｉｎｇ Ｂａｃｋ Ｔｏｎｅ、接続維持メッセージ）を第１接続端末Ａ５ｂへ送信する。

また、ＮＧＮにおいては、シグナリングチャネルとデータチャネルを確立するＩＰアドレスが同一である必要が条件としてあり、従来の３ＰＣＣサービスフローのように通信させる２者間（第１接続端末Ａ５ｂと第２接続端末Ｂ５ｃ間）のデータチャネル確立代行が不可能である。この点については、本実施の形態では、第１接続端末Ａ５ｂからのデータをＳＯＡＰ−ＳＩＰアダプタ２で受信し、そのデータを第２接続端末Ｂ５ｃへ転送する。第２接続端末Ｂ５ｃからのデータをＳＯＡＰ−ＳＩＰアダプタ２で受信し、そのデータを第１接続端末Ａ５ｂへ転送する。また、ＳＯＡＰ−ＳＩＰアダプタ２は、上述の転送を実現するためのメディアストリーム制御情報テーブル２０４０を作成する。

さらに、３ＰＣＣサービスにおいては、通信する２者（第１接続端末Ａ５ｂと第２接続端末Ｂ５ｃ）とは違う第三者であるＳＯＡＰ−ＳＩＰアダプタ２がその２者に対し発呼をするため、第１接続端末Ａ５ｂまたは第２接続端末Ｂ５ｃが不在着信をするときに、通知される電話番号がＳＯＡＰ−ＳＩＰアダプタ２の情報となる。そのため、第１接続端末または第２接続端末が通信開始元（発信元）の接続端末を特定することができず、折返しの電話をすることが不可能となる課題がある。そこで、本実施の形態では、ｗｅｂサーバ１上で、３ＰＣＣサービスにおける発着信履歴情報を作成し、ｗｅｂサーバ１と通信可能な端末に、通信のために必要となるユーザ情報（ログインＩＤなど）に対応した発着信履歴情報を提供する。

以下、シーケンス図及び各フローチャートに従って本実施の形態の手順を説明する。

図６に沿ってシーケンスフローを説明する。まず、ｗｅｂサーバ１の管理者は、ｗｅｂサーバ１へログインする。３ＰＣＣサービスを利用するユーザなどの情報を入力し、端末情報テーブル２４００に登録する。例えば、登録内容には、ユーザＩＤ２４０１、複数の端末を識別する端末ＩＤ２４０２、端末名称２４０３、電話番号２４０４、ｃｏｒｒｅｌａｔｏｒ２４０５を含む。次に、ｗｅｂサーバ１は、ＳＯＡＰ ｓｔａｒｔＣａｌｌＮｏｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔ（通知開始要求）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１６）。ＳＯＡＰ ｓｔａｒｔＣａｌｌＮｏｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔは、接続状態の通知の要求対象のユーザに対応するＳＩＰ−ＵＲＩ、関連性を示すための値ｃｏｒｒｅｌａｔｏｒを含む。ＳＯＡＰ−ＳＩＰアダプタ２は、受信したＳＯＡＰ ｓｔａｒｔＣａｌlＮｏｔｉｆｉｃａｔｉｏｎＲｅｓｐｏｎｓｅ（通知開始応答）を送信する（Ｓ１７）。ｗｅｂサーバ１は、ＳＯＡＰ ｓｔａｒｔＣａｌlＮｏｔｉｆｉｃａｔｉｏｎＲｅｓｐｏｎｓｅ（通知開始応答）受信契機に、端末情報テーブル２４００の端末登録状態２４０６を“未”から“済”へ更新する（初期値は、“未”である）。次に、第三者のユーザ、または、ｗｅｂサーバ１の管理者は、端末５ａを操作してＷｅｂサーバ１にログインする。Ｗｅｂサーバ１は、通信するユーザのユーザ識別子（ユーザＩＤ）（例えば、端末Ａ５ｂ、端末Ｂ５ｃの各々について、使用するユーザに対応するユーザＩＤ）を端末５ａより入力する。例えば、Ｗｅｂサーバ１が、ログインした端末５ａに対して表示した画面に従い、ユーザの操作により通信する２者のユーザが選択されてもよい。

Ｗｅｂサーバ１は、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（接続要求）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１）。ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔは、接続要求の対象の２者のユーザに対応するＳＩＰ−ＵＲＩを含む。Ｗｅｂサーバ１は、ユーザ識別子（ユーザＩＤ）とそのユーザのＳＩＰ−ＵＲＩが対応して電話帳テーブル２４１０に記憶されており、電話帳テーブル２４１０への検索により、入力されたユーザ識別子（ユーザＩＤ）に対応するＳＩＰ−ＵＲＩを取得する。Ｗｅｂサーバ１は、取得されたＳＩＰ−ＵＲＩを含むＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔを生成してＳＯＡＰ−ＳＩＰアダプタ２に送信する。 ＳＯＡＰ−ＳＩＰアダプタ２は、受信したＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔに含まれるＳＩＰ−ＵＲＩに対応するそれぞれの端末５ｂ、５ｃに対して接続を開始し、ＳＯＡＰ−ＳＩＰアダプタ２で生成したｓｅｓｓｉｏｎＩＤを含むＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅ送信する（Ｓ２〜Ｓ１５）。このとき、ｗｅｂサーバ１は、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔに含まれる、接続要求対象の２者のユーザ情報（ＳＩＰ−ＵＲＩ）のうち、発信元アドレスとされているユーザ情報（ＳＩＰ−ＵＲＩ）に対応する第１接続端末Ａ５ｂについて、発信履歴情報テーブル２４２０に発信履歴を登録する。

例えば、発信履歴情報テーブル２４２０には、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅに含む、ｓｅｓｓｉｏｎＩＤ２４２３、発信先アドレス（第２接続端末Ａ５ｃのＳＩＰ−ＵＲＩ）２４２４、発信先アドレス表示名２４２５、発信先名２４２６、発信元アドレス（第１接続端末Ａ５ｂのＳＩＰ−ＵＲＩ）２４２７、発信日時２４２８を含む。

さらに、ｗｅｂサーバ１は、ＳＯＡＰ−ＳＩＰアダプタ２からＳＯＡＰ ｎｏｔｉｆｙＣａｌｌｅｄＮｕｍｂｅｒＲｅｑｕｅｓｔを受信（S２３）、また、ＳＯＡＰ ｎｏｔｉｆｙＡｎｓｗｅｒＲｅｑｕｅｓｔを受信（S２６）する。このとき、ｗｅｂサーバ１は、それぞれ、ＳＯＡＰ−ＳＩＰアダプタ２へ、ＳＯＡＰ ｎｏｔｉｆｙＣａｌｌｅｄＮｕｍｂｅｒＲｅｓｐｏｎｓｅ（S２４）、ＳＯＡＰ ｎｏｔｉｆｙＡｎｓｗｅｒＲｅｓｐｏｎｓｅ（S２７）を送信する。そして、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔに含まれる接続の要求対象の２者のユーザ情報（ＳＩＰ−ＵＲＩ）のうち、発信先アドレスとされているユーザ情報（ＳＩＰ−ＵＲＩ）に対応する第２接続端末Ａ５ｃについて、後述するように、着信履歴情報テーブル２４３０に着信履歴を登録する（Ｓ１８〜Ｓ２７）。例えば、着信履歴情報テーブル２４３０には、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅに含む、ｓｅｓｓｉｏｎＩＤ２４３３、発信元アドレス（第１接続端末Ａ５ｂのＳＩＰ−ＵＲＩ）２４３４、発信元アドレス表示名２４３５、発信元名２４３６、不在着信フラグ２４３７、着信日時２４３８を含む。

以下、ＳＯＡＰ−ＳＩＰアダプタ２に関するステップＳ２〜Ｓ１５、Ｓ１８〜Ｓ２７の詳細な動作について説明する。

ＳＯＡＰ−ＳＩＰアダプタ２のＳＯＡＰ制御部２１０１は、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔを受信し、接続要求を３ＰＣＣモジュール部２１０２に送信する（Ｓ２）。この接続要求は、例えば、受信したＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔに基づいてＳＯＡＰ−ＳＩＰアダプタ２で用いる適宜のプロトコルに従って生成されることができ、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ内のＳＩＰ−ＵＲＩを含む。

３ＰＣＣモジュール部２１０２は、接続要求を受信すると（７００１、８００１）、ｓｅｓｓｉｏｎＩＤを生成する（８００２）。以下に、図７を参照してｓｅｓｓｉｏｎＩＤの生成について説明する。

３ＰＣＣモジュール部２１０２は、接続要求を受信すると、乱数値を生成する（７００２）。３ＰＣＣモジュール部２１０２は、生成された乱数値がセッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１に登録済みであるか否かを判断する（７００３）。生成された乱数値が既に登録済みの場合（すなわち、既に使用されている場合）、３ＰＣＣモジュール部２１０２はステップ７００２に戻り、以降の処理を繰り返す。一方、生成された乱数値が未登録の場合、３ＰＣＣモジュール部２１０２は、生成したｓｅｓｓｉｏｎＩＤをセッション情報テーブル２０１０に記憶する（７００４）。さらに、３ＰＣＣモジュール部２１０２は、セッション情報テーブル２０１０のセッション状態２０１２を「Ｉｎｉｔｉａｌ（初期状態）」に設定する。

また、３ＰＣＣモジュール部２１０２は、受信した接続要求に含まれるＳＩＰ−ＵＲＩを呼参加者情報テーブル２０２０に記憶する。図３−２に示す呼参加者情報テーブル２０２０の例では、端末Ａ５ｂのＳＩＰ−ＵＲＩ（２０２０＿Ａ参照）と、端末Ｂ５ｃのＳＩＰ−ＵＲＩ（２０２０＿Ｂ参照）が記憶される。３ＰＣＣモジュール部２１０２は、呼参加者情報テーブル２０２０の各端末５ｂ、５ｃに対応する呼状態２０２２を「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＩｎｉｔｉａｌ（初期状態）」にそれぞれ設定する。

さらに、３ＰＣＣモジュール部２１０２は、端末Ａ５ｂ、端末Ｂ５ｃの端末情報を記憶する。具体的には、３ＰＣＣモジュール部２１０２は、生成したｓｅｓｓｉｏｎＩＤを各端末５ｂ、５ｃに対応して端末情報テーブル２０３０に記憶する。また、３ＰＣＣモジュール部２１０２は、受信した接続要求に含まれる各ＳＩＰ−ＵＲＩを、端末情報テーブル２０３０の各端末５ｂ、５ｃに対応するＴｏ ＵＲＩ２０３８にそれぞれ記憶する。３ＰＣＣモジュール部２１０２は、端末情報テーブル２０３０の各端末５ｂ、５ｃに対応する端末状態２０３２を「Ｉｎｉｔｉａｌ（初期状態）」にそれぞれ設定する。３ＰＣＣモジュール部２１０２は、端末情報テーブル２０３０の各端末５ｂ、５ｃに対応するＲｏｌｅ２０３３に、発信側又は着信側を示す情報をそれぞれ設定する。なお、端末５ｂ、５ｃのいずれを発信側とするかは適宜定めることができる。また、３ＰＣＣモジュール部２１０２は、ＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を端末情報テーブル２０３０のｓｅｎｄ ＳＤＰ情報２０３５に記憶する。また、３ＰＣＣモジュール部２１０２は、ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ−ＵＲＩを端末情報テーブル２０３０の各端末５ｂ、５ｃに対応するＦｒｏｍ ＵＲＩ２０３７にそれぞれ記憶する。なお、ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ−ＵＲＩ、ＩＰアドレス及びポート番号は、予め適宜の記憶部に記憶されている。

３ＰＣＣモジュール部２１０２は、接続要求成功応答を生成し、ＳＯＡＰ制御部２１０１に送信する（Ｓ３、８０１１）。接続要求成功応答は、生成したｓｅｓｓｉｏｎＩＤを含む。ＳＯＡＰ制御部２１０１は、接続要求成功応答を受信し、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅ（接続要求成功応答）をＷｅｂサーバ１に送信する（Ｓ４、８０１２）。ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅは生成されたｓｅｓｓｉｏｎＩＤを含み、受信した接続要求成功応答に基づいてＳＯＡＰに従って生成される。Ｗｅｂサーバ１は、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅを受信し、受信したＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅに含まれるｓｅｓｓｉｏｎＩＤを適宜の記憶部に記憶する。

なお、ステップ８００２でｓｅｓｓｉｏｎＩＤの生成に失敗した場合、３ＰＣＣモジュール部２１０２は、接続要求失敗応答（エラーレスポンスメッセージ）を生成し（８０１３）、ＳＯＡＰ制御部２１０１に送信する。ＳＯＡＰ制御部２１０１は、接続要求失敗応答を受信し、接続要求の失敗を示すＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅをＷｅｂサーバ１に送信する（８０１２）。

次に、ＳＯＡＰ−ＳＩＰアダプタ２と端末Ａ５ｂとのセッションを確立する。

より具体的には、３ＰＣＣモジュール部２１０２は、メディアストリーム制御・転送用のポートを取得する（８００３）。３ＰＣＣモジュール部２１０２は、端末Ａ５ｂに対する発信要求（Ａ）をＳＩＰ制御部２１０４に送信する（Ｓ５、８００４）。例えば、３ＰＣＣモジュール部２１０２は、端末情報テーブル２０３０に記憶された端末Ａ５ｂに対応するｓｅｎｄ ＳＤＰ情報２０３５、Ｆｒｏｍ ＵＲＩ２０３７及びＴｏ ＵＲＩ２０３８を含む発信要求をＳＩＰ制御部２１０４に送信する。また、３ＰＣＣモジュール部２１０２は、一例としてこのときの時刻を呼参加者情報テーブル２０２０の端末Ａ５ｂに対応する開始時間２０２３に記憶する。図３−２に示す呼参加者情報テーブル２０２０の例では、「２０１０．０８．２２ １０：３０．３０」が記憶される。なお、開始時間２０２３は、このときの時刻に限らず、端末Ａ５ｂとのセッションの開始を示す適宜の時刻を記憶してもよい。

ＳＩＰ制御部２１０４は、発信要求（Ａ）に含まれるＴｏ ＵＲＩに従い、ＩＮＶＩＴＥメッセージ（Ａ）を端末Ａ５ｂに送信する（Ｓ６）。ＩＮＶＩＴＥメッセージ（Ａ）は、例えば、受信した発信要求に含まれる、ｓｅｎｄ ＳＤＰ情報、Ｆｒｏｍ ＵＲＩ、Ｔｏ ＵＲＩを少なくとも含む。また、ＳＩＰ制御部２１０４は、端末Ａ５ｂとのセッションを識別するハンドル値を生成する。

端末Ａ５ｂは、ＩＮＶＩＴＥメッセージ（Ａ）を受信し、受信したＩＮＶＩＴＥメッセージ（Ａ）のｓｅｎｄ ＳＤＰ情報に含まれるＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を適宜の記憶部に記憶する。記憶されたＩＰアドレスとポート番号は、例えばメディアストリームの送信の際に用いられる。また、端末Ａ５ｂは、自身のＩＰアドレスとポート番号を含むｒｅｃｖ ＳＤＰ情報を生成し、生成したＳＤＰ情報を含むＳＩＰの２００ ＯＫ（Ａ）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ７）。ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ制御部２１０４は、２００ ＯＫ（Ａ）を受信し、ＳＩＰのＡＣＫ（Ａ）を端末Ａ５ｂに送信する（Ｓ８）。

ＳＩＰ制御部２１０４は、応答通知（Ａ）を３ＰＣＣモジュール部２１０２に送信する（Ｓ９、８００５）。応答通知（Ａ）は、例えば、ステップＳ６で生成したハンドル値と、ステップＳ７で受信した２００ ＯＫに含まれる端末Ａ５ｂのｒｅｃｖ ＳＤＰ情報とを含む。３ＰＣＣモジュール部２１０２は、受信した応答通知（Ａ）に含まれるハンドル値とｒｅｃｖ ＳＤＰ情報を、端末情報テーブル２０３０に端末Ａ５ｂに対応して記憶する。なお、ハンドル値は、ステップＳ６〜Ｓ８の間の適宜のタイミングで記憶されてもよい。３ＰＣＣモジュール部２１０２は、端末情報テーブル２０３０の端末Ａ５ｂに対応する端末状態２０３３を「ＣａｌｌＣｏｍｐｌｅｔｅ（セッション確立状態）」に更新する。また、３ＰＣＣモジュール部２１０２は、呼参加者情報テーブル２０２０の端末Ａ５ｂに対応する呼状態２０２２を「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＣｏｎｎｅｃｔｅｄ（接続状態）」に更新する。なお、端末状態２０３３は、例えば、ＳＩＰのメッセージ（例えば、２００ ＯＫ等）の送受信に応じて適宜更新してもよい。

また、３ＰＣＣモジュール部２１０２は、生成したｓｅｓｓｉｏｎＩＤと、ＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレス及びポート番号と、受信したｒｅｃｖ ＳＤＰ情報に含まれる端末Ａ５ｂのＩＰアドレス及びポート番号とをメディアストリーム制御部２１０３に送信する。メディアストリーム制御部２１０３は、受信した情報をそれぞれメディアストリーム制御情報テーブル２０４０に記憶する。例えば、メディアストリーム制御部２１０３は、受信したＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレス及びポート番号をメディアストリーム送受信用ＩＰアドレス２０４２、メディアストリーム送受信用ポート番号２０４３に記憶し、受信した端末Ａ５ｂのＩＰアドレス及びポート番号を相手先ＩＰアドレス（１）２０４４、相手先ポート番号（１）２０４５に記憶する。また、メディアストリーム制御部２１０３は、受信したｓｅｓｓｉｏｎＩＤを記憶する。

３ＰＣＣモジュール部２１０２は、擬似ＲＢＴ送信要求をメディアストリーム制御部２１０３に送信する（Ｓ１０１）。メディアストリーム制御部２１０３は、擬似ＲＢＴ送信要求を受信すると、例えばＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）に従い、擬似ＲＢＴを端末Ａ５ｂに送信する（Ｓ１０、８００６）。メディアストリーム制御部２１０３は、例えば相手を呼び出し中である旨のアナウンスや適宜の音楽等を擬似ＲＢＴとして用いてもよい。

次に、ＳＯＡＰ−ＳＩＰアダプタ２と端末Ｂ５ｃとのセッションを確立する。

３ＰＣＣモジュール部２１０２は、端末Ｂ５ｃに対する発信要求（Ｂ）をＳＩＰ制御部２１０４に送信する（Ｓ１１、８００７）。例えば、３ＰＣＣモジュール部２１０２は、端末情報テーブル２０３０に記憶された端末Ｂ５ｃに対応するｓｅｎｄ ＳＤＰ情報２０３５、Ｆｒｏｍ ＵＲＩ２０３７及びＴｏ ＵＲＩ２０３８を含む発信要求をＳＩＰ制御部２１０４に送信する。また、３ＰＣＣモジュール部２１０２は、このときの時刻を呼参加者情報テーブル２０２０の端末Ｂ５ｃに対応する開始時間２０２３に記憶する。図３−２に示す呼参加者情報テーブル２０２０の例では、「２０１０．０８．２２ １０：３０．４５」が記憶される。

ＳＩＰ制御部２１０４は、発信要求（Ｂ）に含まれるＴｏ ＵＲＩに従い、ＩＮＶＩＴＥメッセージ（Ｂ）を端末Ｂ５ｃに送信する（Ｓ１２）。ＩＮＶＩＴＥメッセージ（Ｂ）は、例えば、受信した発信要求に含まれる、ｓｅｎｄ ＳＤＰ情報、Ｆｒｏｍ ＵＲＩ、Ｔｏ ＵＲＩを少なくとも含む。また、ＳＩＰ制御部２１０４は、端末Ｂ５ｃとのセッションを識別するハンドル値を生成する。

端末Ｂ５ｃは、ＩＮＶＩＴＥメッセージ（Ｂ）を受信し、受信したＩＮＶＩＴＥメッセージ（Ｂ）のｓｅｎｄ ＳＤＰ情報に含まれるＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を適宜の記憶部に記憶する。

また、端末Ｂ５ｃは、呼出中であることを示す１８０ Ｒｉｎｇｉｎｇ（呼出中通知）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ２０）。ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ制御部２１０４は、１８０ Ｒｉｎｇｉｎｇを受信し、３ＰＣＣモジュール部２１０２にリンギング通知を送信する（Ｓ２１）。その後、３ＰＣＣモジュール部２１０２は、ＳＯＡＰ制御部２１０１へ接続通知を送信（Ｓ２２）し、次にＳＯＡＰ制御部２１０１は、ｗｅｂサーバ１へＳＯＡＰ ｎｏｔｉｆｙＣａｌｌｅｄＮｕｍｂｅｒＲｅｑｕｅｓｔ（接続通知、接続通知イベント）を送信する（Ｓ２３）。ＳＯＡＰ ｎｏｔｉｆｙＣａｌｌｅｄＮｕｍｂｅｒＲｅｑｕｅｓｔは、例えば、ｃｏｒｒｅｌａｔｏｒ、Ｆｒｏｍ ＵＲＩ、Ｔｏ ＵＲＩ、ＳｅｓｓｉｏｎＩＤとを含む。このとき、ｗｅｂサーバ１は、受信したｃｏｒｒｅｌａｔｏｒをキーにして、端末情報テーブル２４００を検索し、ユーザＩＤ２４０１を取得する。次に、受信したＳｅｓｓｉｏｎＩＤをキーにして、発信履歴情報テーブル２４２０を検索し、発信先アドレス２４２４と受信したＴｏ ＵＲＩとを比較し、同じであれば、発信元アドレス２４２７を取得する。こうして取得した、ユーザＩＤ及び発信元アドレスを、着信履歴情報テーブル２４３０に登録する。これらの少なくともいずれかをキーとして電話帳テーブル２４１０から検索して取得する発信元の表示アドレス及び名前、また、対応するセッションＩＤと、対応させて併せて登録してもよい。このとき不在着信フラグは更新しない。（不在着信フラグは、初期値が“ｔｒｕｅ”であり、不在着信状態となる。） １８０ Ｒｉｎｇｉｎｇをトリガーとして着信履歴情報テーブル２４３０登録を行う場合、明示的に端末呼出中の状態であるため、リアルタイムな着信履歴情報の作成を実現することできる。ここでは、１８０ Ｒｉｎｇｉｎｇを着信履歴情報テーブルへの登録のトリガーとしたが、端末へのセッション接続処理をトリガーとすることができる。すなわち、接続処理における端末へのアクションをトリガーとし、例えば、ＩＮＶＩＴＥをトリガーとしてもよい。ＩＮＶＩＴＥをトリガーとした場合、例えば、端末Ｂ５ｃが何らかの理由により、通話できない状態（電源ＯＦＦ、通話圏外にいる）であっても着信履歴情報テーブルへの登録が可能となる。

ｓｅｓｓｉｏｎＩＤをキーに発信履歴情報を検索した結果、送信先アドレス２４２４と受信したＴｏ ＵＲＩが異なる場合は、ＳＯＡＰ ｎｏｔｉｆｙＣａｌｌｅｄＮｕｍｂｅｒＲｅｑｕｅｓｔを破棄してよい。すなわち、送信先アドレスと受信したＴｏＵＲＩが異なる場合は、着信履歴情報を作成、更新する対象ではないとして、破棄してもよいものとする。例えば、受信したＴｏＵＲＩが発信元アドレスと同じ場合などである。

ｗｅｂサーバ１は、ＳＯＡＰ ｎｏｔｉｆｙＣａｌｌｅｄＮｕｍｂｅｒＲｅｑｕｅｓｔに対し、ＳＯＡＰ制御部２１０１へＳＯＡＰ ｎｏｔｉｆｙＣａｌｌｅｄＮｕｍｂｅｒＲｅｓｐｏｎｓｅを送信する（Ｓ２４）。さらに、端末Ｂ５ｃは、自身のＩＰアドレスとポート番号を含むｒｅｃｖ ＳＤＰ情報を生成し、生成したｒｅｃｖ ＳＤＰ情報を含む２００ ＯＫ（Ｂ）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１３）。ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ制御部２１０４は、２００ ＯＫ（Ｂ）を受信し、ＡＣＫ（Ｂ）を端末Ｂ５ｃに送信する（Ｓ１４）。

ＳＩＰ制御部２１０４は、応答通知（Ｂ）を３ＰＣＣモジュール部２１０２に送信する（Ｓ１５、８００８）。応答通知（Ｂ）は、例えば、ステップＳ１２で生成したハンドル値と、ステップＳ１３で受信した２００ ＯＫに含まれる端末Ｂ５ｃのｒｅｃｖ ＳＤＰ情報とを含む。３ＰＣＣモジュール部２１０２は、受信した応答通知（Ｂ）に含まれるハンドル値及びｒｅｃｖ ＳＤＰ情報を、端末情報テーブル２０３０に端末Ｂ５ｃに対応して記憶する。なお、ハンドル値は、ステップＳ１２〜Ｓ１４の間の適宜のタイミングで記憶されてもよい。３ＰＣＣモジュール部２１０２は、端末情報テーブル２０３０の端末Ｂ５ｃに対応する端末状態２０３３を「ＣａｌｌＣｏｍｐｌｅｔｅ（セッション確立状態）」に更新する。また、３ＰＣＣモジュール部２１０２は、呼参加者情報テーブル２０２０の端末Ｂ５ｃに対応する呼状態２０２２を「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＣｏｎｎｅｃｔｅｄ（接続状態）」に更新する。また、３ＰＣＣモジュール部２１０２は、セッション情報テーブル２０１０のセッション状態を「Ｃｏｎｎｅｃｔｅｄ（接続状態）」に更新する。

次に、３ＰＣＣモジュール部２１０２は、ＳＯＡＰ制御部２１０１へ接続応答通知を送信する（Ｓ２５）。ｗｅｂサーバ１へ、ＳＯＡＰ ｎｏｔｉｆｙＡｎｓｗｅｒＲｅｑｕｅｓｔ（応答通知、応答通知イベント）を送信する（Ｓ２６）。ＳＯＡＰ ｎｏｔｉｆｙＡｎｓｗｅｒＲｅｑｕｅｓｔは、例えば、ｃｏｒｒｅｌａｔｏｒ、Ｆｒｏｍ ＵＲＩ、Ｔｏ ＵＲＩ、ＳｅｓｓｉｏｎＩＤとを含む。このとき、ｗｅｂサーバ１は、受信したｃｏｒｒｅｌａｔｏｒをキーにして、端末情報テーブル２４００を検索し、ユーザＩＤ２４０１を取得する。次に、受信したＳｅｓｓｉｏｎＩＤをキーにして、発信履歴情報テーブル２４２０を検索し、発信先アドレス２４２４と受信したＴｏ ＵＲＩとを比較し、同じであれば、発信元アドレス２４２７を取得する。次に、受信したＳｅｓｓｉｏｎＩＤをキーにして着信履歴情報テーブル２４３０を検索し、該当する着信履歴情報テーブルを更新（不在着信フラグを“ｆａｌｓｅ”に更新する。つまり、通常の着信状態となる。）該当する着信履歴が存在しない場合は、新規に着信履歴情報テーブル２４３０に登録する。もし、発信先アドレス２４２４と受信したＴｏ ＵＲＩが異なる場合は、破棄する。ｗｅｂサーバ１は、ＳＯＡＰ ｎｏｔｉｆｙＡｎｓｗｅｒＲｅｑｕｅｓｔに対し、ＳＯＡＰ制御部２１０１へＳＯＡＰ ｎｏｔｉｆｙＡｎｓｗｅｒＲｅｓｐｏｎｓｅを送信する（Ｓ２７）。

３ＰＣＣモジュール部２１０２は、ｓｅｓｓｉｏｎＩＤと、受信したｒｅｃｖ ＳＤＰ情報に含まれる端末Ｂ５ｃのＩＰアドレス及びポート番号をメディアストリーム制御部２１０３に送信する。メディアストリーム制御部２１０３は、受信したｓｅｓｓｉｏｎＩＤに対応して、端末Ｂ５ｃのＩＰアドレス及びポート番号をメディアストリーム制御情報テーブル２０４０の相手先ＩＰアドレス（２）２０４６、相手先ポート番号（２）２０４７に記憶する。

３ＰＣＣモジュール部２１０２は、擬似ＲＢＴ停止要求をメディアストリーム制御部２１０３に送信する（Ｓ１０２、８００９）。メディアストリーム制御部２１０３は、擬似ＲＢＴ停止要求に従い擬似ＲＢＴの送信を停止する。

ＳＯＡＰ−ＳＩＰアダプタ２は、端末Ａ５ｂと端末Ｂ５ｃとの間でメディアストリーム転送を開始する（８０１０）。

メディアストリーム転送に関するシーケンスを図１２に示す。本シーケンスは、少なくとも図６のＳ１０２以降に実施されるものである。例えば、端末Ａ５ｂは、ＲＴＰに従い、メディアストリームをＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１２−１）。このとき、端末Ａ５ｂは、ステップＳ６で記憶したＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を宛先に設定し、自身のＩＰアドレスとポート番号を送信元に設定する。

ＳＯＡＰ−ＳＩＰアダプタ２のメディアストリーム制御部２１０３は、受信したメディアストリームを、メディアストリーム制御情報テーブル２０４０を参照して端末Ｂ５ｃに転送する（Ｓ１２−２）。例えば、メディアストリーム制御部２１０３は、受信したメディアストリームの送信元ＩＰアドレスとポート番号に基づいてメディアストリーム制御情報テーブル２０４０を参照し、対応する相手先ＩＰアドレスとポート番号を取得する。図３−４に示すメディアストリーム制御情報テーブル２０４０の例では、受信したメディアストリームの送信元ＩＰアドレスとポート番号は、端末Ａ５ｂのＩＰアドレス（１０．０．２．１）、ポート番号（２００００）であり、対応する相手先ＩＰアドレス（２）２０４６（１０．０．２．２）とポート番号（２）２０４７（３００００）が取得される。メディアストリーム制御部２１０３は、取得したＩＰアドレスとポート番号に従い、受信したメディアストリームを端末Ｂ５ｃに転送する。

同様に、端末Ｂ５ｃは、ＲＴＰに従い、メディアストリームをＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１２−３）。端末Ａ５ｂの場合と同様に、端末Ｂ５ｃは、ステップＳ１２で記憶したＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を宛先に設定し、自身のＩＰアドレスとポート番号を送信元に設定する。

ＳＯＡＰ−ＳＩＰアダプタ２のメディアストリーム制御部２１０３は、受信したメディアストリームを、メディアストリーム制御情報テーブル２０４０を参照して端末Ａ５ｂに転送する（Ｓ１２−４）。図３−４に示すメディアストリーム制御情報テーブル２０４０の例では、受信したメディアストリームの送信元ＩＰアドレスとポート番号は、端末Ｂ５ｃのＩＰアドレス（１０．０．２．２）、ポート番号（３００００）であり、対応する相手先ＩＰアドレス（１）２０４４（１０．０．２．１）とポート番号（１）２０４５（２００００）が取得される。メディアストリーム制御部２１０３は、取得したＩＰアドレスとポート番号に従い、受信したデータストリームを端末Ａ５ｂに転送する。

図１３は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼情報（セッション情報）要求受信の手順を説明するシーケンス図である。図９は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼情報（セッション情報）要求受信時の動作を説明するフローチャートである。

図１３、図９を参照して、Ｗｅｂサーバ１が呼情報を取得する動作について説明する。ここでは、Ｗｅｂサーバ１は、指定したｓｅｓｓｉｏｎＩＤに対応する情報を取得できる。図１３のステップＳ２１〜Ｓ２４の処理は、上述のステップＳ１２−１〜Ｓ１２−４の処理に対応する。

Ｗｅｂサーバ１は、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔ（セッション情報要求、呼情報要求）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ２５）。ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔは、取得したい呼情報のｓｅｓｓｉｏｎＩＤを含む。より具体的には、Ｗｅｂサーバ１は、上述のステップＳ４で記憶されたｓｅｓｓｉｏｎＩＤを含むＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔを生成し、ＳＯＡＰ−ＳＩＰアダプタ２に送信する。なお、Ｗｅｂサーバ１は、端末５ａより、ユーザ操作に基づいて上述のステップＳ４で記憶されたｓｅｓｓｉｏｎＩＤから取得したい呼情報のｓｅｓｓｉｏｎＩＤを選択してもよい。

ＳＯＡＰ−ＳＩＰアダプタ２は、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔに含まれるｓｅｓｓｉｏｎＩＤをキーにＳＯＡＰ−ＳＩＰアダプタ２で保持しているセッション情報テーブル２０１０を検索し、一致するｓｅｓｓｉｏｎＩＤ２０１１のテーブル情報を含むＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅを送信する（Ｓ２６〜Ｓ２８）。以下、ＳＯＡＰ−ＳＩＰアダプタ２におけるステップＳ２６〜Ｓ２８の詳細な動作について説明する。

まず、ＳＯＡＰ−ＳＩＰアダプタ２のＳＯＡＰ制御部２１０１は、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔを受信し、セッション情報要求を３ＰＣＣモジュール部２１０２に送信する（Ｓ２６）。このセッション情報要求は、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔ内のｓｅｓｓｉｏｎＩＤを含む。

３ＰＣＣモジュール部２１０２は、セッション情報要求を受信すると（９００１）、受信したセッション情報要求に含まれるｓｅｓｓｉｏｎＩＤに基づいてセッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１を検索する（９００２）。受信したセッション情報要求に含まれるｓｅｓｓｉｏｎＩＤがセッション情報テーブル２０１０に登録済みの場合、該当したｓｅｓｓｉｏｎＩＤ２０１１に対応するセッション情報が特定される（９００３）。３ＰＣＣモジュール部２１０２は、該当したｓｅｓｓｉｏｎＩＤ２０１１に対応する呼参加者情報テーブル（呼参加者状態）２０２０を参照して、例えば各端末５ｂ、５ｃに対応するＵＲＩ２０２１及び呼状態２０２２を、それぞれ取得する（９００４）。さらに、３ＰＣＣモジュール部２１０２は、例えば該当したｓｅｓｓｉｏｎＩＤ２０１１に対応する端末情報（端末 Ａ５ｂ用）２０３０＿Ａ及び端末情報（端末 Ｂ５ｃ用）２０３０＿Ｂより、各端末のｒｅｃｖ ＳＤＰ情報２０３６をそれぞれ取得する。

３ＰＣＣモジュール部２１０２は、ｓｅｓｓｉｏｎＩＤ２０１１、取得したＵＲＩ２０２１、呼状態２０２２及びｒｅｃｖ ＳＤＰ情報２０３６を含むセッション情報要求成功応答を生成し（９００５）、生成したセッション情報要求成功応答をＳＯＡＰ制御部２１０１に送信する（Ｓ２７）。ＳＯＡＰ制御部２１０１は、セッション情報要求成功応答を受信し、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅ（セッション情報要求成功応答）をＷｅｂサーバ１に送信する（Ｓ２８、９００６）。ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅは、受信したセッション情報要求成功応答内のｓｅｓｓｉｏｎＩＤ、ＵＲＩ、呼状態及びｒｅｃｖ ＳＤＰ情報を含み、ＳＯＡＰに従って生成される。

なお、ステップ９００２において、受信したセッション情報要求に含まれるｓｅｓｓｉｏｎＩＤが未登録の場合、３ＰＣＣモジュール部２１０２は、セッション情報要求失敗応答（エラーレスポンスメッセージ）を生成し（９００７）、生成したセッション情報要求失敗応答をＳＯＡＰ制御部２１０１に送信する。ＳＯＡＰ制御部２１０１は、セッション情報要求失敗応答を受信し、セッション情報要求の失敗を示すＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅをＷｅｂサーバ１に送信する（９００６）。

Ｗｅｂサーバ１は、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅを受信し、例えば受信したＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅに含まれる呼状態を参照することで、要求した通信が成立したかなどセッションの状態を確認できる。また、例えば、端末から呼を終了した場合、呼状態が「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＴｅｒｍｉｎａｔｅｄ（終了状態）」となり、Ｗｅｂサーバ１は、端末Ａ５ｂ又は端末Ｂ５ｃから呼が終了されたと判断できる。また、例えば、呼状態が正常でない場合、Ｗｅｂサーバ１は、例えば後述するＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔを用いて通信を停止させてもよい。

図１４は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼参加者情報要求受信時の手順を説明するシーケンス図である。図１０は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼参加者情報要求受信時の動作を説明するフローチャートである。

図１４、図１０を参照して、Ｗｅｂサーバ１が呼参加者情報を取得する動作について説明する。ここでは、指定したＳＩＰ−ＵＲＩに対応するユーザの情報を取得できる。図１４のステップＳ３１〜Ｓ３４の処理は、上述のステップＳ１２−１〜Ｓ１２−４の処理に対応する。

Ｗｅｂサーバ１は、ＳＯＡＰ ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔ（呼参加者情報要求）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ３５）。ＳＯＡＰ ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔは、取得したい呼参加者情報のｓｅｓｓｉｏｎＩＤとＵＲＩを含む。具体的には、例えば、Ｗｅｂサーバ１は、上述のステップＳ４で記憶されたｓｅｓｓｉｏｎＩＤと、所望の呼参加者のＳＩＰ−ＵＲＩを含むＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔを生成し、ＳＯＡＰ−ＳＩＰアダプタ２に送信する。一例として、Ｗｅｂサーバ１は、端末５ａより、ユーザ操作に基づいて取得したい呼情報のｓｅｓｓｉｏｎＩＤとユーザ識別子（ユーザＩＤ）（例えば、端末Ａ５ｂ、端末Ｂ５ｃを使用するユーザに対応するユーザＩＤ）を選択してもよい。なお、Ｗｅｂサーバ１は、上述のようにユーザ識別子（ユーザＩＤ）とそのユーザのＳＩＰ−ＵＲＩが対応して電話帳テーブル２４１０に記憶されており、電話帳テーブル２４１０への検索により、入力されたユーザ識別子（ユーザＩＤ）に対応するＳＩＰ−ＵＲＩを取得できる。

ＳＯＡＰ−ＳＩＰアダプタ２は、ＳＯＡＰ ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔに含まれるｓｅｓｓｉｏｎＩＤをキーにＳＯＡＰ−ＳＩＰアダプタ２で保持しているセッション情報テーブル２０１０を検索し、一致するｓｅｓｓｉｏｎＩＤ２０１１のテーブル情報を特定する。さらに、ＳＯＡＰ−ＳＩＰアダプタ２は、ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔに含まれるＳＩＰ−ＵＲＩをキーに呼参加者情報テーブル２０２０を検索し、一致するＳＩＰ−ＵＲＩ２０２１に対応するテーブル情報を含むＳＯＡＰ ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅを送信する（Ｓ３６〜Ｓ３８）。以下、ＳＯＡＰ−ＳＩＰアダプタ２におけるステップＳ３６〜Ｓ３８の動作について説明する。

ＳＯＡＰ−ＳＩＰアダプタ２のＳＯＡＰ制御部２１０１は、ＳＯＡＰ ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔを受信し、呼参加者情報要求を３ＰＣＣモジュール部２１０２に送信する（Ｓ３６）。この呼参加者情報要求は、ＳＯＡＰ ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔ内のｓｅｓｓｉｏｎＩＤとＳＩＰ−ＵＲＩとを含む。３ＰＣＣモジュール部２１０２は、呼参加者情報要求を受信すると（１００１）、受信した呼参加者情報要求に含まれるｓｅｓｓｉｏｎＩＤに基づいてセッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１を検索する（１００２）。受信した呼参加者情報要求に含まれるｓｅｓｓｉｏｎＩＤがセッション情報テーブル２０１０に登録済みの場合、該当したｓｅｓｓｉｏｎＩＤ２０１１によりセッション情報が特定される（１００３）。３ＰＣＣモジュール部２１０２は、受信した呼参加者情報要求に含まれるＳＩＰ−ＵＲＩに基づいて、該当したｓｅｓｓｉｏｎＩＤ２０１１に対応する呼参加者情報テーブル（呼参加者状態）２０２０のＵＲＩ２０２１を検索する（１００４）。受信した呼参加者情報要求に含まれるＳＩＰ−ＵＲＩが登録済みの場合、３ＰＣＣモジュール部２１０２は、該当したＵＲＩ２０２１に対応する呼状態２０２２を取得する（１００５）。また、３ＰＣＣモジュール部２１０２は、受信した呼参加者情報要求に含まれるＳＩＰ−ＵＲＩに基づいて端末情報テーブル２０３０のＴｏ ＵＲＩ２０３８を参照し、対応するｒｅｃｖ ＳＤＰ情報２０３６を取得する。

３ＰＣＣモジュール部２１０２は、ＵＲＩ２０２１、取得した呼状態２０２２及びｒｅｃｖ ＳＤＰ情報２０３６を含む呼参加者情報要求成功応答を生成し（１００６）、生成した呼参加者情報要求成功応答をＳＯＡＰ制御部２１０１に送信する（Ｓ３７）。ＳＯＡＰ制御部２１０１は、呼参加者情報要求成功応答を受信し、ＳＯＡＰ ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅ（呼参加者情報要求成功応答）をＷｅｂサーバ１に送信する（Ｓ３８、１００７）。ＳＯＡＰ ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅは、受信した呼参加者情報要求成功応答内のＵＲＩ、呼状態及びｒｅｃｖ ＳＤＰ情報を含み、ＳＯＡＰに従って生成される。

なお、ステップ１００２において、受信した呼参加者情報要求に含まれるｓｅｓｓｉｏｎＩＤが未登録の場合、及び、ステップ１００４において受信した呼参加者情報要求に含まれるＳＩＰ−ＵＲＩが未登録の場合、３ＰＣＣモジュール部２１０２は、呼参加者情報要求失敗応答（エラーレスポンスメッセージ）を生成し（１００８）、生成した呼参加者情報要求失敗応答をＳＯＡＰ制御部２１０１に送信する。ＳＯＡＰ制御部２１０１は、呼参加者情報要求失敗応答を受信し、呼参加者情報要求の失敗を示すＳＯＡＰ ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅをＷｅｂサーバ１に送信する（１００７）。

図１５は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼終了要求受信時の手順を説明するシーケンス図である。図１１は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼終了要求受信時の動作を説明するフローチャートである。

図１５、図１１は、Ｗｅｂサーバ１が呼終了する動作について説明する。図１５のステップＳ４１〜Ｓ４４の処理は、上述のステップＳ１２−１〜Ｓ１２−４の処理に対応する。

Ｗｅｂサーバ１は、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（呼終了要求）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ４５）。ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔは、呼終了したい呼のｓｅｓｓｉｏｎＩＤを含む。より具体的には、Ｗｅｂサーバ１は、上述のステップＳ４で記憶されたｓｅｓｓｉｏｎＩＤを含むＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔを生成し、ＳＯＡＰ−ＳＩＰアダプタ２に送信する。一例として、Ｗｅｂサーバ１は、端末５ａより、ユーザ操作に基づいて上述のステップＳ４で記憶されたｓｅｓｓｉｏｎＩＤから呼終了したい呼のｓｅｓｓｉｏｎＩＤを選択してもよい。

ＳＯＡＰ−ＳＩＰアダプタ２は、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔに含まれるｓｅｓｓｉｏｎＩＤをキーにＳＯＡＰ−ＳＩＰアダプタ２で保持しているセッション情報テーブル２０１０を検索し、一致するｓｅｓｓｉｏｎＩＤ２０１１のテーブル情報から切断する端末５ｂ、５ｃを特定して切断する（Ｓ４６〜Ｓ５６）。以下、ＳＯＡＰ−ＳＩＰアダプタ２におけるステップＳ４６〜Ｓ５６の詳細な動作について説明する。

ＳＯＡＰ−ＳＩＰアダプタ２のＳＯＡＰ制御部２１０１は、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（呼終了要求）を受信し、呼終了要求を３ＰＣＣモジュール部２１０２に送信する（Ｓ４６）。この呼終了要求は、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ内のｓｅｓｓｉｏｎＩＤを含む。３ＰＣＣモジュール部２１０２は、呼終了要求を受信すると（１１０１）、受信した呼終了要求に含まれるｓｅｓｓｉｏｎＩＤに基づいてセッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１を検索する（１１０２）。

受信した呼終了要求に含まれるｓｅｓｓｉｏｎＩＤがセッション情報テーブル２０１０に登録済みの場合、３ＰＣＣモジュール部２１０２は、呼終了要求成功応答を生成し（１１０９）、生成した呼終了要求成功応答をＳＯＡＰ制御部２１０１に送信する（Ｓ４７）。ＳＯＡＰ制御部２１０１は、呼終了要求成功応答を受信し、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅ（呼終了要求成功応答）をＷｅｂサーバ１に送信する（Ｓ４８、１１１０）。なお、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅは、成功応答のみが送信されてもよい。

また、該当したｓｅｓｓｉｏｎＩＤ２０１１によりセッション情報を特定し、通話中の２者（ここでは端末Ａ５ｂ、端末Ｂ５ｃ）を特定する（１１０３）。例えば、３ＰＣＣモジュール部２１０２は、受信した呼終了要求に含まれるｓｅｓｓｉｏｎＩＤに対応する呼参加者情報テーブル２０２０を参照し、各端末Ａ５ｂ、端末Ｂ５ｃのＳＩＰ−ＵＲＩ２０２１をそれぞれ取得する。メディアストリーム制御部２１０３は、メディアストリームの転送を停止する（１１０４）。なお、３ＰＣＣモジュール部２１０２から、メディアストリーム転送停止要求をメディアストリーム制御部２１０３に送信してもよい。

３ＰＣＣモジュール部２１０２は、取得されたＳＩＰ−ＵＲＩの一方に従い、取得されたＳＩＰ−ＵＲＩを含む切断要求（Ａ）をＳＩＰ制御部２１０４に送信する（Ｓ４９、１１０５）。ＳＩＰ制御部２１０４は、切断要求（Ａ）を受信し、受信した切断要求（Ａ）に含まれるＳＩＰ−ＵＲＩをＴｏ ＵＲＩとして、ＳＩＰのＢＹＥメッセージ（Ａ）を端末Ａ５ｂに送信する（Ｓ５０）。

同様に、３ＰＣＣモジュール部２１０２は、取得されたＳＩＰ−ＵＲＩの他方に従い、取得されたＳＩＰ−ＵＲＩを含む切断要求（Ｂ）をＳＩＰ制御部２１０４に送信する（Ｓ５１、１１０６）。ＳＩＰ制御部２１０４は、切断要求（Ｂ）を受信し、受信した切断要求（Ｂ）に含まれるＳＩＰ−ＵＲＩをＴｏ ＵＲＩとしてＢＹＥメッセージ（Ｂ）を端末Ｂ５ｃに送信する（Ｓ５２）。

端末Ａ５ｂは、ステップＳ５０において受信したＢＹＥメッセージ（Ａ）に対する２００ ＯＫ（Ａ）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ５３）。ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ制御部２１０４は、２００ ＯＫ（Ａ）を受信し、切断完了通知（Ａ）を３ＰＣＣモジュール部２１０２に送信する（Ｓ５４、１１０７）。

同様に、端末Ｂ５ｃは、ステップＳ５２において受信したＢＹＥメッセージ（Ｂ）に対する２００ ＯＫ（Ｂ）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ５５）。ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ制御部２１０４は、２００ ＯＫ（Ｂ）を受信し、切断完了通知（Ｂ）を３ＰＣＣモジュール部２１０２に送信する（Ｓ５６、１１０８）。

なお、ステップ１１０２において、受信した呼終了要求に含まれるｓｅｓｓｉｏｎＩＤが未登録の場合、３ＰＣＣモジュール部２１０２は、呼終了要求失敗応答（エラーレスポンスメッセージ）を生成し（１１１１）、生成した呼終了要求失敗応答をＳＯＡＰ制御部２１０１に送信する。ＳＯＡＰ制御部２１０１は、呼終了要求失敗応答を受信し、呼終了要求の失敗を示すＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅをＷｅｂサーバ１に送信する（１１１０）。

図１９に、ｗｅｂサーバ１により、電話帳データ、発信履歴データ、及び着信履歴データを参照させる動作を説明する。

３ＰＣＣサービスを利用するユーザは、例えば、端末５ａなどからｗｅｂサーバ１へアクセスし、ログインをする。ｗｅｂサーバ１の処理部１００は、ログインを受け付けたユーザＩＤをキーとして、電話帳テーブル、発信履歴情報テーブル、及び着信履歴情報テーブルの少なくともいずれかに検索を行う。そして、検索の結果、各々のテーブルごとに、一のユーザＩＤに対応するデータ（群）を抽出する。そして、各々のテーブルごとに抽出されたデータ（群）を、端末５aに送信する。ここでは、ｗｅｂサーバ１がデータ（群）送付とあわせて、端末５aにデータ群の表示まで指令し、端末５aにデータ群の表示がなされる実施形態を説明している。

ログインしたユーザ、つまり電話帳テーブル２４１０のユーザＩＤ２４１２について、対応した電話帳データ、発信履歴データ、着信履歴データを参照することができる。表示方法は、例えば、各々のデータに対応するタブを利用し、１つのウィンドウにて参照する。

図２０−１は電話帳表示例を示す。ログインしたユーザに関する情報が表示される。、図２０−２は発信履歴表示例を示す。ログインしたユーザの発信履歴が、例えば、発信先と発信時間と発信先表示アドレスとの組合せにより、セッションごとに表示される。図２０−３は着信履歴表示例を示す。ログインしたユーザの着信履歴が、例えば、発信元と着信時間と発信元表示アドレスとの組合せにより、セッションごとに表示される。

また、ｗｅｂサーバ１が各々のテーブルごとに抽出されたデータ（群）を、端末５ａに送付し、端末５ａではそれらのデータ（群）からユーザの指定する情報のみを表示可能とするアプリケーションを有してもよい。

なお、電話帳の登録、削除、編集や、電話帳テーブル２４１０の、名前２４１３、ふりがな２４１４、アドレス２４１５は、端末５aのＧＵＩ画面によりを更新してもよい。

１ Ｗｅｂサーバ
２、６ ＳＯＡＰ−ＳＩＰアダプタ
３ ＳＩＰサーバ
４ ＨＧＷ
５、７ 端末
１００ 処理部
１１０ 入力部
１２０ 表示部
１３０ 記憶部
１４０ 通信インタフェース
２００１、５００１ ＣＰＵ
２００３、５００３ ＩＦ
２００４、５００４ メモリ
２０１０ セッション情報テーブル
２０１１ ｓｅｓｓｉｏｎＩＤ
２０２０ 呼参加者情報テーブル
２０３０、５０２０、６０２０ 端末情報テーブル
２０４０、５０３０、６０３０ メディアストリーム制御情報テーブル
２１０１、５１０１ ＳＯＡＰ制御部
２１０２ ３ＰＣＣモジュール部
２１０３、５１０３ メディアストリーム制御部
２１０４、５１０４ ＳＩＰ制御部
２４００ 端末情報テーブル
２４１０ 電話帳テーブル
２４２０ 発信履歴情報テーブル
２４３０ 着信履歴情報テーブル
５０１０、６０１０ コネクション情報テーブル
５０１１、６０１１ ｃｏｎｎｅｃｔｉｏｎＩＤ
５１０２ ＮＧＮ接続モジュール部
Ｎ１ インターネット
Ｎ２ ＮＧＮ

Claims (10)

1. 複数の通信端末とセッション接続処理をする通信装置と通信する接続装置と、ネットワークを介して接続され、
   前記接続装置にユーザ識別子を用いてログインし、
   前記通信端末を所有するユーザのユーザ識別子と対応づけて、呼の着信が前記接続装置により管理される着信履歴情報のうち、前記ログインに用いたユーザ識別子に対応する着信履歴情報を参照する
   ことを特徴とする端末。
2. 前記通信装置において、前記接続装置から前記通信端末間の接続要求が受信されると、通信端末間のセッションを確立するセッション接続処理がなされ、
   前記接続装置において、発信先となる通信端末における呼の着信が、前記発信先の通信端末を所有するユーザのユーザ識別子と対応づけて着信履歴情報として管理される
   ことを特徴とする請求項１記載の端末。
3. 前記発信先の通信端末の呼出処理をトリガとして、前記発信先の通信端末についての着信履歴が、前記発信先の通信端末を所有するユーザのユーザ識別子と対応づけて登録される前記着信履歴情報を参照する
   ことを特徴とする請求項２記載の端末。
4. 前記接続装置において前記発信先の通信端末から前記通信装置へ送信された接続成功通知に基づく接続応答通知が前記通信装置から受信されると、前記接続応答通知に基づいて前記発信先の通信端末に対応するユーザ識別子の着信履歴に含まれる不在着信情報が着信状態とされる前記着信履歴情報、を参照する
   ことを特徴とする請求項２記載の端末。
5. 前記セッション接続処理では、発信元となる通信端末と前記発信先となる通信端末との間のセッションが確立される
   ことを特徴とする請求項４記載の端末。
6. 前記接続装置において前記発信先の通信端末から前記通信装置へ送信された前記発信先の通信端末を呼出中である呼出中通知に基づく接続通知が前記通信装置から受信されると、前記接続通知に基づいて、前記不在着信情報が不在着信状態である前記発信先の通信端末に対応するユーザ識別子の着信履歴に、前記発信元の通信端末のアドレスが登録される着信履歴情報、を参照する
   ことを特徴とする請求項５記載の端末。
7. 複数の通信端末とセッション接続処理をする通信装置と通信する接続装置と、ネットワークを介して接続され、
   前記接続装置にユーザ識別子を用いてログインし、
   前記通信端末を所有するユーザのユーザ識別子と対応づけて、前記通信端末の電話番号が前記接続装置により管理される電話帳情報のうち、前記ログインに用いたユーザ識別子に対応する電話帳情報を参照する
   ことを特徴とする端末。
8. 前記通信端末を所有するユーザのユーザ識別子と対応づけて、呼の着信が前記接続装置により管理される着信履歴情報のうち、前記ログインに用いたユーザ識別子に対応する着信履歴情報を参照する
   ことを特徴とする請求項７記載の端末。
9. 複数の通信端末とセッション接続処理をする通信装置と通信する接続装置と、ネットワークを介して接続され、
   前記接続装置にユーザ識別子を用いてログインし、
   前記通信端末を所有するユーザのユーザ識別子と対応づけて、呼の発信が前記接続装置により管理される発信履歴情報のうち、前記ログインに用いたユーザ識別子に対応する発信履歴情報を参照する
   ことを特徴とする端末。
10. 前記通信端末を所有するユーザのユーザ識別子と対応づけて、呼の着信が前記接続装置により管理される着信履歴情報のうち、前記ログインに用いたユーザ識別子に対応する着信履歴情報を参照する
    ことを特徴とする請求項９記載の端末。

Images