DTMF中继与CUBE互通
目录
简介
本文档介绍为思科统一边界元素(CUBE)企业配置双音多频(DTMF)中继的过程。此外，它还提供了有关如何为CUBE支持的不同VoIP网关协议配置、验证DTMF中继并排除其故障的信息和命令。
作者：思科TAC工程师Michael Mendoza。
先决条件
要求
思科建议您了解这些主题
- DTMF音的基本知识
- 有关如何配置和使用Cisco IOS语音（如拨号对等体）的基本知识
- 有关如何配置和使用CUBE的基本知识
- SIP和H323协议使用的信令的基本知识
- 有关调试VoIP协议（如H323和SIP）的基本知识
使用的组件
本文档中的信息基于这些软件和硬件版本
- 在IOS上运行的思科统一边界元素
- 思科统一通信管理器7.x或更高版本
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。
规则
有关文档规则的信息，请参阅 Cisco 技术提示规则。
支持的CUBE DTMF中继方法
CUBE为H.323和会话初始协议(SIP)信令协议的带内和带外支持多种DTMF中继方法。
支持的带内DTMF中继方法
- 带内审计DTMF至G711
- RFC2833
支持的带外DMTF中继方法
- H.245字母数字
- H.245信号
- SIP未经请求的通知
- SIP KPML
- SIP信息
通过G711支持带内音频DTMF
语音带内音频或G711 DTMF是指通过语音音频流传输可听音音，除了正常设置呼叫和使用G711Ulaw/Alaw编解码器通过音频端到端传输外，无需信令协议或DSP的任何额外参与即可传输。这意味着CUBE/IOS仅将来自一端的音调的音频传递到另一端，就像它是普通语音音频一样。此方法需要采取的重要措施是确保使用G711Ulaw/Alaw编解码器建立呼叫，因为使用可压缩音频的编解码器（除G711之外的任何其他编解码器）会扭曲DTMF音，并可能使接收端无法识别这些呼叫。这是因为高压缩编解码器使用的压缩算法旨在识别和预测人类语音，而不是DTMF音。
带内音频/G711 DTMF受任何VoIP信令协议支持，并且只要求对端到端呼叫实施G711编解码器。还必须记住，从低比特率(LBR)编解码器到G711的任何转码处理都极有可能扭曲音调。
H323支持的DTMF中继方法
H.245字母数字
DTMF数字从语音流中分离，并通过H.245信令信道OOB发送，而不是通过RTP信道发送。这些音调以H.245用户输入指示消息传输。H.245信令信道是可靠信道，传输DTMF音的数据包将得到保证。所有符合H.323版本2的系统都需要支持dtmf-relay h245-amultic命令。但是，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编解码器端到端传递的纯音频音。
关于H323的NTE的其他一些有趣事实：
- H.323自V4起支持RFC2833
- 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消息在消息正文的负载内发送。
按键标记语言(KPML)
根据RFC4730，数字在订阅/通知消息中使用XML传输OOB。它主要用于注册到CUCM或CME的SIP终端，也用于ITSP。
信息（信息）
数字作为OOB SIP INFO消息在终端之间中继。此方法不需要任何配置，并且CUBE会自动接受和相关。
在CUBE上配置DTMF-Relay
默认情况下，H323和SIP拨号对等体（SIP信息除外）都禁用DTMF中继；必须在每个呼叫支路的入站和出站拨号对等体上配置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 SUBCRIBE/NOTIFY sip-NOTIFY DTMF Relay via SIP NOTIFY messages
配置DTMF中继数字丢弃
为了通过带内和带外方法将相同的DTMF数字中继到从带内（特别是RTP-NTE）到带外方法互通的呼叫的传出支路，以避免重复数字，请在入站拨号对等体上配置dtmf-relay rtp-nte digit-drop命令，并在外拨对等体上配置所需的带外方法。否则，同一数字将在OOB和带内发送，并被接收端解释为重复数字。
当在入站支路中配置了digit-drop选项时，CUBE使用在出站支路上配置的OOB方法抑制NTE数据包，并且仅中继数字。
如本图所示，只有在这些DTMF中继方法之间互通时，digit-drop选项才可用。
例如，在入站拨号对等体上为通过RFC2833发送数字的SIP支路配置dtmf-relay rtp-nte digit-drop命令，然后在出站H.323端配置dtmf-relay h245 — 字母数字或dtmf-relay h245-signal;这必须导致CUBE抑制NTE数据包，而只发送OOB H245事件。
有关详细信息，请参阅DTMF中继数字丢弃。
验证DTMF中继并排除故障
验证H323的OOB DTMF中继
H.245字母数字功能通告
要验证终端是否通告H.245字母数字功能，请在H.245终端功能集(TCS)消息中使用debug h245 asn1查找此行。
capability receiveUserInputCapability : basicString : NULL
H.245字母数字传输示例
以下是终端使用H245字母数字方法使用debug h245 asn1传输数字1的示例。
000510: Sep 28 19:02:02.716: H245 MSC OUTGOING PDU ::= value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1“
H.245信号功能广告
要确认终端是否通告H.245信号功能，请在H.245终端功能集(TCS)消息中使用debug h245 asn1查找此线路。
capability receiveUserInputCapability : dtmf : NULL
H.245信号传输示例
这是终端使用H245信号方法传输持续时间为100毫秒的数字1的示例。有两条消息，第一条消息表示正在拨叫的数字，持续时间为4秒。但是，第二信号(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功能，请在H.245 TCS消息中使用debug h245 asn1（在示例负载类型101为0到16的事件通告）查找此结构。
capabilityTableEntryNumber 34
capability receiveRTPAudioTelephonyEventCapability :
{
dynamicRTPPayloadType 101
audioTelephoneEvent "0-16"
}
验证SIP的OOB DTMF中继
未经请求的通知(UN)通告示例
要确认终端是否通告未经请求的通知(UN)功能，请在INVITE消息和/或响应消息中使用debug ccsip消息查找此行。
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: 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广告示例
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消息通过XML传输数字，并带有KPML事件。正在传输的数字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需要分配转码资源(具体而言：DSP资源)，以在音频流内注入或侦听音调。
- 带内音支路的拨号对等体不得配置任何DTMF中继命令。
- 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方法。在此场景中，CUCM需要分配必要的资源来传输和/或检测带内音，因为两端的DTMF中继不匹配。
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（思科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.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。
何时使用软件或硬件MTP?
要在网络中部署的MTP类型取决于呼叫流中的终端、网关和中继支持的特定编解码器参数
- 要使用的编解码器风格
- 要使用的编解码器数据包大小（分组）
- T.38传真使用（需要Codec Pass-Through支持）
根据这些参数，您可以安全地选择和部署网络所需的正确资源。
如表所示，不同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通用Xcoder |
Yes |
Yes |
Yes |
Yes |
支持任何编解码器、分组和转码。 |
有关CUCM中MTP配置的详细信息，请参阅媒体终端点配置示例。
CUCM媒体资源组(MRG)和媒体资源组列表(MRGL)MTP注意事项
在为媒体资源组(MRG)和媒体资源组列表(MRGL)创建和分配媒体资源时，请考虑一些附加点，以避免特定呼叫流的最佳资源超订用并相应地确定其优先级，因为CUCM无法从MTP和转码器的给定列表中选择用于呼叫的最佳设备。相反，它会选择支持所请求功能的第一台设备。因此，即使呼叫在两条支路上都使用G711，如果它找到的第一台设备是转码器，它也会将其分配为呼叫的MTP，而不会在列表中进一步查找MTP资源。
当同时具有通用和常规转码器时，会发生另一种类似行为。CUCM可以先在其中一条支路为G711的呼叫中使用常规转码器，然后在呼叫被转接到使用非G711编解码器的目的地时失败，因为CUCM不会释放当前转码器，在呼叫被转接时获取另一个转码器。
绕过此行为的最佳设计实践是将所有仅MTP的设备分配到单个MRG中，然后将通用转码器分配给另一个MRG，将常规转码器分配给第三个MRG;然后在MRGL中按相同顺序排定优先级。现在，此设计不能适用于每个拓扑，必须逐个案例进行审核。
SCCP MTP消息
这些SCCP消息在CUCM和MTP资源之间交换，用于DTMF处理
- StationCapabilitiesRes
- StationUpdateCapabilities
- StationSubscribeDtmfPayloadReq
- StationSubscribeDTMFPayloadErrv
- StationSubscribeDtmfPayloadRes
- StationUnsubscribeDtmfPayloadErr
- StationNOTIFYDtmfToneMessage
- StationSendDtmfToneMessage
- StationUnsubscribeDtmfPayloadReq
- StationUnsubscribeDtmfPayloadRes
到CUBE的CUCM SIP中继
CUBE支持KPML、NTE或未经请求的通知作为DTMF机制，具体取决于其配置。由于系统中可以混合使用终端，因此可以在CUBE上同时配置多种方法，以最大限度地降低MTP要求。
在CUBE上，在SIP拨号对等体下将sip-kpml和rtp-nte配置为DTMF中继方法。此配置支持与所有类型的终端进行DTMF交换，包括仅支持NTE的终端和仅支持OOB方法的终端，而无需MTP资源。通过此配置，网关与CUCM协商NTE和KPML。如果Unified CM终端不支持NTE，则KPML用于DTMF交换。如果两种方法都成功协商，则网关依赖NTE接收数字，不订阅KPML。
CUBE还能够对DTMF使用未经请求的通知(UN)方法。UN方法发送SIP通知消息，其正文包含描述DTMF音的文本。Unified CM也支持此方法，如果sip-kpml不可用，则可使用此方法。将sip-notify配置为DTMF中继方法。请注意，此方法是思科专有的。
仅为NTE中继配置的CUBE或由于某些互通限制而配置的CUBE，在与不支持NTE的终端通信时，只能提供NTE和在CUCM端分配所需的MTP资源。
您可以找到有关CUCM SIP中继MTP要求的详细信息
CUCM H323中继到CUBE
CUCM动态选择H323中继的DTMF传输方法；因此，没有可配置的选项可以选择一个选项，而不是另一个选项。如果要强制使用特定的DTMF中继方法，则可以通过此中继的CUBE拨号对等体配置执行此操作。
即使H323 CUBE支持NTE，也不得使用NTE选项，因为H.323网关/中继的CUCM目前不支持NTE选项；因此，CUCM在交换H245媒体功能时不会通告此功能。CUCM的首选选项是H.245信号。
如果其他终端没有与CUCM相同的信令功能，则建立对H.323 CUBE的呼叫需要MTP资源。例如，运行SIP堆栈的思科统一IP电话7960仅支持NTE，因此需要MTP与H.323中继，以便H323支路上可以使用H245字母数字。
CUBE动态/非对称负载
自IOS版本15.1(1)T(CUBE 1.4)开始，引入了对DTMF的动态负载类型互通和SIP到SIP呼叫的编解码器数据包的支持。
此功能允许CUBE处理以下交互操作：音频/视频编解码器、NSE和DTMF的动态负载类型；到此为止，由于IOS将保留静态范围，并且只允许在呼叫段上协商相同的负载类型，并且由于不匹配的音频/视频/NSE编解码器（或回退到带内语音G711 DTMF）而拒绝具有488错误响应的呼叫，因此NTE负载不匹配。因此，该功能允许CUBE动态地为与SIP提供商或第三方设备交互工作而取消保留或释放负载类型，这些设备使用不同范围的负载类型到不支持它们或需要特定映射的另一个支路。
CUBE上的呼叫段被视为对称或非对称，具体取决于在提供期间通过SDP交换的负载类型值，以及与终端的应答
- 对称终端接受并发送NTE事件的相同负载类型或呼叫段的特定编解码器。
- 非对称终端可以接受并发送不同的负载类型用于NTE事件或特定编解码器用于呼叫段。
此命令可用于指定非对称负载的使用；该命令可在语音服务voip进入sip配置模式下全局应用，也可在拨号对等体级别使用voice-class sip CLI应用
asymmetric payload {dtmf | dynamic-codecs | full | system}
有关动态/非对称负载的详细信息，请导航至DTMF的动态负载类型，以及SIP到SIP呼叫的编解码器数据包
对称负载示例
以下是SDP在传输DTMF音时的对称负载协商和debug voip rtp session named event的输出的示例。请注意，用于强制IOS的配置应使用rtp payload-type nte命令为NTE事件使用不同的负载类型。
DTMF中继协商
DTMF中继传输
非对称负载示例
以下是SDP在传输DTMF音时的非对称负载协商和debug voip rtp session named event命令的输出的示例。请注意使用rtp payload-type nte命令和语音类sip非对称负载dtmf CLI强制IOS对NTE事件使用不同负载类型的配置。
DTMF中继协商
DTMF中继传输
使用哪种DTMF中继方法？
选择要使用的DTMF中继时，需要考虑这些变量
- 涉及的设备和平台
- 涉及VoIP协议
- 媒体路径和支持的编解码器
- 支持或首选的DTMF中继方法
H.323的首选DTMF中继方法
H323的首选方法是在几乎所有场景中使用OOB通过H.245字母数字或信号。只要不涉及CUCM，您也可以使用RFC2833。
SIP的首选DTMF中继方法
- 到服务提供商的SIP中继 — 只要存在到SIP提供商的SIP中继，或与3交互第 首选参与方SIP设备或IVR系统，然后通过RFC2833进行带内。
- 到CUCM或CME的SIP中继 — 同时启用RFC2833和KPML。
- SIP中继到CUE - CUE的默认方法是UN，但您也可以将其配置为使用NTE;如果呼叫来自SIP提供商到CUE系统，则这也是最佳选项。
反馈