DTMF中继和相互作用在多维数据集
目录
简介
本文描述进程配置Cisco Unified Border Element (多维数据集)企业的Dual Tone Multi-frequency (DTMF)中继。另外，它也提供信息和on命令如何配置，验证和排除故障多维数据集支持的不同的VoIP网关协议的DTMF中继。
贡献用迈克尔Mendoza， Cisco TAC工程师。
先决条件
要求
思科建议您有这些主题知识
- DTMF音基础知识
- 基础知识如何配置和使用Cisco IOS语音(例如dial-peer)
- 基础知识如何配置和使用多维数据集
- SIP和H323协议使用的信令的基础知识
- 基础知识如何调试VoIP协议类似H323和SIP
使用的组件
本文档中的信息根据这些软件和硬件版本
- 在IOS运行的Cisco Unified Border Element
- Cisco Unified Communications Manager 7.x或以上
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。
规则
有关文档规则的信息，请参阅 Cisco 技术提示规则。
多维数据集的支持的dtmf-relay方法
求支持的立方带内和OOB的(带外)各种各样的DTMF中继方法H.323和会话初始化协议(SIP)信令协议的。
支持的在波段之内DTMF中继方法
- 在波段之内audtio DTMF通过G711
- RFC2833
支持的带外DMTF中继方法
- H.245字母数字
- H.245信号
- 未经请求的SIP通知
- SIP KPML
- SIP INFO
在波段之内音频DTMF的支持通过G711
使用G711Ulaw/Alaw编码，语音在波段之内音频或G711 DTMF是指可闻信号音传输在语音音频流的，不用信令协议的任何另外的介入或他们的发射的DSP除之外通常设置呼叫和通过音频端对端。这意味着CUBE/IOS只通过来自一端的音的音频到其他，好象它正常语音音频。重要测量为此方法采取是保证呼叫特别地被设立使用G711Ulaw/Alaw编码，因为曾经将压缩音频的编码(其他编码比G711)扭曲DTMF音并且是可能使他们无法认出对接收端。这是因为高压缩编码使用的压缩算法设计认可和预测而不是人的语音DTMF音。
在波段之内audio/G711 DTMF支持与所有VoIP信令协议和只要求为呼叫将强制执行的G711编码端到端。一必须必须也记住从低比特率(LBR)编码的所有转码处理到G711很可能扭曲音。
H323的支持的dtmf-relay方法
H.245字母数字
DTMF位从语音流被分离并且通过H.245信令信道OOB发送而不是发送通过RTP信道。音在H.245用户输入征兆消息传输。H.245信令信道是一个可靠信道，并且传输DTMF音的数据包保证传送。是H.323版本2-compliant的所有系统要求支持dtmf-relay h245-alphanumeric命令。然而，支持dtmf-relay h245-signal命令可选。
H.245信号
类似于H.245字母数字的OOB方法允许涉及音时长信息的段落，从而与字母数字方法的一个潜在问题，当相互作用用其他供应商的系统时。
已命名Telephony Events (NTE) - RFC2833
此方法根据RFC 2833的第3部分传输在独立的RTP数据包的DTMF音。RFC 2833定义了NTE用于的RTP数据包格式传输DTMF位，连接闪存和其他电话事件在两个对等体终端之间。使用NTE方法，终端执行DTMF中继参数的每呼叫协商确定NTE RTP数据包和支持的NTE位事件的有效载荷类型值。结果， DTMF音通过有有效载荷类型值的RTP数据包被传达与为其他媒体数据包协商的值不同;哪提供传输位和避免他们的可靠方法不被识别，当他们压缩通过用于的编码编码语音、视频或者传真流量。
因为位在RTP音频数据流内传输，不用GW信令协议的任何介入， RFC2833/NTE DTMF中继认为一个在波段之内方法。
指出是重要的不能与语音在波段之内音频或G711 RTP数据流混淆RFC2833/NTE方法，因为越以后通过，正常音频，不用任何中继信令方法的可闻信号音意识或介入进程。意味着他们是无格式音频音通过的端到端使用G711Ulaw/Alaw编码。
关于NTE的一些其他有趣的事实与H323 ：
- H.323自V4的支持RFC2833
- IOS总是通告其在TCS的2833支持
- CUCM通过H.323 ICT只支持NTE。
思科业主RTP
使用此方法DTMF音在RTP信道被发送和语音数据一样。然而， DTMF音编码与语音示例不同和识别作为有效载荷类型121，使接收方识别他们作为DTMF音。CUCM不支持此方法，并且其使用被中断了。
SIP的支持的dtmf-relay方法
NTE - RFC2833
在波段之内RFC2833 NTE有效载荷类型和属性在SIP消息的正文部分内协商在呼叫建立的二末端之间使用会话描述协议(SDP)。
未经请求的请通知(联合国)
使用此方法，因为SIP通知在消息主题的有效负载的内，消息位是发送的OOB。
关键按标记语言(KPML)
使用在Subscribe/NOTIFY消息内的XML凭RFC4730，位是传输的OOB。它主要使用SIP终端注册对CUCM或CME，而且与ITSPs。
信息(INFO)
位中继作为OOB SIP在末端之间的INFO消息。此方法不要求任何配置和由多维数据集自动地接受并且涉及。
配置dtmf-relay在多维数据集
默认情况下， DTMF中继为H323和SIP dial-peer禁用(除了SIP INFO);配置DTMF中继方法是使用的端到端在每个呼叫段的两个Inbound和Outbound Dial Peer是必须的。
配置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
您能根据终止的末端的需求配置超过每dial-peer一个方法。
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
您能根据终止的末端的需求配置超过每dial-peer一个方法。
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位丢弃on命令呼入拨号对端和希望的带外方法在流出拨号对等体。否则，同一个位在作为重复的位以及带内和获得解释的OOB发送由接收端。
当位丢弃选项在入站段时配置，多维数据集抑制NTE数据包和仅中继位使用在出站段配置的OOB方法。
如此镜像所显示，位丢弃选项是可用的，只有当相互作用在这些DTMF中继方法之间时。
例如，请配置dtmf-relay RTP NTE位丢弃on命令发送位的SIP段的呼入拨号对端通过RFC2833在出站H.323侧然后请配置dtmf-relay h245-alphanumeric或dtmf-relay h245-signal;这必须导致抑制NTE数据包的多维数据集和派出仅OOB H245事件。
欲知更多信息请参阅DTMF中继位丢弃。
验证并且排除故障DTMF中继
验证H323的OOB DTMF中继
H.245字母数字功能通告
为了验证终端是否通告H.245字母数字功能，请寻找此线路在H.245终端的功能集合(TCS)使用debug h245 asn1，消息里面。
capability receiveUserInputCapability : basicString : NULL
H.245字母数字发射示例
这是传送位1的终端的示例使用H245字母数字方法使用debug h245 asn1。
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信号发射示例
这是传送有100毫秒的持续时间的终端的示例位1使用H245信号方法。有两个消息，第一条消息指示拨号与4s的持续时间的位。然而，第二个信号(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中继
未经请求的请通知(联合国)广告示例
为了确认终端是否通告未经请求的请通知(联合国)使用调试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“
未经请求的请通知(联合国)发射示例
联合国方法传送位作为二进制数据在NTFY消息里面;不会如此您能发现通过使用调试ccsip消息，什么位传输。您或者将需要数据包捕获(PCAP)或必须运行all命令调试的ccsip发现在二进制数据输出内的位。
示例7拨号的同一个位如何将看起来象当运行all命令调试的ccsip。
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)广告示例
KPML功能在允许事件SIP报头内是列出的。对于KPML位发射，传送的终端需要首先发送订阅到KPML服务;订阅请求功能的消息传送;跟随由从指示KPML事件的接收端的一个通知消息订阅状态作为激活。
初始邀请通告功能。
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 sip:192.168.105.25:5060 SIP/2.0 Event: kpml Subscription-State: active
KPML发射示例
在订阅发生了后，终端能传送位使用通过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
在相互作用30的不同种类的DTMF附近求支持的立方。能相互作用和转码根据dtmf-relay命令已配置的区别中继方法之间在呼叫的匹配的Inbound和Outbound Dial Peer内。
参考多维数据集配置指南的DTMF互通性表部分关于在相互作用支持的DTMF的详细信息。
多维数据集什么时候要求DTMF的转码资源？
多维数据集要求在这些情况下注册的转码资源本地
- 相互作用在RFC2833和语音带内之间
- 相互作用在一个OOB方法和RFC2833之间流在呼叫附近的
没有代码转换器的需要，多维数据集能相互作用在与直通业务呼叫的其他DTMF中继方法之间。
相互作用在带内G711之间的DTMF对RFC2833
多维数据集能相互作用在带内G711 DTMF (原始音频音)之间到RFC2833。然而，这些需求需要符合
- 使用的编码必须是端到端的G711。这是限制，因为，如果将然后使用LBR编码音将获得误解的由于压缩损耗。
- 转码的资源一定相应地取得到和已注册与多维数据集。这，因为多维数据集需要指定转码资源(特别地：一种DSP资源)对注入或细听在音频流内的音的媒体RTP数据流。
- 带内音段的dial-peer不能有其中任一dtmf relay命令已配置的。
- RFC2833段的dial-peer必须安排dtmf-relay RTP NTE配置。
- 请勿启用在的位丢弃任何dial-peer参与呼叫。
相互作用选项的其他DTMF
也有其他设置在特定呼叫情形可能要求的相互作用命令;哪些可以配置全局或在dial-peer级别。
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需要特别地相互作用在两个设备，他们中的一个使用RFC2833方法和其他之间的不同的DTMF方法OOB方法。在此方案， CUCM需要指定必要的资源传送并且/或者检测带内音由于二末端之间的DTMF中继不匹配。
MTP的角色是监控RTP流量，并且检测从RFC2833段的NTE事件或注入NTE事件RTP由CUCM放出，如果请求的。如果MTP检测只支持RFC2833那么从终端的入站NTE事件它发送SCCP StationNOTIFYDtmfToneMessage对通知在数据流检测的它的CUCM音。CUCM反过来发送同一个位使用信令协议(OOB)对另一端。如果CUCM收到从OOB DTMF终端的一个OOB DTMF信号那么发送SCCP StationSendDtmfToneMessage对MTP以NTE事件的形式，以便MTP能注入请求的音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律、G.729a， G.729、G.729ab、G.729b和转接。其中一些对CUCM实施不是有关的。
路由器配置允许1,000各自的数据流，支持500转码的会话生成10兆字节流量。Cisco ISR G2s和ASR路由器比此可以支持显着大数字。
此MTP消耗CPU周期运行。记录下来作为它启用的会话数量可能影响CPU性能和触发高CPU利用率。
硬件MTP (PVDM2、思科NM-HDV2和NM-HD-1V/2V/2VE)
此硬件使用PVDM-2模块提供DSP。
硬件MTP (Cisco 2900和3900系列路由器有PVDM3的)
这些路由器在主板或PVDM2本地使用PVDM3 DSP用一台适配器在主板或在服务模块。
什么时候使用软件或硬件MTP ？
部署的MTP种类在您的网络取决于终端、网关和中继支持的特定编码参数在呼叫流
- 将使用的编码类似
- 将使用的编码数据包大小(封包化)
- 电传使用情况的T.38 (要求编码转接支持)
基于这些参数您能通过您的网络安全选择和部署正确需的资源。
如表所显示，不同的MTP和代码转换器类型支持的不同的功能
| 类型 |
同样编码 |
不同的编码 |
另外封包化 |
编码 转接 |
备注 |
| CUCM SW MTP |
是 |
无 |
是 |
无 |
G711 ALAW ULaw转码和repacketization |
| IOS HW MTP |
是 |
无 |
无 |
是 |
任何编码(和同样类似的)支持，只要同样封包化。没有转码。 |
| IOS SW MTP |
是 |
无 |
无 |
是 |
支持所有编码(和同样类似)，只要同样封包化。没有转码。 |
| IOS正常Xcoder |
是 |
是 |
是 |
是 |
只要至少一端是G711u/G711a，支持所有repacketization和转码。 |
| IOS普遍性Xcoder |
是 |
是 |
是 |
是 |
在任何编码、封包化和转码的支持。 |
关于MTP的更多信息在CUCM的配置请参考媒介终接点配置示例。
CUCM梅迪亚资源组(MRG)和MTP的Media Resource Group List (MRGL)考虑事项
当创建和分配媒体资源到媒体资源组(MRG)时和媒体资源组列表(MRGL)，请采取对考虑事项的一些额外点避免最好的资源的超量预订特定呼叫流的和相应地优先安排他们，因为CUCM无法选择最好的设备使用，当选择媒体时资源一呼叫，从MTPs和代码转换器一给的列表，如果他们有同一优先级或预定。反而，它选择支持请求的功能的第一个设备。因此，即使呼叫使用在两个段的G711，如果查找的第一个设备是然后分配它的代码转换器，当呼叫的一MTP和不寻找MTP资源进一步下来列表。
当您有通用和正常代码转换器，另一种相似的行为出现。CUCM可能使用正常代码转换器首先在其中一个段是G711的呼叫，然后发生故障，当呼叫获得已转接对使用一个non-G711编码的目的地时，因为CUCM不发布当前代码转换器和获得另一个，当呼叫转接时。
避过的最好的设计实践此行为是分配在单个MRG的所有MTP设备，然后通用代码转换器对另一MRG和正常代码转换器对第三MRG;然后请优先安排他们在MRGL内的同样顺序。现在，此设计不为每拓扑工作，并且必须查看根据案例由BASE基本类型。
SCCP MTP消息
这些SCCP消息被交换在DTMF处理的CUCM和MTP资源之间
- StationCapabilitiesRes
- StationUpdateCapabilities
- StationSubscribeDtmfPayloadReq
- StationSubscribeDTMFPayloadErrv
- StationSubscribeDtmfPayloadRes
- StationUnsubscribeDtmfPayloadErr
- StationNOTIFYDtmfToneMessage
- StationSendDtmfToneMessage
- StationUnsubscribeDtmfPayloadReq
- StationUnsubscribeDtmfPayloadRes
CUCM求立方的SIP中继
多维数据集支持KPML， NTE，或者未经请求的请通知作为DTMF机制，根据其配置。由于可以有终端的混合在系统的，多种方法在多维数据集可以同时配置为了最小化MTP需求。
在多维数据集，请配置SIPkpml和RTP NTE作为DTMF中继方法在SIP拨号对端下。此配置启用与终端的所有类型的DTMF交换，包括支持仅NTE支持仅OOB方法的那些和那些，不用对MTP资源的需要。使用此配置，网关协商NTE和KPML与CUCM。如果Unified CM终端不支持NTE，则KPML使用DTMF交换。如果两个方法顺利地协商，则网关依靠NTE收到位，并且不订阅对KPML。
多维数据集也有能力使用未经请求的通知(联合国) DTMF的方法。联合国方法发送SIP通知包含描述DTMF音的文本与正文的消息。如果SIPkpml不是可用的， Unified CM也支持此方法，并且可以使用。配置SIP通知、作为DTMF中继方法。注意此方法是思科业主。
为仅NTE中继配置的多维数据集，或者该由于若干相互作用限制，能只提供在CUCM侧和需要的MTP资源将分配的NTE，当通信与不支持NTE的终端时。
您能找到关于CUCM SIP中继MTP需求的更多信息
求立方的CUCM H323中继
CUCM动态地选择H323中继的DTMF传输方法;那么没有可配置选项选择一在其他。如果要强制一个特定DTMF中继方法，则您能从此中继的多维数据集拨号对等配置如此执行。
既使当H323多维数据集支持NTE，不能使用NTE选项，因为H.323网关/中继的CUCM不支持此时;在H245媒介功能交换时， CUCM不所以通知此功能。CUCM的首选是H.245信号。
如果另一个终端没有信令功能与CUCM相同， MTP资源为建立对H.323多维数据集的呼叫要求。例如，运行SIP堆叠的Cisco Unified IP电话7960支持仅NTEs，因此MTP用H.323中继必要，因此H245字母数字在H323段可以使用。
多维数据集动态/不对称有效载荷
根据IOS版本15.1(1)T (动态有效载荷类型相互作用DTMF的和编码数据包的多维数据集1.4)支持对SIP呼叫的SIP的介绍。
此功能允许多维数据集处理相互作用：音频/视频编码解码器、NSE和DTMF的动态有效载荷类型;哪些至此点被限制了，因为IOS将保留一个静态范围和只允许在两个呼叫段将协商的同样有效载荷类型并且拒绝与488错误反应的呼叫不匹配音频/视频/NSE对语音带内G711 DTMF的编码(或fallback的)不匹配的NTE有效载荷。所以，功能动态地允许多维数据集非保留或自由有效载荷类型相互作用用使用一个不同的范围有效载荷类型到另一个段不会支持他们或要求一另外特定映射的SIP供应商或第三方设备。
根据有效载荷类型值在多维数据集的一个呼叫段认为对称或不对称的交换通过SDP在提供和答案期间与终端
- 一个对称终端接受并且发送NTE事件的同一种有效载荷类型或呼叫段的一个特定编码。
- 一个不对称终端能接受和发送NTE事件的不同的有效载荷类型或呼叫段的一个特定编码。
此命令是可用指定不对称有效载荷使用情况;命令可以应用全局在语音服务voip回车sip配置模式下或在dial-peer级使用语音类sip CLI
asymmetric payload {dtmf | dynamic-codecs | full | system}
关于动态/不对称有效载荷的更多信息请导航到DTMF的动态有效载荷类型相互作用和SIP的编码数据包对SIP呼叫
对称有效载荷示例
这是示例SDP如何将看起来象为一对称有效负载协商，并且从debug voip rtp会话的输出命名了事件，当DTMF音传送时。使用RTP有效载荷类型nte命令，请注意:用于的配置强制IOS应该使用一种不同的有效载荷类型NTE事件。
DTMF中继协商
DTMF中继发射
不对称有效载荷示例
这是示例SDP如何将看起来象为一不对称有效负载协商，并且从debug voip rtp会话的输出命名了event命令，当DTMF音传送时。请注意配置用于的强制IOS使用一种不同的有效载荷类型NTE事件使用RTP有效载荷类型nte命令和语音类啜饮不对称有效负载DTMF CLI。
DTMF中继协商
DTMF中继发射
使用的哪个DTMF中继方法？
当选择dtmf-relay使用您需要考虑到这些变量时
- 介入的设备和平台
- 介入的VoIP协议
- 梅迪亚路径和支持的编码
- 支持的或首选的DTMF中继方法
首选的H.323的DTMF中继方法
H323的首选方法通过H.245字母数字将使用OOB或几乎发信号在所有情形。只要CUCM不是包含的，您能也使用RFC2833。
首选的SIP的DTMF中继方法
- SIP建立中继对服务提供商-，每当有SIP中继对介入的SIP供应商或与第三方SIP设备或IVR系统带内的交互作用通过RFC2833然后更喜欢。
- 对CUCM或CME的SIP中继-请启用RFC2833和KPML。
- 提示的SIP中继-提示的默认方法是联合国，但是您能也配置它使用NTE;哪些也是最好的选项，如果呼叫来自SIP供应商到提示系统。
相关信息
使用配置的Cisco Unified Communications Manager转码和媒介终接点
反馈