(57)【要約】【課題】初めて出現する文字列パターンを多く含むシグナリングメッセージであっても効率の良い圧縮が可能なシグナリング圧縮装置を得る。【解決手段】固定／可変パターン分離部１は、シグナリングメッセージ内の固定的な文字列パターンと可変な文字列パターンとを識別して、固定的な文字列が連続するよう文字列の並べ替えを行う。圧縮器２は、固定／可変パターン分離部１から出力されたシグナリングメッセージを圧縮する。固定／可変パターン結合部５は、伸長器４で伸長されたシグナリングメッセージに対して、シグナリングプロトコルによって規定される書式に従った順序に戻す文字列の並べ替えを行う。【選択図】図１
2010258787.tif 000002
【特許請求の範囲】
【請求項１】
静的辞書または動的辞書のうち少なくともいずれか一方を用いてシグナリングメッセージを圧縮する圧縮器と、
前記圧縮器の前段側で、前記シグナリングメッセージ内の固定的な文字列パターンと可変な文字列パターンとを識別して、固定的な文字列が連続するよう文字列の並べ替えを行う固定／可変パターン分離部とを備えたシグナリング圧縮装置。
【請求項２】
シグナリングメッセージ内のヘッダ記述順序を予め定めた優先度に従って変更するヘッダ順序並べ替え部と、
前記ヘッダ順序並べ替え部で並べ替えられたシグナリングメッセージ内の固定的な文字列パターンと可変な文字列パターンとを識別して、固定的な文字列が連続するよう文字列の並べ替えを行う固定／可変パターン分離部とを備えたシグナリング圧縮装置。
【請求項３】
固定／可変パターン分離部で並べ替えられた文字列に対して、メッセージ種別毎に予め定められた必須ヘッダを削除する必須ヘッダ削除部を備えたことを特徴とする請求項１または請求項２記載のシグナリング圧縮装置。
【請求項４】
シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内に複数のＶｉａヘッダが含まれる場合に一部のＶｉａヘッダを削除するＶｉａヘッダ削除部を備えたシグナリング圧縮装置。
【請求項５】
シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが含まれる場合にこれを削除するＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部を備えたことを特徴とするシグナリング圧縮装置。
【請求項６】
シグナリングプロトコルがＳＩＰである場合、Ｃａｌｌ−ＩＤヘッダの文字列を短縮コードに変換するＣａｌｌ−ＩＤ短縮コード化部を備えたことを特徴とするシグナリング圧縮装置。
【請求項７】
シグナリングプロトコルがＳＩＰである場合、Ｆｒｏｍヘッダのｔａｇパラメータ文字列を短縮コードに変換するＦｒｏｍｔａｇ短縮コード化部を備えたことを特徴とするシグナリング圧縮装置。
【請求項８】
シグナリングプロトコルがＳＩＰである場合、Ｔｏヘッダのｔａｇパラメータ文字列を短縮コードに変換するＴｏｔａｇ短縮コード化部を備えたことを特徴とするシグナリング圧縮装置。
【請求項９】
シグナリングプロトコルがＳＩＰである場合、Ｖｉａヘッダのｂｒａｎｃｈパラメータ文字列を短縮コードに変換するｂｒａｎｃｈ短縮コード化部を備えたことを特徴とするシグナリング圧縮装置。
【請求項１０】
固定的な文字列が連続するように文字列の並べ替えが行われたメッセージに対して、シグナリングプロトコルによって規定される書式に従った順序に戻す文字列の並べ替えを行う固定／可変パターン結合部を備えたシグナリング伸長装置。
【請求項１１】
固定／可変パターン結合部の前段側で、シグナリングプロトコルによって規定される必須ヘッダを挿入する必須ヘッダ挿入部を備えたことを特徴とする請求項１０記載のシグナリング伸長装置。
【請求項１２】
シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内に複数のＶｉａヘッダが含まれる場合に一部のＶｉａヘッダを削除すると共に、当該削除したＶｉａヘッダをＶｉａヘッダ保持部に保持させるＶｉａヘッダ削除部と、
前記リクエストメッセージに対応する応答メッセージに対して、前記Ｖｉａヘッダ保持部に保持されているＶｉａヘッダを挿入するＶｉａヘッダ挿入部を備えたシグナリング圧縮伸長装置。
【請求項１３】
シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが含まれる場合にこれを削除すると共に、当該削除したＲｅｃｏｒｄ−ＲｏｕｔｅヘッダをＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部に保持させるＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部と、
前記リクエストメッセージに対応する応答メッセージに対して、前記Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部に保持されているＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを挿入するＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部と、
Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダが削除されたリクエストメッセージを受信した場合、前記Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部に保持されているＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを元にＲｏｕｔｅヘッダを生成し、当該リクエストメッセージに対して挿入するＲｏｕｔｅヘッダ挿入部を備えたシグナリング圧縮伸長装置。
【請求項１４】
シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内のＣａｌｌ−ＩＤヘッダに短縮コードが含まれる場合、当該短縮コードをＣａｌｌ−ＩＤヘッダ文字列に変換すると共に、当該短縮コードとＣａｌｌ−ＩＤヘッダとの対応関係をＣａｌｌ−ＩＤ短縮コード／文字列対応テーブルに保持させるＣａｌｌ−ＩＤ文字列化部と、
前記リクエストメッセージに対応する応答メッセージに対して、前記Ｃａｌｌ−ＩＤ短縮コード／文字列対応テーブルを参照し、Ｃａｌｌ−ＩＤヘッダ文字列に対応した短縮コードに変換するＣａｌｌ−ＩＤ短縮コード化部とを備えたシグナリング圧縮伸長装置。
【請求項１５】
シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内のＦｒｏｍヘッダのｔａｇパラメータに短縮コードが含まれる場合、当該短縮コードをｔａｇパラメータ文字列に変換すると共に、前記短縮コードと文字列との対応関係をＦｒｏｍｔａｇ短縮コード／文字列対応テーブルに保持させるＦｒｏｍｔａｇ文字列化部と、
前記リクエストメッセージに対応する応答メッセージに対して、前記Ｆｒｏｍｔａｇ短縮コード／文字列対応テーブルを参照し、Ｆｒｏｍヘッダのｔａｇパラメータ文字列に対応した短縮コードに変換するＦｒｏｍｔａｇ短縮コード化部とを備えたシグナリング圧縮伸長装置。
【請求項１６】
シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内のＴｏヘッダのｔａｇパラメータに短縮コードが含まれる場合、当該短縮コードをＴｏヘッダのｔａｇパラメータ文字列に変換すると共に、前記短縮コードと文字列との対応関係をＴｏｔａｇ短縮コード／文字列対応テーブルに保持させるＴｏｔａｇ文字列化部と、
前記リクエストメッセージに対応する応答メッセージに対して、前記Ｔｏｔａｇ短縮コード／文字列対応テーブルを参照し、Ｔｏヘッダのｔａｇパラメータ文字列に対応した短縮コードに変換するＴｏｔａｇ短縮コード化部とを備えたシグナリング圧縮伸長装置。
【請求項１７】
シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内のＶｉａヘッダのｔａｇパラメータに短縮コードが含まれる場合、当該短縮コードをＶｉａヘッダのｂｒａｎｃｈパラメータ文字列に変換すると共に、前記短縮コードと文字列との対応関係をｂｒａｎｃｈ短縮コード／文字列対応テーブルに保持させるｂｒａｎｃｈ文字列化部と、
前記リクエストメッセージに対応する応答メッセージに対して、前記ｂｒａｎｃｈ短縮コード／文字列対応テーブルを参照し、Ｖｉａヘッダのｂｒａｎｃｈパラメータ文字列に対応した短縮コードに変換するｂｒａｎｃｈ短縮コード化部とを備えたシグナリング圧縮伸長装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、呼制御に用いられるシグナリングメッセージを圧縮するシグナリング圧縮装置および圧縮されたシグナリングメッセージを伸長するシグナリング伸長装置およびシグナリングメッセージの圧縮／伸長を行うシグナリング圧縮伸長装置に関するものである。
【背景技術】
【０００２】
近年のＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークの発展に伴い、電話音声信号やファクシミリ信号をＩＰパケット化して伝送するＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）技術が注目されている。各国の通信キャリアは、従来の回線交換用の通信設備をＩＰ用の設備に置き換えつつある状況であり、このため、特に有線通信の分野ではＶｏＩＰの普及が急速に進んでいる。ＶｏＩＰによる電話の呼制御には、音声や画像などマルチメディア通信を行うために必要なセッションの開始や終了を行うプロトコルであるＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）が広く普及している。また、ＩＰネットワークの広がりは無線にまで及び、近年は無線ＶｏＩＰの実用化が期待されているが、無線伝送路の帯域は有線に比べて狭いという問題がある。上記ＳＩＰではデータ量の大きいテキストメッセージをＩＰパケットに乗せて伝送するプロトコルであり、帯域の狭い回線で用いるとメッセージ伝送遅延が大きくなる。このため、ＳＩＰのようなデータ量の大きいメッセージを圧縮伝送する技術が要望されている。
【０００３】
このようなＳＩＰメッセージを圧縮するシグナリング圧縮方式として、例えば、特許文献１に示されたような従来の方式では、圧縮器（コンプレッサ）、圧縮辞書（コードブック）、及び伸長器（デコンプレッサ）を備える。圧縮器は予め用意したテンプレートを用いてそのテンプレートに適合する文字列を削除し、伝送すべき文字列を生成する。圧縮辞書は、ＳＩＰメッセージ固有の文字列パターンを格納する静的辞書と、新たな文字列パターンが出現した場合にこれを格納する動的辞書から成る。圧縮器はこれらの辞書を用い、上記テンプレートを用いて生成した文字列に対して更に符号化を行う。伸長器では圧縮器と逆の処理が行われ、圧縮されたメッセージを復元する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−９６７１７号公報（段落番号［００２８］から［００４３］、図４）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のシグナリング圧縮方式では、ＳＩＰメッセージ固有の文字列は、上記テンプレートまたは静的辞書によって圧縮され、それ以外の文字列は動的辞書によって圧縮される。動的辞書による圧縮には、通常ＬＺ（Ｌｅｍｐｅｌ−Ｚｉｖ）タイプ圧縮方式が用いられる。この圧縮方式は、過去に出現した文字列パターンを動的辞書の中に組み込むことによって、繰り返し出現する文字列パターンを効率良く圧縮出来る。しかしながら、辞書内に存在しない初めて出現する文字列パターンは圧縮されない。つまりＬＺタイプ圧縮方式をベースとした従来のシグナリング圧縮方式は、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対しては圧縮効率が悪いという課題があった。
【０００６】
この発明は上記のような課題を解決するためになされたもので、初めて出現する文字列パターンを多く含むシグナリングメッセージであっても効率の良い圧縮が可能なシグナリング圧縮装置、シグナリング伸長装置およびシグナリング圧縮伸長装置を得ることを目的とする。
【課題を解決するための手段】
【０００７】
この発明に係るシグナリング圧縮装置は、静的辞書または動的辞書のうち少なくともいずれか一方を用いてシグナリングメッセージを圧縮する圧縮器と、圧縮器の前段側で、シグナリングメッセージ内の固定的な文字列パターンと可変な文字列パターンとを識別して、固定的な文字列が連続するよう文字列の並べ替えを行う固定／可変パターン分離部とを備えたものである。
【発明の効果】
【０００８】
この発明のシグナリング圧縮装置は、圧縮器の前段側で、シグナリングメッセージ内の固定的な文字列パターンと可変な文字列パターンとを識別して、固定的な文字列が連続するよう文字列の並べ替えを行うようにしたので、初めて出現する文字列パターンを多く含むシグナリングメッセージであっても効率の良い圧縮を行うことができる。
【図面の簡単な説明】
【０００９】
【図１】この発明の実施の形態１によるシグナリング圧縮装置とシグナリング伸長装置とを示す構成図である。
【図２】この発明の実施の形態１のシグナリング圧縮装置における文字列並べ替え前の非圧縮メッセージを示す説明図である。
【図３】この発明の実施の形態１のシグナリング圧縮装置における固定／可変パターン分離後のメッセージを示す説明図である。
【図４】この発明の実施の形態２によるシグナリング圧縮装置とシグナリング伸長装置とを示す構成図である。
【図５】この発明の実施の形態２のシグナリング圧縮装置における非圧縮メッセージを示す説明図である。
【図６】この発明の実施の形態２のシグナリング圧縮装置におけるヘッダ順序並べ替え後のメッセージを示す説明図である。
【図７】この発明の実施の形態３によるシグナリング圧縮装置とシグナリング伸長装置とを示す構成図である。
【図８】この発明の実施の形態３のシグナリング圧縮装置における必須ヘッダ削除後のメッセージを示す説明図である。
【図９】この発明の実施の形態３のシグナリング伸長装置における必須ヘッダ挿入後のメッセージを示す説明図である。
【図１０】ＳＩＰに関するネットワーク構成要素と伝送されるメッセージの流れを示す説明図である。
【図１１】この発明の実施の形態４によるシグナリング圧縮伸長装置を示す構成図である。
【図１２】この発明の実施の形態４のシグナリング圧縮伸長装置におけるＳＩＰサーバ（Ｂ）が出力する非圧縮メッセージを示す説明図である。
【図１３】この発明の実施の形態４のシグナリング圧縮伸長装置におけるＶｉａヘッダ削除後のメッセージを示す説明図である。
【図１４】この発明の実施の形態４のシグナリング圧縮伸長装置におけるＳＩＰ−ＵＡ（Ｂ）が出力する非圧縮メッセージを示す説明図である。
【図１５】この発明の実施の形態４のシグナリング圧縮伸長装置における伸長メッセージを示す説明図である。
【図１６】この発明の実施の形態６によるシグナリング圧縮伸長装置を示す構成図である。
【図１７】この発明の実施の形態６のシグナリング圧縮伸長装置におけるＶｉａヘッダ削除後のメッセージを示す説明図である。
【図１８】この発明の実施の形態６のシグナリング圧縮伸長装置におけるＳＩＰ−ＵＡ（Ｂ）が出力する非圧縮メッセージを示す説明図である。
【図１９】この発明の実施の形態６のシグナリング伸長装置における伸長メッセージを示す説明図である。
【図２０】この発明の実施の形態６のシグナリング圧縮伸長装置におけるＳＩＰ−ＵＡ（Ｂ）が出力する非圧縮メッセージを示す説明図である。
【図２１】この発明の実施の形態６によるシグナリング圧縮伸長装置におけるＲｏｕｔｅヘッダ挿入後のメッセージを示す説明図である。
【図２２】この発明の実施の形態８によるシグナリング圧縮伸長装置の構成図である。
【図２３】この発明の実施の形態８のシグナリング圧縮伸長装置におけるＳＩＰサーバ（Ｂ）側から受信したＣａｌｌ−ＩＤ短縮コード化後のメッセージを示す説明図である。
【図２４】この発明の実施の形態８のシグナリング圧縮伸長装置におけるＳＩＰ−ＵＡ（Ｂ）に送信するＣａｌｌ−ＩＤ文字列化後のメッセージを示す説明図である。
【図２５】この発明の実施の形態８のシグナリング圧縮伸長装置におけるＳＩＰ−ＵＡ（Ｂ）が出力する非圧縮メッセージを示す説明図である。
【図２６】この発明の実施の形態８のシグナリング圧縮伸長装置におけるＳＩＰサーバ（Ｂ）に送信するＣａｌｌ−ＩＤ短縮コード化後のメッセージを示す説明図である。
【図２７】この発明の実施の形態８のシグナリング圧縮伸長装置におけるＣａｌｌ−ＩＤ文字列化後のメッセージを示す説明図である。
【図２８】この発明の実施の形態１０によるシグナリング圧縮伸長装置を示す構成図である。
【図２９】この発明の実施の形態１１によるシグナリング圧縮伸長装置を示す構成図である。
【図３０】この発明の実施の形態１２によるシグナリング圧縮伸長装置を示す構成図である。
【発明を実施するための形態】
【００１０】
実施の形態１．
図１は、この発明の実施の形態１によるシグナリング圧縮装置とシグナリング伸長装置を示す構成図である。
図において、シグナリング圧縮装置は、固定／可変パターン分離部１と圧縮器２とからなり、シグナリング伸長装置は、伸長器４と固定／可変パターン結合部５からなる。シグナリング圧縮装置は、非圧縮メッセージ（ＳＩＰメッセージ）が入力されると、固定／可変パターン分離部１及び圧縮器２によってこの非圧縮メッセージ（ＳＩＰメッセージ）が圧縮され、得られた圧縮メッセージを出力する装置である。また、シグナリング伸長装置は、伝送路３で伝送された圧縮メッセージを受信し、これが伸長器４及び固定／可変パターン結合部５によって非圧縮メッセージ（ＳＩＰメッセージ）に復元する装置である。
【００１１】
シグナリング圧縮装置における固定／可変パターン分離部１は、入力した非圧縮メッセージ（ＳＩＰメッセージ）中の固定の文字列パターンと、メッセージ毎に異なる可変の文字列パターンとが分離された状態になるように、文字列の並べ替えを行う。圧縮器２は、ＬＺ（Ｌｅｍｐｅｌ−Ｚｉｖ）タイプ圧縮方式として一般的なＬＺ７７（Ｌｅｍｐｅｌ−Ｚｉｖ  ７７）方式とハフマン符号化を組み合わせたＤＥＦＬＡＴＥ符号化方式により、文字列並べ替えが行われた後のメッセージを圧縮して、得られた圧縮メッセージを伝送路３に出力する。また、シグナリング伸長装置における伸長器４は、伝送路３から入力した圧縮メッセージをＬＺ７７方式により伸長し、固定／可変パターン結合部５に出力する。固定／可変パターン結合部５は、伸長器４より固定の文字列パターンと可変の文字列パターンとが分離されたメッセージを入力し、分離された固定の文字列パターンと可変の文字列パターンとをＳＩＰメッセージの書式に従うように結合し、元の非圧縮メッセージ（ＳＩＰメッセージ）を復元する。
【００１２】
以下、固定／可変パターン分離部１と固定／可変パターン結合部５の文字列並べ替え動作について図２及び図３を用いて説明する。
図２は、文字列並べ替え前の非圧縮メッセージ（ＳＩＰメッセージ）である。図において、１行目の「ＩＮＶＩＴＥ」まではリクエスト名でＳＩＰ固有の固定文字列パターンであるが、「ｓｉｐ：ｂｏｂ＠ａｂｃｄｅｆｇ．ｅｘａｍｐｌｅ．ｃｏｍ」はこのリクエストの送信先を示すＵＲＩであるため可変の文字列である。また、「ＳＩＰ／２．０」はＳＩＰというプロトコルでバージョンが２．０であることを示す部分であり、固定の文字列となる。従って、固定／可変パターン分離部１は「ＩＮＶＩＴＥ  ＳＩＰ／２．０」を固定文字列、「ｓｉｐ：ｂｏｂ＠ａｂｃｄｅｆｇ．ｅｘａｍｐｌｅ．ｃｏｍ」を可変文字列であると判定して、それぞれを分離する。２行目については、「Ｖｉａ：」はＳＩＰで規定されるヘッダの名称で固定文字列であり、「ＳＩＰ／２．０］は上記１行目と同様に固定文字列となる。「／ＵＤＰ」はＳＩＰメッセージの伝送に用いるトランスポート層がＵＤＰであることを示しており、メッセージ毎に変わるものではないためここまでを固定文字列と判定する。４行目のＦｒｏｍヘッダから１０行目のＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダまでについては、ヘッダ名称と「：」までは固定文字列であり、それ以降がヘッダのパラメータであり可変文字列となる。１２行目のｖ＝０からは、ＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）ボディ部であり、音声や画像などのメディアストリーム制御用の記述となっている。どの行も「＝」まではＳＤＰ固有の文字列であり、「＝」以降が制御パラメータである。よって各行の「＝」までが固定文字列、それ以降が可変文字列となる。
【００１３】
以上に説明した固定文字列と可変文字列の判断基準による上記固定／可変パターン分離部１の出力は、図３に示す通りとなる。図において、１行目から１８行目（「ａ＝」まで）が固定文字列パターン部分であり、２１行目（「ｓｉｐ：ｂｏｂ＠ａｂｃｄｅｆｇ．ｅｘａｍｐｌｅ．ｃｏｍ」）以降が可変文字列パターン部分となる。固定文字列パターン部分と可変文字列パターン部分との境界には２行の空行を設けている。ＳＩＰメッセージの書式上は２行以上の空行が存在しないため、これらの空行を境界の判断に用いる。
【００１４】
ＬＺタイプの圧縮方式では、辞書を検索して入力メッセージ内の文字列パターンと一致するパターンを探し、その辞書内で見つかった文字列パターンの位置と長さの情報を符号化する。これは圧縮ブロックと呼ばれる。逆に辞書内に一致するパターンがない場合は、入力文字列をそのまま出力する。これは非圧縮ブロックと呼ばれる。従って、図２に示すように固定文字列パターン部分と初めて出現する可変文字列パターン部分とが混在すると、圧縮メッセージ全体では、圧縮ブロックと非圧縮ブロックが交互に現れることになる。一方、図３に示すように固定の文字列パターンが集中して配置されている場合は、この部分が１個の圧縮ブロックとして符号化される。具体的には、図３に示したメッセージ中、１行目（「ＩＮＶＩＴＥ  ＳＩＰ／２．０」）から１８行目（「ａ＝」）までが１個の圧縮ブロックとなる。つまり多くの文字数が１個の圧縮ブロックとなるため、図２に示すメッセージを圧縮する場合と比較して圧縮効率が改善される。
【００１５】
このように、実施の形態１のシグナリング圧縮装置では、固定／可変パターン分離部１が、ＤＥＦＬＡＴＥ符号化方式による圧縮の前に入力メッセージ中の固定の文字列パターンと可変の文字列パターンとが分離された状態になるように文字列の並べ替えを行うので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮が可能なシグナリング圧縮方式を得ることが出来る。
【００１６】
以上説明したように、実施の形態１のシグナリング圧縮装置によれば、静的辞書または動的辞書のうち少なくともいずれか一方を用いてシグナリングメッセージを圧縮する圧縮器と、圧縮器の前段側で、シグナリングメッセージ内の固定的な文字列パターンと可変な文字列パターンとを識別して、固定的な文字列が連続するよう文字列の並べ替えを行う固定／可変パターン分離部とを備えたので、初めて出現する文字列パターンを多く含むシグナリングメッセージであっても効率の良い圧縮を可能とすることができる。
【００１７】
また、実施の形態１のシグナリング伸長装置によれば、固定的な文字列が連続するように文字列の並べ替えが行われたメッセージに対して、シグナリングプロトコルによって規定される書式に従った順序に戻す文字列の並べ替えを行う固定／可変パターン結合部を備えたので、圧縮されたメッセージに対してもシグナリングプロトコルによって規定される書式に従ったメッセージとして出力することができる。
【００１８】
実施の形態２．
図４は、この発明の実施の形態２によるシグナリング圧縮装置及びシグナリング伸長装置を示す構成図である。
図において、シグナリング圧縮装置は、固定／可変パターン分離部１、圧縮器２、ヘッダ順序並べ替え部６からなり、シグナリング伸長装置は、伸長器４と固定／可変パターン結合部５からなる。
シグナリング圧縮装置におけるヘッダ順序並べ替え部６は、入力するＳＩＰメッセージ内のヘッダの順序を予め定めておいた規則に従って並べ替える機能部である。シグナリング圧縮装置におけるその他のブロック及びシグナリング伸長装置の各ブロックについては、図１に示した実施の形態１における各ブロックと同様であるため、ここでの説明は省略する。
【００１９】
ここで、図５に示す非圧縮メッセージ（ＳＩＰメッセージ）が入力された場合のヘッダ順序並べ替え部６の動作を説明する。ヘッダ順序並べ替え部６では、ヘッダ順序の規則として、Ｖｉａヘッダ、Ｍａｘ−Ｆｏｒｗａｒｄｓヘッダ、Ｆｒｏｍヘッダ、Ｔｏヘッダ、Ｃａｌｌ−ＩＤヘッダ、ＣＳｅｑヘッダ、Ｃｏｎｔａｃｔヘッダ、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダ、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダの順に並べ替えるものとする。ヘッダ順序並べ替え部６は図５に示すメッセージを入力すると、上記ヘッダ順序の規定に従って並べ替えを行い、図６に示すメッセージを出力する。
【００２０】
入力ＳＩＰメッセージのヘッダ順序については、同一のＳＩＰ端末が出力するメッセージであれば通常は常に同じ順序となるが、このシグナリング圧縮方法が複数のＳＩＰ端末からのメッセージを圧縮・伝送する用途で用いられる場合、どのような順序となるかは不定である。これはＳＩＰの規定上、メッセージ内のヘッダ順序について特に制約がないためである。このような場合、ヘッダ順序並べ替え部６によってヘッダ順序を常に一定に保つことで、固定文字列パターン部分が常に同じパターンとなり、ＤＥＦＬＡＴＥ符号化方式による圧縮率を改善することが出来る。
【００２１】
尚、ヘッダ順序並べ替え部６以外の各ブロックの動作は図１の場合と同様である。図６に示すメッセージは、固定／可変パターン分離部１及び圧縮器２によって圧縮され、更に、伸長器４及び固定／可変パターン結合部５で伸長されると、図６に示すヘッダ順序並べ替え後のメッセージに復元される。つまり、図５に示した元の非圧縮メッセージには復元されないことになるが、上述の通りＳＩＰの規定ではヘッダ順序に制約はないため、元の順序が復元されなくても不都合は生じない。また、ＳＩＰメッセージ中のＳＤＰボディ部については、各行の並べ替えを行わないが、これは、ＳＤＰの規定により各行の出現順序が固定であるためである。
【００２２】
このように、実施の形態２のシグナリング圧縮装置では、ヘッダ順序並べ替え部６がヘッダの順序を予め定めておいた規則に従って並べ替えるので、複数のＳＩＰ端末からのメッセージを圧縮・伝送する用途で用いる場合でも、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮が可能なシグナリング圧縮方式を得ることが出来る。
【００２３】
以上説明したように、実施の形態２のシグナリング圧縮装置によれば、シグナリングメッセージ内のヘッダ記述順序を予め定めた優先度に従って変更するヘッダ順序並べ替え部６と、ヘッダ順序並べ替え部６で並べ替えられたシグナリングメッセージ内の固定的な文字列パターンと可変な文字列パターンとを識別して、固定的な文字列が連続するよう文字列の並べ替えを行う固定／可変パターン分離部１とを備えたので、複数の端末からのシグナリングメッセージを圧縮・伝送する用途で用いる場合でも、初めて出現する文字列パターンを多く含むシグナリングメッセージに対して効率の良い圧縮を可能とすることができる。
【００２４】
実施の形態３．
図７は、この発明の実施の形態３によるシグナリング圧縮装置とシグナリング伸長装置を示す構成図である。
図においてシグナリング圧縮装置は、固定／可変パターン分離部１、圧縮器２、ヘッダ順序並べ替え部６、必須ヘッダ削除部７からなり、シグナリング伸長装置は、伸長器４、固定／可変パターン結合部５及び必須ヘッダ挿入部８からなる。
【００２５】
シグナリング圧縮装置における必須ヘッダ削除部７は、ＳＩＰの規定によりメッセージの種類毎に必須と定まっているヘッダを削除する機能部である。シグナリング伸長装置における必須ヘッダ挿入部８は、ＳＩＰの規定によりメッセージの種類毎に必須と定まっているヘッダを挿入する機能部である。その他のブロックの動作については、図１及び図４に示したシグナリング圧縮装置及びシグナリング伸長装置の各ブロックと同様である。
【００２６】
以下、先に図３に示した固定／可変パターン分離後のメッセージが必須ヘッダ削除部７の入力である場合の動作を説明する。ＳＩＰの規定では、ＩＮＶＩＴＥメッセージの必須ヘッダは、Ｖｉａヘッダ、Ｍａｘ−Ｆｏｒｗａｒｄｓヘッダ、Ｆｒｏｍヘッダ、Ｔｏヘッダ、Ｃａｌｌ−ＩＤヘッダ、ＣＳｅｑヘッダ、及び、Ｃｏｎｔａｃｔヘッダである。よって、必須ヘッダ削除部７は、図３に示すメッセージを入力してこれらの必須ヘッダ、即ち図３の２行目から８行目を削除し、図８に示すメッセージを出力する。このメッセージは、圧縮器２においてＤＥＦＬＡＴＥ符号化方式による圧縮が行われ、圧縮メッセージが伝送路３に出力される。伸長器４は伝送路３からの圧縮メッセージを入力すると、ＤＥＦＬＡＴＥ符号化方式による伸長処理を行い、図８に示したものと同じメッセージを復元する。必須ヘッダ挿入部８は、図８に示したメッセージに対し、ＩＮＶＩＴＥメッセージの必須ヘッダであるＶｉａヘッダ、Ｍａｘ−Ｆｏｒｗａｒｄｓヘッダ、Ｆｒｏｍヘッダ、Ｔｏヘッダ、Ｃａｌｌ−ＩＤヘッダ、ＣＳｅｑヘッダ、及び、Ｃｏｎｔａｃｔヘッダを、この順番で２行目から挿入する。その結果、図９に示すメッセージが得られる。更に、固定／可変パターン結合部５が図９に示すメッセージを処理すると、図６と同じメッセージが得られる。
【００２７】
このシグナリング圧縮方法では、圧縮器２において、図８に示した必須ヘッダ削除後のメッセージにおける１行目（「ＩＮＶＩＴＥ  ＳＩＰ／２．０」）から１１行目（「ａ＝」）までが１個の圧縮ブロックとなる。図１或いは図４に示したシグナリング圧縮方法においても、固定パターン部分が１個の圧縮ブロックになるという点では同様であるが、固定パターン部分の文字数に違いがある。即ち、一致するパターンの文字数が少ない方が、辞書の検索に要する処理時間が短くなり、処理の高速化を図ることが出来る。
【００２８】
このように、実施の形態３のシグナリング圧縮装置では、ヘッダ順序並べ替え部６がヘッダの順序を予め定めておいた規則に従って並べ替えるので、複数のＳＩＰ端末からのメッセージを圧縮・伝送する用途で用いる場合でも、ＳＩＰメッセージの圧縮効率が良くなると共に、必須ヘッダ削除部７が固定パターン部分の文字数を削減するので、圧縮器２における圧縮処理の高速化が可能なシグナリング圧縮方式を得ることが出来る。
【００２９】
尚、上記実施の形態３では、圧縮器２及び伸長器４を備えているが、これらの圧縮器２と伸長器４を省略する構成としても良い。これらを省略するとＤＥＦＬＡＴＥ符号化方式によるメッセージ圧縮は行われないが、必須ヘッダを削除する分だけメッセージ量を低減することが出来る。
【００３０】
以上説明したように、実施の形態３のシグナリング圧縮装置によれば、固定／可変パターン分離部１で並べ替えられた文字列に対して、メッセージ種別毎に予め定められた必須ヘッダを削除する必須ヘッダ削除部７を備えたので、圧縮器２における圧縮処理の高速化が可能なシグナリング圧縮方式を得ることが出来る。
【００３１】
また、実施の形態３のシグナリング伸長装置によれば、固定／可変パターン結合部５の前段側で、シグナリングプロトコルによって規定される必須ヘッダを挿入する必須ヘッダ挿入部８を備えたので、必須ヘッダが削除されたメッセージに対してもシグナリングプロトコルによって規定される書式に従ったメッセージとして出力することができる。
【００３２】
実施の形態４．
図１０は、ＳＩＰを用いて呼制御が行われるネットワークにおいて、ＳＩＰに関するネットワーク構成要素と伝送されるメッセージの流れを示した例である。図において、ＳＩＰサーバ（Ａ）１０にはＳＩＰ−ＵＡ（Ｕｓｅｒ  Ａｇｅｎｔ）（Ａ）１１が接続され、ＳＩＰサーバ（Ｂ）１２にはＳＩＰ−ＵＡ（Ｂ）１３が接続されている。このようなネットワークにおいて、ＳＩＰサーバ（Ｂ）１２とＳＩＰ−ＵＡ（Ｂ）１３との間が帯域の狭い回線であり、ＳＩＰメッセージの圧縮対象となる伝送路とする。
【００３３】
図１１は、この発明の実施の形態４によるシグナリング圧縮伸長装置を示す構成図であり、図１０のＳＩＰサーバ（Ｂ）１２とＳＩＰ−ＵＡ（Ｂ）１３との間に挿入される場合の構成を示している。図において、ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００はＳＩＰサーバ（Ｂ）１２から入力するＳＩＰメッセージの圧縮とＳＩＰサーバ（Ｂ）１２に出力するＳＩＰメッセージの伸長を行うもので、圧縮器１０１、伸長器１０２、Ｖｉａヘッダ削除部１０３、Ｖｉａヘッダ保持部１０４、Ｖｉａヘッダ挿入部１０５を備えている。また、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００は、ＳＩＰ−ＵＡ（Ｂ）１３から入力するＳＩＰメッセージの圧縮とＳＩＰ−ＵＡ（Ｂ）１３に出力するＳＩＰメッセージの伸長を行うもので、内部構成はＳＩＰサーバ（Ｂ）側圧縮・伸長部１００と同様である。即ち、圧縮器２０１、伸長器２０２、Ｖｉａヘッダ削除部２０３、Ｖｉａヘッダ保持部２０４、Ｖｉａヘッダ挿入部２０５を備えている。ここで、圧縮器１０１，２０１及び伸長器１０２，２０２は、それぞれ図１，４，７における圧縮器２及び伸長器４と同様であるため、ここでの説明は省略する。
【００３４】
また、Ｖｉａヘッダ削除部１０３、２０３は、ＳＩＰのリクエストメッセージ内に複数のＶｉａヘッダが存在する場合、最後に挿入されたＶｉａヘッダを残してそれ以外のＶｉａヘッダの削除を行う。また、Ｖｉａヘッダ保持部１０４、２０４は、Ｖｉａヘッダ削除部１０３、２０３によって削除されたＶｉａヘッダを保持しておくものである。そして、Ｖｉａヘッダ挿入部１０５、２０５は、Ｖｉａヘッダ削除部１０３、２０３によってＶｉａヘッダが削除されたリクエストメッセージに対する応答メッセージに対し、Ｖｉａヘッダ保持部１０４、２０４で保持していたＶｉａヘッダを挿入する機能を有している。
【００３５】
以下、図１０に示すように、呼接続のための最初のメッセージであるＩＮＶＩＴＥリクエストメッセージがＳＩＰ−ＵＡ（Ａ）１１からＳＩＰ−ＵＡ（Ｂ）１３に送信され、このリクエストに対応した２００  ＯＫ応答メッセージがＳＩＰ−ＵＡ（Ｂ）１３からＳＩＰ−ＵＡ（Ａ）１１に送信される場合のＳＩＰメッセージ圧縮・伸長動作について、図１２〜図１５を用いて説明する。
図１２は、ＳＩＰサーバ（Ｂ）１２が出力する非圧縮メッセージ（ＩＮＶＩＴＥリクエスト）である。ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００内のＶｉａヘッダ削除部１０３は図１２に示す非圧縮メッセージを入力すると、このメッセージ中の２行目から６行目に３個あるＶｉａヘッダの中から、先頭にある２行目のＶｉａヘッダを残してそれ以外のＶｉａヘッダを削除する。その結果、図１３に示すメッセージを生成して圧縮器１０１に出力する。またＶｉａヘッダ削除部１０３は、削除した３行目〜６行目のＶｉａヘッダを、残ったＶｉａヘッダのｂｒａｎｃｈパラメータ「ｚ９ｈＧ４ｂＫ７２１ｅ４．１」と共にＶｉａヘッダ保持部１０４に保存する。このｂｒａｎｃｈパラメータは、後に保存したＶｉａヘッダを検索する際のキーに用いられる。圧縮器１０１はＤＥＦＬＡＴＥ符号化方式により図１３に示すＶｉａヘッダ削除後のメッセージを入力してこれを圧縮し、圧縮メッセージを伝送路３０１に出力する。伝送路３０１から圧縮メッセージを受信したＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００内の伸長器２０２は、ＤＥＦＬＡＴＥ符号化方式による伸長処理を行う。その結果、図１３に示すＶｉａヘッダ削除後のメッセージが復元され、これがＶｉａヘッダ挿入部２０５に出力される。Ｖｉａヘッダ挿入部２０５は、リクエストメッセージに対しては何も処理を行わない。従って、図１３に示すメッセージがそのままＳＩＰ−ＵＡ（Ｂ）１３に出力されることとなる。
【００３６】
以上のように、ＳＩＰサーバ（Ｂ）１２から送信されたＩＮＶＩＴＥリクエスト内のＶｉａヘッダの一部が削除された後、ＤＥＦＬＡＴＥ符号化による圧縮が行われるため、その分圧縮メッセージのサイズを小さくすることが出来る。しかし、このＩＮＶＩＴＥリクエストについては、削除されたＶｉａヘッダが復元されないままＳＩＰ−ＵＡ（Ｂ）１３に転送されることとなる。ＳＩＰエンティティ（ＳＩＰ−ＵＡ又はＳＩＰサーバ）は、受信するリクエストメッセージのＶｉａヘッダ中、最終段のＳＩＰエンティティが挿入したＶｉａヘッダのみを必要とする。図１２に示すＩＮＶＩＴＥリクエストメッセージ内のＶｉａヘッダ中、ＳＩＰサーバ（Ｂ）１２が挿入したものは２行目のＶｉａヘッダである。従って、ＳＩＰ−ＵＡ（Ｂ）１３が必要とするのはこの２行目のみである。具体的にはこのヘッダのｂｒａｎｃｈパラメータ「ｚ９ｈＧ４ｂＫ７２１ｅ４．１」はリクエストの識別に用いられる。つまり、このｂｒａｎｃｈパラメータが同じリクエストは同一リクエスト、即ち再送リクエストと見なし、ｂｒａｎｃｈパラメータが異なるリクエストは別のリクエストであると見なすことになっている。Ｖｉａヘッダはこのように用いられるため、３行目以降のＶｉａヘッダが全部もしくは一部削除されても、ＳＩＰ−ＵＡ（Ｂ）１３の動作上、不都合が生じることはない。
【００３７】
ＳＩＰ−ＵＡ（Ｂ）１３が上記ＩＮＶＩＴＥリクエストを受信し、このリクエストを受け付けると２００  ＯＫ応答メッセージを返す。このＳＩＰ−ＵＡ（Ｂ）１３が出力する非圧縮メッセージ（２００  ＯＫ応答メッセージ）を図１４に示す。ＳＩＰの規定上、ＳＩＰーＵＡは全てのリクエストに対する応答メッセージを生成する際、元のリクエストに含まれるＶｉａヘッダを保持しておき、これを挿入する必要がある。従って、図１４に示す非圧縮メッセージ（２００ ＯＫ応答メッセージ）の２行目に、図１３に示すＶｉａヘッダ削除後のメッセージ（ＳＩＰ−ＵＡ（Ｂ）１３が受信したＩＮＶＩＴＥリクエストメッセージ）の２行目と同じＶｉａヘッダが挿入されている。
【００３８】
ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００内のＶｉａヘッダ削除部２０３は、図１４に示す非圧縮メッセージ（２００ ＯＫ応答メッセージ）を入力するが、応答メッセージに対しては何も処理を行わず、そのまま圧縮器２０１に転送する。圧縮器２０１はＤＥＦＬＡＴＥ符号化方式による圧縮を行って、圧縮メッセージを伝送路３０２に出力する。ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００内の伸長器１０２は、伝送路３０２からこの圧縮メッセージを受信すると、ＤＥＦＬＡＴＥ符号化方式による伸長処理を行い、伸長したメッセージをＶｉａヘッダ挿入部１０５に出力する。Ｖｉａヘッダ挿入部１０５が入力するメッセージは、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００内の圧縮器２０１の入力が復元されるため、図１４に示す非圧縮メッセージ（２００ ＯＫ応答メッセージ）と同じになる。
【００３９】
Ｖｉａヘッダ挿入部１０５は、このメッセージ内のＶｉａヘッダにあるｂｒａｎｃｈパラメータ「ｚ９ｈＧ４ｂＫ７２１ｅ４．１」をキーとしてＶｉａヘッダ保持部１０４内を検索し、このキーに一致するＶｉａヘッダを取り出して４行目以降に挿入する。上述の通り、ＳＩＰサーバ（Ｂ）１２からＩＮＶＩＴＥリクエストが送信された際、このリクエストメッセージから削除したＶｉａヘッダをＶｉａヘッダ保持部１０４に保存する際のキーは「ｚ９ｈＧ４ｂＫ７２１ｅ４．１」である。従って、Ｖｉａヘッダ挿入部１０５は図１２に示した非圧縮メッセージ（ＳＩＰサーバ（Ｂ）１２が出力したＩＮＶＩＴＥリクエストメッセージ）の３行目から６行目と同じ文字列を取り出して挿入することとなり、全体のメッセージは図１５に示す通りとなる。このメッセージがＳＩＰサーバ（Ｂ）１２に出力される。これは、もしも図１２に示したＩＮＶＩＴＥリクエストメッセージが完全に復元されてＳＩＰ−ＵＡ（Ｂ）１３に到達した場合に、ＳＩＰ−ＵＡ（Ｂ）１３が出力する応答メッセージと等しい。ＳＩＰサーバ（Ｂ）１２の動作上、応答メッセージ中に含まれるＶｉａヘッダが、対応するリクエスト中に含まれるＶｉａヘッダと同じでないと問題が生じる。しかし、以上説明した通りＶｉａヘッダ挿入部１０５によって削除されたＶｉａヘッダが復元されるため、この問題が回避される。
【００４０】
Ｖｉａヘッダはリクエスト送信元のＳＩＰ−ＵＡ、及び、リクエストを転送した全てのＳＩＰサーバが自ＵＲＩを挿入するものである。図１０に示すネットワーク形態では、ＳＩＰ−ＵＡ（Ｂ）１３のメッセージ送受信はＳＩＰサーバ（Ｂ）１２のみと行う運用が想定されるが、図１０においてＳＩＰ−ＵＡ（Ａ）１１に相当するメッセージの送信元ＳＩＰ−ＵＡは、通常、呼毎に異なる。ＳＩＰ−ＵＡが異なるとメッセージの転送経路が変わるため、図１０においてＳＩＰサーバ（Ａ）１０に相当するＳＩＰサーバ（ＳＩＰサーバ（Ｂ）１２の前段に位置するＳＩＰサーバ）も呼毎に異なる場合がある。つまり、図１０においてＳＩＰサーバ（Ａ）１０に相当するＳＩＰサーバ（ＳＩＰサーバ（Ｂ）１２の前段に位置するＳＩＰサーバ）も呼毎に異なる場合を想定する必要がある。つまり、ＳＩＰサーバ（Ｂ）１２からＳＩＰ−ＵＡ（Ｂ）１３に送信されるリクエストメッセージについては、ＳＩＰサーバ（Ｂ）１２が挿入するＶｉａヘッダを除く他のＶｉａヘッダは呼の先頭では初めて出現する文字列となる。図１１に示した構成のシグナリング圧縮伸長装置によれば、この呼毎に異なるためにＤＥＦＬＡＴＥ符号化では圧縮困難なＶｉａヘッダ文字列を削除することが出来る。
【００４１】
このように、実施の形態４のシグナリング圧縮装置では、Ｖｉａヘッダ削除部１０３が、リクエストメッセージ内に複数のＶｉａヘッダが含まれる場合、最後に挿入されたＶｉａヘッダを除いて削除するので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮を可能とすることが出来る。また、リクエストに含まれるＶｉａヘッダの一部を削除したことによって、このリクエストに対する応答メッセージのＶｉａヘッダがＳＩＰ−ＵＡ（Ｂ）１３から出力されないこととなり、結果として応答メッセージのサイズを低減する効果もある。
尚、上述した例では、最後に挿入されたＶｉａヘッダを残して全てのＶｉａヘッダを削除したが、全てのＶｉａヘッダではなく、最後に挿入されたＶｉａヘッダ以外の任意のＶｉａヘッダを削除するだけでも効果は得られる。
【００４２】
また、図１１の圧縮器１０１，２０１と伸長器１０２，２０２を省略する構成としても良い。これらを省略するとＤＥＦＬＡＴＥ符号化方式によるメッセージ圧縮は行われないが、Ｖｉａヘッダを削除する分だけメッセージ量を低減することが出来る。
【００４３】
以上のように、実施の形態４のシグナリング圧縮装置によれば、シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内に複数のＶｉａヘッダが含まれる場合に一部のＶｉａヘッダを削除するＶｉａヘッダ削除部１０３を備えたので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮を可能とすることが出来る。
【００４４】
また、実施の形態４のシグナリング圧縮伸長装置によれば、シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内に複数のＶｉａヘッダが含まれる場合に一部のＶｉａヘッダを削除すると共に、削除したＶｉａヘッダをＶｉａヘッダ保持部１０４に保持させるＶｉａヘッダ削除部１０３と、リクエストメッセージに対応する応答メッセージに対して、Ｖｉａヘッダ保持部１０４に保持されているＶｉａヘッダを挿入するＶｉａヘッダ挿入部１０５を備えたので、Ｖｉａヘッダが削除されたメッセージに対してもＳＩＰプロトコルによって規定される書式に従った応答メッセージとして出力することができる。
【００４５】
実施の形態５．
図１１に示したＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００内のＶｉａヘッダ削除部２０３は、ＳＩＰ−ＵＡ（Ｂ）１３が出力するＳＩＰリクエストメッセージ内のＶｉａヘッダを削除する機能を持つ。そして、Ｖｉａヘッダの削除は、上で説明した通り、ＳＩＰのリクエストメッセージ内に複数のＶｉａヘッダが存在する場合に行われる。Ｖｉａヘッダは、リクエストメッセージを生成したＳＩＰ−ＵＡと、このメッセージを中継するＳＩＰサーバが１個ずつ挿入するものであるため、ＳＩＰ−ＵＡ（Ｂ）１３が出力するリクエストメッセージには、複数のＶｉａヘッダが含まれることはなく、常に１個である。よって、図１０に示したようなネットワーク形態では、Ｖｉａヘッダ削除部２０３が実際にＶｉａヘッダ削除動作をすることはなく、Ｖｉａヘッダ挿入部２０５もＶｉａヘッダ挿入を行うこともない。従って、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００内のＶｉａヘッダ削除部２０３、Ｖｉａヘッダ保持部２０４、Ｖｉａヘッダ挿入部２０５を省略しても良い。
【００４６】
このように、ＳＩＰサーバ（Ｂ）１２側とＳＩＰ−ＵＡ（Ｂ）１３側の構成が必ずしも同一である必要はなく、ネットワーク構成上、リクエストメッセージ中に複数のＶｉａヘッダが含まれるケースが存在しないことが予め分かっている場合には、Ｖｉａヘッダ削除部２０３、Ｖｉａヘッダ保持部２０４、Ｖｉａヘッダ挿入部２０５を省略することで、構成の簡略化を図ることが出来る。
【００４７】
実施の形態６．
図１６は、この発明の実施の形態６によるシグナリング圧縮伸長装置を示す構成図であり、先に示した図１０のＳＩＰサーバ（Ｂ）１２とＳＩＰ−ＵＡ（Ｂ）１３との間に挿入される場合の構成を示している。図において、ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ａは、ＳＩＰサーバ（Ｂ）１２から入力するＳＩＰメッセージの圧縮とＳＩＰサーバ（Ｂ）１２に出力するＳＩＰメッセージの伸長を行うもので、圧縮器１０１、伸長器１０２、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部１０６、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部１０７、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部１０８、Ｒｏｕｔｅヘッダ挿入部１０９を備えている。また、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ａは、ＳＩＰ−ＵＡ（Ｂ）１３から入力するＳＩＰメッセージの圧縮とＳＩＰ−ＵＡ（Ｂ）１３に出力するＳＩＰメッセージの伸長を行うもので、内部構成は、ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ａと同様である。即ち、圧縮器２０１、伸長器２０２、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部２０６、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部２０７、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部２０８、Ｒｏｕｔｅヘッダ挿入部２０９を備えている。尚、圧縮器１０１，２０１及び伸長器１０２，２０２は、それぞれ図１１における圧縮器１０１及び伸長器１０２と同様であるため、ここでの説明は省略する。
【００４８】
また、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部１０６，２０６は、ＳＩＰメッセージ内のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを削除する。Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部１０７，２０７は、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部１０６，２０６によって削除されたＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを保持しておくものである。また、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部１０８，２０８は、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部１０６，２０６によってＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが削除されたリクエストメッセージに対する応答メッセージに対して、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部１０７，２０７で保持していたＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを挿入する。Ｒｏｕｔｅヘッダ挿入部１０９，２０９は、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダが削除されたリクエストと同じ呼のリクエストメッセージに対して、削除されたＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを基にＲｏｕｔｅヘッダを生成して挿入する。
【００４９】
以下、図１０に示すように、呼接続のための最初のメッセージであるＩＮＶＩＴＥリクエストメッセージがＳＩＰ−ＵＡ（Ａ）１１からＳＩＰ−ＵＡ（Ｂ）１３に送信され、このリクエストに対応した２００  ＯＫ応答メッセージがＳＩＰ−ＵＡ（Ｂ）１３からＳＩＰ−ＵＡ（Ａ）１１に送信される場合のＳＩＰメッセージ圧縮・伸長動作について、先に示した図１２と図１７〜図２１を用いて説明する。図１２はＳＩＰサーバ（Ｂ）１２が出力する非圧縮メッセージ（ＩＮＶＩＴＥリクエストメッセージ）である。ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ａ内のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部１０６は図１２に示すメッセージを入力すると、このメッセージ中の８行目から９行目にあるＲｅｃｏｒ−Ｒｏｕｔｅヘッダを削除して図１７に示すメッセージを圧縮器１０１に出力する。またＲｅｃｏｒ−Ｒｏｕｔｅヘッダ削除部１０６は、削除したＲｅｃｏｒ−Ｒｏｕｔｅヘッダを、このメッセージ内の最も上の行にあるＶｉａヘッダのｂｒａｎｃｈパラメータ「ｚ９ｈＧ４ｂＫ７２１ｅ４．１」と、このメッセージ内のＣａｌｌ−ＩＤヘッダ文字列「３８４８２７６２９８２２０１８８５１１＠ｈｉｊｋｌｍｎ．ｅｘａｍｐｌｅ．ｃｏｍ」と共にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部１０７に保存する。このｂｒａｎｃｈパラメータとＣａｌｌ−ＩＤヘッダは、後に保存したＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを検索する際のキーに用いられる。圧縮器１０１はＤＥＦＬＡＴＥ符号化方式により図１７に示すメッセージを圧縮し、圧縮メッセージを伝送路３０１に出力する。
【００５０】
伝送路３０１から圧縮メッセージを受信したＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ａ内の伸長器２０２は、ＤＥＦＬＡＴＥ符号化方式による伸長処理を行う。その結果、図１７に示すＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除後のメッセージが復元され、これがＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部２０８に出力される。Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部２０８は、リクエストメッセージに対しては何も処理を行わない。従って、図１７に示すものと同じメッセージがそのままＲｏｕｔｅヘッダ挿入部２０９に出力される。Ｒｏｕｔｅヘッダ挿入部２０９は、リクエストメッセージを入力すると、そのメッセージ内のＣａｌｌ−ＩＤヘッダ文字列をキーとして、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部２０７内を検索し、過去に削除されたＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが見つかった場合には、このＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを基にＲｏｕｔｅヘッダを生成する。Ｃａｌｌ−ＩＤヘッダ文字列は呼を識別するために用いられるものであり、呼接続を開始するためにＩＮＶＩＴＥリクエストメッセージを生成する発信側ＳＩＰ−ＵＡが生成し、同一の呼におけるメッセージは同一のＣａｌｌ−ＩＤヘッダが付く。ここで、このＩＮＶＩＴＥリクエストメッセージは呼接続のためのメッセージであり、その呼で最初のメッセージとなるため、このメッセージ内のＣａｌｌ−ＩＤヘッダ文字列をキーにＲｅｏｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部２０７内を検索しても、このキーと一致するＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダは見つからない。従って、Ｒｏｕｔｅヘッダ挿入部２０９は、図１７に示すものと同じＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除後のメッセージをそのままＳＩＰ−ＵＡ（Ｂ）１３に出力する。
【００５１】
以上のように、ＳＩＰサーバ（Ｂ）１２から送信されたＩＮＶＩＴＥリクエスト内のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが削除された後、ＤＥＦＬＡＴＥ符号化による圧縮が行われるため、その分圧縮メッセージのサイズを小さくすることが出来る。しかし、このＩＮＶＩＴＥリクエストは削除されたＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが復元されないままＳＩＰ−ＵＡ（Ｂ）１３に転送されることとなる。ＳＩＰ−ＵＡにおいて、ＩＮＶＩＴＥリクエストに対する応答メッセージを送信する際には、そのＩＮＶＩＴＥリクエスト内のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダをそのまま応答メッセージにも挿入する必要がある。また、ＳＩＰ−ＵＡが新たにリクエストメッセージを送信する際、そのリクエストと同一の呼において過去に受信したＩＮＶＩＴＥリクエストにＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダがあった場合、このＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダの情報を用いて新たなメッセージに挿入するＲｏｕｔｅヘッダを生成する。つまり上記Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダの削除が行われる場合と行われない場合では、ＳＩＰ−ＵＡが出力する応答メッセージとリクエストメッセージが違うものになるが、図１６に示す構成のシグナリング圧縮方法ではこの問題を回避する手段を含んでいる。以下の説明では、その回避方法について示す。
【００５２】
ＳＩＰ−ＵＡ（Ｂ）１３が上記ＩＮＶＩＴＥリクエストを受信し、このリクエストを受け付けると２００  ＯＫ応答メッセージを返す。このＳＩＰ−ＵＡ（Ｂ）１３が出力する非圧縮メッセージ（２００  ＯＫ応答メッセージ）を図１８に示す。上述の通り、ＳＩＰの規定上、ＳＩＰ−ＵＡはＩＮＶＩＴＥリクエストに対する２００  ＯＫ応答メッセージを生成する際、元のリクエストに含まれるＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを保持しておき、同じヘッダを挿入する必要がある。しかし、ＳＩＰ−ＵＡ（Ｂ）１３が先に受信したＩＮＶＩＴＥリクエストは図１７に示すものであり、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダが存在しない。従って、図１８に示すメッセージにはＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが存在しない。
【００５３】
ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ａ内のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部２０６は、図１８に示す非圧縮メッセージを入力するが、このメッセージ中にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが含まれないため何も処理を行わず、そのまま圧縮器２０１に転送する。圧縮器２０１は、ＤＥＦＬＡＴＥ符号化方式による圧縮を行って、圧縮メッセージを伝送路３０２に出力する。ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ａ内の伸長器１０２は、伝送路３０２からこの圧縮メッセージ受信すると、ＤＥＦＬＡＴＥ符号化方式による伸長処理を行い、伸長したメッセージをＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部１０８に出力する。Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部１０８が入力するメッセージはＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ａ内の圧縮器２０１に対する入力メッセージが復元されるため、図１８に示す非圧縮メッセージとなる。Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部１０８は、このメッセージ内のＶｉａヘッダにあるｂｒａｎｃｈパラメータ「ｚ９ｈＧ４ｂＫ７２１ｅ４．１」をキーとしてＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部１０７内を検索し、このキーに一致するＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを取り出して入力メッセージ内に挿入する。
【００５４】
上述の通り、ＳＩＰサーバ（Ｂ）１２からＩＮＶＩＴＥリクエストが送信された際、このリクエストメッセージから削除したＲｅｃｏｒｄ−ＲｏｕｔｅヘッダをＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部１０７に保存した際のキーは「ｚ９ｈＧ４ｂＫ７２１ｅ４．１」である。従って、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部１０８は、図１２に示した非圧縮メッセージのＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ（図１２の８行目から９行目）と同じ文字列を取り出して挿入することとなり、全体のメッセージは図１９に示す通りとなる。このメッセージがＳＩＰサーバ（Ｂ）１２に出力される。これは、もしも図１２に示した非圧縮メッセージが完全に復元されてＳＩＰ−ＵＡ（Ｂ）１３に到達した場合に、ＳＩＰ−ＵＡ（Ｂ）１３が出力する応答メッセージと等しい。上述の通り、ＩＮＶＩＴＥリクエストメッセージに対する２００  ＯＫ応答メッセージ中に含まれるＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダは、対応するＩＮＶＩＴＥリクエストメッセージ中のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダと同じでないと問題が生じる。しかし、以上説明した通りＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部１０８によってＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが復元されるため、この問題は回避される。
【００５５】
次に、ＳＩＰ−ＵＡ（Ｂ）１３が呼を切断するためにＢＹＥリクエストメッセージを送信する場合について説明する。このＢＹＥリクエストメッセージは図２０に示す通りである。ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ａ内のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部２０６は、図２０に示す非圧縮メッセージにＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが含まれないため処理を行わず、このまま圧縮器２０１に転送する。圧縮器２０１はＤＥＦＬＡＴＥ符号化方式により図２０に示す非圧縮メッセージを圧縮し、圧縮メッセージを伝送路３０２に出力する。伝送路３０２から圧縮メッセージを受信したＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ａ内の伸長器１０２は、ＤＥＦＬＡＴＥ符号化方式による伸長処理を行う。その結果、図２０に示す非圧縮メッセージが復元され、これがＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部１０８に出力される。Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部１０８は、ＩＮＶＩＴＥリクエストに対する２００  ＯＫ応答以外のメッセージに対しては処理を行わないため、入力したメッセージをそのままＲｏｕｔｅヘッダ挿入部１０９に転送する。従って、Ｒｏｕｔｅヘッダ挿入部１０９は、図２０に示す非圧縮メッセージを入力することになる。
【００５６】
Ｒｏｕｔｅヘッダ挿入部１０９は、入力したリクエストメッセージ内のＣａｌｌ−ＩＤヘッダ文字列、即ち「３８４８２７６２９８２２０１８８５１１＠ｈｉｊｋｌｍｎ．ｅｘａｍｐｌｅ．ｃｏｍ」をキーにＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部１０７内を検索してこのキーに一致するＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを取り出し、取り出したＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを基にＲｏｕｔｅヘッダを生成する。上述の通り、ＳＩＰサーバ（Ｂ）１２からＩＮＶＩＴＥリクエストが送信された際、このリクエストメッセージから削除したＲｅｃｏｒｄ−ＲｏｕｔｅヘッダをＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部１０７に保存した際のキーは「３８４８２７６２９８２２０１８８５１１＠ｈｉｊｋｌｍｎ．ｅｘａｍｐｌｅ．ｃｏｍ」である。従って、Ｒｏｕｔｅヘッダ挿入部１０９は、図１２に示した非圧縮メッセージのＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ（図１２の８行目から９行目）と同じ文字列を取り出すことになる。
【００５７】
取り出したＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダには、２個のＵＲＩ＜ｓｉｐ：ｓｓ２．ａｂｃｄｅｆｇ．ｅｘａｍｐｌｅ．ｃｏｍ；ｌｒ＞と＜ｓｉｐ：ｓｓ１．ｈｉｊｋｌｍｎ．ｅｘａｍｐｌｅ．ｃｏｍ；ｌｒ＞が挿入されているが、Ｒｏｕｔｅヘッダを生成する際にはこれらのＵＲＩを逆順に挿入する。従って、Ｒｏｕｔｅヘッダ挿入部１０９の出力は図２１に示す通りとなる。
ＳＩＰ−ＵＡ（Ｂ）１３から出力されるＢＹＥリクエストメッセージにはＲｏｕｔｅヘッダが含まれておらず、上述の通りこれがそのままＳＩＰサーバ（Ｂ）１２に転送されると問題となる。しかし、Ｒｏｕｔｅヘッダ挿入部１０９が代わってＲｏｕｔｅヘッダを生成するため、この問題は回避される。
【００５８】
Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダはリクエストを転送した全てのＳＩＰサーバが自ＵＲＩを挿入するものである。図１０に示すネットワーク形態では、ＳＩＰ−ＵＡ（Ｂ）１３のメッセージ送受信はＳＩＰサーバ（Ｂ）１２のみと行う運用が想定されるが、図１０においてＳＩＰ−ＵＡ（Ａ）１１に相当するメッセージの送信元又は送信先ＳＩＰ−ＵＡは呼毎に異なる。ＳＩＰ−ＵＡが異なるとメッセージの転送経路が変わるため、図１０においてＳＩＰサーバ（Ａ）１０に相当するＳＩＰサーバ（ＳＩＰサーバ（Ｂ）１２の前段に位置するＳＩＰサーバ）も呼毎に異なる場合が多い。つまり、ＳＩＰサーバ（Ｂ）１２からＳＩＰ−ＵＡ（Ｂ）１３に送信されるメッセージ内のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ文字列は、呼の先頭では初めて出現する文字列となる場合が多い。図１６に示した構成のシグナリング圧縮伸長装置によれば、この呼毎に異なるためにＤＥＦＬＡＴＥ符号化では圧縮困難なＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを削除することが出来る。
【００５９】
このように、実施の形態６のシグナリング圧縮伸長装置では、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部１０６がＩＮＶＩＴＥリクエストメッセージ内にあるＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを削除するので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮が可能なシグナリング圧縮方式を得ることが出来る。
【００６０】
また、ＩＮＶＩＴＥリクエストに含まれるＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを削除したことによって、このリクエストに対する２００  ＯＫ応答メッセージのＲｅｃｏｒｄ−ＲｏｕｔｅヘッダがＳＩＰ−ＵＡ（Ｂ）１３から出力されないこととなり、結果としてこの応答メッセージのサイズを低減する効果もある。
【００６１】
尚、図１６の圧縮器１０１，２０１と伸長器１０２，２０２を省略する構成としても良い。これらを省略するとＤＥＦＬＡＴＥ符号化方式によるメッセージ圧縮は行われないが、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダを削除する分だけメッセージ量を低減することが出来る。
【００６２】
以上説明したように、実施の形態６のシグナリング圧縮装置によれば、シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが含まれる場合にこれを削除するＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部１０６を備えたので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮を可能とすることが出来る。
【００６３】
また、実施の形態６のシグナリング圧縮伸長装置によれば、シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが含まれる場合にこれを削除すると共に、削除したＲｅｃｏｒｄ−ＲｏｕｔｅヘッダをＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部１０７に保持させるＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部１０６と、リクエストメッセージに対応する応答メッセージに対して、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部１０７に保持されているＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを挿入するＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部１０８と、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダが削除されたリクエストメッセージを受信した場合、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部１０７に保持されているＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを元にＲｏｕｔｅヘッダを生成し、リクエストメッセージに対して挿入するＲｏｕｔｅヘッダ挿入部１０９を備えたので、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダが削除されたメッセージに対してもＳＩＰプロトコルによって規定される書式に従った応答メッセージやリクエストメッセージとして出力することができる。
【００６４】
実施の形態７．
図１６に示したＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ａ内のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部２０６は、ＳＩＰ−ＵＡ（Ｂ）１３が出力するメッセージ内のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを削除する機能を持つ。しかし、Ｒｅｃｏｒｄ−ＲｏｕｔｅヘッダはＳＩＰサーバが転送するメッセージに挿入するヘッダであるため、ＳＩＰ−ＵＡ（Ｂ）１３が出力するＩＮＶＩＴＥリクエストメッセージには、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダが含まれることはない。よって、図１０に示したようなネットワーク形態では、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部２０６が実際にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除動作をすることはない。従って、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部２０７にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが保存されることもなく、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部２０８もＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入を行うことはない。更に、Ｒｏｕｔｅヘッダ挿入部２０９がＲｏｕｔｅヘッダ挿入を行うこともない。つまり、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ａ内のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部２０６、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部２０７、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部２０８及びＲｏｕｔｅヘッダ挿入部２０９を省略しても良い。
【００６５】
このように、ＳＩＰサーバ（Ｂ）１２側とＳＩＰ−ＵＡ（Ｂ）１３側の構成が必ずしも同一である必要はなく、ネットワーク構成上、メッセージ中にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが含まれるケースが存在しないことが予め分かっている場合には、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部２０６、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部２０７、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部２０８、及び、Ｒｏｕｔｅヘッダ挿入部１０９を省略することで、構成の簡略化を図ることが出来る。
【００６６】
実施の形態８．
図２２は、この発明の実施の形態８によるシグナリング圧縮伸長装置を示す構成図であり、先に示した図１０のＳＩＰサーバ（Ｂ）１２とＳＩＰ−ＵＡ（Ｂ）１３との間に挿入される場合の構成を示している。図において、ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ｂは、ＳＩＰサーバ（Ｂ）１２から入力するＳＩＰメッセージの圧縮とＳＩＰサーバ（Ｂ）１２に出力するＳＩＰメッセージの伸長を行うもので、圧縮器１０１、伸長器１０２、Ｃａｌｌ−ＩＤ短縮コード化部１１０、Ｃａｌｌ−ＩＤ短縮コード／文字列対応テーブル１１１、Ｃａｌｌ−ＩＤ文字列化部１１２を備えている。また、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｂは、ＳＩＰ−ＵＡ（Ｂ）１３から入力するＳＩＰメッセージの圧縮とＳＩＰ−ＵＡ（Ｂ）１３に出力するＳＩＰメッセージの伸長を行うもので、内部構成はＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ｂと同様である。即ち、圧縮器２０１、伸長器２０２、Ｃａｌｌ−ＩＤ短縮コード化部２１０、Ｃａｌｌ−ＩＤ短縮コード／文字列対応テーブル２１１、Ｃａｌｌ−ＩＤ文字列化部２１２を備えている。尚、圧縮器１０１，２０１及び伸長器１０２，２０２は、それぞれ図１１，１６における圧縮器１０１及び伸長器１０２と同様であるため、ここでの説明は省略する。
【００６７】
また、Ｃａｌｌ−ＩＤ短縮コード化部１１０，２１０は、入力したＳＩＰメッセージ中のＣａｌｌ−ＩＤヘッダ文字列を１文字のコードに短縮化すると共に、このＣａｌｌ−ＩＤヘッダ文字列が初めて出現した文字列であった場合はＣａｌｌ−ＩＤヘッダ文字列と短縮コードとの対応をＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル１１１，２１１に登録する。Ｃａｌｌ−ＩＤ文字列化部１１２は、Ｃａｌｌ−ＩＤ短縮コードを通常のＣａｌｌ−ＩＤヘッダ文字列に変換すると共に、このＣａｌｌ−ＩＤ短縮コードが初めて出現したコードであった場合はＣａｌｌ−ＩＤヘッダ文字列と短縮コードとの対応をＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル１１１，２１１に登録する。
【００６８】
以下、図１０に示すように、呼接続のための最初のメッセージであるＩＮＶＩＴＥリクエストメッセージがＳＩＰ−ＵＡ（Ａ）１１からＳＩＰ−ＵＡ（Ｂ）１３に送信され、このリクエストに対応した２００  ＯＫ応答メッセージがＳＩＰ−ＵＡ（Ｂ）１３からＳＩＰ−ＵＡ（Ａ）１１に送信される場合のＳＩＰメッセージ圧縮・伸長動作について、先に示した図１２と図２３〜図２７を用いて説明する。図１２はＳＩＰサーバ（Ｂ）１２が出力する非圧縮メッセージ（ＩＮＶＩＴＥリクエストメッセージ）である。
【００６９】
ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ｂ内のＣａｌｌ−ＩＤ短縮コード化部１１０は、図１２に示すメッセージを入力すると、このメッセージ中のＣａｌｌ−ＩＤヘッダ文字列「３８４８２７６２９８２２０１８８５１１＠ｈｉｊｋｌｍｎ．ｅｘａｍｐｌｅ．ｃｏｍ」が既にＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル１１１に登録されているかどうか検索する。このＩＮＶＩＴＥリクエストメッセージは呼接続のためのメッセージであり、Ｃａｌｌ−ＩＤヘッダ文字列はＳＩＰ−ＵＡ（Ａ）１１が新規に生成したものであるため、Ｃａｌｌ−ＩＤ短縮コード／文字列対応テーブル１１１には登録されていない。従って、Ｃａｌｌ−ＩＤ短縮コード化部１１０はこのＣａｌｌ−ＩＤヘッダ文字列「３８４８２７６２９８２２０１８８５１１＠ｈｉｊｋｌｍｎ．ｅｘａｍｐｌｅ．ｃｏｍ」に「０」という１文字を短縮コードとして割り当てることとし、図１２に示す非圧縮メッセージを図２３に示す通りに変換すると共に、このＣａｌｌ−ＩＤヘッダ文字列と短縮コードとの対応をＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル１１１に登録する。圧縮器１０１はＤＥＦＬＡＴＥ符号化方式により図２３に示すＣａｌｌ−ＩＤ短縮コード化後のメッセージを圧縮し、圧縮メッセージを伝送路３０１に出力する。
【００７０】
伝送路３０１から圧縮メッセージを受信したＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｂ内の伸長器２０２は、ＤＥＦＬＡＴＥ符号化方式による伸長処理を行う。その結果、図２３に示すＣａｌｌ−ＩＤ短縮コード化後のメッセージが復元され、これがＣａｌｌ−ＩＤ文字列化部２１２に出力される。Ｃａｌｌ−ＩＤ文字列化部２１２は、図２３に示すＣａｌｌ−ＩＤ短縮コード化後のメッセージを入力すると、Ｃａｌｌ−ＩＤヘッダの短縮コード「０」がＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル２１１に登録されているかどうか検索する。上述の通り、このＩＮＶＩＴＥリクエストメッセージは呼接続のためのメッセージであり、Ｃａｌｌ−ＩＤヘッダは新規生成されたものであるため、この短縮コード「０」はＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル２１１には登録されていない。従って、Ｃａｌｌ−ＩＤ文字列化部２１２はＣａｌｌ−ＩＤ短縮コード「０」に対応する文字列として「ｈｇｆｅｄｃｂａ」を生成し、図２３に示すＣａｌｌ−ＩＤ短縮コード化後のメッセージを図２４に示すメッセージに変換してＳＩＰ−ＵＡ（Ｂ）１３に出力すると共に、このＣａｌｌ−ＩＤヘッダ文字列と短縮コードとの対応をＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル２１１に登録する。
【００７１】
ＳＩＰ−ＵＡ（Ｂ）１３が図２４に示すＣａｌｌ−ＩＤ文字列化後のメッセージ（ＩＮＶＩＴＥリクエストメッセージ）を受信し、このリクエストを受け付けると２００  ＯＫ応答メッセージを返す。このＳＩＰ−ＵＡ（Ｂ）１３が出力する非圧縮メッセージ（２００  ＯＫ応答メッセージ）を図２５に示す。この２００  ＯＫ応答メッセージのＣａｌｌ−ＩＤヘッダ文字列は、ＳＩＰ−ＵＡ（Ｂ）１３が受信したＩＮＶＩＴＥリクエストメッセージ（図２４）中のＣａｌｌ−ＩＤ文字列である「ｈｇｆｅｄｃｂａ」と同じである。ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｂ内のＣａｌｌ−ＩＤ短縮コード化部２１０はこの非圧縮メッセージを入力すると、メッセージ中のＣａｌｌ−ＩＤヘッダ文字列「ｈｇｆｅｄｃｂａ」が既にＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル２１１に登録されているかどうか検索する。検索の結果、このＣａｌｌ−ＩＤヘッダ文字列「ｈｇｆｅｄｃｂａ」は登録されており、短縮コード「０」が割り当てられていることが分かる。そこで、Ｃａｌｌ−ＩＤ短縮コード化部２１０は、図２５に示す非圧縮メッセージのＣａｌｌ−ＩＤヘッダ文字列を変換して図２６に示すメッセージを圧縮器２０１に出力する。圧縮器２０１はＤＥＦＬＡＴＥ符号化方式による圧縮を行って、圧縮メッセージを伝送路３０２に出力する。
【００７２】
ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ｂ内の伸長器１０２は、伝送路３０２からこの圧縮メッセージ受信すると、ＤＥＦＬＡＴＥ符号化方式による伸長処理を行い、伸長したメッセージをＣａｌｌ−ＩＤ文字列化部１１２に出力する。Ｃａｌｌ−ＩＤ文字列化部１１２が入力するメッセージはＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｂ内の圧縮器２０１に対する入力メッセージが復元されるため、図２６に示したＣａｌｌ−ＩＤ短縮コード化後のメッセージと同じとなる。Ｃａｌｌ−ＩＤ文字列化部１１２は、このメッセージを入力すると、Ｃａｌｌ−ＩＤヘッダの短縮コード「０」がＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル１１１に登録されているかどうか検索する。検索の結果、この短縮コード「０」は登録されており、これに対応するＣａｌｌ−ＩＤヘッダ文字列が「３８４８２７６２９８２２０１８８５１１＠ｈｉｊｋｌｍｎ．ｅｘａｍｐｌｅ．ｃｏｍ」であることが分かる。そこで、Ｃａｌｌ−ＩＤ文字列化部１１２は、図２６に示すＣａｌｌ−ＩＤ短縮コード化後のメッセージのＣａｌｌ−ＩＤヘッダ短縮コードを変換し、図２７に示すメッセージをＳＩＰサーバ（Ｂ）１２に出力する。
【００７３】
このように、ＳＩＰサーバ（Ｂ）１２から出力されたメッセージ内のＣａｌｌ−ＩＤヘッダ文字列「３８４８２７６２９８２２０１８８５１１＠ｈｉｊｋｌｍｎ．ｅｘａｍｐｌｅ．ｃｏｍ」は、ＳＩＰ−ＵＡ（Ｂ）１３に到達すると「ｈｇｆｅｄｃｂａ」に変化し、同じ文字列は復元されない。しかし、Ｃａｌｌ−ＩＤヘッダは呼を識別するために用いられるものであるため、以降送受信される同一呼のメッセージに対して常に同じＣａｌｌ−ＩＤヘッダ文字列、つまりＳＩＰサーバ（Ｂ）１２側で「３８４８２７６２９８２２０１８８５１１＠ｈｉｊｋｌｍｎ．ｅｘａｍｐｌｅ．ｃｏｍ」が、ＳＩＰ−ＵＡ（Ｂ）１３側で「ｈｇｆｅｄｃｂａ」が用いられ、その対応関係が変わらないのであれば、ＳＩＰサーバ（Ｂ）１２側とＳＩＰ−ＵＡ（Ｂ）１３側で異なる文字列が用いられても不都合はない。
【００７４】
以上説明した通り、ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ｂ内のＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル１１１では、Ｃａｌｌ−ＩＤヘッダ文字列「３８４８２７６２９８２２０１８８５１１＠ｈｉｊｋｌｍｎ．ｅｘａｍｐｌｅ．ｃｏｍ」に対応する短縮コードとして「０」が、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｂ内のＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル２１１では、Ｃａｌｌ−ＩＤヘッダ文字列「ｈｇｆｅｄｃｂａ」に対応する短縮コードとして「０」が、それぞれ登録されている。従って、以降、送受信される同一呼のメッセージにおいて、ＳＩＰサーバ（Ｂ）１２側のＣａｌｌ−ＩＤヘッダ文字列とＳＩＰ−ＵＡ（Ｂ）１３側のＣａｌｌ−ＩＤヘッダ文字列の対応関係は変わらず、ＳＩＰサーバ（Ｂ）１２及びＳＩＰ−ＵＡ（Ｂ）１３の動作に不都合が生じることはない。
【００７５】
Ｃａｌｌ−ＩＤヘッダ文字列は呼毎に異なる文字列となる。即ち呼毎に初めて出現する文字列となる。実施の形態８のシグナリング圧縮装置では、Ｃａｌｌ−ＩＤヘッダ文字列を文字数の少ない短縮コードに変換するので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮が可能なシグナリング圧縮方式を得ることが出来る。
【００７６】
また、図２２の圧縮器１０１，２０１と伸長器１０２，２０２を省略する構成としても良い。これらを省略するとＤＥＦＬＡＴＥ符号化方式によるメッセージ圧縮は行われないが、Ｃａｌｌ−ＩＤヘッダ文字列を短縮コード化する分だけメッセージ量を低減することが出来る。
【００７７】
尚、上記実施の形態８では、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｂで、Ｃａｌｌ−ＩＤの短縮コードを文字列化してＳＩＰ−ＵＡ（Ｂ）１３に送出するようにしたが、短縮コードが文字列（テキストデータ）である場合は、短縮コードのままで送出するようにしてもよい。この場合、Ｃａｌｌ−ＩＤ短縮コード化部２１０は、特に何もしない。即ち、この構成では、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｂ側では更なるＳＩＰメッセージの伸長や圧縮は行わない。
【００７８】
以上説明したように、実施の形態８のシグナリング圧縮装置によれば、シグナリングプロトコルがＳＩＰである場合、Ｃａｌｌ−ＩＤヘッダの文字列を短縮コードに変換するＣａｌｌ−ＩＤ短縮コード化部１１０を備えたので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮を可能とすることが出来る。
【００７９】
また、実施の形態８のシグナリング圧縮伸長装置によれば、シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内のＣａｌｌ−ＩＤヘッダに短縮コードが含まれる場合、短縮コードをＣａｌｌ−ＩＤヘッダ文字列に変換すると共に、短縮コードとＣａｌｌ−ＩＤヘッダとの対応関係をＣａｌｌ−ＩＤ短縮コード／文字列対応テーブル２１１に保持させるＣａｌｌ−ＩＤ文字列化部２１２と、リクエストメッセージに対応する応答メッセージに対して、Ｃａｌｌ−ＩＤ短縮コード／文字列対応テーブル２１１を参照し、Ｃａｌｌ−ＩＤヘッダ文字列に対応した短縮コードに変換するＣａｌｌ−ＩＤ短縮コード化部２１０とを備えたので、短縮コードと文字列との相互変換を容易に行うことができると共に、ＳＩＰプロトコルによって規定される書式に従った非圧縮メッセージとして出力することができる。
【００８０】
実施の形態９．
上記実施の形態８では、Ｃａｌｌ−ＩＤヘッダの文字列を文字数の少ない短縮コードに変換したが、これは文字でなくても良く、例えば、特定ビット数のバイナリ数値であっても良い。尚、この構成では、Ｃａｌｌ−ＩＤ文字列化部２１２およびＣａｌｌ−ＩＤ短縮コード化部２１０における短縮コードから文字列への変換および文字列から短縮コードへの変換は必須である。
【００８１】
実施の形態１０．
ＳＩＰメッセージに含まれるＦｒｏｍヘッダのｔａｇパラメータは、Ｃａｌｌ−ＩＤと共に呼を識別するために用いられるものであり、呼接続を開始するためにＩＮＶＩＴＥリクエストメッセージを送信する発信側ＳＩＰ−ＵＡが生成する任意の文字列であり、以降送受信される同一呼のメッセージには同一のパラメータが付く。従って、ＦｒｏｍヘッダのｔａｇパラメータもＣａｌｌ−ＩＤと同様な方法で短縮コード化することが可能であり、このような例を実施の形態１０として説明する。
【００８２】
図２８は、この発明の実施の形態１０によるシグナリング圧縮伸長装置を示す構成図である。
図示の装置はＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ｃとＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｃを示している。ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ｃは、圧縮器１０１、伸長器１０２、Ｆｒｏｍｔａｇ短縮コード化部１１０ａ、Ｆｒｏｍｔａｇ短縮コード／文字列対応テーブル１１１ａ、Ｆｒｏｍｔａｇ文字列化部１１２ａを備えている。また、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｃは、圧縮器２０１、伸長器２０２、Ｆｒｏｍｔａｇ短縮コード化部２１０ａ、Ｆｒｏｍｔａｇ短縮コード／文字列対応テーブル２１１ａ、Ｆｒｏｍｔａｇ文字列化部２１２ａを備えている。ここで、Ｆｒｏｍｔａｇ短縮コード化部１１０ａ，２１０ａ、Ｆｒｏｍｔａｇ短縮コード／文字列対応テーブル１１１ａ，２１１ａ、Ｆｒｏｍｔａｇ文字列化部１１２ａ，２１２ａは、それぞれ処理の対象が実施の形態８におけるＣａｌｌ−ＩＤからＦｒｏｍヘッダのｔａｇパラメータに変わっただけで処理の内容は、実施の形態８におけるＣａｌｌ−ＩＤ短縮コード化部１１０，２１０、Ｃａｌｌ−ＩＤ短縮コード／文字列対応テーブル１１１，２１１、Ｃａｌｌ−ＩＤ文字列化部１１２，２１２と同様である。また、圧縮器１０１，２０１及び伸長器１０２，２０２は、それぞれ実施の形態４以降の圧縮器１０１及び伸長器１０２と同様である。
【００８３】
Ｆｒｏｍヘッダのｔａｇパラメータは呼毎に異なる文字列となるため、ＤＥＦＬＡＴＥ符号化のみでは圧縮困難であるが、本構成によればＦｒｏｍヘッダのｔａｇパラメータを短縮コード化することが出来る。各部の動作については、Ｃａｌｌ−ＩＤヘッダ文字列を短縮コード化する場合と同様であるため、ここでの説明は省略する。
また、実施の形態１０においても短縮コードが文字列である場合は、短縮コードのままで送出するようにしてもよいのは実施の形態８と同様である。
【００８４】
このように、実施の形態１０のシグナリング圧縮方法では、ＤＥＦＬＡＴＥ符号化では圧縮困難なＦｒｏｍヘッダのｔａｇパラメータを１文字の短縮コードに変換するので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮が可能なシグナリング圧縮方式を得ることが出来る。
【００８５】
また、図２８の圧縮器１０１，２０１と伸長器１０２，２０２を省略する構成としても良い。これらを省略するとＤＥＦＬＡＴＥ符号化方式によるメッセージ圧縮は行われないが、Ｆｒｏｍヘッダのｔａｇパラメータを短縮コード化する分だけメッセージ量を低減することが出来る。
【００８６】
以上説明したように、実施の形態１０のシグナリング圧縮装置によれば、シグナリングプロトコルがＳＩＰである場合、Ｆｒｏｍヘッダのｔａｇパラメータ文字列を短縮コードに変換するＦｒｏｍｔａｇ短縮コード化部１１０ａを備えたので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮を可能とすることが出来る。
【００８７】
また、実施の形態１０のシグナリング圧縮伸長装置によれば、シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内のＦｒｏｍヘッダのｔａｇパラメータに短縮コードが含まれる場合、短縮コードをｔａｇパラメータ文字列に変換すると共に、短縮コードと文字列との対応関係をＦｒｏｍｔａｇ短縮コード／文字列対応テーブル２１１ａに保持させるＦｒｏｍｔａｇ文字列化部２１２ａと、リクエストメッセージに対応する応答メッセージに対して、Ｆｒｏｍｔａｇ短縮コード／文字列対応テーブル２１１ａを参照し、Ｆｒｏｍヘッダのｔａｇパラメータ文字列に対応した短縮コードに変換するＦｒｏｍｔａｇ短縮コード化部２１０ａとを備えたので、短縮コードと文字列との相互変換を容易に行うことができると共に、ＳＩＰプロトコルによって規定される書式に従った非圧縮メッセージとして出力することができる。
【００８８】
実施の形態１１．
ＳＩＰメッセージに含まれるＴｏヘッダのｔａｇパラメータは、Ｆｒｏｍヘッダのｔａｇパラメータ及びＣａｌｌ−ＩＤと共に呼を識別するために用いられるものであり、呼接続を開始するためのＩＮＶＩＴＥリクエストメッセージを受信した着信側ＳＩＰ−ＵＡが生成し、以降送受信される同一呼のメッセージには同一のパラメータが付く。従って、ＴｏヘッダのｔａｇパラメータもＣａｌｌ−ＩＤと同様な方法で短縮コード化することが可能であり、このような例を実施の形態１１として次に説明する。
【００８９】
図２９は、この発明の実施の形態１１によるシグナリング圧縮伸長装置を示す構成図である。
図示の装置はＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ｄとＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｄを示している。ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ｄは、圧縮器１０１、伸長器１０２、Ｔｏｔａｇ短縮コード化部１１０ｂ、Ｔｏｔａｇ短縮コード／文字列対応テーブル１１１ｂ、Ｔｏｔａｇ文字列化部１１２ｂを備えている。また、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｄは、圧縮器２０１、伸長器２０２、Ｔｏｔａｇ短縮コード化部２１０ｂ、Ｔｏｔａｇ短縮コード／文字列対応テーブル２１１ｂ、Ｔｏｔａｇ文字列化部２１２ｂを備えている。ここで、Ｔｏｔａｇ短縮コード化部１１０ｂ，２１０ｂ、Ｔｏｔａｇ短縮コード／文字列対応テーブル１１１ｂ，２１１ｂ、Ｔｏｔａｇ文字列化部１１２ｂ，２１２ｂは、それぞれ処理の対象が実施の形態８におけるＣａｌｌ−ＩＤからＴｏヘッダのｔａｇパラメータに変わっただけで処理の内容は、実施の形態８におけるＣａｌｌ−ＩＤ短縮コード化部１１０，２１０、Ｃａｌｌ−ＩＤ短縮コード／文字列対応テーブル１１１，２１１、Ｃａｌｌ−ＩＤ文字列化部１１２，２１２と同様である。また、圧縮器１０１，２０１及び伸長器１０２，２０２は、それぞれ実施の形態４以降の圧縮器１０１及び伸長器１０２と同様である。
【００９０】
Ｔｏヘッダのｔａｇパラメータは呼毎に異なる文字列となるため、ＤＥＦＬＡＴＥ符号化のみでは圧縮困難であるが、本構成によればＴｏヘッダのｔａｇパラメータを短縮コード化することが出来る。各部の動作については、Ｃａｌｌ−ＩＤヘッダ文字列を短縮コード化する場合と同様である。
また、実施の形態１１においても短縮コードが文字列である場合は、短縮コードのままで送出するようにしてもよいのは実施の形態８と同様である。
【００９１】
このように、実施の形態１１のシグナリング圧縮装置では、ＤＥＦＬＡＴＥ符号化では圧縮困難なＴｏヘッダのｔａｇパラメータを１文字の短縮コードに変換するので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮が可能なシグナリング圧縮方式を得ることが出来る。
【００９２】
また、図２９の圧縮器１０１，２０１と伸長器１０２，２０２を省略する構成としても良い。これらを省略するとＤＥＦＬＡＴＥ符号化方式によるメッセージ圧縮は行われないが、Ｔｏヘッダのｔａｇパラメータを短縮コード化する分だけメッセージ量を低減することが出来る。
【００９３】
以上説明したように、実施の形態１１のシグナリング圧縮装置によれば、シグナリングプロトコルがＳＩＰである場合、Ｔｏヘッダのｔａｇパラメータ文字列を短縮コードに変換するＴｏｔａｇ短縮コード化部１１０ｂを備えたので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮を可能とすることが出来る。
【００９４】
また、実施の形態１１のシグナリング圧縮伸長装置によれば、シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内のＴｏヘッダのｔａｇパラメータに短縮コードが含まれる場合、短縮コードをＴｏヘッダのｔａｇパラメータ文字列に変換すると共に、短縮コードと文字列との対応関係をＴｏｔａｇ短縮コード／文字列対応テーブルに保持させるＴｏｔａｇ文字列化部と、リクエストメッセージに対応する応答メッセージに対して、Ｔｏｔａｇ短縮コード／文字列対応テーブルを参照し、Ｔｏヘッダのｔａｇパラメータ文字列に対応した短縮コードに変換するＴｏｔａｇ短縮コード化部とを備えたので、短縮コードと文字列との相互変換を容易に行うことができると共に、ＳＩＰプロトコルによって規定される書式に従った非圧縮メッセージとして出力することができる。
【００９５】
実施の形態１２．
ＳＩＰメッセージに含まれるＶｉａヘッダのｂｒａｎｃｈパラメータは、リクエストとその応答を識別するために用いられるものであり、リクエストを生成するＳＩＰ−ＵＡ及びリクエストを転送するＳＩＰサーバが生成する任意の文字列で、以降送受信される同一のリクエスト（再送リクエスト）及びそのリクエストに対する応答メッセージには同一のパラメータが付く。従って、このパラメータについても、Ｃａｌｌ−ＩＤヘッダ文字列と同様な方法で短縮コード化することが可能であり、このような例を実施の形態１２として次に説明する。
【００９６】
図３０は、この発明の実施の形態１２によるシグナリング圧縮伸長装置を示す構成図である。
図示の装置はＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ｅとＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｅを示している。ＳＩＰサーバ（Ｂ）側圧縮・伸長部１００ｅは、圧縮器１０１、伸長器１０２、ｂｒａｎｃｈ短縮コード化部１１０ｃ、ｂｒａｎｃｈ短縮コード／文字列対応テーブル１１１ｃ、ｂｒａｎｃｈ文字列化部１１２ｃを備えている。また、ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部２００ｅは、圧縮器２０１、伸長器２０２、ｂｒａｎｃｈ短縮コード化部２１０ｃ、ｂｒａｎｃｈ短縮コード／文字列対応テーブル２１１ｃ、ｂｒａｎｃｈ文字列化部２１２ｃを備えている。ここで、ｂｒａｎｃｈ短縮コード化部１１０ｃ，２１０ｃ、ｂｒａｎｃｈ短縮コード／文字列対応テーブル１１１ｃ，２１１ｃ、ｂｒａｎｃｈ文字列化部１１２ｃ，２１２ｃは、それぞれ処理の対象が実施の形態８におけるＣａｌｌ−ＩＤからＶｉａヘッダのｂｒａｎｃｈパラメータに変わっただけで処理の内容は、実施の形態８におけるＣａｌｌ−ＩＤ短縮コード化部１１０，２１０、Ｃａｌｌ−ＩＤ短縮コード／文字列対応テーブル１１１，２１１、Ｃａｌｌ−ＩＤ文字列化部１１２，２１２と同様である。また、圧縮器１０１，２０１及び伸長器１０２，２０２は、それぞれ実施の形態４以降の圧縮器１０１及び伸長器１０２と同様である。
【００９７】
Ｖｉａヘッダのｂｒａｎｃｈパラメータはリクエスト毎に異なる文字列となるため、ＤＥＦＬＡＴＥ符号化のみでは圧縮困難であるが、本構成によればＶｉａヘッダのｂｒａｎｃｈパラメータを短縮コード化することが出来る。各部の動作については、Ｃａｌｌ−ＩＤヘッダ文字列を短縮コード化する場合と同様である。
また、実施の形態１２においても短縮コードが文字列である場合は、短縮コードのままで送出するようにしてもよいのは実施の形態８と同様である。
【００９８】
このように、実施の形態１２のシグナリング圧縮装置では、ＤＥＦＬＡＴＥ符号化では圧縮困難なＶｉａヘッダのｂｒａｎｃｈパラメータを１文字の短縮コードに変換するので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮が可能なシグナリング圧縮方式を得ることが出来る。
【００９９】
また、図３０の圧縮器１０１，２０１と伸長器１０２，２０２を省略する構成としても良い。これらを省略するとＤＥＦＬＡＴＥ符号化方式によるメッセージ圧縮は行われないが、Ｖｉａヘッダのｂｒａｎｃｈパラメータを短縮コード化する分だけメッセージ量を低減することが出来る。
【０１００】
以上説明したように、実施の形態１２のシグナリング圧縮装置によれば、シグナリングプロトコルがＳＩＰである場合、Ｖｉａヘッダのｂｒａｎｃｈパラメータ文字列を短縮コードに変換するｂｒａｎｃｈ短縮コード化部１１０ｃを備えたので、初めて出現する文字列パターンを多く含むＳＩＰメッセージに対して効率の良い圧縮を可能とすることが出来る。
【０１０１】
また、実施の形態１２のシグナリング圧縮伸長装置によれば、シグナリングプロトコルがＳＩＰである場合、リクエストメッセージ内のＶｉａヘッダのｔａｇパラメータに短縮コードが含まれる場合、短縮コードをＶｉａヘッダのｂｒａｎｃｈパラメータ文字列に変換すると共に、短縮コードと文字列との対応関係をｂｒａｎｃｈ短縮コード／文字列対応テーブル２１１ｃに保持させるｂｒａｎｃｈ文字列化部２１２ｃと、リクエストメッセージに対応する応答メッセージに対して、ｂｒａｎｃｈ短縮コード／文字列対応テーブル２１１ｃを参照し、Ｖｉａヘッダのｂｒａｎｃｈパラメータ文字列に対応した短縮コードに変換するｂｒａｎｃｈ短縮コード化部２１０ｃとを備えたので、短縮コードと文字列との相互変換を容易に行うことができると共に、ＳＩＰプロトコルによって規定される書式に従った非圧縮メッセージとして出力することができる。
【符号の説明】
【０１０２】
１  固定／可変パターン分離部、２  圧縮器、３  伝送路、４  伸長器、５  固定／可変パターン結合部、６  ヘッダ順序並べ替え部、７  必須ヘッダ削除部、８  必須ヘッダ挿入部、１１  ＳＩＰ−ＵＡ（Ａ）、１２  ＳＩＰサーバ（Ｂ）、１３  ＳＩＰ−ＵＡ（Ｂ）、１００，１００ａ，１００ｂ，１００ｃ，１００ｄ、１００ｅ  ＳＩＰサーバ（Ｂ）側圧縮・伸長部、１０１，２０１  圧縮器、１０２，２０２  伸長器、１０３  Ｖｉａヘッダ削除部、１０４  Ｖｉａヘッダ保持部、１０５  Ｖｉａヘッダ挿入部、１０６  Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部、１０７  Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部、１０８  Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部、１０９  Ｒｏｕｔｅヘッダ挿入部、１１０  Ｃａｌｌ−ＩＤ短縮コード化部、１１０ａ  Ｆｒｏｍｔａｇ短縮コード化部、１１０ｂ  Ｔｏｔａｇ短縮コード化部、１１０ｃ  ｂｒａｎｃｈ短縮コード化部、１１１  Ｃａｌｌ−ＩＤ短縮コード／文字列対応テーブル、１１１ａ  Ｆｒｏｍｔａｇ短縮コード／文字列対応テーブル、１１１ｂ  Ｔｏｔａｇ短縮コード／文字列対応テーブル、１１１ｃ  ｂｒａｎｃｈ短縮コード／文字列対応テーブル、１１２  Ｃａｌｌ−ＩＤ文字列化部、１１２ａ  Ｆｒｏｍｔａｇ文字列化部、１１２ｂ  Ｔｏｔａｇ文字列化部、１１２ｃ  ｂｒａｎｃｈ文字列化部、２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅ  ＳＩＰ−ＵＡ（Ｂ）側圧縮・伸長部、２０３  Ｖｉａヘッダ削除部、２０４  Ｖｉａヘッダ保持部、２０５  Ｖｉａヘッダ挿入部、２０６  Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ削除部、２０７  Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ保持部、２０８  Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダ挿入部、２０９  Ｒｏｕｔｅヘッダ挿入部、２１０  Ｃａｌｌ−ＩＤ短縮コード化部、２１０ａ  Ｆｒｏｍｔａｇ短縮コード化部、２１０ｂ  Ｔｏｔａｇ短縮コード化部、２１０ｃ  ｂｒａｎｃｈ短縮コード化部、２１１  Ｃａｌｌ−ＩＤ短縮コード／文字列対応テーブル、２１１ａ  Ｆｒｏｍｔａｇ短縮コード／文字列対応テーブル、２１１ｂ  Ｔｏｔａｇ短縮コード／文字列対応テーブル、２１１ｃ  ｂｒａｎｃｈ短縮コード／文字列対応テーブル、２１２  Ｃａｌｌ−ＩＤ文字列化部、２１２ａ  Ｆｒｏｍｔａｇ文字列化部、２１２ｂ  Ｔｏｔａｇ文字列化部、２１２ｃ  ｂｒａｎｃｈ文字列化部、３０１，３０２  伝送路。
【図１】
2010258787.tif 000003
【図２】
2010258787.tif 000004
【図３】
2010258787.tif 000005
【図４】
2010258787.tif 000006
【図５】
2010258787.tif 000007
【図６】
2010258787.tif 000008
【図７】
2010258787.tif 000009
【図８】
2010258787.tif 000010
【図９】
2010258787.tif 000011
【図１０】
2010258787.tif 000012
【図１１】
2010258787.tif 000013
【図１２】
2010258787.tif 000014
【図１３】
2010258787.tif 000015
【図１４】
2010258787.tif 000016
【図１５】
2010258787.tif 000017
【図１６】
2010258787.tif 000018
【図１７】
2010258787.tif 000019
【図１８】
2010258787.tif 000020
【図１９】
2010258787.tif 000021
【図２０】
2010258787.tif 000022
【図２１】
2010258787.tif 000023
【図２２】
2010258787.tif 000024
【図２３】
2010258787.tif 000025
【図２４】
2010258787.tif 000026
【図２５】
2010258787.tif 000027
【図２６】
2010258787.tif 000028
【図２７】
2010258787.tif 000029
【図２８】
2010258787.tif 000030
【図２９】
2010258787.tif 000031
【図３０】
2010258787.tif 000032