JP5036841B2 - 通信システム - Google Patents

Description

本発明は、通信システムに係り、特に第三者呼制御による拠点間接続方式についての通信システムに関する。

近年、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）技術を利用した通信事業者による次世代の通信網に関する検討が盛んに行われている。この種の次世代通信網をＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）と呼んでいる。ＮＧＮでは、通信をしようとするサーバとクライアントの間にセッションを確立し、そのセッション毎に帯域を管理する方法が採られることが多い。また、ＮＧＮにて、帯域の確保に用いられるセッション制御プロトコルは例えばＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）がある。
また、帯域確保用セッションの制御プロトコルを実装しないクライアント装置が帯域保障型網で通信するとき、セッション代行装置がクライアント装置に代わって帯域保障型網内に帯域確保用セッションを確立する技術が開示されている（例えば、特許文献１参照）。
また、アプリケーション間で情報交換を行うためのＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）が知られている。
また、３ＰＣＣ（３ｒｄ Ｐａｒｔｙ Ｃａｌｌ Ｃｏｎｔｒｏｌ、第３者による呼制御）が例えば非特許文献１に開示され、ＳＩＰのＲＥＦＥＲメソッドが例えば非特許文献２に開示されている。

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

ＲＦＣ３７２５ ＲＦＣ３５１５

ＮＧＮにおいては、シグナリングチャネルとデータチャネルを確立するＩＰアドレスが同一であることが必要である。そのため、従来の３ＰＣＣ（３ｒｄ Ｐａｒｔｙ Ｃａｌｌ Ｃｏｎｔｒｏｌ）サービスフローのように通信させる２者間（第１接続端末と第２接続端末間）のデータチャネルの確立代行が不可能となる課題がある。また、３ＰＣＣサービスフローにおいて、まず３ＰＣＣを実装する装置と第１接続端末とのセッションを確立し、次に３ＰＣＣを実装する装置と第２接続端末とのセッションを確立して、第１接続端末と第２接続端末間で通話する場合、第１接続端末とのセッションの確立が完了し、第２接続端末とのセッションの確立を開始している段階で、第１接続端末では無音状態となってしまう課題がある。また、既存のアプリケーション端末などはＮＧＮで通信帯域を確保する為のＳＩＰを実装していないものが多く、ＮＧＮ上での通信が不可能であるといった課題がある。
また、上記３ＰＣＣを実装する装置で管理するセッション数が多くなると、装置の負荷が大きくなる課題がある。
本発明は以上の点に鑑み、３ＰＣＣサービスを提供するＳＯＡＰ−ＳＩＰアダプタでのセッションの管理及び中継処理などの負荷を軽減することを目的のひとつとする。また、本発明は、端末間の通信条件が異なる場合に、ＳＯＡＰ−ＳＩＰアダプタが該端末間の通信の整合を取ることを目的のひとつとする。

本発明の第１の解決手段によると、
上位装置から第１端末及び第２端末間の接続要求メッセージを受信し、該第１端末及び該第２端末とそれぞれセッションを確立するサーバと、
前記第１端末と前記第２端末間のセッションを管理する呼制御装置と
を備え、
前記サーバが、第１端末及び第２端末とそれぞれセッションを確立した後に、前記呼制御装置へセッションの転送要求を送信し、以後、前記サーバとセッションを確立している前記第１及び第２端末間のセッションを前記呼制御装置が管理する通信システムが提供される。
第１の解決手段によると、ＳＯＡＰ−ＳＩＰアダプタの負荷を軽減することができる。例えば、ＳＯＡＰ−ＳＩＰアダプタでのＩＮＶＩＴＥセッションの管理数を削減することができる。また、ＳＯＡＰ−ＳＩＰアダプタでのメディアの中継処理の負荷を削減できる。また、呼制御装置が転送機能を代行することで、ＲＥＦＥＲやＩＮＶＩＴＥ（ｒｅｐｌａｃｅｓ）機能を持たない端末でも転送ができる。
また、上述の通信システムにおいて、
前記サーバは、
前記第１及び第２端末とセッションを確立する処理において受信されるデータから予め定められたキー情報を抽出し、該キー情報に基づいて、自サーバでメディア中継するか又は前記呼接続装置へセッションの管理を引き渡すか判断し、
セッションの管理を引き渡すと判断した場合、前記呼制御装置に前記転送要求を送信し、
自サーバでメディア中継すると判断した場合、前記第１端末及び前記第２端末と確立したセッションを用い、該第１及び第２端末間のメディア情報に所定の変換又は付加サービスを施して中継してもよい。
この場合、特定のサービスを提供する通信を特定し、この通信についてはＳＯＡＰ−ＳＩＰアダプタを介して当該サービスに対応する処理を実行することができ、一方、特定サービスを提供しない通信については呼制御装置にセッションの管理を転送して負荷を軽減し、ＳＯＡＰ−ＳＩＰアダプタの処理資源を効率的に使用できる。
本発明の第２の解決手段によると、
上位装置から第１端末及び第２端末間の接続要求メッセージを受信し、該第１端末及び該第２端末とそれぞれセッションを確立するサーバを備え、第１端末及び第２端末間で通信するための通信システムであって、
前記サーバは、
セッションを確立した前記第１及び第２端末が受信するメディア情報のコーディックの識別情報を含む通信条件情報をそれぞれ取得し、
取得した通信条件情報に基づき、前記第１及び第２端末が受信するメディア情報のコーディックを判断し、
判断結果に従い使用するコーディックを決定して、決定したコーディックを前記第１及び／又は第２端末へ通知する前記通信システムが提供される。
また、上述の通信システムにおいて、
前記サーバは、
予め定められたひとつ又は複数の第１通信条件情報を含む接続要求を、前記第１端末に送信し、
該第１端末が該第１通信条件情報の中から選択した該第１端末が受信可能な第２通信条件情報を含む接続応答を受信し、
該第２通信条件情報の基づき作成した第３通信条件情報を含む接続要求を、前記第２端末に送信し、
該第２端末が該第３通信条件情報の中から選択した該第２端末が受信可能な第４通信条件情報を含む接続応答を受信し、
第４通信条件情報の中から、使用するコーディックを決定して、決定したコーディックを前記第１端末へ通知してもよい。
本発明の第３の解決手段によると、
上位装置から第１端末及び第２端末間の接続要求メッセージを受信し、該第１端末及び該第２端末とそれぞれセッションを確立するサーバを備え、第１端末及び第２端末間で通信するための通信システムであって、
前記サーバは、
セッションを確立した前記第１及び第２端末が受信するメディア情報のコーディックの識別情報を含む通信条件情報をそれぞれ取得し、
取得した前記第１及び第２端末各々の通信条件情報を照合し、
照合結果に対応するように、前記第１及び第２端末が送受信するメディア情報のコーディックを変換する前記通信システムが提供される。
第３の解決手段によると、端末間の通信条件が異なる場合に、ＳＯＡＰ−ＳＩＰアダプタが該端末間の通信の整合を取ることができる。

本発明によると、３ＰＣＣサービスを提供するＳＯＡＰ−ＳＩＰアダプタでのセッションの管理及び中継処理などの負荷を軽減することができる。また、本発明によると、端末間の通信条件が異なる場合に、ＳＯＡＰ−ＳＩＰアダプタが該端末間の通信の整合を取ることができる。

第１の実施の形態の通信網の構成例を示す説明図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２の構成例を示す説明図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２におけるセッション情報テーブル２０１０の構成の一例を示す説明図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼参加者情報テーブル２０２０の構成の一例を示す説明図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における端末情報テーブル２０３０の構成の一例を示す説明図である。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２におけるメディアストリーム制御情報テーブル２０４０の構成の一例を示す説明図である。 第２の実施の形態の通信網の構成例を示す説明図である。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６の構成例を示す説明図である。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ａにおけるコネクション情報テーブル５０１０の構成の一例を示す説明図である。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ａにおける端末情報テーブル５０２０の構成の一例を示す説明図である。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ａにおけるメディアストリーム制御情報テーブル５０３０の構成の一例を示す説明図である。 ＳＯＡＰ−ＳＩＰアダプタにおけるｓｅｓｓｉｏｎＩＤ／ｃｏｎｎｅｃｔｉｏｎＩＤ生成を説明するフローチャートである。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼開始要求受信時の動作を説明するフローチャートである。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼情報（セッション情報）要求受信時の動作を説明するフローチャートである。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼参加者情報要求受信時の動作を説明するフローチャートである。 第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼終了要求受信時の動作を説明するフローチャートである。 第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図（１）である。 第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図（２）である。 第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図（３）である。 第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図（４）である。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６における接続開始要求受信時の動作を説明するフローチャートである。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６におけるコネクション情報要求受信時の動作を説明するフローチャートである。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６における接続終了要求受信時の動作を説明するフローチャートである。 第２の実施の形態のＮＧＮ接続サービスの手順を説明するシーケンス図（１）である。 第２の実施の形態のＮＧＮ接続サービスの手順を説明するシーケンス図（２）である。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ｂにおけるコネクション情報テーブル６０１０の構成の一例を示す説明図である。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ｂにおける端末情報テーブル６０２０の構成の一例を示す説明図である。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ｂにおけるメディアストリーム制御情報テーブル６０３０の構成の一例を示す説明図である。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６における着信通知受信時の動作を説明するフローチャートである。 第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６における切断通知受信時の動作を説明するフローチャートである。 ｗｅｂサーバ１の構成図である。 第３の実施の形態の第１シーケンス図（１）である。 第３の実施の形態の第１シーケンス図（２）である。 第３の実施の形態の第１シーケンス図（３）である。 第３の実施の形態の第１シーケンス図（４）である。 第３の実施の形態の第２シーケンス図（１）である。 第３の実施の形態の第２シーケンス図（２）である。 第３の実施の形態の第２シーケンス図（３）である。 第３の実施の形態の第２シーケンス図（４）である。 第３の実施の形態の第３シーケンス図（１）である。 第３の実施の形態の第３シーケンス図（２）である。 第３の実施の形態の第３シーケンス図（３）である。 第３の実施の形態の第３シーケンス図（４）である。 第３の実施の形態の第４シーケンス図（１）である。 第３の実施の形態の第４シーケンス図（２）である。 第３の実施の形態の第４シーケンス図（３）である。 第３の実施の形態の第４シーケンス図（４）である。 第３の実施の形態の第５シーケンス図（１）である。 第３の実施の形態の第５シーケンス図（２）である。 第３の実施の形態の第５シーケンス図（３）である。 第３の実施の形態の第５シーケンス図（４）である。 第４の実施の形態の第１シーケンス図（１）である。 第４の実施の形態の第１シーケンス図（２）である。 第４の実施の形態の第１シーケンス図（３）である。 第４の実施の形態の第１シーケンス図（４）である。 第４の実施の形態の第２シーケンス図（１）である。 第４の実施の形態の第２シーケンス図（２）である。 第４の実施の形態の第２シーケンス図（３）である。 第４の実施の形態の第２シーケンス図（４）である。 第３の実施の形態の概要を示す説明図である。 第３の実施の形態の通信網の構成例を示す説明図である。 呼制御装置の構成図である。

１．第１の実施の形態
（ネットワーク構成）
図１は、第１の実施の形態の通信網の構成例を示す説明図である。
本通信網（システム）は、例えば、Ｗｅｂサーバ１と、ＳＯＡＰ−ＳＩＰアダプタ２と、ＳＩＰサーバ３と、ＨＧＷ（Ｈｏｍｅ Ｇａｔｅｗａｙ）４ａ及び４ｂとを備える。ＳＩＰサーバ３は、例えばＮＧＮ Ｎ２に設置される。
Ｗｅｂサーバ１は、ＳＯＡＰ−ＳＩＰアダプタ２と通信する。また、Ｗｅｂサーバ１は、インターネットＮ１等のネットワークを介して端末５ａと通信する。ＳＯＡＰ−ＳＩＰアダプタ２は、ＮＧＮ Ｎ２とＨＧＷ４ａを介して端末Ａ５ｂと通信する。ＳＯＡＰ−ＳＩＰアダプタ２と端末Ｂ５ｃについても同様である。
図２は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２の構成例を示す説明図である。
ＳＯＡＰ−ＳＩＰアダプタ２は、例えば、プロセッサ（以下、ＣＰＵ）２００１と、インタフェース（以下、ＩＦ）２００３ａ及び２００３ｂと、メモリ２００４とを備える。メモリ２００４は、ＳＯＡＰ制御部２１０１と、３ＰＣＣモジュール部２１０２と、メディアストリーム制御部２１０３と、ＳＩＰ制御部２１０４とを有する。３ＰＣＣモジュール部２１０２は、セッション情報テーブル２０１０を有し、メディアストリーム制御部２１０３は、メディアストリーム制御情報テーブル２０４０を有する。セッション情報テーブル２０１０は、呼参加者情報テーブル２０２０と、端末情報テーブル２０３０とを有する。
ＣＰＵ２００１は、ＳＯＡＰ−ＳＩＰアダプタ２における各処理を実行する。メモリ２００４上のＳＯＡＰ制御部２１０１、３ＰＣＣモジュール部２１０２、メディアストリーム制御部２１０３及びＳＩＰ制御部２１０４は、ＣＰＵ２００１により実行される。ＩＦ２００３は、回線２００２を介してＷｅｂサーバ１やＮＧＮ Ｎ２と通信するためのインタフェースである。
図３−１は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２におけるセッション情報テーブル２０１０の構成の一例を示す説明図である。
セッション情報テーブル２０１０は、例えば、ｓｅｓｓｉｏｎＩＤ２０１１に対応して、セッション状態２０１２と、呼参加者状態２０２０と、端末情報２０３０とを記憶する。
ｓｅｓｓｉｏｎＩＤ２０１１は、Ｗｅｂサーバ１からの接続要求に対応するセッション識別子である。ｓｅｓｓｉｏｎＩＤ２０１１は、端末Ａ５ｂと端末Ｂ５ｃとの通信を識別する。セッション状態２０１２は、ｓｅｓｓｉｏｎＩＤ２０１１が示すセッションの状態を示す。セッション状態２０１２は、例えば、「Ｉｎｉｔｉａｌ（初期状態）」、「Ｃｏｎｎｅｃｔｅｄ（接続状態）」、「Ｔｅｒｍｉｎａｔｅｄ（終了状態）」等が記憶される。呼参加者状態２０２０は、呼参加者情報テーブル２０２０に相当する。呼参加者情報テーブル２０２０の詳細については、後述する。端末情報２０３０は、端末情報テーブル２０３０に相当する。端末情報２０３０は、端末毎にそれぞれ記憶される。図示の例では、端末Ａ５ｂに対応する端末情報（Ｃｌｉｅｎｔ Ａ用）２０３０＿Ａと、端末Ｂ５ｃに対応する端末情報（Ｃｌｉｅｎｔ Ｂ用）２０３０＿Ｂとが記憶される。端末情報テーブル２０３０の詳細については、後述する。
図３−２は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼参加者情報テーブル２０２０の構成の一例を示す説明図である。
呼参加者情報テーブル２０２０は、例えば、端末毎に、ＵＲＩ２０２１と呼状態２０２２と開始時間（時刻）２０２３とを記憶する。
ＵＲＩ２０２１は、各ユーザに対応するＳＩＰ−ＵＲＩを示す。呼状態２０２２は、ＳＯＡＰ−ＳＩＰアダプタ２と各端末５ｂ、５ｃとの間のＳＩＰのセッションの状態を示す。呼状態２０２２は、例えば、「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＩｎｉｔｉａｌ（初期状態）」、「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＣｏｎｎｅｃｔｅｄ（接続状態）」、「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＴｅｒｍｉｎａｔｅｄ（終了状態）」等が記憶される。開始時間２０２３は、ＳＯＡＰ−ＳＩＰアダプタ２が各端末５ｂ、５ｃに対して、ＳＩＰのセッションを確立したときの時刻を示す。
図３−３は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における端末情報テーブル２０３０の構成の一例を示す説明図である。
端末情報テーブル２０３０は、例えば、ＳＩＰで用いるパラメータ等が記憶される。端末情報テーブル２０３０は、例えば、ハンドル値２０３１と、ｓｅｓｓｉｏｎＩＤ２０３２と、端末状態２０３３と、Ｒｏｌｅ２０３４と、ｓｅｎｄ ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）情報２０３５と、ｒｅｃｖ ＳＤＰ情報２０３６と、Ｆｒｏｍ ＵＲＩ２０３７と、Ｔｏ ＵＲＩ２０３８とを記憶する。
ハンドル値２０３１は、ＳＯＡＰ−ＳＩＰアダプタ２と端末５ｂとの間のＳＩＰのセッション、及び、ＳＯＡＰ−ＳＩＰアダプタ２と端末Ｂ５ｃとの間のＳＩＰのセッションをそれぞれ識別する情報である。ｓｅｓｓｉｏｎＩＤ２０３２は、上述のセッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１に対応する。端末状態２０３３は、ＳＯＡＰ−ＳＩＰアダプタ２と各端末５ｂ、５ｃとのセッション確立に至るまでの状態を示す。端末状態２０３３は、例えば、「Ｉｎｉｔｉａｌ（初期状態）」、「ＣｏｎｎｅｃｔＷａｉｔ（「応答」を待っている状態）」、「ＣａｌｌＣｏｍｐｌｅｔｅ（「応答」を受け付け、ＵＡとのセッションが確立している状態）」、「ＣｌｏｓｅＷａｉｔ（「切断完了通知」を待っている状態）」、「Ｃｌｏｓｅｄ（終了状態）」等が記憶される。なお、「Ｉｎｉｔｉａｌ」、「ＣｏｎｎｅｃｔＷａｉｔ」は、呼参加者情報テーブル２０２０に記憶される呼状態２０２２の「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＩｎｉｔｉａｌ」に対応する。また、「ＣａｌｌＣｏｍｐｌｅｔｅ」、「ＣｌｏｓｅＷａｉｔ」は、呼参加者情報テーブル２０２０に記憶される呼状態２０２２の「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＣｏｎｎｅｃｔｅｄ」に対応する。「ＣｌｏｓｅＷａｉｔ」は、呼状態２０２２の「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＴｅｒｍｉｎａｔｅｄ」に対応する。
Ｒｏｌｅ２０３４は、発信側又は着信側を示す情報である。ｓｅｎｄ ＳＤＰ情報２０３５は、例えば、ＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を含む。ｒｅｃｖ ＳＤＰ情報２０３６は、例えば、端末Ａ５ｂ又は端末Ｂ５ｃのＩＰアドレスとポート番号を含む。Ｆｒｏｍ ＵＲＩ２０３７は、ＳＯＡＰ−ＳＩＰアダプタ２が送信するＳＩＰメッセージの送信元ＵＲＩを示す。Ｆｒｏｍ ＵＲＩ２０３７は、例えばＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ−ＵＲＩである。Ｔｏ ＵＲＩ２０３８は、ＳＯＡＰ−ＳＩＰアダプタ２が送信するＳＩＰメッセージの送信先ＵＲＩを示す。Ｔｏ ＵＲＩ２０３８は、例えば、端末Ａ５ｂ又は端末Ｂ５ｃのＳＩＰ−ＵＲＩである。

図３−４は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２におけるメディアストリーム制御情報テーブル２０４０の構成の一例を示す説明図である。
メディアストリーム制御情報テーブル２０４０は、例えば、ｓｅｓｓｉｏｎＩＤ２０４１に対応して、メディアストリーム送受信用ＩＰアドレス２０４２と、メディアストリーム送受信用ポート番号２０４３と、相手先ＩＰアドレス（１）２０４４と、相手先ポート番号（１）２０４５と、相手先ＩＰアドレス（２）２０４６と、相手先ポート番号（２）２０４７とを記憶する。
ｓｅｓｓｉｏｎＩＤ２０４１は、セッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１と対応する。メディアストリーム送受信用ＩＰアドレス２０４２及びメディアストリーム送受信用ポート番号２０４３は、ＳＯＡＰ−ＳＩＰアダプタ２がメディアストリームを転送する際に用いるＩＦ２００３のＩＰアドレス及びポート番号である。相手先ＩＰアドレス（１）２０４４及び相手先ポート番号（１）２０４５と、相手先ＩＰアドレス（２）２０４６及び相手先ポート番号（２）２０４７の対は、メディアストリームの転送先を示す。例えば、メディアストリームの送信元が相手先ＩＰアドレス（１）２０４４及び相手先ポート番号（１）２０４５に該当する場合、対応する相手先ＩＰアドレス（２）２０４６及び相手先ポート番号（２）２０４７を転送先としてメディアストリームを転送する。メディアストリームの送信元が相手先ＩＰアドレス（２）２０４６及び相手先ポート番号（２）２０４７の場合も同様に、対応する相手先ＩＰアドレス（１）２０４４及び相手先ポート番号（１）２０４５を転送先としてメディアストリームを転送する。図示の例では、相手先ＩＰアドレス（１）２０４４及び相手先ポート番号（１）２０４５は、端末Ａ５ｂのＩＰアドレス及びポート番号を示し、相手先ＩＰアドレス（２）２０４６及び相手先ポート番号（２）２０４７は、端末Ｂ５ｃのＩＰアドレス及びポート番号を示す。
図２４は、ｗｅｂサーバ１の構成図である。
ｗｅｂサーバ１は、例えば、処理部１００と、入力部１１０と、表示部１２０と、記憶部１３０と、通信インタフェース１４０を備える。入力部１１０は、例えば、ＳｅｓｓｉｏｎＩＤの入力やユーザ識別子の入力を受け付ける。表示部１２０は、ユーザ識別子、ＳＩＰ−ＵＲＩを表示する。記憶部１３０は、例えば、受信したＳｅｓｓｉｏｎＩＤを記憶する。通信インタフェース１４０は、例えばＳＯＡＰ−ＳＩＰアダプタ２と通信するためのインタフェースである。処理部１００は、ｗｅｂサーバ１での各種処理を実行する。

（動作）
図１２は、第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図である。図７は、ＳＯＡＰ−ＳＩＰアダプタにおけるｓｅｓｓｉｏｎＩＤ／ｃｏｎｎｅｃｔｉｏｎＩＤ生成を説明するフローチャートである。なお、ｃｏｎｎｅｃｔｉｏｎＩＤについては第２の実施の形態で用いる。図８は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼開始要求受信時の動作を説明するフローチャートである。
本実施の形態によると、通信品質が保証されたＮＧＮ上で３ＰＣＣサービスを提供することが可能となる。
３ＰＣＣサービスまでの流れは、以下の（ａ）〜（ｃ）となる。（ａ）ＳＯＡＰ−ＳＩＰアダプタ２と第１接続端末Ａ５ｂとのセッション確立。（ｂ）ＳＯＡＰ−ＳＩＰアダプタ２と第２接続端末Ｂ５ｃとのセッション確立。（ｃ）第１接続端末Ａ５ｂと第２接続端末Ｂ５ｃ間で通話。しかし、（ａ）が完了し、（ｂ）を開始している段階で、第１接続端末Ａ５ｂでは無音状態となってしまう課題がある。そこで、ＳＯＡＰ−ＳＩＰアダプタ２から擬似的にＲＢＴ（Ｒｉｎｇｉｎｇ Ｂａｃｋ Ｔｏｎｅ、接続維持メッセージ）を第１接続端末Ａ５ｂへ送信し、この課題を解消する。
また、ＮＧＮにおいては、シグナリングチャネルとデータチャネルを確立するＩＰアドレスが同一である必要が条件としてあり、従来の３ＰＣＣサービスフローのように通信させる２者間（第１接続端末Ａ５ｂと第２接続端末Ｂ５ｃ間）のデータチャネル確立代行が不可能となる課題がある。そこで、本実施の形態では、第１接続端末Ａ５ｂからのデータをＳＯＡＰ−ＳＩＰアダプタ２で受信し、そのデータを第２接続端末Ｂ５ｃへ転送する。第２接続端末Ｂ５ｃからのデータをＳＯＡＰ−ＳＩＰアダプタ２で受信し、そのデータを第１接続端末Ａ５ｂへ転送する。また、ＳＯＡＰ−ＳＩＰアダプタ２は、上述の転送を実現するためのメディアストリーム制御情報テーブル２０４０を作成する。

以下、シーケンス図及び各フローチャートに従って本実施の形態の手順を説明する。
まず、第３者のユーザは、端末５ａを操作してＷｅｂサーバ１にログインする。Ｗｅｂサーバ１は、通信するユーザのユーザ識別子（例えば、端末Ａ５ｂ、端末Ｂ５ｃに対応する２者のユーザ名）を端末５ａより入力する。例えば、Ｗｅｂサーバ１が、ログインした端末５ａに対して表示した画面に従い、ユーザの操作により通信する２者のユーザが選択されてもよい。
Ｗｅｂサーバ１は、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（接続要求）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１）。ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔは、接続させたい２者のユーザに対応するＳＩＰ−ＵＲＩを含む。例えば、Ｗｅｂサーバ１は、ユーザ識別子とそのユーザのＳＩＰ−ＵＲＩが対応して予め記憶され、入力されたユーザ識別子に対応するＳＩＰ−ＵＲＩを取得する。Ｗｅｂサーバ１は、取得されたＳＩＰ−ＵＲＩを含むＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔを生成してＳＯＡＰ−ＳＩＰアダプタ２に送信する。
ＳＯＡＰ−ＳＩＰアダプタ２は、受信したＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔに含まれるＳＩＰ−ＵＲＩに対応するそれぞれの端末５ｂ、５ｃに対して接続を開始し、ＳＯＡＰ−ＳＩＰアダプタ２で生成したｓｅｓｓｉｏｎＩＤを含むＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅ送信する（Ｓ２〜Ｓ１５）。以下、ＳＯＡＰ−ＳＩＰアダプタ２におけるステップＳ２〜Ｓ１５の詳細な動作について説明する。
ＳＯＡＰ−ＳＩＰアダプタ２のＳＯＡＰ制御部２１０１は、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔを受信し、接続要求を３ＰＣＣモジュール部２１０２に送信する（Ｓ２）。この接続要求は、例えば、受信したＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔに基づいてＳＯＡＰ−ＳＩＰアダプタ２で用いる適宜のプロトコルに従って生成されることができ、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ内のＳＩＰ−ＵＲＩを含む。

３ＰＣＣモジュール部２１０２は、接続要求を受信すると（７００１、８００１）、ｓｅｓｓｉｏｎＩＤを生成する（８００２）。以下に、図７を参照してｓｅｓｓｉｏｎＩＤの生成について説明する。
３ＰＣＣモジュール部２１０２は、接続要求を受信すると、乱数値を生成する（７００２）。３ＰＣＣモジュール部２１０２は、生成された乱数値がセッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１に登録済みであるか否かを判断する（７００３）。生成された乱数値が既に登録済みの場合（すなわち、既に使用されている場合）、３ＰＣＣモジュール部２１０２はステップ７００２に戻り、以降の処理を繰り返す。一方、生成された乱数値が未登録の場合、３ＰＣＣモジュール部２１０２は、生成したｓｅｓｓｉｏｎＩＤをセッション情報テーブル２０１０に記憶する（７００４）。さらに、３ＰＣＣモジュール部２１０２は、セッション情報テーブル２０１０のセッション状態２０１２を「Ｉｎｉｔｉａｌ（初期状態）」に設定する。
また、３ＰＣＣモジュール部２１０２は、受信した接続要求に含まれるＳＩＰ−ＵＲＩを呼参加者情報テーブル２０２０に記憶する。図３−２に示す呼参加者情報テーブル２０２０の例では、端末Ａ５ｂのＳＩＰ−ＵＲＩ（２０２０＿Ａ参照）と、端末Ｂ５ｃのＳＩＰ−ＵＲＩ（２０２０＿Ｂ参照）が記憶される。３ＰＣＣモジュール部２１０２は、呼参加者情報テーブル２０２０の各端末５ｂ、５ｃに対応する呼状態２０２２を「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＩｎｉｔｉａｌ（初期状態）」にそれぞれ設定する。
さらに、３ＰＣＣモジュール部２１０２は、端末Ａ５ｂ、端末Ｂ５ｃの端末情報を記憶する。具体的には、３ＰＣＣモジュール部２１０２は、生成したｓｅｓｓｉｏｎＩＤを各端末５ｂ、５ｃに対応して端末情報テーブル２０３０に記憶する。また、３ＰＣＣモジュール部２１０２は、受信した接続要求に含まれる各ＳＩＰ−ＵＲＩを、端末情報テーブル２０３０の各端末５ｂ、５ｃに対応するＴｏ ＵＲＩ２０３８にそれぞれ記憶する。３ＰＣＣモジュール部２１０２は、端末情報テーブル２０３０の各端末５ｂ、５ｃに対応する端末状態２０３２を「Ｉｎｉｔｉａｌ（初期状態）」にそれぞれ設定する。３ＰＣＣモジュール部２１０２は、端末情報テーブル２０３０の各端末５ｂ、５ｃに対応するＲｏｌｅ２０３３に、発信側又は着信側を示す情報をそれぞれ設定する。なお、端末５ｂ、５ｃのいずれを発信側とするかは適宜定めることができる。また、３ＰＣＣモジュール部２１０２は、ＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を端末情報テーブル２０３０のｓｅｎｄ ＳＤＰ情報２０３５に記憶する。また、３ＰＣＣモジュール部２１０２は、ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ−ＵＲＩを端末情報テーブル２０３０の各端末５ｂ、５ｃに対応するＦｒｏｍ ＵＲＩ２０３７にそれぞれ記憶する。なお、ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ−ＵＲＩ、ＩＰアドレス及びポート番号は、予め適宜の記憶部に記憶されている。

３ＰＣＣモジュール部２１０２は、接続要求成功応答を生成し、ＳＯＡＰ制御部２１０１に送信する（Ｓ３、８０１１）。接続要求成功応答は、生成したｓｅｓｓｉｏｎＩＤを含む。ＳＯＡＰ制御部２１０１は、接続要求成功応答を受信し、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅ（接続要求成功応答）をＷｅｂサーバ１に送信する（Ｓ４、８０１２）。ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅは生成されたｓｅｓｓｉｏｎＩＤを含み、受信した接続要求成功応答に基づいてＳＯＡＰに従って生成される。Ｗｅｂサーバ１は、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅを受信し、受信したＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅに含まれるｓｅｓｓｉｏｎＩＤを適宜の記憶部に記憶する。
なお、ステップ８００２でｓｅｓｓｉｏｎＩＤの生成に失敗した場合、３ＰＣＣモジュール部２１０２は、接続要求失敗応答（エラーレスポンスメッセージ）を生成し（８０１３）、ＳＯＡＰ制御部２１０１に送信する。ＳＯＡＰ制御部２１０１は、接続要求失敗応答を受信し、接続要求の失敗を示すＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅをＷｅｂサーバ１に送信する（８０１２）。
次に、ＳＯＡＰ−ＳＩＰアダプタ２と端末Ａ５ｂとのセッションを確立する。
より具体的には、３ＰＣＣモジュール部２１０２は、メディアストリーム制御・転送用のポートを取得する（８００３）。３ＰＣＣモジュール部２１０２は、端末Ａ５ｂに対する発信要求（Ａ）をＳＩＰ制御部２１０４に送信する（Ｓ５、８００４）。例えば、３ＰＣＣモジュール部２１０２は、端末情報テーブル２０３０に記憶された端末Ａ５ｂに対応するｓｅｎｄ ＳＤＰ情報２０３５、Ｆｒｏｍ ＵＲＩ２０３７及びＴｏ ＵＲＩ２０３８を含む発信要求をＳＩＰ制御部２１０４に送信する。また、３ＰＣＣモジュール部２１０２は、一例としてこのときの時刻を呼参加者情報テーブル２０２０の端末Ａ５ｂに対応する開始時間２０２３に記憶する。図３−２に示す呼参加者情報テーブル２０２０の例では、「２００８．１０．２２ １０：３０．３０」が記憶される。なお、開始時間２０２３は、このときの時刻に限らず、端末Ａ５ｂとのセッションの開始を示す適宜の時刻を記憶してもよい。
ＳＩＰ制御部２１０４は、発信要求（Ａ）に含まれるＴｏ ＵＲＩに従い、ＩＮＶＩＴＥメッセージ（Ａ）を端末Ａ５ｂに送信する（Ｓ６）。ＩＮＶＩＴＥメッセージ（Ａ）は、例えば、受信した発信要求に含まれる、ｓｅｎｄ ＳＤＰ情報、Ｆｒｏｍ ＵＲＩ、Ｔｏ ＵＲＩを少なくとも含む。また、ＳＩＰ制御部２１０４は、端末Ａ５ｂとのセッションを識別するハンドル値を生成する。
端末Ａ５ｂは、ＩＮＶＩＴＥメッセージ（Ａ）を受信し、受信したＩＮＶＩＴＥメッセージ（Ａ）のｓｅｎｄ ＳＤＰ情報に含まれるＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を適宜の記憶部に記憶する。記憶されたＩＰアドレスとポート番号は、例えばメディアストリームの送信の際に用いられる。また、端末Ａ５ｂは、自身のＩＰアドレスとポート番号を含むｒｅｃｖ ＳＤＰ情報を生成し、生成したＳＤＰ情報を含むＳＩＰの２００ ＯＫ（Ａ）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ７）。ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ制御部２１０４は、２００ ＯＫ（Ａ）を受信し、ＳＩＰのＡＣＫ（Ａ）を端末Ａ５ｂに送信する（Ｓ８）。

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

３ＰＣＣモジュール部２１０２は、擬似ＲＢＴ送信要求をメディアストリーム制御部２１０３に送信する（Ｓ１０１）。メディアストリーム制御部２１０３は、擬似ＲＢＴ送信要求を受信すると、例えばＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）に従い、擬似ＲＢＴを端末Ａ５ｂに送信する（Ｓ１０、８００６）。メディアストリーム制御部２１０３は、例えば相手を呼び出し中である旨のアナウンスや適宜の音楽等を擬似ＲＢＴとして用いてもよい。本実施の形態では、端末Ａ５ｂとのセッションの確立が完了し、端末Ｂ５ｃとのセッションの確立を開始している段階で、端末Ａ５ｂが無音状態となることを防ぐ。なお、この擬似ＲＢＴは、後述する停止要求があるまで送信し続けることができる。
次に、ＳＯＡＰ−ＳＩＰアダプタ２と端末Ｂ５ｃとのセッションを確立する。
３ＰＣＣモジュール部２１０２は、端末Ｂ５ｃに対する発信要求（Ｂ）をＳＩＰ制御部２１０４に送信する（Ｓ１１、８００７）。例えば、３ＰＣＣモジュール部２１０２は、端末情報テーブル２０３０に記憶された端末Ｂ５ｃに対応するｓｅｎｄ ＳＤＰ情報２０３５、Ｆｒｏｍ ＵＲＩ２０３７及びＴｏ ＵＲＩ２０３８を含む発信要求をＳＩＰ制御部２１０４に送信する。また、３ＰＣＣモジュール部２１０２は、このときの時刻を呼参加者情報テーブル２０２０の端末Ｂ５ｃに対応する開始時間２０２３に記憶する。図３−２に示す呼参加者情報テーブル２０２０の例では、「２００８．１０．２２ １０：３０．４５」が記憶される。
ＳＩＰ制御部２１０４は、発信要求（Ｂ）に含まれるＴｏ ＵＲＩに従い、ＩＮＶＩＴＥメッセージ（Ｂ）を端末Ｂ５ｃに送信する（Ｓ１２）。ＩＮＶＩＴＥメッセージ（Ｂ）は、例えば、受信した発信要求に含まれる、ｓｅｎｄ ＳＤＰ情報、Ｆｒｏｍ ＵＲＩ、Ｔｏ ＵＲＩを少なくとも含む。また、ＳＩＰ制御部２１０４は、端末Ｂ５ｃとのセッションを識別するハンドル値を生成する。
端末Ｂ５ｃは、ＩＮＶＩＴＥメッセージ（Ｂ）を受信し、受信したＩＮＶＩＴＥメッセージ（Ｂ）のｓｅｎｄ ＳＤＰ情報に含まれるＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を適宜の記憶部に記憶する。また、端末Ｂ５ｃは、自身のＩＰアドレスとポート番号を含むｒｅｃｖ ＳＤＰ情報を生成し、生成したｒｅｃｖ ＳＤＰ情報を含む２００ ＯＫ（Ｂ）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１３）。ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ制御部２１０４は、２００ ＯＫ（Ｂ）を受信し、ＡＣＫ（Ｂ）を端末Ｂ５ｃに送信する（Ｓ１４）。

ＳＩＰ制御部２１０４は、応答通知（Ｂ）を３ＰＣＣモジュール部２１０２に送信する（Ｓ１５、８００８）。応答通知（Ｂ）は、例えば、ステップＳ１２で生成したハンドル値と、ステップＳ１３で受信した２００ ＯＫに含まれる端末Ｂ５ｃのｒｅｃｖ ＳＤＰ情報とを含む。３ＰＣＣモジュール部２１０２は、受信した応答通知（Ｂ）に含まれるハンドル値及びｒｅｃｖ ＳＤＰ情報を、端末情報テーブル２０３０に端末Ｂ５ｃに対応して記憶する。なお、ハンドル値は、ステップＳ１２〜Ｓ１４の間の適宜のタイミングで記憶されてもよい。３ＰＣＣモジュール部２１０２は、端末情報テーブル２０３０の端末Ｂ５ｃに対応する端末状態２０３３を「ＣａｌｌＣｏｍｐｌｅｔｅ（セッション確立状態）」に更新する、また、３ＰＣＣモジュール部２１０２は、呼参加者情報テーブル２０２０の端末Ｂ５ｃに対応する呼状態２０２２を「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＣｏｎｎｅｃｔｅｄ（接続状態）」に更新する。また、３ＰＣＣモジュール部２１０２は、セッション情報テーブル２０１０のセッション状態を「Ｃｏｎｎｅｃｔｅｄ（接続状態）」に更新する。
３ＰＣＣモジュール部２１０２は、ｓｅｓｓｉｏｎＩＤと、受信したｒｅｃｖ ＳＤＰ情報に含まれる端末Ｂ５ｃのＩＰアドレス及びポート番号をメディアストリーム制御部２１０３に送信する。メディアストリーム制御部２１０３は、受信したｓｅｓｓｉｏｎＩＤに対応して、端末Ｂ５ｃのＩＰアドレス及びポート番号をメディアストリーム制御情報テーブル２０４０の相手先ＩＰアドレス（２）２０４６、相手先ポート番号（２）２０４７に記憶する。
３ＰＣＣモジュール部２１０２は、擬似ＲＢＴ停止要求をメディアストリーム制御部２１０３に送信する（Ｓ１０２、８００９）。メディアストリーム制御部２１０３は、擬似ＲＢＴ停止要求に従い擬似ＲＢＴの送信を停止する。
ＳＯＡＰ−ＳＩＰアダプタ２は、端末Ａ５ｂと端末Ｂ５ｃとの間でメディアストリーム転送を開始する（８０１０）。

例えば、端末Ａ５ｂは、ＲＴＰに従い、メディアストリームをＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１６）。このとき、端末Ａ５ｂは、ステップＳ６で記憶したＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を宛先に設定し、自身のＩＰアドレスとポート番号を送信元に設定する。
ＳＯＡＰ−ＳＩＰアダプタ２のメディアストリーム制御部２１０３は、受信したメディアストリームを、メディアストリーム制御情報テーブル２０４０を参照して端末Ｂ５ｃに転送する（Ｓ１７）。例えば、メディアストリーム制御部２１０３は、受信したメディアストリームの送信元ＩＰアドレスとポート番号に基づいてメディアストリーム制御情報テーブル２０４０を参照し、対応する相手先ＩＰアドレスとポート番号を取得する。図３−４に示すメディアストリーム制御情報テーブル２０４０の例では、受信したメディアストリームの送信元ＩＰアドレスとポート番号は、端末Ａ５ｂのＩＰアドレス（１０．０．２．１）、ポート番号（２００００）であり、対応する相手先ＩＰアドレス（２）２０４６（１０．０．２．２）とポート番号（２）２０４７（３００００）が取得される。メディアストリーム制御部２１０３は、取得したＩＰアドレスとポート番号に従い、受信したメディアストリームを端末Ｂ５ｃに転送する。
同様に、端末Ｂ５ｃは、ＲＴＰに従い、メディアストリームをＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１８）。端末Ａ５ｂの場合と同様に、端末Ｂ５ｃは、ステップＳ１２で記憶したＳＯＡＰ−ＳＩＰアダプタ２のＩＰアドレスとポート番号を宛先に設定し、自身のＩＰアドレスとポート番号を送信元に設定する。
ＳＯＡＰ−ＳＩＰアダプタ２のメディアストリーム制御部２１０３は、受信したメディアストリームを、メディアストリーム制御情報テーブル２０４０を参照して端末Ａ５ｂに転送する（Ｓ１９）。図３−４に示すメディアストリーム制御情報テーブル２０４０の例では、受信したメディアストリームの送信元ＩＰアドレスとポート番号は、端末Ｂ５ｃのＩＰアドレス（１０．０．２．２）、ポート番号（３００００）であり、対応する相手先ＩＰアドレス（１）２０４４（１０．０．２．１）とポート番号（１）２０４５（２００００）が取得される。メディアストリーム制御部２１０３は、取得したＩＰアドレスとポート番号に従い、受信したデータストリームを端末Ａ５ｂに転送する。
以上のように、シグナリングチャネルを確立するＩＰアドレスと、データチャネルを確立するＩＰアドレスとが同一となり、端末Ａ５ｂからのデータをＳＯＡＰ−ＳＩＰアダプタ２で受信し、そのデータを端末Ｂ５ｃへ転送して、また、端末Ｂ５ｃからのデータをＳＯＡＰ−ＳＩＰアダプタ２で受信し、そのデータを端末Ａ５ｂへ転送することで、通信品質が保証されたＮＧＮ上で３ＰＣＣサービスが可能となる。

図１３は、第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図（２）である。図９は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼情報（セッション情報）要求受信時の動作を説明するフローチャートである。
図１３、図９を参照して、Ｗｅｂサーバ１が呼情報を取得する動作について説明する。ここでは、Ｗｅｂサーバ１は、指定したｓｅｓｓｉｏｎＩＤに対応する情報を取得できる。図１３のステップＳ２１〜Ｓ２４の処理は、上述のステップＳ１６〜Ｓ１９の処理に対応する。
Ｗｅｂサーバ１は、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔ（セッション情報要求、呼情報要求）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ２５）。ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔは、取得したい呼情報のｓｅｓｓｉｏｎＩＤを含む。より具体的には、Ｗｅｂサーバ１は、上述のステップＳ４で記憶されたｓｅｓｓｉｏｎＩＤを含むＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔを生成し、ＳＯＡＰ−ＳＩＰアダプタ２に送信する。なお、Ｗｅｂサーバ１は、端末５ａより、ユーザ操作に基づいて上述のステップＳ４で記憶されたｓｅｓｓｉｏｎＩＤから取得したい呼情報のｓｅｓｓｉｏｎＩＤを選択してもよい。
ＳＯＡＰ−ＳＩＰアダプタ２は、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔに含まれるｓｅｓｓｉｏｎＩＤをキーにＳＯＡＰ−ＳＩＰアダプタ２で保持しているセッション情報テーブル２０１０を検索し、一致するｓｅｓｓｉｏｎＩＤ２０１１のテーブル情報を含むＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅを送信する（Ｓ２６〜Ｓ２８）。以下、ＳＯＡＰ−ＳＩＰアダプタ２におけるステップＳ２６〜Ｓ２８の詳細な動作について説明する。

まず、ＳＯＡＰ−ＳＩＰアダプタ２のＳＯＡＰ制御部２１０１は、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔを受信し、セッション情報要求を３ＰＣＣモジュール部２１０２に送信する（Ｓ２６）。このセッション情報要求は、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔ内のｓｅｓｓｉｏｎＩＤを含む。
３ＰＣＣモジュール部２１０２は、セッション情報要求を受信すると（９００１）、受信したセッション情報要求に含まれるｓｅｓｓｉｏｎＩＤに基づいてセッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１を検索する（９００２）。受信したセッション情報要求に含まれるｓｅｓｓｉｏｎＩＤがセッション情報テーブル２０１０に登録済みの場合、該当したｓｅｓｓｉｏｎＩＤ２０１１に対応するセッション情報が特定される（９００３）。３ＰＣＣモジュール部２１０２は、該当したｓｅｓｓｉｏｎＩＤ２０１１に対応する呼参加者情報テーブル（呼参加者状態）２０２０を参照して、例えば各端末５ｂ、５ｃに対応するＵＲＩ２０２１及び呼状態２０２２を、それぞれ取得する（９００４）。さらに、３ＰＣＣモジュール部２１０２は、例えば該当したｓｅｓｓｉｏｎＩＤ２０１１に対応する端末情報（Ｃｌｉｅｎｔ Ａ用）２０３０＿Ａ及び端末情報（Ｃｌｉｅｎｔ Ｂ用）２０３０＿Ｂより、各端末のｒｅｃｖ ＳＤＰ情報２０３６をそれぞれ取得する。
３ＰＣＣモジュール部２１０２は、ｓｅｓｓｉｏｎＩＤ２０１１、取得したＵＲＩ２０２１、呼状態２０２２及びｒｅｃｖ ＳＤＰ情報２０３６を含むセッション情報要求成功応答を生成し（９００５）、生成したセッション情報要求成功応答をＳＯＡＰ制御部２１０１に送信する（Ｓ２７）。ＳＯＡＰ制御部２１０１は、セッション情報要求成功応答を受信し、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅ（セッション情報要求成功応答）をＷｅｂサーバ１に送信する（Ｓ２８、９００６）。ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅは、受信したセッション情報要求成功応答内のｓｅｓｓｉｏｎＩＤ、ＵＲＩ、呼状態及びｒｅｃｖ ＳＤＰ情報を含み、ＳＯＡＰに従って生成される。
なお、ステップ９００２において、受信したセッション情報要求に含まれるｓｅｓｓｉｏｎＩＤが未登録の場合、３ＰＣＣモジュール部２１０２は、セッション情報要求失敗応答（エラーレスポンスメッセージ）を生成し（９００７）、生成したセッション情報要求失敗応答をＳＯＡＰ制御部２１０１に送信する。ＳＯＡＰ制御部２１０１は、セッション情報要求失敗応答を受信し、セッション情報要求の失敗を示すＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅをＷｅｂサーバ１に送信する（９００６）。

Ｗｅｂサーバ１は、ＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅを受信し、例えば受信したＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅに含まれる呼状態を参照することで、要求した通信が成立したかなどセッションの状態を確認できる。また、例えば、端末から呼を終了した場合、呼状態が「ＣａｌｌＰａｒｔｉｃｉｐａｎｔＴｅｒｍｉｎａｔｅｄ（終了状態）」となり、Ｗｅｂサーバ１は、端末Ａ５ｂ又は端末Ｂ５ｃから呼が終了されたと判断できる。また、例えば、呼状態が正常でない場合、Ｗｅｂサーバ１は、例えば後述するＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔを用いて通信を停止させてもよい。
図１４は、第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図（３）である。図１０は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼参加者情報要求受信時の動作を説明するフローチャートである。
図１４、図１０を参照して、Ｗｅｂサーバ１が呼参加者情報を取得する動作について説明する。ここでは、指定したＳＩＰ−ＵＲＩに対応するユーザの情報を取得できる。図１４のステップＳ３１〜Ｓ３４の処理は、上述のステップＳ１６〜Ｓ１９の処理に対応する。
Ｗｅｂサーバ１は、ＳＯＡＰ ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔ（呼参加者情報要求）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ３５）。ＳＯＡＰ ｇｅｔＣａｌｌＰａｒｔｉｃｉｐａｎｔｓＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔは、取得したい呼参加者情報のｓｅｓｓｉｏｎＩＤとＵＲＩを含む。具体的には、例えば、Ｗｅｂサーバ１は、上述のステップＳ４で記憶されたｓｅｓｓｉｏｎＩＤと、所望の呼参加者のＳＩＰ−ＵＲＩを含むＳＯＡＰ ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔを生成し、ＳＯＡＰ−ＳＩＰアダプタ２に送信する。一例として、Ｗｅｂサーバ１は、端末５ａより、ユーザ操作に基づいて取得したい呼情報のｓｅｓｓｉｏｎＩＤとユーザ識別子（例えば、端末Ａ５ｂ、端末Ｂ５ｃに対応するユーザ名）を選択してもよい。なお、Ｗｅｂサーバ１は、上述のようにユーザ識別子とそのユーザのＳＩＰ−ＵＲＩが対応して予め記憶され、入力されたユーザ識別子に対応するＳＩＰ−ＵＲＩを取得できる。

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

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

図１５は、第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図（４）である。図１１は、第１の実施の形態のＳＯＡＰ−ＳＩＰアダプタ２における呼終了要求受信時の動作を説明するフローチャートである。
図１５、図１１は、Ｗｅｂサーバ１が呼終了する動作について説明する。図１５のステップＳ４１〜Ｓ４４の処理は、上述のステップＳ１６〜Ｓ１９の処理に対応する。
Ｗｅｂサーバ１は、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（呼終了要求）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ４５）。ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔは、呼終了したい呼のｓｅｓｓｉｏｎＩＤを含む。より具体的には、Ｗｅｂサーバ１は、上述のステップＳ４で記憶されたｓｅｓｓｉｏｎＩＤを含むＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔを生成し、ＳＯＡＰ−ＳＩＰアダプタ２に送信する。一例として、Ｗｅｂサーバ１は、端末５ａより、ユーザ操作に基づいて上述のステップＳ４で記憶されたｓｅｓｓｉｏｎＩＤから呼終了したい呼のｓｅｓｓｉｏｎＩＤを選択してもよい。
ＳＯＡＰ−ＳＩＰアダプタ２は、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔに含まれるｓｅｓｓｉｏｎＩＤをキーにＳＯＡＰ−ＳＩＰアダプタ２で保持しているセッション情報テーブル２０１０を検索し、一致するｓｅｓｓｉｏｎＩＤ２０１１のテーブル情報から切断する端末５ｂ、５ｃを特定して切断する（Ｓ４６〜Ｓ５６）。以下、ＳＯＡＰ−ＳＩＰアダプタ２におけるステップＳ４６〜Ｓ５６の詳細な動作について説明する。

ＳＯＡＰ−ＳＩＰアダプタ２のＳＯＡＰ制御部２１０１は、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（呼終了要求）を受信し、呼終了要求を３ＰＣＣモジュール部２１０２に送信する（Ｓ４６）。この呼終了要求は、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ内のｓｅｓｓｉｏｎＩＤを含む。３ＰＣＣモジュール部２１０２は、呼終了要求を受信すると（１１０１）、受信した呼終了要求に含まれるｓｅｓｓｉｏｎＩＤに基づいてセッション情報テーブル２０１０のｓｅｓｓｉｏｎＩＤ２０１１を検索する（１１０２）。
受信した呼終了要求に含まれるｓｅｓｓｉｏｎＩＤがセッション情報テーブル２０１０に登録済みの場合、３ＰＣＣモジュール部２１０２は、呼終了要求成功応答を生成し（１１０９）、生成した呼終了要求成功応答をＳＯＡＰ制御部２１０１に送信する（Ｓ４７）。ＳＯＡＰ制御部２１０１は、呼終了要求成功応答を受信し、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅ（呼終了要求成功応答）をＷｅｂサーバ１に送信する（Ｓ４８、１１１０）。なお、ＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅは、成功応答のみが送信されてもよい。
また、該当したｓｅｓｓｉｏｎＩＤ２０１１によりセッション情報を特定し、通話中の２者（ここでは端末Ａ５ｂ、端末Ｂ５ｃ）を特定する（１１０３）。例えば、３ＰＣＣモジュール部２１０２は、受信した呼終了要求に含まれるｓｅｓｓｉｏｎＩＤに対応する呼参加者情報テーブル２０２０を参照し、各端末Ａ５ｂ、端末Ｂ５ｃのＳＩＰ−ＵＲＩ２０２１をそれぞれ取得する。メディアストリーム制御部２１０３は、メディアストリームの転送を停止する（１１０４）。なお、３ＰＣＣモジュール部２１０２から、メディアストリーム転送停止要求をメディアストリーム制御部２１０３に送信してもよい。
３ＰＣＣモジュール部２１０２は、取得されたＳＩＰ−ＵＲＩの一方に従い、取得されたＳＩＰ−ＵＲＩを含む切断要求（Ａ）をＳＩＰ制御部２１０４に送信する（Ｓ４９、１１０５）。ＳＩＰ制御部２１０４は、切断要求（Ａ）を受信し、受信した切断要求（Ａ）に含まれるＳＩＰ−ＵＲＩをＴｏ ＵＲＩとして、ＳＩＰのＢＹＥメッセージ（Ａ）を端末Ａ５ｂに送信する（Ｓ５０）。

同様に、３ＰＣＣモジュール部２１０２は、取得されたＳＩＰ−ＵＲＩの他方に従い、取得されたＳＩＰ−ＵＲＩを含む切断要求（Ｂ）をＳＩＰ制御部２１０４に送信する（Ｓ５１、１１０６）。ＳＩＰ制御部２１０４は、切断要求（Ｂ）を受信し、受信した切断要求（Ｂ）に含まれるＳＩＰ−ＵＲＩをＴｏ ＵＲＩとしてＢＹＥメッセージ（Ｂ）を端末Ｂ５ｃに送信する（Ｓ５２）。
端末Ａ５ｂは、ステップＳ５０において受信したＢＹＥメッセージ（Ａ）に対する２００ ＯＫ（Ａ）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ５３）。ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ制御部２１０４は、２００ ＯＫ（Ａ）を受信し、切断完了通知（Ａ）を３ＰＣＣモジュール部２１０２に送信する（Ｓ５４、１１０７）。
同様に、端末Ｂ５ｃは、ステップＳ５２において受信したＢＹＥメッセージ（Ｂ）に対する２００ ＯＫ（Ｂ）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ５５）。ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ制御部２１０４は、２００ ＯＫ（Ｂ）を受信し、切断完了通知（Ｂ）を３ＰＣＣモジュール部２１０２に送信する（Ｓ５６、１１０８）。
なお、ステップ１１０２において、受信した呼終了要求に含まれるｓｅｓｓｉｏｎＩＤが未登録の場合、３ＰＣＣモジュール部２１０２は、呼終了要求失敗応答（エラーレスポンスメッセージ）を生成し（１１１１）、生成した呼終了要求失敗応答をＳＯＡＰ制御部２１０１に送信する。ＳＯＡＰ制御部２１０１は、呼終了要求失敗応答を受信し、呼終了要求の失敗を示すＳＯＡＰ ｅｎｄＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅをＷｅｂサーバ１に送信する（１１１０）。

２．第２の実施の形態
（ネットワーク構成）
図４は、第２の実施の形態の通信網の構成例を示す説明図である。
本実施の形態の通信網（システム）は、例えば、ＳＩＰサーバ３と、ＳＯＡＰ−ＳＩＰアダプタ６ａ及び６ｂを備える。ＳＩＰサーバ３は、ＮＧＮ Ｎ２に設置されている。
ＳＯＡＰ−ＳＩＰアダプタ６ａは、ＮＧＮ Ｎ２を介してＳＯＡＰ−ＳＩＰアダプタ６ｂと通信する。また、端末Ａ７ａと端末Ｂ７ｂは、ＳＯＡＰ−ＳＩＰアダプタ６ａ及びＳＯＡＰ−ＳＩＰアダプタ６ｂを介して通信する。なお、端末７がどのＳＯＡＰ−ＳＩＰアダプタ６に接続されるかは予め定められており、ＳＯＡＰ−ＳＩＰアダプタ６ａと端末Ａ７ａは１対１に対応し、ＳＯＡＰ−ＳＩＰアダプタ６ｂと端末Ｂ７ｂも１対１に対応する。例えば、端末Ｂ７ｂで通信したい場合、ＳＯＡＰ−ＳＩＰアダプタ６ｂを指定すれば端末Ｂ７ｂと通信できる。また、ＳＯＡＰ−ＳＩＰアダプタ６と端末７は１対多でもよく、端末７が接続されるＳＯＡＰ−ＳＩＰアダプタ６の対応関係が適宜の装置に記憶されていてもよい。
図５は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６の構成例を示す説明図である。
本実施の形態のＳＯＡＰ−ＳＩＰアダプタ６は、例えば、第１の実施の形態の３ＰＣＣモジュール部２１０２に換えてＮＧＮ接続モジュール部５１０２を備える。ＮＧＮ接続モジュール部５１０２は、コネクション情報テーブル５０１０を有し、コネクション情報テーブル５０１０は、端末情報テーブル５０２０を有する。ＣＰＵ５００１、ＩＦ５００３ａ及び５００３ｂ、ＳＯＡＰ制御部５１０１、メディアストリーム制御部５１０３、ＳＩＰ制御部５１０４は、第１の実施の形態と同様である。
図６−１は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ａにおけるコネクション情報テーブル５０１０の構成の一例を示す説明図である。
コネクション情報テーブル５０１０は、例えば、ｃｏｎｎｅｃｔｉｏｎＩＤ５０１１に対応して、コネクション状態５０１２と、端末情報５０１３とを記憶する。
ｃｏｎｎｅｃｔｉｏｎＩＤ５０１１は、端末７からの接続要求に対応するコネクションを識別する情報である。例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）でのコネクションを識別する。なお、ｃｏｎｎｅｃｔｉｏｎＩＤ５０１１は、ＳＯＡＰ−ＳＩＰアダプタ６毎にそれぞれ生成される。コネクション状態５０１２は、コネクションの状態を示し、例えば、第１の実施の形態のセッション状態２０１２に相当し、同様の状態が記憶される。端末情報５０１３は、端末情報テーブル５０２０に相当する。

図６−２は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ａにおける端末情報テーブル５０２０の構成の一例を示す説明図である。
端末情報テーブル５０２０は、例えば、ハンドル値５０２１と、ｃｏｎｎｅｃｔｉｏｎＩＤ５０２２と、端末状態５０２３と、ｓｅｎｄ ＳＤＰ情報５０２４と、ｒｅｃｖ ＳＤＰ情報５０２５とＦｒｏｍ ＵＲＩ５０２６と、Ｔｏ ＵＲＩ５０２７とを記憶する。
ハンドル値５０２１は、ＳＯＡＰ−ＳＩＰアダプタ６ａとＳＯＡＰ−ＳＩＰアダプタ６ｂの間のＳＩＰのセッションを識別する情報である。ｃｏｎｎｅｃｔｉｏｎＩＤ５０２２は、上述のコネクション情報テーブル５０１０のｃｏｎｎｅｃｔｉｏｎＩＤ５０１１に対応する。端末状態５０２３は、ＳＯＡＰ−ＳＩＰアダプタ６ａとＳＯＡＰ−ＳＩＰアダプタ６ｂ間のセッションの状態を示す。端末状態５０２３は、例えば、第１の実施の形態の端末状態２０３３と同様の状態が記憶される。ｓｅｎｄ ＳＤＰ情報５０２４は、例えば、ＳＯＡＰ−ＳＩＰアダプタ６自身のＩＰアドレスとポート番号を含む。図６−２に示すＳＯＡＰ−ＳＩＰアダプタ６ａの例では、ＳＯＡＰ−ＳＩＰアダプタ６ａのＩＰアドレス（１０．０．１．１）とポート番号（１００００）を含む。ｒｅｃｖ ＳＤＰ情報５０２５は、例えば、接続先のＳＯＡＰ−ＳＩＰアダプタ６のＩＰアドレスとポート番号を含む。図６−２の例では、ＳＯＡＰ−ＳＩＰアダプタ６ｂのＩＰアドレス（１０．０．２．１）とポート番号（２００００）を含む。Ｆｒｏｍ ＵＲＩ５０２６は、例えば、ＳＯＡＰ−ＳＩＰアダプタ６自身のＳＩＰ−ＵＲＩを示す。図６−２の例では、ＳＯＡＰ−ＳＩＰアダプタ６ａのＳＩＰ−ＵＲＩを示す。Ｔｏ ＵＲＩ５０２７は、例えば、接続先のＳＯＡＰ−ＳＩＰアダプタ６のＳＩＰ−ＵＲＩを示す。図６−２の例では、ＳＯＡＰ−ＳＩＰアダプタ６ｂのＳＩＰ−ＵＲＩを示す。
図６−３は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ａにおけるメディアストリーム制御情報テーブル５０３０の構成の一例を示す説明図である。

本実施の形態のメディアストリーム制御情報テーブル５０３０は、例えば、第１の実施の形態のｓｅｓｓｉｏｎＩＤ２０４１に換えてｃｏｎｎｅｃｔｉｏｎＩＤ５０３１を記憶する。
ｃｏｎｎｅｃｔｉｏｎＩＤ５０３１は、コネクション情報テーブル５０１０のｃｏｎｎｅｃｔｉｏｎＩＤ５０１１に対応する。その他の、メディアストリーム送受信用ＩＰアドレス５０３２、メディアストリーム送受信用ポート番号５０３３、相手先ＩＰアドレス（１）５０３４、相手先ポート番号（１）５０３５、相手先ＩＰアドレス（２）５０３６、相手先ポート番号（２）５０３７は、第１の実施の形態と同様である。なお、本実施の形態におけるＳＯＡＰ−ＳＩＰアダプタ６ａでは、相手先ＩＰアドレス（１）５０３４及び相手先ポート番号（１）５０３５は、ＳＯＡＰ−ＳＩＰアダプタ６ｂのＩＰアドレス及びポート番号が記憶され、相手先ＩＰアドレス（２）５０３６及び相手先ポート番号（２）５０３７は、端末Ａ７ａのＩＰアドレス及びポート番号が記憶される。また、メディアストリーム送受信用ＩＰアドレス５０３２及びメディアストリーム送受信用ポート番号５０３３は、第１の実施の形態と同様に、ＳＯＡＰ−ＳＩＰアダプタ６ａのＩＰアドレス及びポート番号が記憶される。
図２１−１は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ｂにおけるコネクション情報テーブル６０１０の構成の一例を示す説明図である。図２１−２は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ｂにおける端末情報テーブル６０２０の構成の一例を示す説明図である。図２１−３は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ｂにおけるメディアストリーム制御情報テーブル６０３０の構成の一例を示す説明図である。

ＳＯＡＰ−ＳＩＰアダプタ６ｂにおける各テーブル６０１０、６０２０、６０３０の構成は、上述のＳＯＡＰ−ＳＩＰアダプタ６ａにおける各テーブル５０１０、５０２０、５０３０と同様である。
なお、ＳＯＡＰ−ＳＩＰアダプタ６ｂの端末情報テーブル６０２０では、ｓｅｎｄ ＳＤＰ情報６０２４にＳＯＡＰ−ＳＩＰアダプタ６ｂのＩＰアドレス及びポート番号が記憶され、ｒｅｃｖ ＳＤＰ情報６０２５に接続先のＳＯＡＰ−ＳＩＰアダプタ６ａのＩＰアドレス及びポート番号が記憶される。また、Ｆｒｏｍ ＵＲＩ６０２６は、ＳＯＡＰ−ＳＩＰアダプタ６ｂのＳＩＰ−ＵＲＩ、Ｔｏ ＵＲＩ６０２７は、ＳＯＡＰ−ＳＩＰアダプタ６ａのＳＩＰ−ＵＲＩを示す。
また、メディアストリーム制御情報テーブル６０３０では、相手先ＩＰアドレス（１）６０３４及び相手先ポート番号（１）６０３５は、ＳＯＡＰ−ＳＩＰアダプタ６ａのＩＰアドレス及びポート番号が記憶され、相手先ＩＰアドレス（２）６０３６及び相手先ポート番号（２）６０３７は、端末Ｂ７ｂのＩＰアドレス及びポート番号が記憶される。メディアストリーム送受信用ＩＰアドレス６０３２及びメディアストリーム送受信用ポート番号６０３３は、ＳＯＡＰ−ＳＩＰアダプタ６ｂのＩＰアドレス及びポート番号が記憶される。

（動作）
図１９は、第２の実施の形態のＮＧＮ接続サービスの手順を説明するシーケンス図（１）である。図１６は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６における接続開始要求受信時の動作を説明するフローチャートである。図２２は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６における着信通知受信時の動作を説明するフローチャートである。図１７は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６におけるコネクション情報要求受信時の動作を説明するフローチャートである。
本実施の形態では、ＳＩＰのプロトコルを意識することなく、自端末ともう一方の相手端末とを通信品質が保証されたＮＧＮ上で接続するサービスが可能となる。
既存のアプリケーション端末などはＮＧＮで通信帯域確保を行う為のＳＩＰを実装していないものが多く、ＮＧＮ上での通信が不可能であるといった課題がある。本実施の形態では、一例として端末Ａ７ａの画面上などで通信したい相手を選択することをトリガーに、接続開始要求ＳＯＡＰメッセージをＳＯＡＰ−ＳＩＰアダプタ６に送信することで、ＳＩＰを意識することなく相手端末Ｂ７ｂとの間に通信帯域確保を行うことが可能である。通信帯域確保後は、端末７はこれまで既存のインターネット上と変わらない動作で帯域が確保された通信を行うことが可能である。

以下、端末７が接続を開始する動作について説明する。
ＳＯＡＰ−ＳＩＰアダプタ６ａに接続されている端末Ａ７ａは、例えば起動の際ＳＯＡＰ−ＳＩＰアダプタ６ａ間の待受けポートをオープンする（開く）。これにより、端末Ａ７ａとＳＯＡＰ−ＳＩＰアダプタ６ａ間のデータ送受信が可能な状態となる。このとき、ＳＯＡＰ−ＳＩＰアダプタ６ａは、端末Ａ７ａのＩＰアドレスとポート番号を受信し、受信した端末Ａ７ａのＩＰアドレスとポート番号を適宜の記憶部に記憶する。端末Ｂ７ｂ、ＳＯＡＰ−ＳＩＰアダプタ６ｂについても同様である。なお、端末７は、上述の例に限らず、適宜のタイミングで待受けポートをオープンしてもよい。 端末Ａ７ａは、ＳＯＡＰ ｃｏｎｎｅｃｔＲｅｑｕｅｓｔ（接続要求）をＳＯＡＰ−ＳＩＰアダプタ６ａに送信する（Ｓ６１）。ＳＯＡＰ ｃｏｎｎｅｃｔＲｅｑｕｅｓｔは、接続先の端末Ｂ７ｂに対応するＳＯＡＰ−ＳＩＰアダプタ６ｂのＳＩＰ−ＵＲＩを含む。例えば、端末Ａ７ａは、ユーザ操作に基づき、適宜の入力部から接続先のユーザのユーザ識別子又はＳＯＡＰ−ＳＩＰアダプタ６のＳＩＰ−ＵＲＩを選択する。ユーザ識別子を選択する際、例えば、端末Ａ７ａは、ユーザ識別子とそのユーザの端末７が接続されるＳＯＡＰ−ＳＩＰアダプタ６のＳＩＰ−ＵＲＩとが対応して予め記憶され、入力されたユーザ識別子に対応するＳＯＡＰ−ＳＩＰアダプタ６のＳＩＰ−ＵＲＩを特定してもよい。また、ユーザ識別子とそのユーザの端末７が接続されるＳＯＡＰ−ＳＩＰアダプタ６のＳＩＰ−ＵＲＩとが対応して予め記憶されたＷｅｂサーバを設置し、当該Ｗｅｂサーバが、端末Ａ７ａで選択されたユーザ識別子に対応するＳＯＡＰ−ＳＩＰアダプタ６のＳＩＰ−ＵＲＩを返すようにしてもよい。
ＳＯＡＰ−ＳＩＰアダプタ６ａのＳＯＡＰ制御部５１０１ａは、ＳＯＡＰ ｃｏｎｎｅｃｔＲｅｑｕｅｓｔを受信し、接続要求（Ｂ）をＳＯＡＰ−ＳＩＰアダプタ６ａのＮＧＮ接続モジュール部５１０２ａに送信する（Ｓ６２）。この接続要求（Ｂ）は、ＳＯＡＰ ｃｏｎｎｅｃｔＲｅｑｕｅｓｔ内のＳＩＰ−ＵＲＩを含む。ＳＯＡＰ−ＳＩＰアダプタ６ａは、このＳＩＰ−ＵＲＩに対して接続を開始する。
具体的には、まず、ＮＧＮ接続モジュール部５１０２ａは、接続要求（Ｂ）を受信すると（１６０１）、ｃｏｎｎｅｃｔｉｏｎＩＤを生成する（１６０２）。ｃｏｎｎｅｃｔｉｏｎＩＤの生成については、第１の実施の形態の図７及びその説明と同様である。なお、図７の説明と一部重複するが、図６−１、図６−２を参照して本実施の形態について説明すると、ＮＧＮ接続モジュール部５１０２ａは、生成したｃｏｎｎｅｃｔｉｏｎＩＤをコネクション情報テーブル５０１０と端末情報テーブル５０２０にそれぞれ記憶する。ＮＧＮ接続モジュール部５１０２ａは、コネクション情報テーブル５０１０のコネクション状態５０１２を「Ｉｎｉｔｉａｌ（初期状態）」に設定する。さらに、ＮＧＮ接続モジュール部５１０２ａは、受信した接続要求（Ｂ）に含まれるＳＩＰ−ＵＲＩを端末情報テーブル５０２０のＴｏ ＵＲＩ５０２７に記憶する。

また、ＮＧＮ接続モジュール部５１０２ａは、端末情報テーブル５０２０の端末状態５０２３を「Ｉｎｉｔｉａｌ（初期状態）」に設定する。ＮＧＮ接続モジュール部５１０２ａは、ＳＯＡＰ−ＳＩＰアダプタ６ａのＩＰアドレスとポート番号を含むｓｅｎｄ ＳＤＰ情報５０２４を端末情報テーブル５０２０に記憶する。また、ＮＧＮ接続モジュール部５１０２ａは、ＳＯＡＰ−ＳＩＰアダプタ６ａのＳＩＰ−ＵＲＩを端末情報テーブル５０２０のＦｒｏｍ ＵＲＩ５０２６に記憶する。なお、ＳＯＡＰ−ＳＩＰアダプタ６ａのＳＩＰ−ＵＲＩ、ＩＰアドレス及びポート番号は、予め適宜の記憶部に記憶されている。
ＮＧＮ接続モジュール部５１０２ａは、接続成功応答（Ｂ）を生成し（１６０７）、生成した接続成功応答（Ｂ）をＳＯＡＰ制御部５１０１ａに送信する（Ｓ６３）。接続成功応答（Ｂ）は、生成したｃｏｎｎｅｃｔｉｏｎＩＤを含む。ＳＯＡＰ制御部５１０１ａは、接続成功応答（Ｂ）を受信し、ＳＯＡＰ ｃｏｎｎｅｃｔＲｅｓｐｏｎｓｅ（接続成功応答）を端末Ａ７ａに送信する（Ｓ６４、１６０８）。ＳＯＡＰ ｃｏｎｎｅｃｔＲｅｓｐｏｎｓｅは、受信した接続成功応答（Ｂ）内のｃｏｎｎｅｃｔｉｏｎＩＤを含み、ＳＯＡＰに従って生成される。端末Ａ７ａは、ＳＯＡＰ ｃｏｎｎｅｃｔＲｅｓｐｏｎｓｅを受信し、受信したＳＯＡＰ ｃｏｎｎｅｃｔＲｅｓｐｏｎｓｅに含まれるｃｏｎｎｅｃｔｉｏｎＩＤを適宜の記憶部に記憶する。
なお、ステップ１６０２でｃｏｎｎｅｃｔｉｏｎＩＤの生成に失敗した場合、ＮＧＮ接続モジュール部５１０２ａは、接続要求失敗応答（エラーレスポンスメッセージ）を生成し（１６０９）、ＳＯＡＰ制御部５１０１ａに送信する。ＳＯＡＰ制御部５１０１ａは、接続要求失敗応答を受信し、接続要求の失敗を示すＳＯＡＰ ｃｏｎｎｅｃｔＲｅｓｐｏｎｓｅを端末Ａ７ａに送信する（１６０８）。

次に、ＳＯＡＰ−ＳＩＰアダプタ６ａは、ＳＯＡＰ−ＳＩＰアダプタ６ｂとセッションを確立する。
まず、ＮＧＮ接続モジュール部５１０２ａは、メディアストリーム制御転送用ポートを取得する（１６０３）。ＮＧＮ接続モジュール部５１０２ａは、発信要求（Ｂ）をＳＯＡＰ−ＳＩＰアダプタ６ａのＳＩＰ制御部５１０４ａに送信する（Ｓ６５、１６０４）。発信要求（Ｂ）は、端末情報テーブル５０２０に記憶されたｓｅｎｄ ＳＤＰ情報５０２４、Ｆｒｏｍ ＵＲＩ５０２６及びＴｏ ＵＲＩ５０２７を含む。
ＳＩＰ制御部５１０４ａは、発信要求（Ｂ）を受信し、受信した発信要求（Ｂ）に含まれるＴｏ ＵＲＩに従い、ＳＩＰのＩＮＶＩＴＥメッセージ（Ｂ）をＳＯＡＰ−ＳＩＰアダプタ６ｂに送信する（Ｓ６６）。ＩＮＶＩＴＥメッセージ（Ｂ）は、例えば、受信した発信要求（Ｂ）内のｓｅｎｄ ＳＤＰ情報、Ｆｒｏｍ ＵＲＩ、Ｔｏ ＵＲＩを少なくとも含む。また、ＳＩＰ制御部５１０４ａは、ＳＯＡＰ−ＳＩＰアダプタ６ｂとのＳＩＰのセッションを識別するハンドル値を生成する。
以下、ＳＯＡＰ−ＳＩＰアダプタ６ｂ側の各部の動作を説明する。
ＳＯＡＰ−ＳＩＰアダプタ６ｂのＳＩＰ制御部５１０４ｂは、ＩＮＶＩＴＥメッセージ（Ｂ）を受信し、着信通知（Ａ）をＳＯＡＰ−ＳＩＰアダプタ６ｂのＮＧＮ接続モジュール部５１０２ｂに送信する（Ｓ６７）。着信通知（Ａ）は、受信したＩＮＶＩＴＥメッセージ（Ｂ）内のｓｅｎｄ ＳＤＰ情報、Ｆｒｏｍ ＵＲＩ、Ｔｏ ＵＲＩを含む。
ＮＧＮ接続モジュール部５１０２ｂは、着信通知（Ａ）を受信すると（１９０１）、ｃｏｎｎｅｃｔｉｏｎＩＤを生成する（１９０２）。本実施の形態では、ＳＯＡＰ−ＳＩＰアダプタ６ａとＳＯＡＰ−ＳＩＰアダプタ６ｂで独立してｃｏｎｎｅｃｔｉｏｎＩＤが生成される。なお、ｃｏｎｎｅｃｔｉｏｎＩＤの生成については、上述のステップ１６０２と同様である。ＮＧＮ接続モジュール部５１０２ｂは、生成したｃｏｎｎｅｃｔｉｏｎＩＤをコネクション情報テーブル６０１０と端末情報テーブル６０２０にそれぞれ記憶する。ＮＧＮ接続モジュール部５１０２ｂは、コネクション情報テーブル６０１０のコネクション状態６０１２を設定する。例えば、コネクション状態６０１２を「Ｉｎｉｔｉａｌ（初期状態）」又は「Ｃｏｎｎｅｃｔｅｄ（接続状態）」に設定する。なお、「Ｉｎｉｔｉａｌ」又は「Ｃｏｎｎｅｃｔｅｄ」は、適宜のタイミングで変更してもよい。さらに、ＮＧＮ接続モジュール部５１０２ｂは、受信した着信通知（Ａ）に含まれるｓｅｎｄ ＳＤＰ情報を端末情報テーブル６０２０のｒｅｃｖ ＳＤＰ情報６０２５に記憶する。ＮＧＮ接続モジュール部５１０２ｂは、受信した着信通知（Ａ）に含まれるＦｒｏｍ ＵＲＩを端末情報テーブル６０２０のＴｏ ＵＲＩ６０２７に記憶し、同様に、受信した着信通知（Ａ）に含まれるＴｏ ＵＲＩ（すなわち自身のＳＩＰ−ＵＲＩ）をＦｒｏｍ ＵＲＩ６０２６に記憶する。

また、ＮＧＮ接続モジュール部５１０２ｂは、端末情報テーブル６０２０の端末状態６０２３を設定する。例えば、端末状態６０２３を適宜「Ｉｎｉｔｉａｌ（初期状態）」、「ＣａｌｌＣｏｍｐｌｅｔｅ（セッション確立状態）」等に設定する。なお、端末状態６０２３は、適宜変更してもよい。ＮＧＮ接続モジュール部５１０２ｂは、ＳＯＡＰ−ＳＩＰアダプタ６ｂのＩＰアドレスとポート番号を端末情報テーブル６０２０のｓｅｎｄ ＳＤＰ情報６０２４に記憶する。なお、ＳＯＡＰ−ＳＩＰアダプタ６ｂのＩＰアドレスとポート番号は予め適宜の記憶部に記憶されている。また、ＳＩＰ制御部５１０４ｂは、ＳＯＡＰ−ＳＩＰアダプタ６ａとのＳＩＰのセッションを識別するハンドル値を生成し、端末情報テーブル６０２０に記憶する。
ＳＯＡＰ−ＳＩＰアダプタ６ｂのＮＧＮ接続モジュール部５１０２ｂは、メディアストリーム制御転送用ポートを取得する（１９０３）。ＮＧＮ接続モジュール部５１０２ｂは、生成したｃｏｎｎｅｃｔｉｏｎＩＤと、受信した着信通知（Ａ）内のｓｅｎｄ ＳＤＰ情報に含まれるＳＯＡＰ−ＳＩＰアダプタ６ａのＩＰアドレス及びポート番号と、ポートオープンにより記憶された端末Ｂ７ｂのＩＰアドレス及びポート番号とを、メディアストリーム制御部５１０３ｂに送信する。メディアストリーム制御部５１０３ｂは、受信した情報をそれぞれメディアストリーム制御情報テーブル６０３０に記憶する。例えば、メディアストリーム制御部５１０３ｂは、受信したＳＯＡＰ−ＳＩＰアダプタ６ａのＩＰアドレス及びポート番号を相手先ＩＰアドレス（１）６０３４、相手先ポート番号（１）６０３５に記憶し、受信した端末Ｂ７ｂのＩＰアドレス及びポート番号を相手先ＩＰアドレス（２）６０３６、相手先ポート番号（２）６０３７に記憶する。また、メディアストリーム制御部５１０３ｂは、受信したｃｏｎｎｅｃｔｉｏｎＩＤを記憶し、自身のＩＰアドレス及びポート番号をメディアストリーム送受信用ＩＰアドレス６０３２、メディアストリーム送受信用ポート番号６０３３に記憶する。これにより、ＳＯＡＰ−ＳＩＰアダプタ６ｂでは、メディアストリームの転送を開始できる（１９０４）。
ＮＧＮ接続モジュール部５１０２ｂは、応答（Ａ）を生成し、ＳＩＰ制御部５１０４ｂに送信する（Ｓ６８、１９０５）。応答（Ａ）は、端末情報テーブル６０２０に記憶されたｓｅｎｄ ＳＤＰ情報６０２４、Ｆｒｏｍ ＵＲＩ６０２６及びＴｏ ＵＲＩ６０２７を含む。ＳＩＰ制御部５１０４ｂは、応答（Ａ）を受信すると、ＳＩＰの２００ ＯＫ（Ｂ）をＳＯＡＰ−ＳＩＰアダプタ６ａに送信する（Ｓ６９）。２００ ＯＫ（Ｂ）は、例えば、受信した応答（Ａ）内のｓｅｎｄ ＳＤＰ情報、Ｆｒｏｍ ＵＲＩ、Ｔｏ ＵＲＩを少なくとも含む。

なお、上述のステップ１９０２でｃｏｎｎｅｃｔｉｏｎＩＤの生成に失敗した場合、ＮＧＮ接続モジュール部５１０２ｂは、端末Ａ７ａに対応するＳＯＡＰ−ＳＩＰアダプタ６ａとのＳＩＰのセッションを切断する（１９０６）。
ＳＯＡＰ−ＳＩＰアダプタ６ａ側の説明に戻ると、ＳＯＡＰ−ＳＩＰアダプタ６ａのＳＩＰ制御部５１０４ａは、２００ ＯＫ（Ｂ）を受信し、ＳＩＰのＡＣＫ（Ｂ）をＳＯＡＰ−ＳＩＰアダプタ６ｂに送信する（Ｓ７０）。ＳＩＰ制御部５１０４ａは、応答通知（Ｂ）をＮＧＮ接続モジュール部５１０２ａに送信する（Ｓ７１、１６０５）。応答通知（Ｂ）は、ステップＳ６６で生成したハンドル値と、ステップＳ６９で受信した２００ ＯＫ（Ｂ）に含まれるｓｅｎｄ ＳＤＰ情報とを含む。ＮＧＮ接続モジュール部５１０２ａは、受信した応答通知（Ｂ）に含まれるハンドル値を端末情報テーブル５０２０に記憶する。また、ＮＧＮ接続モジュール部５１０２ａは、受信した応答通知（Ｂ）に含まれるｓｅｎｄ ＳＤＰ情報を端末情報テーブル５０２０のｒｅｃｖ ＳＤＰ情報５０２５に記憶する。なお、ハンドル値は、適宜のタイミングで記憶されてもよい。ＮＧＮ接続モジュール部５１０２ａは、端末情報テーブル５０２０の端末状態５０２３を「ＣａｌｌＣｏｍｐｌｅｔｅ（セッション確立状態）」に更新する。また、ＮＧＮ接続モジュール部５１０２ａは、コネクション情報テーブル５０１０のコネクション状態５０１２を「Ｃｏｎｎｅｃｔｅｄ（接続状態）」に更新する。なお、端末状態２０３３は、例えば、ＳＩＰのメッセージ（例えば、２００ ＯＫ等）の送受信に対応して適宜更新してもよい。

ＮＧＮ接続モジュール部５１０２ａは、生成したｃｏｎｎｅｃｔｉｏｎＩＤと、ポートオープンにより記憶された端末Ａ７ａのＩＰアドレス及びポート番号と、受信したｓｅｎｄ ＳＤＰ情報に含まれるＳＯＡＰ−ＳＩＰアダプタ６ｂのＩＰアドレス及びポート番号とをメディアストリーム制御部５１０３ａに送信する。メディアストリーム制御部５１０３ａは、受信した情報をメディアストリーム制御情報テーブル５０３０にそれぞれ記憶する。例えば、メディアストリーム制御部５１０３ａは、受信したＳＯＡＰ−ＳＩＰアダプタ６ｂのＩＰアドレス及びポート番号を相手先ＩＰアドレス（１）５０３４、相手先ポート番号（１）５０３５に記憶し、受信した端末Ａ７ａのＩＰアドレス及びポート番号を相手先ＩＰアドレス（２）５０３６、相手先ポート番号（２）５０３７に記憶する。また、メディアストリーム制御部５１０３ａは、受信したｃｏｎｎｅｃｔｉｏｎＩＤを記憶し、自身のＩＰアドレス及びポート番号をメディアストリーム送受信用ＩＰアドレス５０３２、メディアストリーム送受信用ポート番号５０３３に記憶する。これにより、ＳＯＡＰ−ＳＩＰアダプタ６ａでは、メディアストリームの転送を開始できる（１６０６）。
次に、端末７がコネクション情報を取得する動作について説明する。
端末Ａ７ａは、ＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｑｕｅｓｔ（コネクション情報要求）をＳＯＡＰ−ＳＩＰアダプタ６ａに送信する（Ｓ７２）。ＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｑｕｅｓｔは、取得したい接続情報（コネクション情報）のｃｏｎｎｅｃｔｉｏｎＩＤを含む。より具体的には、端末Ａ７ａは、上述のステップＳ６４で記憶されたｃｏｎｎｅｃｔｉｏｎＩＤを含むＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｑｕｅｓｔを生成する。一例として、端末Ａ７ａは、ステップＳ６４のＳＯＡＰ ｃｏｎｎｅｃｔｉｏｎＲｅｓｐｏｎｓｅを受信後、定期的にステップＳ７２の処理を実行する。
ＳＯＡＰ−ＳＩＰアダプタ６ａは、ＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｑｕｅｓｔに含まれるｃｏｎｎｅｃｔｉｏｎＩＤをキーにＳＯＡＰ−ＳＩＰアダプタ６ａで保持しているコネクション情報テーブル５０１０を検索し、一致するｃｏｎｎｅｃｔｉｏｎＩＤ５０１１のテーブル情報を含むＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｓｐｏｎｓｅを送信する（Ｓ７３〜Ｓ７５）。以下、ＳＯＡＰ−ＳＩＰアダプタ６ａにおけるステップＳ７３〜Ｓ７５の詳細な動作について説明する。

まず、ＳＯＡＰ−ＳＩＰアダプタ６ａのＳＯＡＰ制御部５１０１ａは、ＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｑｕｅｓｔを受信し、コネクション情報要求をＮＧＮ接続モジュール部５１０２ａに送信する（Ｓ７３）。このコネクション情報要求は、ＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｑｕｅｓｔ内のｃｏｎｎｅｃｔｉｏｎＩＤを含む。
ＮＧＮ接続モジュール部５１０２ａは、コネクション情報要求を受信すると（１７０１）、受信したコネクション情報要求に含まれるｃｏｎｎｅｃｔｉｏｎＩＤに基づいてコネクション情報テーブル５０１０のｃｏｎｎｅｃｔｉｏｎＩＤ５０１１を検索する（１７０２）。受信したコネクション情報要求に含まれるｃｏｎｎｅｃｔｉｏｎＩＤがコネクション情報テーブル５０１０に登録済みの場合、該当したｃｏｎｎｅｃｔｉｏｎＩＤ５０１１に対応するコネクション情報が特定される（１７０３）。ＮＧＮ接続モジュール部５１０２ａは、該当したｃｏｎｎｅｃｔｉｏｎＩＤ５０１１に対応するコネクション状態５０１２を取得する（１７０４）。なお、ＮＧＮ接続モジュール部５１０２ａは、コネクション状態５０１２に限らずコネクション情報テーブル５０１０、端末情報テーブル５０２０に記憶された適宜の情報をさらに取得してもよい。
ＮＧＮ接続モジュール部５１０２ａは、取得したコネクション状態５０１２を含むコネクション情報成功応答を生成し（１７０５）、生成したコネクション情報成功応答をＳＯＡＰ制御部５１０１ａに送信する（Ｓ７４）。ＳＯＡＰ制御部５１０１ａは、コネクション情報成功応答を受信し、ＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｓｐｏｎｓｅを端末Ａ７ａに送信する（Ｓ７５、１７０６）。ＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｓｐｏｎｓｅは、受信したコネクション情報成功応答内のコネクション状態を含み、ＳＯＡＰに従って生成される。

なお、ステップ１７０２において、受信したコネクション情報要求に含まれるｃｏｎｎｅｃｔｉｏｎＩＤがコネクション情報テーブル５０１０に未登録の場合、ＮＧＮ接続モジュール部５１０２ａは、コネクション情報失敗応答（エラーレスポンスメッセージ）を生成し（１７０７）、生成したコネクション情報失敗応答をＳＯＡＰ制御部５１０１ａに送信する。ＳＯＡＰ制御部５１０１ａは、コネクション情報失敗応答を受信し、コネクション情報要求の失敗を示すＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｓｐｏｎｓｅを端末Ａ７ａに送信する（１７０６）。
端末Ａ７ａは、ＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｓｐｏｎｓｅを受信し、受信したＳＯＡＰ ｇｅｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｉｓｔＲｅｓｐｏｎｓｅに含まれるコネクション状態を参照することにより、接続の状態を確認できる。これにより、例えばコネクション状態が「Ｃｏｎｎｅｃｔｅｄ（接続状態）」であることを確認すると、端末Ａ７ａと端末Ｂ７ｂでＨＴＴＰに従ったＡＰレベルでのシグナリングを開始し（Ｓ７６〜Ｓ８１）、及び、ＲＴＰに従ったメディアストリームの通信を行う（Ｓ８２〜８７）。
例えば、シグナル及びメディアストリームの転送について、端末Ａ７ａから端末Ｂ７ｂへのメディアストリームについて説明すると、端末Ａ７ａは、ＳＯＡＰ−ＳＩＰアダプタ６ａのＩＰアドレスとポート番号を宛先に設定し、自身のＩＰアドレスとポート番号を送信元に設定し、メディアストリームを送信する（Ｓ８２）。なお、ＳＯＡＰ−ＳＩＰアダプタ６ａのＩＰアドレスとポート番号は、予め適宜の記憶部に記憶されている。
ＳＯＡＰ−ＳＩＰアダプタ６ａのメディアストリーム制御部５１０３ａは、メディアストリーム制御情報テーブル５０３０を参照して、受信したメディアストリームをＳＯＡＰ−ＳＩＰアダプタ６ｂに転送する（Ｓ８３）。転送の動作は第１の実施の形態と同様である。図６−３を参照して本実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ａについて説明すると、受信したメディアストリームの送信元ＩＰアドレスとポート番号は、端末Ａ７ａのＩＰアドレス（１９２．１６８．１０．１）、ポート番号（３００００）であり、対応する相手先ＩＰアドレス（１）５０３４（１０．０．２．１）とポート番号（１）５０３５（２００００）が取得される。ＮＧＮ接続モジュール部５１０２ａは、取得したＩＰアドレスとポート番号に従い、受信したメディアストリームをＳＯＡＰ−ＳＩＰアダプタ６ｂに転送する。また、このとき、ＮＧＮ接続モジュール部５１０２ａは、メディアストリーム制御情報テーブル５０３０のメディアストリーム送受信用ＩＰアドレス５０３２とメディアストリーム送受信用ポート番号５０３３とを送信元に設定する。

ＳＯＡＰ−ＳＩＰアダプタ６ｂのメディアストリーム制御部５１０３ｂは、メディアストリームを受信し、メディアストリーム制御情報テーブル６０３０を参照して受信したシグナルを端末Ｂ７ｂに転送する（Ｓ８４）。図２１−３を参照して本実施の形態のＳＯＡＰ−ＳＩＰアダプタ６ｂについて説明すると、受信したメディアストリームの送信元ＩＰアドレスとポート番号は、ＳＯＡＰ−ＳＩＰアダプタ６ａのＩＰアドレス（１０．０．１．１）、ポート番号（１００００）であり、対応する相手先ＩＰアドレス（２）６０３６（１９２．１６８．１０．２）とポート番号（２）６０３７（４００００）が取得される。ＮＧＮ接続モジュール部５１０２ｂは、取得したＩＰアドレスとポート番号に従い、受信したメディアストリームを端末Ｂ７ｂに転送する。また、このとき、ＮＧＮ接続モジュール部５１０２ｂは、メディアストリーム制御情報テーブル６０３０のメディアストリーム送受信用ＩＰアドレス６０３２とメディアストリーム送受信用ポート番号６０３３とを送信元に設定する。
なお、端末Ｂ７ｂから端末Ａ７ａにメディアストリームを送信する場合（Ｓ８５〜Ｓ８７）、端末Ａ７ａ及び端末Ｂ７ｂ間でＡＰレベルのシグナルを送受信する場合（Ｓ７６〜Ｓ８１）も同様である。
以上のように、一例として端末Ａ７ａの画面上などで通信したい相手を選択することをトリガーに、接続開始要求のＳＯＡＰメッセージをＳＯＡＰ−ＳＩＰアダプタ６ａに送信することで、ＳＩＰを意識することなく相手端末Ｂ７ｂとの間に通信帯域を確保することが可能である。通信帯域確保後は、端末７は、これまで既存のインターネット上と変わらない動作で帯域が確保されたＮＧＮ Ｎ２で通信することが可能である。また、シグナリングチャネルを確立するＩＰアドレスと、データチャネルを確立するＩＰアドレスが同一となる。

図２０は、第２の実施の形態のＮＧＮ接続サービスの手順を説明するシーケンス図（２）である。図１８は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６における接続終了要求受信時の動作を説明するフローチャートである。図２３は、第２の実施の形態のＳＯＡＰ−ＳＩＰアダプタ６における切断通知受信時の動作を説明するフローチャートである。
図２０、図１８、図２３を参照して、接続を終了する動作について説明する。図２０のステップＳ９１〜Ｓ９６の処理は、上述のＳ８２〜Ｓ８７に対応する。
端末Ａ７ａは、ＳＯＡＰ ｄｉｓｃｏｎｎｅｃｔＲｅｑｕｅｓｔ（切断要求）をＳＯＡＰ−ＳＩＰアダプタ６ａに送信する（Ｓ９７）。ＳＯＡＰ ｄｉｓｃｏｎｎｅｃｔＲｅｑｕｅｓｔは、接続を終了したい呼のｃｏｎｎｅｃｔｉｎＩＤを含む。具体的には、例えば、端末Ａ７ａは、上述のステップＳ６４で記憶されたｃｏｎｎｅｃｔｉｏｎＩＤを含むＳＯＡＰ ｄｉｓｃｏｎｎｅｃｔＲｅｑｕｅｓｔを生成する。一例として、端末Ａ７ａは、適宜の入力部より、ユーザ操作に基づいて上述のステップＳ６４で記憶されたｃｏｎｎｅｃｔｉｏｎＩＤから接続を終了したい呼のｃｏｎｎｅｃｔｉｏｎＩＤを選択してもよい。
ＳＯＡＰ−ＳＩＰアダプタ６ａは、ｃｏｎｎｅｃｔｉｏｎＩＤをキーにＳＯＡＰ−ＳＩＰアダプタ６ａで保持しているコネクション情報テーブル５０１０を検索し、一致するｃｏｎｎｅｃｔｉｏｎＩＤ５０１１のテーブル情報から切断する端末７を特定して切断する（Ｓ９８〜Ｓ１０５）。以下、ＳＯＡＰ−ＳＩＰアダプタ６ａにおけるステップＳ９８〜Ｓ１０５の詳細な動作について説明する。
まず、ＳＯＡＰ−ＳＩＰアダプタ６ａのＳＯＡＰ制御部５１０１ａは、ＳＯＡＰ ｄｉｓｃｏｎｎｅｃｔＲｅｑｕｅｓｔを受信し、切断要求（Ｂ）をＮＧＮ接続モジュール部５１０２ａに送信する（Ｓ９８）。この切断要求（Ｂ）は、ＳＯＡＰ ｄｉｓｃｏｎｎｅｃｔＲｅｑｕｅｓｔ内のｃｏｎｎｅｃｔｉｏｎＩＤを含む。
ＮＧＮ接続モジュール部５１０２ａは、切断要求（Ｂ）を受信すると（１８０１）、受信した切断要求（Ｂ）に含まれるｃｏｎｎｅｃｔｉｏｎＩＤに基づいてコネクション情報テーブル５０１０のｃｏｎｎｅｃｔｉｏｎＩＤ５０１１を検索する（１８０２）。受信した切断要求（Ｂ）に含まれるｃｏｎｎｅｃｔｉｏｎＩＤがコネクション情報テーブル５０１０に登録済みの場合、ＮＧＮ接続モジュール部５１０２ａは、切断成功応答を生成し（１８０７）、生成した切断成功応答をＳＯＡＰ制御部５１０１ａに送信する（Ｓ９９）。ＳＯＡＰ制御部５１０１ａは、切断成功応答を受信し、ＳＯＡＰ ｄｉｓｃｏｎｎｅｃｔＲｅｓｐｏｎｓｅを端末Ａ７ａに送信する（Ｓ１００、１８０８）。なお、ＳＯＡＰ ｄｉｓｃｏｎｎｅｃｔＲｅｓｐｏｎｓｅは、成功応答のみが送信されてもよい。
また、メディアストリーム制御部５１０３ａは、メディアストリームの転送を停止する（１８０３）。なお、ＮＧＮ接続モジュール部５１０２ａから、メディアストリーム転送停止要求をメディアストリーム制御部５１０３ａに送信してもよい。

ＮＧＮ接続モジュール部５１０２ａは、切断要求（Ｂ）を生成し、ＳＩＰ制御部５１０４ａに送信する（Ｓ１０１、１８０４）。具体的には、ＮＧＮ接続モジュール部５１０２ａは、該当したｃｏｎｎｅｃｔｉｏｎＩＤ５０１１に対応する端末情報テーブル５０２０を参照し、Ｔｏ ＵＲＩ５０２７を取得する。ＮＧＮ接続モジュール部５１０２ａは、取得したＴｏ ＵＲＩ５０２７を含む切断要求（Ｂ）をＳＩＰ制御部５１０４ａに送信する。
ＳＩＰ制御部５１０４ａは、切断要求（Ｂ）を受信し、受信した切断要求（Ｂ）に含まれるＴｏ ＵＲＩに従いＳＩＰのＢＹＥメッセージ（Ｂ）をＳＯＡＰ−ＳＩＰアダプタ６ｂに送信する（Ｓ１０２）。ＳＯＡＰ−ＳＩＰアダプタ６ｂのＳＩＰ制御部５１０４ｂは、ＢＹＥメッセージ（Ｂ）を受信し（２００１）、切断通知（Ａ）をＮＧＮ接続モジュール部５１０２ｂに送信する（Ｓ１０３）。また、ＳＩＰ制御部５１０４ｂは、ＳＩＰの２００ ＯＫ（Ｂ）をＳＯＡＰ−ＳＩＰアダプタ６ａに送信する（Ｓ１０４、２００２）。
メディアストリーム制御部５１０３ｂは、メディアストリームの転送を停止し（２００３）、メディアストリーム未転送に設定する（２００４）。なお、ＮＧＮ接続モジュール部５１０２ｂから、メディアストリーム転送停止要求をメディアストリーム制御部５１０３ｂに送信してもよい。
ＳＯＡＰ−ＳＩＰアダプタ６ａのＳＩＰ制御部５１０４ａは、２００ ＯＫ（Ｂ）を受信し、切断完了通知（Ｂ）をＮＧＮ接続モジュール部５１０２ａに送信する（Ｓ１０５、１８０５）。ＮＧＮ接続モジュール部５１０２ａは、切断完了通知（Ｂ）を受信し、メディアストリーム未転送に設定する（１８０６）。
なお、ステップ１８０２において、受信した呼終了要求に含まれるｓｅｓｓｉｏｎＩＤが未登録の場合、ＮＧＮ接続モジュール部５１０２ａは、呼終了要求失敗応答（エラーレスポンスメッセージ）を生成し（１８０９）、生成した呼終了要求失敗応答をＳＯＡＰ制御部５１０１ａに送信する。
ＳＯＡＰ制御部５１０１ａは、呼終了要求失敗応答を受信し、呼終了要求の失敗を示すＳＯＡＰ ｄｉｓｃｏｎｎｅｃｔＲｅｓｐｏｎｓｅを端末Ａ７ａに送信する（１８０８）。

３．その他
（第１の実施の形態の構成）
第１の実施の形態において、通信システムは、例えば、第１サーバ（ＳＯＡＰ−ＳＩＰアダプタ２）と、前記第１サーバとＳＩＰプロトコルで接続設定をする装置（端末Ｂ５ｃ、ＣＬＩＥＮＴ Ｂ）と、前記第１サーバと通信する第１端末（端末Ａ５ｂ、ＣＬＩＥＮＴ Ａ）とを有する通信システムであって、
前記第１サーバは、
接続要求メッセージ（ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｓｅｔ）を受信するインタフェース（ＳＯＡＰ制御部）と、
受信した前記接続要求メッセージに従い、前記ＳＩＰプロトコルで前記装置に対して接続設定を行う処理部（３ＰＣＣモジュール部、ＳＩＰ制御部）と、
前記処理部の接続設定の後に、前記第１端末から受信したデータを前記装置に転送する第１転送制御部（メディアストリーム制御部）と
を有する。
上述の通信システムにおいて、前記装置は第２端末（端末Ｂ５ｃ、ＣＬＩＥＮＴ Ｂ）であり、
前記通信システムは、前記第１サーバへ、前記第１端末と前記第２端末とで通信するための前記接続要求メッセージを送信する第２サーバ（ｗｅｂサーバ１）をさらに備え、
前記処理部は、前記ＳＩＰプロトコルで前記第１端末及び前記第２端末に対して接続設定を行い、
前記第１転送処理部は、前記第２端末から受信したデータを前記第１端末に、前記第１端末から受信したデータを前記第２端末に、各々転送する。
なお、上述の通信システムは、さらに以下のように構成してもよい。

例えば、上述の通信システムにおいて、前記処理部は、前記接続要求メッセ−ジに基づいて、前記第１端末と前記第２端末とのセッションに関するセッションＩＤを生成してもよい。
上述の通信システムにおいて、前記第１サーバは、前記セッションＩＤと、前記第１端末とのセッションに関する第１セッション情報及び前記第２端末とのセッションに関する第２セッション情報とを対応して記憶する記憶部をさらに有してもよい。
上述の通信システムにおいて、前記第２サーバは、前記セッションＩＤの入力を受け付ける入力部をさらに有し、
前記処理部は、前記入力部により入力された前記セッションＩＤを含む情報要求を前記インタフェースを介して前記第２サーバから受信し、前記セッションＩＤに基づいて前記記憶部に対して検索処理を実行し、該当するセッションＩＤに対応する第１及び第２セッション情報を、前記インタフェースを介して前記第２サーバへ送信するようにしてもよい。
上述の通信システムにおいて、前記記憶部は、前記第１セッション情報が前記第１端末のユーザのＳＩＰ−ＵＲＩに対応して記憶され、前記第２セッション情報が前記第２端末のユーザのＳＩＰ−ＵＲＩに対応して記憶され、
前記第２サーバは、前記セッションＩＤ及びＳＩＰ−ＵＲＩの入力を受け付ける入力部をさらに有し、
前記処理部は、前記入力部により入力された前記セッションＩＤ及びＳＩＰ−ＵＲＩを含む情報要求を前記第２インタフェースを介して前記第２サーバから受信し、前記セッションＩＤ及びＳＩＰ−ＵＲＩに基づいて前記記憶部に対して検索処理を実行し、該当するセッションＩＤ及びＳＩＰ−ＵＲＩに対応する第１セッション情報又は第２セッション情報を、前記インタフェースを介して前記第２サーバへ送信するようにしてもよい。
上述の通信システムにおいて、前記第１サーバは、前記処理部による前記第１端末又は前記第２端末に対する前記接続設定の後に、前記第１端末又は前記第２端末に対して接続維持メッセージを送信してもよい。
上述の通信システムにおいて、前記第２サーバは、前記セッションＩＤの入力を受け付ける入力部をさらに有し、
前記処理部は、前記入力部により入力された前記セッションＩＤを含む切断要求を前記インタフェースを介して前記第２サーバから受信し、前記セッションＩＤに対応するセッションについて、前記ＳＩＰプロトコルで前記第１端末及び／又は前記第２端末に対して接続切断設定を行うようにしてもよい。
上述の通信システムにおいて、前記処理部は３ＰＣＣモジュールを含んでもよい。
上述の通信システムにおいて、前記第１転送制御部は、
前記第１端末及び前記第２端末に対する前記接続設定において、前記第１端末と前記第２端末のアドレス情報を取得し、
前記第１端末と前記第２端末のアドレス情報の対を記憶し、
該記憶されたアドレス情報の対を参照して、前記第２端末から受信したデータを前記第１端末に、前記第１端末から受信したデータを前記第２端末に、各々転送するようにしてもよい。
上述の通信システムにおいて、前記処理部は、前記第１端末及び前記第２端末に対する接続設定において、前記第１サーバのアドレス情報を前記第１端末及び前記第２端末に通知し、
前記第１端末及び前記第２端末は、通知されたアドレス情報を宛先としてデータを前記第１サーバに送信するようにしてもよい。

（第２の実施の形態の構成）
第２の実施の形態において、通信システムは、例えば、第１サーバ（ＳＯＡＰ−ＳＩＰアダプタ６ａ）と、前記第１サーバとＳＩＰプロトコルで接続設定をする装置（ＳＯＡＰ−ＳＩＰアダプタ６ｂ）と、前記第１サーバと通信する第１端末（端末Ａ７ａ、ＣＬＩＥＮＴ Ａ）とを有する通信システムであって、
前記第１サーバは、
接続要求メッセージ（ＳＯＡＰ ｃｏｎｎｅｃｔＲｅｑｕｓｅｔ）を受信するインタフェース（ＳＯＡＰ制御部）と、
受信した前記接続要求メッセージに従い、前記ＳＩＰプロトコルで前記装置に対して接続設定を行う処理部（３ＰＣＣモジュール部、ＳＩＰ制御部）と、
前記処理部の接続設定の後に、前記第１端末から受信したデータを前記装置に転送する第１転送制御部（メディアストリーム制御部）と
を有する。
上述の通信システムは、第２端末（端末Ｂ７ｂ、ＣＬＩＥＮＴ Ｂ）をさらに備え、
前記装置は、第２転送処理部（メディアストリーム制御部５１０３ｂ）を備えた第３サーバ（ＳＯＡＰ−ＳＩＰアダプタサーバ６ｂ）であり、
前記第２転送処理部は、前記第１転送制御部が転送する前記データを受信し、該データを前記第２端末へ転送する。
なお、上述の通信システムにおいて、前記第１端末が、前記第１サーバへ、前記第２端末と通信するための接続要求メッセージを送信してもよい。

（第１、第２の実施の形態の効果）
第１、第２の実施の形態によると、通信品質が保証されたＮＧＮにおいて、通信させる２者間（第１接続端末と第２接続端末間）のデータを転送する通信システム及びサーバを提供することをできる。また、第１、第２の実施の形態によると、通信品質が保証されたＮＧＮ上で３ＰＣＣサービスを提供することができる。第１、第２の実施の形態によると、３ＰＣＣサービスフローにおいて、第１接続端末とのセッションを確立後、第２接続端末とのセッションを確立する際に、第１接続端末で無音状態となることを防ぐことができる。
さらに、第１、第２の実施の形態によると、端末がＳＩＰを意識することなく相手端末との間にＮＧＮの通信帯域を確保し、通信帯域確保後は、端末はこれまで既存のインターネット上と変わらない動作で帯域が確保されたＮＧＮで通信することが可能な通信システム及びサーバを提供することができる。また、第１、第２の実施の形態によると、ＳＯＡＰ−ＳＩＰアダプタに多セッション確立を可能とするインタフェースを実装し、数百〜数千のセッションの確立が可能になる。

４．第３の実施の形態
４．１ 概要
上述の各実施の形態では、ＳＯＡＰ−ＳＩＰアダプタでメディアストリームを中継したが、この場合ＳＯＡＰ−ＳＩＰアダプタに中継処理の負荷がかかる。また、ＳＯＡＰ−ＳＩＰアダプタでＩＮＶＩＴＥセッションの管理をする。セッションの数が多くなると、ＳＯＡＰ−ＳＩＰアダプタへの負荷が大きくなる場合がある。また、通常の３ＰＣＣサービスにおいても、ＳＯＡＰ−ＳＩＰアダプタ相当の装置でＩＮＶＩＴＥセッションの管理をするため、セッションの数が多くなると、上述と同様にＳＯＡＰ−ＳＩＰアダプタへの負荷が大きくなる場合がある。
本実施の形態では、ＳＯＡＰ−ＳＩＰアダプタの負荷を軽減する。
図３２は、第３の実施の形態の概要を示す説明図である。
まず、例えばユーザＡが、ｗｅｂ端末を操作してユーザＢへ電話をかけることを選択する（図中（１））。Ｗｅｂサーバは、ｗｅｂ端末からの要求に従い、ユーザＡの電話Ａと、ユーザＢの電話Ｂとの接続要求をＳＯＡＰ−ＳＩＰアダプタに送信する（図中（２））。ＳＯＡＰ−ＳＩＰアダプタは、ＩＮＶＩＴＥメッセージを電話Ａ、Ｂにそれぞれ送信して、電話Ａ、Ｂとのセッションをそれぞれ確立する（図中（３、４））。その後、ＳＯＡＰ−ＳＩＰアダプタはＲＥＦＥＲメッセージを呼制御装置に送信して、呼制御装置にセッションの制御を移す（図中（５））。呼制御装置は、ＲＥＦＥＲメッセージを終端して電話Ａ、Ｂとのセッションを管理する。

４．２ ハード構成
図３３は、第３の実施の形態の通信網の構成例を示す説明図である。
本通信網（通信システム）は、例えば、ｗｅｂサーバ１と、ＳＯＡＰ−ＳＩＰアダプタ（サーバ）２と、呼制御装置３０とを備える。呼制御装置３０は、例えば、一般的な従来のＩＰネットワークに設置される。
Ｗｅｂサーバ１、ＳＯＡＰ−ＳＩＰアダプタ２の構成は、上述の実施の形態と同様のものを用いることができる。呼制御装置３０は、例えば、ＩＰ−ＰＢＸ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ−ｐｒｉｖａｔｅ ｂｒａｎｃｈ ｅｘｃｈａｎｇｅ：ＩＰ−構内電話交換機）であり、端末Ａ５ｂ、５ｃと通信する。
図３４は、呼制御装置３０の構成図である。
呼制御装置３０は、例えば、メモリ３１０と、処理部（ＣＰＵ）３２０と、インタフェース（ＩＦ）３３１、３３２、３３３とを有する。
メモリ３１０は、転送制御部３１１と、メディア制御部３１２と、位置情報管理部３１３と、呼制御管理部３１４と、通信制御部３１５を有する。なお、これらの各部は、例えば各部の機能を実現するためのプログラムがメモリ３１０に記憶され、ＣＰＵ３２０に読み出され実行されることで実現できる。また、メモリ３１０には、端末能力情報テーブル３１１ａ、メディア情報テーブル３１２ａ、ＲＥＧＩＳＴＥＲ情報管理部３１３ａ及びセッション情報テーブル３１４ａが記憶される。
転送処理部３１１は、例えば転送要求を処理する（ＲＥＦＥＲ）。メディア制御部３１２は、保留音の送信機能を有する。位置情報管理部３１３は、端末からの位置情報登録を処理し管理する（ＲＥＧＩＳＴＥＲ）。呼制御管理部３１４は、どの電話とどの電話が接続しているのか管理する（ＩＮＶＩＴＥ）。通信制御部３１５は、プロトコルに関する通信処理を行う。
端末能力情報テーブル３１１ａは、端末の通信能力を記憶し、管理する（ＳＤＰ）。メディア情報テーブル３１２ａは、メディアリソースの空き状況を管理する。ＲＥＧＩＳＴＥＲ情報管理３１３ａは、ＳＩＰ−ＵＲＩと実際の通信に使うＩＰアドレスなど接続情報のマッピングテーブルである。セッション情報テーブル３１４ａは、どの電話とどの電話が接続しているかを管理するテーブルである。
呼制御装置３０は例えばＩＰ−ＰＢＸなので、インタフェース３３１〜３３３は、構内のＩＰ内線電話、構内の内線携帯電話、外線発信などのＩＦを具備する。既存の内線電話も扱うことができる。

４．３ 処理シーケンス
図２５−１〜図２５−４は、第３の実施の形態の第１シーケンス図である。
図中、カッコ内のステップ番号（Ｓｘｘ）は、上述の実施の形態のステップ番号に対応する。対応する各ステップにおいて、上述のようにデータを記憶するなどの処理を行っても良い。これらの詳細なデータ、テーブルへの記憶等の処理については、上述の通りであるので省略して説明する。
まず、ユーザは、例えば端末５ａを操作してＷｅｂサーバ１にログインする。Ｗｅｂサーバ１は、通信するユーザのユーザ識別子（例えば、端末Ａ５ｂ、端末Ｂ５ｃに対応する２者のユーザ名）を端末５ａより入力する。例えば、Ｗｅｂサーバ１が、ログインした端末５ａに対して表示した画面に従い、ユーザの操作により通信する２者のユーザが選択されてもよい。
Ｗｅｂサーバ１は、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（接続要求）をＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１００１）。ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔは、接続させたい２者のユーザに対応するＳＩＰ−ＵＲＩを含む。例えば、Ｗｅｂサーバ１は、ユーザ識別子とそのユーザのＳＩＰ−ＵＲＩが対応して予め記憶され、入力されたユーザ識別子に対応するＳＩＰ−ＵＲＩを取得する。Ｗｅｂサーバ１は、取得されたＳＩＰ−ＵＲＩを含むＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔを生成してＳＯＡＰ−ＳＩＰアダプタ２に送信する。
ＳＯＡＰ−ＳＩＰアダプタ２のＳＯＡＰ制御部２１０１は、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔを受信し、接続要求を３ＰＣＣモジュール部２１０２に送信する（Ｓ１００２）。この接続要求は、例えば、受信したＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔに基づいてＳＯＡＰ−ＳＩＰアダプタ２で用いる適宜のプロトコルに従って生成されることができ、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ内のＳＩＰ−ＵＲＩを含む。なお、ＳＯＡＰ−ＳＩＰアダプタ２は、Ｃａｌｌ ＩＤを適宜割り当てて接続要求に設定する。Ｃａｌｌ ＩＤは、上述の実施の形態におけるハンドル値に相当する。
３ＰＣＣモジュール部２１０２は、接続要求成功応答をＳＯＡＰ制御部２１０１に送信する（Ｓ１００３）。ＳＯＡＰ制御部２１０１は、接続要求成功応答を受信し、ＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅ（接続要求成功応答）をＷｅｂサーバ１に送信する（Ｓ１００４）。

次に、ＳＯＡＰ−ＳＩＰアダプタ２と端末Ａ５ｂとのセッションを確立する。
３ＰＣＣモジュール部２１０２は、端末Ａ５ｂに対する発信要求（Ａ）をＳＩＰ制御部２１０４に送信する（Ｓ１００５）。例えば、発信要求（Ａ）は、少なくとも端末Ａ５ｂを示すＴｏ ＵＲＩを含む。
ＳＩＰ制御部２１０４は、発信要求（Ａ）に含まれるＴｏ ＵＲＩに従い、呼制御装置３０を介してＩＮＶＩＴＥメッセージ（Ａ）を端末Ａ５ｂに送信する（Ｓ１００６）。端末Ａ５ｂからは、ＳＯＡＰ−ＳＩＰアダプタ（図中、ＳＳＡ）２からの着信にみえる。ＩＮＶＩＴＥメッセージ（Ａ）は、例えば構成定義で予め設定したｏｆｆｅｒ−ＳＤＰを含む。ｏｆｆｅｒ−ＳＤＰは、例えば端末が対応しているコーディック（ＣＯＤＥＣ）の種類など、端末の通信条件情報（能力情報）のリストが記載される。
端末Ａ５ｂは、処理中であることを示す１００Ｔｒｙｉｎｇ、呼び出し中であることを示す１８０Ｒｉｎｇｉｎｇなどの所定のＳＩＰメッセージを呼制御装置３０を介して適宜ＳＩＰ制御部２１０４に送信する（Ｓ１００７、Ｓ１００８）。
端末Ａ５ｂは、ステップＳ１００６のｏｆｆｅｒ−ＳＤＰから通信に使用したい通信条件情報を選択し、選択された通信条件情報が記載されたａｎｓｗｅｒ−ＳＤＰ（以下，ａｎｓ−ＳＤＰと記す）を含む２００ ＯＫ（Ａ）を、ＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１００９）。ａｎｓ−ＳＤＰは、受信したｏｆｆｅｒ−ＳＤＰに記載された通信条件情報のリストのうち、端末Ａ５ｂが対応しているものなど、通信に使用したい通信条件情報が選択されて記載される。選択される通信条件情報はひとつでもよいし、複数でも良い。なお、通信条件情報（図中のＡｎｓ−ＳＤＰ内の情報）は呼接続装置３０を介さずにＳＯＡＰ−ＳＩＰアダプタ２が直接端末から受信する構成としてもよい。
ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ制御部２１０４は、２００ ＯＫ（Ａ）を受信し、応答通知（Ａ）を３ＰＣＣモジュール部２１０２に送信する（Ｓ１０１０）。また、ＳＩＰ制御部２１０４は、ＳＩＰのＡＣＫ（Ａ）を端末Ａ５ｂに送信する（Ｓ１０１１）。

次に、ＳＯＡＰ−ＳＩＰアダプタ２と端末Ｂ５ｃとのセッションを確立する。
３ＰＣＣモジュール部２１０２は、端末Ｂ５ｃに対する発信要求（Ｂ）をＳＩＰ制御部２１０４に送信する（Ｓ１０２０）。例えば、発信要求（Ｂ）は、端末Ｂ５ｃに対応するＴｏ ＵＲＩ２０３８を含む。
ＳＩＰ制御部２１０４は、発信要求（Ｂ）に含まれるＴｏ ＵＲＩに従い、呼制御装置３０を介してＩＮＶＩＴＥメッセージ（Ｂ）を端末Ｂ５ｃに送信する（Ｓ１０２１）。ＩＮＶＩＴＥメッセージ（Ｂ）は、端末Ａ５ｂからのａｎｓ−ＳＤＰを基に、端末Ａ５ｂが選択した通信条件情報（例えば、端末Ａ５ｂの能力情報）を示すｏｆｆｅｒ−ＳＤＰを含むことができる。なお、予め定められた必須コーディックがない場合は、ｏｆｆｅｒ−ＳＤＰに追加する。
端末Ｂ５ｃは、１００Ｔｒｙｉｎｇ、１８０Ｒｉｎｇｉｎｇなどの所定のＳＩＰメッセージをＳＩＰ制御部２１０４に送信する（Ｓ１０２２、Ｓ１０２３）。
また、端末Ｂ５ｃは、ステップＳ１０２１のｏｆｆｅｒ−ＳＤＰから通信に使用したい通信条件情報を選択し、選択された通信条件情報が記載されたａｎｓ−ＳＤＰを含む２００ ＯＫ（Ｂ）を、ＳＯＡＰ−ＳＩＰアダプタ２に送信する（Ｓ１０２４）。ＳＯＡＰ−ＳＩＰアダプタ２のＳＩＰ制御部２１０４は、２００ ＯＫ（Ｂ）を受信し、応答通知（Ｂ）を３ＰＣＣモジュール部２１０２に送信する（Ｓ１０２５）。ＳＩＰ制御部２１０４は、ＡＣＫ（Ｂ）を端末Ｂ５ｃに送信する（Ｓ１０２６）。

なお、ＳＯＡＰ−ＳＩＰアダプタ２は、ステップＳ１０２４、Ｓ１０２５で受信した通信条件情報（第４通信条件情報）の中から、使用する通信条件（例えば、使用するコーディック）を決定して、決定した通信条件を端末Ａ５ｂへ通知してもよい。また、ＳＯＡＰ−ＳＩＰアダプタ２及び呼制御装置３０は、受信した端末の通信条件情報を適宜記憶してもよい。
３ＰＣＣモジュール部２１０２は、ＳＩＰ制御部２１０４に端末Ａ５ｂと端末Ｂ５ｃ間のセッションの転送指示を送信する（Ｓ１０３５）。なお、転送指示を送信する契機としては、１８０Ｒｉｎｇｉｎｇ（Ｓ１０２３）の受信、２００ ＯＫの受信などでもよい。１８０Ｒｉｎｇｉｎｇの受信を契機にＲＥＦＥＲを送信する場合、端末Ｂ５ｃのユーザが電話に出たか出ないかにかかわらず転送処理を進めることになり、例えば、秘書や交換手が電話を保留状態にし、通話相手がその保留電話をとるイメージになる。一方、２００ ＯＫの受信を契機にＲＥＦＥＲを送信する場合、端末Ｂ５ｃのユーザが電話に出てから転送処理を進めることになり、例えば、秘書や交換手が通話相手と電話で話してから電話を取り次ぐようなイメージになる。また、これら以外を契機としてもよい。
ＳＩＰ制御部２１０４は、ＳＩＰのＲＥＦＥＲメッセージを呼制御装置３０に送信する（Ｓ１０３６）。ＲＥＦＥＲメッセージは、例えばＣａｌｌ ＩＤなど、転送するセッションを示すセッション識別情報を含む。
呼制御装置３０は、ＲＥＦＥＲの受信を契機に、端末Ａ５ｂと端末Ｂ５ｃで通信能力のネゴシエーションを行う。例えば、呼制御装置３０は、ＲＥＦＥＲメッセージに含まれるＣａｌｌ ＩＤから、端末Ａ５ｂ、端末Ｂ５ｃを特定する。なお、呼制御装置３０は、例えば上述のＩＮＶＩＴＥメッセージの受信時などに、Ｃａｌｌ ＩＤと端末の識別情報を対応してメモリ３１０に記憶しておくことができる。呼制御装置３０は、端末Ａ５ｂにｒｅ−ＩＮＶＩＴＥメッセージを送信する（Ｓ１０３７）。ｒｅ−ＩＮＶＩＴＥメッセージは、端末Ａ５ｂ、端末Ｂ５ｃの通信条件情報のリストが記載されたｏｆｆｅｒ−ＳＤＰを含む。端末Ａ５ｂは、ｒｅ−ＩＮＶＩＴＥメッセージを受信すると、２００ ＯＫを呼制御装置３０に送信する（Ｓ１０３８）。２００ ＯＫは、端末Ａ５ｂが選択した、端末Ａ５ｂと通信するための情報を含む。呼制御装置３０は、ＡＣＫを端末Ａ５ｂに返す（Ｓ１０３９）。呼制御装置３０は、端末Ｂ５ｃに対しても、上述のステップＳ１０３７〜Ｓ１０３９と同様の処理を行う（Ｓ１０４０〜Ｓ１０４２）。なお、ステップＳ１０４１で送信される２００ ＯＫは、ここでは端末Ｂ５ｃと通信するための情報を含む。

なお、端末Ａ５ｂ、端末Ｂ５ｃの通信条件情報をＳＯＡＰ−ＳＩＰアダプタ２は取得済みであるため、ステップＳ１０３７〜Ｓ１０４２を省略してもよい。この場合、端末Ａ５ｂ、端末Ｂ５ｃの共通の通信条件情報を抽出し、この抽出結果で、後述するＳ１０４５以降の呼制御装置３０が成りすましを行うことでも対応可能である。
呼制御装置３０は、ＳＩＰの２０２ ＡＣＣＥＰＴメッセージをＳＩＰ制御部２１０４に送信する（Ｓ１０４３）。ＳＩＰ制御部２１０４は、応答通知を３ＰＣＣモジュール部２１０２に送信する（Ｓ１０４４）。
呼制御装置３０が、端末Ｂ５ｃになりすまし、接続先変更の要求を端末Ａ５ｂに行う。例えば、端末Ｂ５ｃと通信するための情報が記載されたｏｆｆｅｒ−ＳＤＰを含むｒｅ−ＩＮＶＩＴＥメッセージを端末Ａ５ｂに送信する（Ｓ１０４５）。ここでの端末Ｂ５ｃと通信するための情報は、上述のステップＳ１０４１で取得された情報を用いることができる。端末Ａ５ｂは２００ ＯＫを送信する（Ｓ１０４６）。同様に、呼制御装置３０は、端末Ａ５ｂになりすまし、接続先変更の要求を端末Ｂ５ｃに行う。例えば、端末Ａ５ｂと通信するための情報が記載されたｏｆｆｅｒ−ＳＤＰを含むｒｅ−ＩＮＶＩＴＥメッセージを端末Ｂ５ｃに送信する（Ｓ１０４７）。ここでの端末Ａ５ｂと通信するための情報は、上述のステップＳ１０３８で取得された情報を用いることができる。端末Ｂ５ｃは２００ ＯＫを送信する（Ｓ１０４８）。また、呼制御装置３０はＡＣＫを端末Ａ５ｂ、端末Ｂ５ｃに送信する。
以上により、ＳＯＡＰ−ＳＩＰアダプタ２を介さずに、端末Ａ５ｂと端末Ｂ５ｃとの間で通信が可能となる。なお、シーケンス図に示すように端末Ａ５ｂと端末Ｂ５ｃが直接通信してもよく、また呼制御装置３０を備えないときはＳＯＡＰ−ＳＩＰアダプタ２を、呼制御装置３０を備えるときは呼制御装置３０を、各々介して通信してもよい。
また、呼制御装置３０は、ＢＹＥメッセージをＳＩＰ制御部２１０４に送信する（Ｓ１０５２、Ｓ１０５５）。これは、ＳＯＡＰ−ＳＩＰアダプタ２で管理している端末とのセッションを切断するものである。例えば、ステップＳ１０５２のＢＹＥメッセージがＳＯＡＰ−ＳＩＰアダプタ２と端末Ａ５ｂとのセッションに対応し、ステップＳ１０５５のＢＹＥメッセージがＳＯＡＰ−ＳＩＰアダプタ２と端末Ｂ５ｃとのセッションに対応する。ＳＩＰ制御部２１０４は、切断要求を３ＰＣＣモジュール部２１０２に送信する（Ｓ１０５３、Ｓ１０５６）。ＳＩＰ制御部２１０４は、２００ ＯＫを呼制御装置３０に送信する（Ｓ１０５５、Ｓ１０５７）。ＳＯＡＰ−ＳＩＰアダプタ２は、切断要求に従い端末Ａ５ｂ、端末Ｂ５ｃとのセッションの管理を解放する。

図２６−１〜図２６−４は、第３の実施の形態の第２シーケンス図である。
このシーケンスは、上述の第１シーケンスに、「保留」に関する処理が追加されたものである。例えば、呼制御装置３０が確立する端末Ａ５ｂとのセッションを保留状態にして、端末Ｂ５ｃに対するセッションの確立処理を行うことができる。また、例えば、呼制御装置３０が確立する端末Ｂ５ｃとのセッションを保留状態にして、呼制御装置３０に対するＲＥＦＥＲの送信を行うことができる。例えば、複数の呼を並行して処理できないシステムに有効である。
ステップＳ１００１〜Ｓ１０１１は、上述の第１シーケンスと同様である。３ＰＣＣモジュール部２１０２は、ステップＳ１０１０で端末Ａの発信要求に対する応答通知を受信すると、端末Ａ５ｂの保留要求をＳＩＰ制御部２１０４に送信する（Ｓ１０１４）。ＳＩＰ制御部２１０４は、呼制御装置３０に、端末Ａ５ｂとのセッションを保留にするためのＩＮＶＩＴＥメッセージを送信する（Ｓ１０１５）。呼制御装置３０は、ＩＮＶＩＴＥメッセージを受信すると、端末Ａ５ｂとのセッションを保留状態にし、２００ ＯＫをＳＩＰ制御部２１０４に送信する（Ｓ１０１６）。ＳＩＰ制御部２１０４は、応答通知を３ＰＣＣモジュール部２１０２に送信し（Ｓ１０１７）、ＡＣＫを呼制御装置３０に返す（Ｓ１０１８）。
以上の保留の処理の後に、ステップＳ１０２０以降の処理を実行する。なお、ステップステップＳ１０２０〜Ｓ１０２６は、上述の第１シーケンスと同様である。３ＰＣＣモジュール部２１０２は、ステップＳ１０２５で端末Ｂの発信要求に対する応答通知を受信すると、端末Ｂの保留要求をＳＩＰ制御部２１０４に送信する（Ｓ１０２９）。ＳＩＰ制御部２１０４は、上述の端末Ａ５ｂの場合と同様に、呼制御装置３０に端末Ｂ５ｃとのセッションを保留にするためのＩＮＶＩＴＥメッセージを送信する（Ｓ１０３０）。呼制御装置３０は、ＩＮＶＩＴＥメッセージを受信すると、端末Ｂ５ｃとのセッションを保留状態にし、２００ ＯＫをＳＩＰ制御部２１０４に送信する（Ｓ１０３１）。ＳＩＰ制御部２１０４は、応答通知を３ＰＣＣモジュール部２１０２に送信し（Ｓ１０３２）、ＡＣＫを呼制御装置３０に返す（Ｓ１０３３）。以上の保留の処理の後に、ステップＳ１０３５以降の処理を実行する。ステップＳ１０３５〜Ｓ１０５７は、上述の第１シーケンスと同様である。

図２７−１〜図２７−４は、第３の実施の形態の第３シーケンス図である。
このシーケンスは、上述の第１シーケンスに、擬似ＲＢＴの送信、停止に関する処理が追加されたものである。
ステップＳ１００１〜Ｓ１０１１は、上述の第１シーケンスと同様である。３ＰＣＣモジュール部２１０２は、例えばステップＳ１０１０で端末Ａの発信要求に対する応答通知を受信すると、擬似ＲＢＴ送信要求をメディアストリーム制御部２１０３に送信する（Ｓ１０１２）。メディアストリーム制御部２１０３は、擬似ＲＢＴ送信要求を受信すると、例えばＲＴＰに従い、擬似ＲＢＴを端末Ａ５ｂに送信する（Ｓ１０１３）。メディアストリーム制御部２１０３は、例えば相手を呼び出し中である旨のアナウンスや適宜の音楽等を擬似ＲＢＴとして用いてもよい。例えば、端末Ａ５ｂとのセッションの確立が完了し、端末Ｂ５ｃとのセッションの確立を開始している段階や、ＲＥＦＥＲメッセージを送信して呼制御装置にセッションを転送している段階で、端末Ａ５ｂが無音状態となることを防ぐことができる。なお、この擬似ＲＢＴは、後述する停止要求があるまで送信し続けることができる。
例えば擬似ＲＢＴの送信中に、ステップＳ１０２０以降の処理を実行する。なお、ステップＳ１０２０〜Ｓ１０２６は、上述の第１シーケンスと同様である。３ＰＣＣモジュール部２１０２は、ステップＳ１０２５で端末Ｂの発信要求に対する応答通知を受信すると、端末Ｂ５ｃに対しても、上述の端末Ａ５ｂの場合と同様に擬似ＲＢＴを送信する（Ｓ１０２７、Ｓ１０２８）。以上の処理の後に、ステップＳ１０３５以降の処理を実行する。ステップＳ１０３５〜Ｓ１０５７は、上述の第１シーケンスと同様である。
なお、３ＰＣＣモジュール部２１０２は、メディアストリーム制御部２１０３に擬似ＲＢＴ送信停止要求を送信する。送信するタイミングとしては、例えば、３ＰＣＣモジュール部２１０２から転送要求を送信した後でも良いし（Ｓ２００１、Ｓ２００２）、転送要求に対する応答通知を受信した後でもよい（Ｓ２００３、Ｓ２００４）。メディアストリーム制御部２１０３は、擬似ＲＢＴ送信停止要求に従い、端末Ａ５ｂ及び端末Ｂ５ｃへの擬似ＲＢＴの送信を停止する。

図２８−１〜図２８−４は、第３の実施の形態の第４シーケンス図である。
このシーケンスは、上述の第１シーケンスに、「保留」に関する処理と、擬似ＲＢＴの送信、停止に関する処理との双方が追加されたものである。
まず、Ｗｅｂサーバ１からのＳＯＡＰ ｍａｋｅＣａｌｌＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（接続要求）に応じて、ＳＯＡＰ−ＳＩＰアダプタ２と端末Ａ５ｂとの間でセッションを確立する（Ｓ１００１〜Ｓ１０１１）。なお、各ステップの詳細は、上述の通りであるので、説明を省略する。その後、ＳＯＡＰ−ＳＩＰアダプタ２は端末Ａ５ｂに擬似ＲＢＴを送信する（Ｓ１０１２〜Ｓ１０１３）。また、ＳＯＡＰ−ＳＩＰアダプタ２は、端末Ａ５ｂのセッションを保留させる（Ｓ１０１４〜Ｓ１０１８）。ここで、３ＰＣＣモジュール部２１０２は、擬似ＲＢＴ送信停止要求をメディアストリーム制御部２１０３に送信し、メディアストリーム制御部２１０３が端末Ａ５ｂへの擬似ＲＢＴの送信を停止するようにしてもよい（Ｓ１０１９）。なお、擬似ＲＢＴ送信停止の処理は、上述の第３シーケンスと同様のタイミングで行ってもよい。
次に、端末Ｂ５ｃに対しても同様に、ＳＯＡＰ−ＳＩＰアダプタ２と端末Ｂ５ｃとの間でセッションを確立し（Ｓ１０２０〜Ｓ１０２６）、端末Ｂ５ｃに擬似ＲＢＴを送信する（Ｓ１０２７〜Ｓ１０２８）。また、ＳＯＡＰ−ＳＩＰアダプタ２は、端末Ａ５ｂのセッションを保留させる（Ｓ１０２９〜Ｓ１０３３）。ここで、３ＰＣＣモジュール部２１０２は、擬似ＲＢＴ送信停止要求をメディアストリーム制御部２１０３に送信し、メディアストリーム制御部２１０３が端末Ｂ５ｃへの擬似ＲＢＴの送信を停止するようにしてもよい（Ｓ１０３４）。
その後、ＳＯＡＰ−ＳＩＰアダプタ２は、呼制御装置３０へセッションを転送する処理を実行する（Ｓ１０３５〜Ｓ１０５７）。

図２９−１〜図２９−４は、第３の実施の形態の第５シーケンス図である。
本シーケンスは、保留制御から処理が始まる例である。
ステップＳ１００１〜Ｓ１００４は、上述の第１シーケンスと同様である。次に、３ＰＣＣモジュール部２１０２は、端末Ａ、端末Ｂを擬似的に保留状態にする（Ｓ１０１４〜Ｓ１０１８、Ｓ１０２９〜Ｓ１０３３）。なお、各ステップの詳細は、上述の通りであるので、説明を省略する。
この状態で、３ＰＣＣモジュール部２１０２は転送要求を送信する（Ｓ１０３５）。なお、この転送要求に、端末Ａ、端末Ｂを識別する識別情報が含まれても良い。また、上述の保留の処理において、保留要求にＣａｌｌ ＩＤと端末の識別情報を含めて呼制御装置３０に送信して呼制御装置３０でＣａｌｌ ＩＤと端末の識別情報を対応して記憶し、転送要求では、上述のシーケンスと同様にＣａｌｌ ＩＤを含めて送信してもよい。ステップＳ１０３５以降の処理は上述の第１シーケンスと同様である。

５．第４の実施の形態
本実施の形態では、上述の第３の実施の形態の処理において、セッションを確立した複数端末の各々の通信条件情報に基づいて、ＳＯＡＰ−ＳＩＰアダプタ２での中継や予め定められたサービスを提供するための処理が必要か否かを判断する。また、ＳＯＡＰ−ＳＩＰアダプタ２では、例えば、メディア情報の変換などの処理を行う。
図３０−１〜図３０−４は、第４の実施の形態の第１シーケンス図である。
本シーケンスの例は、上述の第３の実施の形態の第１シーケンスに、メディアストリーム制御部２１０３での中継判定処理ステップ（Ｓ２０１０）を追加したものである。
ステップＳ１００１〜Ｓ１０１１、Ｓ１０２０〜Ｓ１０２６は、上述の第１シーケンスと同様である。
ＳＯＡＰ−ＳＩＰアダプタ２のメディアストリーム制御部２１０３は、例えば、ステップＳ１０２４の後に、中継判定処理を実行する（Ｓ２０１０）。なお、中継判定処理は、端末Ｂとのセッション制御において、接続応答（２００ ＯＫ）を受信した後であればよく、例えば、ステップＳ１０２５の３ＰＣＣモジュール部２００２への応答通知（発信Ｂ）の後でもよいし、ステップＳ１０２６の端末Ｂ５ｃへのＡＣＫ送信の後でもよい。なお、端末の通信条件情報（能力情報）が２００ ＯＫ以外のタイミングで受信される構成の場合、この通信条件情報の受信後であればよい。
ここで、ＳＯＡＰ−ＳＩＰアダプタ中継判定処理の例を説明する。中継判定処理では、予め定められたキーを用いて、ＳＯＡＰ−ＳＩＰアダプタ２での中継の要否判定、中継時の適用サービス判定を行う。例えば、ＩＰバージョンが不一致の場合、コーディックが不一致の場合、付加サービスがある場合などは、メディアの中継シーケンスに移り、それ以外はＲＥＦＥＲシーケンスに移る。
メディア中継シーケンスでは、ＳＯＡＰ−ＳＩＰアダプタ２は、セッションを保留状態にしている場合は保留解除要求を送信して保留を解除し、ＳＯＡＰ−ＳＩＰアダプタ２を介して端末間のメディアを通信させる。ＲＥＦＥＲシーケンスは、上述のステップＳ１０３５以降の処理と同様である。
判断のキーとなる情報と、中継時の適用サービスを以下例示する。なお、以下に示すキーを組み合わせて用いてもよい。例えば、ＳＩＰヘッダの加入者情報から特定の加入者のみ、トランスコーディックを実施するなどしてもよい。

（１）キーとしてＳＩＰヘッダを用いる例
判断のキーとして、例えば、ＳＩＰのｆｒｏｍ ＵＲＩ、Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙヘッダなど用いることができる。ＳＩＰヘッダには、このような送信元（加入者）を示す情報がある。ＳＯＡＰ−ＳＩＰアダプタ２は、ＳＩＰヘッダから抽出した加入者情報（加入者識別情報）をキーに、「加入者−加入サービス」テーブル（加入サービステーブル）を検索し、該当するサービスを判断する。「加入者−加入サービス」テーブルは、加入者情報に対応して、その加入者が契約しているサービスを識別する情報（加入サービス識別情報）が予め記憶される。サービスとしては、一例として、通話録音サービス、同時通訳サービス、議事録サービスなどがある。通話録音サービスは、例えば第１端末と第２端末間の通話を録音する。同時通訳サービスは、第１端末と第２端末間の通話を同時通訳して転送する。議事録サービスは、第１端末と第２端末間の通話を文書化して記憶する。なお、これら以外にも適宜のサービスであってもよい。
該当するサービスがある場合、ＳＯＡＰ−ＳＩＰアダプタ２はＲＥＦＥＲを送信せずに、ＳＯＡＰ−ＳＩＰアダプタ２を介して端末Ａ５ｂ、端末Ｂ５ｃ間を通信させ、該当サービスを提供する。例えば、通話録音サービスにおいては、端末Ａ５ｂ、端末Ｂ５ｃ間の通話を録音する。一方、該当サービスが存在しない場合は、第３の実施の形態と同様にＲＥＦＥＲを実施する。図３０のシーケンスは、該当サービスが存在せず、ＲＥＦＥＲを実施する場合を示している。
（２）キーとして、対向装置から受信したａｎｓｗｅｒ−ＳＤＰを解析して用いる例
判断のキーとして、例えば、ＳＤＰに含まれるｓ行（セッション情報）を用いることができる。ｓ行をキーに、「セッション種別−提供サービス」テーブル（提供サービステーブル）を検索し、該当サービスの有無を判断する。「セッション種別−提供サービス」テーブルは、セッション種別に対応して、サービスを識別する情報が予め記憶される。なお、サービスを識別する情報は、その加入者が契約しているサービスでもよい。該当サービスがある場合、ＳＯＡＰ−ＳＩＰアダプタ２はＲＥＦＥＲを送信せずに、ＳＯＡＰ−ＳＩＰアダプタ２を介して端末Ａ５ｂ、端末Ｂ５ｃ間を通信させ、該当サービスを提供する。一方、該当サービスが存在しない場合は、第３の実施の形態と同様にＲＥＦＥＲを実施する。なお、ｓ行の他に、ＳＤＰには、ｅ行、ｐ行、ｕ行など提供サービスの判定に有効な情報があり、これらを用いることもできる。なお、ＳＤＰの行については、例えばＲＦＣ２３２７、ＲＦＣ３２６４等に開示されている。
（３）対向装置から４８８応答受信をキーとする例
ＳＯＡＰ−ＳＩＰアダプタ２が送信したｏｆｆｅｒ−ＳＤＰに対し、対応装置（端末Ａ５ｂ又は端末Ｂ５ｃ）が４８８（ｗａｒｎ ｃｏｄｅ ３００／３０１）応答をした場合、ＳＯＡＰ−ＳＩＰアダプタ２は、例えばＩＰｖ４とＩＰｖ６のネットワークプロトコル変換を実施する。ここで、ｗａｒｎ ｃｏｄｅ ３００／３０１は、ネットワークプロトコルの不一致を意味する応答コードである。
一方、ＳＯＡＰ−ＳＩＰアダプタ２が送信したｏｆｆｅｒ−ＳＤＰに対し対応装置が４８８（ｗａｒｎ ｃｏｄｅ ３０５）応答をした場合、ＳＯＡＰ−ＳＩＰアダプタ２はトランスコーディックを実施する。ここで、ｗａｒｎ ｃｏｄｅ ３０５は、コーディック不一致を意味する応答コードである。なお、ネットワークプロトコルの不一致やコーディック不一致を意味する応答コードを用いる以外にも、端末が用いるプロトコルやコーディックの識別情報を受信して照合し、一致／不一致を判断してもよい。
ＳＯＡＰ−ＳＩＰアダプタ２は、コーディック処理部をさらに備えることができる。コーディック処理部は、メディアストリーム制御部２１０３の内部にあってもよいし、これとは別に外部にあってもよい。コーディック処理部でのトランスコーディックについては、適宜の手法を用いることができる。

ＳＯＡＰ−ＳＩＰアダプタ中継判定処理の他の例を説明する。
ＳＯＡＰ−ＳＩＰアダプタ２は、ステップＳ１００９において、端末Ａ５ｂから、端末Ａ５ｂの通信条件情報（図中のＡｎｓ−ＳＤＰ内の情報、能力情報）を含む接続応答２００ＯＫを受信している。また、ＳＯＡＰ−ＳＩＰアダプタ２は、ステップＳ１０２１において、例えば端末Ａ５ｂからの通信条件情報の少なくとも一部を用いて端末Ｂ５ｃへの接続要求ＩＮＶＩＴＥを生成して送信している。さらに、ステップＳ１０２４において、端末Ｂ５ｃから、端末Ｂ５ｃの通信条件情報を含む２００ＯＫを受信している。
ＳＯＡＰ−ＳＩＰアダプタ２が、例えばステップＳ１０２４の２００ ＯＫを受信すると、メディアストリーム制御部２１０３が、先に受信した端末Ａ５ｂの通信条件情報と照合し、端末Ａ，Ｂについて通信するメディアのコーディックの変更の要否を判断する。例えば、端末Ｂ５ｃが端末Ａ５ｂの通信条件情報の一部を選択した場合、変更が必要と判断する。変更する場合は、ＳＩＰのＵＰＤＡＴＥメッセージかＩＮＶＩＴＥメッセージを用いて、変更した通信条件情報を端末Ａ５ｂに送信する。例えば、端末Ｂ５ｃが選択した通信条件情報を、端末Ａ５ｂに送信する。
これにより、端末Ａ、Ｂ間でのメディアコーディックの調整が実現できる。なお、通信条件情報とは、例えばＳＩＰメッセージのＳＤＰフィールド内に格納される、コーディックに対応するポート設定情報である。

図３１−１〜図３１−４は、第４の実施の形態の第２シーケンス図である。
本シーケンスの例は、上述の第３の実施の形態の第４シーケンスに、メディアストリーム制御部２１０３での処理判断ステップ（Ｓ２０１０）を追加したものである。各ステップの処理は、上述と同様であるので説明を省略する。
なお、本実施の形態では、例として上述の第３の実施の形態の第１シーケンスと、第４シーケンスに処理判断ステップを追加したものを示すが、第３の実施の形態の第１から第５シーケンスのいずれにおいても処理判断ステップを追加することが可能である。

本発明は、例えばＩＰネットワークにおいて利用可能である。

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

Claims (11)

1. 上位装置から第１端末及び第２端末間の接続要求メッセージを受信し、該第１端末とのセッション及び該第２端末とのセッションを確立するサーバと、
   前記第１端末及び前記第２端末を管理する呼制御装置と
   を備え、
   前記サーバが、前記サーバと第１端末との間のセッション及び前記サーバと第２端末とのセッションを確立した後に、前記呼制御装置へセッションの転送要求を送信し、
   前記呼制御装置は、
   前記転送要求を受信すると、前記呼制御装置と前記第１端末との間のセッション及び前記呼制御装置と第２端末との間のセッションを新たに確立し、
   前記サーバと前記第１端末との間のセッションの切断要求及び該サーバと前記第２端末との間のセッションの切断要求を該サーバに送信し、
   以後、前記呼制御装置が、前記呼制御装置と前記第１端末との間のセッション及び前記呼制御装置と第２端末との間のセッションを管理する通信システム。
2. 前記転送要求は、ＳＩＰのＲＥＦＥＲメッセージである請求項１に記載の通信システム。
3. 前記サーバは、
   前記サーバと第１端末との間のセッション又は前記サーバと第２端末とのセッションを確立する処理における、呼び出し中を示すメッセージ、又は、応答確認を示すメッセージを受信すると、前記サーバと第１端末との間のセッション又は前記サーバと第２端末とのセッションを保留状態にするための保留指示を前記呼制御装置に送信し、
   該保留状態において、前記サーバと第２の端末とのセッション確立要求又は前記呼制御装置への転送要求を送信する請求項１に記載の通信システム。
4. 前記サーバは、前記サーバと第１端末との間のセッション又は前記サーバと第２端末とのセッションを確立した後に、前記第１端末又は前記第２端末に対してＲＢＴを送信する請求項１に記載の通信システム。
5. 前記サーバは、転送要求を前記呼制御装置に送信すると、又は、該転送要求に対する応答通知を前記呼制御装置から受信すると、ＲＢＴの送信を停止する請求項４に記載の通信システム。
6. 前記呼制御装置は、前記転送要求に含まれるセッション識別情報から前記第１端末及び前記第２端末を特定する請求項１に記載の通信システム。
7. 前記呼制御装置は、前記サーバと前記第１端末との間のセッション又は前記サーバと第２端末とのセッションの確立の際に、セッション識別情報、前記第１端末の識別情報、及び前記第２端末の識別情報を対応付けて記憶する請求項１に記載の通信システム。
8. 前記呼制御装置は、前記転送要求の受信の後に、前記第１端末に通信条件情報を含む第１の接続要求メッセージを送信し、かつ、前記第２端末に通信条件情報を含む第２の接続要求メッセージを送信する請求項１に記載の通信システム。
9. 前記呼制御装置は、前記転送要求の受信の後に、（ｉ）前記第１端末に、通信条件情報のリストを含む第１の接続要求メッセージを送信し、前記第１端末から、前記リストから選択された通信条件情報を含む第１の応答メッセージを受信し、かつ、（ｉｉ）前記第２端末に、通信条件情報のリストを含む第２の接続要求メッセージを送信し、前記第２端末から、前記リストから選択された通信条件情報を含む第２の応答メッセージを受信する請求項１に記載の通信システム。
10. 前記通信条件情報は前記第１端末と前記第２端末の通信条件情報である請求項９に記載の通信システム。
11. 前記第１の接続要求メッセージ及び前記第２の接続要求メッセージはｒｅ−ＩＮＶＩＴＥメッセージであり、前記第１の応答メッセージ及び前記第２の応答メッセージは２００ＯＫである請求項１０に記載の通信システム。
    

Images