• 検索結果がありません。

SIP の RFC 準拠の実現

N/A
N/A
Protected

Academic year: 2021

シェア "SIP の RFC 準拠の実現"

Copied!
54
0
0

読み込み中.... (全文を見る)

全文

(1)

この章では、公開されている

Session Initiation Protocol

SIP

)基準に準拠するための、

Cisco IOS SIP

ゲートウェイの使用方法または設定方法を説明します。次の機能について説明します。

• RFC 4040 ベースの

SIP

コール用クリア

チャネル

コーデック

ネゴシエーション

• SIP:

Core SIP Technology Enhancements

RFC 2543

および

RFC 2543-bis-04

• SIP:

DNS SRV RFC 2782 Compliance

RFC 2782

• SIP:

RFC 3261 Enhancements

RFC 3261

• RFC 3261、

RFC 3262

、および

RFC 3264

に対する

SIP

ゲートウェイの準拠

• SIP スタック

ポータビリティ

(注)

この機能については、次の

URL

の「Configuring SIP Message, Timer, and Response

Features」の章を参照してください。

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

tml

RFC 4040

ベースの

SIP

コール用クリア

チャネル

コーデック

ネゴシエーションの機能履歴

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_bo

ok.html)の

encap clear-channel standard

および

voice-class sip encap

clear-channel コマンドの説明を参照してください。

リリース

変更点

12.2(13)T

この機能は、

SIP RFC 2543-bis-04

(後に、

RFC_3261

として発行)への準

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

(2)

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

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

(3)

SIP

RFC

準拠の制約事項

• RFC 3261 に記載されているとおり、次の項目はサポートされていません。

– SIP UPDATE 要求の送信。ゲートウェイが送受信できるのは、

UPDATE

要求だけです。

– IPv6 ホスト

アドレスを持つ

SIP

セキュアな

SIP

。セキュアな

SIP

は、セキュアな

Uniform Resource Identifiers

URI;

ユニ

フォーム

リソース識別子)です。発信側が

SIP

を使用してコールを行った場合、着信側へは

セキュアなメッセージ転送が行われます。

– Unicode Transformation Format Version 8(

UTF-8

)で符号化された、

SIP

ヘッダー内で引用

された文字列のフィールド文字

0x0 to 0x7E

• RFC 3264 に記載されているとおり、

0

と等しい

bandwidth (b=) SDP

アトリビュートはサポートさ

れていません。

SIP

RFC

準拠に関する情報

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

SIP

RFC 2543

準拠」(

P.3

SIP

RFC 2782

準拠」(

P.3

SIP

RFC 3261

準拠」(

P.3

SIP

RFC 3261

RFC 3262

、および

RFC 3264

への準拠」(

P.32

SIP

RFC 2543

準拠

Cisco SIP

ゲートウェイは

RFC 2543

に準拠しています。ただし現在、

RFC 3261

RFC 2543

に取っ

て代わっています。新しい

RFC

でサポートされる項目およびサポートされない項目の詳細については、

SIP

RFC

準拠の制約事項」(

P.3

および

SIP

RFC 3261

準拠」(

P.3

を参照してください。

SIP

RFC 2782

準拠

Cisco VoIP

ゲートウェイの

SIP

は、

Domain Name System Server

DNS SRV

)クエリーを使用して、

ユーザのエンドポイントの

IP

アドレスを決定します。クエリー文字列は、

RFC 2052

で定義されてい

るとおり、「

protocol.transport

」の形式のプレフィクスを持ちます。このプレフィクスは、ネクスト

ホップ

SIP

サーバの

Fully Qualified Domain Name

FQDN;

完全修飾ドメイン名)に付きます。

Cisco VoIP

ゲートウェイには、別のプレフィクス形式が追加され、現在はデフォルトになっています。

この

2

番目のプレフィクス形式は

RFC 2782

で定義されたものです。この

RFC 2782

により

RFC 2052

2000

2

月に廃止されています。新しい形式は

RFC 2782

に準拠しており、「

_protocol._transport

のようにプロトコル

ラベルに下線「_」が追加されます。下線を追加することで、関連のない目的に同

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

SIP

RFC 3261

準拠

廃止になった

RFC 2543

に代わる

RFC 3261

では、セッションを作成、変更、終了するための

SIP

シグナ

リング

プロトコルを定義しています。シスコによる

RFC 3261

の実装では、次をサポートしています。

(4)

• 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

なし

(5)

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

ヘッダーフィールド(続き)

ヘッダー

フィールド

シスコ

ゲートウェイによるサポートの有無

(6)

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

ヘッダーフィールド(続き)

ヘッダー

フィールド

シスコ

ゲートウェイによるサポートの有無

(7)

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

を送信します。

(8)

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

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

が示されます。

(9)

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

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

(10)

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

ゲートウェ

イは、メディア

ネゴシエーションが失敗した場合にこの応答を生成し

ます。

7

4xx

応答(続き)

(11)

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

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

ません。

7

4xx

応答(続き)

(12)

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

なし

(13)

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

なし

プロキシ認証

なし

(14)

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

トーンを認識することによって実行されま

す。

必須

あり

(15)

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

ファックス要件(続き)

要件

説明

必須または任

サポートの有無

(16)

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

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

(17)

同等

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

)ステータス

メッセージで応答する必要があります。

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

要求の要求行は、次のように見える場合があります。

(18)

以前

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

(19)

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

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

メッセージ

表 4 1xx  応答 1xx 応答 説明 100 Trying 発信側に代わってアクションが実行されていますが、着信側の場所は まだ確認されていません。 SIP  ゲートウェイは、着信した  Invite  要求に 対してこの応答を生成します。ゲートウェイは、この応答を受け取る とすぐに、 Invite  要求の再送信を停止して、 180 Ringing  または  200  OK  応答を待ちます。 180 Ringing 着信側の場所が確認され、コールがあることが通知されています。着 信側の場所が確認
表 6 3xx  応答 (続き)
表 7 4xx  応答 (続き)
表 7 4xx  応答 (続き)
+7

参照

関連したドキュメント

仕上げを含む製造プロセスの手順によって品質が担保され ます。すべての継手も ASME BPE 規格に正確に準拠して おり、 ASME BPE

本手順書は複数拠点をアグレッシブモードの IPsec-VPN を用いて FortiGate を VPN

燃料取り出しを安全・着実に進めるための準備・作業に取り組んでいます。 【燃料取り出しに向けての主な作業】

・本計画は都市計画に関する基本的な方 針を定めるもので、各事業の具体的な

・電源投入直後の MPIO は出力状態に設定されているため全ての S/PDIF 信号を入力する前に MPSEL レジスタで MPIO を入力状態に設定する必要がある。MPSEL

最初の 2/2.5G ネットワークサービス停止は 2010 年 3 月で、次は 2012 年 3 月であり、3 番 目は 2012 年 7 月です。. 3G ネットワークは 2001 年と

定的に定まり具体化されたのは︑

三 配電費の部門の第一次整理原価を、基礎原価等項目