此产品的文档集力求使用非歧视性语言。在本文档集中,非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言,文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。
思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言,希望全球的用户都能通过各自的语言得到支持性的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任,并建议您总是参考英文原始文档(已提供链接)。
本文档介绍为Cisco Unified Border Element(CUBE)Enterprise配置双音多频(DTMF)中继的过程。
Cisco建议您了解这些主题。
本文档中的信息基于以下软件和硬件版本。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您的网络处于活动状态,请确保您了解所有命令的潜在影响。
有关文档规则的信息,请参阅 Cisco 技术提示规则。
本文档还提供有关如何为CUBE支持的不同VoIP网关协议配置、验证和排除DTMF中继故障的信息和命令。
CUBE支持用于H.323和会话发起协议(SIP)信令协议的带内和带外(OOB)的各种DTMF中继方法。
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传输,以及它是“带内”音频音时。务必说明应用正确配置和使用正确方法进行故障排除所需的/支持的实际方法。
DTMF数字与语音流分离,通过H.245信令信道OOB发送,而不是通过RTP信道发送。音调在H.245用户输入指示消息中传输。H.245信令信道是可靠的信道,传输DTMF音的数据包可以保证传输。所有符合H.323版本2的系统都需要支持dtmf-relay h245-alphanumeric命令。但是,可以选择是否支持dtmf-relay h245-signal命令。
类似于H.245字母数字的OOB方法允许传递音调持续时间信息,从而解决与其他供应商的系统交互工作时字母数字方法可能存在的问题。
根据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的其他事实:
使用此方法,DTMF音与语音数据在同一个RTP信道中发送。但是,DTMF音的编码与语音样本不同,并被标识为负载类型121,这使接收器能够将其标识为DTMF音。CUCM不支持此方法,已停止使用此方法。
带内RFC2833 NTE负载类型和属性在呼叫建立时两端之间协商,使用SIP消息正文部分中的会话描述协议(SDP)。
使用此方法,数字将作为消息正文负载内的SIP NOTIFY消息的OOB发送。
基于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。
默认情况下,H323和SIP拨号对等体均禁用DTMF中继(SIP INFO除外);对于每个呼叫段,必须将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
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选项变为可用。
为了通过从带内(具体是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中继数字丢弃。
要验证终端是否通告H.245字母数字功能,请使用debug h245 asn1在H.245终端功能集(TCS)消息中查找此行。
capability receiveUserInputCapability : basicString : NULL
以下是使用debug h245 asn1使用H245字母数字方法传输数字1的终端示例。
000510: Sep 28 19:02:02.716: H245 MSC OUTGOING PDU ::= value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1“
要确认终端是否通告H.245信号功能,请在使用debug h245 asn1的H.245 Terminal Capability Set(TCS)消息中查找此行。
capability receiveUserInputCapability : dtmf : NULL
这是一个终端使用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 }
具有H.323 V5的终端可以通过TerminalCapabilitySet(TCS)消息中的功能消息指示其支持RFC2833。
要确认终端是否正在通告RFC2833功能,请在使用debug h245 asn1(在示例中为从0到16的事件通告负载类型101)的H.245 TCS消息中查找此结构。
capabilityTableEntryNumber 34 capability receiveRTPAudioTelephonyEventCapability : { dynamicRTPPayloadType 101 audioTelephoneEvent "0-16" }
要确认终端是否正在通告未经请求的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方法在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
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
订用发生后,终端可以通过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"/>
CUBE支持大约30种不同类型的DTMF互通。它能够根据在匹配的呼叫入站和出站拨号对等体中配置的dtmf-relay命令,在不同中继方法之间进行互通和转码。
有关DTMF互通支持的详细信息,请参阅CUBE配置指南的DTMF互操作性表部分。
CUBE需要在这些场景中本地注册的代码转换资源
CUBE能够通过直通呼叫在所有其他DTMF中继方法之间互通,而无需转码器。
CUBE能够在Inband G711 DTMF(原始音频音)和RFC2833之间进行互通。但是,这些要求需要满足
此外,还可能需要在特定呼叫场景下使用一组额外互通命令;这些命令可在全局配置或在拨号对等体级别配置。
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需要在两个设备之间互通不同的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流。
软件MTP是通过在CUCM服务器上启用思科IP语音媒体流应用实现的设备。当安装的应用程序配置为MTP应用程序时,它会向CUCM节点注册,并通知CUCM它支持多少个MTP资源。软件MTP设备仅支持G.711数据流。CUCM的默认设置允许按每个软件MTP处理最多48个呼叫。有关如何修改服务参数的详细信息,请参阅相应版本的Cisco Unified Communications Manager管理指南。
此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利用率。
此硬件使用PVDM-2模块提供DSP。
这些路由器在主板上本地使用PVDM3 DSP,或者在主板或服务模块上使用带适配器的PVDM2。
注意:在Cisco IOS中配置硬件MTP资源时,无法配置G.729或G.729b。但是,如果所有其他MTP资源耗尽或不可用,Unified CM可将硬件转码资源用作MTP。
要在网络中部署的MTP类型取决于呼叫流中终端、网关和中继所支持的特定编解码器参数
根据这些参数,您可以安全地选择和部署您的网络所需的正确资源。
如表所示,不同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配置的详细信息,请参阅媒体终端点配置示例。
创建媒体资源并将其分配给媒体资源组(MRG)和媒体资源组列表(MRGL)时,请另外考虑一些要点,以避免为特定呼叫流超订用最佳资源并相应地排定优先级。如果CUCM从给定的MTP列表和转码器具有相同优先级或顺序,则在为呼叫选择媒体资源时,CUCM无法挑选最佳设备。相反,它会选择支持所请求功能的第一个设备。因此,即使呼叫在两个支路上都使用G711,如果它找到的第一台设备是转码器,那么它就会将其分配为呼叫的MTP,而不在列表中再进一步查找MTP资源。
当您同时具有通用和常规转码器时,也会发生类似行为。CUCM可以首先在呼叫中使用常规转码器,其中一条支路是G711,然后当呼叫被转接到使用非G711编解码器的目标时,CUCM会失败,因为CUCM不会释放当前转码器,而在呼叫被转接到另一个转码器时,CUCM会释放另一个转码器。
避免此行为的最佳设计做法是将所有仅MTP设备分配到单个MRG,然后通用转码器分配到另一个MRG,常规转码器分配到第三个MRG;然后在MRGL中按相同顺序排列这些设备的优先级。现在,此设计无法适用于每个拓扑,必须逐个进行审核。
这些SCCP消息在CUCM和MTP资源之间交换以进行DTMF处理。
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中继动态选择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字母数字。
自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交换的负载类型值。
此命令可用于指定非对称负载的使用;此命令可在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事件使用不同的负载类型。
以下示例展示非对称负载协商的SDP外观,以及传输DTMF音时debug voip rtp session named event命令的输出。请注意用于强制Cisco IOS对NTE事件使用不同负载类型的配置,并使用rtp payload-type nte命令和voice-class sip非对称负载dtmf CLI。
选择要使用的DTMF中继时,需要考虑这些变量。
H323的首选方法是使用OOB至H.245字母数字或信号,几乎在所有情况下。只要不涉及CUCM,您也可以使用RFC2833。
版本 | 发布日期 | 备注 |
---|---|---|
2.0 |
15-May-2023 |
添加了Alt Text和Background Info。
更新的简介、品牌要求、SEO、机器翻译、风格要求、简档和格式 |
1.0 |
30-Mar-2016 |
初始版本 |