(57)【要約】【課題】Ｂ２ＢＵＡ（Back to Back User Agent）を必要とするＵＡに対してのみ、Ｂ２ＢＵＡを経由するＳＩＰルートを設定することによって、ネットワーク設備の負荷を軽減する。【解決手段】ＩＭＳネットワークに接続するＩＭＳクライアントからＳＩＰリクエストがあったときに、送信元と送信先のＩＭＳクライアント１ａ〜１ｃが、確立しようとするセッションで要求される機能を有しているかどうかを確認するＩＭＳクライアント機能確認機能２１ｃと、ＩＭＳクライアント１ａ〜１ｃが、確立しようとするセッションで要求される機能を有していない場合は、Ｂ２ＢＵＡ２１を経由するＳＩＰルートの設定を行なう一方、ＩＭＳクライアント１ａ〜１ｃが、確立しようとするセッションで要求される機能を有している場合は、Ｂ２ＢＵＡ２１を経由しないＳＩＰルートの設定を行なう選択的ＳＩＰルート設定部２１ｄと、を備える。【選択図】図２
2010239292.tif 000002
【特許請求の範囲】
【請求項１】
ＩＭＳ（IP Multimedia Subsystem）ネットワーク上でＳＩＰ（Session Initiation Protocol）セッションを確立するBack to Back User Agentの動作を制御するネットワーク制御装置であって、
前記ＩＭＳネットワークに接続するＩＭＳクライアントからＳＩＰリクエストがあったときに、前記ＩＭＳクライアントと前記ＳＩＰリクエストの送信先となるＩＭＳクライアントが、確立しようとするセッションで要求される機能を有しているかどうかを確認するＩＭＳクライアント機能確認部と、
前記ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有していない場合は、前記Back to Back User Agentを経由するＳＩＰルートの設定を行なう一方、前記ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有している場合は、前記Back to Back User Agentを経由しないＳＩＰルートの設定を行なう選択的ＳＩＰルート設定部と、を備えることを特徴とするネットワーク制御装置。
【請求項２】
前記ＩＭＳクライアント機能確認部による確認結果を保持するＩＭＳクライアント機能情報保持部をさらに備え、
前記選択的ＳＩＰルート設定部は、新たなＳＩＰリクエストがあったときは、前記保持されている確認結果を利用して、ＳＩＰルートの設定を行なうことを特徴とする請求項１記載のネットワーク制御装置。
【請求項３】
請求項１または請求項２記載のネットワーク制御装置と、
ＳＩＰプロキシ機能を発揮するＳＩＰプロキシ部と、を備えることを特徴とするBack to Back User Agent。
【請求項４】
請求項１または請求項２記載のネットワーク制御装置を備えることを特徴とする呼制御装置。
【請求項５】
ＩＭＳ（IP Multimedia Subsystem）ネットワーク上でＳＩＰ（Session Initiation Protocol）セッションを確立するBack to Back User Agentの動作を制御するネットワーク制御方法であって、
ＩＭＳクライアント機能確認部において、前記ＩＭＳネットワークに接続するＩＭＳクライアントからＳＩＰリクエストがあったときに、前記ＩＭＳクライアントと前記ＳＩＰリクエストの送信先となるＩＭＳクライアントが、確立しようとするセッションで要求される機能を有しているかどうかを確認するステップと、
選択的ＳＩＰルート設定部において、前記ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有していない場合は、前記Back to Back User Agentを経由するＳＩＰルートの設定を行なう一方、前記ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有している場合は、前記Back to Back User Agentを経由しないＳＩＰルートの設定を行なうステップと、を少なくとも含むことを特徴とするネットワーク制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＭＳ（IP Multimedia Subsystem）ネットワーク上でＳＩＰ（Session Initiation Protocol）セッションを確立するBack to Back User Agentの動作を制御する技術に関する。
【背景技術】
【０００２】
従来から知られているＳＩＰ（Session Initiation Protocol）は、ＩＰ（Internet Protocol）上における呼制御に用いられるプロトコルであり、通信を行なう端末間で通信に必要なＩＰアドレスやポート番号、エンコーディング等のネゴシエーション、発呼、着呼などの制御に用いられる。これに加え、ＩＭＳ（IP Multimedia Subsystem）では、このＳＩＰの情報に基づいて通信に必要なネットワークリソースの割り当て、ゲート制御を行なう。ＳＩＰは、従来、Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ型で、クライアント主導で呼制御を行なうプロトコルであった。しかしながら、ＩＭＳにおける呼制御としてＳＩＰが採用され、通信オペレータによる運用が始められている。
【０００３】
このような状況下では、セッションのハンドオーバや、ネットワークからの制御リクエストの送信、また端末間の差異の吸収などのネットワーク主導の制御が必要とされているが、本来、Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ型のＳＩＰをネットワーク主導で制御を行なうことは困難であるため、一度通信オペレータ内の設備でＳＩＰセッションを終端し、再度新しいＳＩＰセッションを構築するBack to Back User Agent（以下、「Ｂ２ＢＵＡ」と呼称する。）を用いる手法が多く用いられている。なお、このＢ２ＢＵＡは、ＩＭＳクライアントから要求を受け取り、ユーザーエージェントサーバー（UAS）として、それを処理する論理構成体と位置付けられるものである。どのように要求が答えられるべきであるかを決定するために、ユーザーエージェントクライアント（UAC）として機能し、要求を発生させる。Ｂ２ＢＵＡは、プロキシサーバーと違って、ダイアログ状態を維持し、それが設立したダイアログの上に送られたすべての要求に関与する。Ｂ２ＢＵＡは、一般的に、ＵＡＣとＵＡＳとを結合したものであると定義することができる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】3GPP TS23.228 IP Multimedia Subsystem (IMS)
【非特許文献２】RFC3261 6.Definitions (http://www.ietf.org/rfc/rfc3261.txt)
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、セッションハンドオーバやフォーマットの吸収など、ネットワーク主導で行なわずとも高性能なＵＡ（User Agent）であれば備えている機能も多い。そのため、一律にネットワークで制御を行なうことは非効率的である。そこで、ネットワーク主導で処理が必要なＵＡに対してのみネットワーク主導の制御を行ない、処理が不要なＵＡに対しての処理を軽減する手法が望まれる。
【０００６】
従来技術では、セッションのハンドオーバや、ネットワークからの制御リクエストの送信、端末間の差異の吸収などを行なうには、Ｂ２ＢＵＡの技術が用いられてきた。しかしながら、Ｂ２ＢＵＡは、ＵＡと同等のＳＩＰ制御処理を求められ、全端末に対して処理を行なうと多くの設備が必要となる。
【０００７】
一方で、ネットワーク主導で制御を行なわずともＵＡ自体に機能を備えている高機能なＵＡも多い。現在の方法ではＵＡに一部専用の機能設けることで、効率的な動作を可能とできるが、やはりＵＡの動作に依存してしまう。
【０００８】
本発明は、このような事情に鑑みてなされたものであり、Back to Back User Agentを必要とするＵＡに対してのみ、Back to Back User Agentを経由するＳＩＰルートを設定することによって、ネットワーク設備の負荷を軽減することができるネットワーク制御装置、Back to Back User Agent、呼制御装置およびネットワーク制御方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
（１）上記の目的を達成するために、本発明は、以下のような手段を講じた。すなわち、本発明のネットワーク制御装置は、ＩＭＳ（IP Multimedia Subsystem）ネットワーク上でＳＩＰ（Session Initiation Protocol）セッションを確立するBack to Back User Agentの動作を制御するネットワーク制御装置であって、前記ＩＭＳネットワークに接続するＩＭＳクライアントからＳＩＰリクエストがあったときに、前記ＩＭＳクライアントと前記ＳＩＰリクエストの送信先となるＩＭＳクライアントが、確立しようとするセッションで要求される機能を有しているかどうかを確認するＩＭＳクライアント機能確認部と、前記ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有していない場合は、前記Back to Back User Agentを経由するＳＩＰルートの設定を行なう一方、前記ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有している場合は、前記Back to Back User Agentを経由しないＳＩＰルートの設定を行なう選択的ＳＩＰルート設定部と、を備えることを特徴としている。
【００１０】
このように、ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有していない場合は、Back to Back User Agentを経由するＳＩＰルートの設定を行なう一方、ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有している場合は、Back to Back User Agentを経由しないＳＩＰルートの設定を行なうので、Back to Back User Agentを必要とするＵＡ（User Agent）に対してのみ、Back to Back User Agentを経由するＳＩＰルートを設定することができる。これにより、Back to Back User Agentを必要としないＵＡはBack to Back User Agentを経由しないため、Back to Back User Agentにおける処理量を削減することが可能となる。また、ＵＡに機能の拡張を加えることなく、要求されたセッションを確立することが可能となる。さらに、既存のBack to Back User Agentの機能で実施することができるため、既存のＩＭＳシステムに変更を加えることなく、実現することが可能となる。
【００１１】
（２）また、本発明のネットワーク制御装置は、前記ＩＭＳクライアント機能確認部による確認結果を保持するＩＭＳクライアント機能情報保持部をさらに備え、前記選択的ＳＩＰルート設定部は、新たなＳＩＰリクエストがあったときは、前記保持されている確認結果を利用して、ＳＩＰルートの設定を行なうことを特徴としている。
【００１２】
このように、新たなＳＩＰリクエストがあったときは、保持されている確認結果を利用して、ＳＩＰルートの設定を行なうので、ＩＭＳクライアント機能確認部における機能確認を省略することが可能となる。その結果、処理の迅速化を図ることが可能となる。
【００１３】
（３）また、本発明のBack to Back User Agentは、上記（１）または（２）記載のネットワーク制御装置と、ＳＩＰプロキシ機能を発揮するＳＩＰプロキシ部と、を備えることを特徴としている。
【００１４】
この構成により、ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有していない場合は、Back to Back User Agentを経由するＳＩＰルートの設定を行なう一方、ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有している場合は、Back to Back User Agentを経由しないＳＩＰルートの設定を行なうので、Back to Back User Agentを必要とするＵＡ（User Agent）に対してのみ、Back to Back User Agentを経由するＳＩＰルートを設定することができる。これにより、Back to Back User Agentを必要としないＵＡはBack to Back User Agentを経由しないため、Back to Back User Agentにおける処理量を削減することが可能となる。また、ＵＡに機能の拡張を加えることなく、要求されたセッションを確立することが可能となる。さらに、既存のBack to Back User Agentの機能で実施することができるため、既存のＩＭＳシステムに変更を加えることなく、実現することが可能となる。
【００１５】
（４）また、本発明の呼制御装置は、上記（１）または（２）記載のネットワーク制御装置を備えることを特徴としている。
【００１６】
この構成により、ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有していない場合は、Back to Back User Agentを経由するＳＩＰルートの設定を行なう一方、ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有している場合は、Back to Back User Agentを経由しないＳＩＰルートの設定を行なうので、Back to Back User Agentを必要とするＵＡ（User Agent）に対してのみ、Back to Back User Agentを経由するＳＩＰルートを設定することができる。これにより、Back to Back User Agentを必要としないＵＡはBack to Back User Agentを経由しないため、Back to Back User Agentにおける処理量を削減することが可能となる。また、ＵＡに機能の拡張を加えることなく、要求されたセッションを確立することが可能となる。さらに、既存のBack to Back User Agentの機能で実施することができるため、既存のＩＭＳシステムに変更を加えることなく、実現することが可能となる。
【００１７】
（５）また、本発明のネットワーク制御方法は、ＩＭＳ（IP Multimedia Subsystem）ネットワーク上でＳＩＰ（Session Initiation Protocol）セッションを確立するBack to Back User Agentの動作を制御するネットワーク制御方法であって、ＩＭＳクライアント機能確認部において、前記ＩＭＳネットワークに接続するＩＭＳクライアントからＳＩＰリクエストがあったときに、前記ＩＭＳクライアントと前記ＳＩＰリクエストの送信先となるＩＭＳクライアントが、確立しようとするセッションで要求される機能を有しているかどうかを確認するステップと、選択的ＳＩＰルート設定部において、前記ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有していない場合は、前記Back to Back User Agentを経由するＳＩＰルートの設定を行なう一方、前記ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有している場合は、前記Back to Back User Agentを経由しないＳＩＰルートの設定を行なうステップと、を少なくとも含むことを特徴としている。
【００１８】
このように、ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有していない場合は、Back to Back User Agentを経由するＳＩＰルートの設定を行なう一方、ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有している場合は、Back to Back User Agentを経由しないＳＩＰルートの設定を行なうので、Back to Back User Agentを必要とするＵＡ（User Agent）に対してのみ、Back to Back User Agentを経由するＳＩＰルートを設定することができる。これにより、Back to Back User Agentを必要としないＵＡはBack to Back User Agentを経由しないため、Back to Back User Agentにおける処理量を削減することが可能となる。また、ＵＡに機能の拡張を加えることなく、要求されたセッションを確立することが可能となる。さらに、既存のBack to Back User Agentの機能で実施することができるため、既存のＩＭＳシステムに変更を加えることなく、実現することが可能となる。
【発明の効果】
【００１９】
本発明によれば、ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有していない場合は、Back to Back User Agentを経由するＳＩＰルートの設定を行なう一方、ＩＭＳクライアントが、確立しようとするセッションで要求される機能を有している場合は、Back to Back User Agentを経由しないＳＩＰルートの設定を行なうので、Back to Back User Agentを必要とするＵＡ（User Agent）に対してのみ、Back to Back User Agentを経由するＳＩＰルートを設定することができる。これにより、Back to Back User Agentを必要としないＵＡはBack to Back User Agentを経由しないため、Back to Back User Agentにおける処理量を削減することが可能となる。また、ＵＡに機能の拡張を加えることなく、要求されたセッションを確立することが可能となる。さらに、既存のBack to Back User Agentの機能で実施することができるため、既存のＩＭＳシステムに変更を加えることなく、実現することが可能となる。
【図面の簡単な説明】
【００２０】
【図１】本実施形態に係るネットワーク構成を示す図である。
【図２】ネットワークを構成する要素のブロック図である。
【図３】Ｓ−ＣＳＣＦ２３が「ＩＭＳクライアント機能確認機能２１ｃと、選択的ＳＩＰルート設定機能２１ｄと、ＩＭＳクライアントの機能情報保持機能２１ｅ」を有する形態を示す図である。
【図４】本実施形態において、ＩＭＳクライアント同士がＳＩＰメッセージを送受信する際に、双方の機能を確認してＢ２ＢＵＡの利用判断し、Ｂ２ＢＵＡを用いる場合のシーケンスチャートである。
【図５】本実施形態において、ＩＭＳクライアント同士がＳＩＰメッセージを送受信する際に、双方の機能を確認してＢ２ＢＵＡの利用判断し、Ｂ２ＢＵＡを用いない場合のシーケンスチャートである。
【図６】通常のＳＩＰリクエストをそのまま用いて、クライアントの機能を調べ、結果Ｂ２ＢＵＡを用いる動作を示すシーケンスチャートである。
【図７】通常のＳＩＰリクエストをそのまま用いて、クライアントの機能を調べ、結果Ｂ２ＢＵＡを用いない動作を示すシーケンスチャートである。
【発明を実施するための形態】
【００２１】
本発明は、双方のＩＭＳクライアント（SIP UA）が通信する際に、ＩＭＳクライアントが備える機能を確認し、Ｂ２ＢＵＡ（Back to Back User Agent）における処理が必要か否かを判断し、効率的にＢ２ＢＵＡを用いることで、処理量やトラフィックを削減する。このために、Ｂ２ＢＵＡに、ＩＭＳクライアント機能確認の機能と保持機能、および場合に応じてＳＩＰプロキシとして動作する機能を備える。
【００２２】
図１は、本実施形態に係るネットワーク構成を示す図である。このネットワークは、ＩＭＳクライアント１ａ〜１ｃ、アクセスネットワーク１０、ＩＭＳコアネットワーク２０、Ｐ−ＣＳＣＦ（Proxy Call Session Control Function）２２、Ｓ−ＣＳＣＦ（Serving Call Session Control Function）／Ｉ−ＣＳＣＦ（Interrogating Call Session Control Function）２３、ＨＳＳ（Home Subscriber Server）２４から構成されている。
【００２３】
図１に示すように、ＩＭＳクライアント１ａ〜１ｃが、アクセスネットワーク１０を介して、ＩＭＳコアネットワーク２０に接続し、ＳＩＰセッションを確立している。高機能のＩＭＳクライアント１ａと１ｂとの間では、本発明に係る選択的Ｂ２ＢＵＡ２１を経由しないで通信を行なう。また、一方でも必要な機能を備えていない場合は、それを補助するために選択的Ｂ２ＢＵＡ２１を経由する。
【００２４】
図２は、ネットワークを構成する要素のブロック図である。ＩＭＳクライアント１ａ〜１ｃ、Ｐ−ＣＳＣＦ２２、Ｓ−ＣＳＣＦ２３は、従来の同様の構成を採る。すなわち、ＩＭＳクライアント１ａ〜１ｃは、ＩＭＳクライアント機能１ｄを有しており、Ｐ−ＣＳＣＦ２２は、従来機能２２ａを有している。また、Ｓ−ＣＳＣＦ２３は、従来機能２３ａを有している。
【００２５】
選択的Ｂ２ＢＵＡ２１は、従来のＢ２ＢＵＡ機能２１ａと、ＳＩＰ  Ｐｒｏｘｙ機能２１ｂと、ＩＭＳクライアント機能確認機能２１ｃと、選択的ＳＩＰルート設定機能２１ｄと、ＩＭＳクライアントの機能情報保持機能２１ｅと、から構成されている。
【００２６】
ＩＭＳクライアント機能確認機能２１ｃは、ＩＭＳクライアントに対して、確立するセッションに対して要求する機能が備えられているかを確認する機能である。ＯＰＴＩＯＮＳを用いる手法や、ＯＰＴＩＯＮＳが使えない場合に通常のＳＩＰメッセージに含める手法を備える。
【００２７】
選択的ＳＩＰルート設定機能２１ｄは、上記で確認したＩＭＳクライアントの機能情報に基づいて、Ｂ２ＢＵＡとして動作させるためのＳＩＰルートの設定と、ＳＩＰ  Ｐｒｏｘｙとして動作しＢ２ＢＵＡを通らないようにＳＩＰルートの設定を行なう機能である。
【００２８】
ＩＭＳクライアントの機能情報保持機能２１ｅは、ＩＭＳクライアント機能確認機能で確認したＩＭＳクライアントの機能を保持する機能である。
【００２９】
以上のように構成されたネットワーク構成要素は、Ｂ２ＢＵＡがＩＭＳクライアントの機能に応じて動作を選択するために次の動作を行なう。
【００３０】
（Ａ）選択的Ｂ２ＢＵＡ２１は、ＳＩＰメッセージを受け取ると、そこで要求されている拡張機能を調べ、自身が対応できるものであるかを確認する。
【００３１】
（Ｂ）選択的Ｂ２ＢＵＡ２１は、自身が対応する機能であった場合は、相手のＩＭＳクライアントへＯＰＴＩＯＮＳリクエストによる機能確認を行なう。
【００３２】
（Ｃ）ＯＰＴＩＯＮＳリクエストが使用できない場合は、通常のＳＩＰリクエストにＲｅｑｕｉｒｅヘッダに確認機能を追記して機能の確認を行なう。
【００３３】
（Ｄ）選択的Ｂ２ＢＵＡは確認したＩＭＳクライアントの機能に基づき、自身を経由するＳＩＰルートと、自身を省略するＳＩＰルートの指定を行なう。
【００３４】
なお、選択的Ｂ２ＢＵＡ２１が有する「ＩＭＳクライアント機能確認機能２１ｃと、選択的ＳＩＰルート設定機能２１ｄと、ＩＭＳクライアントの機能情報保持機能２１ｅ」を、Ｓ−ＣＳＣＦ２３に持たせることも可能である。図３は、Ｓ−ＣＳＣＦ２３が「ＩＭＳクライアント機能確認機能２１ｃと、選択的ＳＩＰルート設定機能２１ｄと、ＩＭＳクライアントの機能情報保持機能２１ｅ」を有する形態を示す図である。この場合、機能確認、判断はＳ−ＣＳＣＦで行なわれ、必要がある場合のみ従来のＢ２ＢＵＡ２１’へ転送する方式となる。
【００３５】
図４および図５は、本実施形態において、ＩＭＳクライアント同士がＳＩＰメッセージを送受信する際に、双方の機能を確認してＢ２ＢＵＡの利用判断を行なうシーケンスチャートである。図４では、Ｂ２ＢＵＡを利用する場合のシーケンスチャートを示す。
【００３６】
（１）ＩＭＳクライアント（Ａ）は、ＩＭＳクライアント（Ｂ）に対してＳＩＰリクエストを送信する。このとき、必要な機能をＲｅｑｕｉｒｅヘッダに指定する。必須で無い場合はＳｕｐｐｏｒｔｅｄヘッダに自身がサポートする機能を指定する。本シーケンスでは、必要な機能としてAを指定しているが無指定でもよい。
【００３７】
（２）ＳＩＰリクエストはＳ−ＣＳＣＦからｉＦＣ（initial Filter Criteria）により選択的Ｂ２ＢＵＡへ転送される。
【００３８】
（３）選択的Ｂ２ＢＵＡは、ＩＭＳシステムが必要とする機能を端末が備えない場合に、それを吸収するために設定されている。例えばＳＩＰセッションのハンドオーバにはｒｅｐｌａｃｅ機能が必要である。選択的Ｂ２ＢＵＡはサポートすべき機能がＳＩＰリクエストのｓｕｐｐｏｒｔｅｄヘッダに入っていない場合には、すぐに自身を通過するようにＲｅｃｏｒｄ−Ｒｏｕｔｅに自身を記録し、Ｂ２ＢＵＡの動作を行なう。
【００３９】
（４）このシーケンスチャートでは、選択的Ｂ２ＢＵＡは機能Ａをサポートする。ＳＩＰリクエストのＳｕｐｐｏｒｔｅｄヘッダでＡがサポートされている場合は、次に送信先のＩＭＳクライアント（Ｂ）の機能を確認する。これはＯＰＴＩＯＮＳリクエストをＩＭＳクライアント（Ｂ）に送信して確認する。
【００４０】
（５）ＩＭＳクライアント（Ｂ）のＯＰＴＩＯＮＳ応答メッセージ中に、Ｓｕｐｐｏｒｔｅｄヘッダで機能Ａが指定されていない場合、選択的Ｂ２ＢＵＡは自身を経由するようにＲｅｃｏｒｄ−Ｒｏｕｔｅを設定し、Ｂ２ＢＵＡの処理を行なう。
【００４１】
（６）Ｂ２ＢＵＡの処理では、機能Ａをサポートするため、ＩＭＳクライアント（Ｂ）へ送信するＳＩＰリクエストのＲｅｑｕｉｒｅヘッダにAが指定されていれば、それを除いておく。
【００４２】
（７）以後のＩＭＳクライアント（Ａ）、（Ｂ）間の通信は、選択的Ｂ２ＢＵＡを介して通信を行なう。また、以後の新しいＳＩＰリクエストに関しては、保持している端末の機能に基づいて機能確認を省略して動作することが可能である。
【００４３】
図５では、ＩＭＳクライアントが双方共に機能を備えるため、Ｂ２ＢＵＡを利用しない場合のシーケンスチャートを示す。
【００４４】
（１）ＩＭＳクライアント（Ａ）は、ＩＭＳクライアント（Ｂ）に対してＳＩＰリクエストを送信し、ＯＰＴＩＯＮＳを用いて機能確認を行なうまでは上記Ｂ２ＢＵＡを用いる場合と同様である。
【００４５】
（２）ＩＭＳクライアント（Ｂ）のＯＰＴＩＯＮＳ応答中で、Ｓｕｐｐｏｒｔｅｄヘッダに機能Ａが指定されていた場合、Ｂ２ＢＵＡでの処理は必要ない。そのため、選択的Ｂ２ＢＵＡは、ＳＩＰリクエストに対して通常のＳＩＰプロキシとして動作し、またＲｅｃｏｒｄ−Ｒｏｕｔｅに自身を加えない。
【００４６】
（３）選択的Ｂ２ＢＵＡからＩＭＳクライアント（Ｂ）にＳＩＰリクエストが転送されると以後は選択的Ｂ２ＢＵＡを経由せずにＳＩＰメッセージの送受信が行なわれる。また、以後の新しいＳＩＰリクエストに関しては、保持している端末の機能に基づいて機能確認を省略して動作することが可能である。
【００４７】
ＯＰＴＩＯＮＳはＳＩＰクライアントの機能を調べるために有効な機能であるが、セキュリティ等の理由により使用できない場合もある。そこで、次に、通常のＳＩＰリクエストをそのまま用いて、クライアントの機能を調べる動作について説明する。
【００４８】
図６および図７は、通常のＳＩＰリクエストをそのまま用いて、クライアントの機能を調べる動作を示すシーケンスチャートである。図６では、Ｂ２ＢＵＡを利用する場合のシーケンスチャートを示す。
【００４９】
（１）ＩＭＳクライアント（Ａ）は、ＩＭＳクライアント（Ｂ）に対してＳＩＰリクエストを送信する。このとき、必要な機能としてＲｅｑｕｉｒｅヘッダに指定し、必須で無い場合はＳｕｐｐｏｒｔｅｄヘッダに自身がサポートする機能を指定する。本シーケンスではＲｅｑｕｉｒｅヘッダには何も指定していないが、指定しても良い。
【００５０】
（２）ＳＩＰリクエストはＳ−ＣＳＣＦからｉＦＣ（initial Filter Criteria）により選択的Ｂ２ＢＵＡへ転送される。
【００５１】
（３）選択的Ｂ２ＢＵＡは、受信したＳＩＰリクエストから自身の機能Ａがサポートされていることを確認する。サポートされていなければ、すぐに自身を通過するようにＲｅｃｏｒｄ−Ｒｏｕｔｅに自身を記録し、Ｂ２ＢＵＡの動作を行なう。
【００５２】
（４）ＳＩＰリクエストのＳｕｐｐｏｒｔｅｄヘッダで選択的Ｂ２ＢＵＡの機能であるＡがサポートされている場合は、次に送信先のＩＭＳクライアント（Ｂ）の機能を確認する。このために、一端Ｒｅｃｏｒｄ−Ｒｏｕｔｅに自身を記録せず、Ｒｅｑｕｉｒｅヘッダに調べたい機能Ａを指定してＩＭＳクライアント（Ｂ）に送信する。
【００５３】
（５）ＩＭＳクライアントが機能Ａをサポートしない場合、ＳＩＰリクエストに対して４２０  Ｂａｄ  Ｅｘｔｅｎｓｉｏｎが返される。Ｂ２ＢＵＡはそのエラーに対してＩＭＳクライアントの機能を保持し、ＩＭＳクライアント（Ａ）へ５０３  Ｓｅｒｖｉｃｅ  ＵｎａｖａｉｌａｂｌｅなどのエラーとＲｅｔｒｙ−ａｆｔｅｒヘッダで再試行を指定して応答する。この場合Ｒｅｔｒｙ−ａｆｔｅｒの時間は極力短くてよい。
【００５４】
（６）エラーを受信したＩＭＳクライアント（Ａ）は、Ｒｅｔｒｙ−ａｆｔｅｒで指定された時間後再度ＳＩＰリクエストを送信する。
【００５５】
（７）二度目のＳＩＰリクエストを受け取った選択的Ｂ２ＢＵＡは、ＩＭＳクライアント（Ｂ）が機能Ａをサポートしないことを保持している記録から判断し、自身を通るようにＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを指定して、Ｂ２ＢＵＡの処理を行なう。
【００５６】
（８）Ｂ２ＢＵＡの処理では機能Ａをサポートするため、ＩＭＳクライアント（Ｂ）へ送信するＳＩＰリクエストからＲｅｑｕｉｒｅヘッダにAが指定されていれば、それを除いておく。
【００５７】
（９）以後の通信は、ＩＭＳクライアント（Ａ）、（Ｂ）ともに選択的Ｂ２ＢＵＡを介して通信を行なう。また、以後の新しいＳＩＰリクエストに関しては、保持している端末の機能に基づいて機能確認を省略して動作することが可能である。
【００５８】
図７では、ＩＭＳクライアントが双方共に機能を備えるため、Ｂ２ＢＵＡを利用しない場合のシーケンスチャートを示す。
【００５９】
（１）ＩＭＳクライアント（Ａ）は、ＩＭＳクライアント（Ｂ）に対してＳＩＰリクエストを送信し、Ｒｅｑｕｉｒｅヘッダを用いて機能確認を行なうまでは上記Ｂ２ＢＵＡを用いる場合と同様である。
【００６０】
（２）ＩＭＳクライアント（Ｂ）へのＲｅｑｕｉｒｅヘッダにＡを追記したＳＩＰリクエストに対する応答で、２００ＯＫが戻ってきた場合、ＩＭＳクライアント（Ｂ）は機能Ａをサポートすると判断でき、選択的Ｂ２ＢＵＡは、応答メッセージをそのまま、ＩＭＳクライアント（Ａ）に転送する。このとき、Ｒｅｃｏｒｄ−Ｒｏｕｔｅには選択的Ｂ２ＢＵＡを記録していないままである。
【００６１】
（３）以後は選択的Ｂ２ＢＵＡを経由せずにＩＭＳクライアント間でＳＩＰメッセージの送受信が行なわれる。また、以後の新しいＳＩＰリクエストに関しては、保持している端末の機能に基づいて機能確認を省略して動作することが可能である。
【００６２】
以上説明したように、本実施形態によれば、Ｂ２ＢＵＡでの処理量を削減することが可能である。また、ＳＩＰ  ＵＡに拡張機能を加えることなく、ＳＩＰ  ＵＡの機能に基づいた選択が可能である。さらに、Ｂ２ＢＵＡ単体の機能で実現できるため、既存ＩＭＳシステムに変更を加えずに済む。
【符号の説明】
【００６３】
１ａ〜１ｃ  ＩＭＳクライアント
１ｄ  ＩＭＳクライアント機能
１０  アクセスネットワーク
２０  ＩＭＳコアネットワーク
２１  選択的Ｂ２ＢＵＡ
２１ｂ  ＳＩＰプロキシ機能
２１ｃ  ＩＭＳクライアント機能確認機能
２１ｄ  選択的ＳＩＰルート設定機能
２１ｅ  ＩＭＳクライアントの機能情報保持機能
２２  Ｐ−ＣＳＣＦ
２３  Ｓ／Ｉ−ＣＳＣＦ（Ｓ−ＣＳＣＦ／Ｉ−ＣＳＣＦ）
【図１】
2010239292.tif 000003
【図２】
2010239292.tif 000004
【図３】
2010239292.tif 000005
【図４】
2010239292.tif 000006
【図５】
2010239292.tif 000007
【図６】
2010239292.tif 000008
【図７】
2010239292.tif 000009