Cisco IOS SIP コンフィギュレーション ガイド
S IP の概要
SIP の概要
発行日;2012/02/01 | 英語版ドキュメント(2011/04/13 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 7MB) | フィードバック

目次

SIP の概要

この章の構成

SIP の概要

SIP 機能

SIP コンポーネント

SIP クライアント

SIP サーバ

SIP の機能

SIP とプロキシ サーバの機能

SIP とリダイレクト サーバの機能

SIP コール フロー

SIP ゲートウェイから SIP ゲートウェイ:コールの設定と切断

SIP ゲートウェイから SIP ゲートウェイ:SIP リダイレクト サーバ経由のコール

SIP ゲートウェイから SIP ゲートウェイ:SIP プロキシ サーバ経由のコール

その他の参考資料

関連資料

規格

MIB

RFC

シスコのテクニカル サポート

SIP の概要

この章では、Session Initiation Protocol(SIP)の概要を説明します。

SIP の概要

Session Initiation Protocol(SIP)は、ASCII ベースのアプリケーション層制御プロトコルであり、複数のエンドポイント間のコールの確立、維持、および終了に使用できます。SIP は、Internet Engineering Task Force(IETF; インターネット技術特別調査委員会)が開発した、IP を介したマルチメディア会議用の代替プロトコルです。SIP 機能は、1999 年 3 月に発表された IETF RFC 2543「SIP: Session Initiation Protocol」に準拠しています。

Cisco SIP の実装では、サポートされるシスコ プラットフォームが IP ネットワークを介した音声コールおよびマルチメディア コールの確立を通知します。

他の Voice over IP(VoIP)プロトコルと同様に、SIP はパケット テレフォニー ネットワークにおけるシグナリングとセッション管理の機能に対応するよう設計されています。シグナリングは、ネットワーク境界を越えてコール情報を伝送する機能です。セッション管理は、エンドツーエンド コールのアトリビュートを制御する機能です。

SIP 機能

SIP には次の機能があります。

ターゲット エンドポイントの位置の判別:SIP は、アドレス解決、ネーム マッピング、およびコール リダイレクションをサポートします。

ターゲット エンドポイントのメディア機能の判別:SIP は、Session Description Protocol(SDP)を介してエンドポイント間で共通する最小レベルのサービスを判別します。会議は、すべてのエンドポイントでサポートされるメディア機能だけを使用して確立されます。

ターゲット エンドポイントのアベイラビリティの判別:ターゲット エンドポイントが使用できないためにコールを確立できない場合、SIP は、着信側が電話中であるか、割り当てられた呼び出し音の回数内に応答しなかったかを判別します。その後、ターゲット エンドポイントが使用できない理由を示すメッセージを返します。

発信側エンドポイントとターゲット エンドポイント間のセッションの確立:コールが確立すると、SIP はエンドポイント間のセッションを確立します。SIP は、別のエンドポイントを会議に追加したり、メディアの特性やコーデックを変更したりするなど、コール途中での変更もサポートします。

コールの転送および終了の処理:SIP は、あるエンドポイントから別のエンドポイントへのコールの転送をサポートします。コール転送時には、SIP は単に転送される側と新しいエンドポイント(転送する側が指定)との間のセッションを確立し、転送される側と転送する側との間のセッションを終了させます。コールが終了した時点で、SIP は、すべての通話者間のセッションを終了します。


) 「会議」という用語は、複数のエンドポイント間で確立されているセッション(またはコール)を表します。会議は、2 人以上のユーザで構成され、マルチキャスト セッションまたは複数のユニキャスト セッションを使用して確立します。


SIP コンポーネント

SIP はピアツーピア プロトコルです。セッション内のピアは User Agent(UA; ユーザ エージェント)と呼ばれます。UA は次のいずれかとして機能します。

User-Agent Client(UAC; ユーザ エージェント クライアント):SIP 要求を開始するクライアント アプリケーション。

User-Agent Server(UAS; ユーザ エージェント サーバ):SIP 要求を受信したときにユーザに通知し、ユーザに代わって応答を返すサーバ アプリケーション。

通常、SIP エンドポイントは UAC と UAS の両方の働きをしますが、トランザクションごとにいずれか一方としてだけ機能します。エンドポイントが UAC として機能するか、UAS として機能するかは、要求を開始したユーザ エージェントによって決まります。

アーキテクチャの観点からは、SIP ネットワークの物理コンポーネントは、クライアント(エンドポイント)とサーバの 2 つのカテゴリに分類されます。図 1 に、SIP ネットワークのアーキテクチャを示します。


) SIP サーバは、Lightweight Directory Access Protocol(LDAP)サーバ、ロケーション サーバ、データベース アプリケーション、Extensible Markup Language(XML; 拡張マークアップ言語)アプリケーションなど、他のアプリケーション サービスとも対話できます。これらのアプリケーション サービスは、ディレクトリ サービス、認証サービス、課金サービスなどのバックエンド サービスを提供します。


図 1 SIP アーキテクチャ

 

SIP クライアント

電話機:UAS または UAC のいずれかとして機能します。

ソフトフォン(電話機の機能がインストールされた PC)および Cisco SIP IP Phone は、SIP 要求を開始し、SIP 要求に応答できます。

ephone:ゲートウェイで設定されない IP 電話。

ゲートウェイ:コールを制御します。ゲートウェイはさまざまなサービスを提供しますが、最も一般的なものは、SIP 会議エンドポイントと他の端末タイプとの間での変換機能です。この機能には、伝送フォーマットの変換および通信プロシージャの変換が含まれます。また、ゲートウェイは、オーディオ コーデック間およびビデオ コーデック間で変換を行い、LAN 側と交換回線網側の両方でコールを確立または切断します。

SIP サーバ

プロキシ サーバ:クライアントから SIP 要求を受信し、その要求をクライアントに代わって転送します。基本的に、プロキシ サーバは、SIP メッセージを受信し、そのメッセージをネットワーク内の次の SIP サーバに転送します。プロキシ サーバは、認証、許可、ネットワーク アクセス制御、ルーティング、信頼性の高い要求再送信、セキュリティなどの機能を備えています。

リダイレクト サーバ:メッセージが進む次の 1 つまたは複数のホップに関する情報をクライアントに提供します。クライアントはネクストホップ サーバまたは UAS に直接接続します。

登録サーバ:現在位置の登録を求める、UAC からの要求を処理します。登録サーバは、多くの場合リダイレクト サーバやプロキシ サーバと同じ場所に置かれます。

SIP の機能

SIP は単純な ASCII ベース プロトコルで、要求および応答を使用してネットワーク内のさまざまなコンポーネント間で通信を確立し、最終的に複数のエンドポイント間で会議を確立します。

SIP ネットワークのユーザは、独自の SIP アドレスで識別されます。SIP アドレスは E メール アドレスに似た sip: userID @ gateway.com の形式です。ユーザ ID は、ユーザ名または E.164 アドレスのいずれかです。ゲートウェイは、ドメイン(ホスト名あり、またはなし)または特定のインターネット IP アドレスのいずれかです。


) E.164 アドレスは、公衆網の終端地点を一意に示す 10 進数の文字列を持つ電話番号です。この番号には、コールをこの終端地点にルーティングするために必要なすべての情報が含まれます。


ユーザは、割り当てられた SIP アドレスを使用して登録サーバに登録されます。登録サーバは、要求に応じてこの情報をロケーション サーバに提供します。

ユーザがコールを開始すると、SIP 要求が SIP サーバ(プロキシ サーバまたはリダイレクト サーバ)に送信されます。この SIP 要求には、発信側アドレス(From ヘッダー フィールド)と目的の着信側アドレス(To ヘッダー フィールド)が含まれます。

時間の経過とともに、SIP のエンド ユーザはエンド システム間を移動することがあります。エンド ユーザの位置は、SIP サーバにダイナミックに登録できます。ロケーション サーバは、1 つまたは複数のプロトコル(フィンガー、rwhois、LDAP など)を使用してエンド ユーザの位置を特定できます。エンド ユーザは複数のステーションにログインできるため、またロケーション サーバの情報が正しくないこともあるため、ロケーション サーバはエンド ユーザのアドレスを複数返すことがあります。要求が SIP プロキシ サーバを経由して着信した場合、SIP プロキシ サーバはエンド ユーザを見つけるまで返された各アドレスを試行します。要求が SIP リダイレクト サーバを経由して着信した場合、SIP リダイレクト サーバは INVITE 応答の Contact ヘッダー フィールドを使用して発信者にすべてのアドレスを転送します。

SIP とプロキシ サーバの機能

プロキシ サーバ経由で通信する場合、発信側 UA がプロキシ サーバに INVITE 要求を送信すると、プロキシ サーバはパスを決定して着信側にその要求を転送します(図 2 を参照)。

図 2 プロキシ サーバ経由の SIP INVITE 要求

 

着信側 UA はプロキシ サーバに応答し、プロキシ サーバは応答を発信者に転送します(図 3 を参照)。

図 3 プロキシ サーバ経由の SIP 応答

 

発信側と受信側の両方が確認応答(SIP ACK メッセージ)で応答すると、プロキシ サーバは確認応答を相手側に転送し、発信側と受信側との間にセッション(会議)が確立されます。Real-time Transfer Protocol(RTP; リアルタイム トランスポート プロトコル)が発信側 UA と着信側 UA の間に確立された接続を介した通信に使用されます(図 4 を参照)。

図 4 プロキシ サーバ経由の SIP セッション

 

SIP とリダイレクト サーバの機能

リダイレクト サーバ経由で通信する場合、発信側 UA がリダイレクト サーバに SIP INVITE 要求を送信すると、リダイレクト サーバはロケーション サーバに接続して着信側へのパスを決定し、発信側 UA にその情報を返信します。発信側 UA は情報を受信したという確認応答を行います(図 5 を参照)

図 5 リダイレクト サーバ経由の SIP INVITE

 

発信側 UA は、リダイレクト情報に示されているデバイスに SIP INVITE 要求を直接送信して、リダイレクト サーバをバイパスします (この段階のターゲット デバイスは、着信側 UA 自身または要求を転送するプロキシ サーバのいずれかです)。要求が着信側 UA に到達すると、着信側 UA は応答を送信します。この応答が SIP 200 OK メッセージの場合、発信側 UA は SIP ACK メッセージで応答して 200 OK 応答を受信したという確認応答を行います。発信側 UA と着信側 UA の間の通信に RTP を使用して、セッションが 2 つのエンドポイント間に確立されます (図 6 を参照)。

図 6 リダイレクト サーバ経由の SIP セッション

 

 

SIP コール フロー

ここでは、次のシナリオのコール フローについて説明し、成功したコールを図示します。

「SIP ゲートウェイから SIP ゲートウェイ:コールの設定と切断」

「SIP ゲートウェイから SIP ゲートウェイ:SIP リダイレクト サーバ経由のコール」

「SIP ゲートウェイから SIP ゲートウェイ:SIP プロキシ サーバ経由のコール」

SIP ゲートウェイから SIP ゲートウェイ:コールの設定と切断

図 7 に、ゲートウェイからゲートウェイへの成功したコールの設定と切断を示します。エンド ユーザはユーザ A とユーザ B の 2 人です。ユーザ A は PBX A 側に位置し、PBX A は T1/E1 によって SIP ゲートウェイ 1 に接続されています。ユーザ B は PBX B 側に位置し、PBX B は T1/E1 によって SIP ゲートウェイ 2 に接続されています。ユーザ B の電話番号は 555-0100 です。SIP ゲートウェイ 1 は、IP ネットワーク経由で SIP ゲートウェイ 2 に接続されています。

コール フロー シナリオは次のとおりです。

1. ユーザ A がユーザ B にコールを発信します。

2. ユーザ B がコールに応答します。

3. ユーザ B がコールを切断します。

図 7 SIP ゲートウェイから SIP ゲートウェイ:コールの設定と切断

 


) RFC 2543-bis-04 では、BYE 要求を受信する UAS は、コールを切断する前にまずそのコールの保留されている要求に対する応答を送信する必要があります。UAS は、BYE 要求を受信すると、487(Request Cancelled)ステータス メッセージで応答する必要があります。


図 7 では、次のプロセスが実行されます。

 

プロセス
説明

1. Setup:PBX A から SIP ゲートウェイ 1 へ

コール設定が PBX A と SIP ゲートウェイ 1 との間で開始されます。コール設定には、ユーザ A がユーザ B にコールを発信しようとするときに行われる標準トランザクションが含まれます。

2. INVITE:SIP ゲートウェイ 1 から SIP ゲートウェイ 2 へ

SIP ゲートウェイ 1 は、SIP ゲートウェイ 2 に INVITE 要求を送信します。INVITE 要求は、コール セッションに参加するようユーザ B に求める招待です。INVITE 要求の内容は次のとおりです。

ユーザ B の電話暗号が SIP URL の形式で Request-URI フィールドに挿入されます。SIP URL は、ユーザ B のアドレスを指定し、E メール アドレスのような形式を取ります(user@host、user は電話番号、host はドメイン(ホスト名あり、またはなし)または数値ネットワーク アドレスです)。たとえば、ユーザ B への INVITE 要求の Request-URI フィールドは「INVITE sip:555-0100@example.com; user=phone」と表示されます。「user=phone」パラメータは、Request-URI アドレスはユーザ名ではなく、電話番号であることを示します。

PBX A は、コール セッションの開始側として From フィールドに指定されます。

固有の数値 ID がコールに割り当てられ、Call-ID フィールドに挿入されます。

1 つのコール レッグ内のトランザクション番号が CSeq フィールドに指定されます。

ユーザ A が受信可能なメディア機能が指定されます。

SIP ゲートウェイ 1 が RTP データを受信できるポートが指定されます。

3. Call Proceeding:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Call Proceeding メッセージを送信し、コール設定要求を受信したという確認応答を行います。

4. Setup:SIP ゲートウェイ 2 から PBX B へ

SIP ゲートウェイ 2 は SIP ゲートウェイ 1 から INVITE 要求を受信し、PBX B を経由してユーザ B とのコール設定を開始します。

5. 100 Trying:SIP ゲートウェイ 2 から SIP ゲートウェイ 1 へ

SIP ゲートウェイ 2 は、SIP ゲートウェイ 1 から送信された INVITE 要求に対して 100 Trying 応答を送信します。100 Trying 応答は、INVITE 要求が SIP ゲートウェイ 2 によって受信されたが、ユーザ B の場所がまだ特定されていないこと、およびデータベース参照などの指定されていないアクションが実行されていることを示します。

6. Call Proceeding:PBX B から SIP ゲートウェイ 2 へ

PBX B は、SIP ゲートウェイ 2 に Call Proceeding メッセージを送信し、コール設定要求を受信したという確認応答を行います。

7. Alerting:PBX B から SIP ゲートウェイ 2 へ

PBX B は、ユーザ B の位置を特定し、SIP ゲートウェイ 2 に Alert メッセージを送信します。ユーザ B の電話機の呼び出し音が鳴り始めます。

8. 180 Ringing:SIP ゲートウェイ 2 から SIP ゲートウェイ 1 へ

SIP ゲートウェイ 2 は、SIP ゲートウェイ 1 に 180 Ringing 応答を送信します。180 Ringing 応答は、SIP ゲートウェイ 2 がユーザ B の位置を特定し、ユーザ B にアラートを通知しようとしていることを示します。

9. Alerting:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A を経由してユーザ A に Alert メッセージを送信します。Alert メッセージは、SIP ゲートウェイ 1 が SIP ゲートウェイ 2 から 180 Ringing 応答を受信したことを示します。ユーザ A には、ユーザ B にアラートが通知されたことを示すリングバック トーンが聞こえます。

この時点で、SIP ゲートウェイ 1 と PBX A の間、および SIP ゲートウェイ 2 と PBX B の間に単方向音声パスが確立します。SIP ゲートウェイ 1 と SIP ゲートウェイ 2 の間には双方向 RTP チャネルが確立します。

10. Connect:PBX B から SIP ゲートウェイ 2 へ

ユーザ B が電話に応答します。PBX B は、SIP ゲートウェイ 2 に Connect メッセージを送信します。Connect メッセージは、接続が確立したことを SIP ゲートウェイ 2 に通知します。

11. 200 OK:SIP ゲートウェイ 2 から SIP ゲートウェイ 1 へ

SIP ゲートウェイ 2 は、SIP ゲートウェイ 1 に 200 OK 応答を送信します。200 OK 応答は、接続が確立したことを SIP ゲートウェイ 1 に通知します。

ユーザ B が SIP ゲートウェイ 1 から送信された INVITE メッセージでアドバタイズされたメディア機能をサポートしている場合、ユーザ B はユーザ B 自身とユーザ A のメディア機能の共通部分を 200 OK 応答でアドバタイズします。ユーザ B がユーザ A によってアドバタイズされたメディア機能をサポートしていない場合、ユーザ B は 304 Warning ヘッダー フィールドを持つ 400 Bad Request 応答を返信します。

12. Connect:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Connect メッセージを送信します。Connect メッセージは、接続が確立したことを PBX A に通知します。

13. Connect ACK:PBX A から SIP ゲートウェイ 1 へ

PBX A は、SIP ゲートウェイ 1 の Connect メッセージを受信したという確認応答を行います。

14. ACK:SIP ゲートウェイ 1 から SIP ゲートウェイ 2 へ

SIP ゲートウェイ 1 は、SIP ゲートウェイ 2 に ACK を送信します。ACK は、SIP ゲートウェイ 1 が SIP ゲートウェイ 2 から 200 OK 応答を受信したことを確認します。

15. Connect ACK:SIP ゲートウェイ 2 から PBX B へ

SIP ゲートウェイ 2 は、PBX B の Connect メッセージを受信したという確認応答を行います。

これで、コール セッションはリアルタイム トランスポート プロトコル(RTP)を介した双方向音声パスでアクティブになります。

この時点で、SIP ゲートウェイ 1 と PBX A の間、および SIP ゲートウェイ 2 と PBX B の間に双方向音声パスが確立します。SIP ゲートウェイ 1 と SIP ゲートウェイ 2 の間には双方向 RTP チャネルが確立します。

16. Disconnect:PBX B から SIP ゲートウェイ 2 へ

ユーザ B がコールを切断すると、PBX B は SIP ゲートウェイ 2 に Disconnect メッセージを送信します。Disconnect メッセージは、コール セッション終了プロセスを開始します。

17. BYE:SIP ゲートウェイ 2 から SIP ゲートウェイ 1 へ

SIP ゲートウェイ 2 は、SIP ゲートウェイ 1 に BYE 要求を送信します。BYE 要求は、ユーザ B がコールを解放しようとしていることを示します。コールを終了しようとしているのがユーザ B であるため、Request-URI フィールドは PBX A の SIP URL に置き換えられ、From フィールドにユーザ B の SIP URL が含まれます。cseq 値が 1 増加します。

18. Release:SIP ゲートウェイ 2 から PBX B へ

SIP ゲートウェイ 2 は、PBX B に Release メッセージを送信します。

19. Disconnect:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Disconnect メッセージを送信します。

20. Release:PBX A から SIP ゲートウェイ 1 へ

PBX A は、SIP ゲートウェイ 1 に Disconnect メッセージを送信します。

21. 200 OK:SIP ゲートウェイ 1 から SIP ゲートウェイ 2 へ

SIP ゲートウェイ 1 は、SIP ゲートウェイ 2 に 200 OK 応答を送信します。200 OK 応答は、SIP ゲートウェイ 1 が BYE 要求を受信したことを SIP ゲートウェイ 2 に通知します。

22. Release Complete:PBX B から SIP ゲートウェイ 2 へ

PBX B は、SIP ゲートウェイ 2 に Release Complete メッセージを送信します。

23. Release Complete:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 が PBX A に Release Complete メッセージを送信すると、セッションが終了します。

SIP ゲートウェイから SIP ゲートウェイ:SIP リダイレクト サーバ経由のコール

図 8 に、SIP リダイレクト サーバを経由したゲートウェイからゲートウェイへの成功したコールの設定と切断を示します。このシナリオでは、エンド ユーザはユーザ A とユーザ B の 2 人です。ユーザ A は PBX A 側に位置します。PBX A は、T1/E1 によって SIP ゲートウェイ 1 に接続されています。SIP ゲートウェイ 1 は、SIP リダイレクト サーバを使用しています。ユーザ B は PBX B 側に位置します。PBX B は、T1/E1 によって SIP ゲートウェイ 2 に接続されています。ユーザ B の電話番号は 555-0100 です。SIP ゲートウェイ 1 は、IP ネットワーク経由で SIP ゲートウェイ 2 に接続されています。

コール フロー シナリオは次のとおりです。

1. ユーザ A が、SIP リダイレクト サーバを使用して SIP ゲートウェイ 1 を経由してユーザ B にコールを発信します。

2. ユーザ B がコールに応答します。

3. ユーザ B がコールを切断します。

図 8 SIP ゲートウェイから SIP ゲートウェイ:SIP リダイレクト サーバ経由のコール

 

図 8 では、次のプロセスが実行されます。

 

プロセス
説明

1. Setup:PBX A から SIP ゲートウェイ 1 へ

コール設定が PBX A と SIP ゲートウェイ 1 との間で開始されます。コール設定には、ユーザ A がユーザ B にコールを発信しようとするときに行われる標準トランザクションが含まれます。

2. INVITE:SIP ゲートウェイ 1 から SIP リダイレクト サーバへ

SIP ゲートウェイ 1 は、SIP リダイレクト サーバに INVITE 要求を送信します。INVITE 要求は、コール セッションに参加するようユーザ B に求める招待です。INVITE 要求の内容は次のとおりです。

ユーザ B の電話暗号が SIP URL の形式で Request-URI フィールドに挿入されます。SIP URL は、ユーザ B のアドレスを指定し、E メール アドレスのような形式を取ります(user@host、user は電話番号、host はドメイン(ホスト名あり、またはなし)または数値ネットワーク アドレスです)。たとえば、ユーザ B への INVITE 要求の Request-URI フィールドは「INVITE sip:555-0100@example.com; user=phone」と表示されます。「user=phone」パラメータは、Request-URI アドレスはユーザ名ではなく電話番号であることを示します。

PBX A は、コール セッションの開始側として From フィールドに指定されます。

固有の数値 ID がコールに割り当てられ、Call-ID フィールドに挿入されます。

1 つのコール レッグ内のトランザクション番号が CSeq フィールドに指定されます。

ユーザ A が受信可能なメディア機能が指定されます。

SIP ゲートウェイ 1 が RTP データを受信できるポートが指定されます。

3. 300 Multiple Choice:SIP リダイレクト サーバから SIP ゲートウェイ 1 へ

SIP リダイレクト サーバは、SIP ゲートウェイ 1 に 300 Multiple Choice 応答を送信します。300 Multiple Choice 応答は、SIP リダイレクト サーバが INVITE 要求を受け入れたこと、ユーザ B の SIP URL の全部または一部でロケーション サーバに接続したこと、およびユーザ B を見つけられる可能性がある代替位置のリストをロケーション サーバが提供したことを示します。SIP リダイレクト サーバは、SIP ゲートウェイ 1 に 300 Multiple Choice 応答でこれらの可能性のあるアドレスを返します。

4. ACK:SIP ゲートウェイ 1 から SIP リダイレクト サーバへ

SIP ゲートウェイ 1 は、ACK で 300 Multiple Choice 応答を受信したという確認応答を行います。

5. INVITE:SIP ゲートウェイ 1 から SIP ゲートウェイ 2 へ

SIP ゲートウェイ 1 は、SIP ゲートウェイ 2 に新しい INVITE 要求を送信します。新しい INVITE 要求には、300 Multiple Choice 応答に一覧表示されている最初のコンタクトがユーザ B の新しいアドレスとして含まれ、CSeq フィールドに上位トランザクション番号が示され、最初の INVITE 要求と同じ Call-ID が含まれます。

6. Setup:SIP ゲートウェイ 2 から PBX B へ

SIP ゲートウェイ 2 は、SIP ゲートウェイ 1 から INVITE 要求を受信し、PBX B を経由してユーザ B とのコール設定を開始します。

7. Call Proceeding:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Call Proceeding メッセージを送信し、コール設定要求を受信したという確認応答を行います。

8. 100 Trying:SIP ゲートウェイ 2 から SIP ゲートウェイ 1 へ

SIP ゲートウェイ 2 は、SIP ゲートウェイ 1 から送信された INVITE 要求に対して 100 Trying 応答を送信します。100 Trying 応答は、INVITE 要求が SIP ゲートウェイ 2 によって受信されたがユーザ B の場所がまだ特定されていないことを示します。

9. Call Proceeding:PBX B から SIP ゲートウェイ 2 へ

PBX B は、SIP ゲートウェイ 2 に Call Proceeding メッセージを送信し、コール設定要求を受信したという確認応答を行います。

10. Alerting:PBX B から SIP ゲートウェイ 2 へ

PBX B は、ユーザ B の位置を特定し、SIP ゲートウェイ 2 に Alert メッセージを送信します。ユーザ B の電話機の呼び出し音が鳴り始めます。

11. 180 Ringing:SIP ゲートウェイ 2 から SIP ゲートウェイ 1 へ

SIP ゲートウェイ 2 は、SIP ゲートウェイ 1 に 180 Ringing 応答を送信します。180 Ringing 応答は、SIP ゲートウェイ 2 がユーザ B の位置を特定し、ユーザ B にアラートを通知しようとしていることを示します。

12. Alerting:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Alert メッセージを送信します。ユーザ A にはリングバック トーンが聞こえます。

この時点で、SIP ゲートウェイ 1 と PBX A の間、および SIP ゲートウェイ 2 と PBX B の間に単方向の音声パスが確立します。SIP ゲートウェイ 1 と SIP ゲートウェイ 2 の間には双方向 RTP チャネルが確立します。

13. Connect:PBX B から SIP ゲートウェイ 2 へ

ユーザ B が電話に応答します。PBX B は、SIP ゲートウェイ 2 に Connect メッセージを送信します。Connect メッセージは、接続が確立したことを SIP ゲートウェイ 2 に通知します。

14. 200 OK:SIP ゲートウェイ 2 から SIP ゲートウェイ 1 へ

SIP ゲートウェイ 2 は、SIP ゲートウェイ 1 に 200 OK 応答を送信します。200 OK 応答は、接続が確立したことを SIP ゲートウェイ 1 に通知します。

ユーザ B が SIP ゲートウェイ 1 から送信された INVITE メッセージでアドバタイズされたメディア機能をサポートしている場合、ユーザ B はユーザ B 自身とユーザ A のメディア機能の共通部分を 200 OK 応答でアドバタイズします。ユーザ B がユーザ A によってアドバタイズされたメディア機能をサポートしていない場合、ユーザ B は 304 Warning ヘッダー フィールドを持つ 400 Bad Request 応答を返信します。

15. Connect:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Connect メッセージを送信します。Connect メッセージは、接続が確立したことを PBX A に通知します。

16. Connect ACK:PBX A から SIP ゲートウェイ 1 へ

PBX A は、SIP ゲートウェイ 1 の Connect メッセージを受信したという確認応答を行います。

17. ACK:SIP ゲートウェイ 1 から SIP ゲートウェイ 2 へ

SIP ゲートウェイ 1 は、SIP ゲートウェイ 2 に ACK を送信します。ACK は、200 OK 応答が受信されたことを確認します。

これで、コールは RTP を介した双方向の音声パスで進行中です。

18. Connect ACK:SIP ゲートウェイ 2 から PBX B へ

SIP ゲートウェイ 2 は、PBX B の Connect メッセージを受信したという確認応答を行います。

この時点で、SIP ゲートウェイ 1 と PBX A の間、および SIP ゲートウェイ 2 と PBX B の間に双方向音声パスが確立します。SIP ゲートウェイ 1 と SIP ゲートウェイ 2 の間には双方向 RTP チャネルが確立します。

19. Disconnect:PBX B から SIP ゲートウェイ 2 へ

ユーザ B がコールを切断すると、PBX B は SIP ゲートウェイ 2 に Disconnect メッセージを送信します。Disconnect メッセージは、コール セッション終了プロセスを開始します。

20. BYE:SIP ゲートウェイ 2 から SIP ゲートウェイ 1 へ

SIP ゲートウェイ 2 は、SIP ゲートウェイ 1 に BYE 要求を送信します。BYE 要求は、ユーザ B がコールを解放しようとしていることを示します。コールを終了しようとしているのがユーザ B であるため、Request-URI フィールドは PBX A の SIP URL に置き換えられ、From フィールドにユーザ B の SIP URL が含まれます。

21. Disconnect:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Disconnect メッセージを送信します。

22. Release:SIP ゲートウェイ 2 から PBX B へ

SIP ゲートウェイ 2 は、PBX B に Release メッセージを送信します。

23. Release:PBX A から SIP ゲートウェイ 1 へ

PBX A は、SIP ゲートウェイ 1 に Release メッセージを送信します。

24. 200 OK:SIP ゲートウェイ 1 から SIP ゲートウェイ 2 へ

SIP ゲートウェイ 1 は、SIP ゲートウェイ 2 に 200 OK 応答を送信します。200 OK 応答は、SIP ゲートウェイ 1 が BYE 要求を受信したことを SIP ゲートウェイ 2 に通知します。

25. Release Complete:PBX B から SIP ゲートウェイ 2 へ

PBX B は、SIP ゲートウェイ 2 に Release Complete メッセージを送信します。

26. Release Complete:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 が PBX A に Release Complete メッセージを送信すると、セッションが終了します。

SIP ゲートウェイから SIP ゲートウェイ:SIP プロキシ サーバ経由のコール

図 9 および 図 10 に、プロキシ サーバを経由したゲートウェイからゲートウェイへの成功したコールの設定と切断を示します。エンド ユーザはユーザ A とユーザ B の 2 人です。ユーザ A は PBX A 側に位置し、PBX A は T1/E1 によって SIP ゲートウェイ 1 に接続されています。SIP ゲートウェイ 1 はプロキシ サーバを使用しています。SIP ゲートウェイ 1 は、IP ネットワーク経由で SIP ゲートウェイ 2 に接続されています。ユーザ B は PBX B 側に位置し、BX B は T1/E1 によって SIP ゲートウェイ 2(SIP ゲートウェイ)に接続されています。ユーザ B の電話番号は 555-0100 です。


) プロキシ サーバは要求に Record-Route ヘッダー フィールドを挿入して、ダイアログ内の今後の要求がプロキシを経由してルーティングされるようにします。


図 9 では、プロキシ サーバ上でレコード ルート機能がイネーブルに設定されています。図 10 では、プロキシ サーバ上でレコード ルート機能がディセーブルに設定されています。

レコード ルートがイネーブルの場合、プロキシ サーバは Record-Route ヘッダーを SIP メッセージに追加し、同じコール レッグに対する以後の SIP 要求のパス内にあることを保証します。Record-Route フィールドには、プロキシ サーバを指定する、グローバルに到達可能な Request-URI が含まれます。レコード ルートがイネーブルの場合、各プロキシ サーバは Request-URI をリストの先頭に追加します。

レコード ルートがディセーブルの場合、コールが確立されると SIP メッセージは直接 SIP ゲートウェイを通過します。

コール フローは次のとおりです。

1. ユーザ A が、プロキシ サーバを使用して SIP ゲートウェイ 1 を経由してユーザ B にコールを発信します。

2. ユーザ B がコールに応答します。

3. ユーザ B がコールを切断します。

図 9 SIP ゲートウェイから SIP ゲートウェイ:レコード ルートがイネーブルのプロキシ サーバ経由のコール

 

図 9 では、次のプロセスが実行されます。

 

プロセス
説明

1. Setup:PBX A から SIP ゲートウェイ 1 へ

コール設定が PBX A と SIP ゲートウェイ 1 との間で開始されます。コール設定には、ユーザ A がユーザ B にコールを発信しようとするときに行われる標準トランザクションが含まれます。

2. INVITE:SIP ゲートウェイ 1 からプロキシ サーバへ

SIP ゲートウェイ 1 は、SIP プロキシ サーバに INVITE 要求を送信します。INVITE 要求は、コール セッションに参加するようユーザ B に求める招待です。

INVITE 要求の内容は次のとおりです。

ユーザ B の電話暗号が SIP URL の形式で Request-URI フィールドに挿入されます。SIP URL は、ユーザ B のアドレスを指定し、E メール アドレスのような形式を取ります(user@host、user は電話番号、host はドメイン(ホスト名あり、またはなし)または数値ネットワーク アドレスです)。たとえば、ユーザ B への INVITE 要求の Request-URI フィールドは「INVITE sip:555-0100@example.com; user=phone」と表示されます。「user=phone」パラメータは、Request-URI アドレスはユーザ名ではなく電話番号であることを示します。

PBX A は、コール セッションの開始側として From フィールドに指定されます。

固有の数値 ID がコールに割り当てられ、Call-ID フィールドに挿入されます。

1 つのコール レッグ内のトランザクション番号が CSeq フィールドに指定されます。

ユーザ A が受信可能なメディア機能が指定されます。

SIP ゲートウェイ 1 が RTP データを受信できるポートが指定されます。

3. Call Proceeding:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Call Proceeding メッセージを送信し、コール設定要求を受信したという確認応答を行います。

4. INVITE:SIP プロキシ サーバから SIP ゲートウェイ 2 へ

SIP プロキシ サーバは、自身のアドレスが Via フィールドに含まれているかを確認し(ループを防止するため)、SIP ゲートウェイ 1 から受信した要求から To、From、Call-ID、および Contact フィールドを直接コピーします。次に Request-URI を変更して INVITE 要求の送信先であるサーバを指定し、SIP ゲートウェイ 2 に新しい INVITE 要求を送信します。

5. 100 Trying:SIP プロキシ サーバから SIP ゲートウェイ 1 へ

SIP プロキシ サーバ は、SIP ゲートウェイ 1 に 100 Trying 応答を送信します。

6. Setup:SIP ゲートウェイ 2 から PBX B へ

SIP ゲートウェイ 2 は SIP プロキシ サーバから INVITE 要求を受信し、PBX B を経由してユーザ B とのコール設定を開始します。

7. 100 Trying:SIP ゲートウェイ 2 から SIP プロキシ サーバへ

SIP ゲートウェイ 2 は、SIP プロキシ サーバに 100 Trying 応答を送信します。SIP プロキシ サーバは、SIP ゲートウェイ 1 に 100 Trying 応答を転送する場合と転送しない場合があります。

8. Call Proceeding:PBX B から SIP ゲートウェイ 2 へ

PBX B は、SIP ゲートウェイ 2 に Call Proceeding メッセージを送信し、コール設定要求を受信したという確認応答を行います。

9. Alerting:PBX B から SIP ゲートウェイ 2 へ

PBX B は、ユーザ B の位置を特定し、SIP ゲートウェイ 2 に Alert メッセージを送信します。ユーザ B の電話機の呼び出し音が鳴り始めます。

10. 180 Ringing:SIP ゲートウェイ 2 から SIP プロキシ サーバへ

SIP ゲートウェイ 2 は、SIP プロキシ サーバに 180 Ringing 応答を送信します。

11. 180 Ringing:SIP プロキシ サーバから SIP ゲートウェイ 1 へ

SIP プロキシ サーバは、SIP ゲートウェイ 1 に 180 Ringing 応答を転送します。

12. Alerting:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A を経由してユーザ A に Alert メッセージを送信します。Alert メッセージは、SIP ゲートウェイ 1 が 180 Ringing 応答を受信したことを示します。ユーザ A には、ユーザ B にアラートが通知されたことを示すリングバック トーンが聞こえます。

この時点で、SIP ゲートウェイ 1 と PBX A の間、および SIP ゲートウェイ 2 と PBX B の間に単方向音声パスが確立します。SIP ゲートウェイ 1 と SIP ゲートウェイ 2 の間には双方向 RTP チャネルが確立します。

13. Connect:PBX B から SIP ゲートウェイ 2 へ

ユーザ B が電話に応答します。PBX B は、SIP ゲートウェイ 2 に Connect メッセージを送信します。Connect メッセージは、接続が確立したことを SIP ゲートウェイ 2 に通知します。

14. 200 OK:SIP ゲートウェイ 2 から SIP プロキシ サーバへ

SIP ゲートウェイ 2 は、SIP プロキシ サーバに 200 OK 応答(INVITE で受信した Record-Route ヘッダーを含む)を送信します。200 OK 応答は、接続が確立したことを SIP プロキシ サーバに通知します。

ユーザ B が SIP プロキシ サーバから送信された INVITE メッセージでアドバタイズされたメディア機能をサポートしている場合、ユーザ B はユーザ B 自身とユーザ A のメディア機能の共通部分を 200 OK 応答でアドバタイズします。ユーザ B がユーザ A によってアドバタイズされたメディア機能をサポートしていない場合、ユーザ B は 304 Warning ヘッダー フィールドを持つ 400 Bad Request 応答を返信します。

SIP プロキシ サーバは、200 OK 応答をアップストリームに転送する必要があります。

15. 200 OK:SIP プロキシ サーバから SIP ゲートウェイ 1 へ

SIP プロキシ サーバは、SIP ゲートウェイ 2 から受信した 200 OK 応答を SIP ゲートウェイ 1 に転送します。200 OK 応答では、SIP プロキシ サーバは Record-Route ヘッダーを転送し、同じコール レッグに対する以後の SIP 要求のパス内にあることを保証します。SIP プロキシ サーバは、Record-Route フィールドに Request-URI を追加します。

16. Connect:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Connect メッセージを送信します。Connect メッセージは、接続が確立したことを PBX A に通知します。

17. Connect ACK:PBX A から SIP ゲートウェイ 1 へ

PBX A は、SIP ゲートウェイ 1 の Connect メッセージを受信したという確認応答を行います。

18. ACK:SIP ゲートウェイ 1 から SIP プロキシ サーバへ

SIP ゲートウェイ 1 は、SIP プロキシ サーバに ACK を送信します。ACK は、SIP ゲートウェイ 1 が SIP プロキシ サーバから 200 OK 応答を受信したことを確認します。

19. ACK:SIP プロキシ サーバから SIP ゲートウェイ 2 へ

To、From、CSeq、および Call-ID フィールドの値に応じて、SIP プロキシ サーバは ACK をローカルで処理するか、プロキシする場合があります。ACK 内のフィールドが SIP プロキシ サーバで処理された以前の要求内のフィールドと一致する場合、サーバは ACK をプロキシします。一致しない場合、ACK は、INVITE 要求のようにプロキシされます。

SIP プロキシ サーバは、SIP ゲートウェイ 2 に SIP ゲートウェイ 1 の ACK 応答を転送します。

20. Connect ACK:SIP ゲートウェイ 2 から PBX B へ

SIP ゲートウェイ 2 は、PBX B の Connect メッセージを受信したという確認応答を行います。これで、コール セッションがアクティブになります。

SIP ゲートウェイ 1 と SIP ゲートウェイ 2 の間に、プロキシ サーバを経由せずに直接双方向音声パスが確立します。

この時点で、SIP ゲートウェイ 1 と PBX A の間、および SIP ゲートウェイ 2 と PBX B の間に双方向音声パスが確立します。SIP ゲートウェイ 1 と SIP ゲートウェイ 2 の間には双方向 RTP チャネルが確立します。

21. Disconnect:PBX B から SIP ゲートウェイ 2 へ

コールの完了後、PBX B は SIP ゲートウェイ 2 に Disconnect メッセージを送信します。Disconnect メッセージは、コール セッション終了プロセスを開始します。

22. BYE:SIP ゲートウェイ 2 から SIP プロキシ サーバへ

SIP ゲートウェイ 2 は、SIP プロキシ サーバに BYE 要求を送信します。BYE 要求は、ユーザ B がコールを解放しようとしていることを示します。コールを終了しようとしているのがユーザ B であるため、Request-URI フィールドは PBX A の SIP URL に置き換えられ、From フィールドにユーザ B の SIP URL が含まれます。

23. BYE:SIP プロキシ サーバから SIP ゲートウェイ 1 へ

SIP プロキシ サーバは、SIP ゲートウェイ 1 に BYE 要求を転送します。

24. Disconnect:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Disconnect メッセージを送信します。

25. Release:SIP ゲートウェイ 2 から PBX B へ

コールの完了後、SIP ゲートウェイ 2 は PBX B に Release メッセージを送信します。

26. Release:PBX A から SIP ゲートウェイ 1 へ

PBX A は、SIP ゲートウェイ 1 に Release メッセージを送信します。

27. 200 OK:SIP ゲートウェイ 1 から SIP プロキシ サーバへ

SIP ゲートウェイ 1 は、SIP プロキシ サーバに 200 OK 応答を送信します。200 OK 応答は、SIP ゲートウェイ 1 が BYE 要求を受信したことを SIP ゲートウェイ 2 に通知します。

28. 200 OK:SIP プロキシ サーバ から SIP v へ

SIP プロキシ サーバは、SIP ゲートウェイ 2 に 200 OK 応答を転送します。

29. Release Complete:PBX B から SIP ゲートウェイ 2 へ

PBX B は、SIP ゲートウェイ 2 に Release Complete メッセージを送信します。

30. Release Complete:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 が PBX A に Release Complete メッセージを送信すると、コール セッションが終了します。

図 10 SIP ゲートウェイから SIP ゲートウェイ:レコード ルートがディセーブルのプロキシ サーバ経由のコール

 

図 10 では、次のプロセスが実行されます。

 

プロセス
説明

1. Setup:PBX A から SIP ゲートウェイ 1 へ

コール設定が PBX A と SIP ゲートウェイ 1 との間で開始されます。コール設定には、ユーザ A がユーザ B にコールを発信しようとするときに行われる標準トランザクションが含まれます。

2. INVITE:SIP ゲートウェイ 1 から SIP プロキシ サーバへ

SIP ゲートウェイ 1 は、SIP プロキシ サーバに INVITE 要求を送信します。INVITE 要求は、コール セッションに参加するようユーザ B に求める招待です。INVITE 要求の内容は次のとおりです。

ユーザ B の電話暗号が SIP URL の形式で Request-URI フィールドに挿入されます。SIP URL は、ユーザ B のアドレスを指定し、E メール アドレスのような形式を取ります(user@host、user は電話番号、host はドメイン(ホスト名あり、またはなし)または数値ネットワーク アドレスです)。たとえば、ユーザ B への INVITE 要求の Request-URI フィールドは「INVITE sip:555-0100@example.com; user=phone」と表示されます。「user=phone」パラメータは、Request-URI アドレスはユーザ名ではなく電話番号であることを示します。

PBX A は、コール セッションの開始側として From フィールドに指定されます。

固有の数値 ID がコールに割り当てられ、Call-ID フィールドに挿入されます。

1 つのコール レッグ内のトランザクション番号が CSeq フィールドに指定されます。

ユーザ A が受信可能なメディア機能が指定されます。

SIP ゲートウェイ 1 が RTP データを受信できるポートが指定されます。

3. Call Proceeding:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Call Proceeding メッセージを送信し、コール設定要求を受信したという確認応答を行います。

4. INVITE:SIP プロキシ サーバから SIP ゲートウェイ 2 へ

SIP プロキシ サーバは、自身のアドレスが Via フィールドに含まれているかを確認し(ループを防止するため)、SIP ゲートウェイ 1 から受信した要求から To、From、Call-ID、および Contact フィールドを直接コピーします。次に Request-URI を変更して INVITE 要求の送信先であるサーバを指定し、SIP ゲートウェイ 2 に新しい INVITE 要求を送信します。

5. 100 Trying:SIP プロキシ サーバから SIP ゲートウェイ 1 へ

SIP プロキシ サーバ は、SIP ゲートウェイ 1 に 100 Trying 応答を送信します。

6. Setup:SIP ゲートウェイ 2 から PBX B へ

SIP ゲートウェイ 2 は SIP プロキシ サーバから INVITE 要求を受信し、PBX B を経由してユーザ B とのコール設定を開始します。

7. 100 Trying:SIP ゲートウェイ 2 から SIP プロキシ サーバへ

SIP ゲートウェイ 2 は、SIP プロキシ サーバに 100 Trying 応答を送信します。SIP プロキシ サーバは、SIP ゲートウェイ 1 に 100 Trying 応答を転送する場合と転送しない場合があります。

8. Call Proceeding:PBX B から SIP ゲートウェイ 2 へ

PBX B は、SIP ゲートウェイ 2 に Call Proceeding メッセージを送信し、コール設定要求を受信したという確認応答を行います。

9. Alerting:PBX B から SIP ゲートウェイ 2 へ

PBX B は、ユーザ B の位置を特定し、SIP ゲートウェイ 2 に Alert メッセージを送信します。ユーザ B の電話機の呼び出し音が鳴り始めます。

10. 180 Ringing:SIP ゲートウェイ 2 から SIP プロキシ サーバへ

SIP ゲートウェイ 2 は、SIP プロキシ サーバに 180 Ringing 応答を送信します。

11. 180 Ringing:SIP プロキシ サーバから SIP ゲートウェイ 1 へ

SIP プロキシ サーバは、SIP ゲートウェイ 1 に 180 Ringing 応答を転送します。

12. Alerting:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A を経由してユーザ A に Alert メッセージを送信します。Alert メッセージは、SIP ゲートウェイ 1 が 180 Ringing 応答を受信したことを示します。ユーザ A には、ユーザ B にアラートが通知されたことを示すリングバック トーンが聞こえます。

この時点で、SIP ゲートウェイ 1 と PBX A の間、および SIP ゲートウェイ 2 と PBX B の間に単方向音声パスが確立します。SIP ゲートウェイ 1 と SIP ゲートウェイ 2 の間には双方向 RTP チャネルが確立します。

13. Connect:PBX B から SIP ゲートウェイ 2 へ

ユーザ B が電話に応答します。PBX B は、SIP ゲートウェイ 2 に Connect メッセージを送信します。Connect メッセージは、接続が確立したことを SIP ゲートウェイ 2 に通知します。

14. 200 OK:SIP ゲートウェイ 2 から SIP プロキシ サーバへ

SIP ゲートウェイ 2 は、SIP プロキシ サーバに 200 OK 応答を送信します。200 OK 応答は、接続が確立したことを SIP プロキシ サーバに通知します。

ユーザ B が SIP プロキシ サーバから送信された INVITE メッセージでアドバタイズされたメディア機能をサポートしている場合、ユーザ B はユーザ B 自身とユーザ A のメディア機能の共通部分を 200 OK 応答でアドバタイズします。ユーザ B がユーザ A によってアドバタイズされたメディア機能をサポートしていない場合、ユーザ B は 304 Warning ヘッダー フィールドを持つ 400 Bad Request 応答を返信します。

SIP プロキシ サーバは、200 OK 応答をアップストリームに転送する必要があります。

15. 200 OK:SIP プロキシ サーバから SIP ゲートウェイ 1 へ

SIP プロキシ サーバは、SIP ゲートウェイ 2 から受信した 200 OK 応答を SIP ゲートウェイ 1 に転送します。

16. Connect:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Connect メッセージを送信します。Connect メッセージは、接続が確立したことを PBX A に通知します。

17. Connect ACK:PBX A から SIP ゲートウェイ 1 へ

PBX A は、SIP ゲートウェイ 1 の Connect メッセージを受信したという確認応答を行います。

18. ACK:SIP ゲートウェイ 1 から SIP ゲートウェイ 2 へ

SIP ゲートウェイ 1 は、SIP ゲートウェイ 2 に ACK を送信します。ACK は、SIP ゲートウェイ 1 が SIP プロキシ サーバから 200 OK 応答を受信したことを確認します。

19. Connect ACK:SIP ゲートウェイ 2 から PBX B へ

SIP ゲートウェイ 2 は、PBX B の Connect メッセージを受信したという確認応答を行います。これで、コール セッションがアクティブになります。

SIP ゲートウェイ 1 と SIP ゲートウェイ 2 の間に、プロキシ サーバを経由せずに直接双方向音声パスが確立します。

この時点で、SIP ゲートウェイ 1 と PBX A の間、および SIP ゲートウェイ 2 と PBX B の間に双方向音声パスが確立します。SIP ゲートウェイ 1 と SIP ゲートウェイ 2 の間には双方向 RTP チャネルが確立します。

20. Disconnect:PBX B から SIP ゲートウェイ 2 へ

コールの完了後、PBX B は SIP ゲートウェイ 2 に Disconnect メッセージを送信します。Disconnect メッセージは、コール セッション終了プロセスを開始します。

21. BYE:SIP ゲートウェイ 2 から SIP ゲートウェイ 1 へ

SIP ゲートウェイ 2 は、SIP ゲートウェイ 1 に BYE 要求を送信します。BYE 要求は、ユーザ B がコールを解放しようとしていることを示します。コールを終了しようとしているのがユーザ B であるため、Request-URI フィールドは PBX A の SIP URL に置き換えられ、From フィールドにユーザ B の SIP URL が含まれます。

22. Disconnect:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 は、PBX A に Disconnect メッセージを送信します。

23. Release:SIP ゲートウェイ 2 から PBX B へ

コールの完了後、SIP ゲートウェイ 2 は PBX B に Release メッセージを送信します。

24. Release:PBX A から SIP ゲートウェイ 1 へ

PBX A は、SIP ゲートウェイ 1 に Release メッセージを送信します。

25. 200 OK:SIP ゲートウェイ 1 から SIP ゲートウェイ 2 へ

SIP ゲートウェイ 1 は、SIP ゲートウェイ 2 に 200 OK 応答を送信します。200 OK 応答は、SIP ゲートウェイ 1 が BYE 要求を受信したことを SIP ゲートウェイ 2 に通知します。

26. Release Complete:PBX B から SIP ゲートウェイ 2 へ

PBX B は、SIP ゲートウェイ 2 に Release Complete メッセージを送信します。

27. Release Complete:SIP ゲートウェイ 1 から PBX A へ

SIP ゲートウェイ 1 が PBX A に Release Complete メッセージを送信すると、コール セッションが終了します。

 

その他の参考資料

ここでは、SIP に関する関連資料について説明します。


) • 次に示す関連資料のほかに、各章に SIP に関する追加関連資料が示されています。

このマニュアルに記載されている製品やサービスの中には、生産や販売が終了しているものもあります。詳細については、 http://www.cisco.com/en/US/products/prod_end_of_life.html を参照してください。


 

関連資料

関連項目
参照先

ルータの基本設定

Cisco 2600 シリーズのドキュメント( http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis2600/index.htm

Cisco 3600 シリーズのドキュメント( http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3600/index.htm

Cisco 3700 シリーズのドキュメント( http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3700/index.htm

Cisco AS5300 のドキュメント( http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/index.htm

Cisco IOS コマンド リファレンス

Cisco IOS Debug Command Reference 』(リリース 12.3T)( http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/123dbr/index.htm

Cisco IOS Voice Command Reference 』(リリース 12.3T)( http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/123tvr/index.htm

Cisco IOS の設定の基礎と例

Cisco IOS Configuration Fundamentals Configuration Guide 』( http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/

Cisco IOS Interface Command Reference 』( http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/finter_r/index.htm

Cisco IOS Interface Configuration Guide 』( http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/finter_c/

Cisco IOS Voice, Video, and Fax Configuration Guide 』(リリース 12.2)( http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fvvfax_c/index.htm

Cisco Systems Technologies Web サイト( http://cisco.com/en/US/tech/index.html

この Web サイトで、テクノロジー カテゴリおよび後続のサブカテゴリ階層を選択し、[Technical Documentation] > [Configuration Examples] をクリックします。

『Cisco IOS Voice Configuration Library』(ライブラリの序文および用語集を含む)

Cisco IOS Voice Configuration Library 』( http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/cisco_ios_voice_configuration_library_glossary/vcl.htm

開発者サポート

『Developer Support Agreement』( http://www.cisco.com/go/developersupport

IVR スクリプト情報

TCL IVR API 2.0 Programming Guide 』( http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/tclivrv2/index.htm

NAT の設定

Configuring Network Address Translation: Getting Started 』( http://www.cisco.com/warp/public/556/12.htm)

SIP のマニュアル

Cisco SIP プロキシ サーバのドキュメント( http://www.cisco.com/univercd/cc/td/doc/product/voice/sipproxy/index.htm

Guide to Cisco Systems' VoIP Infrastructure Solution for SIP 』( http://www.cisco.com/univercd/cc/td/doc/product/voice/sipsols/biggulp/index.htm

Session Initiation Protocol Gateway Call Flows 』( http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/rel_docs/sip_flo/index.htm

音声ゲートウェイの SS7

Configuring Media Gateways for the SS7 Interconnect for Voice Gateways Solution』( http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/das22/gateway/dascfg5.htm

Tcl IVR プログラミング

Tcl IVR API Version 2.0 Programmer's Guide』( http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/tclivrv2/index.htm

トラブルシューティング

Cisco IOS Debug Command Reference 』(リリース 12.3T)( http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/123dbr/index.htm

Cisco IOS Voice Troubleshooting and Monitoring Guide 』( http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/voipt_c/index.htm

Internetwork Troubleshooting Guide』( http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/index.htm

Troubleshooting and Debugging VoIP Call Basics 』( http://www.cisco.com/warp/public/788/voip/voip_debugcalls.html

Voice over IP Troubleshooting and Monitoring 』( http://cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/voipt_c/index.htm

VoIP Debug Commands 』( http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/1700/1750/1750voip/debug.htm

Voice over ATM(VoATM)の設定

Configuring AAL2 and AAL5 for the High-Performance Advanced Integration Module on the Cisco 2600 Series』( http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xa/122xa_2/ft_ataim.htm

VoIP の設定

Voice over IP for the Cisco 2600/3600 Series』( http://www.cisco.com/univercd/cc/td/doc/product/access/nubuvoip/voip3600/index.htm)

Voice over IP for the Cisco AS5300』( http://www.cisco.com/univercd/cc/td/doc/product/access/nubuvoip/voip5300/index.htm

Voice over IP for the Cisco AS5800』( http://www.cisco.com/univercd/cc/td/doc/product/access/nubuvoip/voip5800/index.htm

VSA 情報

RADIUS Vendor-Specific Attributes Voice Implementation Guide 』( http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/vsaig3.htm

WAN の設定

Cisco IOS Wide-Area Networking Command Reference』( http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_r/index.htm

Cisco IOS Wide-Area Networking Configuration Guide』( http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_c/wcfatm.htm

その他のマニュアル

Cisco Internetworking Terms and Acronyms 』( http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/

Cisco Resource Policy Management System 2.0 』( http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/rpms/rpms_2-0/

VoIP Call Admission Control 』( http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/cac.htm

規格

規格1
タイトル

ANSI TI.619/a

ISDN Multi-Level Precedence and Preemption (MLPP) Service Capability

draft-ietf-avt-profile-new-12.txt

RTP Profile for Audio and Video Conferences with Minimal Control

draft-ietf-avt-rtp-cn-06.txt

RTP Payload for Comfort Noise , Internet Draft of the Internet Engineering Task Force (IETF) Audio/Video Transport (AVT) working group」

draft-ietf-avt-rtp-mime-06.txt

MIME Type Registration of RTP Payload Formats

draft-ietf-mmusic-sdp-comedia-04.txt

Connection-Oriented Media Transport in SDP

draft-ietf-sipping-reason-header-for-preemption-00

Extending the SIP for Preemption Events

draft-ietf-sip-privacy-02

SIP Extensions for Caller Identity and Privacy

draft-ietf-sip-resource-priority-05

Communications Resources Priority for SIP

draft-levy-diversion-06.txt

「[Sip] verification of diversion header (draft-levy)」

GR-268-CORE

ISDN Basic Rate Interface Call Control Switching and Signalling Generic Requirements

1.サポートされている規格がすべて記載されているわけではありません。

MIB

MIB
MIB リンク

CISCO-SIP-UA-MIB

選択したプラットフォーム、Cisco IOS リリース、および機能セットの MIB を検索してダウンロードする場合は、次の URL にある Cisco MIB Locator を使用します。

http://www.cisco.com/go/mibs

RFC

RFC2
タイトル

RFC 1889
(2003 年 7 月に RFC 3550 によって廃止)

RTP: A Transport Protocol for Real-Time Applications

RFC 2052
(2000 年 2 月に RFC 2782 によって廃止)

A DNS RR for Specifying location of services (DNS SRV)

RFC 2543(および RFC 2543-bis-04)
(2002 年 6 月に RFC 3261、3262、3263、3264、および 3265 によって廃止)

SIP: Session Initiation Protocol

RFC 2617

HTTP Authentication: Basic and Digest Access Authentication

RFC 2782
(2000 年 2 月に RFC 2052 を置き換え)

A DNS RR for specifying the location of services (DNS SRV)

RFC 2806

URLs for Telephone Calls

RFC 2833
(2006 年 12 月に RFC 4733 および 4734 によって廃止)

RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

RFC 2976

SIP INFO Method

RFC 3261
(2002 年 6 月に RFC 2543 を置き換え、2004 年 7 月に RFC 3853 に更新、2006 年 1 月に RFC 4320 に更新)

SIP: Session Initiation Protocol

RFC 3262
(2002 年 6 月に RFC 2543 を置き換え)

Reliability of Provisional Responses in Session Initiation Protocol (SIP)

RFC 3263
(2002 年 6 月に RFC 2543 を置き換え)

Session Initiation Protocol (SIP): Locating SIP Servers

RFC 3264
(2002 年 6 月に RFC 2543 を置き換え)

An Offer/Answer Model with Session Description Protocol (SDP)

RFC 3265
(2002 年 6 月に RFC 2543 を置き換え)

Session Initiation Protocol (SIP)-Specific Event Notification

RFC 3311

The Session Initiation Protocol (SIP) UPDATE Method

RFC 3312
(2005 年 3 月に RFC 4032 に更新)

Integration of Resource Management and Session Initiation Protocol (SIP)

RFC 3326

The Reason Header Field for the Session Initiation Protocol

RFC 3420

Internet Media Type message/sipfrag

RFC 3515

The Session Initiation Protocol (SIP) Refer Method

RFC 3550
(2003 年 7 月に RFC 1889 を置き換え)

RTP: A Transport Protocol for Real-Time Applications

RFC 3853
(2004 年 7 月に RFC 3261 を更新)

S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)

RFC 4032
(2005 年 3 月に RFC 3312 を更新)

Update to the Session Initiation Protocol (SIP) Preconditions Framework

RFC 4320
(2004 年 7 月に RFC 3261 を更新)

Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction

RFC 4733
(2006 年 12 月に RFC 2833 を置き換え、RFC 4734 に更新)

RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals

RFC 4734
(2006 年 12 月に RFC 2833 を置き換え、RFC 4733 を更新)

Definition of Events for Modem, Fax, and Text Telephony Signals

2.サポートされている RFC がすべて記載されているわけではありません。

シスコのテクニカル サポート

説明
リンク

シスコのテクニカル サポート Web サイトでは、製品、テクノロジー、ソリューション、テクニカル ティップス、ツールへのリンクなど、技術的なコンテンツを検索可能な形で大量に提供しています。Cisco.com 登録ユーザの場合は、次のページからログインしてさらに多くのコンテンツにアクセスできます。

http://www.cisco.com/techsupport