proposal of a sip communication method using ntmobile...内容要旨....
TRANSCRIPT
平成25年度 修士論文
邦文題目
NTMobileにおけるSIP通信方式の提案
英文題目
Proposal of a SIP Communication Method
using NTMobile
情報工学専攻
(学籍番号: 123430041)
吉岡 正裕
提出日: 平成26年 1月 31日
名城大学大学院理工学研究科
内容要旨
近年頻繁に使用されるマルチメディア通信用プロトコルのSIP（Session Initiation Protocol）
がセッション制御技術として注目され始めている．SIPは IPペイロード部分に IPアドレス
が記載されているプロトコルであり，単なる NAT越え技術のみでは対応できない．これら
の課題を解決するため，NATに改造を加えることなくNAT越え問題の解決と移動透過性を
同時に実現する NTMobile（Network Traversal with Mobility）と呼ぶ技術を提案している．
NTMobileは，端末に対して仮想 IPアドレスを割り当て，実際の通信を実 IPアドレスによ
る UDPトンネルを用いることで実現する．しかし，NTMobileにおいても SIPのような IP
ペイロード部分に IPアドレスが含まれているアプリケーションに対しては工夫が必要であ
る．NTMobileをSIP通信で利用すると，SIPサーバが仮想 IPアドレスを認識できないため，
基本的なしくみの見直しが必要である．そこで本論文では，SIPサーバにもNTMobileを導
入することで，NTM端末として扱い仮想 IPアドレスを認識可能にする手法を提案する．ま
た，提案手法の実装を行い，動作検証および評価を行った．この結果，NTMobileを用いて
SIP通信を実現することが可能となった．さらに，既存の SIPアプリケーションをそのまま
流用できることを動作検証にて確認した．
i
目次
第 1章 はじめに 1
第 2章 既存技術とその課題 3
2.1 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 SIPにおけるアドレス不整合問題 . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 既存技術 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
第 3章 NTMobile 7
3.1 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 通信シーケンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
第 4章 提案方式 11
4.1 提案方式の方針 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3 提案方式の通信シーケンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
第 5章 動作検証 16
5.1 実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 動作確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
第 6章 評価 19
6.1 既存技術との比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2 処理時間の予測 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
第 7章 まとめ 21
謝辞 22
参考文献 23
研究業績 25
ii
第1章 はじめに
IPv4ネットワークでは IPアドレスの枯渇を回避するため，家庭内や企業のネットワーク
はプライベートアドレスで構築するのが一般的である．それらのネットワークとインター
ネットの間にはNAT（Network Address Translator）が導入されている．このような環境では
インターネット側からはNATしか見えなくなるため，NAT外側の端末から内側の端末へ通
信を開始することができないという制約がある．これは NAT越え問題と呼ばれている．こ
れまでのインターネットの利用形態はWWWの閲覧やメールの利用など，一般にグローバ
ルアドレス空間に設置されたサーバに対してプライベートアドレス空間に存在する端末側か
ら通信を開始していた．ファイアウォールでもこのような通信形態のみを許可するのが一般
的であったため，NAT の制約が表面化することはなかった．しかし，家庭にもネットワー
クが導入され始めており，外出先から家庭内の端末に自由にアクセスしたいというニーズが
増加していくものと考えられる．また，CGN（Career Grade NAT）[1, 2]のようにインター
ネットプロバイダ自身のネットワークをプライベートアドレスで実現するような状況も想定
される．このため IPv4ネットワークにおいて NAT越え問題を解決することは有益である．
NAT越え問題を解決する技術としては，現存するNATをそのまま使えることを目的とし
たアプリケーションレベル改造方式（UPnP [3]），既存のアプリケーションをそのまま使用
することを目的としたネットワークレイヤ改造方式（4+4 [4]，NAT-f [5]，MIPNAT [6]），端
末の改造を不要とすることを目的とした端末非依存方式（AVES [7]，NTSS [8]）がある．
一方，近年頻繁に使用されるマルチメディア通信用プロトコルの SIP（Session Initiation
Protocol）[9]がセッション制御技術として注目され始めている．SIPをNATが存在する環境
で使用する場合，以下の 2つの課題がある．1つは，通常のNAT越え問題に関わるもので，
NAT の外側から内側方向に向けてシグナリングを開始することができない問題がある．も
う 1つは，SIPの IPペイロード内に IPアドレス/ポート番号が埋め込まれるため，NATを通
過すると IPヘッダ内の IPアドレスとの間で IPアドレスの不整合が生じる問題である．本
論文では，この問題をアドレス不整合問題と呼ぶ．SIPは IPペイロード部分に IPアドレス
が記載されているプロトコルであり，単なる NAT 越え技術のみでは対応できない．SIPで
は，SIP URI（Uniform Resource Identifier）と呼ばれる識別子を持っており，メールアドレ
スのように用いて SIP通信を行っている．SIP URIだけでは IPアドレスがわからないため，
SIP端末の SIP URIと IPアドレスを対応付けて管理する SIPサーバがある．SIPサーバはグ
ローバルネットワークに設置しているため，登録する IPアドレスがプライベートアドレス
である場合，プライベートアドレスを認識できず通信を行うことができない．SIPがNATを
1
通過できる手段としては，NATにおいて SIPメッセージ中の IPアドレス/ポート番号を書き
換える SIP-ALG（Application Level Gateway）[10]が挙げられる．これにより、SIPが NAT
を通過することは可能であるが，NATに改造が必要であるため，端末が一般のNAT配下に
移動できないという課題がある．また，NAT を改造せずアプリケーションレベルで対応す
るSTUN [11]，TURN [12]も同様に利用されている．これらは，SIP通信を行う前にNATの
外側 IPアドレスもしくは中継サーバの IPアドレスを取得し，SIPメッセージに取得した IP
アドレスを記載する方法である．あらかじめ IPアドレスを取得することで，SIPパケットを
書き換えることなく通信を行うことができるが、SIPアプリケーションがこれらの技術を実
装する必要がある．
これらの課題を解決するため，NATに改造を加えることなくNAT越え問題の解決と移動
透過性を同時に実現する NTMobile（Network Traversal with Mobility）と呼ぶ技術を提案し
ている [13–16]．NTMobileは，端末に対して仮想 IPアドレスを割り当て，実際の通信を実
IPアドレスによる UDPトンネルを用いることで実現する．しかし，NTMobileにおいても
SIPのような IPペイロード部分に IPアドレスが含まれているアプリケーションに対しては
工夫が必要である．NTMobile上で動作するアプリケーションは，仮想 IPアドレスを自身の
IPアドレスとして認識する．そのため，IPペイロード部分に含まれる IPアドレスは仮想 IP
アドレスとなる．NTMobileを SIP通信で利用すると，SIPサーバが仮想 IPアドレスを認識
できないため，基本的なしくみの見直しが必要である．
そこで，本論文ではSIPサーバにもNTMobileを導入し，NTMobileの機能だけの拡張を行
うことにより，既存の SIPアプリケーションおよび既存の NATに一切の手を加えることな
く SIPプロトコルを使用することができる手法を提案する．この手法により，既存の SIPク
ライアントや SIPサーバのアプリケーションをそのまま流用することが可能になる．また，
NTMobileにより移動通信にも対応できるようになる．提案方式の実装を行い，既存の SIP
アプリケーションを用いて動作検証を行った．
以下，2章でSIPについて説明し，3章でNTMobileとNTMobileを用いた場合のSIP通信
の課題について述べる．4章で提案方式について説明し，5章で提案方式の動作検証を行い，
6章で評価，7章でまとめる．
2
第2章 既存技術とその課題
SIPの概要および NAT を跨る SIP通信時に発生するアドレス不整合問題と，それを解決
する既存技術について説明する．
2.1 SIP
SIPはセッション制御プロトコルとして開発されており，セッションの開始・変更・終了
のみを行う．主な用途として IP電話やインターネット上の web会議などの制御で使用され
ている．本章では，SIPのセッション確立方法と，SIPと NATの関係について述べる．
2.1.1 セッション確立
図 2.1にSIPの基本シーケンスを示す．UA（User Agent）1とUA2は，それぞれSIP Server
A と Bに対して，REGISTERにより自身の URI（Uniform Resource Identifier）と自身の IP
アドレスG1およびG2を登録しておく．
通信開始時，UA1は INVITEによりUA2とのセッションの確立を要求する．INVITEには，
UA1が使用する IPアドレス G1とポート番号 s1が記載されている．SIP Server Aは URI2
に対応する SIPサーバの名前解決を行い，SIP Server Bに転送する．SIP Server Bは，URI2
の名前解決を行い，INVITE をUA2へ転送する．INVITE を受信したUA2は，200 OKを返
答する．200 OKには，UA2が使用する IPアドレスG2とポート番号 d2が記載されており，
INVITE と同様の経路を通りUA1まで転送される．UA1はACKを返答した後，交換した IP
アドレスとポート番号を用いて，UA2と直接メディアセッションを確立する．以後の通信
は，RTP（Real-time Transport Protocol）などにより，UA1と UA2間で直接実行される．
2.2 SIPにおけるアドレス不整合問題
図 2.2にアドレス不整合問題の例を示す．図 2.2では，UA2がNAT配下にあり，プライ
ベートアドレスを持っている．プライベートネットワークにある UA2からグローバルネッ
トワークにある UA1に通信を開始したとする．SIPメッセージに基づき，UA1は受信した
INVITE に記載されている IPアドレスとポート番号に基づき，セッションを確立しようとす
る．しかし，記載されている IPアドレスがプライベート IPアドレスであるため，宛先不明
でパケットが UA2に届かず，セッションを確立することはできない．
3
UA1
SIP INVITE
UA2
SIP URI：URI1
IP:G1
SIP URI：URI2
IP:G2
SIP 200 OK
ACK ACK ACK
RTP
Dst（IP：G2，Port：20000）
RTP
SIP REGISTER
SIP 200 OK
REGISTER：URI2，G2
SIP 200 OK
Regis
tratio
nSessio
n C
onectio
n
URI1
SIP Server1 SIP Server2
G1 URI2 G2
SIP INVITE SIP INVITE
SIP 200 OK SIP 200 OK
URI2G1Port：10000
URI1 G2 Port：20000
Dst（IP：G1，Port：10000）
図 2.1 SIPのセッション確立
NAT
宛先不明RTP
UA1
SIP INVITE
UA2
SIP URI：URI1
IP:G1
SIP URI：URI2
IP:P2
SIP 200 OK
ACK ACK ACK
Dst（IP：P2，Port：20000）
RTP
SIP Server1 SIP Server2
SIP INVITE SIP INVITE
SIP 200 OK SIP 200 OK
URI2G1Port：10000
URI1 P2 Port：20000
Dst（IP：G1，Port：10000）
SIP INVITE
SIP 200 OK
ACK
IP:P1IP:G2
図 2.2 SIP通信で発生するアドレス不整合問題
4
2.3 既存技術
2.2項で示した課題を解決する技術として，アプリケーションレベルで対応する STUN
（Session Traversal Utilities for NAT）と TURN（Traversal Using Relays around NAT）を挙げ
る．ここでは，SIPクライアントを使用するエンド端末を UA（User Agent）と呼称する．
2.3.1 STUN
図 2.3に STUNの動作概要を示す．UAに機能の実装が必要であるとともに，第 3の端末
として STUNサーバが必要となる．
SIPメッセージの送信に先立ち，UAは SIPメッセージを送信する際に使用するのと同じ
ポート番号を使用し，STUNサーバに対してBinding Requestを送信する．これにより，NAT
上に NAT テーブルを生成する．STUNサーバは，STUNサーバ側から見た送信元の IPア
ドレスとポート番号を Binding Responseとして UA に返答する．そして，UA は，Binding
Responseに記載されている IPアドレスおよびポート番号を SIPメッセージに埋め込み送信
する．
STUNは，いくつかの制約がある．1つは，通信が UDPに限定されることである．もう
1つは，Symmetric NATには使用できないことである．Symmetric NATは通信相手毎にポー
ト番号が変わる．そのため，宛先が SIPサーバからUAに切り替わる際，NATでポート番号
の不一致が発生する．
UANAT
STUN Server SIP Server
Binding Request
Binding Response
SIP Message
SIP Message
IP：G1 Port：A1
IP：G2 Port：B2
IP：P1 IP：P2 IP：G1 IP：G2
図 2.3 STUNの動作概要
5
2.3.2 TURN
図 2.4に TURNの動作概要を示す．UAに機能の実装が必要でありかつ第 3の端末として
TURNサーバが必要になる．
UAは通信開始に先立ち，TURNサーバに対して Allocate Requestを行う．これに対して，
TURNサーバは，自身のポートを割り当て，Allocate ResponseによりUAに通知する．この
後，UAは TURNサーバとの間でセッションを維持し続ける．UAは，TURNサーバ上に割
り当てられた IPアドレスとポート番号を SIPメッセージに埋め込み，パケットをカプセル
化して TURNサーバに送信する．TURNサーバが受信した SIPメッセージについては，カ
プセル化を行い，UAまで転送する．
TURNはNATの種類に依存せず，アドレス不整合問題が解決可能である．しかし，TURN
サーバは全ての通信を中継するため，TURNサーバに対する負荷が大きいことと，セッショ
ンのスループットが低下するという課題がある．
UA NATTURN Server SIP Server
Allocate Request
Allocate Response
SIP Message
SIP Message
IP：G2 Port：A1
IP：P1 IP：P2 IP：G1 IP：G3IP：G2
[Dst：IP：G2，Port：A1]
Registration Infomation
UA：（IP：G2）
図 2.4 TURNの動作概要
6
第3章 NTMobile
3.1 概要
図 3.1に，本提案方式の基礎となる NTMobileの構成を示す．NTMobileの構成要素とし
て，NTMobileの機能を実装した端末（以下NTM端末）の他に，NTM端末のアドレス情報
を管理する DC（Direction Coordinator），エンドエンドの通信が行えない場合にパケットを
中継する RS（Relay Server）が存在する．DCは，NTM端末に仮想 IPアドレスを配布する
他，NTM端末に対してトンネル経路を指示する装置であり，NTM端末の情報をデータベー
スで管理している．NTM端末は，DCから端末を一意に識別できる仮想 IPアドレスを与え
られ，NTM端末同士の通信の識別に使用する．アプリケーションは，割り当てられた仮想
IPアドレスを自分のアドレスとして認識する．
実際の通信は，仮想 IPアドレスのパケットを実 IPアドレスによる UDPでカプセル化を
することにより実現する．DCはエンド端末が存在するネットワーク上の位置から適切な通
信経路を決定し，NTM端末にトンネル経路を指示する．NATが存在する場合は，NATの内
RS
NTM Node
RS
NTM Node
NAT Router NAT Router
Wi-Fi
General ServerDC Direction Coordinator
RS Relay Server
Private Network Private Network
General Communication
Encrypted Communication
through UDP Tunnel
NTM Node
NTM Node
DC
図 3.1 NTMobileの概要
7
側からトンネルを構築するように指示するため，NAT越え問題を回避することができる．両
エンド端末が異なるNAT配下に存在するなど，エンドエンド通信が行えない場合にはRSを
経由したトンネル経路を構築する．この手法によって，アプリケーションに対して，NATの
存在や移動に伴う実 IPアドレスの変化を隠蔽することができる．
DCどうし，DCと RS，DCと NTM 端末間には信頼関係があることを前提としており，
NTMobilieで使用される制御メッセージは，全て暗号化される．また，NTM端末間やNTM
端末とRSの間で行われるトンネル通信は，トンネル構築時にDCより配布される共通鍵と
NTM端末が一時的に構築する共通鍵を合成した鍵を用いて暗号化される．
3.2 通信シーケンス
以後の説明では，通信開始側の NTM端末をMN（Mobile Node），受信側の NTM端末を
CN（Correspondent Node）として説明する，また，端末Nの FQDNを FQDNN，Node IDを
NIDN，実 IPv4アドレスをRIP4N，仮想 IPv4アドレスをVIP4N，端末NがNAT配下に接続
している場合の NATの実 IPアドレスを RIPNATN とし，アドレス情報を管理している DCを
DCN，その実 IPv4アドレスを RIPDCN とする．N1と N2がトンネル通信時に用いる Path ID
を PIDN1−N2と表す．Path IDは NTM端末間の通信を一意に識別するための識別子である．
3.2.1 登録処理
図 3.2に登録処理シーケンスを示す．DCは NTM端末の情報をデーターベースで管理す
る．データベースには DCに登録を行っている NTM 端末の情報を記録し，NTMobileにお
ける経路判断およびトンネル構築に利用する．
NTM端末は通信接続性の確保のために，端末起動時にDCに対して実 IPアドレスなどの
端末情報を登録する．MNは，FQDNMN，NIDMN，RIPMNなどを記載したNTM Registration
RequestをDCMNに送信する．DCMNはNTM Registration Requestをによって受け取った端末
情報をデータベースに登録しておく．
3.2.2 名前解決処理
図 3.3に NTMobileの通信シーケンスを示す．MN は，アプリケーションからの DNS問
い合わせを検出すると，そのパケットから FQDNCNを抽出して独自のネゴシエーションを
開始する．トリガーとなった DNS問い合わせのパケットはそのまま DNSサーバに向けて
送出させ，その応答パケットは待避しておく．
MN は，NTM Direction Requestに FQDNMN と FQDNCNを記載して DCMNへ送り，名前
解決およびトンネル構築指示を依頼する．DCMNは NTM Direction Requestに記載している
FQDNMNでデータベースを検索することによりMNの端末情報を取得する．さらに．DCMN
8
MN DCMN
NTM Registration Request
DC DataBase
・FQDNMN
・NIDMN
・RIPMN
・VIPMN
・RIPNATMN
NTM Registration Response
MN Info
図 3.2 NTMobileの名前解決処理シーケンス
は FQDNCNのNSレコードをDNSクエリにより問い合わせる．DNSからのNSレコードの
応答にはDNSサーバの名前だけが含まれ，IPアドレスが含まれていない場合がある．その
場合には，DNSサーバの名前から DNSクエリにより再度 IPアドレスを問い合わせる．
特定した DNSサーバが DCであった場合，DCMNは NTM Infomation Request/Responseに
よりNTM端末情報の収集を行う．NTM Infomation Requestに FQDNCNを載せ，DCCNの端
末情報を要求する．DCCNは，FQDNCNが示す CNの端末情報をデータベースから検索し，
Node Infomation Responseに載せて DCMNへ送り返す．これにより DCMNは CNの端末情報
の取得を完了する．
3.2.3 トンネル構築処理
DCMNは，3.2.2によって得た両端末の情報から最適なトンネル経路を判断する．DCMNは，
経路判断を元にトンネル構築に必要な情報を載せたNTM Route DirectionをMNとCNに送
信する．NTM端末が NAT配下にいる場合，NTM Tunnel Requestを NAT配下の NTM端末
から送信することによってトンネル通信の経路を確保する．
アプリケーションは通信相手として仮想 IPアドレスを認識しているため，アプリケーショ
ンが生成したパケットは仮想 IPアドレスが記載される．これをカプセル化し，CNへ転送す
る．CNはカプセル化されたパケットをデカプセル化し，抽出したアプリケーションパケッ
トを上位アプリケーションへ渡す．
9
NTM Information Request
NTM Information Response
CN Info
MN infoCN info
NTM Tunnel Response
FQDNCN
FQDNCN
DNS
Name Resolution
DCMN DNS DCCN
NTM Route Direction
NATMN
NTM Direction Request
NTM Route Direction
NTM Tunnel Request
CN
DNS Request
DNS Response
図 3.3 NTMobileのトンネル構築シーケンス
10
第4章 提案方式
4.1 提案方式の方針
仮想 IPアドレスを使用するためには，SIPサーバが仮想 IPアドレスを認識できなければ
ならない．NTMobileで用いる仮想 IPアドレスは，NTMobileに関連する機器以外では認識
することができない．また，SIP通信ではグローバル上に存在する SIPサーバを必ず経由す
る必要があり，この課題を解決しなければならない．SIPサーバのアプリケーションに手を
加える手法も考えられるが，SIPアプリケーションが限定されるため望ましくない．次に，
仮想 IPアドレスを実 IPアドレスに変換し，SIPサーバに登録を行う手法も考えられるが，変
換を行う装置をグローバルネットワーク上に設置する必要があり，経路が冗長化する．そこ
で，SIPサーバのアプリケーションに手を加えず，NTMobileを SIPサーバに導入する方式
を採用する．この方法により，SIPサーバを NTM端末として扱うことができるため，仮想
IPアドレスの認識が可能になる．
NTM端末間にてメディアセッションの直接通信を行うためには，SIP通信中にトンネル構
築を行う必要がある．SIP通信前にトンネル構築を行う方法も考えられるが，通信相手が応
答しないという場合も考えられる．そのため，通信相手が応答したことが確定した後にトン
ネル構築を行うことが望ましい．SIP通信において，メディアセッションに応じることが確
認できるタイミングは，通信相手のSIP 200 OKの送信である．そこで，通信開始側のNTM
端末は，SIP 200 OKを受信をトリガとして，NTMobileネゴシエーションを開始し，NTM
端末間でトンネル構築を行う．トンネル構築が完了するまでは，SIP 200 OKをアプリケー
ションに返さず保持する．これにより，メディアセッションをトンネル経路にて直接通信す
ることができる．
4.2 構成
提案方式のネットワーク構成を図 4.1に示す．本提案のネットワーク構成として，DC
（DCMN，DCCN）とSIPサーバ（SIPMN，SIPMN）をグローバル上に設置する．NTM端末のMN
は NAT 配下に，CNはグローバル上に存在する．SIPサーバには，NTMobileを導入する．
SIPサーバのアプリケーションと SIPクライアント，NATには一切の変更を加えない．MN
と CNは，それぞれ SIPMNと SIPCNへユーザ認証が完了し，SIP URIと認証パスワードが発
行されているもとのする．MNと CNは互いの SIP URIを保持しているものとする．
11
MN
NAT
Private
Network
DCMNDCCN
SIPCNSIPMN
CN
図 4.1 提案方式のネットワーク構成
提案方式では，NTM 端末が異なる NAT 配下に存在したネットワーク構成においても，
NTMobileの仕組みによりRSを介してSIP通信は実現できるが，本論文では簡単のためMN
のみが NAT配下に存在するものとする．
4.3 提案方式の通信シーケンス
4.3.1 SIP登録処理
図 4.2に SIP登録処理シーケンスを示す．MNと SIPMNは DCMNへの NTMobileの登録処
理が完了しているものとする．SIPクライアントは，起動時にSIPサーバへ登録処理を行う．
MN は SIPサーバに自身の位置情報である VIPMN を登録するため，SIPURIMN の名前解決
を行う．名前解決により，NTMobileのネゴシエーションが開始される．今回は，NTMobile
が導入された SIPサーバが通信相手であるため，MN と SIPMN の間でトンネルが構築され
る．トンネル構築後，MN は SIPMN に SIP登録メッセージである SIP REGISTERを送信す
る．SIP REGISTERには IPアドレスが含まれており，今回はVIPMNとなる．SIPMNはMN
からの SIP REGISTERを受信後，認証を行うため SIP 401 UnauthorizedをMNに返す．MN
は，SIP REGISTERに認証パスワードのハッシュを付与し，再度 SIPMNに SIP REGISTERを
送信する．SIPMNは認証パスワードのハッシュを参照し，正しいものであればVIPMNを登録
する．正常に登録処理が完了すると，SIPMNはMNに SIP 200 OK返しリクエストが成功し
たことを通知する．SIPクライアントは起動中，SIPサーバに対して定期的にパケットを送
信し経路確保を行う．このため，SIPクライアントが起動している間はMNと SIPMNで構築
されたトンネルは維持される．
12
Application NTMobile
DNS Request
NTM Direction Request
NTM Route Direction NTM Route Direction
NTM Tunnel Request
FQDNSIPMN
FQDNSIPMN
NTM Tunnel Response
DNS Response
SIP REGISTER
SIP URIMN
SIP 401 Unauthorized
VIPMN
MN InfoSIPMN Info
SIP REGISTER
SIP URIMN VIPMN
SIP 200 OKHash
MNNAT
DCMNSIPMN
図 4.2 提案方式の SIP登録シーケンス
4.3.2 SIP通信処理
提案方式のSIP通信シーケンスを図 4.3に示す．MNがCNに対してSIP通信を開始する．
MNは，CNの SIP URIを用いて通信を始める．SIP URIは，SIPのみで使われる識別子であ
り，メールアドレスのように扱われる．MNは宛先の情報である SIPURICNと自身の仮想 IP
アドレスVIPMNを記載した SIP INVITEを，すでに生成済みのトンネルを介して SIPMNに送
信する．SIPMNと SIPCNは NTM 端末として動作しているため，両者の間にトンネルが構築
される．その後，SIP INVITEは SIPCNを経由し CNに送信される．SIP INVITEを受信した
CNは，SIP INVITEと同様の経路で自身の仮想 IPアドレスVIPCNと SIPURICNを SIP 200
OKに記載し，MNに送信する．ここまではトンネル通信であることを除き，通常の SIP通
信と同様である．
図中の Aから Dは提案方式固有の動作である．
A において，MN は SIP 200 OKを受信すると，NTMobileの機能によりパケットをフッ
クする．このパケットは，Dまでの間保持する．NTMobileは SIP 200 OKに含まれている
VIPCNを取得する．取得したVIPCNをNTM Direction Requestに記載し，DCMNに送信する．
13
NTM Direction Request
SIP INVITE
SIP 200 OK
VIPMN
Media session
Registration Infomation
MN：SIP URIMN、VIPMN
Registration Infomation
CN：SIP URICN、VIPCN
Application NTMobile ApplicationNTMobile
SIP INVITE
NTM Information Request
NTM Information Response
CN Info
MN info
NTM Route Direction
CN info
NTM Tunnel Request
NTM Tunnel Response
SIP 200 OK
SIP ACK
Tunnel
ConstructionSIP URICN
VIPCNSIP URIMN
VIPCN
VIPCN
DNS
Name Resolution
A
SIPMN SIPCNNATMNCN
DCMN DNS DCCN
NTM Route Direction
SIPMN SIPCN
Pro
posed m
eth
od p
art
B
C
D
図 4.3 提案方式の SIPシーケンス
NTMobileでは通常，通信相手の FQDNから端末を管理している DCの IPアドレスを取
得を行う．しかし，SIPメッセージには FQDNが含まれていないため，上記の処理を行うこ
とができない．本提案では，仮想 IPアドレスから DCの位置情報を取得するよう DCの拡
張を行う．図中 BにおいてDNS逆引きの仕組みを利用し，VIPCNからDCDCの FQDNを取
得する．続けて DNS正引きを行い，DCCNの IPアドレスを取得する．
NTM Infomation Requestを受信したDCCNは，Cにおいてメッセージに記載されている情
報をキーとしてデータベースを検索する．通常のNTMobileでは，FQDNをキーとしてデー
タベースの検索を行っている．本提案では，仮想 IPアドレスから端末情報を取得できるよう
14
DCの拡張を行う．VIPCNをキーとしてCNの端末情報を取得する．その後，NTM Infomation
Responseに取得した情報を記載し DCMNへ応答する．
CからDまでの間は通常のNTMobileの動作と同様である．トンネルに必要な情報を交換
し，トンネルを構築する．
Dにおいて，トンネル構築が正常に動作したかどうか確認を行う．構築できていたなら
ば，NTMobileで保持していた SIP 200 OKをアプリケーションに返す．
以降は SIP通信の処理に戻る．MN は SIP ACKを SIP INVITEと同様の経路で CNに送
信する．以後は，NTMobileのトンネルによりエンドエンドのメディアセッションが可能に
なる．
15
第5章 動作検証
5.1 実装
提案方式を Linuxに実装を行った．ディストリビュージョンはUbuntu10.04，カーネルバー
ジョン 2.6.32-24-genericを使用した．実装は NTM端末と DCについて行った．
図 5.1に NTM端末のモジュール構成を示す．提案方式を実現するため，NTMobile独自
のデーモンに SIP通信のみで使用するモジュールの追加を行った．SIP通信は UDP上で動
作し，デフォルトポートは 5060番となっている．そこで，カーネルモジュールに受信した
パケットの UDPポートが 5060番の時にフックする処理を追加した．カーネルモジュール
でフックした SIPパケットを新規に作成した SIP通信専用のモジュールに渡す．ここで，解
析を行いパケットが SIP 200 OKかつメディアセッションの情報が含まれていた場合，メッ
セージに含まれている仮想 IPアドレスを抽出する．抽出した通信相手の仮想 IPアドレス
をNTM Direction Requestの拡張ヘッダに記載する．NTM Direction Requestには通信開始側
と受信側の FQDNが記載されているが，これに仮想 IPアドレスの情報を付加できるように
NTMobile独自のヘッダに追加した．
図 5.2に DCのモジュール構成を示す．これまでの DCでは，NTM Direction Requestに
含まれている通信相手の FQDNから，トンネルに必要な情報の取得に使用していた．提案
方式では，FQDNを取り扱わないため，DCの NTMobileデーモンに SIP通信のみで使用す
るモジュールを新規に作成し追加した．NTM Direction Requestに SIP専用のフラグを立て
ることで処理を分岐し，仮想 IPアドレスを FQDNの代わりに用いることでトンネル構築に
必要な情報を取得する．また，NTM Infomation Requestの宛て先を見つけるため，仮想 IP
アドレスをDNS逆引きおよび正引きする処理を追加した．これにより，仮想 IPアドレスを
管理している DCの IPアドレスを取得できる．
16
Real I/FReal I/F
Tunnel
Establishment
User Space
Kernel Space
DNS
NTM Query
DNS
Resolver
Netfilter
Real I/F
Packet
Manipulation
Netfilter
Tunnel Table
Application
Virtual I/F
NTM deamon
（ⅵ）TCP/UDP Packet
(Src/Dst = RIP)
(ⅴ)
（ⅳ）
TCP/UDP Packet
（Src/Dst = VIP）
Netlink Socket
（ⅱ）DNS NTM
Query Msg
Received
DNS Query
Response
Peer’s VIP
Modified
DNS A Query
Response
SIP
Module
Received
SIP
Packet
Responder VIP
(ⅰ) (ⅲ)
Direction Request
Route Direction
Tunnel Request
Tunnel Response
Operation Flow
Packet Flow
Added or modified module
for proposal method
図 5.1 NTM端末のモジュール構成
Real I/FReal I/FReal I/F
User Space
Kernel Space
DNSSIP
ModuleNegotiation
ManagementDatabase
NTM deamonNode Infomation
SIP flag
NTM Negotiation
Message
DNS MessageOperation Flow
Packet Flow
Added or modified module
for proposal method
Responder VIP
図 5.2 DCのモジュール構成
5.2 動作確認
提案方式がアドレス不整合問題を解決できていることを確認するため，既存の SIPアプ
リケーションを用いて NATを含めたネットワークを構築し動作検証を行った．図 5.3に試
験ネットワークの構成を示す．1台の実機 PC上にインストールした VMware6.0を利用し
て，NTM端末 3台およびDC2台，NATを仮想マシンとして構築した．NTM端末 1台にSIP
サーバアプリケーションをインストールし，SIPサーバとして扱う．NTM端末 1台と DC2
台，SIPサーバとNATを同一ネットワークに接続し，NTM端末 1台をNAT配下へ接続した．
MNと CNは同じ SIPサーバを使用する．NTM端末のMNから NAT配下に存在する NTM
17
SIP Server DCMN DCCN
MN
NAT
CN
1000BASE-TVirtual Machines
図 5.3 試験ネットワークの構成
端末 CNへ通信を開始する．
SIPクライアントは Linuxで動作するフリーソフト Jitsi [21]を使用した．SIPサーバアプ
リケーションには一般に使用されているフリーソフトのAsterisk [22]を選択した．上記の環
境にて，SIPで開始する IP電話を実行した．Wireshark [20]を用いてパケットをキャプチャ
し，IP電話がNATを越えて通信できたことを確認した．また，マイクおよびヘッドホンを
用いて正常に音声通話が開始できることを確認した．
18
第6章 評価
6.1 既存技術との比較
STUNと TURNを既存技術の代表としてとりあげ，提案方式との比較を行った結果を表
6.1に示す．
• アドレス不整合問題の解決STUNは，NATがSymmetric NATの場合は使用することができない．TURNは中継装
置を用い，提案方式は仮想 IPアドレスを使用することで，それぞれ NATの種類に依
存せず通信を行うことができる．
• SIPアプリケーションの改造
STUNおよび TURNは，SIPクライアントを改造する必要がある．また，ユーザは使
用するSTUNや TURNのサーバを各々設定する必要があり，ユーザがこれらの技術を
意識しなければならない．提案方式では，SIPクライアントは NTMobileを意識する
必要がなく，既存のものをそのまま流用することができる．
• 移動通信への対応STUNおよび TURNは，端末の移動を想定していないため，端末の IPアドレスが変
化すると再度 IPアドレスを取得しなければならず，メディアセッションを継続するこ
とができない．提案方式では，NTMobileの移動透過性をそのまま活かすことができ，
端末の IPアドレスが変化した場合は再度トンネル構築処理を行い，通信を継続させる
ことができる．
• SIPサーバの改造
STUNおよび TURNは，既存の SIPサーバをそのまま使用できる．提案方式では，
NTMobileを導入する必要がある．しかし，SIPサーバのアプリケーションは手を加え
る必要がないため，NTMobileの導入のみで実現できる．
19
表 6.1 既存技術と提案方式の比較STUN TURN 提案方式
アドレス不整合問題の解決 △ 〇 ○
SIPアプリケーションの改造 × × ○
移動通信への対応 × × ○
SIPサーバの改造 ○ ○ △
6.2 処理時間の予測
提案方式では，通常の SIP通信の合間をぬってNTMobileのネゴシエーションを NTM端
末間と SIPサーバ間で 2回行う．NTMobileのネゴシエーション時間合計は文献 [18]と [19]
より，3GとWi-Fiネットワーク間において約 650msと推測されている．しかし，SIPサー
バは有線によりグローバルネットワーク上に設置することを想定しているため，SIPサーバ
間のNTMobileのネゴシエーションは上記の値よ大幅に短いことが推測される．以上のこと
から，提案方式によるオーバヘッドは実用上問題ないと言える．
20
第7章 まとめ
本論文では，NAT に改造を加えることなく通信接続性と移動透過性を同時に実現する
NTMobileにおいて，NTMobileで拡張を行うことにより，既存のSIPアプリケーションやNAT
に一切の手を加えずにSIP通信を行う方式について提案を行った．提案方式では，NTMobile
で SIP通信を行う際に起きる課題を NTMobileの拡張により解決を行った．SIPサーバに
NTMobileを導入し，仮想 IPアドレスを識別可能とした．加えて，メディアセッションを
NTM端末間で行うためにSIPパケットをフックする処理をNTMobileに追加を行い，SIP通
信中にNTMobileのネゴシエーションを行うよう拡張した．また，提案方式を実装し，現在
使われている SIPアプリケーションを用いて動作確認を行った．
今後は，実ネットワーク上環境において実装したシステムの詳細な性能評価を行う．NTM
端末が異なる NAT 配下に存在する場合および，ハンドオーバ時の動作検証も進めていく．
また，NTMobile非対応端末との SIP通信について検討を進めていく予定である．
21
謝辞
本研究に関して，研究の方向や進め方など終始御熱心な御指導とご教示を賜りました，名
城大学大学院理工学研究科情報工学専攻 渡邊晃教授に心より厚く御礼申し上げます．
本論文を作成するにあたり，快く査読を引き受けてくださり，熱心にご指導を頂きました，
名城大学大学院理工学研究科情報工学専攻 柳田康幸教授に心より厚く御礼申し上げます．
本論文を作成するにあたり，快く査読を引き受けてくださり，熱心にご指導を頂きまし
た，名城大学大学院理工学研究科情報工学専攻 宇佐見庄五准教授に心より厚く御礼申し上
げます．
本論文を作成するにあたり，快く査読を引き受けてくださり，熱心にご指導を頂きました，
名城大学大学院理工学研究科情報工学専攻 鈴木秀和助教に心より厚く御礼申し上げます．
また，本研究を進めるにあたり，常日頃から御意見ならびに御助言を受け賜りました，三
重大学大学院工学研究科 内藤克浩助教に深謝いたします．
最後に，本研究を行うにあたり，適切な御意見および御助言を頂いた，名城大学名城大学
大学院理工学研究科情報工学専攻渡邊研究室並びに鈴木研究室の皆様に心より感謝いたし
ます．
22
参考文献
[1] J.Livingood：Considerations for Transitioning Content to IPv6，RFC6589，IETF（2012）．
[2] I.Yamagata，S.Miyakawa，A.Nakagawa，H.Ashida：Common Requirements for Carrier-
Grade NATs（CGNs），RFC6888，IETF（2013）．
[3] Forum，U.：Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0
（2001）.
[4] Turanyi，Z.，Valko，A. and Campbell，A.：4+4：An Architecture for Evolving the Internet
Address Space Back Toward Transparency，ACM SIGCOMM Computer Communication
Review，Vol.33，No.5，pp.43-54（2003）.
[5] 鈴木秀和，宇佐見庄五，渡邊 晃：外部動的マッピングによりNAT越え通信を実現す
るNAT-f の提案と実装，情報処理学会論文誌，Vol.48，No.12，pp.3949-3961（2007）.
[6] Levkowetz，H.，and Vaarala，S.：Mobile IP Traversal of Network Address Translation（NAT）
Devices，RFC 3519，IETF（2003）.
[7] Ng，T.，Stoica，I.，and Zhang，H.：A Waypoint Service Approach to Connect Heterogeneous
Internet Address Spaces，Proc. USENIX Annual Technical Conference，pp.319-332（2001）.
[8] 宮崎 悠，鈴木秀和，渡邊 晃：端末の改造が不要なNAT越え通信システムNTSSの
提案と評価，情報処理学会論文誌，Vol.51，pp.1234-1241（2010）.
[9] Rosenberg，J.，Schulzrinne，G.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，
R.，Handley，M. and Schooler，E.：SIP：Session Initiation Protocol，RFC 3261，IETF
（2002）．
[10] Johnston，A.，Donovan，S.，Sparks，R.，Cunninghan，C.，and Summers，K.：Session
Initiation Protocol（SIP） Basic Call Flow Examples，RFC 3665，IETF（2003）．
[11] Rosenberg，J.，Mahy，R.，Matthews，P.，and Wing，D.：Session Traversal Utilities for
NAT（STUN），RFC 5389，IETF（2008）．
[12] Mahy，R.，Matthewes，P.，and Rosenberg，J.：Traversal Using Relays around NAT（TURN），
RFC 5766，IETF (2010)．
[13] 鈴木秀和，水谷智大，西尾拓也，内藤克浩，渡辺 晃：NTMobileにおける相互接続性
の確立手法と実装，情報処理学会論文誌，Vol.54，No.1，pp.367-379（2013）．
[14] 内藤克浩，西尾拓也，水谷智大，鈴木秀和，渡辺 晃，森香津夫，小林英雄：NTMobileに
おける移動透過性の実現と実装，情報処理学会論文誌，Vol.54，No.1，pp.380-393（2013）．
23
[15] 西尾拓也，内藤克浩，水谷智大，鈴木秀和，渡辺 晃，森香津夫，小林英雄：NTMobile
における端末アドレスの移動管理と実装，マルチメディア，分散，協調とモバイル
（DICOMO2011）シンポジウム論文集，Vol.2011，No.1，pp.1139-1145（2011）．
[16] 上醉尾一真，鈴木秀和，内藤克浩，渡辺 晃：IPv4/IPv6混在環境で移動透過性を実現す
るNTMobileの実装と評価，マルチメディア，分散，協調とモバイル（DICOMO2012）
シンポジウム論文，Vol.2012，No.1，pp.1169-1179，Jul.2012．
[17] 納堂博史，鈴木秀和，内藤克浩，渡辺 晃：NTMobileの経路最適化の検討，情報処理
学会研究報告，Vol.2011-MBL-61，No.33，pp1-8（2011）.
[18] 上醉尾一真，鈴木秀和，内藤克浩，渡辺 晃：IPv4/IPv6混在環境における NTMobile
の検討，情報処理学会第 74回全国大会論文集，pp.3-221-3-222（2011）．
[19] 細尾幸宏，鈴木秀和，内藤克浩，旭 健作，渡邊 晃：NTMobileにおけるDNS実装
の変更が不要なデータベース型端末情報管理手法の検討，Vol.2012-MBL-64（2012）.
[20] Wireshark. http://www.wireshark.org.
[21] http://www.jitsi.org
[22] Asterisk IP PBX,VOIP Gateway,IVR & Open Source Communications．http://www.asterisk.org
24
研究業績
学術論文
なし
研究会・大会等
1. 吉岡正裕,鈴木秀和，内藤克浩，渡邊晃, “NTMobileにおける SIP通信の実現手法”,
平成 24年度電気関係学会東海支部連合大会論文集，Sep.2011．
2. 吉岡正裕,鈴木秀和，内藤克浩，渡邊晃, “NTMobileにおける SIP通信の実現手法”,
情報処理学会第 74回全国大会講演論文集，Mar.2012．
3. 吉岡正裕，鈴木秀和，内藤克浩，旭健作，渡邊晃，”NTMobileにおける一般SIP端末
との通信確立手法”，情報処理学会MBL 第 64回，Nov.2012．
4. 吉岡正裕，鈴木秀和，内藤克浩，渡邊晃，”NTMobileにおけるSIP通信方式の提案と
実装”，情報処理学会MBL 第 70回，Mar.2014.
25