Cisco Unified Communications Manager SIP 回線メッセージング ガイド(標準) Cisco Unified Communications Manager Release 9.1(1)
SIP 標準回線インターフェイス
SIP 標準回線インターフェイス
発行日;2013/08/13 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 1MB) | フィードバック

目次

SIP 標準回線インターフェイス

定義/用語集

新機能および変更情報

Cisco Unified Communications Manager Release 9.1(1)

以前のリリースでサポートされている機能

Cisco Unified Communications Manager Release 9.0(1)

Cisco Unified Communications Manager Release 8.6(1)

標準インターフェイス準拠の要約

固有および非標準 SIP ヘッダーおよび識別サービス

Remote-Party-ID ヘッダー

発呼回線および名前の ID 表示

発呼回線および名前の ID 表示制限

接続回線と名前の ID 表示

接続回線と名前の ID 表示制限

CPN 番号表示

サポートされるメディア タイプ

サポートされるイベント パッケージ

サポートされるコンテンツ タイプ

SIP メッセージ フィールド

要求メッセージ

INVITE

ACK

応答メッセージ

180 呼び出し中

183 セッション中

2xx

メッセージ タイマー

メッセージの再試行回数

標準機能のシナリオ

登録

RFC3261 対応電話機のソース デバイス ID

MultiLine 登録

REGISTER Refresh(キープアライブ)

デバイスのバインディング

同じ AOR の複数のバインディング

Contact: *

基本的なコール

単純な保留と復帰

転送

在席転送

初期在席転送

ブラインド転送

3 者間コール

コール転送

メッセージ待機インジケータ

エンドポイントが返す 302 リダイレクト

エンドポイントが返す 486 通話中

特定のコール セットアップ障害のアナウンス

INFO パッケージ

INFO 会議パッケージのネゴシエーション

G.Clear コール

G.Clear コールの SDP の例

G.Clear コールのアーリー オファー サポート

BFCP

リソース プライオリティを使用した Multilevel Precedence and Preemption

SIP コールの発信 ID および着信 CLI

URI ダイヤル

電話番号の非通知コールの拒否

SIP 標準回線インターフェイス

この章では、Cisco Unified CM SIP 回線側デバイスの外部インターフェイスについて説明します。回線側インターフェイス上でサポートされる SIP プリミティブを中心に、テクニカル サポートおよび将来の導入のためのガイドとして使用できるコール フロー シナリオについて説明します。

ここでは、Cisco Unified CM SIP 回線インターフェイスについて、外部インターフェイスの視点から説明します。

この章の内容は、次のとおりです。

「定義/用語集」

「新機能および変更情報」

「標準インターフェイス準拠の要約」

「SIP メッセージ フィールド」

「標準機能のシナリオ」

定義/用語集

 

略語/用語
定義

AOR

Address of Record(レコードのアドレス)

BLF

Busy Lamp Field(ビジー ランプ フィールド)

Cseq

Call Sequence Number(コール シーケンス番号)

CPN

Calling Party Normalization(発呼側の正規化)

CSS

Calling Search Space(コーリング サーチ スペース)

CTI

Computer Telephony Integration(コンピュータ テレフォニー インテグレーション)

DND

Do Not Disturb(サイレント)

DNS

Domain Name Server(ドメイン ネーム サーバ)

DTMF

Dual Tone Multifrequency(デュアル トーン多重周波数)

FECC

Far-End Camera Control(遠端カメラ制御)

FMTP

Format-Specific Parameters(Format-Specific のパラメータ)

FQDN

Fully Qualified Domain Name(完全修飾ドメイン名)

KPML

Key Pad Markup Language

MLPP

Multilevel Precedence and Preemption

MTP

Media Termination Point(メディア ターミネーション ポイント)

MWI

Message Waiting Indication(メッセージ待機インジケータ)

OOB

Out Of Band(アウト オブ バンド)

OOD

Out of Dialog(アウト オブ ダイアログ)

PRACK

Provisional Response ACKnowledgment

RDNIS

Redirected Dialed Number Information Service

RPID

Remote Party ID

RTT

Retransmission Time(再送信時間)

SDP

Session Description Protocol(セッション記述プロトコル)

SIP

Session Initiated Protocol(セッション開始プロトコル)

SIS

SIP line Interface Specification(SIP 回線インターフェイス仕様)

TLS

Transport Layer Security(トランスポート層セキュリティ)

UAC

User Agent Client(ユーザ エージェント クライアント)

UAS

User Agent Server(ユーザ エージェント サーバ)

URI

Uniform Resource Identifier(ユニフォーム リソース識別子)

URN

Uniform Resource Name(ユニフォーム リソース名)

VM

Voice Mail(ボイス メール)

新機能および変更情報

この項では、Cisco Unified Communications Manager Release 9.1(1) の SIP 回線メッセージング標準に関する新機能および変更情報、および以前のリリースでサポートされている機能について説明します。次のような構成になっています。

「Cisco Unified Communications Manager Release 9.1(1)」

「以前のリリースでサポートされている機能」

Cisco Unified Communications Manager Release 9.1(1)

リリース 9.1(1) では、SIP 回線インターフェイスの拡張機能に対する新機能や変更はありません。

Cisco Unified Communications Manager Release 9.0(1)

リリース 9.0(1) では、次の新しい SIP 回線インターフェイス機能拡張が導入されました。

「サポートされるコンテンツ タイプ」 の表に application/conference-info+xml が追加されました。

TLS は、サードパーティの AS-SIP エンドポイントをサポートします。

「リソース プライオリティを使用した Multilevel Precedence and Preemption」

「SIP コールの発信 ID および着信 CLI」

「URI ダイヤル」

「電話番号の非通知コールの拒否」

Cisco Unified Communications Manager Release 8.6(1)

Release 8.6(1) では、次の新しい SIP 回線インターフェイス機能拡張が導入されました。

「BFCP」


) ここでは、Unified CM 8.6(1) に追加された新規機能およびコール フローについて説明します。次の URL にある『SIP Line Messaging Guide (Standard) for Release 8.0(1)』の既存の SIP 標準コール フローの全リストを確認することを推奨します。http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_programming_reference_guides_list.html


標準インターフェイス準拠の要約

ここでは、Cisco Unified CM SIP 回線インターフェイス規格準拠について詳しく説明します。「標準機能のシナリオ」では、SIP 回線側実装に関するシステムの動作を機能実装を中心に説明します。詳細なコール フローについては、を参照してください。

SIP 回線インターフェイスの準拠については、次の表を参照してください。

表 1-1 は、該当する規格およびドラフトを示します。

表 1-2 および 表 1-3 は、SIP メッセージの SIP 回線側の準拠を示します。

表 1-4 は、標準 SIP ヘッダーの SIP 回線側の準拠を示します。

 

表 1-1 該当する規格およびドラフト - 標準インターフェイス

ID
注記

RFC 3261

SIP

RFC 3262

PRACK

RFC 3264

SDP オファー/応答

RFC 3311

UPDATE

RFC 3515

REFER

RFC 3842

MWI パッケージ

RFC 3891

Replaces ヘッダー

RFC 3892

Referred-by メカニズム

draft-levy-sip-diversion-08.txt

Diversion ヘッダー

draft-ietf-sip-privacy-04.txt

Remote-Party-Id ヘッダー

 

表 1-2 SIP 要求への準拠

SIP メッセージ
Cisco Unified CM でのサポートの有無
コメント

INVITE

あり

アウトバウンド コールの re-INVITE もサポートされます。

ACK

あり

--

OPTIONS

あり

Cisco Unified CM は受信すると応答します。Cisco Unified CM は OPTIONS 要求を送信しません。

INFO

あり

INFO メソッドはビデオ サポートに使用されます。

BYE

あり

--

CANCEL

あり

--

SUBSCRIBE

なし

「サポートされるイベント パッケージ」の項を参照してください。

NOTIFY

あり

「サポートされるイベント パッケージ」の項を参照してください。

REFER

あり

インバウンド REFER は転送に適用されるので、サポートされます。Cisco Unified CM 回線側では、転送にアウトバウンド REFER を生成しません。アウトバウンド コールの re-INVITE をサポートします。

REGISTER

あり

--

PRACK

あり

PRACK のサポートを設定できます。

UPDATE

あり

Cisco Unified CM は UPDATE の受信および生成をサポートします。

PUBLISH

なし

高度なコール フローの項を参照してください。

 

表 1-3 SIP 応答への準拠

SIP メッセージ
Cisco Unified CM でのサポートの有無
コメント

1xx 応答

あり

--

100 試行中

あり

--

180 呼び出し中

あり

アーリー メディア(early media)がサポートされます。

181 コール転送

なし

Cisco Unified CM はこのメッセージを無視します。

182 キューイング済み

なし

Cisco Unified CM はこのメッセージを無視します。

183 セッション中

あり

アーリー メディア(early media)がサポートされます。

2xx 応答

あり

--

200 OK

あり

--

202 OK

あり

メッセージは REFER に適用されます。

3xx 応答

あり

--

300 ~ 302、305、380、385

あり

このメッセージは生成されません。受信すると、Contact ヘッダーの新しいアドレスに連絡されます。

4xx 応答

あり

受信すると、正常なコールの切断が開始されます。

401

あり

Cisco Unified CM SIP は、認証および許可がイネーブルの場合、メッセージ 401(未認証)を送信します。Cisco Unified CM SIP はインバウンド 401 チャレンジにも応答します。

403

あり

Cisco Unified CM SIP は、SIP メソッドがアクセス コントロール リストにない場合、メッセージ 403(禁止)を送信します。特定の状態でメソッドがサポートされない場合に、403 が返されることもあります。

407

あり

Cisco Unified CM SIP は、インバウンド 407(プロキシ認証が必要)チャレンジに応答します。

412

あり

Cisco Unified CM SIP は、PUBLISH 更新または PUBLISH 削除要求を不明なエンティティのタグとともに受信した場合、412 を送信します。

423

あり

Cisco Unified CM SIP は、受け入れ可能な最小値より短い expires 時間で期限切れのヘッダーを受信した場合、423 を送信します。

5xx 応答

あり

このメッセージを受信すると、追加アドレスがある場合は新しい要求が送信されます。送信されない場合は、正常な切断が開始されます。

6xx 応答

あり

このメッセージは生成されません。このメッセージを受信すると、正常な切断が開始されます。

 

表 1-4 標準 SIP ヘッダー フィールド

SIP ヘッダー
Cisco Unified CM でのサポートの有無
コメント

Accept

あり

--

Accept-Encoding

なし

--

Accept-Language

なし

--

Alert-Info

あり

Cisco Unified CM は Alert-Info を送信して内線と外線を示します。

Allow

あり

--

Authentication-Info

なし

--

Authorization

あり

--

Call-ID

あり

--

Call-Info

あり

--

Contact

あり

--

Content-Disposition

なし

このヘッダーを受信すると、Cisco Unified CM はこのヘッダーを無視します。Cisco Unified CM はこのヘッダーを生成しません。

Content-Encoding

なし

--

Content Language

なし

--

Content-Length

あり

--

Content-Type

あり

「サポートされるコンテンツ タイプ」を参照してください。

CSeq

あり

--

Date

あり

--

Error-Info

なし

--

Expires

あり

--

From

あり

--

In-Reply-To

なし

--

Max-Forwards

あり

Cisco Unified CM は、発信 INVITE に 70 を設定し、増加/減少させません。

MIME-Version

あり

このヘッダーは REFER と一緒に使用されます。

Min-Expires

あり

--

Organization

なし

--

Priority

なし

--

Proxy-Authenticate

あり

Cisco Unified CM SIP は 407 応答でこのヘッダーの受信をサポートします。

Proxy-Authorization

あり

Cisco Unified CM SIP は 407 応答を受信した後、このヘッダーを使用した新しい要求送信をサポートします。

Proxy-Require

なし

--

Record-Route

あり

--

Reply-To

なし

--

Require

あり

--

Retry-After

あり

送信しますが、受信を無視します。

Route

あり

--

Server

あり

--

Subject

なし

--

Supported

あり

--

Timestamp

あり

--

To

あり

--

Unsupported

あり

--

User-Agent

あり

--

Via

あり

--

Warning

あり

--

WWW-Authenticate

あり

--

固有および非標準 SIP ヘッダーおよび識別サービス

表 1-5 に、標準 SIP 回線側インターフェイスの固有および非標準ヘッダー フィールドを示します。詳細については、「Remote-Party-ID ヘッダー」を参照してください。

 

表 1-5 固有または非標準 SIP ヘッダー フィールド

SIP ヘッダー
Cisco Unified CM でのサポートの有無
コメント

Diversion

あり

RDNIS 情報に使用されます。存在する場合、常に元の着信者情報が表示されます。このヘッダーの受信側は、元の着信者情報(存在する場合)であることを常に想定しています。VM へのチェーン接続転送の場合は、メッセージは元の着信者に残されます。

Remote-Party-ID

あり

接続者名および ID を含む ID サービスに使用されます。この非標準、非固有ヘッダーは、標準機能シナリオに含まれます。

Remote-Party-ID ヘッダー

ここでは、回線と名前の識別サービスを含む、SIP 回線用の Cisco Unified CM の SIP 識別サービスについて説明します。回線識別サービスには、発呼回線および接続回線ディレクトリ番号が含まれます。名前識別サービスには、発呼回線名、呼び出し回線名、および接続回線名が含まれます。

Remote-Party-ID ヘッダーは、draft-ietf-sip-privacy-03.txt で指定した ID サービス ヘッダーを提供します。

Cisco Unified CM は、呼び出し回線名や接続回線名を示すためのエンドポイント用の柔軟な設定オプションを提供します。この項では、これらの設定オプションについては説明しません。Cisco Unified CM が SIP エンドポイントとの間でこれらの ID サービスを送受信する方法についてのみ説明します。Remote-Party-ID ヘッダーには、表示名およびアドレス指定の後に省略可能なパラメータが含まれます。表示名には名前が、アドレスのユーザ部分には番号が表示されます。

Cisco Unified CM 8.0(1) では、Cisco Unified CM によりローカル化形式およびグローバル化形式の発呼番号を受信側エンドポイントにルーティングできます。これは 発呼側の正規化 (CPN)と呼ばれます。たとえば、北米にある企業が外部から市内通話を受信する場合、エンドポイント ユーザに対して、見慣れた 7 桁の発呼番号(たとえば、232-5757)を表示することが推奨されます。社外の市内番号にコールを返すには、エンドポイント ユーザは通常、まずアクセス コード(たとえば、9)をダイヤルして、これから外部ディレクトリ番号(92325757)をダイヤルするということを示します。この形式の発呼番号は、 グローバル または グローバル化 番号と呼ばれます。発呼番号のローカル化形式は、アドレスのユーザ部分として SIP Remote-Party-ID ヘッダーに表示されます。発呼番号のグローバル化形式は、任意の SIP URI パラメータとして表示されます。


) Remote-Party-ID ヘッダーは非標準ですが、多くのベンダーが実装しており、ほとんどの Cisco SIP 製品に含まれています。したがって、実際には独自のものですが、このマニュアルの標準の項に記載されています。このヘッダーの使用方法は説明されていません。受信者は、理解できない場合、無視してください。


表 1-6 に、識別パラメータのサポート レベルを示します。後続の項では、次のトピックについて取り上げます。

「発呼回線および名前の ID 表示」

「発呼回線および名前の ID 表示制限」

「接続回線と名前の ID 表示」

「接続回線と名前の ID 表示制限」

 

表 1-6 識別パラメータのサポート

パラメータ
注記

x-cisco-callback-number

various

Cisco Unified CM が受信した場合、無視されます。

グローバル化形式の発呼(コールバック)番号に設定します。番号のグローバル化形式とは、エンドポイントがダイヤルしたときに、ユーザによる編集なしで目的の宛先に正常にルーティングされる形式です。

パラメータ
注記

party

calling

called

Cisco Unified CM が受信した場合、無視されます。

Cisco Unified CM からの発信 INVITE または UPDATE の着信側に設定します。Cisco Unified CM からの発信応答の発信側に設定します。

id-type

subscriber

user

term

Cisco Unified CM が受信した場合、無視されます。

発信要求および応答のサブスクライバに設定します。

privacy

full

name

uri

off

Cisco Unified CM が受信した場合、サポートされます。

Cisco Unified CM は、このパラメータに対する INVITE または UPDATE いずれかの要求および応答のすべての値の送信もサポートします。

screen

no

yes

Cisco Unified CM が受信した場合、無視されます。

Cisco Unified CM は Remote-Party-ID ヘッダーを生成するときは常に yes を送信します。

発呼回線および名前の ID 表示

エンドポイントからの最初の INVITE メッセージの From ヘッダーおよび Remote-Party-ID ヘッダー(任意)に、発呼回線(番号)および名前が含まれます。たとえば、アウトバウンド コールに対するディレクトリ番号が 69005、発信者 ID が「sip line」のエンドポイントからの着信 INVITE には、次の Remote-Party-ID ヘッダーと From ヘッダーが含まれます。

Remote-Party-ID: "sip line" <sip:69005@10.10.10.2>;party=calling;id-type=subscriber;privacy=off;screen=yes
From: "sip line" <sip:69005@10.10.10.2>;tag=1234

発呼回線および名前の ID 表示制限

プライバシー パラメータを使用して、SIP 回線(番号)および名前が制限されます。どちらも制限しない場合、プライバシーは off に設定します。ここでは、プライバシーの他の値(name、uri、および full)および From ヘッダーと Remote-Party-ID ヘッダーのさまざまな値への影響について説明します。

name

名前の制限のみ:名前が制限されている場合、「From」ヘッダーの表示フィールド(発呼者名)は「Anonymous」に設定されます。「Remote-Party-ID」ヘッダーの表示フィールドには実際の名前が残りますが、プライバシー フィールドは「name」に設定されます。次に例を示します。

Remote-Party-ID: "Anonymous" <sip:69005@10.10.10.2>;party=calling;id-type=subscriber;privacy=name;screen=yes
From: "Anonymous" <sip:69005@10.10.10.2>;tag=1234

uri

番号の制限のみ:番号が制限されている場合、「From」ヘッダーの発呼回線は「Anonymous」に設定されますが、「Remote-Party-ID」ヘッダーに含まれます(privacy=uri)。次に例を示します。

Remote-Party-ID: "sip line" <sip:69005@10.10.10.2>;party=calling;id-type=subscriber;privacy=uri;screen=yes
From: "sip line" <sip:Anonymous@10.10.10.2>;tag=1234

full

名前と番号の制限:名前と番号の両方が制限されている場合、同じ原則が適用されます(privacy=full)。次に例を示します。

Remote-Party-ID: "sip line" <sip:69005@10.10.10.2>;party=calling;id-type=subscriber;privacy=full;screen=yes
From: "Anonymous" <sip:Anonymous@10.10.10.2>;tag=1234

接続回線と名前の ID 表示

接続回線/名前の識別は、着信側または接続先の番号と名前を提供する補足サービスです。

Cisco Unified CM は 18x、200、re-INVITE、および UPDATE メッセージの Remote-Party-ID ヘッダーを使用して接続者の名前および番号情報を伝送します。この例では、エンドポイントは 9728135001 にコールを発信しました。Cisco Unified CM は、この番号が「Bob Jones」の番号であると判断し、180 または 183 メッセージで発信元に返信しました。

Remote-Party-ID: "Bob Jones" <sip: 9728135001@10.10.10.2>;party=called;screen=yes;privacy=off

接続回線と名前の ID 表示制限

発信 ID サービスと同様に、RPID は接続された番号や名前を個別に制限できます。

name

名前の制限のみ:名前が制限されている場合、接続された名前がそのまま含まれます(privacy=name)。次に例を示します。

Remote-Party-ID: "Bob Jones"<9728135001@localhost; user=phone>; party=called;screen=no;privacy=name

uri

番号の制限のみ:番号が制限されている場合でも、接続された番号は含まれます(privacy=uri)。次に例を示します。

Remote-Party-ID: "Bob Jones"<9728135001@localhost; user=phone>; party=called;screen=no;privacy=uri

full

名前と番号の制限:名前と番号の両方が制限されている場合、情報パラメータが両方とも含まれます(privacy=full)。次に例を示します。

Remote-Party-ID: "Bob Jones"<9728135001@localhost; user=phone>; party=called;screen=no;privacy=full

CPN 番号表示

発呼側の正規化は、発呼番号をローカル化(正規化)形式およびグローバル化形式で提供する補足サービスです。両方の形式の発呼番号が、Remote-Party-ID を持つ SIP 要求または応答メッセージに表示されることがあります。ローカル化形式の発呼番号は、SIP URI のユーザ部分として表示されます。グローバル化形式は、任意の SIP URI パラメータとして表示されます。次に例を示します。

Remote-Party-ID: "sip line" <sip:2325757@10.10.10.2;x-cisco-callback-number=99192325757>;party=calling;id-type=subscriber;privacy=off;screen=yes

x-cisco-callback-number パラメータは省略可能な URI パラメータであるので、このパラメータをサポートしないエンドポイントでは無視してください。

サポートされるメディア タイプ

SIP 回線インターフェイスでサポートされるメディア タイプについては、次の表を参照してください。

サポートされる音声メディア タイプについては、 表 1-7 を参照してください。

サポートされるビデオ メディア タイプについては、 表 1-8 を参照してください。

サポートされるアプリケーション メディア タイプについては、 表 1-9 を参照してください。

サポートされる T38fax メディア タイプについては、 表 1-10 を参照してください。

 

表 1-7 サポートされる音声メディア タイプ

タイプ
符号化名
ペイロード タイプ
コメント

G.711 μ-law

PCMU

0

--

GSM Full-rate

GSM

3

--

G.723.1

G723

4

--

G.711 A-law

PCMA

8

--

G.722

G722

9

--

G.728

G728

15

--

G.729

G729

18

Annex A と B のすべての組み合わせをサポートします。

RFC2833 DTMF

Telephony-event

動的に割り当て

値の範囲は 96 ~ 127 です。

G.Clear

CLEARMODE

動的に割り当て

すべてのシスコ製品では通常 125 です。Cisco Unified CM は X-CCD、CCD、G.nX64 などの他の符号化名もサポートしています。

 

表 1-8 サポートされるビデオ メディア タイプ

タイプ
符号化名
ペイロード タイプ

H.261

H261

31

H.263

H263

34

H.263+

H263-1998

値の範囲は 96 ~ 127 です。

H.263++

H263-2000

値の範囲は 96 ~ 127 です。

H.264

H264

値の範囲は 96 ~ 127 です。

 

表 1-9 サポートされるアプリケーション メディア タイプ

タイプ
符号化名
ペイロード タイプ

H.224 FECC

H224

値の範囲は 96 ~ 127 です。

 

表 1-10 サポートされる T38fax ペイロード タイプ

タイプ
符号化名
ペイロード タイプ

T38fax

なし

なし

サポートされるイベント パッケージ

表 1-11 に、SIP 回線インターフェイスでサポートされるイベント パッケージを示します。

 

表 1-11 サポートされるイベント パッケージ

イベント パッケージ
サポートの有無
サブスクリプション
または未承諾
コメント

message-summary

あり

未承諾

メッセージ待機インジケータ通知に使用されます。

kpml

あり

サブスクリプション

ディジット収集および DTMF リレーに使用されます。

dialog

あり

サブスクリプション

フック ステータス(オフフックおよびオンフックのみ)に使用されます。

共有回線のリモート状態通知に使用されます。

presence

あり

サブスクリプション

BLF スピード ダイヤルに使用されます。

DND ステータスに使用されます。

不在着信、発信、および受信コールとその他のディレクトリ サービスに使用されます。

BLF アラート インジケータに使用されます。

refer

あり

サブスクリプション

コール転送中の sipfrag 応答を伝送するために使用されます。

remotecc 応答を伝送するために使用されます。

service-control

あり

未承諾

エンドポイントにサービス制御通知を送信する場合に使用します。

サポートされるコンテンツ タイプ

表 1-12 に、SIP 回線インターフェイスでサポートされているコンテンツ タイプを示します。

 

表 1-12 サポートされるコンテンツ タイプ

コンテンツ タイプ
コメント

text/plain

message-summary パッケージを参照してください。

message/sipfrag;version=2.0

転送に使用される refer パッケージを参照してください。

application/pidf+xml

presence パッケージを参照してください。

application/dialog-info+xml

dialog パッケージを参照してください。

application/kpml-request+xml

kpml パッケージを参照してください。

application/kpml-response+xml

kpml パッケージを参照してください。

application/x-cisco-remotecc-request+xml

refer パッケージと remotecc を参照してください。

application/x-cisco-remotecc-response+xml

refer パッケージと remotecc を参照してください。

application/x-cisco-remotecc-cm+xml

refer パッケージと remotecc を参照してください。

application/x-cisco-servicecontrol

service-control パッケージを参照してください。

application/x-cisco-alarm+xml

電話機アラーム システムを参照してください。

multipart/mixed

refer パッケージと remotecc を参照してください。

application/conference-info+xml

Conference Factory 方式の会議用にサードパーティの AS-SIP エンドポイントでだけ使用されます。

SIP メッセージ フィールド

Cisco Unified CM の SIP 回線は、要求メッセージと応答メッセージをサポートします。要求メッセージには、INVITE、ACK、OPTIONS、BYE、CANCEL、PRACK および UPDATE メソッドが含まれます。応答メッセージはさまざまなステータス コード(1xx、2xx、3xx、4xx、5xx、6xx)のステータス行で構成されます。SIP 回線は、SIP の標準インターフェイスのすべての必須フィールドをサポートします。

要求メッセージ

次の項では、一部のタイプの SIP 要求を個々に要約します。ここでは、ダイアログ開始要求について説明します。ミッドコール トランザクションがこれらの要求から使用する値を推定できます。詳細については、のコール フローを参照してください。

ここで詳述する SIP 要求メッセージは次のとおりです。

「INVITE」

「ACK」

INVITE

表 1-13 に、NVITE SIP 要求メッセージのフィールドを示します。

 

表 1-13 INVITE メッセージ フィールド

メッセージ行
変数
着信
(Cisco Unified CM へ)
発信
(Cisco Unified CM から)
INVITE
sip:userpart@destIP:destPort SIP/2.0

userpart

着信側番号

発呼側番号

destIP

Cisco Unified CM の IP アドレスまたは FQDN

エンドポイントの IP アドレス

destPort

Cisco Unified CM の SIP ポート

エンドポイントの SIP ポート

Via:
SIP/2.0/UPD ip:port;Branch=number

ip

エンドポイントの IP アドレス

Cisco Unified CM の IP アドレス

port

エンドポイントの SIP ポート

Cisco Unified CM の SIP ポート

number

エンドポイントのブランチ番号

Cisco Unified CM のブランチ番号

From:
"display" <sip:userpart@ip>;tag=from-tag

display1

発呼側名

発呼側名

userpart

発呼側番号

発呼側番号

ip

Cisco Unified CM の IP アドレスまたは FQDN

Cisco Unified CM の IP アドレス

from-tag

エンドポイントのローカル タグ

Cisco Unified CM のローカル タグ

To: <sip:userpart@destIP>

userpart

着信側番号

着信側番号

destIP

Cisco Unified CM の IP アドレスまたは FQDN

エンドポイントの IP アドレス

Remote-Party-ID:
"display" <sip:userpart@ip>;params

display

発呼側名

発呼側名

userpart

発呼側番号

発呼側番号

ip

エンドポイントの IP アドレス

Cisco Unified CM の IP アドレス

params

エンドポイントごとに異なる

Cisco Unified CM の設定ごとに異なる

Call-ID: string

string

エンドポイントで生成されたストリング

Cisco Unified CM で生成されたストリング

Contact:<sip:userpart@ip:port >

userpart

発呼側番号

発呼側番号

ip

エンドポイントの IP アドレス

Cisco Unified CM の IP アドレス

port

エンドポイントのポート

Cisco Unified CM のポート

Cseq: number method

number

シーケンス番号

シーケンス番号

method

SIP メソッド

SIP メソッド

Max-Forwards: number

number

最大転送数

最大転送数

SDP [sdp]

sdp

エンドポイントの SDP

Cisco Unified CM は通常、ディレイド メディア(delayed media)を使用します。

1.SIP ヘッダーの表示フィールドは、ASCII または Unicode として符号化できます。

ACK

ACK メッセージ値は、INVITE/18x/200 メッセージ シーケンスによって確立された値を表します。


) ACK には、SDP ヘッダーと Remote-Party-ID ヘッダーが含まれている場合があります。


応答メッセージ


) 次の表では、上記の INVITE メッセージの表と比べて、発信および着信の列の順序が入れ替わっています。このように、カラムはこれらの表のダイアログに従って配列されます。つまり、Cisco Unified CM への着信 INVITE は発信 180 メッセージになります。


ここで詳述する SIP 応答メッセージは次のとおりです。

「180 呼び出し中」

「183 セッション中」

「2xx」

180 呼び出し中

表 1-14 に、180 呼び出し中 SIP 応答メッセージのフィールドを示します。

 

表 1-14 180 呼び出し中メッセージ フィールド

メッセージ行
変数
発信
(Cisco Unified CM から)
着信
(Cisco Unified CM へ)

SIP/2.0 180 呼び出し中

Via: SIP/2.0/UPD ip:port;Branch=number

ip

エンドポイントの IP アドレス

Cisco Unified CM の IP アドレス

port

エンドポイントの SIP ポート

Cisco Unified CM の SIP ポート

number

エンドポイントのブランチ番号

Cisco Unified CM のブランチ番号

From:
"display"<sip:userpart@ip>;tag=from-tag

display

発呼側名

発呼側名

userpart

発呼側番号

発呼側番号

ip

Cisco Unified CM の IP アドレスまたは FQDN

Cisco Unified CM の IP アドレス

from-tag

エンドポイントのローカル タグ

Cisco Unified CM のローカル タグ

To: <sip:userpart@destIP>;tag=to-tag

userpart

着信側番号

着信側番号

destIP

Cisco Unified CM の IP アドレスまたは FQDN

エンドポイントの IP アドレス

to-tag

Cisco Unified CM のローカル タグ

エンドポイントのローカル タグ

Remote-Party-ID:
"display" <sip:userpart@ip>;params

display

着信側の名前

着信側の名前

userpart

着信側番号

着信側番号

ip

Cisco Unified CM の IP アドレス

エンドポイントの IP アドレス

params

Cisco Unified CM の処理ごとに異なる

エンドポイントの処理ごとに異なる

Call-ID: string

string

初期 INVITE からエンドポイントで生成されたストリング

初期 INVITE から Cisco Unified CM で生成されたストリング

Contact:<sip:userpart@ip:port >

userpart

着信側番号

着信側番号

ip

Cisco Unified CM の IP アドレス

エンドポイントの IP アドレス

port

Cisco Unified CM のポート

エンドポイントのポート

Cseq: number INVITE

number

初期 INVITE からのシーケンス番号

初期 INVITE からのシーケンス番号

183 セッション中

183 メッセージはアーリー メディア(early media)を確立します。Cisco Unified CM は、エンドポイントに送信される 183 メッセージに SDP を含めます。Remote-Party-ID ヘッダーも変更される可能性があります。それ以外の場合は、183 は 180 と同じ値を伝送します。

2xx


) ほとんどの 2XX 値は 180 メッセージと一致し、200 は SDP を伝送します。また、Remote-Party-ID は 18x メッセージが送信されると、変更される可能性があります。


表 1-15 に、2xx SIP 応答メッセージのフィールドを示します。

 

表 1-15 2XX メッセージ フィールド

メッセージ行
変数
発信
(Cisco Unified CM から)
着信
(Cisco Unified CM へ)

SIP/2.0 200 OK

Via: SIP/2.0/UPD ip:port;Branch=number

ip

エンドポイントの IP アドレス

Cisco Unified CM の IP アドレス

port

エンドポイントの SIP ポート

Cisco Unified CM の SIP ポート

number

エンドポイントのブランチ番号

Cisco Unified CM のブランチ番号

From:
"display"<sip:userpart@ip>;tag=from-tag

display

発呼側名

発呼側名

userpart

発呼側番号

発呼側番号

ip

Cisco Unified CM の IP アドレスまたは FQDN

Cisco Unified CM の IP アドレス

from-tag

エンドポイントのローカル タグ

Cisco Unified CM のローカル タグ

To: <sip:userpart@destIP>;tag=to-tag

userpart

着信側番号

着信側番号

destIP

Cisco Unified CM の IP アドレスまたは FQDN

エンドポイントの IP アドレス

to-tag

Cisco Unified CM のローカル タグ

エンドポイントのローカル タグ

Remote-Party-ID:
“display” <sip:userpart@ip>;params

display

着信側の名前

着信側の名前

userpart

着信側番号

着信側番号

ip

Cisco Unified CM の IP アドレス

エンドポイントの IP アドレス

params

Cisco Unified CM の処理ごとに異なる

エンドポイントの処理ごとに異なる

Call-ID: string

string

初期 INVITE からエンドポイントで生成されたストリング

初期 INVITE から Cisco Unified CM で生成されたストリング

Contact:<sip:userpart@ip:port >

userpart

着信側番号

着信側番号

ip

Cisco Unified CM の IP アドレス

エンドポイントの IP アドレス

port

Cisco Unified CM のポート

エンドポイントのポート

Cseq: number INVITE

number

初期 INVITE からのシーケンス番号

初期 INVITE からのシーケンス番号

SDP [sdp]

sdp

Cisco Unified CM の SDP

エンドポイントの SDP

メッセージ タイマー

次のタイマーは、Cisco Unified Communications Manager Administrationで設定可能なサービス パラメータです。

表 1-6 に、Cisco Unified CM によって維持される SIP タイマーの設定データを示します。

 

表 1-16 メッセージ タイマー

メッセージ
値(デフォルト/範囲)
定義

trying

500 ミリ秒/100 ~ 1000 ミリ秒

INVITE 要求に対する 100 応答を待機する時間

connect

500 ミリ秒/100 ~ 1000 ミリ秒

ACK 要求に対する 200 応答を待機する時間

disconnect

500 ミリ秒/100 ~ 1000 ミリ秒

BYE 要求に対する 200 応答を待機する時間

expires

3 分/1 ~ 5 分

INVITE が有効である時間を制限します。

rel1xx

500 ミリ秒/100 ~ 1000 ミリ秒

信頼性のある 1xx 応答を再送信するまで Cisco Unified CM が待機する時間

prack

500 ミリ秒/100 ~ 1000 ミリ秒

PRACK 要求を再送信するまで Cisco Unified CM が待機する時間

notify

500 ミリ秒/100 ~ 1000 ミリ秒

Notify メッセージを再送信するまで Cisco Unified CM が待機する時間

Publish

2147483647

Cisco Unified CM は、エンドポイントから受信した、パブリッシュされたイベントの状態データを期限切れにするためのタイマーを管理しません。Cisco Unified CM では、イベントの状態データを Cisco Unified CM にパブリッシュする場合、エンドポイントが 2147483647 の expires 時間を指定する必要があります。

メッセージの再試行回数

次の再試行回数はすべて、Cisco Unified Communications Manager Administrationで設定可能なサービス パラメータです。TCP 転送タイプの場合、タイマーは通常どおりポップアップされます。ただし、タイムアウトの場合、スタックは再送信しません。代わりに TCP 自体に依存して再試行します。

表 1-17 に、Cisco Unified CM によって維持される、SIP 再試行の設定データを示します。

 

表 1-17 メッセージの再試行回数

カウンタ
デフォルト値
推奨範囲
定義

Invite 再試行回数

5

1 ~ 10

INVITE の再試行回数

Response 再試行回数

6

1 ~ 10

RESPONSE の再試行回数

Bye 再試行回数

10

1 ~ 10

BYE の再試行回数

Cancel 再試行回数

10

1 ~ 10

Cancel の再試行回数

PRACK 再試行回数

6

1 ~ 10

PRACK の再試行回数

Rel1xx 再試行カウント

10

1 ~ 10

信頼性の高い 1xx 応答の再試行回数

Notify 再試行回数

6

1 ~ 10

NOTIFY の再試行回数

標準機能のシナリオ

ここでは、Cisco Unified CM の回線側インターフェイス上の標準的な SIP 機能の全体的なフローおよび処理に関して説明します。これには次の機能が含まれますが、それらに限定されません。

「登録」

「基本的なコール」

「単純な保留と復帰」

「転送」

「3 者間コール」

「コール転送」

「メッセージ待機インジケータ」

「エンドポイントが返す 302 リダイレクト」

「エンドポイントが返す 486 通話中」

「特定のコール セットアップ障害のアナウンス」

「INFO パッケージ」

「G.Clear コール」

「BFCP」

シナリオの説明と関連するコール フローについては、を参照してください。

登録

Cisco Unified CM は、任意の対応 SIP 電話機からの標準の RFC3261 登録をサポートします。Cisco Unified CM は B2BUA であるので、登録するデバイスを一意に識別して、データベースの設定エントリにそのデバイスを照合する必要があります。さらに、Cisco Unified CM は、メッセージを承認し、フィルタリングし、ルーティングするために、受信する他のすべての SIP 要求(INVITE、REFER、SUBSCRIBE など)の発信元デバイス(および回線)を識別できる必要があります。標準 SIP には発信元デバイスを識別するための一貫性のある明確なメカニズムがないので、標準の登録では Cisco Unified CM は送信側デバイスを識別するために HTTP ダイジェスト ユーザ ID を必要とします。

送信側デバイスと回線がわかると、Cisco Unified CM はさまざまなルーティング、許可、フィルタリングのロジックを着信登録、サブスクリプション、および招待に適用できます。

標準の登録用に TCP および UDP 転送がサポートされますが、TLS はサポートされません。

RFC3261 対応電話機のソース デバイス ID

Cisco Unified CM は、認証、ルーティング、およびフィルタリングを適用するために REGISTER メッセージの送信デバイスを一意に認識する必要があります。連絡先 IP アドレスは、DHCP が使用されている場合動的に変更できるので、適していません。代わりに、Cisco Unified CM は HTTP ダイジェスト ユーザ ID を使用します。Cisco Unified CM で設定された各デバイスには、一意のダイジェスト ユーザ ID が必要です。デバイスが REGISTER を送信すると、Cisco Unified CM はすぐに 401 チャレンジで応答し、Authentication ヘッダーを取得します。Authentication ヘッダーのユーザ ID を使用して、データベースの設定エントリが検出されます。サードパーティ製の電話機に正しいユーザ ID が設定されていない場合、またはユーザ ID が Cisco Unified CM データベース内のデバイスに関連付けられていない場合、Cisco Unified CM は 404 Not Found で応答します。

MultiLine 登録

各回線に固有のディレクトリ番号がある場合、複数の回線を Cisco Unified CM に登録できます。ディレクトリ番号は REGISTER の To ヘッダーと From ヘッダーに表示され、数字である必要があります。

REGISTER Refresh(キープアライブ)

Cisco Unified CM は、REGISTER Refresh をキープアライブ メッセージとして使用して、電話機がまだ動作していて、接続されていることを確認します。最初に電話機が Cisco Unified CM に登録されると、200OK 応答にキープアライブ インターバルが設定された Expires ヘッダーが含まれます。電話機は、この間隔内で同じコール ID、連絡先 IP アドレス、および連絡先ポート番号を使用して REGISTER Refresh を送信する必要があります。Cisco Unified CM は、設定された間隔(デフォルトは 120 秒)内にキープアライブ メッセージを受信しなかった場合、電話機を内部的に登録解除します。したがって、その電話機からコールを発信したり、その電話機でコールを終端したりできません。

デバイスのバインディング

デバイスがダイジェスト ユーザ ID で識別されると、そのデバイス ID と転送アドレス間の Cisco Unified CM 内でバインディングが作成されます。このバインディングが作成されるのは、Cisco Unified CM が電話機からのすべての後続の要求(INVITE、REFER、SUBSCRIBE など)の送信側デバイスを識別する必要があり、これらの要求にはデバイス ID が含まれていないためです。ただし、これらの要求には送信元の転送情報が含まれているので、バインディングはデバイス ID と転送情報の間に作成されます。使用される転送情報は UDP および TCP で異なります。

UDP の場合、デバイス ID と Contact ヘッダーの IP アドレスおよびポート番号の間にバインディングが作成されます。最初の REGISTER メッセージが送信されると、後続の要求はすべて Contact ヘッダー内の同じ IP アドレスとポート番号を使用する必要があります。変更された場合、Cisco Unified CM がメッセージをルーティングできないので、5xx エラー応答が返されます。

TCP の場合、連絡先のバインディングと TCP 接続のバインディングの組み合わせが使用されます。デバイスが TCP 接続を介して登録すると、Cisco Unified CM は TCP 接続が一時的か(新しい接続が各トランザクションに使用されます)永続的かを判断できません。したがって、Cisco Unified CM は最初に連絡先 IP アドレスとポート番号にデバイス ID をバインドします。複数のトランザクションが同じ TCP 接続上で送信されると、TCP 接続は確認されたと見なされ、永続的とマーキングされます。この時点で、バインディングがデバイス ID と TCP 接続の間に作成されます。

同じ AOR の複数のバインディング

Cisco Unified CM は、レコードの 1 つのアドレスに対して複数の登録のバインディングがある場合、RFC3261 から少し逸脱します。Cisco Unified CM アーキテクチャにおいて、321-1000 で共有回線を保持するように 3 台のデバイスが設定されている場合、それぞれ 3211000@ip:port 形式でその回線の連絡先を登録します。各デバイスには一意の IP アドレスが存在するので、その回線に固有の連絡先が保持されます。RFC3261 には、登録後に、既知のすべての連絡先のバインディングを 200OK 応答の登録エンティティに戻すことが記載されています。Cisco Unified CM は、各登録時に登録するデバイスの連絡先のバインディングだけを戻します。登録時に特定の AOR に対して認識している他のバインディングを列挙しません。登録するエンドポイントは、AOR に関連付けられているすべてのバインディングの詳細なリストとして 200OK 応答で返されるバインディング リストに依存しないようにする必要があります。さらに、エンドポイントでは Cisco Unified CM から別のデバイスのバインディングを変更できません。独自のバインディングだけを更新または削除できます。

Contact: *

Cisco Unified CM は、Contact: * 形式をサポートしない RFC3261 から外れています。この形式は、現在 AOR に関連付けられているすべての連絡先を登録解除するためによく使用されます。ただし、Cisco Unified CM では、各 REGISTER メッセージ内の Contact ヘッダーにデバイスを識別する SIP URI を含める必要があり、登録解除メッセージ(Expires: 0 の REGISTER)に元の REGISTER メッセージとして同じ Contact ヘッダーを含める必要があります。

この制約事項は、Cisco Unified CM は各着信 SIP メッセージの送信元デバイスを識別する必要があり、この目的で Contact ヘッダーを使用していることによるものです。Cisco Unified CM では、To ヘッダー内の AOR を使用できません。これは、共有回線機能により複数の異なる送信元デバイスが同じ AOR を持つことができ、AOR が特定のデバイスに対して固有ではないためです。

基本的なコール

Cisco Unified CM は、RFC 3261、3262、および 3264 で説明されている手順に従い、基本的な SIP コールを確立し、クリアします。多くの場合、発信側で Cisco Unified CM は SDP なしで INVITE を送信します。これにより、Cisco Unified CM は両側の機能を検出したり、必要に応じてその間にメディア サービス(たとえば、トランスコーディング)を提供できます。

単純な保留と復帰

Cisco Unified CMSIP 回線側では、RFC 2543(つまり、c = 0)または RFC 3261 および 3264(a = 送信のみ、または a = 非アクティブ)に従って単一のメディア保留をサポートします。

転送

SIP 回線側の転送では、RFC 3515 に従って REFER メッセージ、および組み込み型 Replaces ヘッダーが指定された REFER を使用します。

コール転送には、次の 3 人の関係者が存在します。

被転送者:転送される人。

転送者:コールを転送する人。

転送先(ターゲット):転送を受ける人。

Cisco Unified CM は次の 3 種類の転送をサポートします。

在席(コンサルタティブとも言います)

初期在席

ブラインド

在席転送

在席転送では、転送者は、被転送者を保留にし、ターゲットを呼び出します。転送者は、ターゲットと通話した後で転送を実行し、コールからドロップします。被転送者は自動的に保留が解除され、ターゲットに接続されます。

在席転送には、組み込み型 Replaces ヘッダーが指定された REFER を転送者のデバイスが送信するまで、そのデバイスにおいてある程度独立したダイアログ 2 つが含まれます。このメッセージを受信すると、Cisco Unified CM はコールが関連付けられていることを認識します。

Cisco Unified CM は B2BUA であるので、組み込み型 Replaces ヘッダーが指定された REFER は被転送者から転送先への Replaces が指定された INVITE をトリガーしません。Cisco Unified CM と各電話機の間のダイアログは独立したままです。代わりに、Cisco Unified CM は、被転送者と転送先に reINVITE(および UPDATE)を送信し、被転送者と転送先を接続します。このプロセス中に、転送者は sipfrag NOTIFY メッセージを受信します。接続が完了すると、Cisco Unified CM と転送者の間のダイアログは両方とも BYE を受信します。

次に、REFER を受信したときの処理の詳細を示します。

1. 転送者と被転送者のコールを分割します。

メディアを接続解除する reINVITE。

2. 転送者と転送先のコールを分割します。

メディアを接続解除する reINVITE。

3. 被転送者と転送先のコール レッグを接続します。

a. メディアを接続する reINVITE。

b. Remote-Party-ID ヘッダーによる表示名と番号の更新(UPDATE)。

4. 転送者のダイアログをクリアします。

初期在席転送

初期在席転送では、転送者が元のコールを保留にし、ターゲットを呼び出します。リング バック トーンを受信すると、転送者はターゲットにコールを転送し、両方のコールからドロップします。被転送者は、ターゲットの電話機が呼び出し中リングバックを受信します。ターゲットが応答すると、被転送者とターゲットの間の接続が確立されます。

組み込み型 Replaces ヘッダーが指定された REFER を使用する転送者のコール フローは、SIP 電話機およびゲートウェイでのこの機能の既存の実装に基づいています。ピア ツー ピア環境でのこの実装に関する問題は、複数のターゲットへの並行分岐をサポートできないことです。Replaces ドラフトのバージョン 04 では、特に UAS がその UA から開始されなかった Replaces ヘッダーを受け入れないようにするとされています。その場合、受信 UAS は 481 メッセージを返す必要があります。代わりに、既存の実装は要求を受け入れ、early ダイアログを置き換えます。これにより、転送者に 487 メッセージが返信されます。

初期在席転送には、転送者のデバイスが組み込み型 Replaces ヘッダーが指定された REFER を送信するまで、そのデバイスでのある程度独立したダイアログ 2 つが含まれます。このメッセージを受信すると、Cisco Unified CM はコールが関連付けられていることを登録します。Cisco Unified CM は B2BUA であるので、Replaces ヘッダーが指定された REFER は被転送者から転送先への Replaces が指定された INVITE をトリガーしません。Cisco Unified CM と各電話機の間のダイアログは独立したままです。代わりに、Cisco Unified CM は、被転送者と転送先に reINVITE(および UPDATE)を送信し、被転送者と転送先を接続します。このプロセス中に、転送者は sipfrag NOTIFY メッセージを受信します。接続が完了すると、Cisco Unified CM と転送者の間のダイアログは両方とも BYE を受信します。

次に、REFER を受信したときの処理の詳細を示します。

1. 転送者と被転送者のコールを分割します。

メディアを接続解除する reINVITE。

2. 転送者と転送先のコールを分割します。

メディアを切断するために転送者に送信される reINVITE。

3. 被転送者と転送先のコール レッグを接続します。

a. メディアを接続する reINVITE。

b. Remote-Party-ID ヘッダーによる表示名と番号の更新(UPDATE)。

c. 転送者のダイアログをクリアします。

ターゲットが呼び出し中ですが、被転送者はリングバックを受信しません。

ブラインド転送

ブラインド転送では、転送者が元のコールを保留にし、ターゲットにダイヤルします。転送者は SIP REFER を使用して被転送者をターゲットにリダイレクトします。転送前にターゲットにコールは発信されません。転送者がコールからドロップするタイミングは、転送者の機能の実装によって異なりますが、一般的には転送者がリダイレクト操作が承認され、開始されたことを通知されたときにドロップします。

在席転送および初期在席転送の場合とは異なり、REFER には組み込み型 Replaces は含まれません。

3 者間コール

多くの SIP 電話機はエンドポイントによるローカル ミキシングをサポートします。たとえば、Cisco Unified IP Phone 7960/40 の既存の SIP 実装はこの機能をサポートしています。これは、Cisco Unified CM の回線側 SIP エンドポイントで動作し続けます。電話機でローカル ミキシングをサポートするために、Cisco Unified CM はエンドポイントが複数のアクティブ コールを持てるようにする必要があります。Cisco Unified CM は、SIP エンドポイントにこれを許可します。Cisco Unified CM からは、ローカル ミキシングされた 3 者間コール(または n 者間コール)は個別のアクティブ コールのように見えます。Cisco Unified CM はローカル ミキシングを認識しません。会議リストや最後の参加者の削除など、 Cisco Unified CM の会議関連機能は適用されません。

SIP 環境で、3 者間コールをホストしているエンドポイントはドロップし、残りの 2 人が接続されるよう調整できます。SIP を使用すると、これは組み込み型 Replaces が指定された REFER を使用して行われます。このアクションの前に、4 つのダイアログがある 2 つのコールが存在します。

1. A.1 から B へのコール:

a. A.1 から Cisco Unified CM へのダイアログ。

b. Cisco Unified CM から B へのダイアログ。

2. A.2 から C へのコール:

a. A.2 から Cisco Unified CM へのダイアログ。

b. Cisco Unified CM から C へのダイアログ。

電話機 A は、ダイアログ A.2 を指定する組み込み型 Replaces ヘッダーが指定された In-dialog REFER をダイアログ A.1 で送信することで、コールからドロップできます。Cisco Unified CM は、在席転送機能を起動し、これによって残りの参加者が接続されます。この機能の動作の詳細については、「在席転送」を参照してください。

コール転送

コール転送は、コールが元の着信者によって応答されず、代わりに 1 つ以上の後続の転送側に提供されたときに行われます。Cisco Unified CM は 3 種類の転送をサポートします。

すべてのコールの転送(無制限のコール転送とも呼ばれます)

応答なしのコール転送

話中のコール転送

応答なしのコール転送の場合にだけ、コールは実際に元の着信者に示されます。Cisco Unified CM は、着信者に INVITE を送信する前に、すべてのコールの転送および話中のコール転送を検出するので、転送はその着信者をバイパスします。応答なしのコール転送は Cisco Unified CM のタイマーで検出されるので、Cisco Unified CM は元の着信者へのコールのキャンセルを開始します。

電話機にすべてのコールの転送およびコール転送(通話中)をローカルに実装するために、SIP を使用する以前のシスコ製電話機またはサードパーティ製 SIP 電話機を選択できます。この場合、INVITE にそれぞれ 302(「エンドポイントが返す 302 リダイレクト」を参照)および 486(「エンドポイントが返す 486 通話中」を参照)応答コードを使用する必要があります。

Cisco Unified CM は、更新された 180 メッセージの「Remote-Party-ID:」ヘッダーによってコールが転送されたことを発呼側に通知します。転送の種類は発呼側に通知されません。

次に例を示します。

Remote-Party-ID: "Line 1030 Name" <sip:1030@172.18.203.78>;party=called;id-type=subscriber;privacy=off;screen=yes
 

Cisco Unified CM は、後続の INVITE の「Diversion:」ヘッダーを使用して着信者(または現在の転送先)に転送を示します。 Cisco Unified CM は、最大で 2 つの Diversion ヘッダーを報告します。1 つ目は最後の転送者を示し、2 つ目は元の着信者を示します。シングル ホップの転送の場合、元の着信者と最後の転送者が同じであるので、単一の Diversion ヘッダーだけが使用されます。3 つ以上のホップの場合、途中の当事者は現在の転送先に通知されません。次に例を示します。

Diversion: "Line 1020 Name" <sip:1020@172.18.203.99>;reason=no-answer;privacy=off;screen=yes
Diversion: "Line 2020 Name" <sip:2020@172.18.203.99>;reason=unconditional;privacy=off;screen=yes
Diversion: "Line 3020 Name" <sip:3020@172.18.203.99>;reason=user-busy;privacy=off;screen=yes
 

電話機はソフトキーによってすべてのコールの転送をアクティブにすることができます。

メッセージ待機インジケータ

電話機のメッセージ待機インジケータ(MWI)のアクティブ化は、Cisco Unified CM からの Unsolicited Notify によりトリガーされます。NOTIFY には、イベント タイプ「message-summary」、コンテンツ タイプが「application/simple-message-summary」のメッセージ本文、および電話機に MWI をオンにするように指示する「Messages-Waiting: yes」または電話機に MWI をオフにするように指示する「Messages-Waiting: no」のいずれかが含まれる本文があります。

この MWI NOTIFY は、Cisco Unified CM が電話機の MWI ステータスの変更を検出するたびに送信されます。これは、メッセージが接続されているボイス メッセージング サーバ上のサブスクライバに残されていて、そのボイス メッセージング サーバが Cisco Unified CM に通知する場合、またはすべてのメッセージが消去される場合に実行されることもあります。また、現在の MWI の状態が含まれているこの NOTIFY は回線の登録時に常に送信されるので、フラッシュ メモリを搭載した電話機には、Cisco Unified CM に認識されている MWI の状態が表示されます。

エンドポイントが返す 302 リダイレクト

すべての SIP 電話機が電話機と Cisco Unified CM の間のすべてのコールの転送の状態を同期するための拡張されたすべてのコールの転送のアクティブ化動作をサポートしているわけではないので、一部の電話機では、コール転送番号を電話機にローカルに設定し、代わりに 302 メッセージを INVITE に返信できます。

302 メッセージには、コールの転送先を示す「Contact:」ヘッダーが含まれている必要があります。302 を送信する電話機には、名前と番号および転送の理由を示す「Diversion:」ヘッダーも必要です。

Cisco Unified CM が電話機から 302 メッセージを受信すると、最初にリストされている 302 の Diversion ヘッダーが指定された 302 の Contact ヘッダーに示されている次の当事者にコールを提供します(次の当事者も SIP デバイスとします)。次の当事者も転送すると、302 を送信している電話機が元の着信者であった場合、最初の 302 で送信される Diversion ヘッダーは後続の転送先に渡されます。

エンドポイントが返す 486 通話中

Cisco Unified CM のすべての回線に「ビジー トリガー」を設定できます。回線へのアクティブ コールの数がビジー トリガーに達すると、Cisco Unified CM はその電話機に別の INVITE を送信せずに話中のコール転送を開始して、その電話機にこれ以上コールが提供されないようにします。

ただし、Cisco Unified CM が電話機に存在することを認識していない誤設定やコールの可能性により(たとえば、INVITE をまだ送信していないダイヤル状態の電話機)、電話機は独自のビジー トリガーを管理し、自律的にコールを制御する必要がある場合があります。電話機は INVITE に 486 応答コードを送信して、これを行います。

Cisco Unified CM では回線に話中のコール転送の動作(たとえば、DN への転送やボイス メッセージ システムへの転送)が設定されていることがありますが、486 メッセージが電話機から受信されると、この動作は実行されません。代わりに、486 メッセージは元の着信者に戻されます。

特定のコール セットアップ障害のアナウンス

当事者 A が当事者 B にコールする場合、コールが完了できず、コール障害の理由に関するアナウンスが当事者 A に再生されることがあります。単純な例は、当事者 A が B の番号をかけ間違い、かけ間違えた番号がない場合です。これは空きコード エラーになります。

この同じシナリオでは、当事者 A が SCCP 電話機の場合、当事者 A は Annunciator に接続され、「ダイヤルしたコールを完了できません。ディレクトリを調べてかけ直すか、オペレータに連絡してください。これは録音です。(Your call cannot be completed as dialed.Please consult your directory and call again or ask your operator for assistance.This is a recording.)」といったアナウンスを受信します。アナウンスが完了すると、まだオフフックの場合は当事者 A にリオーダー トーンが聞こえます。Cisco Unified CM 8.0 以前は、当事者 A が SIP であった場合、4xx SIP エラー メッセージの結果すぐに電話機でローカルにリオーダーが聞こえ、アナウンスは聞こえません。Cisco Unified CM 8.0 では、SIP 電話機がアナウンスが行われるエラー シナリオ(たとえば、空きコード)に対応できるようになりました。

これらのアナウンスのコール フローは標準 SIP を使用します。フローのサンプルを次に示します。このシナリオでは、従来どおりアナウンスが再生され、4xx/5xx エラー コードが送信されます。SIP 183 には SDP が含まれます。

図 1-1 Annunciator 挿入コール セットアップ シナリオ

 

 

コール セットアップ時にアナウンスが発生する可能性のあるエラー シナリオには、MLPP に起因する特定のコール セットアップ障害および空きコードがあります。

INFO パッケージ

INVITE ダイアログの期間中、INFO パッケージでは SIP UA がサブスクリプションを管理および相関させずにネゴシエートされた内容を交換できます。INFO パッケージのネゴシエーションは最初のコール セットアップ時に行われ、INVITE ダイアログの期間中記憶されます。これは、エンドポイントが転送や会議などの一部の機能対話を実行する回数に依存しません。

Unified Communication Manager は、会議パッケージをサポートします。ネゴシエーションは次のドラフトに規定されているルールに従って動作します。

draft-ietf-sip-info-events-01.txt。

INFO 会議パッケージのネゴシエーション

Unified Communication Manager は B2BUA です。したがって、コールの確立時に各エンドポイントには Unified Communication Manager との独自の INVITE ダイアログがあります。機能呼び出しのため、Unified Communication Manager は元の INVITE ダイアログを保持しながらメディアを移動できます。たとえば、A が B を C に転送すると、B と C は互いにメディアをリダイレクトし、接続先情報を更新するために、reINVITE および UPDATE だけを取得します。転送前に B と Unified Communication Manager の間および C と Unified Communication Manager の間に確立された元のダイアログはそのまま残ります。

会議 INFO パッケージのネゴシエーションは最初のコール セットアップ時に行われ、INVITE ダイアログの期間中記憶されます。これは、エンドポイントが転送や会議などの一部の機能対話を実行する回数に依存しません。実際の会議パッケージ XML は次の RFC から借用されます。

RFC-4575、『A Session Initiation Protocol (SIP) Event Package for Conference State』

RFC は SUBSCRIBE/NOTIFY フレームワークのコンテキストでパッケージを定義します。同じ XML スキーマは INFO イベント パッケージ フレームワークで使用できます。

Unified Communication Manager のコンテキスト内のネゴシエーションは次の方法で動作します。

A が B をコールする場合、Unified Communication Manager が B2BUA であるので、これは 2 つの異なるダイアログになります。この例では、A は A と Unified Communication Manager の間のダイアログの開始者になります。一方、Unified Communication Manager は Unified Communication Manager と B の間のダイアログの開始者になります。ネゴシエーションは、ダイアログの開始者およびデータの送信者と受信者に基づいて動作します。例では、A と B は会議参加者リストの更新の受信者であり、Unified Communication Manager は送信者です。図 1-2 に、INFO 会議パッケージの使用をネゴシエートするためのこの例での Send-Info ヘッダーと Recv-Info ヘッダーの使用方法を示します。エンドポイントにヘッダー、Recv-Info: conference が含まれていない場合、コールが後で会議に接続されると Unified Communication Manager は会議パッケージを使用した INFO メッセージを送信しません。

図 1-2 会議 INFO パッケージのネゴシエーション

 

INFO 会議パッケージの使用をネゴシエートすると、エンドポイントはダイアログの期間中にいつでも会議 INFO を受信する準備ができている必要があります。ダイアログの期間中、エンドポイントは会議を出入りする場合があります。会議の終了は、エンドポイントがこれ以上会議のアップデートを受信しないことを保証しません。コールは 3 者間から 2 者間に移行して 3 者間に戻すことができます。図 1-3 に、3 者間会議の作成を示します。

図 1-3 3 者間会議の作成

 

G.Clear コール

Cisco Unified CM は、音声およびビデオ コールをサポートします。また、G.Clear のコーデックを使用して 2 つの登録済み SIP エンドポイント間のメディア セッションを確立します。G.Clear のメディア セッションは、2 台のデバイス間の 64kbps 透過データ チャネルを確立するために RTP を使用します。これにより、ISDN 端末で生成されるデータ ストリームを IP ネットワーク経由で透過的に伝送できます。詳細については、RFC 4040 を参照してください。

Cisco Unified CM は次をサポートします。

1. SIP シグナリングおよびコーデック ネゴシエーションの G.Clear コーデック(RFC 4040)の処理。

2. MTP を必要とせず、G.Clear コール用に Cisco Unified CM からの発信 INVITE に SDP を含めること。

G.Clear コールの SDP の例

G.Clear コールを開始できる SIP エンドポイントは、INVITE SDP の m=audio 行に G.Clear コーデックを使用してインジケータを送信します。


) サードパーティ製 SIP デバイスだけが Cisco Unified Comunication Manager との G.Clear コールを開始できます。


G.Clear コーデックを持つ SDP の例

v=0
o=XYZ 317625 317625 IN IP4 172.18.199.61
s=XYZ
c=IN IP4 172.18.199.61
t=0 0
m=audio 30002 RTP/AVP 125
a=rtpmap:125 CLEARMODE/8000
a=ptime:20

Cisco Unified CM は、CLEARMODE に加えて他の rtpmap 属性もサポートします。着信 SDP の G.Clear コーデックとして X-CCD、CCD、および G.nX64 rtpmap 属性を識別できます。Cisco Unified CM は、CLEARMODE、X-CCD、CCD および発信 SDP の rtpmap 属性の G.nX64 のいずれかの値の送信をサポートします。これは Cisco Unified CM の設定に基づいています。たとえば、Cisco Unified CM は、発信 SDPL の G.Clear コーデックのこの属性行を送信するように設定する必要があります。

a=rtpmap:125 X-CCD/8000

G.Clear コールのアーリー オファー サポート

Cisco Unified CM は、INVITE request-uri 内の着信者番号に基づいてコールを別の SIP エンドポイントに、または SIP トランク上でルーティングします。Cisco Unified CM は、G.Clear コール用の発信 INVITE にオファー SDP を含めます。これは設定可能です。発信 INVITE に含まれる SDP は、着信 SIP コール レッグから受信します。したがって、Cisco Unified CM は、MTP を必要とせずに G.Clear コールだけの発信 INVITE のオファー SDP の送信をサポートします。Cisco Unified CM の音声コールには、音声コールの SDP を含めるために引き続き [MTP が必要(MTP Required)] チェックボックスをイネーブルにする必要があります。

BFCP

Cisco Unified CM の Release 8.6(1) は、SIP 回線とプレゼンテーション共有セッションを含むコールに参加している SIP トランク デバイスの間の Binary Floor Control Protocol(BFCP)のネゴシエーションのサポートが追加されています。プレゼンテーションは、メイン ビデオ ストリームに加えて PowerPoint スライド表示などの 2 つ目のビデオ ストリームを送信する機能です。BFCP はこの機能をイネーブルにします。

サンプル使用例のシナリオは、Cisco EX90 電話機によるビデオ コールの 2 人のユーザで構成されます。各ユーザには、HDMI または DVI 経由でそれぞれの EX90 に接続されたラップトップ コンピュータのビデオ出力があります。コール中に、EX90 のユーザ A がユーザ B とラップトップのビデオを共有することを決めます。ユーザ A が EX90 の [表示(Present)] ボタンを押します。EX90 と Cisco Unified CM は、SIP および BFCP プロトコルを使用して、ユーザ B がユーザ A のラップトップのビデオとともにユーザ A のメイン ビデオを見られるようにします。

BFCP は SDP 専用の機能で、シグナリング関連変更を伴いません。

リソース プライオリティを使用した Multilevel Precedence and Preemption

Cisco Unified CM では、設定されたデバイス タイプに応じて、シスコおよびサードパーティの両方のエンドポイントの Multilevel Precedence and Preemption(MLPP)をサポートします。Cisco Unified CM では、特定のモデルに対してのみ MLPP をサポートします。Resource Priority ヘッダーは、Cisco Unified CM とエンドポイント間の優先情報を伝達します。リソース プライオリティの Cisco Unified CM の実装は DISA Unified Capabilities Requirements に準拠し、特にネームスペースの処理に関しては、RFC 4412 標準の規定を上回っています。RFC 4412 ではネームスペース内のダッシュの存在に特別な意味はありませんが、UCR ではネームスペースをネットワーク ドメインと優先ドメインにトークン化するためにダッシュを予約しています。Cisco Unified CM では、ネームスペースにダッシュを使用することができ、ダッシュが単にネームスペースの一部であるか、または Cisco Unified CM 上のネットワーク ドメインの一部として設定されているかどうかに基づいたトークン デリミタであるかを特定します。

MLPP のプリエンプション機能は、Cisco Unified CM ではなく、エンドポイントによって処理されます。エンドポイントへの優先コールを示すために MLPP が有効な場合、Cisco Unified CM では通常のビジー トリガーを上書きします。

SIP コールの発信 ID および着信 CLI

SIP コールの発信 ID および着信 CLI の機能により、サービス プロバイダー(SP)が、HCS サービスの配置された地域における規制要因に対応できるように、SIP インターフェイスでの ID 選択、プレゼンテーション、および制限を拡張できる機能を提供します。これらの機能は、対応する SIP 電話機を制御するために、SIP トランクおよび SIP プロファイルでのプレゼンテーション(ID ヘッダーおよび From ヘッダー)に使用できる追加の設定フィールドによって提供されます。

SP ネットワークによって保持される 2 セットの ID、ネットワーク指定 ID(信頼できる)とユーザ指定 ID(信頼できない)があります。SIP コールでは、P-Asserted-Identity(PAI)、P-Preferred-Identity(PPI)、および Remote-Party-ID(RPID)が含まれた ID ヘッダーはネットワークで認証された ID を伝送する必要がありますが、From ヘッダーはユーザ/発信者指定の ID を伝送します。

従来、Cisco Unified CM は SP ネットワークへの発信コール用に ID の単一セットを提供するだけです。したがって、ID ヘッダーと From ヘッダー内の ID はまったく同じであり、ネットワーク指定 ID とユーザ指定 ID に違いはありません。一般に、管理者は、電話番号(DN)と表示名によって各ユーザ デバイスを設定します。この DN からの発信コールでは、ID ヘッダーと From ヘッダーの両方で電話番号と表示名が伝送されます。

管理者は、SIP トランク上に別の ID を設定することもできます。スイッチボード ID と呼ばれることもあるこの ID を使用して、個々の発信者 ID を隠すことができます。 発信コールの [SIP トランク(SIP Trunk)] の [発信者情報(Caller Information)] セクションでこれを設定できます。設定には、[発信者 ID DN(Caller ID DN)] と [発信者名(Caller Name)] の 2 つのフィールドがあります。たとえば、SIP トランクから発信されたすべてのコールは、[発信者名(Caller Name)] が「Cisco Systems」で [発信者 ID DN(Caller ID DN)] が「(800) 555-1234」の同じ ID を伝送します。ただし、このような設定を有効にすると、発信者の元の電話番号および表示名が上書きされます。

ただし、この新機能により、Cisco Unified CM では、管理者がスイッチボード ID と元の発信者 ID の両方の ID セットをイネーブルにできる設定を提供します。スイッチボード ID は From ヘッダーで伝送され、元の発信者 ID は ID ヘッダーで伝送されます。各 SIP トランクまたは SIP デバイスに対してこの設定をイネーブルにできます。

サービス プロバイダーのネットワークからの着信コールに対して、Cisco Unified CM では、ID ヘッダーで伝送されるネットワーク指定 ID、または From ヘッダーで伝送されるユーザ指定 ID を受け入れるための設定を提供します。Cisco Unified CM はコールごとの ID の単一セットのみを維持します。

URI ダイヤル

URI ダイヤル機能により、Cisco Unified CM は、bob@cisco.com など、英数字の URI をルーティングすることができ、URI および DN の両方をサポートするエンドポイントの ID ヘッダーで URI および DN を配信できるようになります。

次の使用例では、URI クラスタ内コールを示し、両方を混合させた配信が有効で、電話機が対応可能であると想定します。

1. 電話機 A が bob@cisco.com にダイヤルします。UCM は発信者と着信者(1000/bob@cisco.com、2000/alice@cisco.com)の混合した情報を検出します

2. UCM は電話機 B に INVITE を転送します。混合した ID 情報に対応するように電話機 B が設定されているため、RPID には混合した情報が含まれます。

3. 電話機は呼び出しを転送し、電話機からの RPID を無視します。UCM は 1000/bob@cisco.com と再度混合させます

4. UCM は電話機 A に 180 Ringing を転送します。混合した ID 情報に対応するように電話機 A が設定されているため、RPID には混合した情報が含まれます。

電話番号の非通知コールの拒否

電話番号の非通知コールの拒否機能により、管理者が特定の電話番号の非通知コールをブロックできます。この機能は、非通知コールの、特定の電話番号への到達を許可するか、拒否するかについて、管理者がきめ細かく制御できるようになります。

発信者の DN がない場合、または発信者の DN がプライベートで、着信者に表示されない場合、それは非通知の発信者からのコールです。

SIP 内の非通知コールは RFC 5079 に記載された基準に基づいて識別されます。RFC 5079 に基づき、次のような着信の初期 INVITE である場合、コールは非通知であると識別されます。

display-name「Anonymous」を含む From ヘッダーまたは PAI/PPI ヘッダー

From ヘッダー ホスト部分 = anonymous.invalid

プライバシー:ID またはプライバシー:ユーザまたはプライバシー:ヘッダー(PAI/PPI に関連付けられた)

Remote-Party-ID ヘッダーに display-name「Anonymous」が含まれている

Remote-Party-ID ヘッダーに privacy=uri/name/full が含まれている

着信非通知コールが電話機またはトランクなどの SIP デバイスから到着すると、Cisco Unified CM は、SIP 応答が 433 Anonymity Disallowed のコールを拒否します。433 応答は、Q.850 理由値 21(コール拒否)を含む Reason ヘッダーも伝送します。

次に、非通知の発信者に送信される SIP 433 応答の例を示します。

SIP/2.0 433 Anonymity Disallowed
Via: SIP/2.0/TLS 172.18.199.91:50486;branch=z9hG4bK3584db90
From: "Connected6005" <sip:6005@10.81.54.224>;tag=f0257279babd003850ae8c99-11653498
To: <sip:*@10.81.54.224>;tag=32638~078d0a52-bf48-420d-b77b-7737bebdf89b-18845479
Date: Mon, 11 Jun 2012 16:39:40 GMT
Call-ID: f0257279-babd0004-0c6a0894-727311e0@172.18.199.91
CSeq: 101 INVITE
Allow-Events: presence
Reason: Q.850; cause=21
Content-Length: 0
 

他のプロトコルでは、コール レッグで Q.850 理由 = 21(コール拒否)により拒否されます。