(57)【要約】  二者以上のパーティ（１０２）間の二者間通話、三者間通話、および電話会議の実施に用いられる音声インターネットプロトコル（ＶｏＩＰ）システム（２００）の構成が開示される。本システムには、新しい呼機能（２１０，２２０，２３０）が容易に適応される。本ＶｏＩＰシステム（２００）は、セッション開始プロトコル（ＳＩＰ）フレームワークに実装される。本ＳＩＰフレームワークには、分散型機能構成（ＤＦＣ）アーキテクチャの諸形態が修正・適用され、既存のＶｏＩＰフレームワークの適用性に存在する既知の制約が克服される。【特許請求の範囲】
【請求項１】
ネットワーク遠隔通信呼に使用する呼機能を確立する方法が、
着信するセッション開始プロトコル（ＳＩＰ）要求を受信するステップと、
ＳＩＰ要求のパラメータに基づいて適用される機能を決定するステップと、
前記機能に対応する機能ボックスを割り当てるステップと、
ＳＩＰ要求の少なくとも一部を分散型機能構成（ＤＦＣ）シグナリングメッセージに変換するステップと、
ＤＦＣシグナリングメッセージを用いて前記要求を前記機能ボックスにルーティングするステップと、
を備えることを特徴とする方法。
【請求項２】
請求項１の方法において、前記着信するＳＩＰ要求が、発呼側から着呼側へ送る呼要求を含むことを特徴とする方法。
【請求項３】
請求項２の方法において、前記パラメータが、発呼側のソースアドレスと着呼側のターゲットアドレスの内の少なくとも一つを含むことを特徴とする方法。
【請求項４】
請求項３の方法において、発呼側と着呼側の内の少なくとも一方が、適用される機能の加入者であることを特徴とする方法。
【請求項５】
請求項２の方法において、前記機能が、呼転送機能と三者間呼機能と呼会議機能との内の少なくとも一つを含むことを特徴とする方法。
【請求項６】
請求項２の方法において、前記機能に、着呼側の新しいターゲットアドレスが呼要求に適用される追い掛け（ｆｏｌｌｏｗ−ｍｅ）呼機能が含まれることを特徴とする方法。
【請求項７】
請求項６の方法において、前記追い掛け呼機能が、少なくとも二個の追い掛け機能ボックスで実装されることを特徴とする方法。
【請求項８】
請求項７の方法が、
前記少なくとも二個の追い掛け機能ボックスを用いて着呼側のターゲットアドレスの優先度を決定するステップをさらに含むことを特徴とする方法。
【請求項９】
請求項２の方法が、
前記ルーティングの後にＤＦＣシグナリングメッセージを発信ＳＩＰ要求に変換するステップと、
前記発信ＳＩＰ要求を着呼側に対応するターゲットアドレスにルーティングするステップと、
をさらに備えることを特徴とする方法。
【請求項１０】
請求項２の方法において、前記ＤＦＣシグナリングメッセージが、着信するＳＩＰ要求のシグナリング経路とメディア経路の識別子を含むことを特徴とする方法。
【請求項１１】
請求項１０の方法において、前記シグナリング経路が、機能ボックスを含む内部シグナリング経路を含み、前記メディア経路が呼要求に対応するメディアフローの外部経路を含むことを特徴とする方法。
【請求項１２】
請求項１の方法において、前記着信するＳＩＰ要求が、音声インターネットプロトコル（ＶｏＩＰ）呼要求を含むことを特徴とする方法。
【請求項１３】
請求項１の方法において、前記着信するＳＩＰ要求が、登録呼を含み、前記機能ボックスが、ＳＩＰ登録機能ボックスを含むことを特徴とする方法。
【請求項１４】
請求項１の方法において、前記決定するステップが、
呼に適用される機能のデータベースを照会するステップを備えること特徴とする方法。
【請求項１５】
請求項１の方法において、前記変換するステップが、
ＤＦＣシグナリングメッセージの少なくとも一つのフィールドにＳＩＰパラメータとして前記パラメータを記憶するステップをさらに備えることを特徴とする方法。
【請求項１６】
請求項１の方法において、前記ルーティングするステップが、
機能レス呼による呼を呼専用の機能ボックスにルーティングすることを特徴とする方法。
【請求項１７】
請求項１の方法において、前記機能が、呼に割り当てられる複数の機能を含むことを特徴とする方法。
【請求項１８】
請求項１７の方法において、前記ルーティングするステップが、
呼を複数の機能ボックスに既定の順序でルーティングするステップをさらに含み、各機能ボックスが複数の機能の一つに割り当てられていることを特徴とする方法。
【請求項１９】
請求項１８の方法において、前記ルーティングするステップが、
複数の機能ボックスの既定順序に基づいて複数の機能ボックスの第一番目に呼をルーティングするステップさらに備えることを特徴とする方法。
【請求項２０】
請求項１８の方法において、各前記機能ボックスが機能ボックスの割り当てられたゾーンに対応し、前記既定順序が割り当てられたゾーンの第一優先度に対応し、機能の第二優先度が割り当てられたゾーン各々内に割り当てられることを特徴とする方法。
【請求項２１】
請求項２０の方法において、前記割り当てられたゾーンが、ソースゾーンと、ダイアルされるゾーンと、ターゲットゾーンとを含むことを特徴とする方法。
【請求項２２】
請求項１の方法が、
呼の新しい機能を受信するステップと、
前記新しい機能に割り当てられた第二機能ボックスに呼をルーティングするステップと、
をさらに備えることを特徴とする方法。
【請求項２３】
遠隔通信呼をルーティングする方法が、
ＳＩＰパラメータを有するＤＦＣシグナリングメッセージを含む呼を受信するステップと、
呼を複数の機能ボックスに既定の順序でルーティングするステップと、を備え、
各機能ボックスが呼に割り当てられた機能に対応していることを特徴とする方法。
【請求項２４】
請求項２３の方法において、各前記機能ボックスが機能ボックスの割り当てられたゾーンに対応し、前記既定順序が割り当てられたゾーンの第一優先度に対応し、機能の第二優先度が割り当てられたゾーン各々内に割り当てられることを特徴とする方法。
【請求項２５】
着呼側に送られる呼要求を完結する方法が、
発呼側から着呼側に送信される呼要求に対応するＤＦＣシグナリングメッセージを複数の機能ボックスの最後のボックスから受信するステップと、
前記ＤＦＣシグナリングメッセージをＳＩＰ要求に変換するステップと、
前記ＳＩＰ要求を着呼側のターゲットアドレスに送信するステップと、
を含むことを特徴とする方法。
【請求項２６】
呼要求をルーティングする方法が、
発呼側から、追い掛け機能の加入者を含む着呼側に送られる着信ＳＩＰ呼要求を受信するステップと、
着信ＳＩＰ呼要求に対応するＤＦＣシグナリングメッセージを使用して追い掛け機能ボックスに呼要求をルーティングするステップと、
記憶されている着呼側優先順位に基づいて着呼側ターゲットアドレスの優先度を決定するステップと、
発呼側と着呼側の間の呼を確立する発信ＳＩＰ要求を生成するステップと、
を含み、前記発信ＳＩＰ要求が、着呼側の呼応答が得られるまで優先度に基づいて各ターゲットアドレスに順次送信されることを特徴とする方法。
【請求項２７】
ネットワーク遠隔通信呼に使用される呼機能を確立する装置が、
プロセッサと、
前記プロセッサと通信するメモリであって、プロセッサに、
着信セッション開始プロトコル（ＳＩＰ）呼要求を受信し、
前記ＳＩＰ要求のパラメータに基づいて適用される機能を決定し、
前記機能に対応する機能ボックスを割り当て、
前記ＳＩＰ要求の少なくとも一部を分散型機能構成（ＤＦＣ）シグナリングメッセージに変換し、そして
前記ＤＦＣシグナリングメッセージを用いて前記機能ボックスに呼をルーティングする、
ことを指示する複数の処理命令を記憶するメモリと、
を備えることを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般に電話通信、特にインターネットをベースとする遠隔通信マルチメディア通信に関する。
【背景技術】
【０００２】
音声インターネットプロトコル（ＶｏＩＰ）コミュニティは、インターネット上に実装された音声通信システムとアプリケーションを開発・改良し続け、公衆交換電話ネットワーク（ＰＳＴＮ）だけで通常利用可能な呼サービスを改良・強化することを目標としている。ＶｏＩＰのセッションの開始プロトコル（ＳＩＰ）は、一人または複数のユーザを含む呼セッションを生成し、修正し、終了する既存アプリケーション層ＶｏＩＰの一つである。そのようなＶｏＩＰのセッションには、インターネット電話ダイアログとセッション、マルチメディア分散、マルチメディア会議などが含まれる。既存のＳＩＰドメインでは、分散型プロキシサーバルートが、ユーザの現在ロケーションを要求し、多岐にわたるサービスに対してユーザを認証・許可し、プロバイダ呼ルーティングポリシーを策定し、ユーザに多岐にわたる呼機能を提供する。ユーザの現在ロケーションを要求する呼勧誘要求は、セッションを作成し、セッション記述を行うのに使用される。発呼側と着呼側とは、このセッション記述を用いて、マルチパーティ間通信を行うのに適切なメディアタイプについて同意することが可能になる。ＳＩＰは、また、三者間電話のような多岐にわたる呼機能に加入するユーザに対して登録機能を提供する。また、ＳＩＰ登録機能によって、ユーザは、現在ロケーションをアップロードし、ユーザのそのような呼要求を受信するプロキシサーバに使わせることが可能である。
【０００３】
ＰＳＴＮの進化の際に遭遇した問題と同じように、ＳＩＰに利用可能の呼機能の群に新しいオプションが次々に加えられると、新しく加わった呼機能の動作複雑性とそれに起因する既存呼機能との相互作用を適切に管理することがますます困難となる。
【０００４】
相互作用を適切に管理する分散型機能構成法（ＤＦＣ：Ｄｉｓｔｒｉｂｕｔｅｄ  Ｆｅａｔｕｒｅ  Ｃｏｍｐｏｓｉｔｉｏｎ）は、本願の発明者らが以前に開発したものであり、ＰＳＴＮ環境下のこの機能間相互作用問題を軽減するものである。ＤＦＣに関する説明の一つは、米国特許第６，４０４，８７８号と第６，１６０，８８３号に見出すことができる。両特許は本発明の出願人に譲渡されており、本明細書に参考文献として引用する。ＤＦＣを用いると、呼機能の修正と追加が可能であり、一方、思いがけない呼機能干渉やシステム不具合は最小限に抑えられる。これは、呼機能が、機能ボックスと総称される少数の物理コンポーネントで構成される仮想アーキテクチャであり、これら物理コンポーネントは、通信ネットワークを通じて機能レス内部呼で呼ルートに加えられ、既知のＰＳＴＮネットワーク機構で接続される。ユーザによる発呼は、既定の優先度で呼に割り当てられた適切な呼機能に専用の機能ボックス構造を構築することによって取り扱われる。
【０００５】
新しい所望の機能は、新しいコンポーネントを加えるに要する既定ルールに従い、可及的少数、好ましくはただ一個の新しいコンポーネントでＤＦＣ内に実装される。ＤＦＣのアーキテクチャ形式は、動的パイプ／フィルタ技術に類似である。この場合、機能ボックスはフィルタのようなものであり、機能ボックス間の内部機能レス呼接続は、パイプのようなものである。ＤＦＣ機能ボックスは、物理的に独立の実体であり、各々自己の状態を有し、他の機能ボックスとは状態を共有せず、隣接するコンポーネントの識別属性とは独立である。ＤＦＣ機能ボックスは、また、割り当てられた呼に完全専用であって、割り当てられた呼が終了またはキャンセルされた時だけ他の呼に利用可能となる。この独立性こそが、機能間相互作用を適切に管理するＤＦＣの能力に顕著に寄与するものではあるが、一方、大きなネットワークのユーザを収容するには大量の物理コンポーネントが必要にもなる。
【０００６】
ＤＦＣアーキテクチャは、ＳＩＰフレームワークにはそれほど単純には組み込み得ない。第一に、システムは、相異なるコンポーネント形式とシグナリングプロトコルを有する相異なるドメイン環境で処理されているからである。ある種のＤＦＣとＳＩＰハードウェアに対する要求項目もある種の組み込み領域では相矛盾することもある。しかし、ＳＩＰを改良して、その中に呼機能を容易に組み込むことが可能になるならば、確かに有用である。
【０００７】
サードパーティサービス技術、例えば、呼プロセス言語やＳＩＰ共通ゲートウェイインターフェイスが、多岐にわたる分散型コンポーネントアーキテクチャおよび機能相互作用プロトコル、例えば、ソフトウェアエンジニアリングリサーチライブラリ（ＳＥＲＬ）やサードパーティ呼制御（３ＰＣＣ）やアプリケーションサーバコンポーネント（ＡＳＣ）に加えて、ＶｏＩＰの性能を改良するために提唱されている。しかし、ＳＩＰにおける機能相互干渉問題に決定的に対処している技術は存在しない。
【０００８】
【特許文献１】米国特許第６，４０４，８７８号
【特許文献２】米国特許第６，１６０，８８３号
【発明の開示】
【課題を解決するための手段】
【０００９】
従って、本開示の目的は、改良されたＶｏＩＰ通信プロトコルに特定のコンポーネントに関するシステムであって、新しい呼機能に容易に適用可能のシステムを提供することである。特に、本発明の実施の形態の一つは、ＶｏＩＰドメイン内に一個または複数個の呼機能を確立し、ネットワーク遠隔通信上の呼を取り扱う方法と装置を含む。このドメインは、呼勧誘（ｉｎｖｉｔｅ）要求および他の呼要求を取り扱う既定のプロトコルを備える。ある種の実施の形態では、着信ＳＩＰ要求は、呼要求に対するシグナリングパスとメディアパスの識別子を備える内部ＤＦＣシグナリングメッセージに翻訳される。呼を適切な機能ボックスに内部ルーティングするのは、そのようなＤＦＣシグナリングメッセージを使用して行い得る。呼要求にある既存ＳＩＰパラメータは、この翻訳作業では変更されないで残る。機能ボックスは、割り当てられた呼機能と呼機能の既定優先度に基づいて呼要求に割り当てられる。
【００１０】
多岐にわたる実施の形態において、機能ボックスは、物理的に相異なる物理コンポーネントではなく、遠隔通信サーバなどの専用論理ユニットとして実装し得る。個々の機能ボックスは、呼が終了するまでは、呼要求に専用である。追い掛け（ｆｏｌｌｏｗ−ｍｅ）呼機能では、ユーザに呼要求を行う新しいアドレスがユーザのカスタマイズ可能優先順序に基づいて確立されるが、この追い掛け呼機能は、一個または複数個の追い掛け機能ボックスによって実装し得る。
【００１１】
さらに他の実施の形態では、呼要求に対応するメディアフローは、呼の両エンドポイント間に直接ルーティング可能であり、このルートは、機能レス呼用の機能ボックスの専用とすることが可能である。
【発明を実施するための最良の形態】
【００１２】
本開示のさらなる態様は、添付図面を参考にして、多岐にわたる実施の形態の以下の詳細な説明を吟味すれば、さらに容易に理解されよう。
【００１３】
さて、本開示の同じようなコンポーネントは同じような参照番号が付されている図１〜６を参照すると、セッション開始プロトコルを使用する遠隔通信ネットワークシステムと通信サービス方法が開示されている。ＳＩＰとＤＦＣシステムの既存の構造も、より詳細に説明し、従来のスキームと本開示のそれらと間の相違を明快に示すものとする。本明細書に記載のある種の機能を可能とするために用い得る従来のエレメントも同様に記載する。
【００１４】
ＳＩＰの従来の実装は、一組の大略独立の処理段階を一緒に結合した階層型プロトコルとして構成されている。このようにプロトコル動作を階層として記述するのは、説明目的で行われるにすぎず、決して実装に必要な機能として述べるものではない。各層は、その層で定義される一組の既定ルールに準拠する。ＳＩＰプロトコルで規定された物理コンポーネントすべてが層すべてを使用するとは限らない。さらに、ＳＩＰで規定されたエレメントは論理エレメントであり、物理エレメントではない。もっとも、物理的実現は、物理的に明確な論理ハードウェアエレメントを使用し、トランザクション毎をベースとすれば、可能である。既存のＳＩＰ環境は、以下では使用ハードウェアのタイプとこれらのコンポーネント間の通信フォーマットに関して簡単に記載する。ＳＩＰの完全な記述については、ｈｔｔｐ：／／ｗｗｗ．ＩＥＴＦ．ＯＲＧにアクセスすれば見出し得る。
【００１５】
ＳＩＰの第一プログラム層はそのシンタクスとエンコード層である。エンコードは、標準メッセージ構造を備える拡張型バッカス・ナウア形式（ＢＮＦ）文法を用いて規定される。
【００１６】
第二層は、クライアントとサーバがネットワーク上でどのように要求を送信し、応答を受信するかを規定するトランスポート層である。ＳＩＰエレメントはすべてトランスポート層を含む。
【００１７】
第三層はトランザクション層である。トランザクションは、トランスポート層を用いてサーバへクライアントから送信される呼要求であり、サーバトランザクションからクライアントへ送信される呼への応答を一緒に含む。このトランザクション層は、クライアントトランザクションとサーバトランザクションとを網羅するもので、各トランザクションは、ＳＩＰコンポーネント、例えば、特定の要求を処理するために専用の有限ステートマシン（ＦＳＭ）によって実施される。トランザクション層は、アプリケーション層再伝送、応答の要求への翻訳、およびアプリケーション層タイムアウトを取り扱う。ユーザエージェント（ＵＡ）が行うタスクは、以下にさらに記載されるように、一連のクライアント／サーバトランザクションを使用して行い得る。ＳＩＰでは、ＵＡは、ＳＩＰステートフルプロキシと同様に、トランザクション層を含む。しかし、ステートレスプロキシは、トランザクション層を含まない。
【００１８】
第四層は、トランザクションユーザ  （ＴＵ）  層である。ＳＩＰエンティティ各々は、ステートレスプロキシを除いて、ＴＵと指定される。クライアントＴＵが呼要求を送信したいとき、クライアントトランザクションインスタンスを生成し、着信先ＩＰアドレス、ポート、およびトランスポートと共にリクェストを送信する。
【００１９】
クライアントトランザクションを行うＴＵはこれをキャンセルすることも可能である。クライアントがトランザクションをキャンセルするときは、サーバがそれ以上処理することを停止し、トランザクション開始前に存在した状態に戻し、そのトランザクションに特有なエラー応答を生成するようにクライアントは要求する。これは、自己トランザクションを構成するＣＡＮＣＥＬ要求で行われる。
【００２０】
ＳＩＰコンポーネントは、ＵＡクライアントとサーバ、ステートレスとステートフルプロキシとレジストラを含んで、他の各々から自己を区別するコアを含有する。コアは、ステートレスプロキシを除いて、環境内でＴＵとして作動し、ＴＵ層を用いる。ＵＡクライアント／サーバのコア動作は特定のトランザクション状況に依存するが、一方、両者に適用可能の共通ルールも幾つか存在する。ＵＡクライアントに対しては、これらルールが呼要求の構造を支配し、ＵＡサーバに対しては、一般に、これらルールが呼要求の処理と呼要求に対する応答の生成を支配する。
【００２１】
ユーザの登録は、ＳＩＰアプリケーションに重要な役割を果たす。従って、ＳＩＰレジストラ（ＲＥＧＩＳＴＲＡ）と称される専用のＵＡサーバが指定され、レジシタ（ＲＥＧＩＳＴＥＲ）要求を取り扱う。
【００２２】
認証されない要求の悪意ある洪水は、サービス拒否アタックとして知られるが、これを避けるため、ステートレスＵＡを使用し、認証されない要求を処理し、チャレンジ応答を出す。ステートレスＵＡは通常のように要求に応えるが、応答が送られた後にはＵＡサーバに普通は保持される筈のステートは無視する。ステートレスＵＡサーバは要求の再伝送を受信すると、あたかも要求の最初の場合に返答しているかのように、応答を再生成し、これを再送する。ステートレスＵＡサーバは、トランザクション層を使用しない。その代わり、トランスポート層から直接要求を受信し、トランスポート層に応答を直接送信する。
【００２３】
バック・ツー・バックユーザエージェント（Ｂ２ＢＵＡ）は、呼要求を受信し、これをＵＡサーバとして処理する論理エンティティである。要求にどのように応答すべきかを決定するため、それはＵＡクライアントとして作動し、要求を生成する。プロキシサーバと異なって、それはダイアログ状態を維持し、確立したダイアログ上に送られたすべての要求に参加しなければならない。
【００２４】
ＳＩＰで最も重要なメソッドは、ＩＮＶＩＴＥメソッドであり、これはユーザ間にセッションまたはダイアログを確立するために使用される。ダイアログは両ユーザエージェント間のピア・ツー・ピアＳＩＰ関係で、これはある時間だけ存在する。このダイアログを用いると、メッセージの順次表示と、ユーザエージェント間の要求の適切なルーティングとが容易に行われる。セッションは、参加人員の集合と、それらの間のメディアフローのストリームである。セッションは、一個または複数個のＳＩＰダイアログを含み得る。
【００２５】
ステータスコードは、呼要求に応答する試みの結果を示すためにＳＩＰで発生される３桁の整数である。この３桁システムは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）環境に使用されるシステムと類似性を有する。ステータスコードの最初の桁は特定のクラスの応答に割り当てられる。後の二桁は、特定クラスの個々の応答を識別するシーケンス的役割のみを有する。１００〜１９９の間のステータスコードを有する応答は、「１ｘｘ応答」と称され、２００〜２９９の間のステータスコードを有する応答は、「２ｘｘ応答」と称され、以下同様である。ＳＩＰでは最初の桁に６個の値が可能であり、ＳＩＰは以下のように数字１〜６に割り当てられたクラスを有する。
１ｘｘ：要求が受理され、ＵＡが引き続いて要求を処理していることを示す暫定応答。
２ｘｘ：呼要求が、成功裡に受信され、理解され、受理されられたことを示す成功応答クラス。
３ｘｘ：呼要求を完結するにはさらなるアクションを取る必要があることを示すリダイレクション応答。
４ｘｘ：要求が不正シンタックスを含んでいるか、あるいはＵＡでは実現し得ないことを示すクライアントエラー応答。
５ｘｘ：ＵＡが表面的には正しい要求の実現に失敗したことを示すサーバエラー応答。
６ｘｘ：要求の実現がどのサーバでも行い得ないことを示すグローバル失敗応答。
【００２６】
理由フレーズは、人間のオペレータまたはユーザにステータスコードの短いテキスト記述を与えるためである。各ステータスコードはまた、受信したコードに応答して取る適切なアクション（これは特記なき限りデフォルトアクション）を定める。容易に明らかであるが、ＳＩＰコンポーネントは理由フレーズを調べたり、これを表示したりする必要はない。理由フレーズの具体的な表現様式に係わる以下のチャートは、多岐にわたる実施の形態では、変更も一部省略も可能である。
（表１）
ステータス      理由フレーズ アクション
コード    
１００          試行(TRYING)                  INVITEの再送の停止
１８０          呼び出し(RINGING)             多くのステータスメッセージを
上流に送信
１８３          セッション進行                ヘッダフィールドまたはメッセージ
ボディを用いて呼進行に関して詳細を
伝送可能
２００          ＯＫ
３ｘｘ          警告コード(WARNING CODE)
４００          不正要求(BAD REQUEST)
４０１          非認証(UNAUTHORIZED)
４０２          支払い必要
(PAYMENT REQUIRED)
４０３          禁止(FORBIDDEN)
４０４          所在不明(NOT FOUND)           所在不明ステータスメッセージを
送り、その後ティアダウン
４０５          メソッド不許可
(METHOD NOT ALLOWED)
４０６          不受理(NOT ACCEPTABLE)
４０７          プロキシ認証必要
(PROXY AUTHENTICATION
REQUIRED)
４０８          要求タイムアウト
(REQUEST TIMEOUT)
４０９          衝突(CONFLICT)
４１０          所在行方不明(GONE)
４１３          要求エンティティ過大
(REQUEST ENTITY TOO LARGE)
４１４          要求ＵＲＩ長過ぎ
(REQUEST URI TOO LONG)
４１５          非サポートメディア形式
(UNSUPPORTED MEDIA TYPE)
４２０          不正エクステンション
(BAD EXTENTION)
４８０          一時利用不可能
(TEMPORARILY UNAVALABLE)
４８１          コールレグ／トランザクション存在せず
(CALL LEG/BRANSACTION
DOES NOT EXIST)
４８２          ループ検出(LOOP DETECTED)
４８３          ホップ数過大(TOO MANY HOPS)
４８４          アドレス不完全
(ADDRESS INCOMPLETE)
４８５          不明瞭(UMBIGUOUS)
４８６          当方お話し中(BUSY HERE)
４８７          要求終了(REQUEST TERMINATED)
４８８          ここでは不受理
(NOT ACCEPTABLE HERE)
５００          サーバ内部エラー
(SERVER INTERNAL ERROR)
５０１          不実装(NOT IMPLEMENTED)
５０２          不正ゲートウェイ(BAD GATEWAY)
５０３          サービス利用不可能
(SERVICE UNAVAILABLE)
５０４          サーバタイムアウト
(SERVER TIME-OUT)
５０５          非サポートバージョン
(VERSION NOT SUPPORTED)
５１３          メッセージ長過ぎ
(MESSAGE TOO LONG)
６００          どこもお話し中
(BUSY EVERYWHERE)
６０３          拒否(DECLINE)              チャネルすべてに拒否メッセージを
送信し、その後ティアダウン
６０４          どこにも存在せず           不知ステータスメッセージを
(DOES NOT EXIST            送信し、その後ティアダウン
ANYWHERE)
８０６          不受理((NOT ACCEPTABLE)
【００２７】
ＳＩＰヘッダフィールドは、シンタックスとセマンティックス両面でＨＴＴＰヘッダフィールドと類似性がある。特に、ＳＩＰヘッダフィールドは、メッセージヘッダと多重ラインにヘッダフィールドを拡張するためのルールに対してはシンタックスの定義に従う。プロキシ処理に必要なヘッダフィールド、例えば、ｖｉａ，  ｒｏｕｔｅ，  ｒｅｃｏｒｄ−ｒｏｕｔｅ，  ｐｒｏｘｙ−ｒｅｑｕｉｒｅ，  ｍａｘ−ｆｏｒｗａｒｄｓ，  ｐｒｏｘｙ−ａｕｔｈｏｒｉｚａｔｉｏｎは、急速解析を容易にするためＳＩＰ要求のトップに置かれる。
【００２８】
セッションまたはダイアログの詳細、例えば、メディアのタイプ、コーデック、またはサンプリング速度などは、ＳＩＰを用いては記述されない。むしろ、ＳＩＰメッセージのボディは、一般に他のプロトコルフォーマット、例えば、セッション記述プロトコル（ＳＤＰ）でエンコードされ、ＳＩＰメッセージに含まれるセッション説明を含む。
【００２９】
ＤＦＣの既存の実装は、主にＰＳＴＮとＶｏＩＰドメイン上に展開することを意味する。機能ボックス間および／または他のＤＦＣコンポーネント間の呼のルーティングは、ルータの責任である。ユーザのサービス要求は普通発呼側のトランクインターフェイス（ＴＩ）ボックスを作動させてセットアップメッセージをＤＦＣルータに送らせる。セットアップメッセージは、内部呼を生成させる要求である。ルータは、呼を機能ボックスにルーティングする。機能ボックスは呼を受信し、インターフェイスボックスと機能ボックスとを結合することによって内部呼をセットアップするプロトコルを完結する。普通、着信する内部呼を受信する機能ボックスは、対応する発信内部呼を掛ける。この発信呼は、着信呼の一部として受信されたセットアップメッセージを用いて掛けられ、着信呼の継続したものと考えられる。これにより、機能ボックスと内部呼のチェーンが生成され、同チェーンは、すべての適用可能の機能ボックス経由で呼の最終ターゲットアドレスのＴＩボックスに延びる。
【００３０】
このようにしてアセンブルされた機能ボックスのチェーンは、三個のゾーンに機能ボックスを含む。第一には、当該チェーンのソースアドレスで加入された機能ボックスであって、加入アドレスがソースアドレスであるどの呼にも適用可能な機能ボックスから成るソースゾーン（Ｚ１）がある。第二には、ネットワークに存在が要求される機能ボックスから成るネットワークゾーン（Ｚ２）がある。第三には、当該チェーンのターゲットアドレスで加入された機能ボックスであって、加入アドレスがターゲットアドレスであるどの呼にも適用可能な機能ボックスから成るターゲットゾーン（Ｚ１）がある。各ゾーンでは、機能ボックスの順序は、固定の優先順序で決定される。
【００３１】
ゾーンに最初の機能ボックスをルーティングする前に、ＤＦＣルータは、ゾーンの機能ボックスタイプのルーティングリストを作成し、これをセットアップメッセージに挿入する。ルータがセットアップメッセージを機能ボックスにルーティングするとき、機能ボックスのそのタイプをルーティングリストの頭の部分から除去する。このリストは、機能ボックスによって継続呼のセットアップメッセージにコピーされ、その結果、ルータは、今リストの頭にある機能ボックスタイプに継続呼をルーティングする。ルーティングリストの参照が終了すると、このゾーンは、終わる。このようにして、既定の順序で既定のボックスタイプをすべて備えた機能ボックスのチェーンがアセンブルされる。
【００３２】
同時係属米国特許第６，４０４，８７８号と第６，１６０，８８３号の多くの関連部分に記載されたＤＦＣの実装を本明細書に参考文献として引用する。同特許に詳細に記載されているように、新しい呼機能は、ＤＦＣ環境内に自由に付加、または修正し得るし、新しい呼機能に対する機能規定細目データ（ゾーン割当と優先度を含む）も、容易に統合し得る。
【００３３】
さて、図１を参照すると、ＩＰネットワーク１００上に分散型モジュール式成分通信サービスを提供するためのＩＰ合成環境下階層構造拡張通信（ＥＣＬＩＰＳＥ；Ｅｘｔｅｎｄｅｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｌａｙｅｒｅｄ  ｏｎ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｓｙｎｔｈｅｓｉｓ  Ｅｎｖｉｒｏｎｍｅｎｔ）ドメイン２００が示されている。ＩＰネットワークは、物理的および／またはワイヤレス伝送メディア、および処理命令を記憶して本明細書に記載の関数を実行するためのマイクロプロセッサとメモリを備えるハードウェアを含むどのようなタイプの通信および／またはコンピュータネットワークでも差し支えない。ＩＰネットワーク１００内のＥＣＬＩＰＳＥドメイン２００により、呼機能の急速展開と統合、サードパーティサービス、ユーザカスタマイズ、およびＳＩＰ環境下の多重ドメインとノード間の通信が可能となる。多重ＥＣＬＩＰＳＥドメイン２００間の機能相互作用の管理は、標準ネットワーキングトポロジーで行うことができる。
【００３４】
ＥＣＬＩＰＳＥドメイン２００は、有限ステートマシン（ＦＳＭ）抽象と呼機能の細目規定と開発に必要なドメイン専用言語とを提供する。ＥＣＬＩＰＳＥドメイン２００は、多くのサードパーティ通信プロトコル、例えば、Ｈ．３２３とＡＭＥＲＩＣＡ  ＯＮＬＩＮＥ  ＴＯＣ  プロトコルで動作可能である。ＥＣＬＩＰＳＥドメイン２００はさらに、メディア処理機能を果たすためのメディアリソースに対するインターフェイス、管理とユーザ自己用意機能のためのＨＴＴＰインターフェイス、フォルト管理、およびデータベース支援を提供する。ＥＣＬＩＰＳＥは、機能ボックスによる分散型メディア制御を可能とするメディア抽象通信層で動作する。これらの機能各々については、より詳細には以下の図２に記載される。
【００３５】
ＥＣＬＩＰＳＥドメイン２００は、複数のＳＩＰ  ＵＡ１０２，１０３と直接に、また複数のＳＩＰプロキシサーバ１０４とネットワークルータ１０４経由で通信し得る。ＩＰネットワーク１００の限定された数のコンポーネントが図１には示されているけれども、任意の個数のそのようなコンポーネントを備え得ることは容易に理解される筈である。さらに、ＩＰネットワーク１００のどのコンポーネントも他のどのコンポーネントと直接に、または多岐にわたる利用可能な中間コンポーネント経由で通信し得ることは技術に周知である。ＥＣＬＩＰＳＥドメイン２００は、大量の同時および順次呼要求を、ユーザの国家レベルまたは世界レベルネットワークの規模で取り扱い得るし、メッセージヘッダ情報に基づいた呼要求を識別し得なければならない。さらに、認識しなければならないことは、ＳＩＰ  ＵＡ１０２，１０３が図１では呼エンドポイントとして示されているが、追加のクライアントＴＩをＩＰネットワーク１００上の呼のエンドポイントとして含め得るということである。
【００３６】
ＥＣＬＩＰＳＥドメイン２００は、複数のヘッダとフィールドを使用して関連する通信情報を伝えるＳＩＰと同様なメッセージ構造で動作する。ＥＣＬＩＰＳＥドメイン２００は、呼要求をルーティングする目的のため標準ＳＩＰヘッダすべて、例えば、ｖｉａ，  ｒｅｃｏｒｄ−ｒｏｕｔｅ，  ｒｏｕｔｅを認識しなければならない。
【００３７】
ＥＣＬＩＰＳＥドメイン２００は、多くの点でステートフルＳＩＰプロキシサーバの一般機能を果たす。標準機能レスＳＩＰプロキシサーバのように、ＥＣＬＩＰＳＥドメイン２００は、ＤＦＣシグナリングメッセージ内に受信されたすべてのＳＩＰヘッダ情報の値を保存しなければならない。ＥＣＬＩＰＳＥドメイン２００内の機能ボックス、特に図２に関して以下に記載のものは、機能関連のどんな情報をも取り扱うように割り当てられ得る。
【００３８】
以前ＳＩＰでは、一般に、呼のメディアフローがＳＩＰプロキシサーバ内を通ってルーティングされることはない。このことは、機能レス呼に対しては、メディアフローを直接に、二個の呼エンドポイント、例えば、発呼側と着呼側のＴＩまたはＳＩＰ  ＵＡ１０２，１０３の間に流すことが、より効率的であるからである。本開示の機能レス呼では、新しい呼機能が呼び出され、後でメディアフローの制御が必要となるとき、ＥＣＬＩＰＳＥドメイン２００が、ＲＥ−ＩＮＶＩＴＥ要求を用いてメディアフローの制御を行い得る。このことについては以下に詳細に記載する。
【００３９】
従来のＳＩＰドメインと本開示のＳＩＰドメインの双方では、ドメインエンドポイントは、同一の機能を果たし、メディアフローに関して同様な応答を生成する。しかし、割り当てられた呼機能を有する呼では、ＥＣＬＩＰＳＥドメイン２００がそのような機能に関するメディアフローを制御する必要が生じることもあるので、この場合はメディアフローがその中を通ってルーティングされる。
【００４０】
呼のメディアフローを受信する前述のＳＩＰ  ＵＡと同様に、ＥＣＬＩＰＳＥドメイン２００は、また、呼を開始することも、終了することも可能である。例えば、ＥＣＬＩＰＳＥドメイン２００は、会議機能をセットアップし、多くのパーティに会議に参加するようにＩＮＶＩＴＥ要求を送信することができる。従って、ＥＣＬＩＰＳＥドメイン２００は、既存ＳＩＰ  ＵＡのある種の機能を組み入れている。
【００４１】
さて、図２を参照すると、ＥＣＬＩＰＳＥドメイン２００の多岐にわたるコンポーネントが特定の実施の形態に関して記載されているが、本発明を実施するのに用いられる唯一の構成と見てはならない。ある種の実施の形態では、ＥＣＬＩＰＳＥドメイン２００は、複数のＳＩＰ  ＴＩ２０２と２０３、一個または複数個のルータ２０４、データベース２０８，および複数の機能ボックス２１０，２２０，２３０を備え、これら機能ボックスは先ずゾーン（Ｚ１，Ｚ２，Ｚ３）で優先度が決定し、それぞれのゾーン内で既定の優先度を有し、機能相互作用が干渉なしに行い得るようになっている。機能ボックス２１０〜２３０は、別個の物理的コンポーネントに内蔵することも、または単一のネットワーク遠隔通信サーバ内の論理コンポーネントとして構成することもできる。機能ボックス２１０〜２３０は、各々ＥＣＬＩＰＳＥドメイン２００で取り扱われる呼に割り当てられ、発呼側または着呼側ユーザが呼に必要な呼機能を提供する。
【００４２】
機能ボックス２１０〜２３０とＳＩＰ  ＴＩ２０２と２０３との間の呼は、機能レス呼である。多岐にわたる機能ボックスをシステム内に設け、多数の呼機能を果たさせ得る。さらに、機能ボックスは、ルーティングに動的に影響を与えることによって、セッションの構成にアセンブルされた機能ボックスを変更することができる。例えば、ターゲットゾーンの機能ボックスが呼を続けるが、ターゲットアドレスを変更すると、ＤＦＣルータは以前のターゲットアドレスの機能ボックスへのルーティングを停止し、新しいターゲットアドレスのターゲットゾーン機能ボックスにルーティングを開始する。
【００４３】
このように、新しいサードパーティ呼機能が、ＥＣＬＩＰＳＥドメインに新しい機能ボックスを幾つか設けるとともにこれらの位置を優先順に規定することによって容易に構成される。これにより、新しい機能を既存の呼機能とともに用いることが可能となり、これらの統合には追加の努力は不要となる。従って、呼機能を動的に組み立てて自動的に統合するという能力は、このような能力を備えていない既存ＳＩＰプロキシサーバとは相異なるものである。機能ボックスは、登録、認証、および特定のＳＩＰ応答コードの処理を取り扱い、他の呼機能、例えば、以下の図３に関して記載の追い掛け電話機能を提供するために設けることができる。ＳＩＰ  ＴＩ２０２と２０３は、ＥＣＬＩＰＳＥドメイン２００のエンドポイントとして作用し、ＩＰ遠隔通信ネットワーク１００上でシグナリングメッセージを送信し、受信する。ラインインターフェイスとトランクインターフェイスとは同じような機能を果たすので、ＳＩＰ  ＴＩ２０２／２０３は、任意の数のＳＩＰ  ＴＩまたはＬＩで構成し得る。ＳＩＰ  ＴＩ２０２と２０３は、論理的に別個のコンポーネントでも、統合された装置のそれぞれのコンポーネントであっても差し支えない。諸機能とＳＩＰ  ＴＩ２０２と２０３とを備えるＥＣＬＩＰＳＥドメイン２００は、機能ボックス２１０〜２３０で理解できるように着信するＳＩＰ要求をＤＦＣシグナリングメッセージに翻訳可能である。
【００４４】
オリジナルのＳＩＰメッセージは、ＳＩＰ  ＴＩ２０２が発行するＤＦＣメッセージのパラメータとして含ませておくことができる。ＳＩＰ認知機能ボックス（図示せず）は、オリジナルのＳＩＰメッセージを調べ、ＳＩＰ特有の処理を行うことができる。
【００４５】
ルータ２０４は、シグナリングメッセージで受信したソースアドレス、ターゲットアドレス、およびダイアルされたアドレスに基づいてメッセージをルーティングするために設けられる。任意の数のルータ２０４を設け、適切な呼容量を処理することができる。機能レス呼などの場合は、メディアフローは、メディアスイッチ２０６と２０７を使ってＳＩＰ  ＵＡ１０２間を直接ルーティングし得る。メディアスイッチは、一般にリアルタイムプロトコル（ＲＴＰ）パケットとして呼のメディアフローをルーティングし、転送する。
【００４６】
データベース２０８は、ユーザ情報、例えば、用意されたユーザ、ユーザ相互間に適用される呼機能、およびユーザへの呼がリダイレクトされるアドレスの好ましい優先度を記憶するため、ＥＣＬＩＰＳＥドメイン２００内に設けられる。
【００４７】
ＥＣＬＩＰＳＥドメイン２００は、新しいユーザを用意したり、ユーザの好みを変更したりするすべての登録要求を取り扱い、既存レジストラとして部分的に機能する。ある種の実施の形態では、登録は、ＳＩＰ  ＴＩ２０２と２０３によって、あるいは登録要求専用の別個のＴＩまたはＬＩ（図示せず）によって取り扱うことができる。
【００４８】
ＥＣＬＩＰＳＥドメイン２００は、また、遠隔通信サービスには普通のことであるが、ユーザのサードパーティ登録を、受け取ったユーザ情報に基づいて加入者ユーザが直接行う登録から区別し得るようにしなければならない。例えば、発信元（ＦＲＯＭ）ヘッダが登録を行うサードパーティのユニフォームリソース識別子（ＵＲＩ）を含んでいる登録要求であって、着信先（ＴＯ）アドレスが発信元（ＦＲＯＭ）ヘッダとは相異なる（同じＵＲＩでなく加入者のＵＲＩを含む）登録要求は、サードパーティ登録と認識される。
【００４９】
ＥＣＬＩＰＳＥドメイン２００は、また、前述のＳＩＰ  Ｂ２ＢＵＡの機能の多くを備え、インバウンドとアウトバウンドＳＩＰ  ＵＡを幾つか鎖状に連結し、各々相互と機能ボックス２１０〜２３０とＤＦＣルーティング信号経由で通信するものとして考え得る。これにより、ＥＣＬＩＰＳＥドメイン２００は、メディアフロー制御に必要な呼機能フレキシビリティを得ることができる。また、Ｂ２ＢＵＡ機能をＥＣＬＩＰＳＥドメイン２００内に確立すると、ＥＣＬＩＰＳＥドメイン２００の呼エンドポイントの複雑性が簡素化される。例えば、呼が携帯電話のような移動装置からの場合、ＥＣＬＩＰＳＥドメイン２００のエンドポイントの一つが、他のエンドポイントに通知することなく、呼のＩＰアドレスの変更を受信できる。
【００５０】
ＥＣＬＩＰＳＥドメインをＢ２ＢＵＡとして処理すると、ある種の実施の形態では、ドメイン２００が呼シグナルをリレーするとき、機能関連情報のヘッダを含み、幾つかのＳＩＰメッセージヘッダを変更する必要が生じる。例えば、着信勧誘呼要求中の連絡先ヘッダは、呼要求が転送されるとき、ドメイン２００のアドレスに変更できる。別法としては、アドレスは変更しないで置いて、しかし、その代わり、ホストとポートの指定を変更できる。
【００５１】
ユーザ登録は、ＥＣＬＩＰＳＥドメイン２００で以下のように行われる。登録要求は、ソースゾーン（Ｚ１）で優先順位付けされているＳＩＰ登録機能ボックス２１０で取り扱われる。登録されたユーザは、ＥＣＬＩＰＳＥドメイン２００に以降の登録（ＲＥＧＩＳＴＥＲ）要求を送信して呼連絡先情報を変更できる。ＳＩＰ登録機能ボックスは、受信した連絡先情報をデータベース２０８に記憶し、後でＺ３中の追い掛けボックスでこれを使用する。ＳＩＰ登録要求がＳＩＰ  ＴＩ２０２または２０３に到着すると、セットアップメッセージを、ソースアドレス、空のターゲットアドレス、およびダイアルされた文字列フィールドとして着信先（ＴＯ）ヘッダ付でルータ２０４に送信することによって、ＳＩＰ登録機能ボックスのようなソースゾーン機能ボックスのみが呼び出される。セットアップまたはユーザステータスメッセージに規定された着信先（ＴＯ）ヘッダは、用意されたアドレスでなければならない。
【００５２】
ＥＣＬＩＰＳＥドメイン２００で取り扱われる呼要求の他の一つタイプは、呼を確立するＩＮＶＩＴＥ要求である。
（表２）
ECLIPSE中のフィールド SIP INVITEメッセージ中のヘッダ
セットアップメッセージ
ソースアドレス                  FROM
ターゲットアドレス              REQUEST  URI
ダイアルされる文字列            TO
ＩＮＶＩＴＥがインバウンドＳＩＰ  ＴＩ２０２で受信されるとき、要求のソースアドレス、要求のターゲットアドレス、および呼のためのダイアルされた文字列またはダイアルされた番号を含むセットアップメッセージが形成される。次にこのセットアップメッセージが、呼機能を確立するための適切な機能ボックス２１０〜２３０を割り当てるルータ２０４にルーティングされる。ＩＮＶＩＴＥメッセージ中のセッション記述プロトコル（ＳＤＰ）情報は呼セットアップの後にメディアスイッチに送信される。呼は、最終的にアウトバウンドＳＩＰ  ＴＩ２０３にルーティングされ、その結果、ＩＮＶＩＴＥ要求が適切な連絡先アドレスにルーティングされる。
【００５３】
着信するＩＮＶＩＴＥ要求に対して、発呼側が規定するすべてのメディアは、メッセージの内容に示され、インバウンドＳＩＰ  ＴＩ２０２によってセットアップメッセージのメディア選択フィールドに入れられる。勧誘された加入者に対する発信ＩＮＶＩＴＥ要求は、二つのやり方で取り扱うことができる。第一のオプションは、アウトバウンドＳＩＰ  ＴＩ２０３が、勧誘された加入者に対して発呼側が選択したメディアでＩＮＶＩＴＥ要求を送ることができることである。着呼側は、着呼側の能力に基づいて上記メディア選択を受け取らなくても、一部受け取っても、全部受け取ってもよい。これらのメディア選択に対応する一個または複数個の受諾または拒絶メッセージを、発呼側に返信することができる。
【００５４】
他のオプションは、アウトバウンドＳＩＰ  ＴＩ２０３がＩＮＶＩＴＥ要求をＳＤＰなしで着呼側に送信するということである。応答を受信すると、次に着呼側のメディア選択で後刻可能メッセージなどを送信することができる。次いで発呼側は利用可能な好ましいメディアを選択し、確認（ＡＣＫ）メッセージなどのＳＤＰでメディア選択を通信する。これにより、発呼側は、着呼側が登録した連絡先アドレスのパラメータをチエックする必要なしに、メディア選択を行う前に着呼側の能力を知ることが可能となる。
【００５５】
ＥＣＬＩＰＳＥドメイン２００は、多くの理由でＲＥ−ＩＮＶＩＴＥ呼要求を受信することができ、ＲＥ−ＩＮＶＩＴＥの理由に基づく既定の応答を行う。例えば、リモートユーザがＩＰアドレス（すなわち、移動電話システムで）を変更した場合、ＥＣＬＩＰＳＥドメイン２００は、当該呼には他の加入者のＳＩＰ  ＵＡを通知しない。ＥＣＬＩＰＳＥドメイン２００は、コーデックが変更されたかどうかを、勧誘されたパーティに通知するか、通知しないかいずれにも適応可能とすることができる。しかし、ＥＣＬＩＰＳＥドメイン２００は、メディアが呼に関して追加されたり、除外されたりされたかどうかを、勧誘されたパーティに通知する。
【００５６】
極めて多岐にわたる呼機能を本明細書に開示のシステムに追加したり、組み入れたりすることが容易にできる。そのような呼機能の一つは、追い掛け呼機能で、着呼側アドレスに掛けられる呼が、ユーザが確立した優先度で一個または複数個のアドレスに自動的にリダイレクトされ得る機能である。優先度とリストアップされたアドレスとには、好ましい優先度が正しい期間を設定することができる。
【００５７】
ＥＣＬＩＰＳＥドメイン２００に追い掛け機能を実装した一例が、図３に示される。ユーザは、Ｚ３に設けられた追い掛け機能ボックスとして追い掛け機能に加入する。呼要求が受信されると、インバウンドＳＩＰ  ＴＩ２０２が着信先（ＴＯ）アドレスとしてダイアルされる文字列を有するセットアップメッセージを生成する。このセットアップメッセージは、ダイアルされた文字列から発生されたターゲットアドレスに基づいて追い掛けメッセージボックスにルーティングされる。追い掛け機能ボックスがこのセットアップメッセージを受信すると、同ボックスは、データベース２０８によって記憶されたダイアルされる文字列で記憶されている連絡先アドレスを入手する。追い掛け機能ボックスは、次いで、ターゲットフィールド中の連絡先アドレスを置き換え、呼をユーザ優先アドレスにある勧誘加入者に引き続いてルーティングする。あるいは、多重のアドレス（例えば、Ｈ．３２３プロトコル装置３０２，ＰＳＴＮ上の電話３０４，またはＳＩＰ  ＴＩ２０３経由でＥＣＬＩＰＳＥドメイン上の他のユーザ）を優先順位に基づいて試行する。上記追い掛け機能ボックスは、二つの別個の機能ボックスとして、すなわち、サードパーティプロトコルを取り扱う一般追い掛け機能ボックス２３１とシグナリングメッセージ中のＳＩＰ特有引数を取り扱うＳＩＰ追い掛け機能ボックス２３２として確立することができる。このように二つに分離することにより、多岐にわたるサードパーティプロトコルに容易に適応することができる。
【００５８】
図４は、ＥＣＬＩＰＳＥドメイン２００中の呼セットアップ成功例の呼フロー図を示す。発呼側ＳＩＰ  ＵＡ１０２がインバウンドＳＩＰ  ＴＩ２０２にＩＮＶＩＴＥを送ると、ステータスコード「１００」（試行）で確認される。「１００」応答は、ＩＮＶＩＴＥ要求のみの連続的再発信の停止を意味し、さらに上流に伝えられる」必要はない。新しい呼メッセージがＳＩＰ  ＵＡ１０２から着信メディアスイッチ２０６に送られるとする。ＳＩＰ  ＴＩ２０２が、次いでセットアップメッセージを発生し、次いでこのメッセージがアウトバウンドＳＩＰ  ＴＩ２０３に送られると、ＳＩＰ  ＴＩ２０３は、上流確認（ＡＣＫ）とメディアメッセージとで応答する。インバウンドＳＩＰ  ＴＩ２０２は、オーディオ開とビデオ開のメッセージで応答し、次いで両応答は確認される。メディアフロー用の外部チャネルとラインも決定され、ＳＩＰスタックに通信される。次いで、準備完了シグナルがインバウンド側からアウトバウンドＳＩＰ  ＴＩ２０３に送られ、アウトバウンドＳＩＰ  ＴＩ２０３は、次いでＩＮＶＩＴＥメッセージを着呼側のＳＩＰ  ＵＡ１０２に送る。
【００５９】
着呼側のＳＩＰ  ＵＡは、「１８０」（待機）ステータスコードで応答し、開かれたメディアチャネル各々に多重のメッセージを送信すると、これらのメッセージは上流に最終的には発呼側のＳＩＰ  ＵＡ１０２まで伝えられる。着呼側のＳＩＰ  ＵＡ１０２が「２００」ステータスコード（ＯＫ）をアウトバウンドＳＩＰ  ＴＩ２０３に送ると、その後でこの応答は最終的に上流の発呼側のＳＩＰ  ＵＡ１０２まで伝えられる。「２００」メッセージは、これを受信するＳＩＰ  ＴＩとＳＩＰ  ＵＡ双方に確認される。インバウンドＳＩＰ  ＴＩとアウトバウンドＳＩＰ  ＴＩの間では、「２００」メッセージは、受諾（ＡＣＣＥＰＴ）メッセージとして伝えられる。オリジナルのＩＮＶＩＴＥ要求にあるメディアチャネルの幾つかが２００応答に含まれていない場合は、拒絶メッセージが上流にこれらのメディアチャネルに対して送られる。
【００６０】
図５に示される呼セットアップの失敗例は、アウトバウンドＳＩＰ  ＴＩ２０３からＩＮＶＩＴＥ要求を送信するまでは、図４に記載されるステップと同じ初期ステップをたどる。しかし、「２００」レスポンスの代わりに、着呼側ＳＩＰ  ＵＡ１０２は４ｘｘ（要求失敗）、５ｘｘ（サーバ失敗）、または６ｘｘ（グローバル失敗）のステータスコードを送信する。これらの応答の一つに対応して、アウトバウンドＳＩＰ  ＴＩ２０３は利用不可メディアを上流に送信し、その結果、インバウンドＳＩＰ  ＴＩ２０３から発呼側ＳＩＰ  ＵＡ１０２にコードメッセージが伝送される。次ぎに、ティアダウンメッセージがインバウンドＳＩＰ  ＴＩからアウトバウンドＳＩＰ  ＴＩに送られる。上記コードメッセージとティアダウンメッセージは双方とも確認される。
【００６１】
ユーザとＥＣＬＩＰＳＥドメイン２００との間の多岐にわたる登録プロセス例に対する呼フローについては、図６に示される。最初に示されるのは、成功登録プロセス６００である。成功登録プロセス６００は、発呼側ＳＩＰ  ＵＡ１０２からインバウンドＳＩＰ  ＴＩ２０２に送られる登録（ＲＥＧＩＳＴＥＲ）要求で始まる。すると確認として「１００」応答が送られる。次にセットアップと上流確認メッセージがＳＩＰ登録機能ボックスに送られる。すると、ＳＩＰ登録機能ボックスがデータベース２０８に連絡・照会する。現行の連絡先アドレスと連絡先の期限切れ時間は、データベース２０８または外部データベースから得られる。データベース２０８は、ＳＩＰ登録機能ボックスに成功メッセージを送って応答する。すると、同ボックスは、利用可能メッセージを下流のインバウンドＳＩＰ  ＴＩ２０２に送る。次に「２００」メッセージが発呼側ＳＩＰ  ＵＡ１０２に送られる。次いで登録呼がティアダウンされる。
【００６２】
ＳＩＰ  ＢＹＥ要求は、ＤＦＣティアダウンメッセージに翻訳される。インバウンドＳＩＰ  ＴＩまたはアウトバウンドＳＩＰ  ＴＩが終了（ＢＹＥ）要求を受信すると、「２００」応答で確認し、次いでティアダウンメッセージをアウトバウンドＳＩＰ  ＴＩに送る。アウトバウンドＳＩＰ  ＴＩがティアダウンメッセージを受信すると、ＢＹＥメッセージをリモートＳＩＰ  ＵＡ１０２に送る。
【００６３】
認証失敗に基づく登録プロセス失敗６０２が次ぎに示される。これは、照会に対する応答まではプロセス６００と同じ手順で進行する。データベース２０８が用意されたユーザを認証できない場合（例えば、加入者基盤データが古すぎたり、さらに認証情報が必要なったりするとき）照会に認証失敗メッセージをＳＩＰ登録機能ボックスに送って応答する。このＳＩＰ登録機能ボックスは、利用不可能メッセージを生成し、同メッセージは上流のインバウンドＳＩＰ  ＴＩ２０２に送信される。すると、インバウンドＳＩＰ  ＴＩ２０２は、応答のｗｗｗ認証ヘッダに適切なチャレンジ付で「４０１」（非認証）ステータスコードを発呼側ＳＩＰ  ＵＡ１０２に送り、その後で登録呼のティアダウンを行う。
【００６４】
プロセス６０４に示されるように、要求されたユーザをシステムに見出せない場合は、プロセス６０２に使用のステータスコード「４０１」の代わりに「４０４」（不明）応答を送ることも可能である。
【００６５】
これらのプロセスに加えて、ＥＣＬＩＰＳＥドメイン２００は、他のステータスコードメッセージに応答するようにも動作する。例えば、ステータスコード「１８３」（セッション進行）が受信されるプロセスでは、「１８３」応答は、上記の「１８０」応答に関して記載されたやり方で取り扱い得る。さらに、３ｘｘ機能ボックスを、呼のリダイレクションを必要とする３ｘｘ要求をすべて取り扱うために設け得る。このような３ｘｘ機能ボックスは、リダイレクション優先性がユーザから指定された場合の呼のリダイレクションを取り扱い得る。そうでない場合は、３ｘｘレスポンスを単に上流に伝え、ドメインエンドポイントで取り扱うようにもし得る。
【００６６】
ＥＣＬＩＰＳＥドメイン２００は、また、他のＳＩＰ要求を取り入れるように動作することも可能である。このようなＳＩＰ要求としては、例えば、ＯＰＴＩＯＮＳ（ＳＩＰコンポーネントのメディア能力の交換）、ＩＮＦＯ（ＳＩＰシグナリング経路に沿うアプリケーションレベル情報伝達）、ＲＥＦＥＲ（呼転送実施）、ＳＵＢＳＣＲＩＢＥ、ＮＯＴＩＦＹ（ユーザ存在情報を提供）、ＭＥＳＳＡＧＥ（インスタントメッセージの伝達）およびＤＯ（ＳＩＰのネットワーク適用制御）などが挙げられる。
【００６７】
ＳＩＰ  ＣＡＮＣＥＬメッセージは、前の説明の箇所で記載されたＳＩＰ  ＢＹＥ要求と同じやり方で取り扱い得る。取り消し（ＣＡＮＣＥＬ）メッセージはＳＩＰ  ＴＩによってＤＥＣティアダウンメッセージに翻訳される。ＣＡＮＣＥＬ要求がＢＹＥ要求と異なるのは、ＣＡＮＣＥＬ要求は、呼の確立以前に使用されるということである。ＳＩＰ  ＴＩが既存の呼セットアップセッションに対してキャンセル要求を受信すると、「２００」（ＯＫ）応答を送り戻し、その後、オリジナルＩＮＶＩＴＥ要求に対して「４８７」（要求終了）を送信する。次ぎに、ティアダウンメッセージをアウトバウンドＳＩＰ  ＴＩに送り、発呼側ＳＩＰ  ＵＡにＣＡＮＣＥＬ要求を送る。最終応答、例えば、「２００」（ＯＫ）ステータスコードメッセージがＣＡＮＣＥＬ要求以前にリモートＳＩＰ  ＵＡによって送られる場合は、ＳＩＰ  ＴＩは、代わりにＢＹＥ要求を送信する。他の最終応答（例えば、４ｘｘ，５ｘｘ，および６ｘｘ）がリモートＳＩＰ  ＵＡによって送られる場合は、ＳＩＰ  ＴＩは応答を送信しない。
【００６８】
本発明の最良の方法を前述の開示で特に記載したけれども、そのような記載は説明目的のみに提供されたものであり、形式についても詳細についても記載の方法に対する他の変形が、本発明の精神と特許請求の範囲を逸脱することなく、当業者には可能である。本発明は、何よりも先ず記載の特許請求の範囲によって規定されるものである。
【図面の簡単な説明】
【００６９】
【図１】機能ボックスの展開に対するＳＩＰネットワーク環境の例の概略図である。
【図２】図１のＳＩＰネットワーク環境内のドメインの例の概略図である。
【図３】図２の機能ボックス内を流れる呼流れの概略図である。
【図４】図１のＳＩＰネットワーク環境における呼設定プロセス成功の一例の呼フローチャートである。
【図５】図１のＳＩＰネットワーク環境における呼設定プロセス失敗の一例の呼フローチャートである。
【図６】図１のＳＩＰネットワーク環境における登録プロセスの呼フローチャートである。
【図１】
2007504758.tif 000002
【図２】
2007504758.tif 000003
【図３】
2007504758.tif 000004
【図４】
2007504758.tif 000005
【図５】
2007504758.tif 000006
【図６】
2007504758.tif 000007
【国際調査報告】
2007504758.tif 000008
2007504758.tif 000009
2007504758.tif 000010