Cisco Unified Communications Manager 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)」

• 「Cisco Unified Communications Manager Release 8.6(1)」

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

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

表 1-5 に、標準 SIP 回線側インターフェイスの固有および非標準ヘッダー フィールドを示します。詳細については、「Remote-Party-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 表示制限」

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

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

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

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

name

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

uri

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

full

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

接続回線と名前の ID 表示

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

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

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

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

name

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

uri

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

full

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

CPN 番号表示

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

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

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

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

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

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

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

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

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

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

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

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

要求メッセージ

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

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

• 「INVITE」

• 「ACK」

INVITE

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

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 応答メッセージのフィールドを示します。

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 応答メッセージのフィールドを示します。

メッセージ タイマー

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

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

メッセージの再試行回数

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

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

登録

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:」ヘッダーによってコールが転送されたことを発呼側に通知します。転送の種類は発呼側に通知されません。

次に例を示します。

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

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

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

電話機のメッセージ待機インジケータ（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 の例

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 コーデックのこの属性行を送信するように設定する必要があります。

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 応答の例を示します。

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