音声ソース グループ機能
内容
概要
このドキュメントでは、ゲートウェイ(Cisco Unified Border Element(CUBE)がVoIPコールの送信元を特定してルーティングを制御できるようにするCisco IOS®の音声ソースグループ(VSG)機能について説明します。
背景説明
不正なIPアドレスからのコールシグナリングをブロックして通話料金不正を実装する状況が発生した場合は、Cisco IOS 15.1(2)Tで導入された通話料金不正防止機能を使用できます。詳細については、記事「IOS Release 15.1(2)T の電話ハッカーの侵入阻止機能」を参照してください。
ただし、古いバージョンのCisco IOSを使用している場合、または次の追加コントロールが必要な場合は、VSG機能を検討する必要があります。
- 設定可能なreject原因コード
- 発信者に基づいて発番号/着信番号を変更する
- 制御ルーティング（特定のキャリアへのルートなど）
VSG機能を使用すると、選択したサービスがコールに提供されるように、VoIPコールの送信元を特定できます。これらのサービスには、番号変換、着信ダイヤルピア照合、コール受け入れ/拒否の制御などがあります。また、この機能を使用すると、通話料金不正アプリケーションでは不可能な方法で（許可された）コールのルーティングを制御できます。たとえば、コールが着信ダイヤルピアに到達する前に発番号または着番号を操作するために、音声変換をVSGに関連付けることができます。同じダイヤル番号を持つコールが異なる着信ダイヤルピアを経由してルーティングされる可能性があるため、これは強力です。
VSGは、Cisco IOSアクセスコントロールリスト(ACL)を使用して識別を行います。
VSG属性
Access List
標準IOS ACLは、コールの受け入れと処理を行う送信元のIPアドレスを指定するために設定されます。ACLは、関連付けられたVSGで参照されます。
（着信コールの）送信元のIPアドレスにACLのエントリがない場合、ゲートウェイはVSGをコールに関連付けません。これは、コールがVSGで設定された操作の対象ではないことを意味します。
特定のIPアドレスからのコールを拒否する場合、そのIPアドレスをACLの下のdeny文に含める必要があります。
また、deny any文は、明示的に許可または拒否されていないIPアドレスからのコールを拒否するように設定されています。
接続解除原因
着信コールが拒否される原因コードは、VSGで設定できます。デフォルトでは、切断原因はno-serviceです。これは、Session Initiation Protocol(SIP)コールの500内部サーバエラーと、H.323コールの原因コード63(サービスまたはオプションが使用できず、未指定)のReleaseCompleteに変換されます。
ユーザ定義の切断理由は次のとおりです。
- 無効な番号
- 番号未割り当て
- ユーザ ビジー
- コール拒否
キャリア ID
Carrier-ID属性は、関連付けられたACLに一致するコールがcarrier-IDでタグ付けされるようにVSGで設定されます。これにより、発信元のIPアドレスに基づいて、同じ着信番号を持つコールを（発信側で）異なるキャリア経由でルーティングできます。たとえば、2つのIPアドレスグループがある場合、あるアドレスグループからのコールが1つのVSGを通過し、1つのキャリアIDでタグ付けされ、もう一方のグループからの（同じ着信番号への）コールが別のキャリアIDでタグ付けされます。以下が一例です。
voice source-group foo
access-control 98
carrier-id source carrier1
voice source-group bar
access-control 99
carrier-id source carrier2
dial-peer voice 100 pots
carrier-id source carrier1
...
dial-peer voice 200 pots
carrier-id source carrier2
...
ip access-control standard 98
permit 1.1.1.1
ip access-control standard 99
permit 2.2.2.2
deny any any
上記の設定では、1.1.1.1からのコールはダイヤルピア100を経由してルーティングされ、2.2.2.2からのコールはダイヤルピア200を経由してルーティングされます。
trunk-group-label
trunk-group-labelは、carrier-IDと同様に動作します。着信VoIPコールには、設定済みのトランクグループがタグ付けされます。このグループは、発信レッグを通じてコールがルーティングされるときに、適切なダイヤルピアを選択するために使用されます。
H.323ゾーンID
これはH.323プロトコルにのみ適用され、着信H.323コールのソースゾーンをVSGに照合するために使用されます。ソースゾーンIDは、H.323V4シグナリングプロトコルを使用する着信H.323コールで伝送され、H.323ゲートキーパーから発信されます。
複数の音声サービスグループ
IPIPGW上で複数のVSGを設定できます。IPIPGWでは、それぞれ異なるIPアドレスのセットからのコールを許可または拒否します。
複数のVSGがある場合は、最後のVSGのACLにdeny any ONLYを追加することに注意してください。それ以外の場合、中間ACLにdeny anyが設定されている場合、そのACLがdeny anyのACLの後に設定されている場合、別のACLで明示的に許可されているIPアドレスからのコールは拒否されます。たとえば、次の2つのVSGがあります。
voice source-group foo
access-list 98
voice source-group bar
access-list 99
VSGのACLを次に示します。
ip access-list standard 98
permit 1.1.1.1
deny any
ip access-list standard 99
permit 2.2.2.2
deny any
この例では、IPアドレスを許可するACLはdeny anyを指定したACL(98)の後であるため、2.2.2.2からの呼び出しは拒否されます。
このコマンドを使用すると、コールが拒否されたことを確認できます。
Router#test source-group ip-address 2.2.2.2
A source-group is found with ip address=2.2.2.2
An ip address 2.2.2.2 is rejected with disc-cause="no-service"
コールを許可するには、アクセスリスト98からdeny anyを削除する必要があります。
ip access-list standard 98
permit 1.1.1.1
test source-group ip 2.2.2.2コマンドを再度使用して、問題のIPアドレスからのコールが拒否されていないことを確認できます。
Router#test source-group ip-address 2.2.2.2
A source-group is found with ip address=2.2.2.2
確認
test source-group <VSG>コマンドは、基本的な検証（特定のIPアドレスからのコールがVSGによって処理されるかどうか）に使用できます。
トラブルシュート
前のセクションで説明したように、test source-group <VSG>コマンドは、特定のコールが許可されるか拒否されるかを検出するのに役立ちます。また、コールが許可される場合、このコマンドは、どのVSGが？ルーティングを行うかも示します。付与します。同様に、コールが拒否されると、拒否理由が表示されます。このコマンドは、IPアドレスに加えて、他の属性に基づいてルーティングVSGを検索します。
その他のトラブルシューティング支援は、debug voice source-group debugコマンドです。たとえば、H.323コールが（デフォルトの原因コードを使用して）拒否されると、デバッグは次の出力を生成します。
092347: .Apr 7 10:53:46.132: SIPG:src_grp_check_config() src_grp or src_grp
acl is defined
092348: .Apr 7 10:53:46.136: %VOICE_IEC-3-GW: H323: Internal Error (H323
Interworking Error): IEC=1.1.127.5.21.0 on callID 264
注意と注意
VSGに関する重要な注意事項を次に示します。
- VSGは、電話料金詐欺アプリケーションよりもはるかに柔軟性が低い。コールがコール制御層に到達するのを防ぎ、エラーメッセージをログに記録しません。これは、コールが許可されるかブロックされるかに関係なく当てはまります。
- そのゲートウェイに対してGlobal Load Balancing Protocol(GLBP)が有効になっている場合に問題が発生する場合があります。GLBPとVSGが設定されている相対順序に明確な依存関係があるようです。このような問題が発生した場合は、次の手順を実行します。
- GLBPを無効にします。
- VSGを再適用します。
- ゲートウェイを再起動します。
- VSGが動作していることをテスト/確認します。
- GLBPを有効にします。
フィードバック