前回の第1回では、SIPが「マスタースレーブではない自律的なプロトコル」であり、通信のセッションを制御するインフラであることを解説しました。
では、このSIPのメッセージ（INVITEやBYE）は、具体的にネットワークのどの通り道（トランスポート）を使って、どんなサーバーたちを経由して相手に届くのでしょうか？
第2回となる今回は、ネットワークエンジニアの登竜門となる「UDPとTCPの使い分けの歴史」から、システムの中核を担う「プロキシサーバー（ステートフル／ステートレス）」、そしてユーザーの所在を管理する「登録・ロケーション・リダイレクトサーバー」の連携までを徹底解剖します。さらに、多くの人が混同する「SIP URIとURLの違い」や、電話番号をIP網に繋ぐ「ENUM（NID/NSS）」の仕組みまで、インフラ構築の現場で必須となる知識を網羅します。
📚 第2回：本記事で解決する疑問とトピックス
- SIPでUDPもTCPもどちらも必要になった経緯（SCTP、5060、TLS 5061ポートの全貌）
- 端末の二面性：UA、UAS、UACとは何か？
- ステートフルプロキシとは何か？それがないとどうなるか？
- 登録サーバー、ロケーションサーバー、リダイレクトサーバーの役割と、不在時の致命的影響
- SIP URIとは何か？URIとURLの根本的な違い
- 電話番号とIPを結ぶENUM：NIDとNSSの正体
1. トランスポート層の進化：UDPもTCPも必要になった経緯
SIPのメッセージを相手に届けるための「運び屋（トランスポート層）」として、最初はUDP（User Datagram Protocol）が主流でした。しかし現在ではTCP（Transmission Control Protocol）のサポートも必須となっています。なぜこのような変遷を辿ったのでしょうか。
なぜ最初は「UDP」だったのか？
SIPは「リアルタイムな通信」を開始するためのプロトコルです。電話をかけた時、1秒でも早く相手のベルを鳴らす（シグナリングを完了させる）ためには、パケットの到達確認を行わず、データを投げっぱなしにする軽量で高速なUDPが最適でした。
なぜ「TCP」が必須になったのか？
時代が進むにつれ、SIPは高機能化し、メッセージに付与される情報（ヘッダやSDP）が巨大化していきました。
ネットワークには、一度に送れるパケットの最大サイズ（MTU：通常1500バイト程度）という制限があります。SIPメッセージがこのサイズを超えると、UDPではデータが分割（フラグメント化）されてしまい、ネットワーク機器で破棄されたり、順序が入れ替わって正常に解読できなくなるトラブルが頻発しました。
この問題を解決するため、データを分割しても確実に順序通りに組み立て直してくれる「TCP」による通信が、巨大なSIPメッセージ（概ね1300バイト以上）において必須要件となったのです。
SCTPとポート番号（5060 / 5061）のルール
さらに近年では、UDPの高速性とTCPの信頼性の「いいとこ取り」をしたSCTP（Stream Control Transmission Protocol）が使われるケースもあります。SCTPは複数の経路を束ねるマルチホーミング機能を持ち、キャリアグレードの通信（VoLTEや5Gコアなど）で高い耐障害性を発揮します。
- ポート 5060： UDPおよびTCPで使用される、通常の（暗号化されていない）SIP通信ポート。
- ポート 5061（SIPS）： TLS（Transport Layer Security）を用いて暗号化されたSIP通信専用のポート。通信経路での盗聴や改ざんを防ぐための必須設定です。
2. 通信の主役：UA、UAC、UASの二面性
SIPのネットワーク構成図を見ると、エンドポイント（端末）は必ずUA（User Agent：ユーザーエージェント）と呼ばれます。IP電話機、スマホアプリ、あるいは自動音声応答装置（IVR）もすべてUAです。
ここで重要なのは、1つのUAは状況によって2つの顔（UACとUAS）を使い分けるという点です。
- UAC (User Agent Client)： リクエスト（要求）を作成して送信する役割。電話を「かける」時の顔です。
- UAS (User Agent Server)： リクエストを受信してレスポンス（応答）を返す役割。電話を「受ける」時の顔です。
通話が成立する際、発信側のUAはUACとしてINVITEを送り、着信側のUAはUASとして200 OKを返します。しかし、通話中に着信側から「電話を切る（BYE）」場合、今度は着信側がUACとしてBYEを送り、発信側がUASとして200 OKを返すことになります。このように、クライアントとサーバーの役割が動的に入れ替わるのがSIPのピアツーピアモデルの特徴です。
3. SIPプロキシサーバーの真価：ステートフルとステートレス
SIPネットワークにおけるプロキシサーバー（Proxy Server）は、UAの代わりにメッセージを宛先へと中継する「案内役（ルーター）」です。これには大きく分けて2つの種類があり、それぞれ全く異なる役割を持ちます。
ステートレスプロキシ：超高速な単なる「中継機」
ステートレスプロキシは、受信したメッセージを右から左へ転送するだけです。自分がどのメッセージを中継したかという「状態（ステート）」を一切記憶しません。
メリット： メモリを消費しないため、超高速で大量のパケットを捌けます（ロードバランサー等に最適）。
デメリット： 複雑な制御は一切できません。
ステートフルプロキシ：賢い「状態管理者」
ステートフルプロキシは、「AさんからBさんへの通話要求（トランザクション）が現在進行中である」という状態をメモリに記憶しながら中継を行います。
⚠️ もしステートフルプロキシがなかったらどうなる？
ステートフルプロキシがないと、IP電話の利便性を支える高度な機能が全滅します。
- フォーク機能の喪失： 1つの着信で、オフィスの電話と個人のスマホを「同時に鳴らす（パラレルフォーク）」ことができません。片方が出たらもう片方の呼び出しをキャンセルする、といった状態管理ができないからです。
- 再送制御の喪失： UDPでパケットが途中で消えた場合、「相手から応答がないからもう一度送ろう」という気の利いた再送処理ができなくなります。
- 課金・ログの破綻： 「いつからいつまで通話したか」というトランザクションを記憶できないため、正確な通話ログの生成や課金処理が不可能になります。
現代のクラウドPBXやコンタクトセンターにおいて、このステートフルプロキシがシステムのコアとして鎮座しているのです。
4. 所在を追跡するトリオ：登録・ロケーション・リダイレクトサーバー
スマホやノートPCなど、移動するデバイスはネットワークに繋がるたびにIPアドレスが変化します。では、発信者はどうやって相手の現在のIPアドレスを見つけ出しているのでしょうか？それを解決するのが以下の3つのサーバー群です。
| サーバー名 | 役割と挙動 | ない場合の影響 |
|---|---|---|
| 登録サーバー (Registrar) |
端末からの「私は今このIPアドレスにいます」というREGISTER要求を受け付ける窓口です。 | 誰も自分の居場所を申告できず、システムへのログイン（レジスト）が成立しません。 |
| ロケーションサーバー (Location Server) |
登録サーバーが受け取った情報を蓄積・検索・管理するデータベースです。プロキシサーバーが宛先を検索する際に参照します。 | 【致命的】IPアドレスが固定されていないモバイル端末に対し、一切着信させることができなくなります。 |
| リダイレクトサーバー (Redirect Server) |
代理で中継するのではなく、「その人は今あっちのアドレスにいますよ」と発信者に新しい宛先（302 Moved Temporarilyなど）を直接教えるサーバーです。 | 発信側への直接的な転送案内ができなくなり、特定のプロキシに中継負荷が集中しやすくなります。 |
5. 宛先の指定：SIP URIとURLの根本的な違い
SIPにおける通信相手の宛先は、メールアドレスのような形式（例：sip:alice@example.com）で指定されます。これをSIP URIと呼びます。ここでよく「URIとURLの違いがわからない」という疑問が生じます。
- URI (Uniform Resource Identifier)： ネットワーク上のリソース（資源や人）を識別するための「総称（大きな括り）」です。
- URL (Uniform Resource Locator)： URIの一部であり、リソースの「具体的な場所（Location）」を示すものです。（例：
https://www.google.com/index.html） - URN (Uniform Resource Name)： URIのもう一部であり、場所が変わっても変わらない「永続的な名前（Name）」を示します。（例：書籍のISBNコードなど）
つまり、SIPは「その人が世界のどこ（どのIPアドレス）に移動しても、sip:alice@example.com という不変の識別子で呼び出せる」ように設計されているため、場所（URL）ではなく、識別子（URI）という言葉を使っているのです。
6. 電話網とIP網の架け橋「ENUM」：NIDとNSSの正体
IP電話同士なら sip:alice@example.com で通信できますが、世界中の一般の電話は「090-XXXX-XXXX」といったE.164という規格の電話番号を使っています。この「電話番号」から、どうやって「SIP URI」を探し出しているのでしょうか？
この変換を行う仕組みがENUM（E.164 NUmber Mapping）です。ENUMは、インターネットのDNS（Domain Name System）を使って電話番号をドメイン名に変換します。
ここで登場するのが、URIの一種であるURNを構成するNID（ネームスペース識別子）とNSS（ネームスペース固有文字列）です。
urn:ietf:params:enum
・urn: （URNであることを示す）
・NID (Namespace ID): ietf:params:enum （これがENUMに関連する名前空間であることを示す識別子）
・NSS (Namespace Specific String): 実際の固有の文字列や条件
ENUMの具体的な変換プロセスは非常にユニークです。例えば日本の電話番号「+81-3-1234-5678」に発信した場合、システムは電話番号を逆から並べ替え、ドットで区切り、最後に .e164.arpa という特別なドメインを付与します。
8.7.6.5.4.3.2.1.3.1.8.e164.arpa
このドメインに対してDNSに問い合わせ（NAPTRレコード検索）を行うことで、「この電話番号の着信先は sip:tokyo-office@example.com だよ」というSIP URIの回答を得ます。こうして、伝統的な電話網と最新のIP網がシームレスに繋がっているのです。
第2回のまとめと次回予告
今回は、SIPがネットワーク上でどのように運ばれ、どのようなサーバー群がリレーしているのかを解説しました。
- データ大容量化によりUDPだけでなくTCP（さらにはSCTP）が必須となった。
- 複雑な着信制御（フォーク等）を行うために、記憶力を持つステートフルプロキシが不可欠である。
- 移動する端末を追跡するため、登録サーバーとロケーションサーバーが強力に連携している。
- 電話番号とIPアドレス（SIP URI）を結びつける裏側には、ENUMやDNSの高度な変換技術が隠れている。
さて、これで通信の「道路」と「案内所」の仕組みがわかりました。次はいよいよ、その道路を走る「車（パケット）」の中身を覗いてみましょう。
次回、第3回「SIPメッセージ・ヘッダの解剖と応用機能」では、読者の皆様が最も知りたい「INVITE, ACK, BYE, 180 Ringing, PRACK」などの各種メソッドや応答コードの詳細、そして「Call-IDやVia」といった複雑なSIPヘッダの読み解き方を解説します。さらに、コーラープリファレンスやプレゼンスといった応用機能にも迫りますので、お見逃しなく！
