4. Overview of Operation
4 Overview of Operation
この節では, 簡単な例を用いて SIP の基本動作を紹介します. この節はチュートリアル的な性質を持ち, いかなる規範的記述も含みません.
最初の例は, SIP の基本機能を示しています. すなわち, エンドポイントの位置特定, 通信したいという合図, セッションを確立するためのセッションパラメータのネゴシエーション, そして確立されたセッションの切断です.
図 1 は, 2 人のユーザ Alice と Bob の間の SIP メッセージ交換の代表的な例を示しています. (各メッセージには, 本文中で参照するための "F" と数字のラベルが付けられています.) この例では, Alice は PC 上の SIP アプリケーション (ソフトフォンと呼ばれます) を使って, インターネット経由で Bob の SIP 電話を呼び出します. また, Alice と Bob の代理として働き, セッション確立を容易にする 2 つの SIP プロキシサーバも示されています. この典型的な構成は, 図 1 の点線の幾何学的形状から "SIP 台形 (SIP trapezoid)" と呼ばれることがよくあります.
Alice は, Bob の SIP アイデンティティ (SIP URI と呼ばれる Uniform Resource Identifier (URI) の一種) を使って Bob を "呼び出し" ます. SIP URI は 19.1 節で定義されています. これは電子メールアドレスと似た形式で, 通常はユーザ名とホスト名を含みます. この場合, sip:[email protected] となり, biloxi.com は Bob の SIP サービスプロバイダのドメインです. Alice の SIP URI は sip:[email protected] です. Alice は Bob の URI を入力したか, あるいはハイパーリンクやアドレス帳の項目をクリックしたのでしょう. SIP は, SIPS URI と呼ばれる安全な URI も提供します. 例として sips:[email protected] があります. SIPS URI への呼び出しは, 発信者から被呼者のドメインまでのすべての SIP メッセージを運ぶために, 安全で暗号化されたトランスポート (すなわち TLS) が使用されることを保証します. そこから, リクエストは被呼者へ安全に送信されますが, 被呼者のドメインのポリシーに依存するセキュリティ機構を用います.
SIP は HTTP に似たリクエスト/レスポンスのトランザクションモデルに基づいています. 各トランザクションは, サーバ上の特定のメソッドまたは機能を呼び出すリクエストと, 少なくとも 1 つのレスポンスから構成されます. この例では, トランザクションは Alice のソフトフォンが Bob の SIP URI 宛てに送信する INVITE リクエストで始まります. INVITE は, リクエスト元 (Alice) がサーバ (Bob) に対して実行してほしい動作を指定する SIP メソッドの例です. INVITE リクエストには, 多数のヘッダフィールドが含まれます. ヘッダフィールドは, メッセージに関する追加情報を提供する名前付き属性です. INVITE に含まれるものとしては, コールを一意に識別する識別子, 宛先アドレス, Alice のアドレス, および Alice が Bob と確立しようとするセッションの種類に関する情報があります. INVITE (図 1 のメッセージ F1) は次のようになります.
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|`<---------------| 100 Trying F5 |--------------->`|
| |\<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |\<---------------|
| 180 Ringing F8 |\<---------------| 200 OK F9 |
|\<---------------| 200 OK F10 |\<---------------|
| 200 OK F11 |\<---------------| |
|\<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|`<================================================>`|
| BYE F13 |
|\<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |
Figure 1: SIP session setup example with SIP trapezoid
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob `<sip:[email protected]>`
From: Alice `<sip:[email protected]>`;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: `<sip:[email protected]>`
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
テキストで符号化されたメッセージの先頭行にはメソッド名 (INVITE) が含まれます. その後に続く行は, ヘッダフィールドのリストです. この例には, 最小限に必要なものが含まれています. ヘッダフィールドについては以下に簡単に説明します.
Via は, Alice がこのリクエストに対するレスポンスを受信しようとしているアドレス (pc33.atlanta.com) を含みます. また, このトランザクションを識別する branch パラメータも含みます.
To は, リクエストが最初に向けられた表示名 (Bob) と SIP または SIPS URI (sip:[email protected]) を含みます. 表示名は RFC 2822 [3] で説明されています.
From もまた, リクエストの発信者を示す表示名 (Alice) と SIP または SIPS URI (sip:[email protected]) を含みます. このヘッダフィールドには, ソフトフォンによって URI に付加されたランダムな文字列 (1928301774) を含む tag パラメータもあります. これは識別のために使用されます.
Call-ID は, ランダムな文字列とソフトフォンのホスト名または IP アドレスの組み合わせによって生成される, このコールのグローバルに一意な識別子を含みます. To タグ, From タグ, Call-ID の組み合わせは, Alice と Bob の間のピアツーピアの SIP 関係を完全に定義し, これをダイアログと呼びます.
CSeq (Command Sequence) は, 整数とメソッド名を含みます. CSeq 番号は, ダイアログ内の各新しいリクエストごとに増加し, 伝統的なシーケンス番号です.
Contact は, 直接 Alice に連絡するためのルートを表す SIP または SIPS URI を含み, 通常は完全修飾ドメイン名 (FQDN) でのユーザ名から構成されます. FQDN が望ましいですが, 登録済みドメイン名を持たない端末が多いため, IP アドレスも許可されています. Via ヘッダフィールドが他の要素にレスポンスの送信先を指示するのに対し, Contact ヘッダフィールドは他の要素に将来のリクエストの送信先を指示します.
Max-Forwards は, 宛先への到達までにリクエストが経由できるホップ数を制限する役割を持ちます. これは整数からなり, 各ホップで 1 ずつ減算されます.
Content-Type は, メッセージボディ (図示せず) の記述を含みます.
Content-Length は, メッセージボディのオクテット (バイト) 数を含みます.
SIP ヘッダフィールドの完全な集合は 20. 節で定義されています.
セッションの詳細 (メディアの種類, コーデック, サンプリングレートなど) は, SIP を用いて記述されません. むしろ, SIP メッセージのボディには, 他のプロトコル形式で符号化されたセッションの記述が含まれます. そのような形式の 1 つが Session Description Protocol (SDP) (RFC 2327 [1]) です. この SDP メッセージ (例には示されていません) は, 電子メールメッセージに添付された文書, あるいは HTTP メッセージに運ばれる Web ページに類似した方法で, SIP メッセージによって運ばれます.
ソフトフォンは Bob の位置や biloxi.com ドメイン内の SIP サーバを知らないため, ソフトフォンは Alice のドメイン atlanta.com の SIP サーバに INVITE を送信します. atlanta.com の SIP サーバのアドレスは, Alice のソフトフォンに設定されていたか, あるいは DHCP などによって発見されたのでしょう.
atlanta.com の SIP サーバは, プロキシサーバと呼ばれる種類の SIP サーバです. プロキシサーバは SIP リクエストを受信し, リクエスト元に代わってそれらを転送します. この例では, プロキシサーバは INVITE リクエストを受信し, 100 (Trying) レスポンスを Alice のソフトフォンに返します. 100 (Trying) レスポンスは, INVITE が受信され, プロキシが宛先へ INVITE をルーティングするために Alice の代わりに動作していることを示します. SIP のレスポンスは, 3 桁のコードとその後の説明的な句を用います. このレスポンスは, INVITE と同じ To, From, Call-ID, CSeq および Via 内の branch パラメータを含むため, Alice のソフトフォンはこのレスポンスを送信した INVITE に対応付けることができます. atlanta.com プロキシサーバは, biloxi.com のプロキシサーバを探します. おそらく, biloxi.com ドメインにサービスを提供する SIP サーバを見つけるための特定の種類の DNS (Domain Name Service) ルックアップを実行することでしょう. これは [4] で説明されています. その結果, biloxi.com プロキシサーバの IP アドレスを取得し, そこへ INVITE リクエストを転送 (プロキシ) します. リクエストを転送する前に, atlanta.com プロキシサーバは, 自身のアドレスを含む追加の Via ヘッダフィールド値を追加します (INVITE にはすでに Alice のアドレスが最初の Via に含まれています). biloxi.com プロキシサーバは INVITE を受信し, それを受信しリクエストを処理していることを示すために 100 (Trying) レスポンスを atlanta.com プロキシサーバに返します. プロキシサーバは, Bob の現在の IP アドレスを含む, 総称してロケーションサービスと呼ばれるデータベースを参照します. (このデータベースがどのように設定されるかは, 次節で見ます.) biloxi.com プロキシサーバは, 自身のアドレスを含む別の Via ヘッダフィールド値を INVITE に追加し, それを Bob の SIP 電話へプロキシします.
Bob の SIP 電話は INVITE を受信し, Alice からの着信を Bob に知らせ, Bob が通話に応答するかどうかを決定できるようにします. つまり, Bob の電話が鳴ります. Bob の SIP 電話は, これを 180 (Ringing) レスポンスで示し, これは逆方向に 2 つのプロキシを通ってルーティングされます. 各プロキシは Via ヘッダフィールドを用いてレスポンスの送信先を決定し, 自身のアドレスを先頭から削除します. その結果, 初期の INVITE のルーティングに DNS やロケーションサービスのルックアップが必要だったにもかかわらず, 180 (Ringing) レスポンスは, ルックアップやプロキシ内の状態保持なしに発呼者へ返すことができます. これはまた, INVITE を見た各プロキシが, INVITE へのすべてのレスポンスも見るという望ましい特性も持ちます.
Alice のソフトフォンが 180 (Ringing) レスポンスを受信すると, それを Alice に伝えます. おそらく音声のリングバック音を鳴らすか, 画面にメッセージを表示することでしょう.
この例では, Bob は通話に応答することを決めます. 受話器を取ると, 彼の SIP 電話は, 通話が応答されたことを示す 200 (OK) レスポンスを送信します. 200 (OK) には, Bob が Alice と確立しようとするセッションの種類についての SDP メディア記述を含むメッセージボディが含まれます. その結果, SDP メッセージの 2 段階の交換となります. Alice が 1 つを Bob に送り, Bob が 1 つを Alice に返します. この 2 段階の交換は基本的なネゴシエーション機能を提供し, SDP 交換の単純なオファー/アンサーモデルに基づいています. Bob が通話に応答したくない場合や他の通話で話し中の場合は, 200 (OK) の代わりにエラーレスポンスが送信され, メディアセッションは確立されません. SIP レスポンスコードの完全なリストは 21. 節にあります. 200 (OK) (図 1 のメッセージ F9) は, Bob が送信する際, 次のようになります.
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob `<sip:[email protected]>`;tag=a6c85cf
From: Alice `<sip:[email protected]>`;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: `<sip:[email protected]>`
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
レスポンスの先頭行にはレスポンスコード (200) と理由句 (OK) が含まれます. 残りの行にはヘッダフィールドが含まれます. Via, To, From, Call-ID, CSeq ヘッダフィールドは INVITE リクエストからコピーされます. (Via ヘッダフィールド値は 3 つあります. 1 つは Alice の SIP 電話が, 1 つは atlanta.com プロキシが, もう 1 つは biloxi.com プロキシが追加したものです.) Bob の SIP 電話は, To ヘッダフィールドに tag パラメータを追加しました. このタグは両端点によってダイアログに組み込まれ, このコール内のすべての将来のリクエストとレスポンスに含まれます. Contact ヘッダフィールドには, Bob の SIP 電話で直接 Bob に到達できる URI が含まれます. Content-Type および Content-Length は, Bob の SDP メディア情報を含むメッセージボディ (図示せず) を参照します.
この例に示された DNS およびロケーションサービスのルックアップに加えて, プロキシサーバは, リクエストをどこへ送信するかを決定する柔軟な "ルーティング決定" を行うことができます. たとえば, Bob の SIP 電話が 486 (Busy Here) レスポンスを返した場合, biloxi.com プロキシサーバは INVITE を Bob のボイスメールサーバへプロキシできます. プロキシサーバは, 複数の場所へ同時に INVITE を送信することもできます. この種の並列探索はフォーキングと呼ばれます.
この場合, 200 (OK) は 2 つのプロキシを通ってルーティングされ, Alice のソフトフォンによって受信され, そこでリングバック音を停止し, 通話が応答されたことを示します. 最後に, Alice のソフトフォンは, 最終レスポンス (200 (OK)) の受信を確認するために, 確認応答メッセージ ACK を Bob の SIP 電話へ送信します. この例では, ACK は 2 つのプロキシをバイパスして, Alice のソフトフォンから Bob の SIP 電話へ直接送信されます. これは, 端点が INVITE/200 (OK) 交換を通じて互いのアドレスを Contact ヘッダフィールドから学習したためで, これは初期の INVITE 送信時には未知でした. 2 つのプロキシによって行われたルックアップはもはや不要なため, プロキシはコールフローから外れます. これにより, SIP セッションの確立に用いられる INVITE/200/ACK の 3 ウェイハンドシェイクが完了します. セッション確立の詳細は 13. 節にあります.
Alice と Bob のメディアセッションが開始され, 彼らは SDP の交換で合意した形式を用いてメディアパケットを送信します. 一般に, エンドツーエンドのメディアパケットは, SIP シグナリングメッセージとは異なる経路をたどります.
セッション中, Alice または Bob のいずれかが, メディアセッションの特性を変更することを決定する場合があります. これは, 新しいメディア記述を含む再 INVITE (re-INVITE) を送信することで実現されます. この再 INVITE は既存のダイアログを参照するため, 相手はそれが新しいセッションの確立ではなく既存のセッションの変更であることを知ります. 相手は変更を受け入れる 200 (OK) を送信します. リクエスト元は 200 (OK) に ACK で応答します. 相手が変更を受け入れない場合は, 488 (Not Acceptable Here) のようなエラーレスポンスを送信し, これにも ACK が返されます. しかし, 再 INVITE の失敗は既存のコールを失敗させることはなく, セッションは以前にネゴシエートされた特性を用いて継続されます. セッション変更の詳細は 14. 節にあります.
通話の終わりに, Bob が先に切断 (電話を切る) し, BYE メッセージを生成します. この BYE は再びプロキシをバイパスして, Alice のソフトフォンへ直接ルーティングされます. Alice は BYE の受信を 200 (OK) レスポンスで確認し, これによりセッションと BYE トランザクションが終了します. ACK は送信されません. ACK は INVITE リクエストに対するレスポンスへの応答としてのみ送信されます. INVITE に対するこの特別な扱いの理由は後で議論しますが, SIP の信頼性機構, 電話が応答されるまでにかかる時間, およびフォーキングに関係します. このため, SIP のリクエスト処理はしばしば INVITE または非 INVITE (INVITE 以外のすべてのメソッドを指します) に分類されます. セッション終了の詳細は 15. 節にあります.
図 1 に示されたメッセージの完全な記述は 24.2 節にあります.
場合によっては, SIP シグナリングパス上のプロキシが, セッションの期間中, 端点間のすべてのメッセージングを参照できることが有用なことがあります. たとえば, biloxi.com プロキシサーバが初期の INVITE 以降も SIP メッセージングパスにとどまることを望む場合, プロキシのホスト名または IP アドレスに解決される URI を含む, Record-Route と呼ばれる必須のルーティングヘッダフィールドを INVITE に追加します. この情報は Bob の SIP 電話 (および 200 (OK) で返される Record-Route ヘッダフィールドによるため Alice のソフトフォンにも) によって受信され, ダイアログの期間中保存されます. そうすると, biloxi.com プロキシサーバは ACK, BYE, および BYE に対する 200 (OK) を受信してプロキシします. 各プロキシは独立して後続のメッセージを受信するかを決定でき, それらのメッセージは受信を選択したすべてのプロキシを通過します. この機能は, 通話中の機能を提供するプロキシによく用いられます.
登録 (Registration) は SIP のもう 1 つの一般的な操作です. 登録は, biloxi.com サーバが Bob の現在の位置を学習するための 1 つの方法です. 初期化時, および定期的間隔で, Bob の SIP 電話は, biloxi.com ドメイン内の SIP レジストラと呼ばれるサーバへ REGISTER メッセージを送信します. REGISTER メッセージは, Bob の SIP または SIPS URI (sip:[email protected]) を, 彼が現在ログインしているマシン (Contact ヘッダフィールド内の SIP または SIPS URI として伝達されます) に関連付けます. レジストラはこの関連付け (バインディングとも呼ばれます) を, biloxi.com ドメイン内のプロキシが使用できるロケーションサービスと呼ばれるデータベースに書き込みます. 多くの場合, ドメインのレジストラサーバはそのドメインのプロキシと同じ場所に配置されます. 重要な概念として, SIP サーバの種類の区別は論理的なものであり, 物理的なものではありません.
Bob は単一のデバイスからの登録に限定されません. たとえば, 自宅の SIP 電話とオフィスのものの両方が登録を送信できます. この情報はロケーションサービス内に一緒に保存され, プロキシが Bob を見つけるためのさまざまな種類の探索を実行できるようにします. 同様に, 1 つのデバイスに複数のユーザを同時に登録することもできます.
ロケーションサービスは単なる抽象的な概念です. これは一般に, プロキシが URI を入力として受け取り, リクエストをどこへ送信するかを示す 0 個以上の URI の集合を出力できるようにする情報を含みます. 登録はこの情報を作成する 1 つの方法ですが, 唯一の方法ではありません. 任意のマッピング関数は, 管理者の裁量で設定できます.
最後に, SIP において, 登録は着信 SIP リクエストのルーティングに使用され, 発信リクエストの認可には役割を持たないことに注意が重要です. 認可と認証は, SIP では, チャレンジ/レスポンス機構によるリクエストごとの処理, または 26. 節で議論される下位層方式のいずれかによって処理されます.
この登録例に関する SIP メッセージの詳細の完全な集合は 24.1 節にあります.
SIP のその他の操作, たとえば OPTIONS を用いた SIP サーバやクライアントの機能の問い合わせ, または CANCEL を用いた保留中のリクエストの取り消しは, 後の節で紹介します.