SIP の RFC 準拠の実現

Transcription

1 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 の章を参照してください 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 ( 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 として発行 ) への準拠を実現するために導入されました

2 機能情報の確認 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 には からアクセスしてください 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 の章を参照してください 2

3 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

4 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 SIP ヘッダーフィールド ヘッダーフィールド Accept Accept-Encoding シスコゲートウェイによるサポートの有無あり OPTIONS 応答メッセージで使用 なし 4

5 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

6 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

7 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 3 SIP 方式 方式 ACK BYE CANCEL COMET INVITE INFO NOTIFY OPTIONS PRACK REFER REGISTER SUBSCRIBE UPDATE シスコゲートウェイによるサポートの有無あり 廃止 条件に合致 Quality of Service(QoS) 実装で使用され もう一方のエンドポイントに対して 条件が満たされているかどうか つまり適切なリソースが予約されているかどうかを示します あり SIP ゲートウェイは 同じコール ID を持つが Session Description Protocols(SDP) セッションパラメータの異なるミッドコール Invite 要求 ( 転送アドレスを変更するため ) をサポートします ミッドコール INVITE 要求は ポート番号やコーデックの変更 またはセッションのタイマー値の更新も行えます あり SIP ゲートウェイは INFO メッセージの受け入れや生成を行えます あり Refer 要求の実装で使用されます Notify メッセージにより Refer 要求の発信側に転送の結果を通知できます また Notify メッセージにより 加入者に対して 選択されたイベント (DTMF(Dual Tone MultiFrequency) イベント または message waiting indication (MWI) イベントなど ) で発生した変更を通知できます あり SIP ゲートウェイはこの方式のみを受信します あり Provisional Reliable Acknowledgements(PRACK) をイネーブルまたはディセーブルにします あり SIP ゲートウェイは Refer 要求に応答し また在席コール転送およびブラインドコール転送に関する Refer 要求を生成します あり SIP ゲートウェイは SIP REGISTER 要求を送受信できます あり SIP ゲートウェイは SUBSCRIBE 要求を生成して受け入れることができます ゲートウェイは DTMF テレフォニーイベントなど選択したアプリケーションや MWI に対する SUBSCRIBE 要求を処理します あり SIP ゲートウェイは メディアの変更 ターゲットの更新 および QoS シナリオに関する UPDATE を受け入れることができます またゲートウェイは QoS シナリオに対してのみ UPDATE を送信します SIP 応答 Cisco SIP ゲートウェイがサポートする RFC 3261 に準拠した SIP 応答を表 4 ~ 表 9 に示します Cisco SIP ゲートウェイは 発信した または終了したコールに対するキープアライブメッセージの使用は開始しません リモートゲートウェイがキープアライブメッセージを使用する場合 SIP ゲートウェイはそれに従います 7

8 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

9 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

10 SIP の RFC 準拠に関する情報 SIP の RFC 準拠の実現 表 7 4xx 応答 ( 続き ) 4xx 応答 説明 415 Unsupported media 本文の形式が宛先のエンドポイントによってサポートされていないため サーバは要求の処理を拒否します SIP ゲートウェイは サポートされていないイベントタイプに対して Info メッセージを受け取った場合 この応答を生成します サポートされているイベントタイプは 0 ~ 9 A ~ D # および * です 416 Unsupported Request URI scheme 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 ゲートウェイは 着信側が使用不可能な場合にこの応答を生成します たとえば 一定時間内に着信側が電話に応答しない または送信先番号が存在しないか稼動していない場合などです 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 ゲートウェイは メディアネゴシエーションが失敗した場合にこの応答を生成します 10

11 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 7 4xx 応答 ( 続き ) 4xx 応答 説明 491 Request Pending SIP ゲートウェイは 以前要求したオファーに対する応答を受け取る前に新しいオファーを受け取った場合 その新しいオファーを提示する UPDATE メッセージを拒否する際にこの応答を生成します 493 Undecipherable SIP ゲートウェイはこの応答を生成しません 表 8 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

12 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

13 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 13 SIP 拡張機能 SIP 拡張機能 RFC 3262:SIP における暫定応答の信頼性 RFC 3263:SIP サーバの位置確認 RFC 3265:SIP 特定イベントの通知 RFC 3311:SIP UPDATE 方式 RFC 3312: リソース管理と SIP の統合 - RFC RFC 3326:SIP 用の Reason Header フィールド RFC 3515:SIP REFER 方式 説明 サポートされます ゲートウェイは DNS NAPTR ルックアップをサポートしません DNS SRV および A レコードルックアップはサポートしており 複数エントリを循環するための準備ができています ゲートウェイは SUBSCRIBE-NOTIFY フレームワークをサポートします ゲートウェイは メディアの変更 ターゲットの更新 および QoS シナリオに関する UPDATE を受け入れます またゲートウェイは QoS シナリオに対してのみ UPDATE を送信します ミッドコール QoS の変更では この RFC に定義されている 183-PRACK モデルを使用しません ゲートウェイは これを使用して Q.850 原因コードをリモート SIP デバイスに取り次ぎます ゲートウェイは アウトオブダイアログの REFER 要求を送信または受け入れしません REFER の重複はサポートされていません REFER は コール転送シナリオのコンテキストだけ ( つまり INVITE がトリガーされた場合だけ ) でサポートされます ゲートウェイは コール転送シナリオで必要に応じて RFC 3892 の関連部分 (Referred-By) および RFC 3891 の関連部分 (Replaces ヘッダー ) をサポートします SIP セキュリティ 表 14 および表 15 に RFC 3261 でサポートされる SIP セキュリティ暗号化および応答を示します また Cisco SIP ゲートウェイがサポートする特定の機能がある場合はその機能も示します 表 14 SIP 暗号化モード 暗号化モードエンドツーエンド暗号化ホップバイホップ暗号化 SIP 応答のプライバシーフィールド経由暗号化 シスコゲートウェイによるサポートの有無なし IPSEC をセキュリティに使用できます なし なし IPSEC をセキュリティに使用できます 表 15 SIP 認証暗号化モード 認証暗号化モードダイジェスト認証 PGP プロキシ認証セキュア SIP または sips シスコゲートウェイによるサポートの有無ありなしなし URI スキームはサポートされません 13

14 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 の記載に従って実装することが必要です 必須 あり SIPt38-02 SIP 対応の VoIP ゲートウェイは RTP オーディオストリーム内で転送される calling(cng) トーン called station identifier(ced) ファックストーン およびプリアンブルフラグシーケンスを検出します 必須 あり ファックス検出には CED V.21 プリアンブルのみが使用され CNG トーンは使用されません SIPt38-03 ファックス伝送の検出は 受信側ゲートウェイが CED トーンを認識することによって実行されます 必須 あり 14

15 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 表 18 T.38 ファックス要件 ( 続き ) 要件 SIPt38-04 SIPt38-05 SIPt38-06 SIPt38-07 SIPt38-08 SIPt38-09 SIPt38-10 説明 CED トーンがない場合 ファックス伝送は受信側ゲートウェイがプリアンブルフラグシーケンスを認識することにより検出されます ファックス伝送を検出するとただちに 受信側ゲートウェイは SDP を使用して re-invite 要求を送信することにより T.38 ファックスモードに対する切り替えを開始します グレアを防止するため 伝送ゲートウェイがファックス伝送 (CNG トーン ) を検出した場合でも ゲートウェイは T.38 ファックスモードへの切り替えを開始しません SIP セッションがオーディオ機能で開始され その後ファックスに切り替わった場合 セッションは ファックス伝送終了時にオーディオモードに戻します TCP を介した SIP T.38 ファックスコールをサポート ファクシミリ UDP Transport Layer(UDPTL; UDP トランスポートレイヤ ) がサポートされます T.38 ファックスセッションをサポートする SDP アトリビュートは次のとおりです 登録済み SDP プロトコル形式 MIME メディアタイプ :image/t38: MIME メディアタイプ名 :image 必須または任意 必須 必須 必須 必須 推奨 必須 必須 サポートの有無ありありありあり UDP のみありあり MIME サブタイプ名 :t38 SIPt38-11 T.38 セッションをサポートするアトリビュートは次のとおりです 必須 あり T38FaxVersion T38maxBitRate T38FaxFillBitRemoval T38FaxTranscodingMMR T38FaxTranscodingJBIG T38FaxRateManagement T38FaxMaxBuffer T38FaxMaxDatagram T38FaxUdpEC SIPt38-12 T.38 をサポートする Cisco SIP 対応のゲートウェイは シスコおよび他のベンダー製のゲートウェイと相互運用できます 必須 あり 15

16 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:36602@

17 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 同等 URL: 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% は有効な電話番号ですが この場合は解釈が必要となります 解釈が実行されない場合 ユーザパラメータがダイヤルピアの宛先パターンと一致すると コールの試行は失敗します user=phone パラメータ SIP URL は E メールアドレスに似たユーザのアドレスを識別します ユーザアドレスの形式は user@host で user はユーザ ID host はドメイン名または数字でネットワークアドレスを表したものになります たとえば 発信 INVITE 要求の要求行は 次のように見える場合があります INVITE sip: @example.com 17

18 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

19 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

20 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 UAC V UAS INVITE (Offer 1) 18x (ANSWER 1) PRACK/200 OK UPDATE (Offer 2) 200 OK (ANSWER 2) 200 OK (INVITE)/ACK 図 2 では ゲートウェイは INVITE 要求 (Offer 1) に応答する前に UPDATE 要求 (Offer 2) を受信しました これにより ゲートウェイは Retry-After ヘッダーフィールドを 0 ~ 10 秒までのランダムに選択した値に設定した状態で 500 Internal Server Error を送信することで 要求を拒否しました 20

21 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 図 2 最初の UPDATE の拒否 V UAC V UAS INVITE (Offer 1) 18x (Ringing) UPDATE (Offer 2) 500 (Internal Server Error) 200 OK (ANSWER 1)/ACK UPDATE (Offer 2) 200 OK (ANSWER 2) 図 3 では 最初の INVITE 要求にはオファーが含まれておらず UAS ゲートウェイは信頼できる暫定応答 (Offer 1) とともに SDP を送信し これを UAC はオファーとして処理しました 図 3 ディレイドメディア (delayed media) に対する UPDATE 要求 V UAC V UAS INVITE 18x (Offer 1) PRACK (ANSWER 1) 200 OK UPDATE (Offer 2) 200 OK (ANSWER 2) 図 4 では UAS は PRACK を受信する前 つまりアーリーダイアログが確立される前に オファー (Offer 2) とともに UPDATE 要求を受信しており これにより UAS( ゲートウェイ ) は 491 Request Pending 応答を生成しました 21

22 SIP の RFC 準拠に関する情報 SIP の RFC 準拠の実現 図 4 ディレイドメディア (delayed media) に対する UPDATE 要求の失敗 V UAC V UAS INVITE 18x (Offer 1) UPDATE (Offer 2) 491 (Request Pending) PRACK (ANSWER 1) 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 UAC V UAS INVITE (Offer 1) 18x 200 OK (ANSWER 1) UPDATE (Offer 2) 500 (Internal Server Error)

23 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 アクティブ状態での UPDATE 要求の処理 RFC 3261 は re-invite 要求を使用して 既存または保留中のコールのセッションパラメータを変更する SIP メッセージが コールがアクティブになった後にセッションパラメータをアップデートすることを推奨しています コールがアクティブになった後に受信された UPDATE は アップデートするための 200 OK が再送信される場合を除き re-invite のように処理されます ( 図 6 を参照 ) 図 6 アクティブ状態での UPDATE 要求 V UAC V UAS INVITE/200 OK/ACK RTP UPDATE (Offer 2) 200 OK (ANSWER 2) RTP 図 7 に ミッドコール INVITE を送信し まだ応答を受信していない UAC を示します この状態では ゲートウェイは新しいオファーを伴う UPDATE 要求を受信した場合 491 Request Pending エラーを送信します 図 7 アクティブ状態での UPDATE 要求に対するエラー応答 V UAC V UAS INVITE (1) /200 OK/ACK RTP INVITE (2) UPDATE (Offer 3) 491 (Request Pending) Via ヘッダーのパラメータと結合要求の検出 RFC 3261 の仕様を満たすため 発信者 ID とプライバシーのための SIP 拡張機能では 要求の Via ヘッダー内の branch パラメータ つまり要求によって作成されるトランザクションの識別に使用される情報のサポートを提供します branch パラメータの値は z9hg4bk という値で始まり 要求が RFC 3261 に準拠し UAC によって生成されたものであることを示します 発信者 ID とプライバシーのための SIP 拡張では 受信したアドレスを使用して受信したパラメータを生成するためのサポートも追加されています 23

24 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 UAC V UAS INVITE (CSeq: 1 INVITE) 18x Ringing INVITE (CSeq: 2 INVITE) 500 Internal Server Error ACK ミッドコール re-invite 要求の失敗 発信者 ID とプライバシーのための SIP 拡張機能では 図 9 に示すとおりミッドコール re-invite 要求の失敗の処理を実装しています ミッドコール INVITE 要求に対する 2xx 以外の最終応答が次のいずれかの場合 UAC はダイアログを終了します 失敗を示す 481 Call/Transaction Does Not Exist 応答 失敗を示す 408 Request Timeout 応答 24

25 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 図 9 re-invite 要求に対する 481 または 408 応答後のダイアログ終了 V UAC V UAS INVITE (1) /200 OK/ACK RTP INVITE (2) 481/408 ACK 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 UAC V UAS INVITE (Offer 1) 18x (ANSWER 1) PRACK (Offer 2) 200 OK (ANSWER 2) 200 OK (INV, ANSWER 2)/ACK 信頼できる暫定応答の失敗 発信者 ID とプライバシーのための SIP 拡張機能では UAS が許容リトライ最大数分または 32 秒間 信頼できる暫定応答である 18x を再送した後 対応する PRACK を受信しなかった場合 図 11 に示す処理を行います UAS は 5xx 応答を生成して コールをクリアします 25

26 SIP の RFC 準拠に関する情報 SIP の RFC 準拠の実現 図 11 信頼できる暫定応答の失敗 V UAC V UAS INVITE 18x (ANSWER 1)... 18x 504 (Server Timeout) ACK メッセージの例 ここでは SIP ゲートウェイ終了時に収集される SIP メッセージの例を示します SIP UPDATE 要求のコールフローの例 コールがアクティブになる前の UPDATE 要求を含む SIP 要求と応答の交換例を次に示します 1w0d:SIP Msg:ccsipDisplayMsg:Received: INVITE sip:222@ :5060 SIP/2.0 Record-Route:<sip:222@ :5060;maddr= > Via:SIP/2.0/UDP :5060;branch=5,SIP/2.0/UDP :5060;branch=z9hG4bK1D38 From:<sip:111@ >;tag=3DD33DE4-10DF To:<sip:222@ > Date:Mon, 08 Apr :58:08 GMT Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@ Supported:timer 次の行は UAC が暫定応答が高い信頼性で転送されることが必要としていることを示しています Require:100rel Min-SE: 1800 Cisco-Guid: 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:111@ >;party=calling;screen=no;privacy=off Timestamp: Contact:<sip:111@ :5060> Expires:180 Allow-Events:telephone-event Content-Type:application/sdp Content-Length:262 次の SDP は メディアストリームとコーデックを含む最初のオファー およびメディアを受信するための IP アドレスとポートを構成しています v=0 26

27 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 o=ciscosystemssip-gw-useragent IN IP s=sip Call c=in IP t=0 0 m=audio RTP/AVP c=in IP 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/ Trying Via:SIP/2.0/UDP :5060;branch=5,SIP/2.0/UDP :5060;branch=z9hG4bK1D38 From:<sip:111@ >;tag=3DD33DE4-10DF To:<sip:222@ >;tag=24D435A8-C29 Date:Sat, 07 Oct :56:34 GMT Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@ Timestamp: Server:Cisco-SIPGateway/IOS-12.x CSeq:101 INVITE Allow-Events:telephone-event Content-Length:0 次の行では ゲートウェイは 最初のオファーへの応答でアーリーメディア (early media) を送信することによって応答しています 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/ Session Progress Via:SIP/2.0/UDP :5060;branch=5,SIP/2.0/UDP :5060;branch=z9hG4bK1D38 From:<sip:111@ >;tag=3DD33DE4-10DF To:<sip:222@ >;tag=24D435A8-C29 Date:Sat, 07 Oct :56:34 GMT Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@ Timestamp: Server:Cisco-SIPGateway/IOS-12.x CSeq:101 INVITE Require:100rel RSeq:5785 Allow:UPDATE Allow-Events:telephone-event Contact:<sip:222@ :5060> Record-Route:<sip:222@ :5060;maddr= > Content-Disposition:session;handling=required Content-Type:application/sdp Content-Length:191 v=0 o=ciscosystemssip-gw-useragent IN IP s=sip Call c=in IP t=0 0 m=audio RTP/AVP 8 19 c=in IP a=rtpmap:8 PCMA/8000 a=rtpmap:19 CN/8000 次の行では UAS が 183 応答に対して PRACK を受信していることを示しています 1w0d:SIP Msg:ccsipDisplayMsg:Received: 27

28 SIP の RFC 準拠に関する情報 SIP の RFC 準拠の実現 PRACK SIP/2.0 Via:SIP/2.0/UDP :5060;branch=6,SIP/2.0/UDP :5060;branch=z9hG4bK40A Date:Mon, 08 Apr :58:08 GMT CSeq:102 PRACK RAck: INVITE Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/ OK Via:SIP/2.0/UDP :5060;branch=6,SIP/2.0/UDP :5060;branch=z9hG4bK40A Date:Sat, 07 Oct :56:34 GMT Server:Cisco-SIPGateway/IOS-12.x CSeq:102 PRACK Content-Length:0 次の行では UAS が異なるメディアストリームとコーデックを持つアップデートされたオファーを受信していることを示しています 1w0d:SIP Msg:ccsipDisplayMsg:Received: UPDATE SIP/2.0 Via:SIP/2.0/UDP :5060;branch=z9hG4bK10 Via:SIP/2.0/UDP :5060 CSeq:103 UPDATE Content-Length:262 v=0 o=ciscosystemssip-gw-useragent IN IP s=sip Call c=in IP t=0 0 m=audio RTP/AVP c=in IP 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/ OK Via:SIP/2.0/UDP :5060;branch=z9hG4bK10,SIP/2.0/UDP :5060 From:<sip:111@ >;tag=3DD33DE4-10DF To:<sip:222@ >;tag=24D435A8-C29 Date:Sat, 07 Oct :56:34 GMT Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@ Server:Cisco-SIPGateway/IOS-12.x CSeq:103 UPDATE Content-Type:application/sdp Content-Length:191 28

29 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 v=0 o=ciscosystemssip-gw-useragent IN IP s=sip Call c=in IP t=0 0 m=audio RTP/AVP 8 19 c=in IP a=rtpmap:8 PCMA/8000 a=rtpmap:19 CN/8000 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/ OK Via:SIP/2.0/UDP :5060;branch=5,SIP/2.0/UDP :5060;branch=z9hG4bK1D38 From:<sip:111@ >;tag=3DD33DE4-10DF To:<sip:222@ >;tag=24D435A8-C29 Date:Sat, 07 Oct :56:34 GMT Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@ Timestamp: 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:222@ :5060> Record-Route:<sip:222@ :5060;maddr= > Content-Type:application/sdp Content-Length:191 v=0 o=ciscosystemssip-gw-useragent IN IP s=sip Call c=in IP t=0 0 m=audio RTP/AVP 8 19 c=in IP a=rtpmap:8 PCMA/8000 a=rtpmap:19 CN/8000 1w0d:SIP Msg:ccsipDisplayMsg:Received: ACK sip:222@ :5060 SIP/2.0 Via:SIP/2.0/UDP :5060;branch=7,SIP/2.0/UDP :5060;branch=z9hG4bK230 From:<sip:111@ >;tag=3DD33DE4-10DF To:<sip:222@ >;tag=24D435A8-C29 Date:Mon, 08 Apr :58:08 GMT Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@ Max-Forwards:70 CSeq:101 ACK Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Sent: BYE sip:222@ : ;maddr= SIP/2.0 Via:SIP/2.0/UDP :5060;branch=z9hG4bKCA From:<sip:222@ >;tag=24D435A8-C29 To:<sip:111@ >;tag=3DD33DE4-10DF Date:Sat, 07 Oct :56:35 GMT Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@ User-Agent:Cisco-SIPGateway/IOS-12.x Max-Forwards:70 Route:<sip:111@ :5060> Timestamp: CSeq:101 BYE 29

30 SIP の RFC 準拠に関する情報 SIP の RFC 準拠の実現 Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Received: SIP/ OK Via:SIP/2.0/UDP :5060;branch=z9hG4bKCA Date:Mon, 08 Apr :58:29 GMT Server:Cisco-SIPGateway/IOS-12.x Timestamp: Content-Length:0 CSeq:101 BYE ルーズルーティングのコールフローの例次に ルーズルーティング要求を示すメッセージの例を示します 1w0d:SIP Msg:ccsipDisplayMsg:Received: INVITE SIP/2.0 次のコールフローの SIP メッセージでは Request-URI がネクストホップの宛先の SIP URI ではなく 宛先 UA の SIP URI つまり SIP プロキシサーバに設定されています Via:SIP/2.0/UDP :5060;branch=9,SIP/2.0/UDP :5060;branch=z9hG4bK2394 Date:Mon, 08 Apr :58:34 GMT Supported:timer Min-SE: 1800 Cisco-Guid: 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 Timestamp: Expires:180 Allow-Events:telephone-event Content-Type:application/sdp Content-Length:262 v=0 o=ciscosystemssip-gw-useragent IN IP s=sip Call c=in IP t=0 0 m=audio RTP/AVP c=in IP 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/ Trying Via:SIP/2.0/UDP :5060;branch=9,SIP/2.0/UDP :5060;branch=z9hG4bK

31 SIP の RFC 準拠の実現 SIP の RFC 準拠に関する情報 Date:Sat, 07 Oct :57:00 GMT Timestamp: Server:Cisco-SIPGateway/IOS-12.x CSeq:101 INVITE Allow-Events:telephone-event Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/ Ringing Via:SIP/2.0/UDP :5060;branch=9,SIP/2.0/UDP :5060;branch=z9hG4bK2394 Date:Sat, 07 Oct :57:00 GMT Timestamp: Server:Cisco-SIPGateway/IOS-12.x CSeq:101 INVITE Allow:UPDATE Allow-Events:telephone-event Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Sent: SIP/ OK Via:SIP/2.0/UDP :5060;branch=9,SIP/2.0/UDP :5060;branch=z9hG4bK2394 Date:Sat, 07 Oct :57:00 GMT Timestamp: 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 Content-Type:application/sdp Content-Length:191 v=0 o=ciscosystemssip-gw-useragent IN IP s=sip Call c=in IP t=0 0 m=audio RTP/AVP 8 19 c=in IP a=rtpmap:8 PCMA/8000 a=rtpmap:19 CN/8000 1w0d:SIP Msg:ccsipDisplayMsg:Received: ACK sip:222@ :5060 SIP/2.0 Via:SIP/2.0/UDP :5060;branch=10,SIP/2.0/UDP :5060;branch=z9hG4bK103D From:<sip:111@ >;tag=3DD3A404-12A3 To:<sip:222@ >;tag=24D49BE Date:Mon, 08 Apr :58:34 GMT Call-ID:B A4811D6-8015A410-F242231D@

32 SIP の RFC 準拠に関する情報 SIP の RFC 準拠の実現 Max-Forwards:70 CSeq:101 ACK Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Sent: BYE SIP/2.0 Via:SIP/2.0/UDP :5060;branch=z9hG4bK18B6 Date:Sat, 07 Oct :57:01 GMT User-Agent:Cisco-SIPGateway/IOS-12.x Max-Forwards:70 Timestamp: CSeq:101 BYE Content-Length:0 1w0d:SIP Msg:ccsipDisplayMsg:Received: SIP/ OK Via:SIP/2.0/UDP :5060;branch=z9hG4bK18B6 Date:Mon, 08 Apr :58:54 GMT Server:Cisco-SIPGateway/IOS-12.x Timestamp: 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) 大容量の SIP 要求に対するダイナミックトランスポートスイッチング (UPD から TCP) (P.34) Call-Hold の拡張機能 (P.35) max-forwards コマンドの範囲拡張 (P.35) SIP メッセージング拡張機能 SIP メッセージングに対して 次の変更または追加が行われました 32

33 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 接続に関する拡張機能 2xx 応答の送信失敗 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 応答は 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

34 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

35 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= を使用する必要があり 使用方法を両方には設定できません デフォルト設定は 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

36 SIP の FC 準拠の設定方法 SIP の RFC 準拠の実現 手順の概要 1. enable 2. configure terminal 3. sip-ua 4. srv version 5. exit 手順の詳細 ステップ 1 ステップ 2 コマンドまたはアクション enable Router> enable configure terminal 目的特権 EXEC モードをイネーブルにします プロンプトが表示されたら パスワードを入力します グローバルコンフィギュレーションモードを開始します ステップ 3 Router# configure terminal sip-ua Router(config)# sip-ua ステップ 4 srv version {1 2} ステップ 5 Router(config-sip-ua)# srv version 2 exit SIP ユーザエージェントコンフィギュレーションモードを開始します RFC 2052 または RFC 2782 の形式を使用して DNS SRV クエリーを生成します キーワードは次のとおりです 1: ドメイン名のプレフィクス形式 protocol.transport. (RFC 2052 形式 ) 2: ドメイン名のプレフィクス形式 _protocol._transport. (RFC 2782 形式 ) デフォルト :2 現在のモードを終了します Router(config-sip-ua)# exit RFC 3261 への準拠の設定 RFC 3261 をイネーブルにするために必要な設定作業はありません デフォルトではイネーブルになっています RFC 3261 RFC 3262 および RFC 3264 への準拠の設定 ここでは 次の各手順について説明します SIP メッセージングの設定 (P.37) 36

37 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 ステップ 2 コマンドまたはアクション enable Router> enable configure terminal 目的特権 EXEC モードをイネーブルにします プロンプトが表示されたら パスワードを入力します グローバルコンフィギュレーションモードを開始します ステップ 3 Router# configure terminal sip-ua Router(config)# sip-ua SIP ユーザエージェントコンフィギュレーションモードを開始します 37

38 SIP の FC 準拠の設定方法 SIP の RFC 準拠の実現 ステップ 4 ステップ 5 コマンドまたはアクション timers connection aging timer-value Router(config-sip-ua)# timers connection aging 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

39 SIP の RFC 準拠の実現 SIP の FC 準拠の設定方法 5. exit 手順の詳細 ステップ 1 ステップ 2 コマンドまたはアクション enable Router> enable configure terminal 目的特権 EXEC モードをイネーブルにします プロンプトが表示されたら パスワードを入力します グローバルコンフィギュレーションモードを開始します ステップ 3 ステップ 4 ステップ 5 Router# configure terminal dial-peer voice tag voip Router(config)# dial-peer voice 25 voip voice-class sip transport switch udp tcp Router(config-dial-peer)# voice-class sip transport switch udp tcp exit 特定の VoIP ダイヤルピアで ダイヤルピアコンフィギュレーションモードを開始します 特定のダイヤルピアに対して 大容量の SIP 要求に関する UDP および TCP 転送メカニズム間でのスイッチングをイネーブルにします キーワードは次のとおりです udp:mtu サイズを超えている SIP 要求のサイズに基づいて UDP から転送を切り替えます tcp: 転送を TCP に切り替えます 現在のモードを終了します 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

40 SIP の FC 準拠の設定方法 SIP の RFC 準拠の実現 5. transport switch udp tcp 6. exit 手順の詳細 ステップ 1 ステップ 2 コマンドまたはアクション enable Router> enable configure terminal 目的特権 EXEC モードをイネーブルにします プロンプトが表示されたら パスワードを入力します グローバルコンフィギュレーションモードを開始します ステップ 3 ステップ 4 Router# configure terminal voice service voip Router(config)# voice service voip sip 音声サービスコンフィギュレーションモードを開始します SIP コンフィギュレーションモードを開始します ステップ 5 ステップ 6 Router(config-voi-srv)# sip transport switch udp tcp Router(conf-serv-sip)# transport switch udp tcp exit 大容量の SIP 要求に関する UDP および TCP 転送メカニズム間でのスイッチングをグローバルにイネーブルにします キーワードは次のとおりです udp:mtu サイズを超えている SIP 要求のサイズに基づいて UDP から転送を切り替えます tcp: 転送を TCP に切り替えます 現在のモードを終了します Router(conf-serv-sip)# exit ( 注 ) 次のコマンドを使用すると SIP の転送および接続設定の確認やトラブルシューティングに役立ちます debug ccsip transport show sip-ua connections 上記コマンドおよび確認やトラブルシューティング用のその他のコマンドの詳細については SIP の RFC 準拠の確認 (P.42) および トラブルシューティングのヒント (P.45) を参照してください 40