目录

简介

先决条件

要求

使用的组件

规则

背景信息

CUBE支持的DTMF中继方法

支持的带内DTMF中继方法

支持的带外DMTF中继方法

支持带内音频DTMF至G711

H323支持的DTMF中继方法

H.245字母数字

H.245信号

命名电话事件(NTE)- RFC2833

思科专有RTP

SIP支持的DTMF中继方法

NTE - RFC2833

主动通知(UN)

按键标记语言(KPML)

信息（信息）

在CUBE上配置DTMF中继

配置H323的DTMF中继

为SIP配置DTMF中继

配置DTMF中继数字丢弃

验证DTMF中继并对其进行故障排除

验证H323的OOB DTMF中继

H.245字母数字功能通告

H.245字母数字传输示例

H.245信号能力通告

H.245信号传输示例

确认H323的带内DTMF中继

RFC2833功能支持通告

验证SIP的OOB DTMF中继

主动通知(UN)通告示例

主动通知(UN)传输示例

按键标记语言(KPML)通告示例

KPML传输示例

DTMF互通

CUBE何时需要DTMF的转码资源

带内G711与RFC2833之间的DTMF互通

其他DTMF互通选项

CUCM何时需要MTP资源

CUCM支持的MTP设备

软件MTP（CiscoIP语音媒体流应用）

软件MTP（基于CiscoIOS）

硬件MTP（PVDM2、Cisco NM-HDV2和NM-HD-1V/2V/2VE）

硬件MTP（带PVDM3的Cisco 2900和3900系列路由器）

何时使用软件或硬件MTP

MTP的CUCM媒体资源组(MRG)和媒体资源组列表(MRGL)注意事项

SCCP MTP消息

CUCM和CUBE之间的DTMF中继

CUCM SIP中继到CUBE

CUCM H323中继至CUBE

CUBE动态/非对称负载

对称负载示例

DTMF中继协商

DTMF中继传输

非对称负载示例

DTMF中继协商

DTMF中继传输

使用哪种DTMF中继方法

H.323的首选DTMF中继方法

SIP的首选DTMF中继方法

相关信息

简介

本文档介绍为Cisco Unified Border Element(CUBE)Enterprise配置双音多频(DTMF)中继的过程。

先决条件

要求

Cisco建议您了解这些主题。

- DTMF音调的基本知识

- 有关如何配置和使用Cisco® IOS语音（例如拨号对等体）的基本知识

- 了解如何配置和使用CUBE的基本知识

- 有关SIP和H323协议使用的信令的基本知识

- 有关如何调试H323和SIP等VoIP协议的基本知识

使用的组件

本文档中的信息基于以下软件和硬件版本。

- 在Cisco IOS上运行的思科统一边界元素。

- Cisco Unified Communications Manager 7.x或更高版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

规则

有关文档规则的信息，请参阅 Cisco 技术提示规则。

背景信息

本文档还提供有关如何为CUBE支持的不同VoIP网关协议配置、验证和排除DTMF中继故障的信息和命令。

CUBE支持的DTMF中继方法

CUBE支持用于H.323和会话发起协议(SIP)信令协议的带内和带外(OOB)的各种DTMF中继方法。

支持的带内DTMF中继方法

- 带内音频DTMF至G711

- RFC2833

支持的带外DMTF中继方法

- H.245字母数字

- H.245信号

- SIP主动通知

- SIP KPML

- SIP信息

支持带内音频DTMF至G711

Voice In-band audio或G711 DTMF是指通过语音音频流传输可听声音，除了正常设置呼叫和端对端传送音频并使用G711Ulaw/Alaw编解码器外，无需信令协议或DSP参与其传输。这意味着CUBE/Cisco IOS仅将音频从一端传递到另一端，就像正常语音音频一样。此方法的重要措施是确保呼叫建立并专门使用G711Ulaw/Alaw编解码器，因为使用压缩音频的编解码器（除G711以外的任何其他编解码器）会扭曲DTMF音调，并可能使其无法被接收端识别。这是因为高压缩编解码器使用的压缩算法旨在识别和预测人类语音而不是DTMF音。

任何VoIP信令协议都支持带内音频/G711 DTMF，并且仅要求为端到端呼叫实施G711编解码器。还必须记住，从低比特率(LBR)编解码器到G711的任何转码处理都很可能也会扭曲音调。

注意：讨论此DTMF中继方法时，经常会出现一些混淆，因为术语“带内”用于指代名为“命名电话事件”(NTE/RFC2833)的RTP流中的DTMF传输，以及它是“带内”音频音时。务必说明应用正确配置和使用正确方法进行故障排除所需的/支持的实际方法。

H323支持的DTMF中继方法

H.245字母数字

DTMF数字与语音流分离，通过H.245信令信道OOB发送，而不是通过RTP信道发送。音调在H.245用户输入指示消息中传输。H.245信令信道是可靠的信道，传输DTMF音的数据包可以保证传输。所有符合H.323版本2的系统都需要支持dtmf-relay h245-alphanumeric命令。但是，可以选择是否支持dtmf-relay h245-signal命令。

H.245信号

类似于H.245字母数字的OOB方法允许传递音调持续时间信息，从而解决与其他供应商的系统交互工作时字母数字方法可能存在的问题。

命名电话事件(NTE)- RFC2833

根据RFC 2833的第3部分，此方法可在单独的RTP数据包中传输DTMF音。RFC 2833定义了用于在两个对等终端之间传输DTMF数字、挂机闪存和其他电话事件的NTE RTP数据包格式。使用NTE方法，终端执行DTMF中继参数的每呼叫协商，以确定NTE RTP数据包和受支持的NTE数字事件的负载类型值。因此，DTMF音通过RTP分组进行通信，其负载类型值不同于为其他媒体分组协商的值；这提供了一种可靠的方法来传输数字，并避免当数字通过用于对语音、视频或传真流量进行编码的编解码器进行压缩时无法识别它们。

RFC2833/NTE DTMF中继被视为带内方法，因为数字在RTP音频流量自身内传输，不涉及GW信令协议。

必须指出的是，RFC2833/NTE方法不能与语音带内音频或G711 RTP流混淆，因为后者只是作为普通音频传递的可听音，而没有任何中继信令方法感知或参与该过程。这意味着它们只是使用G711Ulaw/Alaw编解码器端到端传递的普通音频音。

有关NTE与H323的其他事实：

- H.323支持RFC2833（自V4起）

- Cisco IOS始终在TCS中通告其2833支持

- CUCM仅通过H.323 ICT支持NTE。

思科专有RTP

使用此方法，DTMF音与语音数据在同一个RTP信道中发送。但是，DTMF音的编码与语音样本不同，并被标识为负载类型121，这使接收器能够将其标识为DTMF音。CUCM不支持此方法，已停止使用此方法。

SIP支持的DTMF中继方法

NTE - RFC2833

带内RFC2833 NTE负载类型和属性在呼叫建立时两端之间协商，使用SIP消息正文部分中的会话描述协议(SDP)。

主动通知(UN)

使用此方法，数字将作为消息正文负载内的SIP NOTIFY消息的OOB发送。

按键标记语言(KPML)

基于RFC4730，数字在Subscribe/NOTIFY消息中使用XML进行OOB传输。它主要用于注册到CUCM或CME的SIP终端，也用于ITSP。

信息（信息）

数字在两端之间作为OOB SIP INFO消息中继。此方法不需要任何配置，并由CUBE自动接受和关联。

注意：Unified CM不支持SIP INFO。

注：当协商了UN和NTE方法时，Cisco IOS始终选择UN而不是NTE以避免双音，并抑制带内2833 NTE数据包。此外，对于CUCM，仅在没有其它可用选项时使用UN。同样，如果KPML和UN都存在，Cisco Call Manager(CCM)会选择KPML而不是UN。

在CUBE上配置DTMF中继

默认情况下，H323和SIP拨号对等体均禁用DTMF中继（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

注意：在dial-peer下添加session protocol sip命令，使SIP dtmf-relay选项变为可用。

配置DTMF中继数字丢弃

为了通过从带内（具体是RTP-NTE）到带外方法的呼叫互通将相同的DTMF数字通过带内和带外方法中继到传出支路，以避免重复数字，请在入站拨号对等体上配置dtmf-relay rtp-nte digit-drop命令，在传出拨号对等体上配置所需的带外方法。否则，同一个数字既在OOB中发送，也在带内发送，接收端将其解释为重复数字。

在入站分支中配置digit-drop选项时，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 H245事件。

有关详细信息，请参阅DTMF中继数字丢弃。

验证DTMF中继并对其进行故障排除

验证H323的OOB DTMF中继

H.245字母数字功能通告

要验证终端是否通告H.245字母数字功能，请使用debug h245 asn1在H.245终端功能集(TCS)消息中查找此行。

capability receiveUserInputCapability : basicString : NULL

H.245字母数字传输示例

以下是使用debug h245 asn1使用H245字母数字方法传输数字1的终端示例。

000510: Sep 28 19:02:02.716: H245 MSC OUTGOING PDU ::=

value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1“

H.245信号能力通告

要确认终端是否通告H.245信号功能，请在使用debug h245 asn1的H.245 Terminal Capability Set(TCS)消息中查找此行。

capability receiveUserInputCapability : dtmf : NULL

H.245信号传输示例

这是一个终端使用H245信号方法传输持续时间为100毫秒的数字1的示例。有两条消息，第一条消息表示拨打的号码的持续时间为4s。但是，第二个信号(signalUpdate)将数字持续时间值更新为100毫秒。

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（在示例中为从0到16的事件通告负载类型101）的H.245 TCS消息中查找此结构。

capabilityTableEntryNumber 34

capability receiveRTPAudioTelephonyEventCapability :

{

dynamicRTPPayloadType 101

audioTelephoneEvent "0-16"

}

验证SIP的OOB DTMF中继

主动通知(UN)通告示例

要确认终端是否正在通告未经请求的NOTIFY(UN)功能，请使用debug ccsip消息在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“

主动通知(UN)传输示例

UN方法在NTFY消息内以二进制数据形式传输数字；因此您无法看到使用debug ccsip消息传输的是什么数字。您可能需要数据包捕获(PCAP)，或者必须运行debug ccsip all命令才能查看二进制数据输出中的数字。

运行debug ccsip all命令时相同数字7的拨号方式示例。

001738: Oct  9 15:37:24.577: //-1/xxxxxxxxxxxx/SIP/Msg/sipDisplayBinaryData&colon;

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

按键标记语言(KPML)A部署示例

Allow-Events SIP报头中列出了KPML功能。对于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传输示例

订用发生后，终端可以通过XML使用包含KPML事件的NOTIFY消息传输数字。正在传输的数字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能够在Inband G711 DTMF（原始音频音）和RFC2833之间进行互通。但是，这些要求需要满足

- 使用的编解码器必须是G711端到端。这是一个限制，因为如果使用LBR编解码器，则由于压缩丢失，音调会失真。

- 代码转换资源必须可用并相应地向CUBE注册。这是因为CUBE需要将转码资源（更具体地说，是DSP资源）分配给媒体RTP流，以插入或侦听音频流中的音调。

- 带内拨号线路的拨号对等体不能配置任何DTMF中继命令。IOS XE 16.12.x或更高版本不再需要此要求。即使入站/ITSP拨号对等体配置了dtmf-relay rtp-nte，CUBE也可以动态分配转码器。分配转码器的决定取决于对等设备之间的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.

CUCM何时需要MTP资源

当CUCM需要在两个设备之间互通不同的DTMF方法时，MTP资源变得必要，其中一个设备具体使用RFC2833方法，另一个设备使用OOB方法。在这种情况下，由于两端之间的DTMF中继不匹配，CUCM需要分配必要的资源来传输和/或检测带内音。

MTP的角色是监控RTP流量并检测来自RFC2833支路的NTE事件，或者在CUCM请求时将NTE事件注入RTP流。如果MTP检测到来自仅支持RFC2833的终端的入站NTE事件，则它会向CUCM发送SCCP StationNOTIFYDtmfToneMessage，并通知它流中检测到的音。CUCM反过来发送相同的数字并使用信令协议(OOB)到另一端。如果CUCM收到来自OOB DTMF终端的OOB DTMF信号，则它向MTP发送SCCP StationSendDtmfToneMessage，以便MTP可以以NTE事件的形式将请求的音频注入RTP流。

CUCM支持的MTP设备

软件MTP（Cisco IP语音媒体流应用）

软件MTP是通过在CUCM服务器上启用思科IP语音媒体流应用实现的设备。当安装的应用程序配置为MTP应用程序时，它会向CUCM节点注册，并通知CUCM它支持多少个MTP资源。软件MTP设备仅支持G.711数据流。CUCM的默认设置允许按每个软件MTP处理最多48个呼叫。有关如何修改服务参数的详细信息，请参阅相应版本的Cisco Unified Communications Manager管理指南。

软件MTP（基于Cisco IOS）

此MTP允许配置这些编解码器中的任何一个，但在给定时间只能配置一个G.711 mu-law和a-law、G.729a、G.729、G.729ab、G.729b和直通。其中一些与CUCM实施无关。

路由器配置最多允许1,000个独立数据流，支持500个转码会话（生成10 MB流量）。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。

注意：在Cisco IOS中配置硬件MTP资源时，无法配置G.729或G.729b。但是，如果所有其他MTP资源耗尽或不可用，Unified CM可将硬件转码资源用作MTP。

何时使用软件或硬件MTP

要在网络中部署的MTP类型取决于呼叫流中终端、网关和中继所支持的特定编解码器参数

- 要使用的编解码器风格

- 要使用的编解码器数据包大小（打包）

- T.38传真使用（需要编解码器直通支持）

根据这些参数，您可以安全地选择和部署您的网络所需的正确资源。

如表所示，不同MTP和转码器类型支持的不同功能

类型

相同的编解码器

不同的编解码器

不同的打包

编解码器

直通

备注

CUCM软件MTP

Yes

无

Yes

无

G711 Alaw-Ulaw转码和重新打包

思科IOS硬件MTP

Yes

无

无

Yes

支持任意编解码器（和相同风格），只要打包相同。没有转码。

思科IOS软件MTP

Yes

无

无

Yes

支持任意编解码器（和相同风格），只要具有相同的打包效果。没有转码。

思科IOS常规Xcoder

Yes

Yes

Yes

Yes

只要至少一端是G711u/G711a，就支持任何重打包和转码。

思科IOS通用编码器

Yes

Yes

Yes

Yes

支持任何编解码器、打包和转码。

有关CUCM中MTP配置的详细信息，请参阅媒体终端点配置示例。

MTP的CUCM媒体资源组(MRG)和媒体资源组列表(MRGL)注意事项

创建媒体资源并将其分配给媒体资源组(MRG)和媒体资源组列表(MRGL)时，请另外考虑一些要点，以避免为特定呼叫流超订用最佳资源并相应地排定优先级。如果CUCM从给定的MTP列表和转码器具有相同优先级或顺序，则在为呼叫选择媒体资源时，CUCM无法挑选最佳设备。相反，它会选择支持所请求功能的第一个设备。因此，即使呼叫在两个支路上都使用G711，如果它找到的第一台设备是转码器，那么它就会将其分配为呼叫的MTP，而不在列表中再进一步查找MTP资源。

当您同时具有通用和常规转码器时，也会发生类似行为。CUCM可以首先在呼叫中使用常规转码器，其中一条支路是G711，然后当呼叫被转接到使用非G711编解码器的目标时，CUCM会失败，因为CUCM不会释放当前转码器，而在呼叫被转接到另一个转码器时，CUCM会释放另一个转码器。

避免此行为的最佳设计做法是将所有仅MTP设备分配到单个MRG，然后通用转码器分配到另一个MRG，常规转码器分配到第三个MRG；然后在MRGL中按相同顺序排列这些设备的优先级。现在，此设计无法适用于每个拓扑，必须逐个进行审核。

SCCP MTP消息

这些SCCP消息在CUCM和MTP资源之间交换以进行DTMF处理。

- 站点功能

- 站点更新功能

- StationSubscribeDtmfPayloadReq

- StationSubscribeDTMFPayloadErrv

- StationSubscribeDtmfPayloadRes

- StationUnsubscribeDtmfPayloadError

- StationNOTIFYDtmfToneMessage

- StationSendDtmfToneMessage

- StationUnsubscribeDtmfPayloadReq

- StationUnsubscribeDtmfPayloadRes

CUCM和CUBE之间的DTMF中继

CUCM SIP中继到CUBE

CUBE支持KPML、NTE或主动通知作为DTMF机制，具体取决于其配置。由于系统中可以混合终端，因此可以同时在CUBE上配置多种方法以最小化MTP要求。

在CUBE上，将sip-kpml和rtp-nte都配置为SIP拨号对等体下的DTMF中继方法。此配置支持与所有类型的终端（包括仅支持NTE的终端和仅支持OOB方法的终端）进行DTMF交换，无需MTP资源。使用此配置，网关将与CUCM协商NTE和KPML。如果Unified CM终端不支持NTE，则将KPML用于DTMF交换。如果两个方法都成功协商，则网关依赖于NTE来接收数字，并且不订阅KPML。

CUBE还能够对DTMF使用主动通知(UN)方法。UN方法发送包含描述DTMF音的文本的SIP通知消息。Unified CM上也支持此方法，如果sip-kpml不可用，则可以使用此方法。将sip-notify配置为DTMF中继方法。请注意，此方法是Cisco专有的。

配置为仅NTE中继的CUBE，或者由于某些互通限制，在与不支持NTE的终端通信时，只能在CUCM端提供NTE和需要的MTP资源。

有关CUCM SIP中继MTP要求的详细信息

CUCM H323中继至CUBE

CUCM会为H323中继动态选择DTMF传输方法；因此，没有可配置的选项可以选择一个而不是另一个。如果要强制使用特定的DTMF中继方法，则可以通过此中继的CUBE拨号对等体配置执行此操作。

即使H323 CUBE支持NTE，也不得使用NTE选项，因为目前在H.323网关/中继的CUCM上不支持该选项；因此，在交换H245媒体功能时，CUCM不会通告该功能。CUCM的首选选项是H.245 Signal。

如果另一个终端没有与CUCM相同的信令功能，则需要使用MTP资源来建立对H.323 CUBE的呼叫。例如，运行SIP堆栈的Cisco Unified IP电话7960仅支持NTE，因此需要使用H.323中继的MTP，以便H323支路可以使用H245字母数字。

CUBE动态/非对称负载

自Cisco IOS版本15.1(1)T(CUBE 1.4)开始，引入了对用于DTMF的动态负载类型互通和用于SIP到SIP呼叫的编解码器数据包的支持。

此功能允许CUBE处理以下交互操作：音频/视频编解码器、NSE和DTMF的动态负载类型；由于思科IOS将保留静态范围，并且仅允许在呼叫段上协商相同负载类型，并拒绝对不匹配的音频/视频/NSE编解码器使用488错误响应的呼叫（或回退到带内语音G711 DTMF）的NTE负载。因此，此功能允许CUBE动态取消保留或释放负载类型，以便与SIP提供商或第三方设备互通，后者使用不同范围的负载类型连接到不支持它们或需要特定不同映射的另一个分支。

CUBE上的呼叫支路被视为对称或非对称，具体取决于在与终端进行提议和应答期间通过SDP交换的负载类型值。

- 对称终端接受并发送NTE事件的相同负载类型或呼叫段的特定编解码器。

- 非对称终端可以接受和发送NTE事件的不同负载类型或呼叫段的特定编解码器。

此命令可用于指定非对称负载的使用；此命令可在voice service voip enter sip配置模式下全局应用，也可以使用voice-class sip CLI在拨号对等体级别应用

asymmetric payload {dtmf | dynamic-codecs | full | system}

有关动态/非对称负载的详细信息，请导航到DTMF的动态负载类型交互作用和SIP到SIP呼叫的编解码器数据包

对称负载示例

下面是一个示例，说明在传输DTMF音时，SDP对于对称负载协商和名为event的debug voip rtp session的输出。请注意，用于强制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非对称负载dtmf CLI。

DTMF中继协商

DTMF中继传输

使用哪种DTMF中继方法

选择要使用的DTMF中继时，需要考虑这些变量。

- 涉及的设备和平台。

- 涉及的VoIP协议。

- 媒体路径和支持的编解码器。

- 支持或首选的DTMF中继方法。

H.323的首选DTMF中继方法

H323的首选方法是使用OOB至H.245字母数字或信号，几乎在所有情况下。只要不涉及CUCM，您也可以使用RFC2833。

SIP的首选DTMF中继方法

- 到服务提供商的SIP中继 — 只要存在与SIP提供商相关的SIP中继或与3的交互rd 第1方SIP设备或IVR系统，则首选带内至RFC2833。

- 到CUCM或CME的SIP中继 — 同时启用RFC2833和KPML。

- SIP中继到CUE - CUE的默认方法是UN，但您也可以将其配置为使用NTE；如果呼叫来自SIP提供商到CUE系统，这也是最佳选项。

相关信息

IP到IP网关的通用语音转码支持

DTMF转换

统一边界网元转码的配置示例

使用Cisco Unified Communications Manager配置转码和媒体终端点

在思科统一边界要素上配置DTMF中继数字丢弃

SIP中继MTP要求

DTMF音频生成的SIP INFO方法

具有媒体终端点的H.323中继

CUBE 9.0本地转码接口(LTI)