SIP の RFC 準拠の実現 - cisco.com · SIP の RFC 準拠の実現機能情報の確認 2 SIP：DNS SRV RFC 2782 Compliance の機能履歴 SIP：RFC 3261 Enhancements の機能履歴

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.html

RFC 4040 ベースの SIP コール用クリアチャネルコーデックネゴシエーションの機能履歴

SIP：Core SIP Technology Enhancements の機能履歴

リリース変更点

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_book.html）の encap clear-channel standard および voice-class sip encap clear-channel コマンドの説明を参照してください。


12.2(13)T この機能は、SIP RFC 2543-bis-04（後に、RFC_3261 として発行）への準

拠を実現するために導入されました。

http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_book.html



http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/sip_cg-msg_tmr_rspns.html






機能情報の確認

SIP：DNS SRV RFC 2782 Compliance の機能履歴

SIP：RFC 3261 Enhancements の機能履歴

RFC 3261、RFC 3262、および RFC 3264 に対する SIP ゲートウェイの準拠の機能履歴

機能情報の確認ご使用のソフトウェアリリースによっては、この章に記載されている機能の一部がサポートされてい

ない場合があります。新の機能情報と注意事項については、ご使用のプラットフォームとソフトウェ

アリリースに対応したリリースノートを参照してください。

プラットフォームサポートと 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


12.2(2)XB この機能が導入されました。

12.2(8)T この機能がこのリリースに統合されました。


12.3(4)T この機能が導入されました。


12.3(8)T この機能が導入されました。

2

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

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

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/vvfresrv.htm#1027153

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/vvfresrv.htm#1027153

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/vvfresrv.html



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）を参照してください。


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」のようにプロトコルラベルに下線「_」が追加されます。下線を追加することで、関連のない目的に同

じ名前のプロトコルが使用される危険性を軽減できます。


廃止になった RFC 2543 に代わる RFC 3261 では、セッションを作成、変更、終了するための SIP シグナ

リングプロトコルを定義しています。シスコによる RFC 3261 の実装では、次をサポートしています。

3


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 あり。OPTIONS 応答メッセージで使用。

Accept-Encoding なし

4



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 なし

表 1 SIP ヘッダーフィールド（続き）


5



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）

プロキシサーバなし

リダイレクトサーバあり

レジストラサーバ

表 1 SIP ヘッダーフィールド（続き）


6



SIP 応答

Cisco SIP ゲートウェイがサポートする、RFC 3261 に準拠した SIP 応答を表 4 ～表 9 に示します。

Cisco SIP ゲートウェイは、発信した、または終了したコールに対するキープアライブメッセージの使

用は開始しません。リモートゲートウェイがキープアライブメッセージを使用する場合、SIP ゲート

ウェイはそれに従います。

表 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 を送信します。

7



表 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



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 ゲートウェイはこの応答を生成しません。

表 6 3xx 応答（続き）

3xx 応答説明

SIP ゲートウェイはこの応答を生成しません。ゲートウェイは、この応答を受け取るとすぐに、

Contact ヘッダーフィールドの新しいアドレスに連絡します。

9



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 ゲートウェ

イは、メディアネゴシエーションが失敗した場合にこの応答を生成し

ます。


4xx 応答説明

10



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 着信側に連絡できましたが、セッションの説明の一部を受け入れでき

ません。


4xx 応答説明

11



SIP SDP の使用方法、トランスポートレイヤプロトコル、および DNS レコード

表 10 ～表 12 に RFC 3261 でサポートされる SIP SDP の使用方法、トランスポートレイヤプロトコ

ル、および DNS レコードを示します。また、Cisco SIP ゲートウェイがサポートする特定の機能があ

る場合はその機能も示します。

SIP 拡張機能

表 13 に、サポートされる 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 あり

12



SIP セキュリティ

表 14 および表 15 に、RFC 3261 でサポートされる SIP セキュリティ暗号化および応答を示します。

また、Cisco SIP ゲートウェイがサポートする特定の機能がある場合はその機能も示します。

表 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 の統合 - RFC

ミッドコール QoS の変更では、この RFC に定義されている 183-PRACK モデルを使用しません。

RFC 3326：SIP 用の Reason Header フィールド

ゲートウェイは、これを使用して Q.850 原因コードをリモート SIP デバイスに取り次ぎます。

RFC 3515：SIP REFER 方式ゲートウェイは、アウトオブダイアログの REFER 要求を送信また

は受け入れしません。REFER の重複はサポートされていません。

REFER は、コール転送シナリオのコンテキストだけ（つまり、

INVITE がトリガーされた場合だけ）でサポートされます。ゲート

ウェイは、コール転送シナリオで必要に応じて RFC 3892 の関連

部分（Referred-By）および RFC 3891 の関連部分（Replaces ヘッ

ダー）をサポートします。

表 14 SIP 暗号化モード

暗号化モードシスコゲートウェイによるサポートの有無

エンドツーエンド暗号化なし。IPSEC をセキュリティに使用できます。

ホップバイホップ暗号化

SIP 応答のプライバシーなし。

フィールド経由暗号化なし。IPSEC をセキュリティに使用できます。

表 15 SIP 認証暗号化モード

認証暗号化モードシスコゲートウェイによるサポートの有無

ダイジェスト認証あり

PGP なし

プロキシ認証なし

セキュア SIP または sips URI スキームはサポートされません。

13



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 ゲートウェイが特定の方式をサポートする

かどうかも示します。

SIP ファックスリレーおよび T.38

表 17 に、RFC 3261 に準拠して Cisco SIP ゲートウェイでサポートされるファックスリレーモードを

示します。また Cisco SIP ゲートウェイが特定の方式をサポートするかどうかも示します。

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 ゲートウェイによる要件のサポートの有無を示します。

表 16 RFC 3261 でサポートされる SIP DTMF リレー


RFC 2833 あり。rtp-nte に対するデフォルトの RTP ペイロードタイプは 101 です。DTMF リレーのデフォルト方式は、インバンド音声です。

Cisco RTP（シスコ独自）あり。ただし、Cisco AS5350 および Cisco AS5400 を除く。

表 17 RFC 3261 でサポートされるファックスリレーモード


T.38 ファックスリレーあり

Cisco ファックスリレーあり。ただし、Cisco AS5350 および Cisco AS5400 を除く。

表 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



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 トランスポートレイヤ）がサポートされま

す。

必須あり

SIPt38-10 T.38 ファックスセッションをサポートする SDP アトリビュートは次のとおりです。

• 登録済み SDP プロトコル形式、MIME メディアタイプ：image/t38:

• MIME メディアタイプ名：image

• MIME サブタイプ名：t38

必須あり

SIPt38-11 T.38 セッションをサポートするアトリビュートは

次のとおりです。

• T38FaxVersion

• T38maxBitRate

• T38FaxFillBitRemoval

• T38FaxTranscodingMMR

• T38FaxTranscodingJBIG

• T38FaxRateManagement

• T38FaxMaxBuffer

• T38FaxMaxDatagram

• T38FaxUdpEC

必須あり

SIPt38-12 T.38 をサポートする Cisco SIP 対応のゲートウェ

イは、シスコおよび他のベンダー製のゲートウェ

イと相互運用できます。

必須あり

表 18 T.38 ファックス要件（続き）

要件説明

必須または任


15



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 の比較対象となるパラメータとそのデフォルト値のリストを示します。

比較が行われていると仮定して、同一 URL の例を次に示します。

元の URL：sip:[email protected]

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 要求に対してメッ

セージ認証を実行できます。

任意なし

表 18 T.38 ファックス要件（続き）

要件説明

必須または任


表 19 SIP の URL の比較対象パラメータとデフォルト値

SIP の URL の比較対象パラメータデフォルト

User —

Password —

Host 必須

Port 5060

User-param IP

16



同等 URL：sip:[email protected]:sip:[email protected];tag=499270-A62;pname=pvaluesip:[email protected];user=ipsip:[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 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



• 「信頼できる暫定応答の失敗」（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



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

図 2 では、ゲートウェイは INVITE 要求（Offer 1）に応答する前に UPDATE 要求（Offer 2）を受信し

ました。これにより、ゲートウェイは、Retry-After ヘッダーフィールドを 0 ～ 10 秒までのランダム

に選択した値に設定した状態で 500 Internal Server Error を送信することで、要求を拒否しました。

9876

4

UAC UAS

INVITE (Offer 1)

UPDATE (Offer 2)

18x (ANSWER 1)

PRACK/200 OK

200 OK (ANSWER 2)

200 OK (INVITE)/ACK

V V

20



図 2 最初の UPDATE の拒否

図 3 では、初の INVITE 要求にはオファーが含まれておらず、UAS ゲートウェイは信頼できる暫定

応答（Offer 1）とともに SDP を送信し、これを UAC はオファーとして処理しました。

図 3 ディレイドメディア（delayed media）に対する UPDATE 要求

図 4 では、UAS は PRACK を受信する前、つまりアーリーダイアログが確立される前に、オファー

（Offer 2）とともに UPDATE 要求を受信しており、これにより UAS（ゲートウェイ）は 491 Request Pending 応答を生成しました。

9876

5

UAC UAS

INVITE (Offer 1)

500 (Internal Server Error)

18x (Ringing)

UPDATE (Offer 2)

200 OK (ANSWER 1)/ACK

UPDATE (Offer 2)

200 OK (ANSWER 2)

V V

9876

6

UAC UAS

INVITE

200 OK

18x (Offer 1)

PRACK (ANSWER 1)

UPDATE (Offer 2)

200 OK (ANSWER 2)

V V

21



図 4 ディレイドメディア（delayed media）に対する UPDATE 要求の失敗

コールがアクティブになる前の 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 要求に対するエラーケース

9876

7

UAC UAS

INVITE

491 (Request Pending)

18x (Offer 1)

UPDATE (Offer 2)

PRACK (ANSWER 1)

200 OK

V V

9876

9

UAC UAS

INVITE (Offer 1)

UPDATE (Offer 2)

18x

200 OK (ANSWER 1)

500 (Internal Server Error)

V V

22



アクティブ状態での UPDATE 要求の処理

RFC 3261 は re-INVITE 要求を使用して、既存または保留中のコールのセッションパラメータを変更

する SIP メッセージが、コールがアクティブになった後にセッションパラメータをアップデートする

ことを推奨しています。コールがアクティブになった後に受信された UPDATE は、アップデートする

ための 200 OK が再送信される場合を除き、re-INVITE のように処理されます（図 6 を参照）。

図 6 アクティブ状態での UPDATE 要求

図 7 に、ミッドコール INVITE を送信し、まだ応答を受信していない UAC を示します。この状態で

は、ゲートウェイは新しいオファーを伴う UPDATE 要求を受信した場合、491 Request Pending エラーを送信します。

図 7 アクティブ状態での UPDATE 要求に対するエラー応答

Via ヘッダーのパラメータと結合要求の検出

RFC 3261 の仕様を満たすため、発信者 ID とプライバシーのための SIP 拡張機能では、要求の Via ヘッダー内の branch パラメータ、つまり要求によって作成されるトランザクションの識別に使用され

る情報のサポートを提供します。branch パラメータの値は、「z9hG4bK」という値で始まり、要求が RFC 3261 に準拠し、UAC によって生成されたものであることを示します。発信者 ID とプライバシー

のための SIP 拡張では、受信したアドレスを使用して受信したパラメータを生成するためのサポート

も追加されています。

9877

0

UAC UAS

INVITE/200 OK/ACK

RTP

UPDATE (Offer 2)

200 OK (ANSWER 2)

RTP

V V

9877

1

UAC UAS

INVITE (1) /200 OK/ACK

RTP

INVITE (2)

UPDATE (Offer 3)

491 (Request Pending)

V V

23



発信者 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 要求

ミッドコール re-INVITE 要求の失敗

発信者 ID とプライバシーのための SIP 拡張機能では、図 9 に示すとおりミッドコール re-INVITE 要求の失敗の処理を実装しています。ミッドコール INVITE 要求に対する 2xx 以外の終応答が次のい

ずれかの場合、UAC はダイアログを終了します。

• 失敗を示す 481 Call/Transaction Does Not Exist 応答

• 失敗を示す 408 Request Timeout 応答

9877

2

UAC UAS

INVITE (CSeq: 1 INVITE)

18x Ringing

INVITE (CSeq: 2 INVITE)

500 Internal Server Error

ACK

V V

24



図 9 re-INVITE 要求に対する 481 または 408 応答後のダイアログ終了

新しいオファーを伴う 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 におけるオファー

信頼できる暫定応答の失敗

発信者 ID とプライバシーのための SIP 拡張機能では、UAS が許容リトライ大数分または 32 秒間、

信頼できる暫定応答である 18x を再送した後、対応する PRACK を受信しなかった場合、図 11 に示す

処理を行います。UAS は 5xx 応答を生成して、コールをクリアします。

UAC UAS

INVITE (1) /200 OK/ACK

RTP

INVITE (2)

481/408

ACK

BYE/200 OK

9877

3

V V

UAC UAS

INVITE (Offer 1)

18x (ANSWER 1)

PRACK (Offer 2)

200 OK (ANSWER 2)

200 OK (INV, ANSWER 2)/ACK

9877

4

V V

25



図 11 信頼できる暫定応答の失敗

メッセージの例

ここでは、SIP ゲートウェイ終了時に収集される SIP メッセージの例を示します。

SIP UPDATE 要求のコールフローの例

コールがアクティブになる前の UPDATE 要求を含む SIP 要求と応答の交換例を次に示します。

1w0d:SIP Msg:ccsipDisplayMsg:Received:INVITE sip:[email protected]:5060 SIP/2.0Record-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/UDP192.0.2.14:5060;branch=z9hG4bK1D38From:<sip:[email protected]>;tag=3DD33DE4-10DFTo:<sip:[email protected]>Date:Mon, 08 Apr 2002 16:58:08 GMTCall-ID:[email protected]:timer

次の行は、UAC が暫定応答が高い信頼性で転送されることが必要としていることを示しています。

Require:100relMin-SE: 1800Cisco-Guid:2729535908-1246237142-2148443152-4064420637User-Agent:Cisco-SIPGateway/IOS-12.x

Allow ヘッダーは、UPDATE 方式がサポートされていることを示しています。

Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTERCSeq:101 INVITEMax-Forwards:70Remote-Party-ID:<sip:[email protected]>;party=calling;screen=no;privacy=offTimestamp:1018285088Contact:<sip:[email protected]:5060>Expires:180Allow-Events:telephone-eventContent-Type:application/sdpContent-Length:262

次の SDP は、メディアストリームとコーデックを含む初のオファー、およびメディアを受信するた

めの IP アドレスとポートを構成しています。

v=0

UAC UAS

INVITE

18x (ANSWER 1)

... 18x

504 (Server Timeout)

ACK

9877

5

V V

26



o=CiscoSystemsSIP-GW-UserAgent 6579 1987 IN IP4 192.0.2.14s=SIP Callc=IN IP4 192.0.2.14t=0 0m=audio 17782 RTP/AVP 8 0 18 19c=IN IP4 192.0.2.14a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:19 CN/8000

1w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 100 TryingVia:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK1D38From:<sip:[email protected]>;tag=3DD33DE4-10DFTo:<sip:[email protected]>;tag=24D435A8-C29Date:Sat, 07 Oct 2000 02:56:34 GMTCall-ID:[email protected]:1018285088Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITE

Allow-Events:telephone-eventContent-Length:0

次の行では、ゲートウェイは、初のオファーへの応答でアーリーメディア（early media）を送信す

ることによって応答しています。

1w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 183 Session ProgressVia:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK1D38From:<sip:[email protected]>;tag=3DD33DE4-10DFTo:<sip:[email protected]>;tag=24D435A8-C29Date:Sat, 07 Oct 2000 02:56:34 GMTCall-ID:[email protected]:1018285088Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITERequire:100relRSeq:5785Allow:UPDATEAllow-Events:telephone-eventContact:<sip:[email protected]:5060>Record-Route:<sip:[email protected]:5060;maddr=192.0.2.4>Content-Disposition:session;handling=requiredContent-Type:application/sdpContent-Length:191

v=0o=CiscoSystemsSIP-GW-UserAgent 5565 7580 IN IP4 192.0.2.12s=SIP Callc=IN IP4 192.0.2.12t=0 0m=audio 18020 RTP/AVP 8 19c=IN IP4 192.0.2.12a=rtpmap:8 PCMA/8000a=rtpmap:19 CN/8000

次の行では、UAS が 183 応答に対して PRACK を受信していることを示しています。

1w0d:SIP Msg:ccsipDisplayMsg:Received:

27



PRACK sip:[email protected]:5060 SIP/2.0Via:SIP/2.0/UDP 192.0.2.4:5060;branch=6,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK40AFrom:<sip:[email protected]>;tag=3DD33DE4-10DFTo:<sip:[email protected]>;tag=24D435A8-C29Date:Mon, 08 Apr 2002 16:58:08 GMTCall-ID:[email protected]:102 PRACKRAck:5785 101 INVITEContent-Length:0

1w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 200 OKVia:SIP/2.0/UDP 192.0.2.4:5060;branch=6,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK40AFrom:<sip:[email protected]>;tag=3DD33DE4-10DFTo:<sip:[email protected]>;tag=24D435A8-C29Date:Sat, 07 Oct 2000 02:56:34 GMTCall-ID:[email protected]:Cisco-SIPGateway/IOS-12.xCSeq:102 PRACKContent-Length:0

次の行では、UAS が異なるメディアストリームとコーデックを持つアップデートされたオファーを受

信していることを示しています。

1w0d:SIP Msg:ccsipDisplayMsg:Received:UPDATE sip:[email protected]:5060 SIP/2.0Via:SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bK10Via:SIP/2.0/UDP 192.0.2.14:5060To:<sip:[email protected]>;tag=24D435A8-C29From:<sip:[email protected]>;tag=3DD33DE4-10DFCall-ID:[email protected]:103 UPDATEContact:sip:[email protected]:5060Content-Length:262

v=0o=CiscoSystemsSIP-GW-UserAgent 6579 1987 IN IP4 192.0.2.14s=SIP Callc=IN IP4 192.0.2.14t=0 0m=audio 17782 RTP/AVP 8 0 18 19c=IN IP4 192.0.2.14a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:19 CN/8000

UPDATE 要求内の新しいオファーはサーバで受け入れ可能なため、サーバは 200 OK メッセージで対

応する応答を使用して応答します。

1w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 200 OKVia:SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bK10,SIP/2.0/UDP 192.0.2.14:5060From:<sip:[email protected]>;tag=3DD33DE4-10DFTo:<sip:[email protected]>;tag=24D435A8-C29Date:Sat, 07 Oct 2000 02:56:34 GMTCall-ID:[email protected]:Cisco-SIPGateway/IOS-12.xCSeq:103 UPDATEContent-Type:application/sdpContent-Length:191

28




1w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 200 OKVia:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK1D38From:<sip:[email protected]>;tag=3DD33DE4-10DFTo:<sip:[email protected]>;tag=24D435A8-C29Date:Sat, 07 Oct 2000 02:56:34 GMTCall-ID:[email protected]:1018285088Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITEAllow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTERAllow-Events:telephone-eventContact:<sip:[email protected]:5060>Record-Route:<sip:[email protected]:5060;maddr=192.0.2.4>Content-Type:application/sdpContent-Length:191


1w0d:SIP Msg:ccsipDisplayMsg:Received:ACK sip:[email protected]:5060 SIP/2.0Via:SIP/2.0/UDP 192.0.2.4:5060;branch=7,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK230From:<sip:[email protected]>;tag=3DD33DE4-10DFTo:<sip:[email protected]>;tag=24D435A8-C29Date:Mon, 08 Apr 2002 16:58:08 GMTCall-ID:[email protected]:70CSeq:101 ACKContent-Length:0

1w0d:SIP Msg:ccsipDisplayMsg:Sent:BYE sip:[email protected]:50605060;maddr=192.0.2.4 SIP/2.0Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bKCAFrom:<sip:[email protected]>;tag=24D435A8-C29To:<sip:[email protected]>;tag=3DD33DE4-10DFDate:Sat, 07 Oct 2000 02:56:35 GMTCall-ID:[email protected]:Cisco-SIPGateway/IOS-12.xMax-Forwards:70Route:<sip:[email protected]:5060>Timestamp:970887414CSeq:101 BYE

29



Content-Length:0

1w0d:SIP Msg:ccsipDisplayMsg:Received:SIP/2.0 200 OKVia:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bKCAFrom:<sip:[email protected]>;tag=24D435A8-C29To:<sip:[email protected]>;tag=3DD33DE4-10DFDate:Mon, 08 Apr 2002 16:58:29 GMTCall-ID:[email protected]:Cisco-SIPGateway/IOS-12.xTimestamp:970887414Content-Length:0CSeq: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/UDP192.0.2.14:5060;branch=z9hG4bK2394From:<sip:[email protected]>;tag=3DD3A404-12A3To:<sip:[email protected]>Date:Mon, 08 Apr 2002 16:58:34 GMTCall-ID:[email protected]:timerMin-SE: 1800Cisco-Guid:2991015782-1246237142-2148770832-4064420637User-Agent:Cisco-SIPGateway/IOS-12.xAllow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTERCSeq:101 INVITEMax-Forwards:70Remote-Party-ID:<sip:[email protected]>;party=calling;screen=no;privacy=offTimestamp:1018285114Contact:<sip:[email protected]:5060>Expires:180Allow-Events:telephone-eventContent-Type:application/sdpContent-Length:262

v=0o=CiscoSystemsSIP-GW-UserAgent 1981 1761 IN IP4 192.0.2.14s=SIP Callc=IN IP4 192.0.2.14t=0 0m=audio 18354 RTP/AVP 8 0 18 19c=IN IP4 192.0.2.14a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:19 CN/8000

1w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 100 TryingVia:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK2394

30



From:<sip:[email protected]>;tag=3DD3A404-12A3To:<sip:[email protected]>;tag=24D49BE8-2346Date:Sat, 07 Oct 2000 02:57:00 GMTCall-ID:[email protected]:1018285114Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITEAllow-Events:telephone-eventContent-Length:0

1w0d:SIP Msg:ccsipDisplayMsg:Sent:SIP/2.0 180 RingingVia:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK2394From:<sip:[email protected]>;tag=3DD3A404-12A3To:<sip:[email protected]>;tag=24D49BE8-2346Date:Sat, 07 Oct 2000 02:57:00 GMTCall-ID:[email protected]:1018285114Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITEAllow:UPDATEAllow-Events:telephone-eventContact:<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 OKVia:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK2394From:<sip:[email protected]>;tag=3DD3A404-12A3To:<sip:[email protected]>;tag=24D49BE8-2346Date:Sat, 07 Oct 2000 02:57:00 GMTCall-ID:[email protected]:1018285114Server:Cisco-SIPGateway/IOS-12.xCSeq:101 INVITEAllow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTERAllow-Events:telephone-eventContact:<sip:[email protected]:5060>Record-Route:<sip:[email protected]:5060;lr;maddr=192.0.2.4>Content-Type:application/sdpContent-Length:191


1w0d:SIP Msg:ccsipDisplayMsg:Received:ACK sip:[email protected]:5060 SIP/2.0Via:SIP/2.0/UDP 192.0.2.4:5060;branch=10,SIP/2.0/UDP192.0.2.14:5060;branch=z9hG4bK103DFrom:<sip:[email protected]>;tag=3DD3A404-12A3To:<sip:[email protected]>;tag=24D49BE8-2346Date:Mon, 08 Apr 2002 16:58:34 GMTCall-ID:[email protected]

31



Max-Forwards:70CSeq:101 ACKContent-Length:0

1w0d:SIP Msg:ccsipDisplayMsg:Sent:BYE sip:[email protected]:5060 SIP/2.0Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bK18B6From:<sip:[email protected]>;tag=24D49BE8-2346To:<sip:[email protected]>;tag=3DD3A404-12A3Date:Sat, 07 Oct 2000 02:57:01 GMTCall-ID:[email protected]:Cisco-SIPGateway/IOS-12.xMax-Forwards:70Route:<sip:[email protected]:5060;lr;maddr=192.0.2.4>Timestamp:970887440CSeq:101 BYEContent-Length:0

1w0d:SIP Msg:ccsipDisplayMsg:Received:SIP/2.0 200 OKVia:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bK18B6From:<sip:[email protected]>;tag=24D49BE8-2346To:<sip:[email protected]>;tag=3DD3A404-12A3Date:Mon, 08 Apr 2002 16:58:54 GMTCall-ID:[email protected]:Cisco-SIPGateway/IOS-12.xTimestamp:970887440Content-Length:0CSeq: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



• この機能は 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



接続を開きます。ゲートウェイは、特定の宛先 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 の 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 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 への準拠を設定するには、次の手順を実行します。

35



手順の概要

1. enable

2. configure terminal

3. sip-ua

4. srv version

5. exit

手順の詳細


RFC 3261 をイネーブルにするために必要な設定作業はありません。デフォルトではイネーブルになっ

ています。

RFC 3261、RFC 3262、および RFC 3264 への準拠の設定

ここでは、次の各手順について説明します。

• 「SIP メッセージングの設定」（P.37）

コマンドまたはアクション目的

ステップ 1 enable

例：

Router> enable

特権 EXEC モードをイネーブルにします。プロンプトが表

示されたら、パスワードを入力します。

ステップ 2 configure terminal

例：

Router# configure terminal

グローバルコンフィギュレーションモードを開始します。

ステップ 3 sip-ua

例：

Router(config)# sip-ua

SIP ユーザエージェントコンフィギュレーションモード

を開始します。

ステップ 4 srv version {1 | 2}

例：

Router(config-sip-ua)# srv version 2

RFC 2052 または RFC 2782 の形式を使用して DNS SRV クエリーを生成します。キーワードは次のとおりです。

• 1：ドメイン名のプレフィクス形式

「protocol.transport.」（RFC 2052 形式）

• 2：ドメイン名のプレフィクス形式

「_protocol._transport.」（RFC 2782 形式）

デフォルト：2。

ステップ 5 exit

例：

Router(config-sip-ua)# exit

現在のモードを終了します。

36



• 「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


3. sip-ua

4. timers connection aging

5. exit

手順の詳細



例：

Router> enable




例：




例：




37



大容量の 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


3. dial-peer voice voip

4. voice-class sip transport switch udp tcp

ステップ 4 timers connection aging timer-value

例：

Router(config-sip-ua)# timers connection aging 5

非アクティビティのため SIP UA が TCP または UDP 接続

を期限切れにするまでの時間を設定します。引数は次のと

おりです。

• timer-value：待機する時間（分）。範囲：5 ～ 30。デ

フォルト：5。

ステップ 5 exit

例：




38



5. exit

手順の詳細

大容量の SIP 要求に対するダイナミックトランスポートスイッチングのグローバルベースでの設定

Cisco SIP ゲートウェイのすべての接続に対して UDP および TCP 転送メカニズム間のスイッチングを

設定するには、次の手順を実行します。

（注） • UDP から TCP へのダイナミックトランスポートスイッチングは、デフォルトではディセーブル

になっています。

• ダイヤルピアの音声コンフィギュレーションモードでダイナミックトランスポートスイッチング

がイネーブルに設定されている場合、この設定がグローバル設定より優先されます。一致する VoIP ダイヤルピアがない場合に限り、次に示すグローバル設定を考慮してください。

手順の概要

1. enable


3. voice service voip

4. sip



例：

Router> enable




例：



ステップ 3 dial-peer voice tag voip

例：

Router(config)# dial-peer voice 25 voip

特定の 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


39



5. transport switch udp tcp

6. exit

手順の詳細

（注）次のコマンドを使用すると、SIP の転送および接続設定の確認やトラブルシューティングに役立ちま

す。

• debug ccsip transport

• show sip-ua connections

上記コマンドおよび確認やトラブルシューティング用のその他のコマンドの詳細については、「SIP の RFC 準拠の確認」（P.42）および「トラブルシューティングのヒント」（P.45）を参照してください。



例：

Router> enable




例：



ステップ 3 voice service voip

例：

Router(config)# voice service voip

音声サービスコンフィギュレーションモードを開始しま

す。

ステップ 4 sip

例：

Router(config-voi-srv)# sip

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


40



Call-Hold の設定

SIP ゲートウェイによる call-hold 要求の開始方法を指定するには、次の手順を実行します。

手順の概要

1. enable


3. sip-ua

4. offer call-hold

5. exit

手順の詳細



例：

Router> enable




例：




例：




ステップ 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

例：



41



Max Forwards の設定

SIP 要求を転送できるプロキシサーバまたはリダイレクトサーバの大数を設定するには、次の手順

を実行します。

手順の概要

1. enable


3. sip-ua

4. max-forwards

5. exit

手順の詳細

SIP の RFC 準拠の確認

SIP RFC 準拠を確認するには、必要に応じて次の手順を実行します（コマンドは、アルファベット順

に示しています）。

（注）通常の確認シーケンスには、show sip-ua connections コマンドのいずれかを使用してコールの統計情

報を表示し、続いて clear sip-ua tcp connection または clear sip-ua udp connection コマンドを適切

に使用することで統計情報をクリアします。



例：

Router> enable




例：




例：




ステップ 4 max-forwards number

例：

Router(config-sip-ua)# max-forwards 65

ホップ、つまり SIP 要求を転送できるプロキシサーバまた

はリダイレクトサーバの大数を設定します。引数は次の

とおりです。

• number：転送数。範囲：1 ～ 70。デフォルト：70。

ステップ 5 exit

例：



42



手順の概要

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 : 2No. of send failures : 0No. of remote closures : 0No. of conn. failures : 0No. 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 conditionRemote-Agent:172.18.194.183, Connections-Count:1Remote-Port Conn-Id Conn-State WriteQ-Size=========== ======= =========== ===========5060 1 Established 0Remote-Agent:172.19.154.18, Connections-Count:1Remote-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 : 1No. of send failures : 0No. of remote closures : 0No. of conn. failures : 0No. of inactive conn. ageouts : 0Max. 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



++ Tuples with mismatched address/port entry- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port> id <connid>'to overcome this error conditionRemote-Agent:172.18.194.183, Connections-Count:1Remote-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 processPurging the entry from reusable global connection table

3. show sip-ua connections コマンドの出力では、すべての接続が想定どおりにクリアされているこ

とを確認します。

Router# show sip-ua connections tcp detail

Total active connections : 0No. of send failures : 0No. of remote closures : 0No. of conn. failures : 0No. of inactive conn. ageouts : 0Max. 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 conditionRemote-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



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 0SIP 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/0Retry 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: 0Last 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 準拠の設定例

• メッセージのサイズが MTU のしきい値サイズを超えていること。このため、トランスポートスイッチング（UDP から TCP へ）がイネーブルになっていること。

• 接続アルゴリズムが開始されている、つまり、非アクティビティが発生した場合、TCP または UDP 接続を期限切れにするためのカウンタが開始されていること。

Router# debug ccsip transport...1w1d: //18/8E16980D800A/SIP/Transport/sipSPISendInvite: Sending Invite to the transport layer1w1d: //18/8E16980D800A/SIP/Transport/sipSPIGetSwitchTransportFlag: Return the Global configuration, Switch Transport is TRUE1w1d: //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=0x614FAB581w1d: //18/8E16980D800A/SIP/Transport/sipSPITransportSendMessage: Proceedable for sending msg immediately1w1d: //18/8E16980D800A/SIP/Transport/sipTransportLogicSendMsg: switch transport is 11w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportGetInterfaceMtuSize: MTU size for remote address 172.18.194.183 is 5001w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportVerifyMsgForMTUThreshold: Interface MTU Size 500, Msg Size 10961w1d: //18/8E16980D800A/SIP/Transport/sipTransportLogicSendMsg: Switching msg=0x64082D50 transport UDP->TCP1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportSetAgeingTimer: Aging timer initiated for holder=0x64084058,addr=172.18.194.1831w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnHolder: Created new holder=0x64084058, addr=172.18.194.1831w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostRequestConnection: Posting TCP conn create request for addr=172.18.194.183, port=5060, context=0x64128D5C1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportSetConnWaitTimer: Wait timer set for connection=0x64129BF4,addr=172.18.194.183, port=50601w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnInstance: Created new initiated conn=0x64129BF4, connid=-1, addr=172.18.194.183, port=5060, transport=tcp1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: gConnTab=0x64128D5C, addr=172.18.194.183, port=5060, connid=1, transport=tcp1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipInstanceHandleConnectionCreated: Moving connection=0x64129BF4, connid=1state to pending1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWConnectionCreated: context=0x64128D5C1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: gConnTab=0x64128D5C, addr=172.18.194.183, port=5060, connid=1, transport=tcp1w1d: //-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）

（注）例に示す IP アドレスおよびホスト名は架空のものです。

46



RFC 3261、RFC 3262、および RFC 3264 に対する SIP ゲートウェイの準拠

ここでは、前の項で説明した設定作業に対応する設定例を示します。

1w1d: %SYS-5-CONFIG_I: Configured from console by consoleBuilding configuration...

Current configuration : 3326 bytes!!Last configuration change at 18:09:20 EDT Fri Apr 23 2004!version 12.3service timestamps debug uptimeservice timestamps log uptimeno service password-encryptionboot-start-markerboot system tftp mantis/c3640-is-mz.disc_w_pi 172.18.207.10boot-end-marker!clock timezone EST -5clock summer-time EDT recurringvoice-card 3!aaa new-model!aaa accounting connection h323 start-stop group radiusaaa nas port extendedaaa session-id commonip subnet-zero!ip cefip host example.com 172.18.194.183ip host CALLGEN-SECURITY-V2 10.36.54.81 10.1.0.0ip name-server 172.18.192.48!isdn switch-type primary-ni!trunk group 1!voice service voipsiprel1xx require "100rel"transport switch udp tcp

!voice class uri 800 sippattern [email protected]!controller T1 3/0framing sflinecode amipri-group timeslots 1-24

!controller T1 3/1framing sflinecode amipri-group timeslots 1-24gw-accounting aaa

!interface Ethernet0/0description CentreComm Hub port 9 in PP070ip address 172.18.194.170 255.255.255.0

47



no ip proxy-arpip mtu 500half-duplexno cdp enableip rsvp bandwidth 100 100

!interface Serial3/0:23no ip addressno logging event link-statusisdn switch-type primary-niisdn incoming-voice voiceno cdp enable

!interface Serial3/1:23no ip addressno logging event link-statusisdn switch-type primary-niisdn protocol-emulate networkisdn incoming-voice voiceno cdp enable

!no ip http serverip classlessip route 0.0.0.0 0.0.0.0 172.18.194.1ip route 0.0.0.0 0.0.0.0 Ethernet0/0ip route 10.0.0.0 255.0.0.0 172.18.194.1ip route 172.16.0.0 255.0.0.0 Ethernet0/0!dialer-list 1 protocol ip permitno cdp run!radius-server host 10.13.84.133 auth-port 1645 acct-port 1646radius-server timeout 2radius-server key ciscoradius-server vsa send accountingradius-server vsa send authentication!control-plane!call application voice testapp79 tftp://172.18.207.10/mantis/my_app.tclcall application voice testapp888 tftp://172.18.207.10/mantis/AL_FEAT_SIP_URL_O_RV_79.tclcall application voice testapp888 mcid-dtmf 9876call 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 voipdestination-pattern 9876voice-class sip transport switch udp tcpsession protocol sipv2session target ipv4:172.18.194.183session transport udp

!dial-peer voice 222 potsincoming called-number .direct-inward-dial

48



!sip-uamax-forwards 65retry invite 4retry bye 4retry cancel 4retry comet 4retry notify 4timers connection aging 15offer call-hold conn-addr

!line con 0exec-timeout 0 0

line vty 0 4password password1

ntp clock-period 17179695ntp server 172.18.194.178ntp server 10.81.254.131!end

49


その他の参考資料


関連資料

規格

MIB

関連項目参照先

『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/configuration/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/command/reference/cme_cr.html

Cisco Unified Communications Manager Express のサ

ポートドキュメント

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/tsd_products_support_series_home.html

『Cisco Unified SIP SRST System Administrator Guide』 http://www.cisco.com/en/US/docs/voice_ip_comm/cusrst/admin/sipsrst/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/tclivrv2.html

規格タイトル

国際標準化機構（ISO）仕様、ISO 639 「Codes for Representation of Names of Languages」

MIB MIB リンク

なし選択したプラットフォーム、Cisco IOS リリース、および機能セッ

トの MIB を検索してダウンロードする場合は、次の URL にある Cisco MIB Locator を使用します。

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

50

http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/sip_cg-roadmap.html

http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/sip_cg-overview.html

http://www.cisco.com/en/US/docs/ios/voice/ivr/pre12.3_14_t/configuration/guide/ivrapp.pdf


http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/command/reference/cme_cr.html

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/tsd_products_support_series_home.html

http://www.cisco.com/en/US/docs/voice_ip_comm/cusrst/admin/sipsrst/configuration/guide/spsrst41.html

http://www.cisco.com/en/US/docs/ios/voice/vxml/developer/guide/vxmlprg.html


http://www.cisco.com/en/US/docs/ios/voice/tcl/developer/guide/tclivrv2.html

http://www.loc.gov/standards/iso639-2/

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



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

http://www.ietf.org/rfc/rfc2833.txt



















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

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.

説明リンク

Cisco Support Web サイトには、資料やツールなど幅

広いオンラインリソースが用意されており、シスコの

製品およびテクノロジーに関するトラブルシューティ

ングや技術的な問題の解決などに役立てることができ

ます。

以下を含むさまざまな作業にこの 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

http://www.cisco.com/techsupport

52

http://www.cisco.com/public/support/tac/home.shtml



Copyright © 2002–2010, シスコシステムズ合同会社 .All rights reserved.

53



54

Documents

SIP の RFC 準拠の実現 - cisco.com · SIP の RFC 準拠の実現 機能情報の確認 2 SIP：DNS SRV RFC 2782 Compliance の機能履歴 SIP：RFC 3261 Enhancements の機能履歴

SIP の RFC 準拠の実現 - cisco.com · SIP の RFC 準拠の実現機能情報の確認 2 SIP：DNS SRV RFC 2782 Compliance の機能履歴 SIP：RFC 3261 Enhancements の機能履歴