×

警告メッセージ

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

CUCM における SIP アーリーオファーとアーリーメディアの動作

ドキュメント

2014/07/14 - 21:00
6月 24th, 2014
User Badges:
  • Cisco Employee,

 

1. はじめに

このドキュメントでは、RFC3261 で規定されている SIP (Session Initiation Protocol) のアーリーオファー (Early Offer) アーリーメディア (Early Media) の概要および Cisco Unified Communications Manager (CUCM) の動作について紹介します。

用語が似ているため混同しやすいですが、これらの動作を正しく理解することは、リングバックトーンの問題、応答後に音声が聞こえない問題、相互接続の問題などに対するトラブルシューティングに役立てることができます。

このドキュメントは CUCM バージョン 9.1(2) の動作を元に記載しています。

2. アーリーオファー

2.1. アーリーオファーとディレイドオファーの概要

SIP 電話機や SIP ゲートウェイなどの SIP ユーザエージェントは、SIP のメッセージボディ部に SDP (Session Description Protocol) を付与してお互いの能力を交換することによってセッションを確立し、通信を行います。最初に SDP にメディア情報を記載して相手側に送信することをオファー (Offer) と呼び、それに対して相手側が対応可能なメディア情報を返信することをアンサー (Answer) と呼びます。このオファーアンサーモデルは RFC3264 で規定されています。SDP は RFC4566 で規定されており、受信 IP アドレス、ポート、対応コーデックなどが記載されます。

以下の例では、発信側がコール発信時の INVITE リクエストに SDP オファーを付与し、着信側が応答時の 200 OK レスポンスに SDP アンサーを付与することによって SDP を交換します。このように発信側が INVITE リクエストに SDP を付与することをアーリーオファー (Early Offer) と呼びます。

  • アーリーオファー (Early Offer) の例


EO

 

一方、以下の例では、発信側は INVITE リクエストに SDP を付与せず、着信側が 200 OK レスポンスに SDP オファーを付与しています。そして発信側は ACK に SDP アンサーを付与しています。このように発信側が INVITE リクエストに SDP を付与しないことをディレイドオファー (Delayed Offer) と呼びます。

アーリーオファーは INVITE リクエストの送信側がオファーになるのに対して、ディレイドオファーは INVITE リクエストの受信側がオファーになります。

  • ディレイドオファー (Delayed Offer) の例


EO

 

2.2. CUCM のアーリーオファーの動作

CUCM は SIP B2BUA (Back-to-Back User Agent) として動作し、デフォルトの発信動作はディレイドオファーとなります。

以下の例は CUCM のデフォルトの動作を示しています。CUCM は発信側 IP Phone からアーリーオファーとして SDP 付きの INVITE リクエストを受信しますが、CUCM は B2BUA として動作しているため、そのまま SDP を透過せず、着信側 SIP サーバに SDP なしの INVITE リクエスト(ディレイドオファー) を送信します。

  • CUCM のデフォルト動作 (ディレイドオファー)の例


EO

 

CUCM は SIP トランク接続でアーリーオファーをサポートしており、下記の 2 つのいずれかの設定で実現することができます。

 (1). 発信側 SIP トランクの「メディアターミネーションポイントが必須 (Media Termination Point Required)」 にチェック


MTP

 (2). 発信側 SIP トランクに関連付けられている SIP プロファイルの 「音声コールとビデオコールに対する早期オファーのサポート(必要な場合はMTPを挿入)  (Early Offer support for voice and video calls (insert MTP if needed))」 にチェック

EO

(1) が設定された SIP トランク宛のコールでは、リソースが確保できる限り MTP の挿入が行われ、MTP の情報が INVITE リクエストの SDP に付与されます。一方、(2) が設定された SIP トランク宛のコールでは、受信した INVITE リクエストの SDP などのメディア情報を可能な限り流用して送信する INVITE リクエストの SDP に付与されます。流用した場合は MTP の挿入は行われません。流用できなければ MTP を挿入します。MTP を用いたコールでは使用コーデックなどが制限され、MTP リソースが消費されるために (2) の設定が推奨されます。

 

下記は (1) の例を示しています。「メディアターミネーションポイントが必須」 の設定は、MTP の挿入を要求します。SIP サーバ向けの SIP トランクの 「メディアターミネーションポイントが必須」 が設定されている場合は、CUCM は INVITE リクエストの SDP に MTP の情報を付与して SIP ゲートウェイに送信します。この例では MTP は CUCM 上のソフトウェア MTP を使用しているため、メディアパスは CUCM 上の MTP を経由します。

  • CUCM のアーリーオファー (メディアターミネーションポイントが必須) の例


EO

 

下記は (2) の例を示しています。「音声コールとビデオコールに対する早期オファーのサポート(必要な場合はMTPを挿入) 」 の設定は、受信したメディア情報を流用し、必要であれば MTP を利用します。CUCM は SIP サーバ向けの SIP トランクに関連付けられている SIP プロファイルの 「音声コールとビデオコールに対する早期オファーのサポート(必要な場合はMTPを挿入) 」が設定されている場合、IP Phone から受信した INVITE リクエストの SDP の情報を流用して SIP ゲートウェイ向けの INVITE リクエストの SDP に設定し、SIP サーバへ送信します。この場合は MTP は利用しません。

  • CUCM のアーリーオファー (音声コールとビデオコールに対する早期オファーのサポート) の例


EO

 

「音声コールとビデオコールに対する早期オファーのサポート(必要な場合はMTPを挿入) 」 が設定されており、CUCM に対する着信を次のいずれかの手段で受信した場合、SIP トランク上で発信アーリー オファー コールを作成するために、CUCM が MTP を挿入する必要はありません。その他の接続については MTP が必要となります。

 ・ アーリーオファーを使用する SIP トランク

 ・ Fast Start を使用する H.323 トランク

 ・ MGCP トランク

 ・ CUCM に登録されている SIP ベースの IP 電話 (アーリーオファーを使用)

 ・ CUCM に登録されている SCCP ベース (バージョン 20 以降) の Cisco Unified IP Phone モデル

  •  アーリー オファーによる音声コールおよびビデオ コールのサポート (SRND から抜粋)


SRND

 

3. アーリーメディア

3.1. アーリーメディアの概要

発信側がコール接続のために INVITE リクエストを送信し、着信側が最終応答 (200 OK レスポンス)する前の暫定応答 (1xx レスポンス) でメディアパスを確立することをアーリーメディアと呼びます。アーリーメディアは、サービスプロバイダがリングバックトーンを提供したり、非課金でアナウンスを提供する場合などに使用されます。

以下の例は、発信側がアーリーオファーとして INVITE リクエストに SDP オファーを付与して送信し、着信側が呼び出し中に 183 Session Progress レスポンスで SDP アンサーを付与して返信し、応答前にメディアパスを確立して着信側からリングバックトーンを聞かせる例となります。

  • アーリーメディア (アーリーオファー) の例


EM

 

以下の例は、発信側がディレイドオファーとして INVITE リクエストに SDP を付与せず、着信側が 183 Session Progress レスポンスに SDP オファーを付与し、発信側が PRACK リクエストで SDP アンサーを返信してメディアパスを確立している例となります。PRACK リクエストは RFC3262 で規定されていて 1xx 暫定応答の信頼性のために利用されます。

  • アーリーメディア (ディレイドオファー) の例


EM

 

3.2. CUCM のアーリーメディアの動作

アーリーオファーのコールフローでアーリーメディアによってメディアパスを開く場合は、特に設定は不要です。以下の例は CUCM がアーリーオファーで動作し、アーリーメディアでメディアパスを確立している例です。

  • CUCM におけるアーリーメディア (アーリーオファー) の例

EM

 

CUCM がディレイドオファーのコールフローでアーリーメディアによってメディアパスを開く場合は、CUCM が PRACK リクエストを送信する必要があります。デフォルトでは CUCM は PRACK リクエストを送信しないため、SIP トランクに関連付けられた SIP プロファイルの設定で、「SIP Rel1XX オプション (SIP Rel1XX Options)」 を 「1xx に SDP が含まれている場合にPRACKを送信 (Send PRACK if 1XX contains SDP)」 もしくは 「すべての1xxメッセージにPRACKを送信(Send PRACK for all 1XX messages)」 に設定する必要があります。


1xx

この設定により、CUCM は INVITE リクエストの Supported ヘッダに PRACK をサポートすることを意味する 100rel オプションを付与し、CUCM と着信側にて PRACK による接続が可能となります。以下の例は、CUCM がディレイドオファーで PRACK リクエストを利用してアーリーメディアでメディアパスを確立する例となります。

  • CUCM におけるアーリーメディア (ディレイドオファー) の例

EM

 

ここで、ディレイドオファーで上記の PRACK の設定を行わなかった場合、CUCM は着信側へ SDP アンサーを送信することができず、メディアパスを開くすることができないため、発信側へは 183 Session Progress レスポンスではなく、180 Ringing レスポンスを IP Phone に返信します。結果として、発信側は着信側からのリングバックトーンやアナウンスを受信することができず、IP Phone でローカルにリングバックトーンを生成します。

  • PRACK を使用しない場合のアーリーメディア (ディレイドオファー) の例


EM

 

4. 関連情報

 

 

Loading.

アクション

このドキュメントについて