Cisco Unified Border Element(SP Edition)コンフィギュレーション ガイド:統合モデル
SIP インスタント メッセージング
SIP インスタント メッセージング
発行日;2012/01/07 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 11MB) | フィードバック

目次

SIP インスタント メッセージング

構成内容

SIP インスタント メッセージング

SIP インスタント メッセージングの設定可能なオプション

SIP インスタント メッセージングの Record-Route パススルー

Record-Route パススルーの概要

登録済みの加入者と Record-Route パススルー

Record-Route パススルーの設定

SIP インスタント メッセージングのプライバシー

SIP インスタント メッセージングの SDP 処理

SDP の SIP URL

その他の SDP 処理

SIP インスタント メッセージング

Cisco Unified Border Element(SP Edition)では、SIP Instant Messaging(IM; インスタント メッセージング)がサポートされます。SIP インスタント メッセージングのオプションには、設定可能な SIP インスタント メッセージングの record-route パススルーとプライバシーの 2 つがあります。

標準的な SIP インスタント メッセージングの実装では、エンドツーエンドの Record-Route パススルーが使用されますが、プライバシーは適用されません。

Cisco Unified Border Element(SP Edition)は、以前は Integrated Session Border Controller と呼ばれており、このマニュアルでは通常 Session Border Controller(SBC; セッション ボーダー コントローラ)と呼びます。

本章で使用されているコマンドの詳細な説明については、『 Cisco Unified Border Element (SP Edition) Command Reference: Unified Model 』(http://www.cisco.com/en/US/docs/ios/sbc/command/reference/sbcu_book.html)を参照してください。

Cisco IOS のすべてのコマンドについては、http://tools.cisco.com/Support/CLILookup にある Command Lookup Tool か、Cisco IOS マスター コマンド リストを使用してください。

SIP インスタント メッセージングの機能履歴

 

リリース
変更点

Cisco IOS XE Release 2.5

SIP インスタント メッセージング機能が Cisco ASR 1000 シリーズ アグリゲーション サービス ルータに追加されました。

SIP インスタント メッセージング

Cisco Unified Border Element(SP Edition)では、SIP インスタント メッセージング(IM)がサポートされます。SIP インスタント メッセージングでは、SBC はコールを次のように処理します。

メディア アナウンス m=message または m=x-ms-message を使用するコールが許可されます。

複数の m=message 行が含まれるメッセージが許可されます。

SBC では、IM ダイアログをサポートするために帯域幅を割り当てません。これは、そのようなダイアログのメディア ストリームがないためです。

SDP にその他のメディア タイプも含まれている場合は、IM メッセージは拒否されます。

SBC は、プライバシーが設定されていない場合は SDP ボディーを変更せずに転送します。

発信側と着信側がエンドツーエンドの Route ヘッダー セットを使用できるように、Record-Route ヘッダーを IM ダイアログのある側から別の側に通過させるよう SBC を設定できます。この場合は、SBC は、Record-Route ヘッダーを追加して、Contact を書き換えないことによって、メッセージのフローに残ります。

SIP インスタント メッセージングの設定可能なオプション

SIP インスタント メッセージングの 2 つのオプションが設定可能です。次のセクションで説明します。

「SIP インスタント メッセージングの Record-Route パススルー」

「SIP インスタント メッセージングのプライバシー」

標準的な SIP インスタント メッセージングの実装では、エンドツーエンドの Record-Route パススルーが使用されますが、プライバシーは適用されません。

SIP インスタント メッセージングの Record-Route パススルー

ここでは、Record-Route パススルーについて説明します。次のサブセクションがあります。

「Record-Route パススルーの概要」

「登録済みの加入者と Record-Route パススルー」

「Record-Route パススルーの設定」

Record-Route パススルーの概要

Record-Route セットは、ホップバイホップ ルート SIP メッセージが SIP ダイアログの一部として 2 つのエンドポイント間を通過しなければならないことを表します。エンドポイントへの最終ホップは、Contact ヘッダーで表されます。SBC の標準的な動作では、Contact が書き換えられ、2 つの独立した Record-Route セット(コールの側ごとに 1 つ)が維持されます。これらの各 Record-Route セットは、コールの同じ側にあるエンドポイントと隣接間のルートを表しています。

エンドツーエンドの Record-Route セットを通過させるということは、コールの隣接が最終ホップを表さないため、Contact ヘッダーによって識別されないようにする必要があることを意味します。エンドツーエンド Record Route セットの通過時に、SBC は、エンドツーエンドの Contact も書き換えることなく通過させます。この場合は、SBC は、着信隣接と発信隣接を表す Record-Route ヘッダーを追加することによって、フローに残ります。

着信隣接と発信隣接に競合している Record-Route パススルー設定がある場合は、着信隣接の設定が使用されます。たとえば、着信隣接で Record-Route パススルーがイネーブルになっていても、発信隣接でイネーブルになっていない場合は、発信隣接は、提供された Record-Route セットを転送し、発信隣接に対応する Record-Route ヘッダーを追加して、Contact ヘッダーを未変更のままにします。

登録済みの加入者と Record-Route パススルー

Record-Route パススルーの動作は、着信隣接の Record-Route パススルー設定に関係なく、登録済みのエンドポイントの間で送受信される SIP メッセージには適用されません。

SIP 仕様(RFC 326)は、レジストラが REGISTER メッセージに存在する Record-Route ヘッダーを無視するよう定めています。そのため、SBC が登録済みの加入者の間で作成された後続のダイアログに確実に残るようにするには、SBC は REGISTER メッセージで Contact を書き換える必要があります。SBC は、ネットワークに以前にパブリッシュされた Contact と一致するように、登録済みのエンドポイントによって作成されるその後のダイアログで Contact を更新します。SBC が Contact を書き換えた時点で、SBC は既存の Record-Route セットをすべて終了し、新規のセットを作成します。

Record-Route パススルーの設定

Record-Route セットを通過させるために、SBC は、MIB フィールド vpssAdjRecordRoutePassthrough を使用して隣接単位で設定を行います。このフィールドは、vpssAdjacency MIB の一部です。

vpssAdjRecordRoutePassthrough が AMB_FALSE に設定されている場合は、Record-Route セットはキャッシュされ、エンドポイントに戻されます。その後、Record-Route セットは、後続の発信メッセージで Route ヘッダーを作成するために使用されます。どちらの側でもエンドツーエンドの Record-Route セット全体は表示されません。これはデフォルトの動作です。

vpssAdjRecordRoutePassthrough が AMB_TRUE に設定され、登録済みの加入者の間で要求が行われない場合は、次のことが発生します。

dialog-creating 要求では、要求に存在する Record-Route セットは SBC を通過し、受信側のエンドポイントに転送されます。

要求に存在する Contact は SBC を通過し、受信側のエンドポイントに転送されます。

着信隣接と発信隣接を表す Record-Route ヘッダーが要求に追加されます。

エンドツーエンドの Record-Route セットは、応答の SBC を通過して戻され、発信側エンドポイントに転送されます。両方のエンドポイントでエンドツーエンドの Record-Route セット全体が表示されます。

発信隣接の設定に関係なく、動作は前述のとおりです。

後続の in-dialog 要求では、dialog-creating 要求で受信した Contact と一致するよう Request URI は更新されません。

登録済みの加入者の間で行われた要求は、実際の値に関係なく、vpssAdjRecordRoutePassthrough が AMB_FALSE だった場合と同じように処理されます。

トポロジの隠蔽またはプライバシーがコールに適用される場合は、vpssAdjRecordRoutePassthrough フィールドの値に関係なく Record-Route セットは要求から除去されます。

Record-Route パススルーを設定しても、後続のメッセージで Route ヘッダーは通過しません。

Record-Route パススルーがイネーブルになっている場合は、前に説明したように IM ダイアログのメッセージは調整されます。そのような Record-Route パススルーの調整の例として、次の要求は、Record-Route パススルーをイネーブルにすると、IM ダイアログに使用される INVITE 要求がどのような影響を受けるかを示しています。最初の例では、Record-Route パススルーは使用されません。2 番めの例では、Record-Route パススルーがイネーブルにされ、SBC によって、太字の Record-Route 情報が INVITE 要求に追加されます。どちらの例でも、プライバシーは使用されません。

これらの例では、INVITE 要求は SBC から SIP プロキシ サーバへのアウトバウンドです。

アウトバウンド INVITE(Record-Route パススルーなし):

INVITE sip:callee@callee.com SIP/2.0
Via: SIP/2.0/UDP sbc.com;branch=z9hG4bK-sbc-1
From: Caller <sip:caller@dcsbc.com>;tag=dcsbc
To: Callee <sip:callee@callee.com>
Call-ID: sbc-call-1
Contact: Caller <sip:abcd@sbc.com>
Content-Type: application/sdp
Content-Length: 135
 
v=0
o=- 0 0 IN IP4 192.168.1.121
s=session
c=IN IP4 192.168.1.121
t=0 0
m=message 5060 sip sip:caller@caller.com
c=IN IP4 192.168.1.122
 

アウトバウンド INVITE(Record-Route パススルーあり):

INVITE sip:callee@callee.com SIP/2.0
From: Caller <sip:caller@caller.com>;tag=caller-tag-1
To: Callee <sip:callee@callee.com>
Call-ID: call-1
Contact: Caller <sip:caller@caller.com>
Record-Route: <sip:proxy1@example.com;lr>
Record-Route: <sip:caller_adj@sbc.com;lr>
Record-Route: <sip:callee_adj@sbc.com;lr>
 

SIP インスタント メッセージングのプライバシー

IM プライバシーでは、通常のコールに使用される CAC 設定も IM ダイアログに使用されます。CAC テーブル エントリ コマンド オプション caller-privacy によってプライバシーを設定します。このコマンドの使用については、http://www.cisco.com/en/US/docs/ios/sbc/command/reference/sbcu_book.html で『 Cisco Unified Border Element (SP Edition) Command Reference: Unified Model 』を参照してください。

プライバシーがイネーブルになっている場合は、SBC は、SIP IM SDP の 3 つのフィールドを調整して匿名にします。

Connection 行(c=)には、接続アドレス フィールドの重要な IP アドレス情報が含まれていることがあります。この情報は、対応する隣接のローカル アドレスとともに Session Description level Connection 行を挿入することで隠蔽されます。その他の Connection 行はすべて削除されます。

o= 行は SBC の独自の情報で置き換えられます。この行のアドレス フィールドは c= 行と一致するよう設定されます。

SIP IM ストリームを示す SDP では、Media Descriptions 行(m=)の形式は次のようになります。

m=message port [/ number_of_ports ] sip format_list

上記の format_list は SIP URL であり、ユーザの機密情報が含まれていることがあります。ユーザの機密情報は、Media Description 行を示すメッセージをすべて除去し、次の Media Description 行を含むオファーを転送することで隠蔽されます。

m=message 5060 sip sip:anonymous@192.168.10.10

次の例は、 caller-privacy をイネーブルにすると、IM ダイアログに使用される SDP メッセージがどのような影響を受けるかを示しています。例では、192.168.10.10 は発信隣接のローカル アドレスで、192.168.2.20 は着信隣接のアドレスです。例では、太字の情報は、発信側を匿名にするために調整されています。次の例は、SBC から SIP プロキシ サーバへのアウトバウンドです。

アウトバウンド INVITE(プライバシーなし):

v=0
o=- 0 0 IN IP4 192.168.1.121
s=session
c=IN IP4 192.168.1.121
t=0 0
m=message 5060 sip sip:caller@caller.com
c=IN IP4 192.168.1.122
 

アウトバウンド INVITE(プライバシーあり):

v=0
o=- 0 0 IN IP4 192.168.10.10
s=session
c=IN IP4 192.168.10.10
t=0 0
m=message 5060 sip sip:anonymous@192.168.10.10
c=IN IP4 192.168.10.10
 
 

次の例は、SBC から SIP ゲートウェイへのアウトバウンドです。

アウトバウンド 200 OK(プライバシーなし):

v=0
o=- 0 0 IN IP4 192.168.2.200
s=session
c=IN IP4 192.168.2.200
t=0 0
m=x-ms-message 5060 sip null
 

アウトバウンド 200 OK(プライバシーあり):

v=0
o=- 0 0 IN IP4 192.168.2.20
s=session
c=IN IP4 192.168.2.20
t=0 0
m=x-ms-message 5060 sip sip:anonymous@192.168.2.20

SIP インスタント メッセージングの SDP 処理

SDP では、SBC は、m=message または m=x-ms-message の有無で IM ダイアログを識別します。IM とオーディオ/ビデオ メディア回線の両方が組み込まれているオファーでは、SBC はエラー コード 488 Not Acceptable Here でオファーを拒否します。最初のメディア ネゴシエーションの後、IM から非 IM(またはその逆)へのコールを変更しようとする後続の再オファーもエラー コード 488 で拒否されます。

SBC は、プライバシーが原因の変更を除き、IM ダイアログの SDP を未変更のまま通過させます(「SIP インスタント メッセージングのプライバシー」を参照)。SBC は、ゲートまたはメディア ピンホールを割り当てません。

ここでは、SBC が SIP インスタント メッセージングの SDP を処理する方法について詳しく説明します。

「SDP の SIP URL」

「その他の SDP 処理」

SDP の SIP URL

SIP IM ダイアログに接続された SDP には、Media Description 行に SIP URL が含まれていることがあります。次に例を示します。

m=message 5060 sip sip:example@home.net

エンドポイントが(Request URI に URL を入れることによって)in-dialog メッセージを SDP の URL に送信する場合の動作は、次のようになります。

SBC が Record-Route セットを通過させるように設定されていない場合は、要求のルーティングは失敗することがあります。

SBC が Record-Route セットを通過させるように設定されている場合は、要求は、Request URI を変更せずに SBC によって転送されます。

Record-Route パススルーについては、「SIP インスタント メッセージングの Record-Route パススルー」を参照してください。

その他の SDP 処理

ここでは、SIP インスタント メッセージングのその他の SDP 処理について説明します。

変換:メディア ストリームはないため、SBC がトランスコーダを導入することはありません。着信側エンドポイントがメディア タイプをサポートしていない場合は、コールは失敗します。

特殊なメディア記述:SDP に、専用のメディア タイプである m=x-ms-message が含まれていることがあります。SBC は、m=x-ms-message を m=message と完全に同じように扱います。その他の専用のメディア タイプについてのサポートは追加されていません。

インターワーキング:SIP インスタント メッセージングは、SIP/H.323 コールまたは SIP-SIP レイト メディアとアーリー メディア間インターワーキング コールの間のインターワーキングを行いません。これらのシナリオで IM ダイアログを使用する場合は、コールの設定は応答コード 488 Not Acceptable Here で失敗します。

無効な接続アドレス:SBC は、プライバシーが設定されている場合を除き、SIP IM ダイアログの SDP を編集しません。そのため、SBC を通過する接続アドレスは、受信側エンドポイントに関する限り有効ではない可能性があります。メディアはエンドポイント間を流れないため、これは許容可能です。