在CUBE上配置DTMF中繼

下載選項

PDF (1.1 MB)
在多種裝置上使用 Adobe Reader 檢視
ePub (727.5 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
Mobi (Kindle) (566.8 KB)
在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視

已更新: 2023 年 5 月 15 日

文件 ID:200412

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

本檔案介紹為Cisco Unified Border Element(CUBE)Enterprise設定雙音多頻(DTMF)中繼的過程。

必要條件

需求

思科建議您瞭解這些主題。

DTMF音調基礎知識
有關如何配置和使用Cisco® IOS語音（例如撥號對等體）的基本知識
有關如何配置和使用CUBE的基本知識
SIP和H323協定使用的信令的基本知識
有關如何調試H323和SIP等VoIP協定的基本知識

採用元件

本文件中的資訊是以下列軟體和硬體版本為依據.

在Cisco IOS上運行的思科統一邊界元素。
思科統一通訊管理器7.x或更高版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

慣例

如需檔案慣例的相關資訊，請參閱思科技術提示慣例。

背景資訊

本文還提供有關如何為CUBE支援的不同VoIP網關協定配置、驗證和排除DTMF中繼故障的資訊和命令。

CUBE支援的DTMF中繼方法

CUBE支援用於H.323和會話初始協定(SIP)信令協定的帶內和帶外(OOB)的各種DTMF中繼方法。

支援的帶內DTMF中繼方法

通過G711的帶內音訊DTMF
RFC283

支援的帶外DMTF中繼方法

H.245字母數字
H.245訊號
SIP未經請求通知
SIP KPML
SIP資訊

支援通過G711的帶內音訊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傳輸，以及它是帶內音訊音時。闡明應用正確配置和使用正確的方法進行故障排除所需/支援的實際方法始終非常重要。

支援的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編解碼器進行端到端傳遞的普通音訊音。

關於H323的NTE的其他事實：

H.323支援RFC2833（自V4）
Cisco IOS始終在TCS中通告其2833支援
CUCM僅通過H.323 ICT支援NTE。

Cisco專有RTP

通過這種方法，DTMF音與語音資料在同一個RTP通道中傳送。然而，DTMF音的編碼與語音樣本不同，並被識別為有效載荷型別121，這使得接收機能夠識別它們為DTMF音。CUCM不支援此方法，已停止使用此方法。

支援的SIP的DTMF中繼方法

注意 — RFC2833

帶內RFC2833 NTE負載型別和屬性在呼叫建立時兩端之間協商，該呼叫建立在SIP消息的主體部分內使用會話描述協定(SDP)。

未經請求的通知(UN)

使用此方法，數字在消息主體的負載內作為SIP NOTIFY消息以OOB形式傳送。

按鍵標籤語言(KPML)

基於RFC4730，數字在訂閱/通知消息內使用XML進行OOB傳輸。它主要用於註冊到CUCM或CME的SIP終端，也用於ITSP。

資訊(INFO)

數字在兩端之間作為OOB SIP INFO消息中繼。此方法不需要任何配置，並且由CUBE自動接受和關聯。

註:Unified CM不支援SIP INFO。

註：當協商了UN和NTE方法時，Cisco IOS總是選擇UN over NTE以避免雙音，並抑制帶內2833 NTE資料包。此外，對於CUCM，僅當沒有其它可用選項時才使用UN。同樣，如果KPML和UN都存在，Cisco Call Manager(CCM)會選擇KPML而不是UN。

在CUBE上配置DTMF-Relay

預設情況下，對於H323和SIP撥號對等體（SIP INFO除外），均禁用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 SUBSCRIBE/NOTIFY 
  sip-NOTIFY          DTMF Relay via SIP NOTIFY  messages

注意：將session protocol sip命令新增到dial-peer下以使SIP dtmf-relay選項變為可用。

配置DTMF中繼數字丟棄

為了通過帶內和帶外方法將相同的DTMF數字中繼到從帶內（具體來說是RTP-NTE）到帶外方法的呼叫的出站支路，以避免重複數字，請在入站撥號對等體上配置dtmf-relay rtp-nte digit-drop命令，並在出站撥號對等體上配置所需的帶外方法。否則，同一數字在OOB和帶內傳送，接收端將其解釋為重複數字。

在入站支路中配置digit-drop選項時，CUBE會抑制NTE資料包，而只中繼使用在出站支路上配置的OOB方法的數字。

如圖所示，數字丟棄選項僅在這些DTMF中繼方法之間互通時才可用。

Digit-Drop Interworking Table

例如，在入站撥號對等體上為通過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終端功能集(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的H.245 TCS消息中查詢此結構（在針對從0到16的事件通告負載型別101的示例中）。

capabilityTableEntryNumber 34
          capability receiveRTPAudioTelephonyEventCapability :
          {
            dynamicRTPPayloadType 101
            audioTelephoneEvent "0-16"
          }

驗證SIP的OOB DTMF中繼

未經請求的通知(UN)通告示例

要確認終端是否正在通告未經請求的NOTIFY(UN)功能，請在INVITE消息和/或使用調試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“

未經請求的NOTIFY(UN)傳輸示例

UN方法在NTFY消息中以二進位制資料形式傳輸數字；因此您看不到使用debug ccsip消息傳輸什麼數字。您可以需要封包擷取(PCAP)，或必須執行debug ccsip all命令才能看到二進位制資料輸出中的位元。

SIP Unsolicited

運行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部署示例

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傳輸示例

預訂發生後，端點可以通過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中繼方法之間互通，而無需轉碼器。

Inband G711與RFC2833之間的DTMF互通

CUBE能夠在Inband G711 DTMF（原始音訊音）和RFC2833之間進行互通。但是，這些要求必須滿足

使用的編解碼器必須是G711端到端。這是一個限制，因為如果使用LBR編解碼器，則音調會因為壓縮丟失而失真。
代碼轉換資源必須可用並相應地向CUBE註冊。這是因為CUBE需要向媒體RTP流分配轉碼資源（更具體地說，是DSP資源），以插入或偵聽音訊流內的音調。
帶內撥號線路的撥號對等體不能配置任何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流。

MTP Resources Required by CUCM

CUCM支援的MTP裝置

軟體MTP（Cisco IP語音媒體串流應用程式）

軟體MTP是通過在CUCM伺服器上啟用Cisco IP Voice Media Streaming Application實現的裝置。當安裝的應用程式配置為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	是	否	是	否	G711 Alaw-Ulaw轉碼和重新打包
Cisco IOS硬體MTP	是	否	否	是	支援任何編解碼器（和相同的風格），只要具有相同的分組化。沒有轉碼。
Cisco IOS SW MTP	是	否	否	是	只要具有相同的分組化，支援任何編解碼器（和相同的風格）。沒有轉碼。
Cisco IOS規則轉碼器	是	是	是	是	只要至少一端是G711u/G711a，它就支援任何重分組和轉碼。
Cisco IOS通用轉碼器	是	是	是	是	支援任何編解碼器、分組處理和轉碼。

有關CUCM中MTP配置的詳細資訊，請參閱媒體終端點配置示例。

MTP的CUCM媒體資源組(MRG)和媒體資源組清單(MRGL)注意事項

在建立媒體資源組(MRG)和媒體資源組清單(MRGL)並為其分配媒體資源時，請考慮一些額外的要點，以避免為特定呼叫流過度訂閱最佳資源，並相應地確定優先順序。CUCM無法從給定的MTP和轉碼器清單（如果它們具有相同優先順序或順序）中選擇呼叫的媒體資源時，選擇使用的最佳裝置。相反，它會選擇支援所請求功能的第一個裝置。因此，即使呼叫在兩個支路上使用G711，如果它找到的第一台裝置是轉碼器，那麼它就會將其分配為呼叫的MTP，而不是在清單中更靠後的位置查詢MTP資源。

當您同時具有通用轉碼器和常規轉碼器時，會出現另一個相似的行為。CUCM可以在呼叫中首先使用常規轉碼器，其中一條支路是G711，然後當呼叫被轉移到使用非G711編解碼器的目的地時失敗，因為CUCM不會釋放當前轉碼器，並且在呼叫被轉移時獲得另一條轉碼器。

避免此行為的最佳設計做法是將所有僅使用MTP的裝置分配到一個MRG中，然後將通用轉碼器分配到另一個MRG，並將常規轉碼器分配到第三個MRG；然後在MRGL中按相同順序排列這些裝置的優先順序。現在，此設計無法適用於每個拓撲，必須逐個進行稽核。

SCCP MTP消息

這些SCCP消息在CUCM和MTP資源之間交換以進行DTMF處理。

站功能Res
站更新功能
StationSubscribeDtmfPayloadReq
StationSubscribeDTMFPayloadErrv
StationSubscribeDtmfPayloadRes
StationUnsubscribeDtmfPayloadErr
StationNOTIFYDtmfToneMessage
StationSendDtmfToneMessage
StationUnsubscribeDtmfPayloadReq
StationUnsubscribeDtmfPayloadRes

CUCM和CUBE之間的DTMF中繼

CUCM SIP中繼到CUBE

CUBE支援KPML、NTE或Unsolicited Notify作為DTMF機制，具體取決於其配置。由於系統中可以混合終端，因此可以同時在CUBE上配置多種方法，以最小化MTP要求。

在CUBE上，將sip-kpml和rtp-nte配置為SIP撥號對等體下的DTMF中繼方法。此配置支援與所有型別的終端的DTMF交換，包括僅支援NTE的終端和僅支援OOB方法的終端，而不需要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選項，因為此時在CUCM上不支援該選項用於H.323網關/中繼；因此，在交換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的動態負載型別的互通；到目前為止，由於Cisco IOS將保留靜態範圍，並且只允許相同的負載型別在兩個呼叫支路上協商，因此會拒絕使用488錯誤響應的呼叫，因為音訊/影片/NSE編解碼器不匹配（或者回退到語音帶內G711 DTMF），從而導致NTE負載不匹配。因此，該功能允許CUBE動態取消預留或釋放負載型別，以便與SIP提供商或第三方裝置互通，這些提供商或第三方裝置使用不同範圍的負載型別到另一個不支援它們或需要特定不同對映的支路。

根據提供期間通過SDP交換的負載型別值，CUBE上的呼叫支路被視為對稱或非對稱，並與端點進行應答。

對稱端點接受NTE事件或呼叫支路的特定編解碼器並傳送相同的負載型別。
非對稱端點可以接受和傳送用於NTE事件的不同負載型別或用於呼叫段的特定編解碼器。

此命令可用於指定非對稱負載的使用；此命令可在voice service voip enter sip config mode下全域性應用，也可使用voice-class sip CLI在撥號對等體級別應用

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

有關動態/非對稱負載的詳細資訊，請導航到DTMF的動態負載型別互通和SIP到SIP呼叫的編解碼器資料包

對稱負載示例

以下範例顯示傳輸DTMF音時，對稱負載交涉和debug voip rtp session named event的輸出的SDP外觀。請注意，用於強制Cisco IOS的配置可以為使用rtp payload-type nte命令的NTE事件使用不同的負載型別。

DTMF中繼協商

DTMF中繼傳輸

非對稱負載示例

以下範例顯示傳輸DTMF音時，非對稱負載交涉和debug voip rtp session named event命令的輸出的SDP外觀。請注意用於強制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字母數字或訊號在幾乎所有情況中。您也可以使用RFC2833，只要不涉及CUCM。

適用於SIP的首選DTMF中繼方法

到服務提供商的SIP中繼 — 只要存在SIP中繼，即可與SIP提供商進行互動或與3^rd 第1方SIP裝置或IVR系統，則首選通過RFC2833帶內。
到CUCM或CME的SIP中繼 — 啟用RFC2833和KPML。
SIP中繼到CUE -CUE的預設方法為UN，但您也可以將其配置為使用NTE；如果呼叫來自SIP提供商到CUE系統，這也是最佳選項。

修訂	發佈日期	意見
2.0	15-May-2023	新增了Alt文本和背景資訊。更新的簡介、品牌要求、SEO、機器翻譯、風格要求、種語和格式
1.0	30-Mar-2016	初始版本

在CUBE上配置DTMF中繼

下載選項

無偏見用語

關於此翻譯

目錄

簡介

必要條件

需求

採用元件

慣例

背景資訊

CUBE支援的DTMF中繼方法

支援的帶內DTMF中繼方法

支援的帶外DMTF中繼方法

支援通過G711的帶內音訊DTMF

支援的H323的DTMF中繼方法

H.245字母數字

H.245訊號

命名電話事件(NTE)- RFC2833

Cisco專有RTP

支援的SIP的DTMF中繼方法

注意 — RFC2833

未經請求的通知(UN)

按鍵標籤語言(KPML)

資訊(INFO)

在CUBE上配置DTMF-Relay

配置H323的DTMF中繼

為SIP配置DTMF中繼

配置DTMF中繼數字丟棄

驗證DTMF中繼並對其進行故障排除

驗證H323的OOB DTMF中繼

H.245字母數字功能通告

H.245字母數位傳輸示例

H.245訊號能力廣告

H.245訊號傳輸範例

確認用於H323的帶內DTMF中繼

RFC2833功能支援通告

驗證SIP的OOB DTMF中繼

未經請求的通知(UN)通告示例

未經請求的NOTIFY(UN)傳輸示例

按鍵標籤語言(KPML)A部署示例

KPML T傳輸示例

DTMF互通

CUBE何時需要DTMF的轉碼資源

Inband G711與RFC2833之間的DTMF互通

其他DTMF互通選項

CUCM何時需要MTP資源

CUCM支援的MTP裝置

軟體MTP（Cisco IP語音媒體串流應用程式）

軟體MTP（基於Cisco IOS）

硬體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中繼方法

相關資訊

修訂記錄

由思科工程師貢獻

這份文件是否有所幫助？

讓思科協助您

本文件適用於這些產品