Comments
Description
Transcript
SIP の RFC 準拠の実現
SIP の RFC 準拠の実現 この章では、公開されている Session Initiation Protocol（SIP）基準に準拠するための、Cisco IOS SIP ゲートウェイの使用方法または設定方法を説明します。次の機能について説明します。 • RFC 4040 ベースの SIP コール用クリア チャネル コーデック ネゴシエーション • SIP：Core SIP Technology Enhancements （RFC 2543 および RFC 2543-bis-04 ） • SIP：DNS SRV RFC 2782 Compliance（RFC 2782） • SIP：RFC 3261 Enhancements（RFC 3261） • RFC 3261、RFC 3262、および RFC 3264 に対する SIP ゲートウェイの準拠 • SIP スタック ポータビリティ （注） この機能については、次の URL の「Configuring SIP Message, Timer, and Response Features」の章を参照してください。 http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/sip_cg-msg_tmr_rspns.h tml RFC 4040 ベースの SIP コール用クリア チャネル コーデック ネゴシエーションの機能履歴 リリース 15.0(1)XA 変更点 この機能は、Cisco IOS SIP Time Division Multiplexing（TDM; 時分割多 重）ゲートウェイおよび Cisco Unified Border Elements（Cisco UBE）で サポートされます。この機能をイネーブルにする方法の詳細については、 『Cisco IOS Voice Command Reference』 （http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_bo ok.html）の encap clear-channel standard および voice-class sip encap clear-channel コマンドの説明を参照してください。 SIP：Core SIP Technology Enhancements の機能履歴 リリース 変更点 12.2(13)T この機能は、SIP RFC 2543-bis-04（後に、RFC_3261 として発行）への準 拠を実現するために導入されました。 SIP の RFC 準拠の実現 機能情報の確認 SIP：DNS SRV RFC 2782 Compliance の機能履歴 リリース 変更点 12.2(2)XB 12.2(8)T この機能が導入されました。 この機能がこのリリースに統合されました。 SIP：RFC 3261 Enhancements の機能履歴 リリース 変更点 12.3(4)T この機能が導入されました。 RFC 3261、RFC 3262、および RFC 3264 に対する SIP ゲートウェイの準拠の機能履歴 リリース 変更点 12.3(8)T この機能が導入されました。 機能情報の確認 ご使用のソフトウェア リリースによっては、この章に記載されている機能の一部がサポートされてい ない場合があります。最新の機能情報と注意事項については、ご使用のプラットフォームとソフトウェ ア リリースに対応したリリース ノートを参照してください。 プラットフォーム サポートと Cisco IOS および Catalyst OS ソフトウェア イメージ サポートに関する 情報を入手するには、Cisco Feature Navigator を使用します。Cisco Feature Navigator には、 http://www.cisco.com/go/cfn からアクセスしてください。Cisco.com のアカウントは必要ありません。 この章の構成 • 「SIP の RFC 準拠の前提条件」（P.2） • 「SIP の RFC 準拠の制約事項」（P.3） • 「SIP の RFC 準拠に関する情報」（P.3） • 「SIP の FC 準拠の設定方法」（P.35） • 「SIP の RFC 準拠の設定例」（P.46） • 「その他の参考資料」（P.50） SIP の RFC 準拠の前提条件 • 基本的な VoIP ネットワークを設定します。 • Reliable Provisional Response 機能をイネーブルにします。 （注） 信頼できる暫定応答の詳細については、次の URL の「SIP Gateway Support of RSVP and TEL URL」の章を参照してください。 http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/vvfresrv.html 2 SIP の RFC 準拠の実現 SIP の RFC 準拠の制約事項 SIP の RFC 準拠の制約事項 • RFC 3261 に記載されているとおり、次の項目はサポートされていません。 – SIP UPDATE 要求の送信。ゲートウェイが送受信できるのは、UPDATE 要求だけです。 – IPv6 ホスト アドレスを持つ SIP。 – セキュアな SIP。セキュアな SIP は、セキュアな Uniform Resource Identifiers（URI; ユニ フォーム リソース識別子）です。発信側が SIP を使用してコールを行った場合、着信側へは セキュアなメッセージ転送が行われます。 – Unicode Transformation Format Version 8（UTF-8）で符号化された、SIP ヘッダー内で引用 された文字列のフィールド文字 0x0 to 0x7E 。 • RFC 3264 に記載されているとおり、0 と等しい bandwidth (b=) SDP アトリビュートはサポートさ れていません。 SIP の RFC 準拠に関する情報 ここでは、次の内容について説明します。 • 「SIP の RFC 2543 準拠」（P.3） • 「SIP の RFC 2782 準拠」（P.3） • 「SIP の RFC 3261 準拠」（P.3） • 「SIP の RFC 3261、RFC 3262、および RFC 3264 への準拠」（P.32） SIP の RFC 2543 準拠 Cisco SIP ゲートウェイは RFC 2543 に準拠しています。ただし現在、RFC 3261 が RFC 2543 に取っ て代わっています。新しい RFC でサポートされる項目およびサポートされない項目の詳細については、 「SIP の RFC 準拠の制約事項」（P.3）および「SIP の RFC 3261 準拠」（P.3）を参照してください。 SIP の RFC 2782 準拠 Cisco VoIP ゲートウェイの SIP は、Domain Name System Server（DNS SRV）クエリーを使用して、 ユーザのエンドポイントの IP アドレスを決定します。クエリー文字列は、RFC 2052 で定義されてい るとおり、「protocol.transport」の形式のプレフィクスを持ちます。このプレフィクスは、ネクスト ホップ SIP サーバの Fully Qualified Domain Name（FQDN; 完全修飾ドメイン名）に付きます。 Cisco VoIP ゲートウェイには、別のプレフィクス形式が追加され、現在はデフォルトになっています。 この 2 番目のプレフィクス形式は RFC 2782 で定義されたものです。この RFC 2782 により RFC 2052 は 2000 年 2 月に廃止されています。新しい形式は RFC 2782 に準拠しており、「_protocol._transport」 のようにプロトコル ラベルに下線「_」が追加されます。下線を追加することで、関連のない目的に同 じ名前のプロトコルが使用される危険性を軽減できます。 SIP の RFC 3261 準拠 廃止になった RFC 2543 に代わる RFC 3261 では、セッションを作成、変更、終了するための SIP シグナ リング プロトコルを定義しています。シスコによる RFC 3261 の実装では、次をサポートしています。 3 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 • SIP UPDATE 要求の受信および処理機能 • 最初のオファーと回答の交換 • Via ヘッダーの branch および sent-by パラメータ • 結合された要求の検出 • ルーズ ルーティング RFC 3261 の利点は次のとおりです。 • 現在の SIP 配置における Cisco IOS ゲートウェイの相互運用性の継続 • 新しい SIP 製品およびアプリケーションを使用した Cisco IOS ゲートウェイの相互運用性の拡張 ここでは、SIP の基本機能に関する次の情報について説明します。 • 「SIP ヘッダー フィールド、ネットワーク コンポーネント、および方式」（P.4） • 「SIP 応答」（P.7） • 「SIP SDP の使用方法、トランスポート レイヤ プロトコル、および DNS レコード」（P.12） • 「SIP 拡張機能」（P.12） • 「SIP セキュリティ」（P.13） • 「SIP DTMF リレー」（P.14） • 「SIP ファックス リレーおよび T.38」（P.14） • 「SIP ユニフォーム リソース ロケータ（URL）の比較」（P.16） • 「487 Sent for BYE 要求」（P.17） • 「3xx リダイレクション応答」（P.17） • 「DNS SRV クエリー手順」（P.17） • 「CANCEL Request Route ヘッダー」（P.17） • 「ユーザ パラメータの解釈」（P.17） • 「user=phone パラメータ」（P.17） • 「SIP 原因コード 303 および 411」（P.18） • 「Content-Type ヘッダーの柔軟性」（P.18） • 「SDP のオプションの「s=」行」（P.18） • 「INVITE および 2xx 応答への Allow ヘッダーの追加」（P.18） • 「Cancel および 2xx クラス応答の同時実行」（P.18） • 「UPDATE 要求の処理」（P.18） SIP ヘッダー フィールド、ネットワーク コンポーネント、および方式 表 1 ～表 3 に、ヘッダー、コンポーネント、および方式を含む RFC 3261 SIP の機能を示します。ま た、Cisco SIP ゲートウェイがサポートする特定の機能がある場合はその機能も示します。 表 1 4 SIP ヘッダー フィールド ヘッダー フィールド シスコ ゲートウェイによるサポートの有無 Accept あり。OPTIONS 応答メッセージで使用。 Accept-Encoding なし SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 1 SIP ヘッダー フィールド （続き） ヘッダー フィールド シスコ ゲートウェイによるサポートの有無 Accept-Language あり Alert-Info なし Allow あり Also Authentication-Info なし Authorization Call-ID あり Call-Info なし CC-Diversion / Diversion あり Contact Content-Disposition Content-Encoding なし Content-Encoding あり Content-Language なし Content-Length あり Content-Type Cseq Date Encryption なし Error-Info Event あり Expires From In-Reply-To なし Max-Forwards あり MIME-Version Min-Expires Min-SE Organization なし Priority Proxy-Authenticate Proxy-Authenticate あり Proxy-Authorization Proxy-Require なし 5 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 1 SIP ヘッダー フィールド （続き） ヘッダー フィールド シスコ ゲートウェイによるサポートの有無 Rack あり Reason Record-Route Referred-By Referred-To Replaces Requested-By Require Response-Key なし Retry-After Retry-After あり Route RSeq Server Session-Expires Subject なし Supported あり Timestamp To Unsupported User-Agent Via Warning WWW-Authenticate なし WWW-Authenticate あり 表 2 SIP ネットワーク コンポーネント SIP ネットワーク コンポー ネント シスコ ゲートウェイによるサポートの有無 ユーザ エージェント クライ あり アント（UAC） ユーザ エージェント サーバ （UAS） プロキシ サーバ なし リダイレクト サーバ あり レジストラ サーバ 6 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 3 SIP 方式 方式 シスコ ゲートウェイによるサポートの有無 ACK あり BYE CANCEL COMET 廃止。条件に合致。Quality of Service（QoS）実装で使用され、もう 一方のエンドポイントに対して、条件が満たされているかどうか、つ まり適切なリソースが予約されているかどうかを示します。 INVITE あり。SIP ゲートウェイは、同じコール ID を持つが、Session Description Protocols（SDP）セッション パラメータの異なるミッド コール Invite 要求（転送アドレスを変更するため）をサポートします。 ミッドコール INVITE 要求は、ポート番号やコーデックの変更、また INFO あり。SIP ゲートウェイは INFO メッセージの受け入れや生成を行えま す。 はセッションの タイマー値の更新も行えます。 NOTIFY あり。Refer 要求の実装で使用されます。Notify メッセージにより、 Refer 要求の発信側に転送の結果を通知できます。また Notify メッ セージにより、加入者に対して、選択されたイベント（DTMF （Dual Tone MultiFrequency）イベント、または message waiting indication （MWI）イベントなど）で発生した変更を通知できます。 OPTIONS あり。SIP ゲートウェイはこの方式のみを受信します。 PRACK あり。Provisional Reliable Acknowledgements（PRACK）をイネーブ ルまたはディセーブルにします。 REFER あり。SIP ゲートウェイは Refer 要求に応答し、また在席コール転送お よびブラインド コール転送に関する Refer 要求を生成します。 REGISTER あり。SIP ゲートウェイは SIP REGISTER 要求を送受信できます。 SUBSCRIBE あり。SIP ゲートウェイは SUBSCRIBE 要求を生成して受け入れるこ とができます。ゲートウェイは、DTMF テレフォニー イベントなど選 択したアプリケーションや MWI に対する SUBSCRIBE 要求を処理し ます。 UPDATE あり。SIP ゲートウェイは、メディアの変更、ターゲットの更新、およ び QoS シナリオに関する UPDATE を受け入れることができます。また ゲートウェイは、QoS シナリオに対してのみ UPDATE を送信します。 SIP 応答 Cisco SIP ゲートウェイがサポートする、RFC 3261 に準拠した SIP 応答を表 4 ～表 9 に示します。 Cisco SIP ゲートウェイは、発信した、または終了したコールに対するキープアライブ メッセージの使 用は開始しません。リモート ゲートウェイがキープアライブ メッセージを使用する場合、SIP ゲート ウェイはそれに従います。 7 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 4 1xx 応答 1xx 応答 100 Trying 説明 発信側に代わってアクションが実行されていますが、着信側の場所は まだ確認されていません。SIP ゲートウェイは、着信した Invite 要求に 対してこの応答を生成します。ゲートウェイは、この応答を受け取る とすぐに、Invite 要求の再送信を停止して、180 Ringing または 200 OK 応答を待ちます。 180 Ringing 着信側の場所が確認され、コールがあることが通知されています。着 信側の場所が確認され通知が行われているとき、SIP ゲートウェイは 180 Ringing 応答を生成します。ゲートウェイは、この応答を受け取る とすぐに、ローカル リングバックを生成し、200 OK 応答を待ちます。 181 Call is being forwarded コールは別の宛先に再ルーティングされています。 SIP ゲートウェイはこれらの応答を生成しません。 ゲートウェイは、この応答を受け取るとすぐに、100 Trying 応答と同 じ処理方法でこの応答を処理します。 182 Queued 着信側は現在対応できませんが、コールを拒否するのではなく、コー ルをキューに入れることを選択しました。 SIP ゲートウェイはこれらの応答を生成しません。 ゲートウェイは、この応答を受け取るとすぐに、100 Trying 応答と同 じ処理方法でこの応答を処理します。 183 Session progress 発信側に帯域内アラートを実行します。 PSTN から適切なメディアを示した ISDN Progress メッセージを受け 取った場合、SIP ゲートウェイは 183 Session progress 応答を生成しま す。 表 5 2xx 応答 2xx 応答 202 Accepted 説明 SIP ゲートウェイは、着信した REFER 要求および SUBSCRIBE 要求 に対してこの応答を送信します。また SIP ゲートウェイは、発信した REFER 要求および SUBSCRIBE 要求に対してこの応答を受け入れま す。 200 OK 表 6 要求は正常に処理されました。実行されるアクションは要求により異 なります。 3xx 応答 3xx 応答 説明 SIP ゲートウェイはこの応答を生成しません。ゲートウェイは、この応答を受け取るとすぐに、 Contact ヘッダー フィールドの新しいアドレスに連絡します。 300 Multiple Choice アドレスは複数の場所に解決されました。すべての場所が表示され、 ユーザまたは User Agent（UA; ユーザ エージェント）は使用する場所 を選択できます。 301 Moved permanently 8 指定された場所に対応可能なユーザはいません。ヘッダーに代替場所 が示されます。 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 6 3xx 応答 （続き） 3xx 応答 説明 SIP ゲートウェイはこの応答を生成しません。ゲートウェイは、この応答を受け取るとすぐに、 Contact ヘッダー フィールドの新しいアドレスに連絡します。 302 Moved temporarily 指定された場所では、ユーザは一時的に対応できません。ヘッダーに 代替場所が示されます。 305 Use proxy 発信側はプロキシを使用して着信側に連絡する必要があります。 380 Alternative service コールに失敗しましたが、代替サービスが使用可能です。 表 7 4xx 応答 4xx 応答 説明 SIP ゲートウェイは、4xx 応答を受け取るとすぐに、正常なコールの接続解除を開始して、コールを クリアします。 423 Interval Too Brief SIP ゲートウェイはこの応答を生成します。 400 Bad Request 要求の形式が不正なため、認識できませんでした。SIP ゲートウェイ は、不正な形式の要求に対してこの応答を生成します。 401 Unauthorized 要求にはユーザ認証が必要です。SIP ゲートウェイはこの応答を生成し ません。 402 Payment required コールを行うには支払いが必要です。SIP ゲートウェイはこの応答を生 成しません。 403 Forbidden サーバは要求を受け取り、認識しましたが、サービスは提供しません。 SIP ゲートウェイはこの応答を生成しません。 404 Not Found サーバには、ユーザが指定されたドメインに存在しないという明確な 情報があります。SIP ゲートウェイは、着信側の場所を確認できない場 合にこの応答を生成します。 405 Method Not Allowed 要求に指定されている方式は許可されていません。応答には、許可さ れている方式のリストが含まれています。要求に無効な方式が指定さ れている場合、SIP ゲートウェイはこの応答を生成します。 406 Not Acceptable 要求されたリソースは、要求の accept ヘッダーで受け入れ不可能と指 定されているコンテンツ特性を持つ応答だけを生成できます。SIP ゲー トウェイはこの応答を生成しません。 407 Proxy authentication required 401 Unauthorized 応答と同様。ただし、クライアントはまずプロキシ を使用してクライアント自身を認証する必要があります。SIP ゲート ウェイはこの応答を生成しません。 408 Request timeout サーバは、Expires がタイムアウトになる前に応答を生成できませんで した。SIP ゲートウェイはこの応答を生成しません。 410 Gone リソースはサーバでは使用不可能で、既知のフォワーディング アドレ スはありません。PSTN が未割り当ての番号の原因コードを返した場 合、SIP ゲートウェイはこの応答を生成します。 413 Request entity too large 要求がサーバによる処理が可能なサイズを超えているため、サーバは 要求の処理を拒否します。SIP ゲートウェイはこの応答を生成しませ ん。 414 Request-URI too long Request-URI が長すぎてサーバが解釈できないため、サーバは要求の 処理を拒否します。SIP ゲートウェイはこの応答を生成しません。 9 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 7 4xx 応答 （続き） 4xx 応答 415 Unsupported media 416 Unsupported Request URI scheme 説明 本文の形式が宛先のエンドポイントによってサポートされていないた め、サーバは要求の処理を拒否します。SIP ゲートウェイは、サポート されていないイベント タイプに対して Info メッセージを受け取った場 合、この応答を生成します。サポートされているイベント タイプは、0 ～ 9、A ～ D、#、および * です。 SIP ゲートウェイは、SIP 要求内にサポートされていない URI スキー ム（http: または sips: など）を受け取った場合、この応答を生成しま す。 420 Bad extension サーバは、Require ヘッダーに示されたプロトコル拡張子を理解できま せんでした。SIP ゲートウェイは、要求されたサービスを理解できない 場合にこの応答を生成します。 421 Extension Required SIP ゲートウェイはこの応答を生成しません。 422 Session Timer Too Small 要求に含まれる Session-Expires ヘッダーにゲートウェイ サーバの最小 タイマーを下回る期間が設定されている場合、UAS によって生成され ます。422 応答には、サーバに対する最小タイマーを備えた Min-SE ヘッダーが含まれていることが必要です。 480 Temporarily unavailable 着信側に連絡できましたが、一時的に使用不可能になっています。SIP ゲートウェイは、着信側が使用不可能な場合にこの応答を生成します。 たとえば、一定時間内に着信側が電話に応答しない、または送信先番 号が存在しないか稼動していない場合などです。 10 481 Call leg/transaction does not exist 要求が、一致しないレッグ ID が存在する Bye 要求、または一致するト ランザクションが存在しない Cancel 要求のいずれかだったため、サー バは要求を無視しています。コール レッグ ID またはトランザクション が識別できない場合、SIP ゲートウェイはこの応答を生成します。 482 Loop detected サーバは、サーバ自体がパスに含まれる要求を受け取りました。SIP ゲートウェイは、同じ要求が異なるパスで複数回到着したことを検出 した場合（フォークによる場合が多い）、この応答を生成します。 483 Too many hops サーバは、Max-Forwards ヘッダーで許可されているより多いホップ数 を求める要求を受け取りました。SIP ゲートウェイはこの応答を生成し ません。 484 Address incomplete サーバは、不完全なアドレスを含む要求を受け取りました。SIP ゲート ウェイはこの応答を生成しません。 485 Ambiguous サーバは、着信側アドレスがあいまいな要求を受け取りました。可能 性のある代替アドレスが提示されます。SIP ゲートウェイはこの応答を 生成しません。 486 Busy here 着信側に連絡できましたが、システムは追加のコールに対応できませ ん。SIP ゲートウェイは、着信側に連絡できたがビジーだった場合にこ の応答を生成します。 487 Request cancelled 要求が Bye 要求または Cancel 要求により終了されました。SIP ゲート ウェイは、要求に対して予期しない Bye または Cancel を受け取った場 合にこの応答を生成します。 488 Not Acceptable Media 要求を処理する際にエラーが発生したことを示します。SIP ゲートウェ イは、メディア ネゴシエーションが失敗した場合にこの応答を生成し ます。 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 7 4xx 応答 （続き） 4xx 応答 491 Request Pending 493 Undecipherable 表 8 説明 SIP ゲートウェイは、以前要求したオファーに対する応答を受け取る前 に新しいオファーを受け取った場合、その新しいオファーを提示する UPDATE メッセージを拒否する際にこの応答を生成します。 SIP ゲートウェイはこの応答を生成しません。 5xx 応答 5xx 応答 説明 SIP ゲートウェイは、要求を処理する妨げとなった予期しないエラーが発生した場合にこの応答を生 成します。 ゲートウェイは、この応答を受け取るとすぐに、正常なコールの接続解除を開始して、コールをクリ アします。 500 Server internal error サーバまたはゲートウェイは、要求を処理する妨げとなった予期しな いエラーの発生を検出しました。 501 Not implemented サーバまたはゲートウェイは、要求の実行に必要な機能をサポートし ていません。 502 Bad gateway サーバまたはゲートウェイは、ダウンストリーム サーバから無効な応 答を受け取りました。 503 Service unavailable サーバまたはゲートウェイは、過負荷または保守上の問題により要求 を処理できません。 504 Gateway timeout サーバまたはゲートウェイは、別のサーバ（ロケーション サーバなど） から適切なタイミングで応答を受け取りませんでした。 505 Version not supported サーバまたはゲートウェイは、要求で使用されている SIP プロトコル のバージョンをサポートしていません。 513 Message too large SIP ゲートウェイはこの応答を生成しません。 580 Precondition failed QoS の前提条件をコールに合致させようとした際にエラーが発生しま した。 表 9 6xx 応答 6xx 応答 説明 SIP ゲートウェイはこの応答を生成しません。ゲートウェイは、この応答を受け取るとすぐに、正常 なコールの接続解除を開始して、コールをクリアします。 600 Busy everywhere 着信側に連絡できましたが、着信側はビジーで、この時点でコールに 対応できません。 603 Decline 着信側に連絡できましたが、着信側はコールへの参加できないか、参 加を希望していません。 604 Does not exist anywhere サーバは、着信側がネットワークに存在しないという信頼できる情報 を得ています。 606 Not acceptable 着信側に連絡できましたが、セッションの説明の一部を受け入れでき ません。 11 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 SIP SDP の使用方法、トランスポート レイヤ プロトコル、および DNS レコード 表 10 ～表 12 に RFC 3261 でサポートされる SIP SDP の使用方法、トランスポート レイヤ プロトコ ル、および DNS レコードを示します。また、Cisco SIP ゲートウェイがサポートする特定の機能があ る場合はその機能も示します。 表 10 RFC 3261 でサポートされる SIP Session Description Protocol（SDP）の使用方法 SIP ネットワーク コンポーネン シスコ ゲートウェイによるサポートの有無 ト a（メディア アトリビュート行） あり。SDP を拡張して、SDP を特定のアプリケーションまたはメ ディアに合わせてカスタマイズするための主な方法 c（接続情報） あり。 m（メディア名および転送アド レス） o（オーナー / 作成者およびセッ ションの識別子） s（セッション名） t（時間の説明） v（プロトコル バージョン） 表 11 SIP トランスポート レイヤ プロトコル プロトコル シスコ ゲートウェイによるサポートの有無 マルチキャスト UDP なし TCP あり TLS なし ユニキャスト UDP あり 表 12 SIP Domain Name System（DNS）レコード 認証暗号化モード シスコ ゲートウェイによるサポートの有無 RFC 3263 タイプ A あり RFC 3263 タイプ NAPTR なし RFC 3263 タイプ SRV あり SIP 拡張機能 表 13 に、サポートされる SIP 拡張機能を示します。 12 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 13 SIP 拡張機能 SIP 拡張機能 説明 RFC 3262：SIP における暫定応 サポートされます。 答の信頼性 RFC 3263：SIP サーバの位置確 ゲートウェイは DNS NAPTR ルックアップをサポートしません。 DNS SRV および A レコード ルックアップはサポートしており、 認 複数エントリを循環するための準備ができています。 RFC 3265：SIP 特定イベントの ゲートウェイは SUBSCRIBE-NOTIFY フレームワークをサポート 通知 します。 RFC 3311：SIP UPDATE 方式 ゲートウェイは、メディアの変更、ターゲットの更新、および QoS シナリオに関する UPDATE を受け入れます。またゲートウェ イは、QoS シナリオに対してのみ UPDATE を送信します。 RFC 3312：リソース管理と SIP ミッドコール QoS の変更では、この RFC に定義されている の統合 - RFC 183-PRACK モデルを使用しません。 RFC 3326：SIP 用の Reason Header フィールド RFC 3515：SIP REFER 方式 ゲートウェイは、これを使用して Q.850 原因コードをリモート SIP デバイスに取り次ぎます。 ゲートウェイは、アウトオブダイアログの REFER 要求を送信また は受け入れしません。REFER の重複はサポートされていません。 REFER は、コール転送シナリオのコンテキストだけ（つまり、 INVITE がトリガーされた場合だけ）でサポートされます。ゲート ウェイは、コール転送シナリオで必要に応じて RFC 3892 の関連 部分（Referred-By）および RFC 3891 の関連部分（Replaces ヘッ ダー）をサポートします。 SIP セキュリティ 表 14 および 表 15 に、RFC 3261 でサポートされる SIP セキュリティ暗号化および応答を示します。 また、Cisco SIP ゲートウェイがサポートする特定の機能がある場合はその機能も示します。 表 14 SIP 暗号化モード 暗号化モード シスコ ゲートウェイによるサポートの有無 エンドツーエンド暗号化 なし。IPSEC をセキュリティに使用できます。 ホップバイホップ暗号化 SIP 応答のプライバシー なし。 フィールド経由暗号化 なし。IPSEC をセキュリティに使用できます。 表 15 SIP 認証暗号化モード 認証暗号化モード シスコ ゲートウェイによるサポートの有無 ダイジェスト認証 あり PGP なし プロキシ認証 なし セキュア SIP または sips URI スキームはサポートされません。 13 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 SIP DTMF リレー Cisco SIP ゲートウェイは、RFC 2833 に準拠して DTMF リレーをサポートします。DTMF リレー方式 は、Named Telephony Events（NTE）の伝送および DTMF digits over a Real-Time Transport Protocol （RTP; リアルタイム トランスポート プロトコル）ストリームに対する DTMF 数値に基づいています。 また Cisco SIP ゲートウェイは、cisco-rtp（シスコ固有のペイロード タイプ）を使用した DTMF トーン の転送もサポートしています。 表 16 に SIP DTMF リレー方式を示します。また Cisco SIP ゲートウェイが特定の方式をサポートする かどうかも示します。 表 16 RFC 3261 でサポートされる SIP DTMF リレー 方式 シスコ ゲートウェイによるサポートの有無 RFC 2833 あり。rtp-nte に対するデフォルトの RTP ペイロード タイプは 101 です。DTMF リレーのデフォルト方式は、インバンド音声です。 Cisco RTP（シスコ独自） あり。ただし、Cisco AS5350 および Cisco AS5400 を除く。 SIP ファックス リレーおよび T.38 表 17 に、RFC 3261 に準拠して Cisco SIP ゲートウェイでサポートされるファックス リレー モードを 示します。また Cisco SIP ゲートウェイが特定の方式をサポートするかどうかも示します。 表 17 RFC 3261 でサポートされるファックス リレー モード 方式 シスコ ゲートウェイによるサポートの有無 T.38 ファックス リレー あり Cisco ファックス リレー あり。ただし、Cisco AS5350 および Cisco AS5400 を除く。 Cisco SIP ゲートウェイは T.38 および T.37 ファックス リレー、ストア、および転送メカニズムをサ ポートします。表 18 は、T.38 ITU 勧告の Annex-D「Procedures for Real-Time Group 3 Facsimile Communication over IP Networks, June 1998」に基づいています。表には、基準に含まれる勧告や、 Cisco SIP ゲートウェイによる要件のサポートの有無を示します。 表 18 T.38 ファックス要件 必須または任 意 サポートの有無 要件 説明 SIPt38-01 SIP に対する T.38 は、T.38 ITU 勧告の ANNEX 必須 D 「Procedures for Real-Time Group 3 Facsimile Communication over IP Networks, June 1998」の あり 記載に従って実装することが必要です。 14 SIPt38-02 SIP 対応の VoIP ゲートウェイは、RTP オーディ オ ストリーム内で転送される、calling（CNG） トーン、called station identifier（CED）ファッ クス トーン、およびプリアンブル フラグ シーケ ンスを検出します。 必須 あり。ファックス 検出には CED V.21 プリアンブル のみが使用され、 CNG トーンは使 用されません。 SIPt38-03 ファックス伝送の検出は、受信側ゲートウェイが CED トーンを認識することによって実行されま す。 必須 あり SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 18 T.38 ファックス要件 （続き） 必須または任 意 サポートの有無 要件 説明 SIPt38-04 CED トーンがない場合、ファックス伝送は受信 側ゲートウェイがプリアンブル フラグ シーケン スを認識することにより検出されます。 必須 あり SIPt38-05 ファックス伝送を検出するとただちに、受信側 ゲートウェイは、SDP を使用して re-INVITE 要 求を送信することにより T.38 ファックス モード に対する切り替えを開始します。 必須 あり SIPt38-06 グレアを防止するため、伝送ゲートウェイが ファックス伝送（CNG トーン）を検出した場合 でも、ゲートウェイは T.38 ファックス モードへ の切り替えを開始しません。 必須 あり SIPt38-07 SIP セッションがオーディオ機能で開始され、そ 必須 の後ファックスに切り替わった場合、セッション は、ファックス伝送終了時にオーディオ モードに 戻します。 あり SIPt38-08 TCP を介した SIP T.38 ファックス コールをサ ポート。 推奨 UDP のみ SIPt38-09 ファクシミリ UDP Transport Layer（UDPTL; UDP トランスポート レイヤ）がサポートされま 必須 あり 必須 あり T.38 セッションをサポートするアトリビュートは 必須 次のとおりです。 あり す。 SIPt38-10 T.38 ファックス セッションをサポートする SDP アトリビュートは次のとおりです。 • 登録済み SDP プロトコル形式、MIME メ ディア タイプ：image/t38: • MIME メディア タイプ名：image • MIME サブタイプ名：t38 SIPt38-11 • T38FaxVersion • T38maxBitRate • T38FaxFillBitRemoval • T38FaxTranscodingMMR • T38FaxTranscodingJBIG • T38FaxRateManagement • T38FaxMaxBuffer • T38FaxMaxDatagram • T38FaxUdpEC SIPt38-12 T.38 をサポートする Cisco SIP 対応のゲートウェ 必須 イは、シスコおよび他のベンダー製のゲートウェ イと相互運用できます。 あり 15 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 18 T.38 ファックス要件 （続き） 要件 説明 必須または任 意 サポートの有無 SIPt38-13 H.323 を介した T.38 をサポートするゲートウェ 任意 なし 必須 あり。次の項目は 設定可能です。 イとの相互運用性 SIPt38-14 SIP 対応のゲートウェイの設定には、SIP T.38 固 有の設定可能な選択項目が含まれます。 • bitrate • TCP/UDP （UDP のみ） • hs および ls 冗 長性 • ECM SIPt38-15 ゲートウェイでの SIP T.38 アクティビティのト 必須 ラッキングとレポートを行うことを推奨します。 これには、SIP T.38 ファックス コールに対する Call Detail Record（CDR; 呼詳細レコード）の作 成が含まれます。 あり SIPt38-16 RFC 3261 セキュリティ メカニズムが適用されま 任意 す。SIP Invite 要求および Bye 要求に対してメッ なし セージ認証を実行できます。 SIP ユニフォーム リソース ロケータ（URL）の比較 Uniform Resource Locators（URL; ユニフォーム リソース ロケータ）が受信された場合、URL が同じ かどうか比較が行われます。URL の比較は、2 つの From SIP URL または 2 つの To SIP URL 間で実 行できます。パラメータの順序は正確に一致している必要はありません。ただし、2 つの URL が同一 になるためには、ユーザ、パスワード、ホスト、およびポート パラメータが一致することが必要です。 Cisco IOS リリース 12.3 では、maddr パラメータと transport パラメータは、Cisco SIP ゲートウェイ 実装では許可されていません。現在、user-param パラメータは比較の対象として受け入れ可能です。 比較されるパラメータが削除されているか、または存在しない場合、デフォルト値に基づいて一致が行 われます。表 19 に SIP の URL の比較対象となるパラメータとそのデフォルト値のリストを示します。 表 19 SIP の URL の比較対象パラメータとデフォルト値 SIP の URL の比較対象パラメータ User — Password — Host 必須 Port 5060 User-param IP デフォルト 比較が行われていると仮定して、同一 URL の例を次に示します。 元の URL： sip:[email protected] 16 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 同等 URL： sip:[email protected]: sip:[email protected];tag=499270-A62;pname=pvalue sip:[email protected];user=ip sip:[email protected]:5060 487 Sent for BYE 要求 RFC 3261 では、BYE 要求を受信する UAS は、コールを切断する前にまずそのコールの保留されてい る要求に対する応答を送信する必要があります。UAS は、BYE 要求を受信すると、487（Request Cancelled）ステータス メッセージで応答する必要があります。 3xx リダイレクション応答 「SIP リダイレクト処理拡張の設定」（P.8）を参照してください。 DNS SRV クエリー手順 RFC 3261 に準拠して、ダイヤル ピアにおける Request URI またはセッション ターゲットには、完全 修飾ドメイン名（FQDN）が含まれており、UAC は要求を転送する前に、エンドポイントのプロトコ ル、ポート、および IP アドレスを決定する必要があります。SIP on Cisco ゲートウェイの SIP は、 Domain Name System Server（DNS SRV）クエリーを使用して、ユーザ エンドポイントのプロトコ ル、ポート、および IP アドレスを決定します。 Cisco IOS リリース 12.2(13)T 以前は、DNS クエリー手順では宛先ポートは考慮されていませんでした。 CANCEL Request Route ヘッダー 最初の INVITE 要求に対して UAC が送信する CANCEL メッセージには、Route ヘッダーを設定できま せん。Route ヘッダーは CANCEL メッセージに含めることはできません。これは Route ヘッダーが INVITE 要求と同じパスを使用し、INVITE 要求には Route ヘッダーを含めることができないためです。 ユーザ パラメータの解釈 電話加入者またはユーザのパラメータに、スペース、制御文字、引用符、ハッシュ記号、およびその他 の文字を含むエスケープ文字が含まれていることがあります。INVITE メッセージを受け取った後、電 話加入者またはユーザのパラメータの解釈が行われてから、ダイヤル ピアのマッチングが実行されま す。たとえば、受信した INVITE メッセージ内でエスケープされた電話番号が次のように示されてい ることがあります。 -%32%32%32 222 は有効な電話番号ですが、この場合は解釈が必要となります。解釈が実行されない場合、ユーザ パラメータがダイヤル ピアの宛先パターンと一致すると、コールの試行は失敗します。 user=phone パラメータ SIP URL は、E メール アドレスに似たユーザのアドレスを識別します。ユーザ アドレスの形式は、 user@host で、user はユーザ ID、host はドメイン名または数字でネットワーク アドレスを表したもの になります。たとえば、発信 INVITE 要求の要求行は、次のように見える場合があります。 INVITE sip:[email protected] 17 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 以前 SIP URL で必須パラメータであった user=phone パラメータは、必須ではなくなりました。ただ し、着信した SIP メッセージの SIP URL に user=phone, が含まれている場合、user=phone が解析さ れ、トランザクションの後続メッセージで使用されます。 SIP 原因コード 303 および 411 RFC 3261 の導入により、SIP の原因コード 303「Redirection: See Other」および 411「Client Error: Length required」が廃止されます。 Content-Type ヘッダーの柔軟性 メッセージ本文のメディア タイプを指定する Content-Type ヘッダーは、Session Description Protocol （SDP）の空の本文を含むことを許可されています。 SDP のオプションの「s=」行 SDP の「s=」行は、オプションとして受け付けられます。「s=」行には、SDP 情報の理由または主題 が記述されます。Cisco SIP ゲートウェイは、SDP 本文に「s=」行が含まれるメッセージを作成でき、 また、「s=」行を含まないメッセージも受け取れます。 INVITE および 2xx 応答への Allow ヘッダーの追加 最初または re-INVITE 要求、または任意の 2xx クラス応答で INVITE に対する Allow ヘッダーの使用 が許可されています。Allow ヘッダーは、メッセージを生成するユーザ エージェントがサポートする 方式の一覧を示します。Allow ヘッダーにより、メッセージを送信するユーザ エージェントでどの方 式を実行するべきかがアドバタイズされるので、メッセージ トラフィックが無駄に混雑するのが回避 されます。Allow ヘッダーには、INVITE、OPTIONS、BYE、CANCEL、ACK、PRACK、COMET、 REFER、NOTIFY、INFO、SUBSCRIBE の内のどれでも、またはすべてを含めることができます。 Cancel および 2xx クラス応答の同時実行 RFC 3261 に準拠して、INVITE に対する応答が受信される前に UAC がコールの終了を希望する場合、 UAC は CANCEL を送信します。ただし、INVITE に対する CANCEL および 2xx クラス応答が有線で 渡された場合、UAC は INVITE に対する 2xx も受け取ります。2 つのメッセージが渡されると、UAC は BYE 要求を送信することでコールを終了します。 UPDATE 要求の処理 RFC 2543 に取って代わった RFC 3261 では、セッションの作成、変更、終了を行うための SIP シグナ リング プロトコルが定義されています。発信者 ID とプライバシーのための SIP 拡張 機能では、RFC 3261 仕様に準拠する次の SIP ゲートウェイ実装がサポートされます。 • 「SIP UPDATE 要求」（P.19） • 「Via ヘッダーのパラメータと結合要求の検出」（P.23） • 「Loose-Routing および Record-Route ヘッダー」（P.24） • 「最終応答前の複数の INVITE 要求」（P.24） • 「ミッドコール re-INVITE 要求の失敗」（P.24） • 「新しいオファーを伴う PRACK 要求」（P.25） 18 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 • 「信頼できる暫定応答の失敗」（P.25） SIP UPDATE 要求 SIP は、サーバかクライアントからの要求または要求に対する応答のいずれかのメッセージを通じて セッション管理を行います。SIP は INVITE 要求を使用してユーザ エージェント（UA）間のセッショ ンを開始および変更し、ACK 方式を使用して INVITE 要求に対する最終応答を確認します。場合に よっては、INVITE 要求への応答前にセッションを変更する必要があります。このシナリオはたとえ ば、アーリー メディア（early media）に、確立されたセッション中にコールの経過を表すよう送信さ れる情報を送信しており、このセッションに対して INVITE 要求が受け入れられていないコールで発 生します。このシナリオでは、発信側または着信側はセッションの特性を、たとえばアーリー メディ ア（early media）をコールへの応答前に保留にすることなどで、変更できることが必要です。クライ アントによるセッション パラメータのアップデートを許可する SIP UPDATE 方式に先立って、発信側 または着信側が、最初の INVITE 要求への最終応答が生成される前にアップデート済みセッション情 報を提供できるようにするメカニズムはありません。発信者 ID とプライバシーのための SIP 拡張 機能 では、UPDATE 方式に対するサポートが提供され、ゲートウェイによる UPDATE 要求の受信と処理を 可能にしますが、送信は可能にしません。またゲートウェイは、コールがアクティブになった後のセッ ション タイマー値もアップデートします。 ユーザ エージェント クライアント（UAC）は、ユーザ エージェント サーバ（UAS）に INVITE 要求 を送信することでセッションを開始します。UAS は、次の応答コードを送信することで、INVITE 要 求に応答します。 • コールの経過を示す 1xx 暫定応答。すべての 1xx 応答は情報目的であり最終応答ではありません。 1xx 応答以外の応答はすべて最終応答です。 • 要求の正常な終了または受信を示す 2xx 応答 • 拒否または失敗を示す 3xx、4xx、5xx、または 6xx 応答 PRACK 応答は、高い信頼性で転送された暫定応答（アーリー メディア（early media）の表示を伴う 応答など）の受信を確認する際に使用され、一方 ACK は、INVITE 要求に対する最終応答を確認する 際に使用されます。PRACK により、UAC および UAS 間にアーリー ダイアログ、つまり新しいオ ファーを伴う UPDATE 要求を受信するための要件が作成されます。 2xx 応答が送信されると、この応答によりセッションが確立され、ダイアログまたはコール レッグも 作成されます。1xx 応答により作成されたダイアログは、アーリー ダイアログと見なされ、最終応答 により確認済みダイアログが作成されます。SIP UPDATE 方式により、UAC は、メディア ストリーム やそのコーデックのセットなどのセッション パラメータをアップデートでき、ダイアログの状態には 影響を及ぼしません。re-INVITE 要求と異なり、SIP UPDATE 要求は、最初の INVITE 要求への応答 前に送信してセッションを変更でき、このときダイアログの状態自体に影響を及ぼすことはありませ ん。UPDATE 方式は、最初の INVITE 要求への応答前（たとえば、アーリー メディア（early media） の送信時など）に、アーリー ダイアログ内でセッション パラメータをアップデートするのに役立ちま す。 SIP UPDATE 方式は、Internet Engineering Task Force（IETF; インターネット技術特別調査委員会） の仕様 RFC 3264「An Offer/Answer Model with the Session Description Protocol (SDP)」で定義されて いるとおり、Session Description Protocol（SDP）を使用してオファーと応答の交換を利用します。 セッション内のある UA が SDP メッセージを生成します。このメッセージは、オファー（UA が使用 しようとしているメディア ストリームとコーデックのセット）と、UA がメディアを受信する IP アド レスやポートで構成されます。その他の UA は応答、つまりオファーに応えるための SDP メッセージ を生成します。 19 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 Cisco SIP 実装では、UAS はアーリー ダイアログと確認済みダイアログの両方で UPDATE 要求を受信 できます。オファーが生成されるポイント、UPDATE を受信するポイント、および信頼できる暫定応 答と SDP の有無はすべて、ゲートウェイが UPDATE 要求の処理方法を決定するための要因となりま す。UPDATE 要求では、次のような数種類の結果のいずれかを示す応答が生成されます。 • 成功 • 未処理のオファーに対する応答を保留中 • 失敗 次に、さまざまなシナリオやコール フローにおける UPDATE 要求の受信方法と処理方法について説明 します。 コールがアクティブになる前の UPDATE 要求の処理 ゲートウェイが信頼できる暫定応答を SDP を使用して送信した場合、応答には、UPDATE 方式の一覧 を示す Allow ヘッダーが含まれ、発信側に UPDATE 処理をサポートするゲートウェイ機能が通知され ます。 図 1 に、UAS が信頼できる暫定応答（ANSWER 1）を INVITE 要求（Offer 1）へ送信する場合のコー ルを示します。18x アーリー メディア（early media）応答により、ゲートウェイの UPDATE サポート 機能が示されました。UAC は暫定確認応答（PRACK）を送信し、PRACK 要求に対して 200 OK 応答 を受信しました。UAC は UAS に、UPDATE 要求（Offer 2）を送信することでアーリー ダイアログの 既存セッション メディア パラメータを変更するよう要求しました。UAS は、200 OK 応答を送信する ことで、Offer 2 を受け入れました。メディア ネゴシエーションが失敗した場合、UAS は代わりに 488 Unacceptable Media 応答を送信します。その後、UAS は最初の INVITE 要求に対して 200 OK 最終応 答を送信しました。UAS は、INVITE 要求への最終応答を確認する ACK 要求を送信しました。 図 1 アーリー メディア（early media）に対する UPDATE V V UAC UAS INVITE (Offer 1) 18x (ANSWER 1) PRACK/200 OK UPDATE (Offer 2) 200 OK (ANSWER 2) 98764 200 OK (INVITE)/ACK 図 2 では、ゲートウェイは INVITE 要求（Offer 1）に応答する前に UPDATE 要求（Offer 2）を受信し ました。これにより、ゲートウェイは、Retry-After ヘッダー フィールドを 0 ～ 10 秒までのランダム に選択した値に設定した状態で 500 Internal Server Error を送信することで、要求を拒否しました。 20 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 図 2 最初の UPDATE の拒否 V V UAC UAS INVITE (Offer 1) 18x (Ringing) UPDATE (Offer 2) 500 (Internal Server Error) 200 OK (ANSWER 1)/ACK UPDATE (Offer 2) 98765 200 OK (ANSWER 2) 図 3 では、最初の INVITE 要求にはオファーが含まれておらず、UAS ゲートウェイは信頼できる暫定 応答（Offer 1）とともに SDP を送信し、これを UAC はオファーとして処理しました。 図 3 ディレイド メディア（delayed media）に対する UPDATE 要求 V V UAC UAS INVITE㧔ࠝࡈࠔߥߒ㧕 18x (Offer 1) PRACK (ANSWER 1) 200 OK UPDATE (Offer 2) 98766 200 OK (ANSWER 2) 図 4 では、UAS は PRACK を受信する前、つまりアーリー ダイアログが確立される前に、オファー （Offer 2）とともに UPDATE 要求を受信しており、これにより UAS（ゲートウェイ）は 491 Request Pending 応答を生成しました。 21 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 図 4 ディレイド メディア（delayed media）に対する UPDATE 要求の失敗 V V UAC UAS INVITE㧔ࠝࡈࠔߥߒ㧕 18x (Offer 1) UPDATE (Offer 2) 491 (Request Pending) PRACK (ANSWER 1) 98767 200 OK コールがアクティブになる前の UPDATE 要求の処理に対するエラー応答 その他のシナリオでは、ゲートウェイが INVITE 要求に 200 OK 応答を送信しているが、まだ ACK を 受信していない場合に、オファーを伴う UPDATE 要求の処理に別のルールが適用されます。次に示す エラー応答が生成されるシナリオを図 5 に示します。 • 最初の INVITE 要求にオファーが含まれているが、信頼できる暫定応答を送信することを必要とし ていない場合、200 OK 内の SDP が応答のように扱われます。UAS が 200 OK に対する ACK 応 答の前に UPDATE 要求を受信した場合、UAS は Retry-After ヘッダーを伴う 500 Server Internal エラー応答を送信します。 • 最初の INVITE 要求にオファーが含まれておらず、信頼できる暫定応答を送信することを必要とし ていない場合、200 OK 内の SDP がオファーのように扱われます。UAS が 200 OK に対する ACK の前に UPDATE 要求を受信した場合、UAS は 491 Request Pending 応答を送信します。 図 5 UPDATE 要求に対するエラー ケース V V UAC UAS INVITE (Offer 1) 18x 200 OK (ANSWER 1) UPDATE (Offer 2) 98769 500 (Internal Server Error) 22 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 アクティブ状態での UPDATE 要求の処理 RFC 3261 は re-INVITE 要求を使用して、既存または保留中のコールのセッション パラメータを変更 する SIP メッセージが、コールがアクティブになった後にセッション パラメータをアップデートする ことを推奨しています。コールがアクティブになった後に受信された UPDATE は、アップデートする ための 200 OK が再送信される場合を除き、re-INVITE のように処理されます（図 6 を参照）。 図 6 アクティブ状態での UPDATE 要求 V V UAC UAS INVITE/200 OK/ACK ᣇะ RTP UPDATE (Offer 2) 200 OK (ANSWER 2) 98770 ࠕ࠶ࡊ࠺࠻ߐࠇߚᣇะ RTP 図 7 に、ミッドコール INVITE を送信し、まだ応答を受信していない UAC を示します。この状態で は、ゲートウェイは新しいオファーを伴う UPDATE 要求を受信した場合、491 Request Pending エ ラーを送信します。 図 7 アクティブ状態での UPDATE 要求に対するエラー応答 V V UAC UAS INVITE (1) /200 OK/ACK ᣇะ RTP INVITE (2) UPDATE (Offer 3) 98771 491 (Request Pending) Via ヘッダーのパラメータと結合要求の検出 RFC 3261 の仕様を満たすため、発信者 ID とプライバシーのための SIP 拡張 機能では、要求の Via ヘッダー内の branch パラメータ、つまり要求によって作成されるトランザクションの識別に使用され る情報のサポートを提供します。branch パラメータの値は、「z9hG4bK」という値で始まり、要求が RFC 3261 に準拠し、UAC によって生成されたものであることを示します。発信者 ID とプライバシー のための SIP 拡張 では、受信したアドレスを使用して受信したパラメータを生成するためのサポート も追加されています。 23 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 発信者 ID とプライバシーのための SIP 拡張 機能では、branch パラメータおよび sent-by パラメータを 使用して、結合された要求（つまり、異なるパスをたどって複数回 UAS に到着した要求）を検出しま す。要求の To ヘッダー フィールドにタグが含まれない場合、UAS は進行中のトランザクションに対 して要求をチェックします。From タグ、Call-ID、および CSeq ヘッダーが、進行中のトランザクショ ンに関連するヘッダーと正確に一致しているが、branch パラメータを含む最上位の Via ヘッダーが一 致しない場合、UAS は要求を結合された要求として処理します。UAS は、結合された要求に応答し、 482 Loop Detected エラーを通知します。 Loose-Routing および Record-Route ヘッダー 発信者 ID とプライバシーのための SIP 拡張 機能では、要求ターゲットおよび次のルートの宛先を個別 に保持するメカニズムであるルーズ ルーティングをサポートします。プロキシが Record-Route ヘッ ダーに配置する Uniform Resource Indicator（URI）で使用されている lr パラメータは、プロキシの RFC 3261 との互換性を示します。要求で lr パラメータが欠落している場合、UA はネクストホップ プ ロキシが RFC 2543 に準拠してストリクト ルーティングを実装していると想定し、メッセージを再 フォーマットして Request-URI の情報を保持します。 最終応答前の複数の INVITE 要求 この機能では、UAS が最初の INVITE 要求に最終応答を送信する前に受信する複数の INVITE 要求の 処理に関するサポートを実装しています（図 8 を参照）。UAS ゲートウェイが、CSeq シーケンス番号 の低い最初の INVITE 要求に対して同じダイアログで最終応答を送信する前に、2 番目の INVITE 要求 を受信した場合、UAS は 2 番目の INVITE 要求に対して 500 Server Internal Error 応答を返します。エ ラー応答には、0 ～ 10 秒までのランダムな値を持つ Retry-After ヘッダー フィールドも含まれます。 図 8 R5xx 応答を使用して拒否される re-INVITE 要求 V V UAC UAS INVITE (CSeq: 1 INVITE) 18x Ringing INVITE (CSeq: 2 INVITE) 500 Internal Server Error 98772 ACK ミッドコール re-INVITE 要求の失敗 発信者 ID とプライバシーのための SIP 拡張 機能では、図 9 に示すとおりミッドコール re-INVITE 要 求の失敗の処理を実装しています。ミッドコール INVITE 要求に対する 2xx 以外の最終応答が次のい ずれかの場合、UAC はダイアログを終了します。 • 失敗を示す 481 Call/Transaction Does Not Exist 応答 • 失敗を示す 408 Request Timeout 応答 24 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 図 9 re-INVITE 要求に対する 481 または 408 応答後のダイアログ終了 V V UAC UAS INVITE (1) /200 OK/ACK ᣇะ RTP INVITE (2) 481/408 ACK 98773 BYE/200 OK 新しいオファーを伴う PRACK 要求 発信者 ID とプライバシーのための SIP 拡張 機能では、新しいオファーを伴う PRACK 要求をサポート します（図 10 を参照）。UAC が応答（Answer 1）を伴う信頼できる暫定応答を受信した場合、UAC は PRACK に追加のオファー（Offer 2）を生成できます。UAS がアップデートされたオファーを伴う PRACK を受信した場合、ネゴシエーションが成功すると UAS は応答（Answer 2）を伴う 200 OK を 生成します。成功しなかった場合、UAS は 488 Unacceptable Media 応答を生成します。 図 10 受け入れられた PRACK におけるオファー V V UAC UAS INVITE (Offer 1) 18x (ANSWER 1) PRACK (Offer 2) 200 OK (ANSWER 2) 98774 200 OK (INV, ANSWER 2)/ACK 信頼できる暫定応答の失敗 発信者 ID とプライバシーのための SIP 拡張 機能では、UAS が許容リトライ最大数分または 32 秒間、 信頼できる暫定応答である 18x を再送した後、対応する PRACK を受信しなかった場合、図 11 に示す 処理を行います。UAS は 5xx 応答を生成して、コールをクリアします。 25 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 図 11 信頼できる暫定応答の失敗 V V UAC UAS INVITE 18x (ANSWER 1) ...ᤨ㑆߇⚻ㆊߒޔ18x ߇ౣㅍାߐࠇࠆ 504 (Server Timeout) 98775 ACK メッセージの例 ここでは、SIP ゲートウェイ終了時に収集される SIP メッセージの例を示します。 SIP UPDATE 要求のコール フローの例 コールがアクティブになる前の UPDATE 要求を含む SIP 要求と応答の交換例を次に示します。 1w0d:SIP Msg:ccsipDisplayMsg:Received: INVITE sip:[email protected]:5060 SIP/2.0 Record-Route:<sip:[email protected]:5060;maddr=192.0.2.4> Via:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK1D38 From:<sip:[email protected]>;tag=3DD33DE4-10DF To:<sip:[email protected]> Date:Mon, 08 Apr 2002 16:58:08 GMT Call-ID:[email protected] Supported:timer 次の行は、UAC が暫定応答が高い信頼性で転送されることが必要としていることを示しています。 Require:100rel Min-SE: 1800 Cisco-Guid:2729535908-1246237142-2148443152-4064420637 User-Agent:Cisco-SIPGateway/IOS-12.x Allow ヘッダーは、UPDATE 方式がサポートされていることを示しています。 Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER CSeq:101 INVITE Max-Forwards:70 Remote-Party-ID:<sip:[email protected]>;party=calling;screen=no;privacy=off Timestamp:1018285088 Contact:<sip:[email protected]:5060> Expires:180 Allow-Events:telephone-event Content-Type:application/sdp Content-Length:262 次の SDP は、メディア ストリームとコーデックを含む最初のオファー、およびメディアを受信するた めの IP アドレスとポートを構成しています。 v=0 26 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 o=CiscoSystemsSIP-GW-UserAgent 6579 1987 IN IP4 192.0.2.14 s=SIP Call c=IN IP4 192.0.2.14 t=0 0 m=audio 17782 RTP/AVP 8 0 18 19 c=IN IP4 192.0.2.14 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:19 CN/8000 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/2.0 100 Trying Via:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK1D38 From:<sip:[email protected]>;tag=3DD33DE4-10DF To:<sip:[email protected]>;tag=24D435A8-C29 Date:Sat, 07 Oct 2000 02:56:34 GMT Call-ID:[email protected] Timestamp:1018285088 Server:Cisco-SIPGateway/IOS-12.x CSeq:101 INVITE Allow-Events:telephone-event Content-Length:0 次の行では、ゲートウェイは、最初のオファーへの応答でアーリー メディア（early media）を送信す ることによって応答しています。 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/2.0 183 Session Progress Via:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK1D38 From:<sip:[email protected]>;tag=3DD33DE4-10DF To:<sip:[email protected]>;tag=24D435A8-C29 Date:Sat, 07 Oct 2000 02:56:34 GMT Call-ID:[email protected] Timestamp:1018285088 Server:Cisco-SIPGateway/IOS-12.x CSeq:101 INVITE Require:100rel RSeq:5785 Allow:UPDATE Allow-Events:telephone-event Contact:<sip:[email protected]:5060> Record-Route:<sip:[email protected]:5060;maddr=192.0.2.4> Content-Disposition:session;handling=required Content-Type:application/sdp Content-Length:191 v=0 o=CiscoSystemsSIP-GW-UserAgent 5565 7580 IN IP4 192.0.2.12 s=SIP Call c=IN IP4 192.0.2.12 t=0 0 m=audio 18020 RTP/AVP 8 19 c=IN IP4 192.0.2.12 a=rtpmap:8 PCMA/8000 a=rtpmap:19 CN/8000 次の行では、UAS が 183 応答に対して PRACK を受信していることを示しています。 1w0d:SIP Msg:ccsipDisplayMsg:Received: 27 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 PRACK sip:[email protected]:5060 SIP/2.0 Via:SIP/2.0/UDP 192.0.2.4:5060;branch=6,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK40A From:<sip:[email protected]>;tag=3DD33DE4-10DF To:<sip:[email protected]>;tag=24D435A8-C29 Date:Mon, 08 Apr 2002 16:58:08 GMT Call-ID:[email protected] CSeq:102 PRACK RAck:5785 101 INVITE Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/2.0 200 OK Via:SIP/2.0/UDP 192.0.2.4:5060;branch=6,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK40A From:<sip:[email protected]>;tag=3DD33DE4-10DF To:<sip:[email protected]>;tag=24D435A8-C29 Date:Sat, 07 Oct 2000 02:56:34 GMT Call-ID:[email protected] Server:Cisco-SIPGateway/IOS-12.x CSeq:102 PRACK Content-Length:0 次の行では、UAS が異なるメディア ストリームとコーデックを持つアップデートされたオファーを受 信していることを示しています。 1w0d:SIP Msg:ccsipDisplayMsg:Received: UPDATE sip:[email protected]:5060 SIP/2.0 Via:SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bK10 Via:SIP/2.0/UDP 192.0.2.14:5060 To:<sip:[email protected]>;tag=24D435A8-C29 From:<sip:[email protected]>;tag=3DD33DE4-10DF Call-ID:[email protected] CSeq:103 UPDATE Contact:sip:[email protected]:5060 Content-Length:262 v=0 o=CiscoSystemsSIP-GW-UserAgent 6579 1987 IN IP4 192.0.2.14 s=SIP Call c=IN IP4 192.0.2.14 t=0 0 m=audio 17782 RTP/AVP 8 0 18 19 c=IN IP4 192.0.2.14 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:19 CN/8000 UPDATE 要求内の新しいオファーはサーバで受け入れ可能なため、サーバは 200 OK メッセージで対 応する応答を使用して応答します。 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/2.0 200 OK Via:SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bK10,SIP/2.0/UDP 192.0.2.14:5060 From:<sip:[email protected]>;tag=3DD33DE4-10DF To:<sip:[email protected]>;tag=24D435A8-C29 Date:Sat, 07 Oct 2000 02:56:34 GMT Call-ID:[email protected] Server:Cisco-SIPGateway/IOS-12.x CSeq:103 UPDATE Content-Type:application/sdp Content-Length:191 28 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 v=0 o=CiscoSystemsSIP-GW-UserAgent 5565 7580 IN IP4 192.0.2.12 s=SIP Call c=IN IP4 192.0.2.12 t=0 0 m=audio 18020 RTP/AVP 8 19 c=IN IP4 192.0.2.12 a=rtpmap:8 PCMA/8000 a=rtpmap:19 CN/8000 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/2.0 200 OK Via:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK1D38 From:<sip:[email protected]>;tag=3DD33DE4-10DF To:<sip:[email protected]>;tag=24D435A8-C29 Date:Sat, 07 Oct 2000 02:56:34 GMT Call-ID:[email protected] Timestamp:1018285088 Server:Cisco-SIPGateway/IOS-12.x CSeq:101 INVITE Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER Allow-Events:telephone-event Contact:<sip:[email protected]:5060> Record-Route:<sip:[email protected]:5060;maddr=192.0.2.4> Content-Type:application/sdp Content-Length:191 v=0 o=CiscoSystemsSIP-GW-UserAgent 5565 7580 IN IP4 192.0.2.12 s=SIP Call c=IN IP4 192.0.2.12 t=0 0 m=audio 18020 RTP/AVP 8 19 c=IN IP4 192.0.2.12 a=rtpmap:8 PCMA/8000 a=rtpmap:19 CN/8000 1w0d:SIP Msg:ccsipDisplayMsg:Received: ACK sip:[email protected]:5060 SIP/2.0 Via:SIP/2.0/UDP 192.0.2.4:5060;branch=7,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK230 From:<sip:[email protected]>;tag=3DD33DE4-10DF To:<sip:[email protected]>;tag=24D435A8-C29 Date:Mon, 08 Apr 2002 16:58:08 GMT Call-ID:[email protected] Max-Forwards:70 CSeq:101 ACK Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Sent: BYE sip:[email protected]:50605060;maddr=192.0.2.4 SIP/2.0 Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bKCA From:<sip:[email protected]>;tag=24D435A8-C29 To:<sip:[email protected]>;tag=3DD33DE4-10DF Date:Sat, 07 Oct 2000 02:56:35 GMT Call-ID:[email protected] User-Agent:Cisco-SIPGateway/IOS-12.x Max-Forwards:70 Route:<sip:[email protected]:5060> Timestamp:970887414 CSeq:101 BYE 29 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Received: SIP/2.0 200 OK Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bKCA From:<sip:[email protected]>;tag=24D435A8-C29 To:<sip:[email protected]>;tag=3DD33DE4-10DF Date:Mon, 08 Apr 2002 16:58:29 GMT Call-ID:[email protected] Server:Cisco-SIPGateway/IOS-12.x Timestamp:970887414 Content-Length:0 CSeq:101 BYE ルーズ ルーティングのコール フローの例 次に、ルーズ ルーティング要求を示すメッセージの例を示します。 1w0d:SIP Msg:ccsipDisplayMsg:Received: INVITE sip:[email protected]:5060 SIP/2.0 次のコール フローの SIP メッセージでは、Request-URI がネクストホップの宛先の SIP URI ではなく、 宛先 UA の SIP URI、つまり SIP プロキシ サーバに設定されています。 Record-Route:<sip:[email protected]:5060;lr;maddr=192.0.2.4> Via:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK2394 From:<sip:[email protected]>;tag=3DD3A404-12A3 To:<sip:[email protected]> Date:Mon, 08 Apr 2002 16:58:34 GMT Call-ID:[email protected] Supported:timer Min-SE: 1800 Cisco-Guid:2991015782-1246237142-2148770832-4064420637 User-Agent:Cisco-SIPGateway/IOS-12.x Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER CSeq:101 INVITE Max-Forwards:70 Remote-Party-ID:<sip:[email protected]>;party=calling;screen=no;privacy=off Timestamp:1018285114 Contact:<sip:[email protected]:5060> Expires:180 Allow-Events:telephone-event Content-Type:application/sdp Content-Length:262 v=0 o=CiscoSystemsSIP-GW-UserAgent 1981 1761 IN IP4 192.0.2.14 s=SIP Call c=IN IP4 192.0.2.14 t=0 0 m=audio 18354 RTP/AVP 8 0 18 19 c=IN IP4 192.0.2.14 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:19 CN/8000 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/2.0 100 Trying Via:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK2394 30 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 From:<sip:[email protected]>;tag=3DD3A404-12A3 To:<sip:[email protected]>;tag=24D49BE8-2346 Date:Sat, 07 Oct 2000 02:57:00 GMT Call-ID:[email protected] Timestamp:1018285114 Server:Cisco-SIPGateway/IOS-12.x CSeq:101 INVITE Allow-Events:telephone-event Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/2.0 180 Ringing Via:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK2394 From:<sip:[email protected]>;tag=3DD3A404-12A3 To:<sip:[email protected]>;tag=24D49BE8-2346 Date:Sat, 07 Oct 2000 02:57:00 GMT Call-ID:[email protected] Timestamp:1018285114 Server:Cisco-SIPGateway/IOS-12.x CSeq:101 INVITE Allow:UPDATE Allow-Events:telephone-event Contact:<sip:[email protected]:5060> Record-Route:<sip:[email protected]:5060;lr;maddr=192.0.2.4> Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/2.0 200 OK Via:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK2394 From:<sip:[email protected]>;tag=3DD3A404-12A3 To:<sip:[email protected]>;tag=24D49BE8-2346 Date:Sat, 07 Oct 2000 02:57:00 GMT Call-ID:[email protected] Timestamp:1018285114 Server:Cisco-SIPGateway/IOS-12.x CSeq:101 INVITE Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER Allow-Events:telephone-event Contact:<sip:[email protected]:5060> Record-Route:<sip:[email protected]:5060;lr;maddr=192.0.2.4> Content-Type:application/sdp Content-Length:191 v=0 o=CiscoSystemsSIP-GW-UserAgent 5181 4737 IN IP4 192.0.2.12 s=SIP Call c=IN IP4 192.0.2.12 t=0 0 m=audio 16720 RTP/AVP 8 19 c=IN IP4 192.0.2.12 a=rtpmap:8 PCMA/8000 a=rtpmap:19 CN/8000 1w0d:SIP Msg:ccsipDisplayMsg:Received: ACK sip:[email protected]:5060 SIP/2.0 Via:SIP/2.0/UDP 192.0.2.4:5060;branch=10,SIP/2.0/UDP 192.0.2.14:5060;branch=z9hG4bK103D From:<sip:[email protected]>;tag=3DD3A404-12A3 To:<sip:[email protected]>;tag=24D49BE8-2346 Date:Mon, 08 Apr 2002 16:58:34 GMT Call-ID:[email protected] 31 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 Max-Forwards:70 CSeq:101 ACK Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Sent: BYE sip:[email protected]:5060 SIP/2.0 Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bK18B6 From:<sip:[email protected]>;tag=24D49BE8-2346 To:<sip:[email protected]>;tag=3DD3A404-12A3 Date:Sat, 07 Oct 2000 02:57:01 GMT Call-ID:[email protected] User-Agent:Cisco-SIPGateway/IOS-12.x Max-Forwards:70 Route:<sip:[email protected]:5060;lr;maddr=192.0.2.4> Timestamp:970887440 CSeq:101 BYE Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Received: SIP/2.0 200 OK Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bK18B6 From:<sip:[email protected]>;tag=24D49BE8-2346 To:<sip:[email protected]>;tag=3DD3A404-12A3 Date:Mon, 08 Apr 2002 16:58:54 GMT Call-ID:[email protected] Server:Cisco-SIPGateway/IOS-12.x Timestamp:970887440 Content-Length:0 CSeq:101 BYE SIP の RFC 3261、RFC 3262、および RFC 3264 への準拠 Internet Engineering Task Force（IETF）は常に SIP 基準のアップデートを行っています。この機能に より、Cisco SIP ゲートウェイに対して実行された特定のアップデートまたは最適化が示され、IETF への準拠が維持されます。次の基準がアップデートされました。 • RFC 3261：SIP 向けのコア基準（RFC 2543 は廃止） • RFC 3262：SIP における暫定応答の信頼性に関する基準 • RFC 3264：Session Description Protocol（SDP）に対するオファー / 応答モデルに関する基準 SIP をご使用のお客様に高品質なサービスを提供するため、シスコは、最新の SIP 関連 RFC に準拠す るよう SIP ゲートウェイを最適化しています。さらに、下位互換性を保持することにより、現在の RFC をまだサポートしていないゲートウェイとの相互運用性を実現します。 ここでは、次の内容について説明します。 • 「SIP メッセージング拡張機能」（P.32） • 「SIP の TCP および UDP 接続に関する拡張機能」（P.33） （P.34） • 「大容量の SIP 要求に対するダイナミック トランスポート スイッチング（UPD から TCP）」 • 「Call-Hold の拡張機能」（P.35） • 「max-forwards コマンドの範囲拡張」（P.35） SIP メッセージング拡張機能 SIP メッセージングに対して、次の変更または追加が行われました。 32 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 • この機能は RFC 3261 に準拠しています。ユーザ エージェント サーバ（UAS）が 2xx 応答を生成 し、確認応答（ACK）を待機していて、サーバ側でコールが切断された場合、UAS はただちに BYE メッセージを送信しません。UAS が BYE メッセージを送信するのは、リトライ タイマーが タイムアウトになった時点、または ACK 応答を受信した時点です。BYE メッセージによりコー ルが終了され、ネットワークのハングが防止されます。 • RFC 3261 に準拠して、ユーザ エージェント（UA）は、発信側ゲートウェイから ACK 応答を受信 するまで BYE メッセージを送信できません。この拡張機能により、200 OK 応答よりも前に BYE 応 答が着信側ゲートウェイに到着した場合に発生する競合状態を避けることができます。この拡張機能 は、通常の切断に適用され、タイムアウトまたはエラーが原因の切断には適用されません。 • ユーザ エージェント クライアント（UAC）では、RFC 3262 に準拠して、Invite 要求に対する Cancel 要求を送信する前に、着信側ゲートウェイからの 1xx 暫定応答（PRACK）を待機するよう になりました。1xx 応答を待機することで、リソースが停滞するのを防止できます。この状態は、 着信側ゲートウェイに Invite メッセージよりも前に Cancel 要求が到着した場合に発生することが あります。 • Cisco SIP ゲートウェイは、RFC 3261 に準拠して、Invite 要求の進行中にダイアログで Invite を 要求するセッション変更を受信した場合に、491 Request Pending 応答を返します。re-Invite を送 信し、491 応答を受信したゲートウェイは、ランダムに選択した値を使用してタイマーを開始しま す。タイマーが満了すると、セッション変更を引き続き希望する場合、ゲートウェイは Invite 要求 を再試行します。 UAC が要求を生成した場合、タイマーには 2.1 ～ 4 秒の範囲（単位：10 ms）でランダムに選択さ れた値が設定されます。UAC が要求を生成していない場合、タイマーには 0 ～ 2 秒の範囲（単 位：10 ms）でランダムに選択された値が設定されます。 SIP の TCP および UDP 接続に関する拡張機能 RFC 3261 以前は、SIP ユーザ エージェントでは、TCP サポートはオプションでした。現在、 RFC 3261 では UDP および TCP のどちらのサポートも要求されます。Cisco SIP ゲートウェイではす でに TCP がサポートされていて、次に示すとおりいくつかの最適化方法が用意されています。 • 「2xx 応答の送信失敗」（P.33） • 「TCP および UDP 接続の再利用」（P.33） • 「トランザクション ベースの転送のスイッチングと使用方法」（P.34） • 「リモート エンドの接続閉鎖の検出」（P.34） • 「元の接続がドロップされた場合に応答を送信するための新しい接続の作成」（P.34） 2xx 応答の送信失敗 2xx 応答は RFC 3261 に準拠しています。トランスポート プロトコルに TCP を使用しており、ゲート ウェイが INVITE メッセージに対して送信した 2xx 応答への確認応答を受信していない場合、ゲート ウェイは TCP を介して 2xx 応答の送信を再試行します。再試行によって、ゲートウェイは確実に 200 OK メッセージを受信します。これにより、ネットワーク上のホップが信頼できないトランスポート プ ロトコル（UDP など）を使用した場合に 2xx 応答が失われる可能性が排除されます。 TCP および UDP 接続の再利用 RFC 3261 以前は、リモート ゲートウェイは同じ TCP 接続上で 2 つの要求を開始できませんでした。 さらにゲートウェイは、新しい各トランザクションに対して新しい接続を作成し、トランザクション終 了後に接続を閉じていました。接続を閉じると、後続の要求が前回のトランザクションと同じ場所を宛 先としていても、開いている / 閉じている不要な多数の接続が原因でパフォーマンスが低下します。 Cisco IOS リリース 12.3(8)T では、ゲートウェイは、リモート IP アドレスとポートにつき 1 つの TCP 33 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 接続を開きます。ゲートウェイは、特定の宛先 IP アドレスとポートが存在していない場合に限り、新 しい接続を開きます。その接続を使用するすべての要求が終了し、指定された期間アクティビティが検 出されない場合、ゲートウェイは接続を閉じます。 timers connection コマンドを使用して、非アクティビティによる TCP または UDP 接続をタイムアウ トできます。 トランザクション ベースの転送のスイッチングと使用方法 Cisco IOS リリース 12.3(8)T では、新しいトランザクション要求がスイッチング可能なしきい値を超 えた場合、TCP 経由で送信されます。スイッチング可能なしきい値は、インターフェイスまたはパス の Maximum Transmission Unit（MTU; 最大伝送ユニット）を 200 バイト以上上回る値です。メッ セージ サイズがスイッチング可能なしきい値より小さい場合、設定されている元の転送が使用されま す。元の転送とは、最初の Invite 要求に対してダイヤル ピア下で設定された転送、または後続の要求 内の着信応答の Contact または Record-Route ヘッダーで指定されている転送です。言い換えれば、転 送の使用方法は現在、コール ベースでなくトランザクション ベースになっていることを意味します。 リモート エンドの接続閉鎖の検出 リモート ゲートウェイの閉鎖が未検出の状態の場合、TCP 接続がハングするおそれがあります。終了 した接続が未検出の状態の場合、対応する接続エントリは接続テーブルから削除されません。未検出の 閉鎖が連続して発生すると、接続テーブルが無効なエントリと、拒否されている有効な SIP 要求でいっ ぱいになり、ルータのリブートが必要になります。Cisco IOS リリース 12.3(8)T では、SIP ゲートウェ イは内部メカニズムを使用して、リモート閉鎖を検出し、接続テーブルをクリーンアップします。ク リーンアップの開始には、ユーザによる入力は必要ありません。 元の接続がドロップされた場合に応答を送信するための新しい接続の作成 Cisco IOS リリース 12.3(8)T では、応答が送信される前にゲートウェイが着信要求の接続を切断した 場合、受信側ゲートウェイは新しい接続を作成して、応答を送信します。新しい接続は、Via ヘッダー の sent-by パラメータで指定されているポートをベースにします。Cisco IOS リリース 12.3(8)T 以前の リリースでは、接続がドロップされた結果、コールの失敗となっていました。 大容量の SIP 要求に対するダイナミック トランスポート スイッチング（UPD から TCP） RFC 3261 では、大容量の SIP 要求（最大伝送ユニット（MTU）が 200 バイト以内の要求）は TCP を 介して伝送する必要があることが記載されています。TCP を介した転送により、UDP のフラグメン テーションが回避され、ゲートウェイが UDP を使用する設定されている場合であっても TCP への切 り替えが行われます。TCP 送信が失敗した場合（たとえば、着信側ゲートウェイが TCP をサポートし ていない場合など）、メッセージは UDP を介して再試行されます。 イーサネットまたはファスト イーサネット インターフェイス上で MTU サイズを設定する機能を、 Cisco SIP ゲートウェイはすでに備えています。MTU が設定されていない場合、デフォルトの MTU 値 は 1500 バイトです。MTU が 1500 バイトであると想定すると、1300 バイトを超える要求は、ダイナ ミック トランスポート スイッチングのしきい値と見なされます。 2 つのコマンドを使用して、ダイナミック スイッチングのサポートをイネーブルまたはディセーブルに できます。このコマンドを使用して、TCP をサポートしないゲートウェイに関する相互運用性の問題 を回避し、下位互換性を維持します。transport switch コマンドはグローバル レベルで設定でき、 voice-class sip transport switch コマンドはダイヤル ピア レベルで設定できます。グローバル設定は、 一致する VoIP ダイヤル ピアがない場合に限り、考慮されます。 この機能は、デフォルトではディセーブルになっています。 34 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 Call-Hold の拡張機能 RFC 3264 では、call-hold を SDP で方向アトリビュート（a=sendonly）を使用して開始することを推 奨しています。Cisco SIP ゲートウェイは新しいガイドラインに従っており、SIP ゲートウェイは次の 2 つの方法のいずれかを使用して call-hold を開始できるようになりました。offer call-hold コマンドを 使用して、call-hold を開始するための形式をグローバルに指定できます。つまり、ゲートウェイは a=sendonly または conn addr=0.0.0.0 を使用する必要があり、使用方法を両方には設定できません。デ フォルト設定は、RFC の推奨方式である a=sendonly です。call-hold の形式は、ダイヤル ピア レベル では指定できません。 （注） Cisco SIP ゲートウェイは、2 つの形式のいずれかでの call-hold 要求の受信をサポートしていますが、 方向アトリビュートの使用を推奨します。 max-forwards コマンドの範囲拡張 RFC 3261 に準拠して、max-forwards コマンドは、設定範囲の拡大（1 ～ 70）およびデフォルト値の 増加（70）によって拡張されました。 SIP の FC 準拠の設定方法 ここでは、次の各手順について説明します。 • 「RFC 2543 への準拠の設定」（P.35） • 「RFC 2782 への準拠の設定」（P.35） • 「RFC 3261 への準拠の設定」（P.36） • 「RFC 3261、RFC 3262、および RFC 3264 への準拠の設定」（P.36） • 「SIP の RFC 準拠の確認」（P.42） • 「トラブルシューティングのヒント」（P.45） （注） • 各手順を実行する前に、次の情報を理解してください。 – 「SIP の RFC 準拠の前提条件」（P.2） – 「SIP の RFC 準拠の制約事項」（P.3） • 手順の支援情報については、上記の検証およびトラブルシューティングの項を参照してください。 RFC 2543 への準拠の設定 RFC 2543 をイネーブルにするために必要な設定作業はありません。デフォルトではイネーブルになっ ています。 RFC 2782 への準拠の設定 RFC 2782 への準拠を設定するには、次の手順を実行します。 35 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 手順の概要 1. enable 2. configure terminal 3. sip-ua 4. srv version 5. exit 手順の詳細 コマンドまたはアクション ステップ 1 enable 目的 特権 EXEC モードをイネーブルにします。プロンプトが表 示されたら、パスワードを入力します。 例： Router> enable ステップ 2 configure terminal グローバル コンフィギュレーション モードを開始します。 例： Router# configure terminal ステップ 3 sip-ua SIP ユーザ エージェント コンフィギュレーション モード を開始します。 例： Router(config)# sip-ua ステップ 4 srv version {1 | 2} RFC 2052 または RFC 2782 の形式を使用して DNS SRV クエリーを生成します。キーワードは次のとおりです。 例： Router(config-sip-ua)# srv version 2 • 1：ドメイン名のプレフィクス形式 「protocol.transport.」（RFC 2052 形式） • 2：ドメイン名のプレフィクス形式 「_protocol._transport.」（RFC 2782 形式） デフォルト：2。 ステップ 5 exit 現在のモードを終了します。 例： Router(config-sip-ua)# exit RFC 3261 への準拠の設定 RFC 3261 をイネーブルにするために必要な設定作業はありません。デフォルトではイネーブルになっ ています。 RFC 3261、RFC 3262、および RFC 3264 への準拠の設定 ここでは、次の各手順について説明します。 • 「SIP メッセージングの設定」（P.37） 36 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 • 「TCP および UDP 接続機能の設定」（P.37） • 「大容量の SIP 要求に対するダイナミック トランスポート スイッチング（UPD から TCP）の設定」 （P.38） • 「Call-Hold の設定」（P.41） • 「Max Forwards の設定」（P.42） SIP メッセージングの設定 設定は必要ありません。 TCP および UDP 接続機能の設定 非アクティビティのため SIP UA が TCP または UDP 接続を期限切れにするまでの時間を設定するに は、次の手順を実行します。 手順の概要 1. enable 2. configure terminal 3. sip-ua 4. timers connection aging 5. exit 手順の詳細 コマンドまたはアクション ステップ 1 enable 目的 特権 EXEC モードをイネーブルにします。プロンプトが表 示されたら、パスワードを入力します。 例： Router> enable ステップ 2 configure terminal グローバル コンフィギュレーション モードを開始します。 例： Router# configure terminal ステップ 3 sip-ua SIP ユーザ エージェント コンフィギュレーション モード を開始します。 例： Router(config)# sip-ua 37 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 コマンドまたはアクション ステップ 4 timers connection aging timer-value 例： Router(config-sip-ua)# timers connection aging 5 ステップ 5 exit 目的 非アクティビティのため SIP UA が TCP または UDP 接続 を期限切れにするまでの時間を設定します。引数は次のと おりです。 • timer-value：待機する時間（分）。範囲：5 ～ 30。デ フォルト：5。 現在のモードを終了します。 例： Router(config-sip-ua)# exit 大容量の SIP 要求に対するダイナミック トランスポート スイッチング（UPD から TCP）の設 定 RFC 3261 では、大容量の SIP 要求（最大伝送ユニット（MTU）が 200 バイト以内）は TCP を介して 伝送する必要があることが記載されています。TCP を介した転送により、UDP のフラグメンテーショ ンが回避され、ゲートウェイが UDP を使用する設定されている場合であっても TCP への切り替えが 行われます。 次に示す設定では、UDP から TCP へ切り替えるためのゲートウェイの設定について説明します。イン ターフェイスの MTU 設定がデフォルトの 1500 バイトであると想定します。設定後、しきい値は 1300 バイトとなります。つまり、1300 バイトを超えるすべての SIP 要求に対して、TCP が転送メカニズム となります。 ダイナミック トランスポート スイッチングは、ダイヤル ピア ベースまたはグローバル ベースで設定 できます。 • 「大容量の SIP 要求に対するダイナミック トランスポート スイッチングのダイヤル ピア ベースで の設定」（P.38） • 「大容量の SIP 要求に対するダイナミック トランスポート スイッチングのグローバル ベースでの 設定」（P.39） 大容量の SIP 要求に対するダイナミック トランスポート スイッチングのダイヤル ピア ベースでの設定 特定のダイヤル ピアに対して UDP および TCP 転送メカニズム間のスイッチングを設定するには、次 の手順を実行します。 （注） • UDP から TCP へのダイナミック トランスポート スイッチングは、デフォルトではディセーブル になっています。 • ダイヤル ピアの音声コンフィギュレーション モードでダイナミック トランスポート スイッチング がイネーブルに設定されている場合、この設定がグローバル設定より優先されます。 手順の概要 1. enable 2. configure terminal 3. dial-peer voice voip 4. voice-class sip transport switch udp tcp 38 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 5. exit 手順の詳細 コマンドまたはアクション ステップ 1 enable 目的 特権 EXEC モードをイネーブルにします。プロンプトが表 示されたら、パスワードを入力します。 例： Router> enable ステップ 2 configure terminal グローバル コンフィギュレーション モードを開始します。 例： Router# configure terminal ステップ 3 dial-peer voice tag voip 特定の VoIP ダイヤルピアで、ダイヤルピア コンフィギュ レーション モードを開始します。 例： Router(config)# dial-peer voice 25 voip ステップ 4 voice-class sip transport switch udp tcp 例： Router(config-dial-peer)# voice-class sip transport switch udp tcp 特定のダイヤル ピアに対して、大容量の SIP 要求に関する UDP および TCP 転送メカニズム間でのスイッチングをイ ネーブルにします。キーワードは次のとおりです。 • udp：MTU サイズを超えている SIP 要求のサイズに基 づいて、UDP から転送を切り替えます。 • tcp：転送を TCP に切り替えます。 ステップ 5 exit 現在のモードを終了します。 例： Router(config-dial-peer)# exit 大容量の SIP 要求に対するダイナミック トランスポート スイッチングのグローバル ベースでの設定 Cisco SIP ゲートウェイのすべての接続に対して UDP および TCP 転送メカニズム間のスイッチングを 設定するには、次の手順を実行します。 （注） • UDP から TCP へのダイナミック トランスポート スイッチングは、デフォルトではディセーブル になっています。 • ダイヤル ピアの音声コンフィギュレーション モードでダイナミック トランスポート スイッチング がイネーブルに設定されている場合、この設定がグローバル設定より優先されます。一致する VoIP ダイヤル ピアがない場合に限り、次に示すグローバル設定を考慮してください。 手順の概要 1. enable 2. configure terminal 3. voice service voip 4. sip 39 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 5. transport switch udp tcp 6. exit 手順の詳細 コマンドまたはアクション ステップ 1 enable 目的 特権 EXEC モードをイネーブルにします。プロンプトが表 示されたら、パスワードを入力します。 例： Router> enable ステップ 2 configure terminal グローバル コンフィギュレーション モードを開始します。 例： Router# configure terminal ステップ 3 voice service voip 音声サービス コンフィギュレーション モードを開始しま す。 例： Router(config)# voice service voip ステップ 4 sip SIP コンフィギュレーション モードを開始します。 例： Router(config-voi-srv)# sip ステップ 5 transport switch udp tcp 例： Router(conf-serv-sip)# transport switch udp tcp 大容量の SIP 要求に関する UDP および TCP 転送メカニズ ム間でのスイッチングをグローバルにイネーブルにしま す。キーワードは次のとおりです。 • udp：MTU サイズを超えている SIP 要求のサイズに基 づいて、UDP から転送を切り替えます。 • tcp：転送を TCP に切り替えます。 ステップ 6 exit 現在のモードを終了します。 例： Router(conf-serv-sip)# exit （注） 次のコマンドを使用すると、SIP の転送および接続設定の確認やトラブルシューティングに役立ちま す。 • debug ccsip transport • show sip-ua connections 上記コマンドおよび確認やトラブルシューティング用のその他のコマンドの詳細については、「SIP の RFC 準拠の確認」（P.42）および「トラブルシューティングのヒント」（P.45）を参照してください。 40 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 Call-Hold の設定 SIP ゲートウェイによる call-hold 要求の開始方法を指定するには、次の手順を実行します。 手順の概要 1. enable 2. configure terminal 3. sip-ua 4. offer call-hold 5. exit 手順の詳細 コマンドまたはアクション ステップ 1 enable 目的 特権 EXEC モードをイネーブルにします。プロンプトが表 示されたら、パスワードを入力します。 例： Router> enable ステップ 2 configure terminal グローバル コンフィギュレーション モードを開始します。 例： Router# configure terminal ステップ 3 sip-ua SIP ユーザ エージェント コンフィギュレーション モード を開始します。 例： Router(config)# sip-ua ステップ 4 offer call-hold {conn-addr | direction-attr} 例： Router(config-sip-ua)# offer call-hold direction-attr SIP ゲートウェイによる call-hold 要求の開始方法を指定し ます。キーワードは次のとおりです。 • conn-addr：call-hold 要求を開始するのに接続アドレ スを使用する RFC 2543/RFC 3261 方式。0.0.0.0. を使 用します。 • direction-attr：call-hold 要求を開始するのに方向ア トリビュートを使用する RFC 3264 方式。SDP で方向 アトリビュートを使用します。 ステップ 5 exit 現在のモードを終了します。 例： Router(config-sip-ua)# exit 41 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 Max Forwards の設定 SIP 要求を転送できるプロキシ サーバまたはリダイレクト サーバの最大数を設定するには、次の手順 を実行します。 手順の概要 1. enable 2. configure terminal 3. sip-ua 4. max-forwards 5. exit 手順の詳細 コマンドまたはアクション ステップ 1 enable 目的 特権 EXEC モードをイネーブルにします。プロンプトが表 示されたら、パスワードを入力します。 例： Router> enable ステップ 2 configure terminal グローバル コンフィギュレーション モードを開始します。 例： Router# configure terminal ステップ 3 sip-ua SIP ユーザ エージェント コンフィギュレーション モード を開始します。 例： Router(config)# sip-ua ステップ 4 max-forwards number 例： Router(config-sip-ua)# max-forwards 65 ステップ 5 exit ホップ、つまり SIP 要求を転送できるプロキシ サーバまた はリダイレクト サーバの最大数を設定します。引数は次の とおりです。 • number：転送数。範囲：1 ～ 70。デフォルト：70。 現在のモードを終了します。 例： Router(config-sip-ua)# exit SIP の RFC 準拠の確認 SIP RFC 準拠を確認するには、必要に応じて次の手順を実行します（コマンドは、アルファベット順 に示しています）。 （注） 42 通常の確認シーケンスには、show sip-ua connections コマンドのいずれかを使用してコールの統計情 報を表示し、続いて clear sip-ua tcp connection または clear sip-ua udp connection コマンドを適切 に使用することで統計情報をクリアします。 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 手順の概要 1. show sip-ua connections 2. show sip-ua statistics 手順の詳細 ステップ 1 show sip-ua connections コールが行われた後、このコマンドを使用して、接続の詳細を確認します。 次の出力例では、複数の宛先に対する複数のコールを示します。この例では UDP の詳細を示していま すが、コマンド出力は TCP コールと同様です。 Router# show sip-ua connections udp detail Total active connections : 2 No. of send failures : 0 No. of remote closures : 0 No. of conn. failures : 0 No. of inactive conn. ageouts : 0 ---------Printing Detailed Connection Report--------Note: ** Tuples with no matching socket entry - Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port>' to overcome this error condition ++ Tuples with mismatched address/port entry - Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port> id <connid>' to overcome this error condition Remote-Agent:172.18.194.183, Connections-Count:1 Remote-Port Conn-Id Conn-State WriteQ-Size =========== ======= =========== =========== 5060 1 Established 0 Remote-Agent:172.19.154.18, Connections-Count:1 Remote-Port Conn-Id Conn-State WriteQ-Size =========== ======= =========== =========== 5060 2 Established 0 次の出力例では、特定のターゲット（この場合は 172.18.194.183 、ポート 5060）への接続に関する シーケンシャル表示とコール統計情報のクリアを示します。 注意 clear コマンドを使用する際は注意が必要です。コマンドについての問題または影響を理解しない で不適切に使用すると、誤ったコール動作、不適切な接続の使用、および接続失敗を招くおそれが あります。 1. show sip-ua connections コマンドの出力には、コール統計情報が表示されます。 Router# show sip-ua connections tcp detail Total active connections : 1 No. of send failures : 0 No. of remote closures : 0 No. of conn. failures : 0 No. of inactive conn. ageouts : 0 Max. tcp send msg queue size of 1, recorded for 172.18.194.183:5060 ---------Printing Detailed Connection Report--------Note: ** Tuples with no matching socket entry - Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port>' to overcome this error condition 43 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 ++ Tuples with mismatched address/port entry - Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port> id <connid>' to overcome this error condition Remote-Agent:172.18.194.183, Connections-Count:1 Remote-Port Conn-Id Conn-State WriteQ-Size =========== ======= =========== =========== 5060 1 Established 0 2. clear sip-ua tcp connection コマンドの出力には、統計情報がクリアされていることが示されま す。 Router# clear sip-ua tcp connection id 1 target ipv4:172.18.194.183:5060 Purging the entry from sip tcp process Purging the entry from reusable global connection table 3. show sip-ua connections コマンドの出力では、すべての接続が想定どおりにクリアされているこ とを確認します。 Router# show sip-ua connections tcp detail Total active connections : 0 No. of send failures : 0 No. of remote closures : 0 No. of conn. failures : 0 No. of inactive conn. ageouts : 0 Max. tcp send msg queue size of 1, recorded for 172.18.194.183:5060 ---------Printing Detailed Connection Report--------Note: ** Tuples with no matching socket entry - Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port>' to overcome this error condition ++ Tuples with mismatched address/port entry - Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port> id <connid>' to overcome this error condition Remote-Agent:172.18.194.183, Connections-Count:0 ステップ 2 show sip-ua statistics このコマンドを使用して、UPDATE 要求を含む SIP 統計情報を表示します。 Router# show sip-ua statistics SIP Response Statistics (Inbound/Outbound) Informational Trying 1/4, Ringing 0/0, Forwarded 0/0, Queued 0/0, SessionProgress 1/4 Success: OkInvite 1/2, OkBye 1/2, OkCancel 0/2, OkOptions 0/0, OkPrack 1/4, OkPreconditionMet 0/0, OkSubscribe 0/0, OkNotify 0/0, OkInfo 0/0, 202Accepted 0/0, OkUpdate 0/0 Redirection (Inbound only): MultipleChoice 0, MovedPermanently 0, MovedTemporarily 0, UseProxy 0, AlternateService 0 Client Error: BadRequest 0/0, Unauthorized 0/0, PaymentRequired 0/0, Forbidden 0/0, NotFound 0/0, MethodNotAllowed 0/0, NotAcceptable 0/0, ProxyAuthReqd 0/0, 44 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 ReqTimeout 0/0, Conflict 0/0, Gone 0/0, ReqEntityTooLarge 0/0, ReqURITooLarge 0/0, UnsupportedMediaType 0/0, BadExtension 0/0, TempNotAvailable 0/0, CallLegNonExistent 0/0, LoopDetected 0/0, TooManyHops 0/0, AddrIncomplete 0/0, Ambiguous 0/0, BusyHere 0/0, RequestCancel 0/2, NotAcceptableMedia 0/0, BadEvent 0/0, SETooSmall 0/0, RequestPending 0/0 Server Error: InternalError 0/0, NotImplemented 0/0, BadGateway 0/0, ServiceUnavail 2/0, GatewayTimeout 0/0, BadSipVer 0/0, PreCondFailure 0/0 Global Failure: BusyEverywhere 0/0, Decline 0/0, NotExistAnywhere 0/0, NotAcceptable 0/0 Miscellaneous counters: RedirectRspMappedToClientErr 0 SIP Total Traffic Statistics (Inbound/Outbound) Invite 4/4, Ack 4/3, Bye 2/1, Cancel 2/0, Options 0/0, Prack 4/1, Comet 0/0, Subscribe 0/0, Notify 0/0, Refer 0/0, Info 0/0, Update 0/0 Retry Statistics Invite 1, Bye 0, Cancel 0, Response 0, Prack 0, Comet 0, Reliable1xx 0, Notify 0 SDP application statistics: Parses: 6, Builds 10 Invalid token order: 0, Invalid param: 0 Not SDP desc: 0, No resource: 0 Last time SIP Statistics were cleared: <never> トラブルシューティングのヒント （注） 一般的なトラブルシューティングのヒント、および重要な debug コマンドについては、「一般的なトラ ブルシューティングのヒント」（P.18）を参照してください。 • SIP 関連のデバッグをイネーブルにするには、debug ccsip all コマンドを使用します。 • debug ccsip transport コマンドを使用して、Invite メッセージを送信すると同時に、転送および 接続に関連する操作をデバッグします。 これらのコマンドの一部の出力例を、次に示します。 debug ccsip transport コマンドの出力例 ここで取り上げる操作は、次の内容を示しています。 • 接続が確立されており、Invite が送信されていること。 • 最初の Invite メッセージが UDP を介して転送されていること。 • リモート ターゲットつまり要求の送信先の詳細。 45 SIP の RFC 準拠の実現 SIP の RFC 準拠の設定例 • メッセージのサイズが MTU のしきい値サイズを超えていること。このため、トランスポート ス イッチング（UDP から TCP へ）がイネーブルになっていること。 • 接続アルゴリズムが開始されている、つまり、非アクティビティが発生した場合、TCP または UDP 接続を期限切れにするためのカウンタが開始されていること。 Router# debug ccsip transport . . . 1w1d: //18/8E16980D800A/SIP/Transport/sipSPISendInvite: Sending Invite to the transport layer 1w1d: //18/8E16980D800A/SIP/Transport/sipSPIGetSwitchTransportFlag: Return the Global configuration, Switch Transport is TRUE 1w1d: //18/8E16980D800A/SIP/Transport/sipSPITransportSendMessage: msg=0x64082D50, addr=172.18.194.183, port=5060, sentBy_port=0, is_req=1, transport=1, switch=1, callBack=0x614FAB58 1w1d: //18/8E16980D800A/SIP/Transport/sipSPITransportSendMessage: Proceedable for sending msg immediately 1w1d: //18/8E16980D800A/SIP/Transport/sipTransportLogicSendMsg: switch transport is 1 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportGetInterfaceMtuSize: MTU size for remote address 172.18.194.183 is 500 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportVerifyMsgForMTUThreshold: Interface MTU Size 500, Msg Size 1096 1w1d: //18/8E16980D800A/SIP/Transport/sipTransportLogicSendMsg: Switching msg=0x64082D50 transport UDP->TCP 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportSetAgeingTimer: Aging timer initiated for holder=0x64084058,addr=172.18.194.183 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnHolder: Created new holder=0x64084058, addr=172.18.194.183 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostRequestConnection: Posting TCP conn create request for addr=172.18.194.183, port=5060, context=0x64128D5C 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportSetConnWaitTimer: Wait timer set for connection=0x64129BF4,addr=172.18.194.183, port=5060 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnInstance: Created new initiated conn=0x64129BF4, connid=-1, addr=172.18.194.183, port=5060, transport=tcp 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: gConnTab=0x64128D5C, addr=172.18.194.183, port=5060, connid=1, transport=tcp 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipInstanceHandleConnectionCreated: Moving connection=0x64129BF4, connid=1state to pending 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWConnectionCreated: context=0x64128D5C 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: gConnTab=0x64128D5C, addr=172.18.194.183, port=5060, connid=1, transport=tcp 1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting send for msg=0x64082D50, addr=172.18.194.183, port=5060, connId=1 for TCP . . . SIP の RFC 準拠の設定例 ここでは、次の設定例について説明します。 • 「RFC 3261、RFC 3262、および RFC 3264 に対する SIP ゲートウェイの準拠」（P.47） （注） 46 例に示す IP アドレスおよびホスト名は架空のものです。 SIP の RFC 準拠の実現 SIP の RFC 準拠の設定例 RFC 3261、RFC 3262、および RFC 3264 に対する SIP ゲートウェイの 準拠 ここでは、前の項で説明した設定作業に対応する設定例を示します。 1w1d: %SYS-5-CONFIG_I: Configured from console by console Building configuration... Current configuration : 3326 bytes ! !Last configuration change at 18:09:20 EDT Fri Apr 23 2004 ! version 12.3 service timestamps debug uptime service timestamps log uptime no service password-encryption boot-start-marker boot system tftp mantis/c3640-is-mz.disc_w_pi 172.18.207.10 boot-end-marker ! clock timezone EST -5 clock summer-time EDT recurring voice-card 3 ! aaa new-model ! aaa accounting connection h323 start-stop group radius aaa nas port extended aaa session-id common ip subnet-zero ! ip cef ip host example.com 172.18.194.183 ip host CALLGEN-SECURITY-V2 10.36.54.81 10.1.0.0 ip name-server 172.18.192.48 ! isdn switch-type primary-ni ! trunk group 1 ! voice service voip sip rel1xx require "100rel" transport switch udp tcp ! voice class uri 800 sip pattern [email protected] ! controller T1 3/0 framing sf linecode ami pri-group timeslots 1-24 ! controller T1 3/1 framing sf linecode ami pri-group timeslots 1-24 gw-accounting aaa ! interface Ethernet0/0 description CentreComm Hub port 9 in PP070 ip address 172.18.194.170 255.255.255.0 47 SIP の RFC 準拠の実現 SIP の RFC 準拠の設定例 no ip proxy-arp ip mtu 500 half-duplex no cdp enable ip rsvp bandwidth 100 100 ! interface Serial3/0:23 no ip address no logging event link-status isdn switch-type primary-ni isdn incoming-voice voice no cdp enable ! interface Serial3/1:23 no ip address no logging event link-status isdn switch-type primary-ni isdn protocol-emulate network isdn incoming-voice voice no cdp enable ! no ip http server ip classless ip route 0.0.0.0 0.0.0.0 172.18.194.1 ip route 0.0.0.0 0.0.0.0 Ethernet0/0 ip route 10.0.0.0 255.0.0.0 172.18.194.1 ip route 172.16.0.0 255.0.0.0 Ethernet0/0 ! dialer-list 1 protocol ip permit no cdp run ! radius-server host 10.13.84.133 auth-port 1645 acct-port 1646 radius-server timeout 2 radius-server key cisco radius-server vsa send accounting radius-server vsa send authentication ! control-plane ! call application voice testapp79 tftp://172.18.207.10/mantis/my_app.tcl call application voice testapp888 tftp://172.18.207.10/mantis/AL_FEAT_SIP_URL_O_RV_79.tcl call application voice testapp888 mcid-dtmf 9876 call application voice testapp888 test 5444 ! voice-port 1/1/0 ! voice-port 1/1/1 ! voice-port 3/0:23 ! voice-port 3/1:23 ! dial-peer cor custom ! dial-peer voice 9876 voip destination-pattern 9876 voice-class sip transport switch udp tcp session protocol sipv2 session target ipv4:172.18.194.183 session transport udp ! dial-peer voice 222 pots incoming called-number . direct-inward-dial 48 SIP の RFC 準拠の実現 SIP の RFC 準拠の設定例 ! sip-ua max-forwards 65 retry invite 4 retry bye 4 retry cancel 4 retry comet 4 retry notify 4 timers connection aging 15 offer call-hold conn-addr ! line con 0 exec-timeout 0 0 line vty 0 4 password password1 ntp clock-period 17179695 ntp server 172.18.194.178 ntp server 10.81.254.131 ! end 49 SIP の RFC 準拠の実現 その他の参考資料 その他の参考資料 関連資料 関連項目 参照先 『Cisco IOS SIP Configuration Guide』の「Features Roadmap」の章 http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide /sip_cg-roadmap.html 『Cisco IOS SIP Configuration Guide』の「Overview of SIP 」の章 http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide /sip_cg-overview.html 『Cisco IOS Tcl IVR and VoiceXML Application Guide』 Cisco IOS リリース 12.3(14)T 以降： http://www.cisco.com/en/US/docs/ios/voice/ivr/configuration/guide /tcl_c.html 12.3(14)T よりも前の Cisco IOS リリース： http://www.cisco.com/en/US/docs/ios/voice/ivr/pre12.3_14_t/confi guration/guide/ivrapp.pdf 『Cisco IOS Voice Command Reference』 http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr _book.html 『Cisco Unified Communications Manager Express Command Reference』 http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/comman d/reference/cme_cr.html Cisco Unified Communications Manager Express のサ http://www.cisco.com/en/US/products/sw/voicesw/ps4625/tsd_prod ucts_support_series_home.html ポート ドキュメント 『Cisco Unified SIP SRST System Administrator Guide』 http://www.cisco.com/en/US/docs/voice_ip_comm/cusrst/admin/sip srst/configuration/guide/spsrst41.html 『Cisco VoiceXML Programmer's Guide』 http://www.cisco.com/en/US/docs/ios/voice/vxml/developer/guide/ vxmlprg.html 『SIP Gateway Support of RSVP and TEL URL』 http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ vvfresrv.html 『Tcl IVR API Version 2.0 Programming Guide』 http://www.cisco.com/en/US/docs/ios/voice/tcl/developer/guide/tcli vrv2.html 規格 規格 国際標準化機構（ISO）仕様、ISO 639 タイトル 「Codes for Representation of Names of Languages 」 MIB MIB MIB リンク なし 選択したプラットフォーム、Cisco IOS リリース、および機能セッ トの MIB を検索してダウンロードする場合は、次の URL にある Cisco MIB Locator を使用します。 http://www.cisco.com/go/mibs 50 SIP の RFC 準拠の実現 その他の参考資料 RFC RFC タイトル RFC 2833 「RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals」 RFC 3261 「SIP: Session Initiation Protocol」 RFC 3262 「Reliability of Provisional Responses in the Session Initiation Protocol (SIP)」 RFC 3264 「An Offer/Answer Model with the Session Description Protocol (SDP)」 RFC 3265 「Session Initiation Protocol (SIP)-Specific Event Notification」 RFC 3312 「Integration of Resource Management and Session Initiation Protocol (SIP)」 RFC 3323 「A Privacy Mechanism for the Session Initiation Protocol (SIP)」 RFC 3325 「Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks」 RFC 3326 「The Reason Header Field for the Session Initiation Protocol (SIP)」 RFC 4028 「Session Timers in the Session Initiation Protocol (SIP)」 RFC 4244 「An Extension to the Session Initiation Protocol (SIP) for Request History Information」 51 SIP の RFC 準拠の実現 その他の参考資料 シスコのテクニカル サポート 説明 リンク Cisco Support Web サイトには、資料やツールなど幅 http://www.cisco.com/techsupport 広いオンライン リソースが用意されており、シスコの 製品およびテクノロジーに関するトラブルシューティ ングや技術的な問題の解決などに役立てることができ ます。 以下を含むさまざまな作業にこの Web サイトが役立 ちます。 • テクニカル サポートを受ける • ソフトウェアをダウンロードする • セキュリティの脆弱性を報告する、またはシスコ 製品のセキュリティ問題に対する支援を受ける • ツールおよびリソースへアクセスする • Product Alert の受信登録 • Field Notice の受信登録 • Bug Toolkit を使用した既知の問題の検索 • Networking Professionals（NetPro）コミュニ ティで、技術関連のディスカッションに参加する • トレーニング リソースへアクセスする • TAC Case Collection ツールを使用して、ハード ウェアや設定、パフォーマンスに関する一般的な 問題をインタラクティブに特定および解決する Japan テクニカル サポート Web サイトでは、Technical Support Web サイト （http://www.cisco.com/techsupport） の、利用頻度の高いドキュメントを日本語で提供してい ます。Japan テクニカル サポート Web サイトには、次の URL からアクセスしてください。 http://www.cisco.com/jp/go/tac CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0910R) このマニュアルで使用している IP アドレスおよび電話番号は、実際のアドレスおよび電話番号を示すものではありません。マニュアル 内の例、コマンド出力、ネットワーク トポロジ図、およびその他の図は、説明のみを目的として使用されています。説明の中に実際の アドレスおよび電話番号が使用されていたとしても、それは意図的なものではなく、偶然の一致によるものです。 © 2002–2009 Cisco Systems, Inc. All rights reserved. 52 SIP の RFC 準拠の実現 その他の参考資料 Copyright © 2002–2010, シスコシステムズ合同会社 . All rights reserved. 53 SIP の RFC 準拠の実現 その他の参考資料 54