JP2007512727A - インタフェース呼シグナリングプロトコル - Google Patents

Abstract

第３世代（３Ｇ）ゲートウェイ（３０）により、第２世代（２Ｇ）ネットワークと３Ｇネットワークとの間の複数のインターネット・プロトコル（４０，６４，７４，８３，１００，１１０，１２０，１３０）が拡張される。セッション開始プロトコル（ＳＩＰ）の種々のメッセージは、ユーザ識別及びサーバ識別サブフィールド（４２）を提供するように拡張される。ＳＩＰメッセージ拡張により、プッシュツートーク及びディスパッチサービスを実装するための２Ｇネットワーク及び３Ｇネットワークの通信が可能となる。

Description

本発明は通信システムに関する。より詳細には、本発明は第３世代（３Ｇ）ネットワークと第２世代（２Ｇ）ネットワークとの間のインタフェースプロトコル構成に関する。

通信システムにおける通信は、通信している複数のネットワークの間で制御情報を発信することにより制御される。当然のことながら、ベアラトラフィックの会話及びデータのサンプルが発信される。しかしながら、ベアラトラフィックの受発信及び処理の方法は、ネットワーク自身の間の通信により制御される。

通信ネットワーク間では、制御情報はプロトコルを用いて交換される。プロトコルは、発信側のネットワークにより送信され、受信側のネットワークにより受信される順序付けられた情報のセットである。このプロトコル情報は、全てのネットワークが他のネットワークと対話できるように標準化されている。通信ネットワークにより用いられる典型的なプロトコルは、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）の種々の標準規格に基づく。通信ネットワークは、その通信ネットワークが通信しているネットワークの種類を認識する。一定のネットワークは特に異なっているか又は旧来の種類であり、ＩＥＴＦ標準規格のプロトコルの使用に適合されていない。詳細には、ＩＥＴＦ標準規格では、ｉＤＥＮの相互接続要件をサポートすることは本質的に不可能である。

通常、ＩＥＴＦ標準規格は、特定のシグナリングプロトコルを規定するリクエスト・フォー・コメント（ＲＦＣ；ｒｅｑｕｅｓｔ ｆｏｒ ｃｏｍｍｅｎｔｓ）へと文書化されている。現行のＲＦＣでは、セッション開始プロトコル（ＳＩＰ）を用いる２ＧのｉＤＥＮネットワークとインタフェースすることは不可能である。

したがって、第２世代の通信ネットワークを第３世代の通信ネットワークと相互接続するためのセッション開始型のプロトコルを得ることが非常に所望される。

図１には、通信システム１０を示す。通信システム１０は、第３世代の３Ｇ ｉＤＥＮゲートウェイ３０を介して３Ｇ（第３世代）ネットワーク２５に接続されている、ｉＤＥＮネットワークなどの２Ｇ（第２世代）ネットワーク２０の相互接続を含む。２Ｇネットワーク２０に接続されているのは、３Ｇ ｉＤＥＮゲートウェイ３０である。第３世代（３Ｇ）ｉＤＥＮゲートウェイ３０は３Ｇネットワーク２５に接続されている。

第３世代ｉＤＥＮゲートウェイ３０は、他の機能に加え、２Ｇネットワーク２０と３Ｇネットワーク２５との間のプロトコル変換を提供する。３Ｇ ｉＤＥＮゲートウェイ３０のプロセッサ３５のソフトウェアは、それらのプロトコルと、本明細書において説明するそれらのプロトコルの拡張部とを制御する。ｉＤＥＮディスパッチ呼サービスの拡張を容易にする新規な呼シグナリングプロトコルを示す。これらの拡張により、ｉＤＥＮディスパッチ呼サービスは３Ｇネットワークなど外部ネットワークまで拡張される。

２Ｇネットワークと３Ｇネットワークとの間のこれらのインタフェースは、セッション開始プロトコル（ＳＩＰ）及び関連するプロトコルの使用に基づく。これらの基礎のプロトコルは、リクエスト・フォー・コメント「ＳＩＰ セッション開始プロトコル」（ＲＦＣ３２６１）に示されており、呼確立のために用いられる。さらに、本発明は、以下のＩＥＴＦ ＲＦＣ、
ＲＦＣ２９７６ ＳＩＰ ＩＮＦＯ メソッド（トーカ調停（ｔａｌｋｅｒ ａｒｂｉｔｒａｔｉｏｎ）用）、
ＲＦＣ３３２６ セッション開始プロトコル（ＳＩＰ）用理由（Ｒｅａｓｏｎ）ヘッダ、
ＲＦＣ２３２７ ＳＤＰ：セッション記述プロトコル、
ＲＦＣ１８８９ リアルタイムアプリケーション用トランスポートプロトコル、
ＲＦＣ１８９０ 最少制御による音声及び映像カンファレンス用ＲＴＰプロファイル、及び
ＲＦＣ３５５８ 可変レート符号化（ＥＶＲＣ；Ｅｎｈａｎｃｅｄ Ｖａｒｉａｂｌｅ
Ｒａｔｅ Ｃｏｄｅｃｓ）及びモード選択可能ボコーダ（ＳＭＶ；Ｓｅｌｅｃｔａｂｌｅ Ｍｏｄｅ Ｖｏｃｏｄｅｒｓ）用のＲＴＰペイロードフォーマット
に対する拡張部を含む、セッション記述プロトコル、リアルタイムトランスポートプロトコル及び付随する標準規格に基づく。

ＳＩＰを用いて本発明を説明するが、プロトコル拡張を用いて新たなパラメータ及び関数を規定し、２Ｇネットワークを３Ｇネットワークへ相互接続することを可能とするという概念は、ＳＩＰ、ＳＤＰなどの使用に限定されない。

ＳＩＰには、リクエスト行、レスポンス行、様々な必須ヘッダ及び任意ヘッダ、任意のメッセージ本体並びに下位のパラメータ／フィールドなど、種々の情報要素を各々含む、幾つかのメッセージタイプ（リクエスト及び関連するレスポンス）が含まれる。ＲＦＣ３２６１（ＲＦＣ２９７６，３３２６により拡張される）により、これらの情報要素の各々に関連する構文、セマンティクス及びメソッド（即ち、関数のビヘイビア）が指定されている。その基盤に基づき、本発明は、メッセージタイプにより組織される、適用可能なＳＩＰ拡張を規定する。作用を受けるメッセージタイプは、
ＳＩＰ ＩＮＶＩＴＥ リクエスト、
ＳＩＰ ３０１ レスポンス（即ち、ＩＮＶＩＴＥリクエストに対するレスポンス）、
ＳＩＰ ３０２ レスポンス（即ち、ＩＮＶＩＴＥリクエストに対するレスポンス）、
ＳＩＰ ２００ レスポンス（即ち、ＩＮＶＩＴＥリクエストに対するレスポンス）、
ＳＩＰ ４ｘｘ−６ｘｘ レスポンス（即ち、ＩＮＶＩＴＥリクエストに対するレスポンス）、
ＳＩＰ ＡＣＫ リクエスト、
ＳＩＰ ＩＮＦＯ リクエスト、及び
ＳＩＰ ＢＹＥ リクエストである。

各々の異なるＳＩＰメッセージタイプについて、プロトコル拡張を伴うＲＦＣ仕様に従い関連するヘッダ及びメッセージ本体を識別する基本的なメッセージ構造の例示的な実施例を示す。

図２には、ＳＩＰ ＩＮＶＩＴＥリクエスト構造４１のデータ配置を示す。標準的なＩＮＶＩＴＥリクエスト行の書式は、ＩＮＶＩＴＥリクエスト／統一リソース識別子（ＵＲＩ）／ＳＩＰバージョン、である。ＵＲＩは種々のＩＰ型プロトコルにおいてリソース又はユーザのアドレスを表示するために用いられ、その書式は、ユーザ名＠ホスト−サーバ（ｕｓｅｒｎａｍｅ＠ｈｏｓｔ−ｓｅｒｖｅｒ）、である。ＩＮＶＩＴＥリクエスト行に対しては２つの拡張部が存在する。

第１に、関連するＵＲＩアドレスのユーザ情報フィールド（ユーザＩＤ）４２には、ユーザＩＤ．非ＳＩＰサーバＩＤ（ｕｓｅｒ＿ｉｄ．ｎｏｎ＿ｓｉｐ＿ｓｅｒｖｅｒ＿ｉｄ）の書式のユーザ名が含まれ、別個のルーティングテーブルの参照を必要とすることなく、ＳＩＰ使用可能でないターゲットサーバへのダイレクトルーティングを容易にする。ゲ
ートウェイ３０の実装では、フィールド４２のｎｏｎ＿ｓｉｐ＿ｓｅｒｖｅｒ＿ｉｄ部分は、ターゲット加入者にサービスを提供しているディスパッチ呼サーバのＩＳＤＮ（サービス総合デジタル網）アドレス（例えば、電話番号）である。

第２に、ｓｄｂ（加入者データベース）フラグ４３の拡張部が追加される。このパラメータは、この呼試行における適用可能な加入者データベース（例えば、ターゲット加入者のＨＬＲ（ホームロケーションレジスタ））に対する問い合わせにより、関連するフィールド４２のｎｏｎ＿ｓｉｐ＿ｓｅｒｖｅｒ＿ｉｄ部分が決定されたことを示すためのフラグとして作用する。

このことは、先のデータベース問い合わせがＳＩＰ ３０２リダイレクトメッセージをトリガし、このＩＮＶＩＴＥリクエストを生成したことを意味する。ｓｄｂパラメータは、通常のキャッシュ優先規則をオーバライドし、不要な追加の加入者データベース問い合わせを除去して、ＳＩＰリダイレクトループを軽減するために用いられる。

第１及び第２の拡張部の構文の例は、それぞれ、
ＩＮＶＩＴＥ １２３＊４５＊６７８．１４８０５５５１２１２＠ｃａｒｒｉｅｒ．ｃｏｍ ＳＩＰ／２．０
ＩＮＶＩＴＥ １２３＊４５＊６７８．１４８０５５５１２１２＠ｃａｒｒｉｅｒ．ｃｏｍ；ｓｄｂ ＳＩＰ／２．０
である。

また、ＳＩＰ ＩＮＶＩＴＥ４０のフロム（Ｆｒｏｍ）ヘッダ４５も、発信元の加入者のプライベート番号を含むように拡張される。プライベート番号は、ｉＤＥＮシステム内で加入者のアドレスとして用いられる（即ち、ディスパッチサービスを容易にするように各ｉＤＥＮ加入者に対し割り当てられている、加入者のＵＦＭＩ（統一機体移動体識別子（Ｕｎｉｖｅｒｓａｌ Ｆｌｅｅｔ Ｍｏｂｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ））、「プライベート番号」）。この情報は、別個の名前翻訳サーバの使用を必要とすることなく、異種のＳＩＰネットワークドメインとｉＤＥＮネットワークドメインとの間で加入者のＩＤのダイレクトマッピングを容易とするために、関連するＳＩＰ−ＵＲＩのユーザ名情報フィールド（ユーザＩＤ）４６に提供される。なお、ＩＮＶＩＴＥとして及びＩＮＶＩＴＥに対するレスポンスとして同じユーザエージェントにより開始される、同じＳＩＰダイアログ内の続く全てのリクエストに対しても、この拡張が適用される。ＩＮＶＩＴＥの受信者により開始される同じＳＩＰダイアログ内の続く全てのリクエストにおいて、Ｆｒｏｍヘッダには、ターゲット加入者のプライベート番号（これは適用可能なＩＮＦＯリクエスト及びＢＹＥリクエストにのみ適用される）が含まれる。

拡張されたＦｒｏｍヘッダ４５の構文の一例を以下に示す。
Ｆｒｏｍ： １２３＊４５＊６７８＠ｃａｒｒｉｅｒ．ｃｏｍ； ｔａｇ＝ａｂｃ１２３
１２３＊４５＊６７８は、拡張されたフィールド４６の値を表す。

ＳＩＰ ＩＮＶＩＴＥ４０のツー（Ｔｏ）ヘッダ４７は、発信元の加入者のプライベート番号を含むように拡張される。プライベート番号は、ｉＤＥＮシステム内で加入者のアドレスとして用いられる。この情報は、別個の名前翻訳サーバの使用を必要とすることなく、異種のＳＩＰネットワークドメインとｉＤＥＮネットワークドメインとの間で加入者のＩＤのダイレクトマッピングを容易とするために、関連するＳＩＰ−ＵＲＩのユーザ名情報フィールド（ユーザＩＤ）４８に提供される。構文を以下に規定する。なお、ＳＩＰ
ＩＮＶＩＴＥとして及びＳＩＰ ＩＮＶＩＴＥに対するレスポンスとして同じユーザエージェントにより開始される、同じＳＩＰダイアログ内の続く全てのリクエストに対して
も、この拡張が適用される。ＩＮＶＩＴＥの受信者により開始される同じＳＩＰダイアログ内の続く全てのリクエストにおいて、Ｔｏヘッダ４７には、発信元の加入者のプライベート番号（これは適用可能なＩＮＦＯリクエスト及びＢＹＥリクエストにのみ適用される）が含まれる。

拡張されたＴｏヘッダの構文の一例を以下に示す。
Ｔｏ： １２３＊４５＊６７８＠ｃａｒｒｉｅｒ．ｃｏｍ； ｔａｇ＝９８７ｘｙｚ
１２３＊４５＊６７８は、拡張されたフィールド４７の値を表す。

ＳＩＰ ＩＮＶＩＴＥ４０のコンタクト（Ｃｏｎｔａｃｔ）ヘッダフィールド４９に対しては２つの拡張部が存在する。第１に、リクエスト行４１について説明した拡張と同様に、ＳＩＰ ＩＮＶＩＴＥ４０のＣｏｎｔａｃｔヘッダフィールド４９には、リクエスト行４１のフィールド４２と同じ情報を含むユーザ名情報フィールド（ユーザＩＤ）５０が含まれる。ｕｓｅｒ＿ｉｄ．ｎｏｎ＿ｓｉｐ＿ｓｅｒｖｅｒ＿ｉｄの書式により、別個のルーティングテーブルの参照を必要とすることなく、ターゲット呼サーバ（ＳＩＰ使用可能でない）への将来のリクエストのダイレクトルーティングが容易となる。３Ｇゲートウェイ３０では、ｎｏｎ＿ｓｉｐ＿ｓｅｒｖｅｒ＿ｉｄは、ターゲット加入者にサービスを提供しているディスパッチ呼サーバのＩＳＤＮアドレスである。なお、ＩＮＶＩＴＥリクエストに対するＳＩＰ ２００ ＯＫレスポンスに対しても、この拡張が適用される。

第２に、関連するＦｒｏｍヘッダ４５のユーザＩＤフィールド４６にて識別される加入者に対する将来の呼における使用のため、関連するＣｏｎｔａｃｔアドレスを受信側のサーバが記憶する必要があることを示すための拡張パラメータとして、新たなキャッシュフラグ５１が追加される。上述のユーザ情報命名規則と共に用いられる場合、このことにより、加入者データベース問い合わせ又は複雑なルーティングテーブルの参照を必要とすることなく、任意の発信元の加入者から適用可能なターゲットサーバ（ＳＩＰ使用可能でない）への将来の呼のダイレクトルーティングが容易になる。なお、ＩＮＶＩＴＥリクエストに対するＳＩＰ ２００ ＯＫレスポンスに対しても、この拡張が適用され、その場合、適用可能な加入者はＴｏヘッダ４７のユーザＩＤフィールド４８にて識別される。

拡張されたＣｏｎｔａｃｔヘッダの構文の例を以下に示す。
Ｃｏｎｔａｃｔ： １２３＊４５＊６７８．１４８０５５５１２１２＠１９２．１２３．１２．３
１２３＊４５＊６７８．１４８０５５５１２１は、拡張されたフィールド５０の値を表す。

Ｃｏｎｔａｃｔ： ｊｏｈｎ．ｄｏｅ＠ｃａｒｒｉｅｒ．ｃｏｍ；ｃａｃｈｅ
Ｃｏｎｔａｃｔ： １２３＊４５＊６７８．１４８０５５５１２１２＠１９２．１２３．１２．３；ｃａｃｈｅ
「キャッシュ（ｃａｃｈｅ）」フィールド５１は、受信側のサーバがＣｏｎｔａｃｔヘッダ４９の値を記憶する必要があることを示す。

ユーザエージェント（Ｕｓｅｒ−Ａｇｅｎｔ）ヘッダ５３には、「ｖｓｇｗ」の拡張の値を含む製品フィールド３９と、関連するインタフェースバージョンを含む製品バージョンフィールド５４とが含まれる。この拡張により、関連するＳＩＰダイアログにおいて用いられるインタフェースバージョンのネゴシエーションが容易となる。

拡張されたＵｓｅｒ−Ａｇｅｎｔヘッダの構文の例を以下に示す。
Ｕｓｅｒ−Ａｇｅｎｔ： ｖｓｇｗ／Ｒ．０２．０１．００／Ｒ０２．０２．００
Ｕｓｅｒ−Ａｇｅｎｔ： ｐｃｃｌｉｅｎｔ／Ｒ．０２．０１．００
「ｖｓｇｗ」は、拡張された製品フィールド３９の値である。

Ｒ．０２．０１．００及びＲ０２．０２．００は、拡張された製品バージョンフィールド５４の値を表す。
ＳＩＰ ＩＮＶＩＴＥリクエスト４０には、コンテンツタイプ（Ｃｏｎｔｅｎｔ−ｔｙｐｅ）ヘッダ５５が含まれる。Ｃｏｎｔｅｎｔ−ｔｙｐｅヘッダはメディアタイプフィールド５６を有する。メッセージ本体５７がｉＧＷ特有の呼処理（Ｃａｌｌ Ｐｒｏｃｅｓｓｉｎｇ）情報を含む単一のアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）部分のみを含む場合、メディアタイプフィールド５６は「ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｉＧＷ−ＣＰ」の拡張の値を含む。

拡張されたＣｏｎｔｅｎｔ−ｔｙｐｅヘッダの構文の一例を以下に示す。
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｉＧＷ−ＣＰ
ＳＩＰ ＩＮＶＩＴＥリクエスト４０のメッセージ本体５７には、ｉＧＷ呼処理タイプ拡張部のフィールド（ｘ−ｉＧＷ−ＣＰ）５８が含まれる。ｘ−ｉＧＷ−ＣＰメッセージ本体フィールドには、呼タイプのパラメータが含まれ、任意で、課金呼参照ＩＤ（Ｂｉｌｌｉｎｇ Ｃａｌｌ Ｒｅｆｅｒｅｎｃｅ ＩＤ）、優先度（Ｐｒｉｏｒｉｔｙ）、サービスエリアＩＤ（Ｓｅｒｖｉｃｅ Ａｒｅａ ＩＤ）、セクタＩＤ（Ｓｅｃｔｏｒ ＩＤ）、ＥＢＴＳ ＩＤ及びＭＳステータスコード（ＭＳ Ｓｔａｔｕｓ Ｃｏｄｅ）のうちの１つ以上のパラメータが含まれてよい。なお、ｘ−ｉＧＷ−ＣＰフィールド５８がマルチパート（ｍｕｌｔｉｐａｒｔ）メッセージ本体の一部である場合、ＲＦＣ２０４５，２０４６に規定されているマルチパートメッセージ本体の構文に従い、関連するＣｏｎｔｅｎｔ−ｔｙｐｅヘッダ及びコンテンツ長（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ）ヘッダもメッセージ本体５７に存在する必要がある。

これに加えて、一部のディスパッチ呼タイプでは、ＳＩＰ ＩＮＶＩＴＥリクエスト４０のメッセージ本体５７には、拡張されたバージョンのセッション記述プロトコル（即ち、「ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ」のＳＤコンテンツタイプにより指定される）を含む第２の本体部分５９も含まれる。詳細を図３に示す。両方のメッセージ本体タイプが含まれる場合、それらはマルチパートメッセージ本体にカプセル化される。この場合、ＳＩＰ ＩＮＶＩＴＥ４０のＣｏｎｔｅｎｔ−ｔｙｐｅヘッダ５５には、ＲＦＣ２０４５，２０４６に従い、「ｍｕｌｔｉｐａｒｔ／ｍｉｘｅｄ」の値が含まれる。

図３には、ＲＦＣ２３２７ セッション記述プロトコル（ＳＤＰ）のメッセージ本体の一般的な構造を示す。なお、Ｃｏｎｔｅｎｔ−ｔｙｐｅヘッダ及びＣｏｎｔｅｎｔ−ｌｅｎｇｔｈヘッダはＳＤＰの一部ではないが、本明細書では、ＲＦＣ２０４５，２０４６によるマルチパートメッセージ本体の使用の可能性を反映するように、それらのヘッダを含める。Ｃｏｎｔｅｎｔ−ｔｙｐｅヘッダ６０では、上述のＣｏｎｔｅｎｔ−ｔｙｐｅヘッダ５５と同じ一般的な構文が用いられる（拡張なし）。

属性（Ａｔｔｒｉｂｕｔｅ）フィールド６１については、本発明では、標準的なＳＤＰメッセージ本体に対する幾つかの独立及び任意のメディア属性の拡張部を含む。
第１に、新たな属性６１「ａ＝ｒｅｃｖｓｓｒｃ」は、ＲＦＣ１８９９ リアルタイムトランスポートプロトコル（ＲＴＰ）にて規定されている標準的なＳＳＲＣ識別子割当及び衝突軽減機能を受信者が抑制する必要があることを示すために規定されており、提供されるＳＳＲＣ値は適用可能な全てのＲＴＰパケットにおいて用いられる。この拡張は、標準的なＳＩＰ「オファー／アンサー」モデルのうちの「オファー」側を構成するＳＤＰメッセージ本体に対して適用される。この属性６１の構文を例として以下に示す。

ａ＝ｒｅｃｖｓｓｒｃ：ｆｆｅｅｄｄｃｃ
「ａ＝ｆｍｔｐ」のメディア属性６１に対しては、新たなパラメータ「ｒａｔｅ＿ｒｅｄｕｃ」が規定される。この属性６１は、レート選択可能ボコーダ（ＳＭＶ、ボコーダの一群）に対する標準モード又は可変レート符号化（ＥＶＲＣ、ボコーダの一群）に対する標準レート減少パターンをオーバライドすることにより、関連する呼に必要なメディア帯域幅を減少するために用いられる。ｒａｔｅ＿ｒｅｄｕｃパラメータの一例を以下に示す。

ａ＝ｆｍｔｐ：９８ ｍａｘｉｎｔｅｒｌｅａｖｅ＝０ ｒａｔｅ＿ｒｅｄｕｃ＝０
また属性フィールド６１には、「ａ＝ｐｔｉｍｅ」及び「ａ＝ｍａｘｐｔｉｍｅ」のメディア属性により規定されるパケット時間に対する許容可能な値の範囲も含まれてよい。これらのメディア属性は、音声品質を改良するように各々の適用可能なボコーダタイプに対して最適化されている。例を以下に示す。

ａ＝ｐｔｉｍｅ：２０
ａ＝ｐｔｉｍｅ：２５．３７５
ａ＝ｍａｘｐｔｉｍｅ：１００
属性フィールド６１の「ａ＝ｒｔｐｍａｐ」属性における使用のため、いずれも８０００のクロックレートを用いる２つの新たな符号化名、Ｘ−ＶＳＥＬＰ＿Ｉ６及びＸ−ＡＭＢＥ＋＋＿Ｉ６が追加される。例を以下に示す。

ａ＝ｒｔｐｍａｐ：９７ Ｘ−ＶＳＥＬＰ＿Ｉ６／８０００
ａ＝ｒｔｐｍａｐ：９８ Ｘ−ＡＭＢＥ＋＋＿Ｉ６／８０００
図４には、ＳＩＰ ３０１ ＩＮＶＩＴＥレスポンス６４の構造を示す。Ｆｒｏｍヘッダ４５、Ｔｏヘッダ４７及びそれぞれの拡張部４６，４８と同様に、Ｆｒｏｍヘッダ６５、Ｔｏヘッダ６６はユーザ情報拡張部６７，６８により拡張されている。

受信側のサーバにおける適用可能なルーティング情報（例えば、ルーティングテーブル）の動的設定を容易にするために、Ｃｏｎｔａｃｔヘッダ６９に対し、「範囲」のコンタクト拡張パラメータ７０が追加されている。一例を以下に示す。

Ｃｏｎｔａｃｔ： １２３＊４５＊６７８＠ｃａｒｒｉｅｒ．ｃｏｍ；ｒａｎｇｅ＝１００，１０００，５０，２００
図５には、ＳＩＰ ３０２ ＩＮＶＩＴＥレスポンス７４の構造を示す。Ｆｒｏｍヘッダ４５、Ｔｏヘッダ４７及びそれぞれの拡張部４６，４８と同様に、Ｆｒｏｍヘッダ７５、Ｔｏヘッダ７７はユーザ情報拡張部７６，７８により拡張されている。

ＳＩＰ ３０２ ＩＮＶＩＴＥレスポンス構造７４において、Ｃｏｎｔａｃｔヘッダ７９に対しては、複数の拡張部が存在する。それらの拡張部は上述の図２において説明した拡張部４２，４３と同様であり、かつ、拡張部４２，４３と共に用いられる。これらの拡張部はユーザＩＤ８０及びｓｄｂ８１のフィールドである。

第１に、関連するＵＲＩアドレスのユーザ情報フィールド（ユーザＩＤ）８０には、ｕｓｅｒ＿ｉｄ．ｎｏｎ＿ｓｉｐ＿ｓｅｒｖｅｒ＿ｉｄの書式のユーザ名が含まれ、別個のルーティングテーブルの参照を必要とすることなく、ＳＩＰ使用可能でないターゲットサーバへのダイレクトルーティングを容易にする。ゲートウェイ３０の実装では、フィールド８０のｎｏｎ＿ｓｉｐ＿ｓｅｒｖｅｒ＿ｉｄ部分は、ターゲット加入者にサービスを提供しているディスパッチ呼サーバのＩＳＤＮ（サービス総合デジタル網）アドレス（例えば、電話番号）である。

第２に、ｓｄｂ（加入者データベース）フラグ８１の拡張部が追加される。このパラメ
ータは、この呼試行における適用可能な加入者データベース（例えば、ターゲット加入者のＨＬＲ（ホームロケーションレジスタ））に対する問い合わせにより、関連するフィールド８０のｎｏｎ＿ｓｉｐ＿ｓｅｒｖｅｒ＿ｉｄ部分が判定されたことを示すためのフラグとして作用する。

このことは、先のデータベース問い合わせがＳＩＰ ３０２リダイレクトメッセージをトリガし、続くＩＮＶＩＴＥリクエストを生成することを意味する。ｓｄｂパラメータは、通常のキャッシュ優先規則をオーバライドし、不要な追加の加入者データベース問い合わせを除去して、ＳＩＰリダイレクトループを軽減するために用いられる。

第１及び第２の拡張部の構文の一例は以下である。
Ｃｏｎｔａｃｔ： １２３＊４５＊６７８．１４８０５５５１２１２＠ｃａｒｒｉｅｒ．ｃｏｍ；ｓｄｂ
図６には、ＳＩＰ ２００（ＩＮＶＩＴＥ）レスポンス８３の構造を示す。このメッセージにおいて拡張されるフィールドのみを説明する。この発明により拡張されている各情報要素について、拡張されたフィールドを参照符号を用いて説明する。

Ｆｒｏｍヘッダ８４は、ユーザＩＤフィールドであるフィールド８５により拡張される。ユーザＩＤフィールド８５はＦｒｏｍヘッダ４５のユーザＩＤフィールド４６と同じフィールドであり、上述において図２を参照して説明した。

同様に、Ｔｏヘッダ８６は、ユーザＩＤフィールドであるフィールド８７により拡張される。ユーザＩＤフィールド８６はＴｏヘッダ４７のユーザＩＤフィールド４８と同じフィールドであり、上述において図２を参照して説明した。

Ｃｏｎｔａｃｔヘッダ８８は、ユーザＩＤフィールド８９、「キャッシュ」フィールド９０を含むフィールド８９，９０により拡張される。ユーザＩＤフィールド８９はＣｏｎｔａｃｔヘッダ４９のユーザＩＤフィールド５０と同じフィールドであり、上述において図２を参照して説明した。さらに、「キャッシュ」フィールド９０は図２の「キャッシュ」フィールド５１と同じであり、説明は同様である。

上述のＵｓｅｒ−Ａｇｅｎｔヘッダ５３と同様に、サーバ（Ｓｅｒｖｅｒ）ヘッダ９１には、「ｖｓｇｗ」の拡張の値を含む製品フィールド９５と、関連するインタフェースバージョンを含む製品バージョンフィールド９２とが含まれる。この拡張により、関連するＳＩＰダイアログにおいて用いられるインタフェースバージョンのネゴシエーションが容易となる。拡張されたＳｅｒｖｅｒヘッダ９１は、拡張されたＵｓｅｒ−Ａｇｅｎｔヘッダ５３と共に用いられる。さらに、製品フィールド９５及び製品バージョンフィールド９２の説明は、図２に示すＳＩＰ ＩＮＶＩＴＥリクエスト４０のフィールド３９，５４にて規定した説明と同じである。

拡張されたＳｅｒｖｅｒヘッダの構文の例を以下に示す。
Ｓｅｒｖｅｒ： ｖｓｇｗ／Ｒ．０２．０１．００／Ｒ０２．０２．００
Ｓｅｒｖｅｒ： ｐｃｃｌｉｅｎｔ／Ｒ．０２．０１．００
「ｖｓｇｗ」は、拡張された製品フィールド９５の値を表す。

Ｒ．０２．０１．００及びＲ０２．０２．００は、拡張された製品バージョンフィールド９２の値を表す。
ＳＤＰメッセージ本体９３についての説明は、図３に示したものと同じである。属性フィールド９４の説明は、図３の属性フィールド６１と同じである。

図７には、ＳＩＰ ４ＸＸ−６ＸＸ ＩＮＶＩＴＥレスポンスのデータ構造１００を示す。このメッセージにおいて拡張されるフィールドのみを説明する。この発明により拡張されている各情報要素について、拡張されたフィールドを参照符号を用いて説明する。

Ｆｒｏｍヘッダ１０１は、ユーザＩＤフィールドであるフィールド１０２により拡張される。ユーザＩＤフィールド１０２はＦｒｏｍヘッダ４５のユーザＩＤフィールド４６と同じフィールドであり、上述において図２を参照して説明した。

同様に、Ｔｏヘッダ１０３は、ユーザＩＤフィールドであるフィールド１０４により拡張される。ユーザＩＤフィールド１０３はＴｏヘッダ４７のユーザＩＤフィールド４８と同じフィールドであり、上述において図２を参照して説明した。

ＳＩＰ理由（Ｒｅａｓｏｎ）ヘッダ１０５は、ＲＦＣ３３２６にて提供される標準的な仕様を超えて拡張され、プロトコルフィールド１０８、原因（ｃａｕｓｅ）フィールド１０６及びテキストフィールド１０７に対して規定される拡張された値と共に、ＳＩＰ ４ＸＸ−６ＸＸレスポンスにおいて用いられる。

一例を以下に示す。
Ｒｅａｓｏｎ： ＰｇＲｓｐ； ｃａｕｓｅ＝２； ｔｅｘｔ＝"ｉＤＥＮ Ｔａｒｇ
ｅｔ Ｓｔａｔｕｓ：０６００"
図８には、ＳＩＰ ＡＣＫリクエスト１１０及びその拡張部の構造を示す。このメッセージにおいて拡張されるフィールドのみを説明する。この発明により拡張されている各情報要素について、拡張されたフィールドを参照符号を用いて説明する。

Ｆｒｏｍヘッダ１１１は、ユーザＩＤフィールドであるフィールド１１２により拡張される。ユーザＩＤフィールド１１２はＦｒｏｍヘッダ４５のユーザＩＤフィールド４６と同じフィールドであり、上述において図２を参照して説明した。

同様に、Ｔｏヘッダ１１３は、ユーザＩＤフィールドであるフィールド１１４により拡張される。ユーザＩＤフィールド１１４はＴｏヘッダ４７のユーザＩＤフィールド４８と同じフィールドであり、上述において図２を参照して説明した。

ＳＩＰ ＡＣＫリクエスト構造１１０に、ＳＤＰメッセージ本体フィールド１１５を示す。ＳＤＰメッセージ本体フィールド１１５は、図３に示すＳＤＰメッセージ本体フィールド９３と同じである。ＡＣＫメッセージ本体１１５においては「ａ＝ｒｅｃｖｓｓｒｃ」フィールド１１６が適用されないこと以外、フィールド１１５の属性フィールド１１６の説明は、図３の属性フィールド６１と同じである。

図９には、ＳＩＰ ＩＮＦＯリクエスト１２０及びその拡張部の構造を示す。このメッセージにおいて拡張されるフィールドのみを説明する。この発明により拡張されている各情報要素について、拡張されたフィールドを参照符号を用いて説明する。

Ｆｒｏｍヘッダ１２１は、ユーザＩＤフィールドであるフィールド１２２により拡張される。ユーザＩＤフィールド１２２はＦｒｏｍヘッダ４５のユーザＩＤフィールド４６又はＴｏヘッダのユーザＩＤフィールド４８と同じフィールドである（ＩＮＶＩＴＥリクエストと比較したメッセージ方向に応じて異なる）。フィールド４６，４８については上述において図２を参照して説明した。

同様に、Ｔｏヘッダ１２３は、ユーザＩＤフィールドであるフィールド１２４により拡張される。ユーザＩＤフィールド１２４はＴｏヘッダ４７のユーザＩＤフィールド４８又
はＦｒｏｍヘッダ４５のユーザＩＤフィールド４６と同じフィールドである。それらのフィールドについては上述において図２を参照して説明した。

また、図９には、ＳＩＰ ＩＮＦＯリクエストメッセージ構造１２０において、さらにＣｏｎｔｅｎｔ−ｔｙｐｅヘッダ１２５が存在する。Ｃｏｎｔｅｎｔ−ｔｙｐｅヘッダ１２５は、メディアタイプフィールド１２６を有する。ＳＩＰ ＩＮＦＯリクエストのＣｏｎｔｅｎｔ−ｔｙｐｅヘッダ１２５のメディアタイプフィールド１２６には、規定のｉＧＷトーカ調停タイプメッセージ本体を含むメッセージを示すための拡張の値「ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｉＧＷ−ＴＡ」が含まれてもよい。拡張されるＣｏｎｔｅｎｔ−ｔｙｐｅヘッダ１２５の構文の一例を以下に示す。

Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｉＧＷ−ＴＡ
さらに、ＳＩＰ ＩＮＦＯリクエスト１２０は、拡張されるトーカ調停フィールド（ｘ−ｉＧＷ−ＴＡ）１２８を含むメッセージ本体１２７を有する。ＳＩＰ ＩＮＦＯリクエスト１２０のｘ−ｉＧＷ−ＴＡフィールド１２８には、ＴＡメッセージタイプパラメータが含まれる。これに加えて、一部のＴＡメッセージタイプでは、メッセージ本体１２７にはメッセージペイロードパラメータも含まれる。ｘ−ｉＧＷ−ＴＡフィールドの構文の例を以下に示す。

１） ＴＡ＝２： フロアリクエスト
２） ＴＡ＝１
タイムスタンプ：０７ｄ３０ｂ０４０１０ｅ１ｅ１４００６４
３） ＴＡ＝３： フロア許可
ｕｓｅｒ：＜ｓｉｐ：５５＊５５＊１２１２１２＠ｎｅｘｔｅｌｇａｔｅｗａｙ．ｃｏｍ
上述の例２，３では、タイムスタンプ及びユーザペイロードパラメータがメッセージ本体１２７に含まれる。

図１０には、ＳＩＰ ＢＹＥリクエスト１３０及びその拡張部のデータ構造を示す。このメッセージにおいて拡張されるフィールドのみを説明する。この発明により拡張されている各情報要素について、拡張されたフィールドを参照符号を用いて説明する。

Ｆｒｏｍヘッダ１３１は、ユーザＩＤフィールドであるフィールド１３２により拡張される。ユーザＩＤフィールド１３２はＦｒｏｍヘッダ４５のユーザＩＤフィールド４６又はＴｏヘッダのユーザＩＤフィールド４８と同じフィールドである（ＩＮＶＩＴＥリクエストと比較したメッセージ方向に応じて異なる）。フィールド４６，４８については上述において図２を参照して説明した。

同様に、Ｔｏヘッダ１３３は、ユーザＩＤフィールドであるフィールド１３４により拡張される。ユーザＩＤフィールド１３４はＴｏヘッダ４７のユーザＩＤフィールド４８又はＦｒｏｍヘッダ４５のユーザＩＤフィールド４６と同じフィールドである。それらのフィールドについては上述において図２を参照して説明した。

また、ＳＩＰ ＢＹＥリクエストメッセージ構造１３０においては理由ヘッダ１３５も存在する。理由ヘッダ１３５は、ＲＦＣ３３２６ セッション開始プロトコル（ＳＩＰ）用理由ヘッダ、にて提供される仕様を超えて拡張される。詳細には、理由ヘッダ１３５では、プロトコルフィールド１４２、原因フィールド１３６及びテキストフィールド１３７に対して拡張される値が用いられる。これらのフィールドの使用の一例を以下に示す。

Ｒｅａｓｏｎ： Ｔｅｒｍ； ｃａｕｓｅ＝２； ｔｅｘｔ＝"ａｂｏｒｔ／Ｄ２Ｖ：
０２００"
ＳＩＰ ＢＹＥリクエスト１３０はＣｏｎｔｅｎｔ−ｔｙｐｅヘッダ１３８を有する。Ｃｏｎｔｅｎｔ−ｔｙｐｅヘッダ１３８は、メッセージがｉＤＥＮゲートウェイ３０に特有の呼処理タイプメッセージ本体１４０を含むことを示すため、メディアタイプフィールド１３９に「ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｉＧＷ−ＣＰ」の値を有する。フィールド１３９には、上述の図２において説明したメディアタイプフィールド５６と同じ値が用いられる。

また、ＳＩＰ ＢＹＥリクエスト１３０には、拡張されたｉＧＷ呼処理（ＣＰ）タイプアプリケーションメッセージ本体（ｘ−ｉＧＷ−ＣＰ）１４０も含まれる。ＢＹＥリクエスト１３０のｘ−ｉＧＷ−ＣＰメッセージ本体１４０には、呼持続時間（ｃａｌｌ ｄｕｒａｔｉｏｎ）パラメータ１４１が含まれる。呼持続時間パラメータ１４１は、関連する呼の長さを示す。呼持続時間フィールド１４１の一例を以下に示す。

Ｃａｌｌ ｄｕｒａｔｉｏｎ＝４１０００
この発明により規定されるベアラプロトコルでは、ＲＦＣ１８８９，１９９０にて文書化されているリアルタイムトランスポートプロトコル（ＲＴＰ）が用いられる。ＶＳＥＬＰ Ｉ６又はＡＭＢＥ＋＋ Ｉ６ボコーダを利用するベアラトラフィック用の新たなＲＴＰペイロードフォーマットを指定するように、適切な拡張部が含まれる。

上述の呼シグナリングプロトコルにより、３Ｇネットワークなど外部ネットワークへのｉＤＥＮネットワーク呼サービスが容易となる。これらのプロトコルにより、ディスパッチ及びプッシュツートーク（ｐｕｓｈ−ｔｏ−ｔａｌｋ）など、ｉＤＥＮネットワークサービスを拡張するためのユーザエージェントサービスが提供される。

本発明によるインタフェース呼シグナリングプロトコルを提供するための通信システムのブロック図。 本発明によるＳＩＰ ＩＮＶＩＴＥリクエストのデータ構造配置図。 本発明によるＳＤＰメッセージ本体のデータ配置図。 本発明によるＳＩＰ ３０１ ＩＮＶＩＴＥレスポンスのデータ配置図。 本発明によるＳＩＰ ３０２ ＩＮＶＩＴＥレスポンスメッセージのデータ配置図。 本発明によるＳＩＰ ２００ ＩＮＶＩＴＥレスポンスメッセージのデータ配置図。 本発明によるＳＩＰ ４ＸＸ−６ＸＸ ＩＮＶＩＴＥレスポンスメッセージのデータ配置図。 本発明によるＳＩＰ ＡＣＫリクエストのデータ配置図。 本発明によるＳＩＰ ＩＮＦＯリクエストのデータ配置図。 本発明によるＳＩＰ ＢＹＥリクエストのデータ配置図。

Claims (50)

1. インターネットプロトコル（ＩＰ）を用いる通信システム用のインタフェース呼シグナリングプロトコルであって、
   ダイレクトルーティング情報を有するユーザ識別拡張部と、
   ネットワークアドレスを有するサーバ識別拡張部と、
   テーブルアクセスが実行されていることを示すための加入者データベースフラグとを含むＩＮＶＩＴＥリクエストフィールドを含むインタフェース呼シグナリングプロトコル。
2. ダイレクトルーティング情報を有するユーザ識別拡張部と、
   ネットワークアドレスを有するサーバ識別拡張部とを含むＦｒｏｍヘッダフィールドを含む請求項１に記載のインタフェース呼シグナリングプロトコル。
3. ダイレクトルーティング情報を有するユーザ識別拡張部と、
   ネットワークアドレスを有するサーバ識別拡張部とを含むＴｏヘッダフィールドを含む請求項１に記載のインタフェース呼シグナリングプロトコル。
4. ダイレクトルーティング情報を有するユーザ識別拡張部と、
   ネットワークアドレスを有するサーバ識別拡張部と、
   ユーザ識別拡張部を保存するためのキャッシュフラグとを含むＣｏｎｔａｃｔヘッダフィールドを含む請求項１に記載のインタフェース呼シグナリングプロトコル。
5. 「音声シグナリングゲートウェイ」を示す製品拡張部と、
   製品バージョン拡張部とを含むユーザエージェントフィールドを含む請求項１に記載のインタフェース呼シグナリングプロトコル。
6. ２Ｇゲートウェイを表すメディアタイプ拡張部を含むコンテンツタイプヘッダフィールドを含む請求項１に記載のインタフェース呼シグナリングプロトコル。
7. ２Ｇゲートウェイを表す呼処理タイプメディアタイプ拡張部を含むメッセージ本体フィールドを含む請求項１に記載のインタフェース呼シグナリングプロトコル。
8. インターネットプロトコルはセッション開始プロトコル（ＳＩＰ）を含み、ＩＮＶＩＴＥリクエストフィールドはＳＩＰ ＩＮＶＩＴＥリクエストである請求項１に記載のインタフェース呼シグナリングプロトコル。
9. セッション記述プロトコルのインターネットプロトコルにおいて、メッセージ本体がマルチパートメッセージを示すとき、セッション記述プロトコル用の属性拡張部を含む請求項１に記載のインタフェース呼シグナリングプロトコル。
10. ビアヘッダフィールド、最大転送ヘッダフィールド、呼識別ヘッダフィールド、Ｃｓｅｑヘッダ及びコンテンツ長ヘッダを含む請求項１に記載のインタフェース呼シグナリングプロトコル。
11. インターネットプロトコル（ＩＰ）を用いる通信システム用のインタフェース呼シグナリングプロトコルであって、
    ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むＦｒｏｍヘッダフィールドを含むインタフェース呼シグナリングプロトコル。
12. ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むＴｏヘッダフィールドを含む請求項１１に記載のインタフェース呼シグナリングプロトコル。
13. ルーティング情報用の範囲拡張部を含むＣｏｎｔａｃｔヘッダフィールドを含む請求項１１に記載のインタフェース呼シグナリングプロトコル。
14. インターネットプロトコルはセッション開始プロトコル（ＳＩＰ）を含み、ＩＮＶＩＴＥレスポンスフィールドはＳＩＰ ３０１ ＩＮＶＩＴＥレスポンスである請求項１１に記載のインタフェース呼シグナリングプロトコル。
15. ビアヘッダフィールド、呼識別ヘッダフィールド、Ｃｓｅｑヘッダフィールド及びコンテンツ長ヘッダフィールドを含む請求項１１に記載のインタフェース呼シグナリングプロトコル。
16. インターネットプロトコル（ＩＰ）を用いる通信システム用のインタフェース呼シグナリングプロトコルであって、
    ＩＮＶＩＴＥレスポンスフィールドと、Ｆｒｏｍヘッダフィールドとを含み、
    Ｆｒｏｍヘッダフィールドは、
    ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むインタフェース呼シグナリングプロトコル。
17. ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むＴｏヘッダフィールドを含む請求項１６に記載のインタフェース呼シグナリングプロトコル。
18. ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部と、
    テーブルアクセスが実行されていることを示すための加入者データベースフラグとを含むＣｏｎｔａｃｔヘッダフィールドを含む請求項１６に記載のインタフェース呼シグナリングプロトコル。
19. インターネットプロトコルはセッション開始プロトコル（ＳＩＰ）を含み、ＩＮＶＩＴＥレスポンスフィールドはＳＩＰ ３０２ ＩＮＶＩＴＥレスポンスを含む請求項１６に記載のインタフェース呼シグナリングプロトコル。
20. ビアヘッダフィールド、呼識別ヘッダフィールド、Ｃｓｅｑヘッダフィールド及びコンテンツ長ヘッダフィールドを含む請求項１６に記載のインタフェース呼シグナリングプロトコル。
21. インターネットプロトコル（ＩＰ）を用いる通信システム用のインタフェース呼シグナリングプロトコルであって、
    ＩＮＶＩＴＥレスポンスフィールドと、Ｆｒｏｍヘッダフィールドとを含み、
    Ｆｒｏｍヘッダフィールドは、
    ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むインタフェース呼シグナリングプロトコル。
22. ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むＴｏヘッダフィールドを含む請求項２１に記載のインタフェース呼シグナリングプロトコル。
23. ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部と、
    ユーザ識別拡張部を保存するためのキャッシュフラグとを含むＣｏｎｔａｃｔヘッダフィールドを含む請求項２１に記載のインタフェース呼シグナリングプロトコル。
24. 製品拡張部及びインタフェース用製品バージョン拡張部を含むサーバヘッダフィールドを含む請求項２１に記載のインタフェース呼シグナリングプロトコル。
25. セッション記述プロトコルのインターネットプロトコルにおいて、メッセージ本体がセッション記述メッセージを示すとき、セッション記述プロトコル用の属性拡張部を含む請求項２１に記載のインタフェース呼シグナリングプロトコル。
26. インターネットプロトコルはセッション開始プロトコル（ＳＩＰ）を含み、ＩＮＶＩＴＥレスポンスフィールドはＳＩＰ ２００ ＩＮＶＩＴＥレスポンスである請求項２１に記載のインタフェース呼シグナリングプロトコル。
27. ビアヘッダフィールド、呼識別ヘッダフィールド、Ｃｓｅｑヘッダフィールド、コンテンツタイプヘッダフィールド及びコンテンツ長ヘッダフィールドを含む請求項２１に記載のインタフェース呼シグナリングプロトコル。
28. インターネットプロトコル（ＩＰ）を用いる通信システム用のインタフェース呼シグナリングプロトコルであって、
    ＩＮＶＩＴＥレスポンスフィールドと、Ｆｒｏｍヘッダフィールドとを含み、
    Ｆｒｏｍヘッダフィールドは、
    ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むインタフェース呼シグナリングプロトコル。
29. ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むＦｒｏｍヘッダフィールドを含む請求項２８に記載のインタフェース呼シグナリングプロトコル。
30. プロトコル拡張部、原因拡張部及びテキスト拡張部を含む理由ヘッダフィールドを含む請求項２８に記載のインタフェース呼シグナリングプロトコル。
31. インターネットプロトコルはセッション開始プロトコル（ＳＩＰ）を含み、ＩＮＶＩＴＥレスポンスフィールドはＳＩＰ ４ＸＸ−６ＸＸ ＩＮＶＩＴＥレスポンスである請求項２８に記載のインタフェース呼シグナリングプロトコル。
32. ビアヘッダフィールド、呼識別ヘッダフィールド、Ｃｓｅｑヘッダフィールド及びコンテンツ長ヘッダフィールドを含む請求項２８に記載のインタフェース呼シグナリングプロトコル。
33. インターネットプロトコル（ＩＰ）を用いる通信システム用のインタフェース呼シグナリングプロトコルであって、
    ＡＣＫリクエストフィールドと、Ｆｒｏｍヘッダフィールドとを含み、
    Ｆｒｏｍヘッダフィールドは、
    ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むインタフェース呼シグナリングプロトコル。
34. ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むＴｏヘッダフィールドを含む請求項３３に記載のインタフェース呼シグナリングプロトコル。
35. インターネットプロトコルはセッション開始プロトコル（ＳＩＰ）を含み、ＡＣＫリクエストフィールドはＳＩＰ ＡＣＫリクエストである請求項３３に記載のインタフェース呼シグナリングプロトコル。
36. ビアヘッダフィールド、最大転送ヘッダフィールド、呼識別ヘッダフィールド、Ｃｓｅｑヘッダフィールド、コンテンツタイプヘッダフィールド及びコンテンツ長ヘッダフィールドを含む請求項３３に記載のインタフェース呼シグナリングプロトコル。
37. セッション記述プロトコルのインターネットプロトコルにおいて、メッセージ本体がセッション記述メッセージを示すとき、セッション記述プロトコル用の属性拡張部を含む請求項３３に記載のインタフェース呼シグナリングプロトコル。
38. インターネットプロトコル（ＩＰ）を用いる通信システム用のインタフェース呼シグナリングプロトコルであって、
    ２Ｇゲートウェイを識別するためのメッセージ本体と、
    複数のパラメータを表すトーカ調停拡張部とを含むインタフェース呼シグナリングプロトコル。
39. 情報リクエスト拡張部と、
    調停タイプ拡張部を含むコンテンツタイプヘッダフィールドとを含む請求項３８に記載のインタフェース呼シグナリングプロトコル。
40. ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むＦｒｏｍヘッダフィールドを含む請求項３８に記載のインタフェース呼シグナリングプロトコル。
41. ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むＴｏヘッダフィールドを含む請求項３８に記載のインタフェース呼シグナリングプロトコル。
42. インターネットプロトコルはセッション開始プロトコル（ＳＩＰ）を含み、情報リクエスト拡張部はＳＩＰ ＩＮＦＯリクエストを含む請求項３９に記載のインタフェース呼シグナリングプロトコル。
43. ビアヘッダフィールド、最大転送ヘッダフィールド、呼識別ヘッダフィールド、Ｃｓｅｑヘッダフィールド及びコンテンツ長ヘッダフィールドを含む請求項３８に記載のインタフェース呼シグナリングプロトコル。
44. インターネットプロトコル（ＩＰ）を用いる通信システム用のインタフェース呼シグナリングプロトコルであって、
    ＢＹＥリクエストフィールドと、
    呼持続時間拡張部を含むゲートウェイ呼処理メッセージ本体フィールドとを含むインタ
    フェース呼シグナリングプロトコル。
45. ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むＦｒｏｍヘッダフィールドを含む請求項４４に記載のインタフェース呼シグナリングプロトコル。
46. ダイレクトルーティング情報を有するユーザ識別拡張部と、
    ネットワークアドレスを有するサーバ識別拡張部とを含むＴｏヘッダフィールドを含む請求項４４に記載のインタフェース呼シグナリングプロトコル。
47. プロトコル拡張部、原因拡張部及びテキスト拡張部を含む理由ヘッダフィールドを含む請求項４４に記載のインタフェース呼シグナリングプロトコル。
48. メディアタイプ拡張部を含むコンテンツタイプヘッダフィールドを含む請求項４４に記載のインタフェース呼シグナリングプロトコル。
49. ビアヘッダフィールド、最大転送ヘッダフィールド、呼識別ヘッダフィールド、Ｃｓｅｑヘッダフィールド及びコンテンツ長ヘッダフィールドを含む請求項４４に記載のインタフェース呼シグナリングプロトコル。
50. インターネットプロトコルはセッション開始プロトコル（ＳＩＰ）を含み、ＢＹＥリクエストフィールドはＳＩＰ ＢＹＥリクエストである請求項４４に記載のインタフェース呼シグナリングプロトコル。

Images