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

Kenichi Ogami · ‎2014-06-24

はじめに
アーリーオファー (Early Offer)
アーリーオファーとディレイドオファーの概要
CUCM のアーリーオファーの動作
アーリーメディア (Early Media)
アーリーメディアの概要
CUCM のアーリーメディアの動作
関連情報

はじめに

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

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

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

アーリーオファー (Early Offer)

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

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) の例

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

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

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

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

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

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

CUCM のデフォルト動作（ディレイドオファー）の例

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

発信側 SIP トランクの [メディアターミネーションポイントが必須 (Media Termination Point Required)] にチェック
発信側 SIP トランクに関連付けられている SIP プロファイルの [音声コールとビデオコールに対する早期オファーのサポート (Early Offer support for voice and video calls)] を、[必須 (必要な場合は MTP を挿入) (Mandatory (insert MTP if needed)) ] に設定
発信側 SIP トランクに関連付けられている SIP プロファイルの [音声コールとビデオコールに対する早期オファーのサポート(Early Offer support for voice and video calls)] を、[ベストエフォート (MTP の挿入なし) (Best Effort (No MTP inserted)) ] に選択

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

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

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

以下は 2. の例を示しています。 [音声コールとビデオコールに対する早期オファーのサポート] が [必須 (必要な場合はMTPを挿入)] の設定は、受信したメディア情報を流用し、流用できなければ MTP を挿入します。

発信側が以下の場合はメディア情報を流用できず、MTP を挿入します。

Unified CM への着信コールがディレイドオファー SIP トランクを介して受信される場合
Unified CM への着信コールが H.323 Slow Start トランクを介して受信される場合
着信コールが Unified CM に登録されている古い SCCP ベース (バージョン 20 未満) の IP Phone から受信される場合

例では Older SCCP phones, SIP Delayed Offer, H.323 Slow Start の場合に MTP を挿入しています。

以下は 3. の例を示しています。 [音声コールとビデオコールに対する早期オファーのサポート] が [ベストエフォート (MTP の挿入なし)] の設定は、受信したメディア情報を流用してアーリーオファーで INVITE を送信し、流用できない場合は MTP を挿入せず、ディレイドオファーで INVITE を送信します。

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

アーリーメディア (Early Media)

アーリーメディアの概要

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

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

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

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

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

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

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

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

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)] に設定する必要があります。

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

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

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

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