🌐 STUN と Cisco CUBE における「stun usage ice lite」設定の解説
NAT/ファイアウォール環境での VoIP（SIP）通信を可能にするための STUN プロトコル と、Cisco CUBE での ICE Lite（Interactive Connectivity Establishment - Lite） の設定・概念を、実装者向けに解説します。
STUN = グローバルIP/ポート検出 ICE Lite = 簡易版ICE（呼出側で複雑性を負担）
Cisco CUBE = NAT越え時に必須
1) STUN（Session Traversal Utilities for NAT）とは
概要
STUN は、NAT/ファイアウォール配下の端末が、グローバルネットワークから見えるIP/ポート番号を自動的に検出するためのプロトコル（RFC 3489 → RFC 5389 で標準化）です。
用途: VoIP（SIP）、ビデオ会議、P2P通信など、直接通信が必要なリアルタイムアプリケーションで使用されます。
STUN の動作フロー
┌────────────────────────────────────────┐
│ NAT内部の端末 │
│ (LAN IP: 192.168.1.100:5060) │
└──────────┬─────────────────────────────┘
│ STUN Request
│ (STUNサーバーへ)
↓
STUNサーバー (例: stun.l.google.com)
│ STUN Response
│ 返答内容:
│ - グローバルIP: 203.0.113.50
│ - グローバルポート: 54321
↓
┌────────────────────────────────────────┐
│ NAT内部の端末（学習後） │
│ 自分は グローバルから見ると: │
│ 203.0.113.50:54321 として見える │
└────────────────────────────────────────┘
STUN が解決する問題
- NAT越えの不可視性: NAT内部からは、ルーターがどんなアドレス/ポートにマッピングしたかが見えない
- シグナリング側への通知: 相手方（SIP プロキシ/CUBE等）に「私はこのグローバルIP/ポートで受信できます」と伝える必要がある
- メディアパス確立: 双方が相手の本当のグローバルアドレスを知ることで、RTP ストリーム（音声/動画）が到達可能になる
2) ICE（Interactive Connectivity Establishment）と ICE Lite
ICE の目的
ICE（RFC 5245）は、NAT経由で2つのピア間の最適な通信経路を自動判定するメカニズムです。
複数の候補ルート（直接接続、STUN経由、TURN経由など）を試し、実際に通信できるものを選択します。
フル ICE vs ICE Lite の比較
| 項目 | フル ICE | ICE Lite |
|---|---|---|
| 候補収集 | ホスト、STUN、TURN 候補を全て集める | ホスト候補のみ（STUN/TURN は使わない） |
| 接続性チェック | 複数候補を N×M でテスト（複雑） | 受動的 - 相手からの接続要求に応答するのみ |
| 計算負荷 | 高い（ピアが協力して最適路を探索） | 低い（呼出側で複雑性を担当） |
| 用途 | WebRTC、P2P通信、外部ネットワーク間通信 | エンタープライズ VoIP（Cisco CUBE等） |
| NAT 対応 | 複数 NAT でも対応可能 | 相手が NAT 側に居る場合、相手は STUN に対応が前提 |
3) Cisco CUBE での「stun usage ice lite」設定
設定の意味
Cisco CUBE で stun usage ice lite を有効化すると、以下が実行されます：
- ICE Lite モードの使用: CUBE は受動的構成で、呼出側から的確な候補が送られてくることを前提に応答
- SDP への記載: CUBE が SIP メッセージに含まれる SDP（Session Description Protocol）で、自身の候補アドレスを明示
- STUN クライアント機能（オプション）:
stun serverコマンドで STUN サーバーが指定された場合のみ、CUBE が STUN サーバーに問い合わせてグローバル IP/ポートを検出
stun server の設定はオプションです。STUN サーバーが指定されなくても、stun usage ice lite は機能し、ホスト候補（LAN IP）のみを SDP に記載します。
最小限の設定（STUN サーバーなし）
voice service voip stun stun usage ice lite !
この設定だけでも ICE Lite は機能します。CUBE は自身のホスト候補（LAN IP）を SDP に記載し、呼出側が接続性チェックを実施します。
STUN サーバーを指定した場合
voice service voip stun stun usage ice lite stun server stun.l.google.com stun server stun.stunprotocol.org !
STUN サーバーを指定すると、グローバル IP/ポート候補も SDP に追加され、相手方が複数の接続可能性を試すことができます。
各コマンドの説明
| コマンド | 説明 | 必須? |
|---|---|---|
voice service voip |
VoIP サービスの設定コンテキストに入る（SIP レベルの各種設定） | ✓ 必須 |
stun |
STUN サブコンテキストに入る | ✓ 必須 |
stun usage ice lite |
ICE Lite を有効化（Key 設定） | ✓ 必須 |
stun server [IP|FQDN] |
利用する STUN サーバーの指定（複数指定可） | ○ オプション |
推奨される STUN サーバー
| STUN サーバー | 特徴 |
|---|---|
stun.l.google.com:19302 |
Google 提供（信頼性高、広く使用） |
stun1.l.google.com:19302 |
Google の冗長構成 |
stun.stunprotocol.org:3478 |
オープンコミュニティ提供 |
numb.viagenie.ca:3478 |
xiph.org/Freeswitch 関連 |
4) CUBE での実装シナリオ
シナリオ 1: オンプレミス CUBE ↔ クラウド（SIP トランク）
状況: オンプレミスの Cisco CUBE がファイアウォール/NAT 配下にあり、クラウド上の SIP プロバイダーと通信する場合
【オンプレミス】 【インターネット】 【クラウド】
CUBE (192.168.1.x) ←NAT/FW→ STUNサーバー SIP Provider
↓
STUN Request
↓
グローバルIP検出
↓
SDP に候補情報を含める
↓
────────────────────────────────────────────→ SIP INVITE + SDP
↓
ICE チェック実施
RTPパス確立
設定例:
voice service voip stun stun usage ice lite stun server 61.193.45.211 stun server 202.156.78.100 ! sip-ua credentials username user_cube password MySecurePass realm example.com registrar ipv4:sip.provider.com:5060 expires 3600 !
シナリオ 2: 複数拠点間の CUBE ↔ CUBE 通信（VPN な環境）
状況: 本社と支社は VPN で接続されており、両拠点の CUBE が ICE Lite を有効化する場合
設定（両拠点共通）:
voice service voip stun stun usage ice lite !
注: VPN だけで ICE Lite + ホスト候補でも十分です。STUN サーバーが外部にある場合、VPN の遅延やプロバイダー制限を避けるため、STUN サーバーは不要な場合が多いです。
5) 動作確認・トラブルシューティング
CUBE で STUN 動作確認
cube# show stun server STUN Server: 61.193.45.211 UDP PORT: 3478 Default: No cube# show voice stun STUN Status: UP cube# debug stun STUN client initiated STUN request to server 61.193.45.211
よくある問題と対処
原因: ファイアウォールルール、DNS 解決不可
対処:
ping、telnet [STUN-IP] 3478 で確認、UDP 通信許可確認
原因: stun usage ice lite が OFF、または STUN サーバー返答なし
対処: 設定確認、デバッグログ确认、STUN サーバー変更を試す
原因: NAT の内側/外側のアドレスが SDP で異なる、相手が候補を認識していない
対処:
show voice voip connection で RTP 送受信統計確認、SDP 確認（debug ccsip all）
デバッグコマンド
! STUN デバッグ debug stun ! SIP シグナリングとSDP確認 debug ccsip all ! VoIP 接続状態確認 show voice voip connection show voice voip connection detailed ! STUN サーバー接続状態 show stun server
6) ICE Lite 採用時の設計検討項目
メリット
- シンプルな運用: CUBE 側は受動的で、追加の接続性チェック処理がない
- CPU/メモリ効率: 複数の ICE チェック候補をテストしないため負荷が低い
- 設定が簡潔: STUN+ICE Lite の 1 行設定で実現
デメリット・制限
- 呼出側の能力が前提: 呼出側が ICE Full または十分なサーバー・エンタープライズゲートウェイであることが前提
- 複数 NAT 環境で限定: CUBE が二重 NAT の場合、相手が複数候補をテストする必要が増加
- TURN 未対応: ICE Lite では TURN（リレーサーバー）を使用しないため、NAT がコーン型でない場合はメディア疎通不可の場合がある
設計ガイドライン - STUN サーバー設定の必要性
| 環境 | 推奨構成 | STUN サーバー設定 | 理由 |
|---|---|---|---|
| 社内 VPN（複数拠点） | ICE Lite のみ | 不要 | VPN で直接接続可能、ホスト候補で十分 |
| エンタープライズ SIP Trunk | ICE Lite + STUN | 推奨 | プロバイダーが Full ICE 対応、グローバル候補で信頼性向上 |
| インターネット経由の SIP 通信 | ICE Lite + STUN | 推奨 | 最適な接続経路を確保 |
| End User Device → CUBE | ICE Lite + STUN + TURN | 推奨（さらに TURN も） | 多様な NAT 環境対応、コーン型 NAT 限定できない場合は TURN 必須 |
7) 詳細設定例
例: フル Cisco CUBE 設定（SIP Trunk + STUN ICE Lite）
voice service voip allow-connections sip to sip stun stun usage ice lite stun server 61.193.45.211 port 3478 stun server 202.156.78.100 port 3478 voice-class codec 1 codec preference 1 g729 codec preference 2 g711alaw codec preference 3 g711ulaw ! voice class h323 1 call-info-url https://example.com/call-info ! sip-ua credentials username user_cube_trunk password C0pl3xP@ss1 realm trunk.provider.com registrar ipv4:sip-trunk.provider.com:5060 expires 3600 options-ping proxy ipv4:sip-trunk.provider.com:5060 ! voice class sip-options-keepalive 1 sip-options max-freq 600 ! dial-peer voice 100 voip description SIP-TRUNK to Cloud Provider destination-pattern ........ session transport udp codec g729 dtmf-relay sip-kpml voice-class sip options-keepalive 1 session server ipv4:sip-trunk.provider.com:5060 media address 0.0.0.0 ! dial-peer voice 1 pots description To-Local-PBX destination-pattern 9T port 0/1/0:15 codec g711ulaw !
8) よくある質問（FAQ）
Q1: ICE Lite を使わず、STUN だけではダメ？
A: STUN だけだと「自分のグローバルIP/ポートを知る」だけしかできません。ICE Lite（や ICE）は、実際に相手とのメディアパスが確立できるかをチェック・確認します。多くの場合 STUN 情報があれば通信成功しますが、複数 NAT や特殊なファイアウォール下では ICE による接続性チェックが有効です。
Q2: ICE Lite では TURN は使えない？
A: ICE Lite の定義上、TURN 候補は収集しません。TURN（中継サーバー）が必要な環境では、フル ICE または TURN を別途設定する必要があります。ただしエンタープライズ SIP では、相手方がコーン型 NAT で対応するため、通常は必要ありません。
Q3: 複数の STUN サーバーを設定した場合の動作は？
A: CUBE は複数 STUN サーバーを冗長構成として試します。最初のサーバーがタイムアウト/エラーの場合、次のサーバーにフェールオーバーします（ベンダー実装に依存）。
Q4: stun usage ice lite は最新 CUBE バージョンでも推奨される？
A: はい。ICE Lite は標準的な構成で、エンタープライズ環境では引き続き推奨されています。TURN が必要でない限り、シンプルで効果的です。
Q5: stun server を設定しないと動作しないのか？
A: いいえ。stun usage ice lite だけで ICE Lite は機能します。STUN サーバーが指定されない場合、CUBE はホスト候補（LAN IP/ポート）のみを SDP に記載し、呼出側がそのホスト候補への接続を試みます。
使い分け:
- STUN サーバーなし: VPN 環境、信頼できる SIP Proxy、社内通信など → シンプル・低負荷
- STUN サーバーあり: インターネット経由の通信、SIP Trunk、複数の NAT 環境など → より多くの候補で接続確率向上
Cisco ベストプラクティスでも、環境に応じて STUN サーバーの設定は選択肢として扱われます。
Q6: Cisco ベストプラクティスで STUN サーバーを設定しない理由は？
A: ベストプラクティスドキュメントが対象とする環境下では、以下の理由が考えられます：
- VPN 環境が前提: 多くのエンタープライズ複数拠点通信は VPN 接続されており、STUN 不要
- 信頼できる SIP Proxy: 社内 SIP Proxy 経由の通信では、CUBE はホスト候補で十分
- シンプルさの重視: ベストプラクティスは最小限の設定で実現可能な構成を示す
- 環境依存性: STUN サーバーはインターネット環境に依存するため、ベストプラクティスでは「必須ではなく、必要に応じて追加」として扱う
つまり、「STUN サーバーがなくても ICE Lite は動作する」ということがベストプラクティスの前提になっています。
参考資料・RFC
- RFC 5389 - Session Traversal Utilities for NAT (STUN)
- RFC 5245 - Interactive Connectivity Establishment (ICE)
- RFC 3489 - STUN (旧版)
- Cisco CUBE 設定ガイド - voice service voip, stun 関連
- RFC 8445 - Interactive Connectivity Establishment (ICE) - Updated version
このドキュメントは、STUN・ICE Lite・Cisco CUBE の基本から実装まで、実務的なポイントをカバーしています。環境固有の要件が生じた場合は、Cisco TAC や STUN サーバープロバイダーへの相談をお勧めします。