(57)【要約】【課題】コーデックが変換された場合でもパケットの対応付けを可能にする。【解決手段】パケット転送網を接続するＲＴＰ変換装置１０であって、発呼側端末と着呼側端末からそれぞれＳＩＰメッセージを受信し、発呼側と着呼側の符号化方式を検出するＩＰヘッダ解析部１１と、発呼側ＲＴＰパケットのデータを着呼側の符号化方式に合わせて符号化する第１符号化部１２と、発呼側ＲＴＰパケットのデータのシーケンス番号と着呼側ＲＴＰパケットのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成する第１ＲＴＰ再生成部１３と、着呼側ＲＴＰパケットのデータを発呼側の符号化方式に合わせて符号化する第２符号化部１４と、着呼側ＲＴＰパケットのデータのシーケンス番号と発呼側ＲＴＰパケットのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成する第２ＲＴＰ再生成部１５とを備える。【選択図】図４
2019161342.tif 000002
【特許請求の範囲】
【請求項１】
パケット転送網を接続するＲＴＰ変換装置であって、
発呼側端末と着呼側端末からそれぞれＳＩＰメッセージを受信し、発呼側と着呼側の符号化方式を検出するＩＰヘッダ解析部と、
前記発呼側端末から受信する発呼側受信ＲＴＰのデータを着呼側の符号化方式に合わせて符号化する第１符号化部と、
発呼側受信ＲＴＰのデータのシーケンス番号と、前記着呼側端末に送信する着呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成する第１ＲＴＰ再生成部と、
前記着呼側端末から受信する着呼側受信ＲＴＰのデータを発呼側の符号化方式に合わせて符号化する第２符号化部と、
着呼側受信ＲＴＰのデータのシーケンス番号と、前記発呼側端末に送信する発呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成する第２ＲＴＰ再生成部と
を備えることを特徴とするＲＴＰ変換装置。
【請求項２】
前記第１ＲＴＰ再生成部と前記第２ＲＴＰ再生成部は、
前記対応付けたデータを、ＲＴＰパケットフォーマットが持つ拡張ヘッダに記述することを特徴とする請求項１に記載のＲＴＰ変換装置。
【請求項３】
ＲＴＰ変換装置が実行するＲＴＰ変換方法であって、
発呼側端末と着呼側端末からそれぞれＳＩＰメッセージを受信し、発呼側と着呼側の符号化方式を検出し、
前記発呼側端末から受信する発呼側受信ＲＴＰのデータを着呼側の符号化方式に合わせて符号化し、
発呼側受信ＲＴＰのデータのシーケンス番号と、前記着呼側端末に送信する着呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成し、
前記着呼側端末から受信する着呼側受信ＲＴＰのデータを発呼側の符号化方式に合わせて符号化し、
着呼側受信ＲＴＰのデータのシーケンス番号と、前記発呼側端末に送信する発呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成する
ことを特徴とするＲＴＰ変換方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＲＴＰ（Real-time Transport Protocol）を用いてデータを転送するパケット転送網を接続するＲＴＰ変換装置及びＲＴＰ変換方法に関する。
【背景技術】
【０００２】
パケット転送網を伝搬する信号の遅延は、発呼側のパケットと着呼側のパケットを正しい順番に並び替えて音声変換した2つの音声を評価することで測定する（非特許文献１）。
【０００３】
ＳＩＰ（Session Initiation Protocol）の場合、ＳＢＣ（Session Border Controller）によりＳＩＰメッセージが終端されて、発呼側及び着呼側でダイアログが変わっても、着番号等の情報から発呼側と着呼側のパケットの対応付けが可能である。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】［平成３０年２月２７日検索］、インターネット＜URL:http://www.ttc.or.jp/jp/document_list/pdf/j/STD/JJ-201.11v1.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、例えばＰＣＭＵからＡＭＲ（Adaptive Multi-Rate）に符号化方式（コーデック）が変換された場合は、パケット数も変化するので、発呼側と着呼側のパケットの対応付けが困難であり、遅延、及びパケット損失率などの解析が不可能になるという課題がある。
【０００６】
本発明は、この課題を鑑みてなされたものであり、コーデックが変換された場合でもパケットの対応付けを可能にするＲＴＰ変換装置及びＲＴＰ変換方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一態様に係るＲＴＰ変換装置は、パケット転送網を接続するＲＴＰ変換装置であって、発呼側端末と着呼側端末からそれぞれＳＩＰメッセージを受信し、発呼側と着呼側の符号化方式を検出するＩＰヘッダ解析部と、前記発呼側端末から受信する発呼側受信ＲＴＰのデータを着呼側の符号化方式に合わせて符号化する第１符号化部と、発呼側受信ＲＴＰのデータのシーケンス番号と、前記着呼側端末に送信する着呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成する第１ＲＴＰ再生成部と、前記着呼側端末から受信する着呼側受信ＲＴＰのデータを発呼側の符号化方式に合わせて符号化する第２符号化部と、着呼側受信ＲＴＰのデータのシーケンス番号と、前記発呼側端末に送信する発呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成する第２ＲＴＰ再生成部とを備えることを要旨とする。
【０００８】
また、本発明の一態様に係るＲＴＰ変換方法は、上記のＲＴＰ変換装置が実行するＲＴＰ変換方法であって、発呼側端末と着呼側端末からそれぞれＳＩＰメッセージを受信し、発呼側と着呼側の符号化方式を検出し、前記発呼側端末から受信する発呼側受信ＲＴＰのデータを着呼側の符号化方式に合わせて符号化し、発呼側受信ＲＴＰのデータのシーケンス番号と、前記着呼側端末に送信する着呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成し、前記着呼側端末から受信する着呼側受信ＲＴＰのデータを発呼側の符号化方式に合わせて符号化し、着呼側受信ＲＴＰのデータのシーケンス番号と、前記発呼側端末に送信する発呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成することを要旨とする。
【発明の効果】
【０００９】
本発明によれば、コーデックが変換された場合でもパケットの対応付けを可能にすることができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態に係るＲＴＰ変換装置を用いたＩＰ電話網の構成例を示すブロック図である。
【図２】図１に示すＩＰ電話網の動作シーケンスを示す図である。
【図３】ＳＩＰメッセージの具体例を示す図である。
【図４】図１に示すＲＴＰ変換装置の機能構成例を示すブロック図である。
【図５】図４に示す第１符号化部と第１ＲＴＰ再生成部の処理手順を示すフローチャートである。
【図６】発呼機側ＲＴＰパケット列と、図４に示す第１ＲＴＰ再生成部で再生成されたＲＴＰパケット列を模式的に示す図である。
【図７】着呼機側ＲＴＰパケット列と、図４に示す第２ＲＴＰ再生成部で再生成されたＲＴＰパケット列を模式的に示す図である。
【図８】ＲＴＰパケットのフォーマットを示す図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態について図面を用いて説明する。複数の図面中同一のものに
は同じ参照符号を付し、説明は繰り返さない。
【００１２】
（ＩＰ電話網）
図１は、本発明の実施形態に係るＲＴＰ変換蔵置を用いたＩＰ電話網の構成例を示すブロック図である。図１に示すＩＰ電話網１００は、ＶｏＩＰ（Voice over Internet Protocol）技術を利用した電話サービスを提供するネットワークである。ＩＰ電話網１００は、パス制御プロトコルとしてＳＩＰ（Session Initiation Protocol）を利用したネットワークであり、ネットワークに接続する端末間で疎通する主情報（データ）は、ＲＴＰ（Realtime Transfer Protocol）を用いて伝送される。
【００１３】
図１に示すＩＰ電話網１００は、発呼側端末１、パケット転送網２、ＲＴＰ変換装置１０、ＳＩＰサーバ３、ＳＩＰサーバ４、ＲＴＰ変換装置２０、パケット転送網５、及び着呼側端末６を備える。パケット転送網２は例えばＡ社、パケット転送網５は例えばＢ社といった様に通信事業者が異なる例を示す。
【００１４】
ＳＩＰサーバ３，４は、ＳＩＰを利用したＩＰ電話サービスの管理制御を行うサーバであり、パケット転送網２，５のそれぞれに設けられる。
【００１５】
ＲＴＰ変換装置１０，２０は、隣接するネットワーク間で主情報のＲＴＰパケットを疎通できるようにする装置である。ＲＴＰ変換装置１０，２０は、一般的にＳＢＣ（Session Border Controller）と称される。ＲＴＰ変換装置１０，２０は、参照番号を異にしているが同じものである。ＲＴＰ変換装置１０，２０は、それぞれ別々のＳＢＣと一体化して構成しても良いし、ＳＩＰサーバ３，４に含めても良い。
【００１６】
図２は、ＩＰ電話網１００の動作手順を模式的に示す動作シーケンス図である。図２では、作図の都合により2台のＳＩＰサーバをＳＩＰサーバ３，４と表記する。また、以降ではＳＩＰサーバ３と省略して説明する。
【００１７】
発呼側端末１と着呼側端末６のそれぞれの電話番号及びＩＰアドレスは、最初にそれぞれの受話器を取り上げたときにＳＩＰサーバ３に送信され、登録されている（REGISTER）。
【００１８】
発呼側端末１と着呼側端末６の間で通信を開始する場合、例えば発呼側端末１から着呼側端末６の電話番号をダイヤルする。この時、発呼側端末１からＲＴＰ変換装置１０を介してＳＩＰサーバ３に、ＳＩＰのINVITEメッセージが送信される（INVITE）。ＳＩＰサーバ３は、ＲＴＰ変換装置２０を介して着呼側端末６の電話番号に対応するＩＰアドレスにINVITEメッセージを転送する。ＲＴＰ変換装置１０と２０は、INVITEメッセージから発呼側端末１の端末情報を取得する（ステップＳ１）。
【００１９】
図３は、ＳＩＰのINVITEメッセージの具体例を示す。上から5行目の＠の後の数列は発呼側端末１の識別子である。6行目の＠の後の数列は着呼側端末６の識別子である。このようにINVITEメッセージに、端末情報が記載されている。
【００２０】
ＳＩＰサーバ３は、INVITEメッセージを着呼側端末６に転送している間、100Tryingの暫定応答をＲＴＰ変換装置１０を介して発呼側端末１に送信する（100Trying）。
【００２１】
着呼側端末６のＩＰアドレスにINVITEメッセージが転送されると、着呼側端末６は180Ringingの暫定応答を、ＳＩＰサーバ３へ返信する（180Ringing）。ＳＩＰサーバ３は、発呼側端末１に180Ringingを転送する。180Ringingを受信している間、発呼側端末１では呼出音が聞こえる。
【００２２】
着呼側端末６の受話器が上げられると、着呼側端末６は200OKの成功応答をＳＩＰサーバ３へ送信する。ＳＩＰサーバ３は受信した200OKを発呼側端末１へ転送する（200OK）。
【００２３】
発呼側端末１は、200OKを受信すると着呼側端末６のＩＰアドレスが分かるため、直接ACKメッセージを着呼側端末６へ送信する。ACKメッセージの送信は、発呼側端末１と着呼側端末６の間で回線が確立（セッション確立）されたことを意味し、以降は、発呼側端末１、ＲＴＰ変換装置１０、ＲＴＰ変換装置２０、及び着呼側端末６の間で、主情報である音声パケットがＲＴＰを用いて伝送される。回線が確立した後の動作の説明は後述する。なお、回線を切断する動作については一般的であり、その説明は省略する。
【００２４】
発呼側端末１の符号化方式が例えばＰＣＭＵ（G.711 μ-low）、着呼側端末６の符号化方式が例えばＡＭＲ（Adaptive Multi-Rate）と仮定した場合のコーデックの変換は、ＲＴＰ変換装置１０又はＲＴＰ変換装置２０のどちらかで行う。どちらで行うかは、通信事業社間の取り決めによる。ここでは、ＲＴＰ変換装置１０がコーデックの変換を行う例で説明する。
【００２５】
（ＲＴＰ変換装置）
図４は、ＲＴＰ変換装置１０の機能構成例を示すブロック図である。図３において、一般的な構成である例えば通信インターフェース部及び制御部等の表記は省略している。
【００２６】
図４に示すようにＲＴＰ変換装置１０は、ＩＰヘッダ解析部１１、第１符号化部１２、第１ＲＴＰ再生成部１３、第２符号化部１４、及び第２ＲＴＰ再生成部１５を備える。ＲＴＰ変換装置１０の各機能構成部は、例えば、ＲＯＭ、ＲＡＭ、ＣＰＵ等からなるコンピュータで実現される。各機能構成部をコンピュータによって実現する場合、各機能構成部が有すべき機能の処理内容はプログラムによって記述される。
【００２７】
ＩＰヘッダ解析部１１は、発呼側端末１と着呼側端末からそれぞれＳＩＰメッセージを受信し、発呼側と着呼側の符号化方式を検出する（図２：ステップＳ１，Ｓ２）。以降の説明は、発呼側の符号化方式をＰＣＭＵ、着呼側の符号化方式をＡＭＲの例で説明する。
【００２８】
第１符号化部１２は、発呼側端末１から受信する発呼側ＲＴＰのデータを着呼側の符号化方式に合わせて符号化する（ステップＳ３）。
【００２９】
第１ＲＴＰ再生成部１３は、発呼側ＲＴＰのデータのシーケンス番号と、着呼側端末６に送信する着呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成する（ステップＳ４）。
【００３０】
第２符号化部１４は、着呼側端末から受信する着呼側受信ＲＴＰのデータを発呼側の符号化方式に合わせて符号化する（ステップＳ５）。
【００３１】
第２ＲＴＰ再生成部１５は、着呼側ＲＴＰのデータのシーケンス番号と、発呼側端末１に送信する発呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成する（ステップＳ６）。
【００３２】
以上述べたように本実施形態に係るＲＴＰ変換装置１０によれば、コーデックが変換された場合でもＲＴＰパケットの対応付けが可能になる。
【００３３】
続いて第１符号化部１２と第１ＲＴＰ再生成部１３の動作を、図面を参照して更に詳しく説明する。図５は、第１符号化部１２と第１ＲＴＰ再生成部１３の処理手順を示すフローチャートである。
【００３４】
第１符号化部１２は、発呼側端末１と着呼側端末６の情報を取得すると動作を開始する（ステップＳ１０）。第１符号化部１２は、動作を開始すると先ず変数ｉとｊを初期化する（ステップＳ１１）。変数ｉは発呼側ＲＴＰのデータのシーケンス番号を表す。変数ｊは着呼側ＲＴＰのデータのシーケンス番号を表す。
【００３５】
次に第１符号化部１２は、変数ｉ＝１のシーケンス番号の発呼側ＲＴＰパケトのデータを読み込む（ステップＳ１２）。そして、読み込んだデータを着呼側の符号化方式であるＡＭＲで符号化する（ステップＳ１３）。
【００３６】
読み込んだデータを着呼側の符号化方式で符号化した後、着呼側の符号化方式で符号化した符号長が所定の符号長になるまで、変数ｉをインクリメント（ステップＳ１５）してステップＳ１２とＳ１３の処理を繰り返す（ステップＳ１４のＮＯのループ）。
【００３７】
この例では、ＰＣＭＵよりもＡＭＲのデータ圧縮率が高いので、複数のＰＣＭＵのＲＴＰパケットに対して1つのＡＭＲのＲＴＰパケットが対応する関係になる。
【００３８】
第１ＲＴＰ再生成部１３は、着呼側の符号化方式で符号化した符号長が所定の符号長になる（ステップＳ１４のＹＥＳ）と、変数ｉとｊを対応付けてＲＴＰパケットを再生成する。
【００３９】
図６は、発呼機側ＲＴＰパケット列と、第１ＲＴＰ再生成部１３で再生成されたＲＴＰパケット列の例を模式的に示す図である。図５の上から1列目は、発呼機側ＲＴＰパケット列を示す。2列目は、第１ＲＴＰ再生成部１３で再生成されたＲＴＰパケット列を示す。
【００４０】
図５に示すように、例えば、3つの発呼側ＲＴＰパケットＡＡ１〜ＡＡ３が、1つのＲＴＰパケットＡ１に変換されている。ＲＴＰパケットＡ１の頭に添付されている1-3は、この対応関係を示す情報である。変換処理は、データが終了するまで繰り返される（ステップＳ１８のＮＯ）。
【００４１】
以上述べたように第１符号化部１２と第１ＲＴＰ再生成部１３の作用によって、発呼側ＲＴＰのデータのシーケンス番号と着呼側端末６に送信する着呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成する。これにより、発呼側と着呼側でコーデックが異なる場合でもパケットの対応付けが可能になる。
【００４２】
逆方向の着呼側→発呼側の変換は、第２符号化部１４と第２ＲＴＰ再生成部１５で行う。図７は、着呼機側ＲＴＰパケット列と、第２ＲＴＰ再生成部１５で再生成されたＲＴＰパケット列の例を模式的に示す図である。図７の上から1列目は、着呼機側ＲＴＰパケット列を示す。2列目は、第２ＲＴＰ再生成部１５で再生成されたＲＴＰパケット列を示す。
【００４３】
図７に示すように、例えば、1つの着呼機側ＲＴＰパケットＢＢ１が、Ａ１、Ａ２、及びＡ３の3つのＲＴＰパケットに変換されている。Ａ１、Ａ２、及びＡ３の3つのＲＴＰパケットは、例えば着呼側ＲＴＰパケットのＢＢ１から変換されたことを示している。
【００４４】
このように着呼側→発呼側の変換も、発呼側→着呼側と同様に対応付けることができる。なお、着呼側→発呼側の変換については、発呼側→着呼側と同様に、容易に実現できるので、フローチャートを参照した説明は省略する。
【００４５】
再生成された発呼側受信ＲＴＰのデータのシーケンス番号と着呼側端末に送信する着呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットと、着呼側受信ＲＴＰのデータのシーケンス番号と、発呼側端末に送信する発呼側送信ＲＴＰのデータのシーケンス番号を対応付けたデータを含むＲＴＰパケット。つまり、対応付けられたデータを含むＲＴＰパケットは、ＲＴＰパケットフォーマットの拡張ヘッダを用いて送信する。
【００４６】
（ＲＴＰパケットフォーマット）
図８は、ＲＴＰパケットの一般的なフォーマットを示す図である。図８に示す上から1行目の数字0〜3はビット数の10の位を示す。2行目はビット数の1の位を示す。
【００４７】
3行目のV=2は、ＲＴＰのバージョンが２であることを示している。Pは、最後にパディングがある場合に示す領域である。Xは、拡張ヘッダ（header extension）を利用する場合に示す領域である。本実施形態では、拡張ヘッダに変換したＲＴＰパケットを書き込むので、ここに１（X=1）を設定する。X以降の領域の説明は省略する。
【００４８】
図８において、拡張ヘッダに「1-3:A1」のＲＴＰパケットが書かれている様子を模式的に示す。このように、1つのＲＴＰパケットが拡張ヘッダに記述されて送信される。
【００４９】
以上述べたように本実施形態のＲＴＰ変換装置１０とその変換方法によれば、ＲＴＰパケットの伝送途中において、符号化方式が変更された場合に、発呼側と着呼側のＲＴＰパケットの対応付けが可能である。よって、パケットロス、遅延等の解析を可能にすることができる。
【００５０】
なお、上記の実施形態では、ＳＩＰサーバ３，４と、ＲＴＰ変換装置１０，２０を別々に構成する例（図１）を示した。しかし、ＲＴＰ変換装置１０，２０は、ＳＩＰサーバ３，４のそれぞれと一体化させて構成しても良い。このように本発明は、上記の実施形態に限定されるものではなく、その要旨の範囲内で変形が可能である。
【符号の説明】
【００５１】
１：発呼側端末
２、５：パケット転送網
３、４：ＳＩＰサーバ
６：着呼側端末
１０、２０：ＲＴＰ変換装置
１１：ＩＰヘッダ解析部
１２：第１符号化部
１３：第１ＲＴＰ再生成部
１４：第２符号化部
１５：第２ＲＴＰ再生成部
【図１】
2019161342.tif 000003
【図２】
2019161342.tif 000004
【図３】
2019161342.tif 000005
【図４】
2019161342.tif 000006
【図５】
2019161342.tif 000007
【図６】
2019161342.tif 000008
【図７】
2019161342.tif 000009
【図８】
2019161342.tif 000010