CUBEでのDTMFリレーの設定
内容
はじめに
このドキュメントでは、Cisco Unified Border Element（CUBE）Enterprise の Dual-Tone Multi-Frequency（DTMF）リレーの設定プロセスを説明しています。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- DTMF トーンの基本的な知識
- Cisco® IOS音声（ダイヤルピアなど）の設定および使用方法に関する基本的な知識
- CUBE の設定および使用方法に関する基礎知識
- SIP および H323 プロトコルによって使用されるシグナリングの基本的な知識
- H323 や SIP などの VoIP プロトコルのデバッグ方法に関する基本的な知識
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- Cisco IOSで動作するCisco Unified Border Element。
- Cisco Unified Communications Manager 7.x以降。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
背景説明
このドキュメントでは、CUBEでサポートされるさまざまなVoIPゲートウェイプロトコルのDTMFリレーを設定、確認、およびトラブルシューティングする方法に関する情報とコマンドについても説明します。
CUBE でサポートされる DTMF リレー方式
CUBEは、H.323およびSession Initiation Protocol(SIP)シグナリングプロトコル用のインバンド(OOB)とアウトオブバンド(OOB)の両方の幅広いDTMFリレー方式をサポートしています。
サポートされるインバンド DTMF リレー方式
- G711によるインバンドオーディオDTMF
- RFC2833
サポートされるアウトオブバンド DMTF リレー方式
- H.245 Alphanumeric
- H.245 Signal
- SIP Unsolicited NOTIFY
- SIP KPML
- SIP INFO
G711によるインバンドオーディオDTMFのサポート
音声インバンドオーディオまたはG711 DTMFは、音声オーディオストリーム上での可聴トーンの転送を指します。この場合、コールを正常にセットアップし、音声をエンドツーエンドで渡してG711Ulaw/Alawコーデックを使用する以外に、シグナリングプロトコルやDSPによる伝送は必要ありません。つまり、CUBE/Cisco IOSは、一方の端から他方の端に到達するトーンの音声を、通常の音声オーディオと同様に渡します。この方式で実行する重要な手段は、コールが確立され、G711Ulaw/Alawコーデックが使用されるようにすることです。これは、オーディオを圧縮するコーデック（G711以外のコーデック）を使用すると、DTMFトーンが歪み、着信側で認識できなくなる可能性があるためです。これは、圧縮率が高いコーデックにより使用される圧縮アルゴリズムは、DTMF トーンではなく人間の音声を認識したり予測したりするように設計されているためです。
インバンド オーディオ/G711 DTMF は、どの VoIP シグナリング プロトコルでもサポートされ、必要とするのはエンド ツー エンドのコールに適用する G711 コーデックのみです。低ビットレート（LBR）コーデックの G711 へのトランスコーディング処理はすべて、トーンを歪める可能性が非常に高いことも必ず留意しておく必要があります。
H323でサポートされるDTMFリレー方式
H.245 Alphanumeric
DTMFディジットは音声ストリームから分離され、RTPチャネルではなくH.245シグナリングチャネルOOBを介して送信されます。トーンは H.245 ユーザ入力通知メッセージで転送されます。H.245 シグナリング チャネルは信頼性の高いチャネルであり、DTMF トーンを転送するパケットの配信が保証されます。H.323 バージョン 2 準拠であるすべてのシステムは、dtmf-relay h245-alphanumeric コマンドをサポートする必要があります。ただし、dtmf-relay h245-signal コマンドのサポートはオプションです。
H.245 Signal
H.245 Alphanumericに類似したOOB方式では、トーン継続時間情報の受け渡しが可能です。これにより、他のベンダーのシステムとインターワーキングする際に発生する可能性がある、Alphanumeric方式の問題に対処できます。
名前付きテレフォニー イベント（NTE）：RFC2833
この方式では、RFC 2833 のセクション 3 に従って、DTMF トーンを別個の RTP パケットで転送します。RFC 2833 では、NTE RTP パケットの形式を、2 つのピア エンドポイント間の DTMF ディジット、フック フラッシュ、および他のテレフォニー イベントの転送に使用するよう定義しています。NTE 方式を使用する場合、エンドポイントは、DTMF リレー パラメータのコールごとのネゴシエーションを実行し、RTP NTE パケットとサポートされる NTE ディジット イベントのペイロード タイプ値を決定します。その結果、DTMFトーンは、他のメディアパケット用にネゴシエートされた値とは異なるペイロードタイプ値を持つRTPパケットを介して通信されます。これにより、ディジットを転送し、音声、ビデオ、またはファックストラフィックのエンコードに使用されるコーデックで圧縮されるときにディジットが認識されないことを回避する信頼性の高い方法が提供されます。
RFC2833/NTE DTMF リレーは、GW シグナリング プロトコルに関係なく、ディジットが RTP オーディオ トラフィック内のみで転送されるので、インバンド方式と見なされます。
重要な点として、RFC2833/NTE方式を音声インバンドオーディオまたはG711 RTPストリームと混同しないようにしてください。後者は、リレーシグナリング方式がプロセスに認識されたり関与したりすることなく、通常のオーディオとして渡される単なる可聴トーンであるためです。これは、それらが G711Ulaw/Alaw コーデックを使用してエンド ツー エンドで受け渡される、単なるプレーン オーディオ トーンであることを意味します。
H323でのNTEに関するその他の情報：
- H.323 は V4 以降の RFC2833 をサポートします。
- Cisco IOSは、TCSでの2833サポートを常にアドバタイズします
- CUCM は H.323 ICT によってのみ NTE をサポートします。
シスコ独自の RTP
この方式では、DTMF トーンは音声データと同じ RTP チャネルで送信されます。ただし、DTMFトーンは音声サンプルとは異なる方法でエンコードされ、ペイロードタイプ121として識別されます。これにより、受信者はそれらをDTMFトーンとして識別できます。この方式は CUCM ではサポートされておらず、その使用は廃止されています。
SIP のサポートされる DTMF リレー方式
NTE - RFC2833
インバンドRFC2833 NTEペイロードタイプおよび属性は、SIPメッセージの本文セクション内でSession Description Protocol(SDP)を使用するコールセットアップ時に、2つのエンド間でネゴシエートされます。
Unsolicited NOTIFY（UN）
この方式では、ディジットはメッセージ本文のペイロード内のSIP NOTIFYメッセージとしてOOBで送信されます。
Key Press Markup Language（KPML）
RFC4730 に基づいて、ディジットは、Subscribe/NOTIFY メッセージ内の XML を使用した OOB で転送されます。主にCUCMまたはCMEに登録されているSIPエンドポイントで使用されますが、ITSPでも使用されます。
情報（INFO）
ディジットは、端末間での OOB SIP INFO メッセージとしてリレーされます。この方式では設定は不要であり、CUBE により自動的に受け入れられて関連付けられます。
CUBE 上での DTMF リレーの設定
デフォルトでは、DTMFリレーはH323ダイヤルピアとSIPダイヤルピアの両方で無効になっています（SIP INFOを除く）。DTMFリレー方式は、各コールレッグの着信ダイヤルピアと発信ダイヤルピアの両方でエンドツーエンドで使用されるように設定する必要があります。
H323 に対する DTMF リレーの設定
Router(config)#dial-peer voice 1 voip Router(config-dial-peer)#dtmf-relay ? cisco-rtp Cisco Proprietary RTP h245-alphanumeric DTMF Relay via H245 Alphanumeric IE h245-signal DTMF Relay via H245 Signal IE rtp-nte RTP Named Telephone Event RFC 2833
受信側端末の要件に応じて、ダイヤルピアごとに複数のメソッドを設定できます。
Router(config-dial-peer)#dtmf-relay rtp-nte ? cisco-rtp Cisco Proprietary RTP digit-drop Digits to be passed out-of-band and in-band digits dropped h245-alphanumeric DTMF Relay via H245 Alphanumeric IE h245-signal DTMF Relay via H245 Signal IE
SIP に対する DTMF リレーの設定
Router(config)#dial-peer voice 1 voip Router(config-dial-peer)#dtmf-relay ? cisco-rtp Cisco Proprietary RTP h245-alphanumeric DTMF Relay via H245 Alphanumeric IE h245-signal DTMF Relay via H245 Signal IE rtp-nte RTP Named Telephone Event RFC 2833 sip-kpml DTMF Relay via KPML over SIP SUBCRIBE/NOTIFY sip-NOTIFY DTMF Relay via SIP NOTIFY messages
受信側端末の要件に応じて、ダイヤルピアごとに複数のメソッドを設定できます。
Router(config-dial-peer)#dtmf-relay rtp-nte ? cisco-rtp Cisco Proprietary RTP digit-drop Digits to be passed out-of-band and in-band digits dropped h245-alphanumeric DTMF Relay via H245 Alphanumeric IE h245-signal DTMF Relay via H245 Signal IE sip-kpml DTMF Relay via KPML over SIP SUBSCRIBE/NOTIFY sip-NOTIFY DTMF Relay via SIP NOTIFY messages
DTMF リレーのディジットドロップの設定
同じ DTMF ディジットを、インバンド方式とアウトオブバンド方式を介してインバンド（具体的には RTP-NTE）からアウトオブバンド方式にインターワーキングするコールの発信レグにリレーすることで、ディジットが重複してしまうことを避けるために、dtmf-relay rtp-nte digit-drop コマンドを着信ダイヤルピア上で、および目的とするアウトオブバンド方式を発信ダイヤルピア上でそれぞれ構成します。そのようにしないと、同じディジットが OOB とインバンドで送信され、受信側端末では重複ディジットとして解釈されてしまいます。
ディジットドロップオプションが着信レッグで設定されている場合、CUBEはNTEパケットを抑制し、発信レッグで設定されたOOB方式を使用するディジットだけをリレーします。
この図に示すように、ディジットドロップ オプションは、これらの DTMF リレー方式の間でのインターワーキング時にのみ使用できます。
たとえば、RFC2833を介してディジットを送信するSIPレッグの着信ダイヤルピアでdtmf-relay rtp-nte digit-dropコマンドを設定してから、発信H.323側でdtmf-relay h245-alphanumericまたはdtmf-relay h245-signalのいずれかを設定します。これにより、CUBEでNTEパケットが抑制され、代OOBのH2H245イベントのみが送信されます。
詳細については、「DTMF リレーのディジット ドロップ」を参照してください。
DTMF リレーの検証およびトラブルシューティング
H323のOOB DTMFリレーの検証
H.245 Alphanumeric 機能のアドバタイズメント
エンドポイントが H.245 Alphanumeric 機能をアドバタイズしているかどうかを検査するには、debug h245 asn1 を使用して、H.245 Terminal Capability Set（TCS）メッセージ内からこの行を見つけます。
capability receiveUserInputCapability : basicString : NULL
H.245 Alphanumeric の送信例
次の例では、H245 Alphanumeric 方式を使用するディジット 1 を、debug h245 asn1 を使って送信するエンドポイントを示しています。
000510: Sep 28 19:02:02.716: H245 MSC OUTGOING PDU ::= value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1“
H.245 Signal 機能のアドバタイズメント
エンドポイントがH.245信号機能をアドバタイズしているかどうかを確認するには、debug h245 asn1を使用するH.245 Terminal Capability Set(TCS)メッセージ内でこの行を探します。
capability receiveUserInputCapability : dtmf : NULL
H.245 Signal の送信例
これは、H245 Signal 方式を使用して、100 msec の期間でディジット 1 を送信するエンドポイントの例です。2 つのメッセージがあり、最初のメッセージは期間が 4s でダイヤルされるディジットを示しています。ただし、2 番目のシグナル（signalUpdate）は、ディジットの期間の値を 100msec に更新します。
000555: Sep 28 19:12:05.364: H245 MSC OUTGOING PDU ::=
value MultimediaSystemControlMessage ::= indication : userInput : signal :
{
signalType "1"
duration 4000
}
000558: Sep 28 19:12:05.368: H245 MSC OUTGOING PDU ::=
value MultimediaSystemControlMessage ::= indication : userInput : signalUpdate :
{
duration 100
rtp
{
logicalChannelNumber 2
}
H323 のインバンド DTMF リレーの確認
H.323 V5を持つエンドポイントは、TerminalCapabilitySet(TCS)メッセージ内の機能メッセージによってRFC2833をサポートすることを示すことができます。
RFC2833機能サポートアドバタイズメント
エンドポイントがRFC2833機能をアドバタイズしているかどうかを確認するには、debug h245 asn1を使用するH.245 TCSメッセージ内でこの構造を探します（この例では、ペイロードタイプ101が0から16のイベントに対してアドバタイズされています）。
capabilityTableEntryNumber 34
capability receiveRTPAudioTelephonyEventCapability :
{
dynamicRTPPayloadType 101
audioTelephoneEvent "0-16"
}
SIP の OOB DTMF リレーの検証
Unsolicited NOTIFY（UN）のアドバタイズメントの例
エンドポイントが Unsolicited NOTIFY（UN）機能をアドバタイズしているかどうかを確認するには、debug ccsip messages を使用して、この行を INVITE メッセージの内部または INVITE への応答メッセージの内部（あるいはその両方）から見つけます。
INVITE sip:9999@192.168.106.66:5060 SIP/2.0 Call-Info: <sip:192.168.106.50:5060>;method="NOTIFY ;Event=telephone-event;Duration=2000“
Unsolicited NOTIFY（UN）の送信例
UN方式では、ディジットがNTFYメッセージ内でバイナリデータとして送信されるため、debug ccsip messagesを使用して、転送されているディジットを確認することはできません。バイナリデータ出力内の数字を確認するには、パケットキャプチャ(PCAP)が必要な場合と、debug ccsip allコマンドを実行する必要がある場合があります。
debug ccsip all コマンドの実行時に、ダイヤルされる同じディジット 7 がどのように表示されるかを示す例です。
001738: Oct 9 15:37:24.577: //-1/xxxxxxxxxxxx/SIP/Msg/sipDisplayBinaryData: Sending: Binary Message Body 001739: Oct 9 15:37:24.577: Content-Type: audio/telephone-event 07 00 07 D0 001756: Oct 9 15:37:24.577: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: NOTIFY sip:9999@192.168.106.66:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.106.50:5060;branch=z9hG4bK10E8E5C From: <sip:2010@192.168.105.189>;tag=557BFE8-9EE To: <sip:9999@192.168.106.66>;tag=cuecebad539 Call-ID: 87C4CAE-115E11E2-8184AAE4-EF882E8F@192.168.253.1 CSeq: 106 NOTIFY Event: telephone-event Subscription-State: active Contact: <sip:192.168.106.50:5060> Content-Type: audio/telephone-event Content-Length: 4 001763: Oct 9 15:37:24.593: //0/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 Ok Via: SIP/2.0/UDP 192.168.106.50:5060;branch=z9hG4bK10E8E5C To: <sip:9999@192.168.106.66>;tag=cuecebad539 From: <sip:2010@192.168.105.189>;tag=557BFE8-9EE Call-ID: 87C4CAE-115E11E2-8184AAE4-EF882E8F@192.168.253.1 CSeq: 106 NOTIFY Content-Length: 0 Allow-Events: refer Allow-Events: telephone-event Allow-Events: message-summary
Key Press Markup Language(KPML)A広告の例
KPML 機能は、Allow-Events SIP ヘッダー内にリストされます。KPMLディジット送信の場合、送信エンドポイントはまずKPMLサービスにサブスクリプションを送信する必要があります。SUBSCRIBEメッセージは機能を要求して送信され、続いて受信端末からのNOTIFYメッセージが送信され、KPMLイベントのサブスクリプション状態がアクティブとしてマーキングされます。
機能をアドバタイズする初期 INVITE。
INVITE sip:95554445001@192.168.105.25:5060 SIP/2.0 Allow-Events: kpml, telephone-event
受信側端末は、KMPL イベントへのサブスクリプションを要求します。
SUBSCRIBE sip:2010@192.168.106.50:5060 SIP/2.0 Event: kpml Content-Type: application/kpml-request+xml
発信側端末は、NOTIFY で応答し、状態をアクティブに設定します。
NOTIFY sip:192.168.105.25:5060 SIP/2.0 Event: kpml Subscription-State: active
KPML T転送の例
サブスクリプションが実施されたら、エンドポイントはディジットを、NOTIFY メッセージを使用して KPML イベントとともに XML によって送信できます。送信されるディジット 1 の例です。
NOTIFY sip:192.168.105.25:5060 SIP/2.0 Event: kpml <?xml version="1.0" encoding="UTF-8"?>
<kpml-response version="1.0" code="200" text="OK" digits="1" tag="dtmf"/>
DTMF インターワーキング
CUBE は、約 30 の異なるタイプの DTMF インターワーキングをサポートします。これは、コールの着信と発信の対のダイヤルピア内で設定された dtmf-relay コマンドに基づいて、さまざまなリレー方式間でのインターワーキングやトランスコードができます。
DTMFインターワーキングサポートの詳細については、『CUBE設定ガイド』の「DTMF相互運用性テーブル」セクションを参照してください。
CUBEがDTMFのトランスコーディングリソースを必要とする場合
CUBE は、これらのシナリオではローカルで登録されているリソースのトランスコードを必要とします。
- RFC2833 と音声インバンドとの間のインターワーキング
- フローアラウンド コールのための OOB 方式と RFC2833 の間のインターワーキング
CUBE は、トランスコーダを必要とせずに、フロースルー コールを行う他のすべての DTMF リレー方式の間でのインターワーキングができます。
インバンドG711とRFC2833間のDTMFインターワーキング
CUBE は、インバンド G711 DTMF（ロー オーディオ トーン）と RFC2833 との間のインターワーキングが可能です。ただし、次の要件が満たされている必要があります。
- 使用されるコーデックは G711 エンド ツー エンドでなければなりません。LBRコーデックを使用すると、圧縮損失によってトーンが歪められるため、これは制限です。
- これに応じて、CUBE ではリソースのトランスコーディングと登録が可能でなければなりません。これは、オーディオストリーム内でトーンをインジェクトまたはリッスンするために、CUBEがメディアRTPストリームにトランスコーディングリソース（具体的にはDSPリソース）を割り当てる必要があるためです。
- インバンドトーン レグのダイヤルピアには、DTMF リレー コマンドが設定されていてはなりません。この要件は、IOS XE 16.12.x以降では不要になりました。CUBEは、着信/ITSPダイヤルピアにdtmf-relay rtp-nteが設定されている場合でも、トランスコーダを動的に割り当てることができます。トランスコーダの割り当ての決定は、ピアデバイス間のSDPネゴシエーションによって異なります。
- RFC2833 レグのダイヤルピアには、dtmf-relay rtp-nte が設定されている必要があります。
- コールに関与しているダイヤルピアでは、ディジット ドロップは有効にしないでください。
他の DTMF インターワーキング オプション
特定のコールシナリオで必要になる可能性がある追加のインターワーキングコマンドセットもあります。これらのコマンドは、グローバルに、またはダイヤルピアレベルで設定できます。
dtmf-interworking {rtp-nte | standard | system}
rtp-nte Enables a delay between the dtmf-digit begin and dtmf-digit end events of RTP NTE packets.
Standard Generates RTP NTE packets that are RFC 4733 compliant.
System Specifies the default global DTMF interworking configuration. This keyword is available only in dial peer voice configuration mode.
MTPリソースがCUCMで必要とされる場合
MTP リソースが必要になるのは、CUCM が 2 つのデバイス間（一方が特に RFC2833 方式を使用し、他方が OOB 方式を使用する）での異なる DTMF 方式のインターワーキングを必要とする場合です。このシナリオでは、2 つの端末間で DTMF リレーの不一致があるため、CUCM は、インバンド トーンの送信または検出（あるいはその両方）を行うために必要なリソースを割り当てる必要があります。
MTP の役割は、RTP トラフィックをモニタして RFC2833 レグからの NTE イベントを検出したり、CUCM により要求された場合に NTE イベントを RTP ストリームに挿入したりすることです。MTPは、RFC2833のみをサポートするエンドポイントからの着信NTEイベントを検出すると、SCCP StationNOTIFYDtmfToneMessageをCUCMに送信し、ストリームで検出されたトーンを通知します。次に、CUCMは同じディジットを送信し、シグナリングプロトコル(OOB)を相手側に使用します。CUCM は、OOB DTMF エンドポイントから OOB DTMF シグナルを受信すると、SCCP StationSendDtmfToneMessage を MTP に送信し、MTP が要求されたトーンを NTE イベントの形式で RTP ストリームに挿入できるようにします。
CUCM でサポートされる MTP デバイス
ソフトウェア MTP（Cisco IP Voice Media Streaming Application）
ソフトウェア MTP とは、CUCM サーバ上で Cisco IP Voice Media Streaming Application を有効にすることによって実装されるデバイスです。インストールされたアプリケーションが、MTP アプリケーションとして設定されると、そのアプリケーションは、CUCM ノードに登録され、サポートする MTP リソース数を CUCM に知らせます。ソフトウェア MTP デバイスは、G.711 ストリームだけをサポートします。CUCM のデフォルト設定では、ソフトウェア MTP ごとに、最大 48 コールを処理できます。サービス パラメータの変更方法については、『Cisco Unified Communications Manager Administration Guide』の適切なバージョンを参照してください。
ソフトウェア MTP（Cisco IOS ベース）
この MTP によって、G.711 mu-law および a-law、G.729a、G.729、G.729ab、G.729b、およびパススルーのコーデックを設定できます。ただし、同時に設定できるコーデックは 1 つだけです。これらの内の一部のコーデックは、CUCM には実装されていません。
ルータ設定では最大 1,000 の個別ストリームが許可されます。これは 10 MB のトラフィックを生成する 500 のトランスコードされたセッションをサポートします。Cisco ISR G2 および ASR ルータでは、これよりもはるかに大きな数をサポートできます。
この MTP は、稼働する CPU のサイクルを消費します。有効にされたセッション数をメモに記録します。それは CPU のパフォーマンスに影響を及ぼし、CPU 使用率を引き上げる可能性があるからです。
ハードウェア MTP（PVDM2、Cisco NM-HDV2 および NM-HD-1V/2V/2VE）
このハードウェアは、PVDM-2 モジュールを使用して DSP を提供します。
ハードウェア MTP（PVDM3 を搭載した Cisco 2900 および 3900 シリーズ ルータ）
これらのルータでは、マザーボード上の PVDM3 DSP をネイティブに使用するか、またはマザーボード上やサービス モジュール上のアダプタによる PVDM2 を使用します。
ソフトウェアまたはハードウェアMTPを使用するケース
ネットワークに展開する MTP のタイプは、コール フロー内のエンドポイント、ゲートウェイ、およびトランクでサポートされる特定のコーデックのパラメータに応じて異なります。
- 使用されるコーデックのフレーバー
- 使用されるコーデックのパケット サイズ（パケット化）
- T.38 での FAX 使用（コーデックのパススルー サポートが必要）
これらのパラメータに基づいて、ネットワークで必要とされる適切なリソースを安全に選択して展開できます。
表に示すように、さまざまな機能が、さまざまな MTP およびトランスコーダのタイプによりサポートされます。
| Type |
サンプル コーデック |
さまざまなコーデック |
さまざまなパケット化 |
コーデック パススルー |
注意事項 |
| CUCM SW MTP |
Yes |
いいえ |
Yes |
いいえ |
G711 Alaw-Ulaw のトランスコーディングおよび再パケット化 |
| Cisco IOS HW MTP |
Yes |
いいえ |
いいえ |
Yes |
すべてのコーデック（および同じフレーバー）のサポート。ただし同じパケット化である場合に限ります。トランスコーディングなし。 |
| Cisco IOS SW MTP |
Yes |
いいえ |
いいえ |
Yes |
すべてのコーデック（および同じフレーバー）のサポート。ただし同じパケット化であることが条件です。トランスコーディングなし。 |
| Cisco IOS通常のXcoder |
Yes |
Yes |
Yes |
Yes |
少なくとも一方の側は、任意の再パケット化とトランスコーディングをサポートする G711u/G711a であることが条件です。 |
| Cisco IOSユニバーサルXcoder |
Yes |
Yes |
Yes |
Yes |
すべてのコーデック、パケット化、およびトランスコーディングでサポートされています。 |
CUCM での MTP 設定の詳細については、メディア ターミネーション ポイントの設定例を参照してください。
MTP の CUCM メディア リソース グループ（MRG）とメディア リソース グループ リスト（MRGL）の考慮事項
メディアリソースを作成し、メディアリソースグループ(MRG)とメディアリソースグループリスト(MRGL)に割り当てる際には、特定のコールフローに対する最適リソースのオーバーサブスクリプションを回避し、適切な優先順位を付けるために、いくつかの追加点を考慮する必要があります。CUCMがコールのメディアリソースを選択する際に、MTPとトランスコーダのリストから使用する最適なデバイスを選択できません（優先順位または順序が同じ場合）。代わりに、要求された機能をサポートする最初のデバイスを選択します。コールが両方のレグで G711 を使用している場合でも、検出する最初のデバイスがトランスコーダである場合は、それをコールに対して MTP として割り当て、それ以上はリストから MTP リソースを検索しません。
別の類似の動作は、ユニバーサルと通常の両方のトランスコーダがある場合に生じます。CUCM はまず、一方のレグが G711 であるコールで通常のトランスコーダを使用しますが、コールが非 G711 コーデックを使用する宛先に転送されると失敗することがあります。これは CUCM が現在のトランスコーダを解放せず、コールの転送時に別のトランスコーダを取得することが原因です。
この動作を回避するためのベストプラクティスは、1つのMRG内のすべてのMTP専用デバイスを割り当て、次にユニバーサルトランスコーダを別のMRGに、通常のトランスコーダを3番目のMRGに割り当て、MRGL内で同じ順序でそれらを優先順位付けすることです。現在、この設計はすべてのトポロジに対して機能するわけではなく、ケースバイベースでレビューする必要があります。
SCCP MTP メッセージ
これらのSCCPメッセージは、DTMF処理のためにCUCMとMTPリソースの間で交換されます。
- StationCapabilitiesRes
- StationUpdateCapabilities
- StationSubscribeDtmfPayloadReq
- StationSubscribeDTMFPayloadErrv
- StationSubscribeDtmfPayloadRes
- StationUnsubscribeDtmfPayloadErr
- StationNOTIFYDtmfToneMessage
- StationSendDtmfToneMessage
- StationUnsubscribeDtmfPayloadReq
- StationUnsubscribeDtmfPayloadRes
CUCMとCUBE間のDTMFリレー
CUBE への CUCM SIP トランク
CUBE は、その設定に応じて、DTMF メカニズムとして KPML、NTE、または Unsolicited Notify をサポートします。システムにはさまざまなエンドポイントが混在していることがあるため、複数の方式を CUBE に同時に設定することで、MTP の要件を最小限に抑えることができます。
CUBE では、SIP ダイヤルピアの DTMF リレー方式として、sip-kpml と rtp-nte の両方を設定します。このように設定すると、NTE だけをサポートするものや OOB 方式だけをサポートするものも含めて、すべてのタイプのエンドポイント間で MTP リソースなしに DTMF 交換を実現できます。この設定では、ゲートウェイは NTE と KPML の両方を CUCM とネゴシエートします。Unified CM のエンドポイントで NTE がサポートされていない場合は、DTMF 交換に KPML が使用されます。両方の方式のネゴシエーションが成功した場合、ゲートウェイは NTE を使用して番号を受信し、KPML へのサブスクライブは行いません。
CUBE では、DTMF に Unsolicited Notify（UN）方式を使用することもできます。UN 方式は、DTMF トーンを表すテキストをメッセージ本体に含む SIP Notify メッセージを送信します。この方式は Unified CM でもサポートされており、sip-kpml が有効でない場合に使用できます。DTMF リレー方式として sip-notify を設定します。この方式はシスコ独自のものである点に注意してください。
NTE リレー専用に設定された CUBE、または何らかのインターワーキング制限がある CUBE は、NTE しか提供できず、NTE をサポートしないエンドポイントとの通信時には、CUCM 側で MTP リソースを割り当てることが必要です。
CUCM の詳細については、「SIP トランク MTP の要件」を参照してください。
CUBE への CUCM H323 トランク
CUCMはH323トランクのDTMF転送方式を動的に選択するため、一方を選択する設定可能なオプションはありません。特定の DTMF リレー方式を適用するには、このトランクの CUBE ダイヤルピア設定から実行できます。
H323 CUBEがNTEをサポートする場合でも、NTEオプションは現時点ではH.323ゲートウェイ/トランクに対してCUCMでサポートされていないため、使用しないでください。そのため、CUCMはH245メディア機能が交換される時点でこの機能をアドバタイズしません。CUCM に適したオプションは H.245 Signal です。
他のエンドポイントにCUCMと共通のシグナリング機能がない場合、MTPリソースはH.323 CUBEへのコールを確立するために必要です。たとえば、SIPスタックを実行するCisco Unified IP Phone 7960はNTEのみをサポートするため、H245 AlphanumericをH323レッグで使用できるように、H.323トランクを使用するMTPが必要です。
CUBE 動的/非対称ペイロード
Cisco IOSバージョン15.1(1)T(CUBE 1.4)では、SIP間コールのDTMFおよびコーデックパケットに対するダイナミックペイロードタイプインターワーキングのサポートが導入されました。
この機能により、CUBEは音声/ビデオコーデック、NSEおよびDTMFのダイナミックペイロードタイプのインターワーキングを処理できます。Cisco IOSはスタティック範囲を予約し、両方のコールレッグで同じペイロードタイプのネゴシエーションのみを許可し、不一致の音声/ビデオ/NSEコーデックに対して488エラー応答でコールを拒否する（または音声インバンドG711 DTMFにフォールバックする）ため、この時点ではで制限制限制限されます。導入された機能により、CUBE は、異なる範囲のペイロード タイプを、それをサポートしない別のレグに使用したり、異なるマッピングを特別に必要としたりする SIP プロバイダーまたはサードパーティ デバイスとのインターワーキングのペイロード タイプを、動的に予約解除または解放できます。
CUBEのコールレッグは、エンドポイントとのオファーおよび応答時にSDPを介して交換されるペイロードタイプ値に基づいて、対称または非対称と見なされます。
- 対称エンドポイントは、NTE イベントやコール レッグの特定のコーデックの、同じペイロード タイプを受け入れたり送信したりします。
- 非対称エンドポイントは、NTE イベントやコール レッグの特定のコーデックの、異なるペイロード タイプを受け入れたり送信したりできます。
このコマンドは、非対称ペイロードの使用を指定するために使用できます。このコマンドは、voice service voip enter sip設定モードでグローバルに適用するか、voice-class sip CLIを使用してダイヤルピアレベルで適用できます
asymmetric payload {dtmf | dynamic-codecs | full | system}
動的/非対称ペイロードの詳細については、「SIP 間コールの DTMF とコーデック パケット用の動的ペイロード タイプ インターワーキング」を参照してください。
対称ペイロードの例
次に、対称ペイロードネゴシエーションの場合のSDPの表示や、DTMFトーン転送中のdebug voip rtp session named eventからの出力の例を示します。Cisco IOSを強制するために使用される設定では、rtp payload-type nteコマンドを使用するNTEイベントに対して異なるペイロードタイプを使用できることに注意してください。
DTMF リレーのネゴシエーション
DTMF リレー伝送
非対称ペイロードの例
次の例では、非対称ペイロードネゴシエーションの場合のSDPの表示や、DTMFトーン転送中のdebug voip rtp session named eventコマンドからの出力を示しています。Cisco IOSでNTEイベントに別のペイロードタイプを使用するように強制するために使用される設定と、rtp payload-type nteコマンドおよびvoice-class sip asymmetric payload dtmf CLIを使用することに注意してください。
DTMF リレーのネゴシエーション
DTMF リレー伝送
使用するDTMFリレー方式
使用するDTMFリレーを選択する際には、これらの変数を考慮する必要があります。
- 関連するデバイスとプラットフォーム。
- 関係する VoIP プロトコル.
- メディア パスおよびサポートされるコーデック.
- サポートされるまたは優先される DTMF リレー方式.
H.323の優先DTMFリレー方式
H323の推奨方法は、ほぼすべてのシナリオでH.245英数字または信号によるOOBを使用することです。CUCM が関与していない限り、RFC2833 も使用できます。
SIP の優先 DTMF リレー方式
- サービスプロバイダーへのSIPトランク – SIPプロバイダーへのSIPトランクが関係する場合、または3とのインタラクションがある場合rd RFC2833を介したインバンドでの使用が推奨されます。
- CUCM または CME への SIP トランク：RFC2833 と KPML の両方を有効にします。
- CUEへのSIPトランク：CUEのデフォルトの方式はUNですが、NTEを使用するように設定することもできます。これは、コールがSIPプロバイダーからCUEシステムに着信する場合の最適なオプションです。
関連情報
IP-to-IP ゲートウェイの Universal Voice Transcoding のサポート
Unified Border Element トランスコーディングの設定例
Cisco Unified Communications Manager を使用したトランスコーディングおよびメディア ターミネーション ポイントの設定
Cisco Unified Border Element 上での DTMF リレーのディジットドロップの設定
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
2.0 |
15-May-2023 |
代替テキストと背景情報が追加されました。
概要、ブランディング要件、SEO、機械翻訳、スタイル要件、言語、フォーマットの更新 |
1.0 |
30-Mar-2016 |
初版 |
フィードバック