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

目次

SIP の RFC 準拠の実現

機能情報の確認

この章の構成

SIP の RFC 準拠の前提条件

SIP の RFC 準拠の制約事項

SIP の RFC 準拠に関する情報

SIP の RFC2543 準拠

SIP の RFC2782 準拠

SIP の RFC3261 準拠

SIP ヘッダー フィールド、ネットワーク コンポーネント、および方式

SIP 応答

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

SIP 拡張機能

SIP セキュリティ

SIP DTMF リレー

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

SIP ユニフォーム リソース ロケータ(URL)の比較

487 Sent for BYE 要求

3xx リダイレクション応答

DNS SRV クエリー手順

CANCEL Request Route ヘッダー

ユーザ パラメータの解釈

user=phone パラメータ

SIP 原因コード 303 および 411

Content-Type ヘッダーの柔軟性

SDP のオプションの「s=」行

INVITE および 2xx 応答への Allow ヘッダーの追加

Cancel および 2xx クラス応答の同時実行

UPDATE 要求の処理

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

Loose-Routing および Record-Route ヘッダー

最終応答前の複数の INVITE 要求

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

新しいオファーを伴う PRACK 要求

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

SIP の RFC3261、RFC3262、および RFC3264 への準拠

SIP メッセージング拡張機能

SIP の TCP および UDP 接続に関する拡張機能

大容量の SIP 要求に対するダイナミック トランスポート スイッチング(UPD から TCP)

Call-Hold の拡張機能

max-forwards コマンドの範囲拡張

SIP の FC 準拠の設定方法

RFC2543 への準拠の設定

RFC2782 への準拠の設定

RFC3261 への準拠の設定

RFC3261、RFC3262、および RFC3264 への準拠の設定

SIP メッセージングの設定

TCP および UDP 接続機能の設定

大容量の SIP 要求に対するダイナミック トランスポート スイッチング(UPD から TCP)の設定

Call-Hold の設定

Max Forwards の設定

SIP の RFC 準拠の確認

トラブルシューティングのヒント

SIP の RFC 準拠の設定例

RFC3261、RFC3262、および RFC3264 に対する SIP ゲートウェイの準拠

その他の参考資料

関連資料

規格

MIB

RFC

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

SIP の RFC 準拠の実現

この章では、公開されている Session Initiation Protocol(SIP)基準に準拠するための、Cisco IOS SIP ゲートウェイの使用方法または設定方法を説明します。次の機能について説明します。

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

SIP:Core SIP Technology Enhancements(RFC 2543 および RFC 2543-bis-04)

SIP:DNS SRV RFC 2782 Compliance(RFC 2782)

SIP:RFC 3261 Enhancements(RFC 3261)

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

SIP スタック ポータビリティ


) この機能については、次の URL の「Configuring SIP Message, Timer, and Response Features」の章を参照してください。http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/sip_cg-msg_tmr_rspns.html


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

リリース
変更点

15.0(1)XA

この機能は、Cisco IOS SIP Time Division Multiplexing(TDM; 時分割多重)ゲートウェイおよび Cisco Unified Border Elements(Cisco UBE)でサポートされます。この機能をイネーブルにする方法の詳細については、『 Cisco IOS Voice Command Reference 』( http://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_book.html )の encap clear-channel standard および voice-class sip encap clear-channel コマンドの説明を参照してください。

SIP:Core SIP Technology Enhancements の機能履歴

リリース
変更点

12.2(13)T

この機能は、SIP RFC 2543-bis-04(後に、RFC_3261 として発行)への準拠を実現するために導入されました。

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

リリース
変更点

12.2(2)XB

この機能が導入されました。

12.2(8)T

この機能がこのリリースに統合されました。

SIP:RFC 3261 Enhancements の機能履歴

リリース
変更点

12.3(4)T

この機能が導入されました。

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

リリース
変更点

12.3(8)T

この機能が導入されました。

機能情報の確認

ご使用のソフトウェア リリースによっては、この章に記載されている機能の一部がサポートされていない場合があります。最新の機能情報と注意事項については、ご使用のプラットフォームとソフトウェア リリースに対応したリリース ノートを参照してください。

プラットフォーム サポートと Cisco IOS および Catalyst OS ソフトウェア イメージ サポートに関する情報を入手するには、Cisco Feature Navigator を使用します。Cisco Feature Navigator には、 http://www.cisco.com/go/cfn からアクセスしてください。Cisco.com のアカウントは必要ありません。

SIP の RFC 準拠の前提条件

基本的な 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


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 準拠」

「SIP の RFC 2782 準拠」

「SIP の RFC 3261 準拠」

「SIP の RFC 3261、RFC 3262、および RFC 3264 への準拠」

SIP の RFC 2543 準拠

Cisco SIP ゲートウェイは RFC 2543 に準拠しています。ただし現在、RFC 3261 が RFC 2543 に取って代わっています。新しい RFC でサポートされる項目およびサポートされない項目の詳細については、「SIP の RFC 準拠の制約事項」および「SIP の RFC 3261 準拠」を参照してください。

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 の実装では、次をサポートしています。

SIP UPDATE 要求の受信および処理機能

最初のオファーと回答の交換

Via ヘッダーの branch および sent-by パラメータ

結合された要求の検出

ルーズ ルーティング

RFC 3261 の利点は次のとおりです。

現在の SIP 配置における Cisco IOS ゲートウェイの相互運用性の継続

新しい SIP 製品およびアプリケーションを使用した Cisco IOS ゲートウェイの相互運用性の拡張

ここでは、SIP の基本機能に関する次の情報について説明します。

「SIP ヘッダー フィールド、ネットワーク コンポーネント、および方式」

「SIP 応答」

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

「SIP 拡張機能」

「SIP セキュリティ」

「SIP DTMF リレー」

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

「SIP ユニフォーム リソース ロケータ(URL)の比較」

「487 Sent for BYE 要求」

「3xx リダイレクション応答」

「DNS SRV クエリー手順」

「CANCEL Request Route ヘッダー」

「ユーザ パラメータの解釈」

「user=phone パラメータ」

「SIP 原因コード 303 および 411」

「Content-Type ヘッダーの柔軟性」

「SDP のオプションの「s=」行」

「INVITE および 2xx 応答への Allow ヘッダーの追加」

「Cancel および 2xx クラス応答の同時実行」

「UPDATE 要求の処理」

SIP ヘッダー フィールド、ネットワーク コンポーネント、および方式

表 1 表 3 に、ヘッダー、コンポーネント、および方式を含む RFC 3261 SIP の機能を示します。また、Cisco SIP ゲートウェイがサポートする特定の機能がある場合はその機能も示します。

 

表 1 SIP ヘッダー フィールド

ヘッダー フィールド
シスコ ゲートウェイによるサポートの有無

Accept

あり。OPTIONS 応答メッセージで使用。

Accept-Encoding

なし

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

なし

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)

プロキシ サーバ

なし

リダイレクト サーバ

あり

レジストラ サーバ

 

表 3 SIP 方式

方式
シスコ ゲートウェイによるサポートの有無

ACK

あり

BYE

CANCEL

COMET

廃止。条件に合致。Quality of Service(QoS)実装で使用され、もう一方のエンドポイントに対して、条件が満たされているかどうか、つまり適切なリソースが予約されているかどうかを示します。

INVITE

あり。SIP ゲートウェイは、同じコール ID を持つが、Session Description Protocols(SDP)セッション パラメータの異なるミッドコール Invite 要求(転送アドレスを変更するため)をサポートします。ミッドコール INVITE 要求は、ポート番号やコーデックの変更、またはセッションの タイマー値の更新も行えます。

INFO

あり。SIP ゲートウェイは INFO メッセージの受け入れや生成を行えます。

NOTIFY

あり。Refer 要求の実装で使用されます。Notify メッセージにより、Refer 要求の発信側に転送の結果を通知できます。また Notify メッセージにより、加入者に対して、選択されたイベント(DTMF(Dual Tone MultiFrequency)イベント、または message waiting indication(MWI)イベントなど)で発生した変更を通知できます。

OPTIONS

あり。SIP ゲートウェイはこの方式のみを受信します。

PRACK

あり。Provisional Reliable Acknowledgements(PRACK)をイネーブルまたはディセーブルにします。

REFER

あり。SIP ゲートウェイは Refer 要求に応答し、また在席コール転送およびブラインド コール転送に関する Refer 要求を生成します。

REGISTER

あり。SIP ゲートウェイは SIP REGISTER 要求を送受信できます。

SUBSCRIBE

あり。SIP ゲートウェイは SUBSCRIBE 要求を生成して受け入れることができます。ゲートウェイは、DTMF テレフォニー イベントなど選択したアプリケーションや MWI に対する SUBSCRIBE 要求を処理します。

UPDATE

あり。SIP ゲートウェイは、メディアの変更、ターゲットの更新、および QoS シナリオに関する UPDATE を受け入れることができます。またゲートウェイは、QoS シナリオに対してのみ UPDATE を送信します。

SIP 応答

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

Cisco SIP ゲートウェイは、発信した、または終了したコールに対するキープアライブ メッセージの使用は開始しません。リモート ゲートウェイがキープアライブ メッセージを使用する場合、SIP ゲートウェイはそれに従います。

 

表 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

指定された場所に対応可能なユーザはいません。ヘッダーに代替場所が示されます。

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

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 ゲートウェイは、メディア ネゴシエーションが失敗した場合にこの応答を生成します。

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

着信側に連絡できましたが、セッションの説明の一部を受け入れできません。

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 拡張機能を示します。

 

表 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 ヘッダー)をサポートします。

SIP セキュリティ

表 14 および 表 15 に、RFC 3261 でサポートされる SIP セキュリティ暗号化および応答を示します。また、Cisco SIP ゲートウェイがサポートする特定の機能がある場合はその機能も示します。

 

表 14 SIP 暗号化モード

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

エンドツーエンド暗号化

なし。IPSEC をセキュリティに使用できます。

ホップバイホップ暗号化

SIP 応答のプライバシー

なし。

フィールド経由暗号化

なし。IPSEC をセキュリティに使用できます。

 

表 15 SIP 認証暗号化モード

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

ダイジェスト認証

あり

PGP

なし

プロキシ認証

なし

セキュア SIP または sips

URI スキームはサポートされません。

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 トーンを認識することによって実行されます。

必須

あり

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 対応のゲートウェイは、シスコおよび他のベンダー製のゲートウェイと相互運用できます。

必須

あり

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@172.18.193.120

同等 URL:

sip:36602@172.18.193.120:
sip:36602@172.18.193.120;tag=499270-A62;pname=pvalue
sip:36602@172.18.193.120;user=ip
sip:36602@172.18.193.120:5060

487 Sent for BYE 要求

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

3 xx リダイレクション応答

「SIP リダイレクト処理拡張の設定」を参照してください。

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:5550100@example.com
 

以前 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 および 2 xx 応答への Allow ヘッダーの追加

最初または re-INVITE 要求、または任意の 2 xx クラス応答で INVITE に対する Allow ヘッダーの使用が許可されています。Allow ヘッダーは、メッセージを生成するユーザ エージェントがサポートする方式の一覧を示します。Allow ヘッダーにより、メッセージを送信するユーザ エージェントでどの方式を実行するべきかがアドバタイズされるので、メッセージ トラフィックが無駄に混雑するのが回避されます。Allow ヘッダーには、INVITE、OPTIONS、BYE、CANCEL、ACK、PRACK、COMET、REFER、NOTIFY、INFO、SUBSCRIBE の内のどれでも、またはすべてを含めることができます。

Cancel および 2 xx クラス応答の同時実行

RFC 3261 に準拠して、INVITE に対する応答が受信される前に UAC がコールの終了を希望する場合、UAC は CANCEL を送信します。ただし、INVITE に対する CANCEL および 2 xx クラス応答が有線で渡された場合、UAC は INVITE に対する 2 xx も受け取ります。2 つのメッセージが渡されると、UAC は BYE 要求を送信することでコールを終了します。

UPDATE 要求の処理

RFC 2543 に取って代わった RFC 3261 では、セッションの作成、変更、終了を行うための SIP シグナリング プロトコルが定義されています。発信者 ID とプライバシーのための SIP 拡張 機能では、RFC 3261 仕様に準拠する次の SIP ゲートウェイ実装がサポートされます。

「SIP UPDATE 要求」

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

「Loose-Routing および Record-Route ヘッダー」

「最終応答前の複数の INVITE 要求」

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

「新しいオファーを伴う PRACK 要求」

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

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 メッセージを生成します。

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 を送信することで、要求を拒否しました。

図 2 最初の UPDATE の拒否

 

図 3 では、最初の INVITE 要求にはオファーが含まれておらず、UAS ゲートウェイは信頼できる暫定応答(Offer 1)とともに SDP を送信し、これを UAC はオファーとして処理しました。

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

 

図 4 では、UAS は PRACK を受信する前、つまりアーリー ダイアログが確立される前に、オファー(Offer 2)とともに UPDATE 要求を受信しており、これにより UAS(ゲートウェイ)は 491 Request Pending 応答を生成しました。

図 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 要求に対するエラー ケース

 

アクティブ状態での 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 拡張 では、受信したアドレスを使用して受信したパラメータを生成するためのサポートも追加されています。

発信者 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 応答

図 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 応答を生成して、コールをクリアします。

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

 

メッセージの例

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

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

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

1w0d:SIP Msg:ccsipDisplayMsg:Received:
INVITE sip:222@192.0.2.12:5060 SIP/2.0
Record-Route:<sip:222@192.0.2.4:5060;maddr=192.0.2.4>
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK1D38
From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DF
To:<sip:222@192.0.2.4>
Date:Mon, 08 Apr 2002 16:58:08 GMT
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14
Supported:timer
 

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

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

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

Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
CSeq:101 INVITE
Max-Forwards:70
Remote-Party-ID:<sip:111@192.0.2.14>;party=calling;screen=no;privacy=off
Timestamp:1018285088
Contact:<sip:111@192.0.2.14:5060>
Expires:180
Allow-Events:telephone-event
Content-Type:application/sdp
Content-Length:262
 

次の SDP は、メディア ストリームとコーデックを含む最初のオファー、およびメディアを受信するための IP アドレスとポートを構成しています。

v=0
o=CiscoSystemsSIP-GW-UserAgent 6579 1987 IN IP4 192.0.2.14
s=SIP Call
c=IN IP4 192.0.2.14
t=0 0
m=audio 17782 RTP/AVP 8 0 18 19
c=IN IP4 192.0.2.14
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:19 CN/8000
 
1w0d:SIP Msg:ccsipDisplayMsg:Sent:
SIP/2.0 100 Trying
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK1D38
From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DF
To:<sip:222@192.0.2.4>;tag=24D435A8-C29
Date:Sat, 07 Oct 2000 02:56:34 GMT
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14
Timestamp:1018285088
Server:Cisco-SIPGateway/IOS-12.x
CSeq:101 INVITE
 
Allow-Events:telephone-event
Content-Length:0
 

次の行では、ゲートウェイは、最初のオファーへの応答でアーリー メディア(early media)を送信することによって応答しています。

1w0d:SIP Msg:ccsipDisplayMsg:Sent:
SIP/2.0 183 Session Progress
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK1D38
From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DF
To:<sip:222@192.0.2.4>;tag=24D435A8-C29
Date:Sat, 07 Oct 2000 02:56:34 GMT
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14
Timestamp:1018285088
Server:Cisco-SIPGateway/IOS-12.x
CSeq:101 INVITE
Require:100rel
RSeq:5785
Allow:UPDATE
Allow-Events:telephone-event
Contact:<sip:222@192.0.2.12:5060>
Record-Route:<sip:222@192.0.2.4:5060;maddr=192.0.2.4>
Content-Disposition:session;handling=required
Content-Type:application/sdp
Content-Length:191
 
v=0
o=CiscoSystemsSIP-GW-UserAgent 5565 7580 IN IP4 192.0.2.12
s=SIP Call
c=IN IP4 192.0.2.12
t=0 0
m=audio 18020 RTP/AVP 8 19
c=IN IP4 192.0.2.12
a=rtpmap:8 PCMA/8000
a=rtpmap:19 CN/8000
 

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

1w0d:SIP Msg:ccsipDisplayMsg:Received:
PRACK sip:222@192.0.2.12:5060 SIP/2.0
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=6,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK40A
From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DF
To:<sip:222@192.0.2.4>;tag=24D435A8-C29
Date:Mon, 08 Apr 2002 16:58:08 GMT
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14
CSeq:102 PRACK
RAck:5785 101 INVITE
Content-Length:0
 
1w0d:SIP Msg:ccsipDisplayMsg:Sent:
SIP/2.0 200 OK
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=6,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK40A
From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DF
To:<sip:222@192.0.2.4>;tag=24D435A8-C29
Date:Sat, 07 Oct 2000 02:56:34 GMT
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14
Server:Cisco-SIPGateway/IOS-12.x
CSeq:102 PRACK
Content-Length:0
 

次の行では、UAS が異なるメディア ストリームとコーデックを持つアップデートされたオファーを受信していることを示しています。

1w0d:SIP Msg:ccsipDisplayMsg:Received:
UPDATE sip:222@192.0.2.12:5060 SIP/2.0
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bK10
Via:SIP/2.0/UDP 192.0.2.14:5060
To:<sip:222@192.0.2.4>;tag=24D435A8-C29
From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DF
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14
CSeq:103 UPDATE
Contact:sip:111@192.0.2.14:5060
Content-Length:262
 
v=0
o=CiscoSystemsSIP-GW-UserAgent 6579 1987 IN IP4 192.0.2.14
s=SIP Call
c=IN IP4 192.0.2.14
t=0 0
m=audio 17782 RTP/AVP 8 0 18 19
c=IN IP4 192.0.2.14
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:19 CN/8000
 

UPDATE 要求内の新しいオファーはサーバで受け入れ可能なため、サーバは 200 OK メッセージで対応する応答を使用して応答します。

1w0d:SIP Msg:ccsipDisplayMsg:Sent:
SIP/2.0 200 OK
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bK10,SIP/2.0/UDP 192.0.2.14:5060
From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DF
To:<sip:222@192.0.2.4>;tag=24D435A8-C29
Date:Sat, 07 Oct 2000 02:56:34 GMT
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14
Server:Cisco-SIPGateway/IOS-12.x
CSeq:103 UPDATE
Content-Type:application/sdp
Content-Length:191
 
v=0
o=CiscoSystemsSIP-GW-UserAgent 5565 7580 IN IP4 192.0.2.12
s=SIP Call
c=IN IP4 192.0.2.12
t=0 0
m=audio 18020 RTP/AVP 8 19
c=IN IP4 192.0.2.12
a=rtpmap:8 PCMA/8000
a=rtpmap:19 CN/8000
 
1w0d:SIP Msg:ccsipDisplayMsg:Sent:
SIP/2.0 200 OK
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=5,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK1D38
From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DF
To:<sip:222@192.0.2.4>;tag=24D435A8-C29
Date:Sat, 07 Oct 2000 02:56:34 GMT
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14
Timestamp:1018285088
Server:Cisco-SIPGateway/IOS-12.x
CSeq:101 INVITE
Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
Allow-Events:telephone-event
Contact:<sip:222@192.0.2.12:5060>
Record-Route:<sip:222@192.0.2.4:5060;maddr=192.0.2.4>
Content-Type:application/sdp
Content-Length:191
 
v=0
o=CiscoSystemsSIP-GW-UserAgent 5565 7580 IN IP4 192.0.2.12
s=SIP Call
c=IN IP4 192.0.2.12
t=0 0
m=audio 18020 RTP/AVP 8 19
c=IN IP4 192.0.2.12
a=rtpmap:8 PCMA/8000
a=rtpmap:19 CN/8000
 
1w0d:SIP Msg:ccsipDisplayMsg:Received:
ACK sip:222@192.0.2.12:5060 SIP/2.0
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=7,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK230
From:<sip:111@192.0.2.14>;tag=3DD33DE4-10DF
To:<sip:222@192.0.2.4>;tag=24D435A8-C29
Date:Mon, 08 Apr 2002 16:58:08 GMT
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14
Max-Forwards:70
CSeq:101 ACK
Content-Length:0
 
1w0d:SIP Msg:ccsipDisplayMsg:Sent:
BYE sip:222@192.0.2.4:50605060;maddr=192.0.2.4 SIP/2.0
Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bKCA
From:<sip:222@192.0.2.4>;tag=24D435A8-C29
To:<sip:111@192.0.2.14>;tag=3DD33DE4-10DF
Date:Sat, 07 Oct 2000 02:56:35 GMT
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14
User-Agent:Cisco-SIPGateway/IOS-12.x
Max-Forwards:70
Route:<sip:111@192.0.2.14:5060>
Timestamp:970887414
CSeq:101 BYE
Content-Length:0
 
1w0d:SIP Msg:ccsipDisplayMsg:Received:
SIP/2.0 200 OK
Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bKCA
From:<sip:222@192.0.2.4>;tag=24D435A8-C29
To:<sip:111@192.0.2.14>;tag=3DD33DE4-10DF
Date:Mon, 08 Apr 2002 16:58:29 GMT
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@192.0.2.14
Server:Cisco-SIPGateway/IOS-12.x
Timestamp:970887414
Content-Length:0
CSeq:101 BYE

ルーズ ルーティングのコール フローの例

次に、ルーズ ルーティング要求を示すメッセージの例を示します。

1w0d:SIP Msg:ccsipDisplayMsg:Received:
INVITE sip:222@192.0.2.12:5060 SIP/2.0
 

次のコール フローの SIP メッセージでは、Request-URI がネクストホップの宛先の SIP URI ではなく、宛先 UA の SIP URI、つまり SIP プロキシ サーバに設定されています。

Record-Route:<sip:222@192.0.2.4:5060;lr;maddr=192.0.2.4>
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK2394
From:<sip:111@192.0.2.14>;tag=3DD3A404-12A3
To:<sip:222@192.0.2.4>
Date:Mon, 08 Apr 2002 16:58:34 GMT
Call-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14
Supported:timer
Min-SE: 1800
Cisco-Guid:2991015782-1246237142-2148770832-4064420637
User-Agent:Cisco-SIPGateway/IOS-12.x
Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
CSeq:101 INVITE
Max-Forwards:70
Remote-Party-ID:<sip:111@192.0.2.14>;party=calling;screen=no;privacy=off
Timestamp:1018285114
Contact:<sip:111@192.0.2.14:5060>
Expires:180
Allow-Events:telephone-event
Content-Type:application/sdp
Content-Length:262
 
v=0
o=CiscoSystemsSIP-GW-UserAgent 1981 1761 IN IP4 192.0.2.14
s=SIP Call
c=IN IP4 192.0.2.14
t=0 0
m=audio 18354 RTP/AVP 8 0 18 19
c=IN IP4 192.0.2.14
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:19 CN/8000
 
1w0d:SIP Msg:ccsipDisplayMsg:Sent:
SIP/2.0 100 Trying
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK2394
From:<sip:111@192.0.2.14>;tag=3DD3A404-12A3
To:<sip:222@192.0.2.4>;tag=24D49BE8-2346
Date:Sat, 07 Oct 2000 02:57:00 GMT
Call-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14
Timestamp:1018285114
Server:Cisco-SIPGateway/IOS-12.x
CSeq:101 INVITE
Allow-Events:telephone-event
Content-Length:0
 
1w0d:SIP Msg:ccsipDisplayMsg:Sent:
SIP/2.0 180 Ringing
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK2394
From:<sip:111@192.0.2.14>;tag=3DD3A404-12A3
To:<sip:222@192.0.2.4>;tag=24D49BE8-2346
Date:Sat, 07 Oct 2000 02:57:00 GMT
Call-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14
Timestamp:1018285114
Server:Cisco-SIPGateway/IOS-12.x
CSeq:101 INVITE
Allow:UPDATE
Allow-Events:telephone-event
Contact:<sip:222@192.0.2.12:5060>
Record-Route:<sip:222@192.0.2.4:5060;lr;maddr=192.0.2.4>
Content-Length:0
 
1w0d:SIP Msg:ccsipDisplayMsg:Sent:
SIP/2.0 200 OK
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=9,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK2394
From:<sip:111@192.0.2.14>;tag=3DD3A404-12A3
To:<sip:222@192.0.2.4>;tag=24D49BE8-2346
Date:Sat, 07 Oct 2000 02:57:00 GMT
Call-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14
Timestamp:1018285114
Server:Cisco-SIPGateway/IOS-12.x
CSeq:101 INVITE
Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
Allow-Events:telephone-event
Contact:<sip:222@192.0.2.12:5060>
Record-Route:<sip:222@192.0.2.4:5060;lr;maddr=192.0.2.4>
Content-Type:application/sdp
Content-Length:191
 
v=0
o=CiscoSystemsSIP-GW-UserAgent 5181 4737 IN IP4 192.0.2.12
s=SIP Call
c=IN IP4 192.0.2.12
t=0 0
m=audio 16720 RTP/AVP 8 19
c=IN IP4 192.0.2.12
a=rtpmap:8 PCMA/8000
a=rtpmap:19 CN/8000
 
1w0d:SIP Msg:ccsipDisplayMsg:Received:
ACK sip:222@192.0.2.12:5060 SIP/2.0
Via:SIP/2.0/UDP 192.0.2.4:5060;branch=10,SIP/2.0/UDP
192.0.2.14:5060;branch=z9hG4bK103D
From:<sip:111@192.0.2.14>;tag=3DD3A404-12A3
To:<sip:222@192.0.2.4>;tag=24D49BE8-2346
Date:Mon, 08 Apr 2002 16:58:34 GMT
Call-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14
Max-Forwards:70
CSeq:101 ACK
Content-Length:0
 
1w0d:SIP Msg:ccsipDisplayMsg:Sent:
BYE sip:111@192.0.2.14:5060 SIP/2.0
Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bK18B6
From:<sip:222@192.0.2.4>;tag=24D49BE8-2346
To:<sip:111@192.0.2.14>;tag=3DD3A404-12A3
Date:Sat, 07 Oct 2000 02:57:01 GMT
Call-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14
User-Agent:Cisco-SIPGateway/IOS-12.x
Max-Forwards:70
Route:<sip:222@192.0.2.4:5060;lr;maddr=192.0.2.4>
Timestamp:970887440
CSeq:101 BYE
Content-Length:0
 
1w0d:SIP Msg:ccsipDisplayMsg:Received:
SIP/2.0 200 OK
Via:SIP/2.0/UDP 192.0.2.12:5060;branch=z9hG4bK18B6
From:<sip:222@192.0.2.4>;tag=24D49BE8-2346
To:<sip:111@192.0.2.14>;tag=3DD3A404-12A3
Date:Mon, 08 Apr 2002 16:58:54 GMT
Call-ID:B2474766-4A4811D6-8015A410-F242231D@192.0.2.14
Server:Cisco-SIPGateway/IOS-12.x
Timestamp:970887440
Content-Length:0
CSeq:101 BYE

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

Internet Engineering Task Force(IETF)は常に SIP 基準のアップデートを行っています。この機能により、Cisco SIP ゲートウェイに対して実行された特定のアップデートまたは最適化が示され、IETF への準拠が維持されます。次の基準がアップデートされました。

RFC 3261:SIP 向けのコア基準(RFC 2543 は廃止)

RFC 3262:SIP における暫定応答の信頼性に関する基準

RFC 3264:Session Description Protocol(SDP)に対するオファー/応答モデルに関する基準

SIP をご使用のお客様に高品質なサービスを提供するため、シスコは、最新の SIP 関連 RFC に準拠するよう SIP ゲートウェイを最適化しています。さらに、下位互換性を保持することにより、現在の RFC をまだサポートしていないゲートウェイとの相互運用性を実現します。

ここでは、次の内容について説明します。

「SIP メッセージング拡張機能」

「SIP の TCP および UDP 接続に関する拡張機能」

「大容量の SIP 要求に対するダイナミック トランスポート スイッチング(UPD から TCP)」

「Call-Hold の拡張機能」

「max-forwards コマンドの範囲拡張」

SIP メッセージング拡張機能

SIP メッセージングに対して、次の変更または追加が行われました。

この機能は 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 応答の送信失敗」

「TCP および UDP 接続の再利用」

「トランザクション ベースの転送のスイッチングと使用方法」

「リモート エンドの接続閉鎖の検出」

「元の接続がドロップされた場合に応答を送信するための新しい接続の作成」

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 接続を開きます。ゲートウェイは、特定の宛先 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 ダイヤル ピアがない場合に限り、考慮されます。

この機能は、デフォルトではディセーブルになっています。

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 への準拠の設定」

「RFC 2782 への準拠の設定」

「RFC 3261 への準拠の設定」

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

「SIP の RFC 準拠の確認」

「トラブルシューティングのヒント」


) • 各手順を実行する前に、次の情報を理解してください。

「SIP の RFC 準拠の前提条件」

「SIP の RFC 準拠の制約事項」

手順の支援情報については、上記の検証およびトラブルシューティングの項を参照してください。


 

RFC 2543 への準拠の設定

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

RFC 2782 への準拠の設定

RFC 2782 への準拠を設定するには、次の手順を実行します。

手順の概要

1. enable

2. configure terminal

3. sip-ua

4. srv version

5. exit

手順の詳細

 

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

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

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

RFC 3261 への準拠の設定

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

SIP メッセージングの設定

設定は必要ありません。

TCP および UDP 接続機能の設定

非アクティビティのため SIP UA が TCP または UDP 接続を期限切れにするまでの時間を設定するには、次の手順を実行します。

手順の概要

1. enable

2. configure terminal

3. sip-ua

4. timers connection aging

5. exit

手順の詳細

 

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

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

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

ステップ 3

sip-ua

 

Router(config)# sip-ua

SIP ユーザ エージェント コンフィギュレーション モードを開始します。

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

 
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 要求に対するダイナミック トランスポート スイッチングのダイヤル ピア ベースでの設定」

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

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

特定のダイヤル ピアに対して UDP および TCP 転送メカニズム間のスイッチングを設定するには、次の手順を実行します。


) • UDP から TCP へのダイナミック トランスポート スイッチングは、デフォルトではディセーブルになっています。

ダイヤル ピアの音声コンフィギュレーション モードでダイナミック トランスポート スイッチングがイネーブルに設定されている場合、この設定がグローバル設定より優先されます。


 

手順の概要

1. enable

2. configure terminal

3. dial-peer voice voip

4. voice-class sip transport switch udp tcp

5. exit

手順の詳細

 

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

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

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

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

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

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

Cisco SIP ゲートウェイのすべての接続に対して UDP および TCP 転送メカニズム間のスイッチングを設定するには、次の手順を実行します。


) • UDP から TCP へのダイナミック トランスポート スイッチングは、デフォルトではディセーブルになっています。

ダイヤル ピアの音声コンフィギュレーション モードでダイナミック トランスポート スイッチングがイネーブルに設定されている場合、この設定がグローバル設定より優先されます。一致する VoIP ダイヤル ピアがない場合に限り、次に示すグローバル設定を考慮してください。


 

手順の概要

1. enable

2. configure terminal

3. voice service voip

4. sip

5. transport switch udp tcp

6. exit

手順の詳細

 

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

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

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

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

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


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

debug ccsip transport

show sip-ua connections

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


 

Call-Hold の設定

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

手順の概要

1. enable

2. configure terminal

3. sip-ua

4. offer call-hold

5. exit

手順の詳細

 

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

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

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

ステップ 3

sip-ua

 

Router(config)# sip-ua

SIP ユーザ エージェント コンフィギュレーション モードを開始します。

ステップ 4

offer call-hold { conn-addr | direction-attr }

 
Router(config-sip-ua)# offer call-hold direction-attr

SIP ゲートウェイによる call-hold 要求の開始方法を指定します。キーワードは次のとおりです。

conn-addr :call-hold 要求を開始するのに接続アドレスを使用する RFC 2543/RFC 3261 方式。0.0.0.0. を使用します。

direction-attr :call-hold 要求を開始するのに方向アトリビュートを使用する RFC 3264 方式。SDP で方向アトリビュートを使用します。

ステップ 5

exit

 

Router(config-sip-ua)# exit

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

Max Forwards の設定

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

手順の概要

1. enable

2. configure terminal

3. sip-ua

4. max-forwards

5. exit

手順の詳細

 

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

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

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

ステップ 3

sip-ua

 

Router(config)# sip-ua

SIP ユーザ エージェント コンフィギュレーション モードを開始します。

ステップ 4

max-forwards number

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

ホップ、つまり SIP 要求を転送できるプロキシ サーバまたはリダイレクト サーバの最大数を設定します。引数は次のとおりです。

number :転送数。範囲:1 ~ 70。デフォルト:70。

ステップ 5

exit

 

Router(config-sip-ua)# exit

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

SIP の RFC 準拠の確認

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


) 通常の確認シーケンスには、show sip-ua connections コマンドのいずれかを使用してコールの統計情報を表示し、続いて clear sip-ua tcp connection または clear sip-ua udp connection コマンドを適切に使用することで統計情報をクリアします。


手順の概要

1. show sip-ua connections

2. show sip-ua statistics

手順の詳細


ステップ 1 show sip-ua connections

コールが行われた後、このコマンドを使用して、接続の詳細を確認します。

次の出力例では、複数の宛先に対する複数のコールを示します。この例では UDP の詳細を示していますが、コマンド出力は TCP コールと同様です。

Router# show sip-ua connections udp detail
 
Total active connections : 2
No. of send failures : 0
No. of remote closures : 0
No. of conn. failures : 0
No. of inactive conn. ageouts : 0
---------Printing Detailed Connection Report---------
Note:
** Tuples with no matching socket entry
- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port>'
to overcome this error condition
++ Tuples with mismatched address/port entry
- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port> id <connid>'
to overcome this error condition
Remote-Agent:172.18.194.183, Connections-Count:1
Remote-Port Conn-Id Conn-State WriteQ-Size
=========== ======= =========== ===========
5060 1 Established 0
Remote-Agent:172.19.154.18, Connections-Count:1
Remote-Port Conn-Id Conn-State WriteQ-Size
=========== ======= =========== ===========
5060 2 Established 0
 

次の出力例では、特定のターゲット(この場合は 172.18.194.183、ポート 5060)への接続に関するシーケンシャル表示とコール統計情報のクリアを示します。


注意 clear コマンドを使用する際は注意が必要です。コマンドについての問題または影響を理解しないで不適切に使用すると、誤ったコール動作、不適切な接続の使用、および接続失敗を招くおそれがあります。

1. show sip-ua connections コマンドの出力には、コール統計情報が表示されます。

Router# show sip-ua connections tcp detail
 
Total active connections : 1
No. of send failures : 0
No. of remote closures : 0
No. of conn. failures : 0
No. of inactive conn. ageouts : 0
Max. tcp send msg queue size of 1, recorded for 172.18.194.183:5060
---------Printing Detailed Connection Report---------
Note:
** Tuples with no matching socket entry
- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port>'
to overcome this error condition
++ Tuples with mismatched address/port entry
- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port> id <connid>'
to overcome this error condition
Remote-Agent:172.18.194.183, Connections-Count:1
Remote-Port Conn-Id Conn-State WriteQ-Size
=========== ======= =========== ===========
5060 1 Established 0
 

2. clear sip-ua tcp connection コマンドの出力には、統計情報がクリアされていることが示されます。

Router# clear sip-ua tcp connection id 1 target ipv4:172.18.194.183:5060
 
Purging the entry from sip tcp process
Purging the entry from reusable global connection table
 

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

Router# show sip-ua connections tcp detail
 
Total active connections : 0
No. of send failures : 0
No. of remote closures : 0
No. of conn. failures : 0
No. of inactive conn. ageouts : 0
Max. tcp send msg queue size of 1, recorded for 172.18.194.183:5060
---------Printing Detailed Connection Report---------
Note:
** Tuples with no matching socket entry
- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port>'
to overcome this error condition
++ Tuples with mismatched address/port entry
- Do 'clear sip <tcp/udp> conn t ipv4:<addr>:<port> id <connid>'
to overcome this error condition
Remote-Agent:172.18.194.183, Connections-Count:0
 

ステップ 2 show sip-ua statistics

このコマンドを使用して、UPDATE 要求を含む SIP 統計情報を表示します。

Router# show sip-ua statistics
 
SIP Response Statistics (Inbound/Outbound)
Informational
Trying 1/4, Ringing 0/0,
Forwarded 0/0, Queued 0/0,
SessionProgress 1/4
Success:
OkInvite 1/2, OkBye 1/2,
OkCancel 0/2, OkOptions 0/0,
OkPrack 1/4, OkPreconditionMet 0/0,
OkSubscribe 0/0, OkNotify 0/0,
OkInfo 0/0, 202Accepted 0/0,
OkUpdate 0/0
Redirection (Inbound only):
MultipleChoice 0, MovedPermanently 0,
MovedTemporarily 0, UseProxy 0,
AlternateService 0
Client Error:
BadRequest 0/0, Unauthorized 0/0,
PaymentRequired 0/0, Forbidden 0/0,
NotFound 0/0, MethodNotAllowed 0/0,
NotAcceptable 0/0, ProxyAuthReqd 0/0,
ReqTimeout 0/0, Conflict 0/0, Gone 0/0,
ReqEntityTooLarge 0/0, ReqURITooLarge 0/0,
UnsupportedMediaType 0/0, BadExtension 0/0,
TempNotAvailable 0/0, CallLegNonExistent 0/0,
LoopDetected 0/0, TooManyHops 0/0,
AddrIncomplete 0/0, Ambiguous 0/0,
BusyHere 0/0, RequestCancel 0/2,
NotAcceptableMedia 0/0, BadEvent 0/0,
SETooSmall 0/0, RequestPending 0/0
Server Error:
InternalError 0/0, NotImplemented 0/0,
BadGateway 0/0, ServiceUnavail 2/0,
GatewayTimeout 0/0, BadSipVer 0/0,
PreCondFailure 0/0
Global Failure:
BusyEverywhere 0/0, Decline 0/0,
NotExistAnywhere 0/0, NotAcceptable 0/0
Miscellaneous counters:
RedirectRspMappedToClientErr 0
SIP Total Traffic Statistics (Inbound/Outbound)
Invite 4/4, Ack 4/3, Bye 2/1,
Cancel 2/0, Options 0/0,
Prack 4/1, Comet 0/0,
Subscribe 0/0, Notify 0/0,
Refer 0/0, Info 0/0,
Update 0/0
Retry Statistics
Invite 1, Bye 0, Cancel 0, Response 0,
Prack 0, Comet 0, Reliable1xx 0, Notify 0
 
SDP application statistics:
Parses: 6, Builds 10
Invalid token order: 0, Invalid param: 0
Not SDP desc: 0, No resource: 0
Last time SIP Statistics were cleared: <never>
 


 

トラブルシューティングのヒント


) 一般的なトラブルシューティングのヒント、および重要な debug コマンドについては、「一般的なトラブルシューティングのヒント」を参照してください。


SIP 関連のデバッグをイネーブルにするには、 debug ccsip all コマンドを使用します。

debug ccsip transport コマンドを使用して、Invite メッセージを送信すると同時に、転送および接続に関連する操作をデバッグします。

これらのコマンドの一部の出力例を、次に示します。

debug ccsip transport コマンドの出力例

ここで取り上げる操作は、次の内容を示しています。

接続が確立されており、Invite が送信されていること。

最初の Invite メッセージが UDP を介して転送されていること。

リモート ターゲットつまり要求の送信先の詳細。

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

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

Router# debug ccsip transport
.
.
.
1w1d: //18/8E16980D800A/SIP/Transport/sipSPISendInvite: Sending Invite to the transport layer
1w1d: //18/8E16980D800A/SIP/Transport/sipSPIGetSwitchTransportFlag: Return the Global configuration, Switch Transport is TRUE
1w1d: //18/8E16980D800A/SIP/Transport/sipSPITransportSendMessage: msg=0x64082D50, addr=172.18.194.183, port=5060, sentBy_port=0, is_req=1, transport=1, switch=1, callBack=0x614FAB58
1w1d: //18/8E16980D800A/SIP/Transport/sipSPITransportSendMessage: Proceedable for sending msg immediately
1w1d: //18/8E16980D800A/SIP/Transport/sipTransportLogicSendMsg: switch transport is 1
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportGetInterfaceMtuSize: MTU size for remote address 172.18.194.183 is 500
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportVerifyMsgForMTUThreshold: Interface MTU Size 500, Msg Size 1096
1w1d: //18/8E16980D800A/SIP/Transport/sipTransportLogicSendMsg: Switching msg=0x64082D50 transport UDP->TCP
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportSetAgeingTimer: Aging timer initiated for holder=0x64084058,addr=172.18.194.183
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnHolder: Created new holder=0x64084058, addr=172.18.194.183
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostRequestConnection: Posting TCP conn create request for addr=172.18.194.183, port=5060, context=0x64128D5C
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportSetConnWaitTimer: Wait timer set for connection=0x64129BF4,addr=172.18.194.183, port=5060
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnInstance: Created new initiated conn=0x64129BF4, connid=-1, addr=172.18.194.183, port=5060, transport=tcp
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: gConnTab=0x64128D5C, addr=172.18.194.183, port=5060, connid=1, transport=tcp
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipInstanceHandleConnectionCreated: Moving connection=0x64129BF4, connid=1state to pending
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWConnectionCreated: context=0x64128D5C
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: gConnTab=0x64128D5C, addr=172.18.194.183, port=5060, connid=1, transport=tcp
1w1d: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting send for msg=0x64082D50, addr=172.18.194.183, port=5060, connId=1 for TCP
.
.
.

SIP の RFC 準拠の設定例

ここでは、次の設定例について説明します。

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


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


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

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

1w1d: %SYS-5-CONFIG_I: Configured from console by console
Building configuration...
 
Current configuration : 3326 bytes
!
!Last configuration change at 18:09:20 EDT Fri Apr 23 2004
!
version 12.3
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
boot-start-marker
boot system tftp mantis/c3640-is-mz.disc_w_pi 172.18.207.10
boot-end-marker
!
clock timezone EST -5
clock summer-time EDT recurring
voice-card 3
!
aaa new-model
!
aaa accounting connection h323 start-stop group radius
aaa nas port extended
aaa session-id common
ip subnet-zero
!
ip cef
ip host example.com 172.18.194.183
ip host CALLGEN-SECURITY-V2 10.36.54.81 10.1.0.0
ip name-server 172.18.192.48
!
isdn switch-type primary-ni
!
trunk group 1
!
voice service voip
sip
rel1xx require "100rel"
transport switch udp tcp
!
voice class uri 800 sip
pattern test@example.com
!
controller T1 3/0
framing sf
linecode ami
pri-group timeslots 1-24
!
controller T1 3/1
framing sf
linecode ami
pri-group timeslots 1-24
gw-accounting aaa
!
interface Ethernet0/0
description CentreComm Hub port 9 in PP070
ip address 172.18.194.170 255.255.255.0
no ip proxy-arp
ip mtu 500
half-duplex
no cdp enable
ip rsvp bandwidth 100 100
!
interface Serial3/0:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable
!
interface Serial3/1:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn protocol-emulate network
isdn incoming-voice voice
no cdp enable
!
no ip http server
ip classless
ip route 0.0.0.0 0.0.0.0 172.18.194.1
ip route 0.0.0.0 0.0.0.0 Ethernet0/0
ip route 10.0.0.0 255.0.0.0 172.18.194.1
ip route 172.16.0.0 255.0.0.0 Ethernet0/0
!
dialer-list 1 protocol ip permit
no cdp run
!
radius-server host 10.13.84.133 auth-port 1645 acct-port 1646
radius-server timeout 2
radius-server key cisco
radius-server vsa send accounting
radius-server vsa send authentication
!
control-plane
!
call application voice testapp79 tftp://172.18.207.10/mantis/my_app.tcl
call application voice testapp888 tftp://172.18.207.10/mantis/AL_FEAT_SIP_URL_O_RV_79.tcl
call application voice testapp888 mcid-dtmf 9876
call application voice testapp888 test 5444
!
voice-port 1/1/0
!
voice-port 1/1/1
!
voice-port 3/0:23
!
voice-port 3/1:23
!
dial-peer cor custom
!
dial-peer voice 9876 voip
destination-pattern 9876
voice-class sip transport switch udp tcp
session protocol sipv2
session target ipv4:172.18.194.183
session transport udp
!
dial-peer voice 222 pots
incoming called-number .
direct-inward-dial
!
sip-ua
max-forwards 65
retry invite 4
retry bye 4
retry cancel 4
retry comet 4
retry notify 4
timers connection aging 15
offer call-hold conn-addr
!
line con 0
exec-timeout 0 0
line vty 0 4
password password1
 
ntp clock-period 17179695
ntp server 172.18.194.178
ntp server 10.81.254.131
!
end

その他の参考資料

関連資料

関連項目
参照先

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
MIB リンク

なし

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

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

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

説明
リンク

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