CUBE에서 DTMF 릴레이 구성

다운로드 옵션

PDF (952.9 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (728.4 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (570.2 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2023년 5월 15일

문서 ID:200412

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 CUBE(Cisco Unified Border Element) Enterprise를 위한 DTMF(Dual-Tone Multi-Frequency) 릴레이 구성 프로세스에 대해 설명합니다.

사전 요구 사항

요구 사항

Cisco에서는 이러한 주제에 대해 알고 있는 것이 좋습니다.

DTMF 색조에 대한 기본 지식
Cisco® IOS 음성(예: 다이얼 피어)을 구성하고 사용하는 방법에 대한 기본 지식
CUBE 구성 및 사용 방법에 대한 기본 지식
SIP 및 H323 프로토콜에서 사용되는 시그널링에 대한 기본 지식
H323 및 SIP와 같은 VoIP 프로토콜을 디버깅하는 방법에 대한 기본 지식

사용되는 구성 요소

이 문서의 정보는 이러한 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

Cisco IOS에서 실행되는 Cisco Unified Border Element.
Cisco Unified Communications Manager 7.x 이상

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.

배경 정보

또한 이 문서에서는 CUBE에서 지원하는 여러 VoIP 게이트웨이 프로토콜에 대한 DTMF 릴레이를 구성, 확인 및 트러블슈팅하는 방법에 대한 정보와 명령을 제공합니다.

CUBE에 대해 지원되는 DTMF-릴레이 방법

CUBE는 H.323 및 SIP(Session Initiation Protocol) 시그널링 프로토콜에 대해 대역 내(In-band) 및 대역 외(Out-Of-Band, OOB) 모두에 대해 다양한 DTMF 릴레이 방법을 지원합니다.

지원되는 대역 내 DTMF 릴레이 방법

대역 내 오디오 DTMF - G711
RFC2833

지원되는 대역 외 DMTF 릴레이 방법

H.245 영숫자
H.245 신호
SIP 원치 않는 알림
SIP KPML
SIP 정보

G711을 통한 대역 내 오디오 DTMF 지원

Voice In-band audio 또는 G711 DTMF는 정상적으로 통화를 설정하고 오디오 엔드를 종단 간에 전달하여 G711Ulaw/Alaw 코덱을 사용하는 것 외에, 신호 프로토콜 또는 DSP의 추가적인 개입 없이 음성 오디오 스트림을 통해 가청 톤을 전송하는 것을 의미합니다. 즉, CUBE/Cisco IOS는 일반 음성 오디오인 것처럼 한 끝에서 다른 끝으로 오는 톤의 오디오만 전달합니다. 이 방법을 위해 수행해야 할 중요한 조치는 특히 오디오를 압축하는 코덱(G711 이외의 코덱)을 사용하여 DTMF 톤을 왜곡하고 수신 단에서 인식할 수 없도록 만들기 때문에 통화가 설정되었는지 확인하고 G711Ulaw/Alaw 코덱을 사용하는 것입니다. 이는 고압축 코덱에서 활용되는 압축 알고리즘이 DTMF 톤이 아닌 사람의 음성을 인식하고 예측하도록 설계되었기 때문이다.

대역 내 오디오/G711 DTMF는 모든 VoIP 신호 처리 프로토콜에서 지원되며 엔드 투 엔드 통화에 대해서만 G711 코덱을 적용해야 합니다. 또한 LBR(low-bit-rate) 코덱에서 G711로의 트랜스코딩 처리는 신호음도 왜곡할 가능성이 높습니다.

참고: 이 DTMF 릴레이 방법을 논의할 때 일반적으로 대역 내(In-band) 용어가 NTE/RFC2833(Named Telephony Event)라고 하는 RTP 스트림 내의 DTMF 전송을 가리키는 데 사용되고 대역 내 오디오 신호음인 경우 사용됩니다. 올바른 구성을 적용하고 올바른 문제 해결 방법을 사용하는 데 필요한/지원되는 실제 방법을 명확히 하는 것이 항상 중요합니다.

H323에서 지원되는 DTMF-릴레이 방법

H.245 영숫자

DTMF 숫자는 음성 스트림에서 분리되어 RTP 채널을 통해 전송되는 대신 H.245 신호 처리 채널 OOB를 통해 전송됩니다. 신호음은 H.245 사용자 입력 표시 메시지로 전송됩니다. H.245 신호 채널은 신뢰할 수 있는 채널이며 DTMF 톤을 전송하는 패킷의 전달을 보장합니다. dtmf-relay h245-alphanumeric 명령을 지원하려면 H.323 버전 2를 준수하는 모든 시스템이 필요합니다. 그러나 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 릴레이는 GW 시그널링 프로토콜의 개입 없이 숫자가 RTP 오디오 트래픽 자체 내에서 전송되기 때문에 대역 내 방법으로 간주됩니다.

RFC2833/NTE 방법은 음성 대역 내 오디오 또는 G711 RTP 스트림과 혼동해서는 안 됩니다. 그 이유는 나중에는 릴레이 신호 방법을 인식하거나 프로세스에 관여하지 않고 일반 오디오로 전달되는 가청 신호음만 있기 때문입니다. 이는 G711Ulaw/Alaw 코덱을 사용하여 엔드 투 엔드로 전달되는 일반 오디오 신호음을 의미합니다.

H323의 NTE에 대한 몇 가지 다른 사실들:

H.323은 V4부터 RFC2833을 지원합니다
Cisco IOS는 항상 TCS에서 2833 지원을 광고합니다.
CUCM은 H.323 ICT를 통해서만 NTE를 지원합니다.

Cisco 독점 RTP

이 방법을 사용하면 DTMF 톤이 음성 데이터와 동일한 RTP 채널에서 전송됩니다. 그러나 DTMF 톤은 음성 샘플과 다르게 인코딩되며 페이로드 유형 121로 식별되어 수신자가 DTMF 톤으로 식별할 수 있게 됩니다. 이 방법은 CUCM에서 지원되지 않으며 사용이 중단되었습니다.

SIP에 지원되는 DTMF-릴레이 방법

NTE - RFC2833

대역 내 RFC2833 NTE 페이로드 유형 및 특성은 SIP 메시지의 본문 섹션 내에서 SDP(Session Description Protocol)를 사용하는 통화 설정에서 두 끝 간에 협상됩니다.

원치 않는 알림(UN)

이 방법을 사용하면 메시지 본문의 페이로드 내에서 숫자가 SIP NOTIFY 메시지로 OOB로 전송됩니다.

KPML(Key Press Markup Language)

RFC4730을 기반으로, 숫자는 Subscribe/NOTIFY 메시지 내의 XML을 사용하여 OOB로 전송됩니다. CUCM 또는 CME에 등록된 SIP 엔드포인트뿐만 아니라 ITSP에도 사용됩니다.

정보(INFO)

숫자는 끝 사이에 OOB SIP INFO 메시지로 릴레이됩니다. 이 메서드는 구성이 필요하지 않으며 CUBE에서 자동으로 승인 및 연결됩니다.

참고: SIP 정보는 Unified CM에서 지원되지 않습니다.

참고: UN 및 NTE 메서드가 모두 협상되면 Cisco IOS는 항상 이중 신호음을 방지하기 위해 UN over NTE를 선택하며 대역 내 2833 NTE 패킷은 억제됩니다. 또한 CUCM의 경우 다른 옵션을 사용할 수 없는 경우에만 UN이 사용됩니다. 마찬가지로 KPML과 UN이 모두 있는 경우 CCM(Cisco Call Manager)은 UN보다 KPML을 선택합니다.

CUBE에서 DTMF-릴레이 구성

기본적으로 DTMF 릴레이는 H323과 SIP 다이얼 피어(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

참고: SIP dtmf 릴레이 옵션을 사용하려면 다이얼 피어 아래에 session protocol sip 명령을 추가합니다.

DTMF 릴레이 숫자-삭제 구성

대역 내(구체적으로 RTP-NTE)에서 대역 외(out-of-band) 방식으로 상호 작용하는 통화의 발신 레그에 대역 내(in-band) 및 대역 외(out-of-band) 방식을 통해 동일한 DTMF 숫자를 릴레이하여 중복 숫자를 방지하려면 인바운드 다이얼 피어에서 dtmf-relay rtp-nte digit-drop 명령을 구성하고 발신 다이얼 피어에서 원하는 대역 외(out-of-band) 방법을 구성합니다. 그렇지 않으면 동일한 숫자가 대역 내뿐만 아니라 OOB에서도 전송되며 수신 측에 의해 중복 숫자로 해석됩니다.

digit-drop 옵션이 인바운드 레그에 구성된 경우 CUBE는 NTE 패킷을 억제하고 아웃바운드 레그에 구성된 OOB 방법을 사용하는 숫자만 릴레이합니다.

이 그림에서 볼 수 있듯이 digit-drop 옵션은 이러한 DTMF 릴레이 방법 간의 상호 연동 시에만 사용할 수 있습니다.

Digit-Drop Interworking Table

예를 들어 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 영숫자 기능을 광고하고 있는지 확인하려면 debug h245 asn1을 사용하여 H.245 TCS(Terminal Capability Set) 메시지 내에서 이 행을 확인합니다.

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 신호 기능을 광고하고 있는지 확인하려면 디버그 h245 asn1을 사용하는 H.245 TCS(Terminal Capability Set) 메시지 내에서 이 행을 확인합니다.

capability receiveUserInputCapability : dtmf : NULL

H.245 신호 전송 예

이는 H245 신호 방법을 사용하여 100 msec의 지속 시간으로 숫자 1을 전송하는 엔드포인트의 예입니다. 두 개의 메시지가 있으며, 첫 번째 메시지는 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가 있는 엔드포인트는 TCS(TerminalCapabilitySet) 메시지 내의 기능 메시지를 통해 RFC2833을 지원함을 나타낼 수 있습니다.

RFC2833 기능 지원 알림

엔드포인트가 RFC2833 기능을 광고하고 있는지 확인하려면 debug h245 asn1을 사용하는 H.245 TCS 메시지 내에서 이 구조를 확인하십시오(페이로드 유형 101의 예에서는 0에서 16까지의 이벤트에 대해 광고되고 있음).

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

SIP용 OOB DTMF 릴레이 유효성 검사

UN(UNSOLICITED NOTIFY) 알림 예

엔드포인트가 UN(Unsolicited NOTIFY) 기능을 광고하고 있는지 확인하려면 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“

UN(UNSOLICITED NOTIFY) 전송 예

UN 메서드는 숫자를 NTFY 메시지 내에서 이진 데이터로 전송합니다. 따라서 디버그 ccsip 메시지를 사용하여 어떤 숫자가 전송되는지 볼 수 없습니다. PCAP(Packet Capture)가 필요하거나 debug csip 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 상호 운용성 표 섹션을 참조하십시오.

DTMF를 위해 CUBE에 트랜스코딩 리소스가 필요한 경우

CUBE에는 이러한 시나리오에서 로컬로 등록된 트랜스코딩 리소스가 필요합니다.

RFC2833과 Voice In-band 간 상호 연동
OOB 메서드 및 RFC2833 간 흐름중심 통화 상호 연동

CUBE는 트랜스코더 없이 흐름 통과 호출로 다른 모든 DTMF 릴레이 메서드 간에 상호 작용할 수 있습니다.

인밴드 G711에서 RFC2833으로의 DTMF 상호 연동

CUBE는 대역 내 G711 DTMF(원시 오디오 톤)에서 RFC2833으로 상호 작용할 수 있습니다. 그러나 이러한 요구 사항을 충족해야 합니다

사용된 코덱은 G711 엔드 투 엔드 코덱이어야 합니다. 이는 LBR 코덱을 사용할 경우 압축 손실로 인해 신호음이 왜곡되기 때문에 제한 사항입니다.
트랜스코딩 리소스가 사용 가능하고 그에 따라 CUBE에 등록되어 있어야 합니다. 이는 CUBE가 오디오 스트림 내에서 톤(tone)을 주입하거나 듣기 위해 미디어 RTP 스트림에 트랜스코딩 리소스(보다 구체적으로는 DSP 리소스)를 할당해야 하기 때문입니다.
대역 내 신호음 레그의 다이얼 피어에 구성된 DTMF 릴레이 명령이 없어야 합니다. IOS XE 16.12.x 이상에서는 이 요구 사항이 더 이상 필요하지 않습니다. 인바운드/ITSP 다이얼 피어에 dtmf-relay rtp-nte가 구성되어 있는 경우에도 CUBE는 트랜스코더를 동적으로 할당할 수 있습니다. 트랜스코더를 할당하는 결정은 피어 디바이스들 사이의 SDP 협상에 의존할 수 있다.
RFC2833 레그의 다이얼 피어에 dtmf-relay rtp-nte가 구성되어 있어야 합니다.
통화와 관련된 다이얼 피어에서 digit-drop을 활성화하지 마십시오.

기타 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 이벤트를 탐지하면 SCCP StationNOTIFYDtmfTtoneMessage를 CUCM에 전송하고 스트림에서 탐지된 신호음을 알립니다. CUCM은 동일한 숫자를 차례대로 전송하고 OOB(Signaling Protocol)를 반대쪽 끝으로 사용합니다. CUCM이 OOB DTMF 엔드포인트로부터 OOB DTMF 신호를 수신하면 MTP가 NTE 이벤트의 형태로 요청된 톤을 RTP 스트림에 삽입할 수 있도록 SCCP StationSendDtmfToneMessage를 MTP로 보냅니다.

MTP Resources Required by CUCM

CUCM에서 지원되는 MTP 디바이스

소프트웨어 MTP(Cisco IP Voice Media Streaming Application)

소프트웨어 MTP는 CUCM 서버에서 Cisco IP Voice Media Streaming Application을 활성화하여 구현하는 장치입니다. 설치된 애플리케이션이 MTP 애플리케이션으로 구성되면 CUCM 노드에 등록하고, 지원하는 MTP 리소스의 수를 CUCM에 알립니다. 소프트웨어 MTP 디바이스는 G.711 스트림만 지원합니다. CUCM의 기본 설정에서는 소프트웨어 MTP당 최대 48건의 통화를 처리할 수 있습니다. 서비스 매개변수를 수정하는 방법에 대한 자세한 내용은 Cisco Unified Communications Manager Administration Guide의 해당 버전을 참조하십시오.

소프트웨어 MTP(Cisco IOS 기반)

이 MTP는 이러한 코덱의 구성을 허용하지만 지정된 시간 G.711 mu-law 및 a-law, G.729a, G.729, G.729ab, G.729b 및 통과에서 하나만 구성할 수 있습니다. 이 중 일부는 CUCM 구현과 관련이 없습니다.

라우터 컨피그레이션에서는 최대 1,000개의 개별 스트림을 허용하며, 이는 10MB의 트래픽을 생성하는 500개의 트랜스코딩 세션을 지원합니다. Cisco ISR G2 및 ASR 라우터는 이보다 훨씬 더 많은 숫자를 지원할 수 있습니다.

이 MTP는 CPU 사이클을 사용하여 작동합니다. 활성화된 세션 수가 CPU의 성능에 영향을 미치고 높은 CPU 사용률을 트리거할 수 있으므로 기록해 둡니다.

하드웨어 MTP(PVDM2, Cisco NM-HDV2 및 NM-HD-1V/2V/2VE)

이 하드웨어는 DSP를 제공하기 위해 PVDM-2 모듈을 사용합니다.

하드웨어 MTP(PVDM3이 포함된 Cisco 2900 및 3900 Series 라우터)

이러한 라우터는 마더보드나 마더보드나 서비스 모듈에 어댑터가 있는 PVDM2에서 PVDM3 DSP를 기본적으로 사용합니다.

참고: Cisco IOS에서 하드웨어 MTP 리소스를 구성할 때 G.729 또는 G.729b를 구성할 수 없습니다. 그러나 다른 모든 MTP 리소스가 소진되었거나 사용할 수 없는 경우 Unified CM은 하드웨어 트랜스코딩 리소스를 MTP로 사용할 수 있습니다.

소프트웨어 또는 하드웨어 MTP 사용 시기

네트워크에서 구축할 MTP 유형은 통화 흐름의 엔드포인트, 게이트웨이 및 트렁크에서 지원하는 특정 코덱 매개변수에 따라 달라집니다

사용할 코덱 유형
사용할 코덱 패킷 크기(패킷화)
T.38 팩스 사용(Codec Pass-Through 지원 필요)

이러한 매개변수를 기반으로 네트워크에 필요한 올바른 리소스를 안전하게 선택하고 구축할 수 있습니다.

표에 나와 있는 것처럼, 서로 다른 MTP 및 트랜스코더 유형에서 지원되는 서로 다른 기능

유형	동일한 코덱	다른 코덱	다른 패킷화	코덱 패스스루	참고
CUCM SW MTP	예	아니요	예	아니요	G711 Alaw-Ulaw 트랜스코딩 및 리패킷화
Cisco IOS HW MTP	예	아니요	아니요	예	모든 코덱(및 동일한 기능)을 지원하며, 동일한 패킷화만 가능합니다. 트랜스코딩이 없습니다.
Cisco IOS SW MTP	예	아니요	아니요	예	동일한 패킷화라면 모든 코덱(및 동일한 맛)을 지원합니다. 트랜스코딩이 없습니다.
Cisco IOS Regular Xcoder	예	예	예	예	적어도 한쪽이 G711u/G711a인 한, 모든 리패킷화 및 트랜스코딩을 지원합니다.
Cisco IOS Universal Xcoder	예	예	예	예	모든 코덱, 패킷화 및 트랜스코딩 지원.

CUCM의 MTP 컨피그레이션에 대한 자세한 내용은 미디어 종료 지점 컨피그레이션 예를 참조하십시오.

MTP에 대한 CUCM MRG(Media Resource Group) 및 MRGL(Media Resource Group List) 고려 사항

미디어 리소스를 만들고 MRG(미디어 리소스 그룹) 및 MRGL(미디어 리소스 그룹 목록)에 할당할 때 특정 통화 흐름에 가장 적합한 리소스의 초과 서브스크립션을 방지하고 그에 따라 우선 순위를 지정하기 위해 몇 가지 추가 사항을 고려해야 합니다. CUCM은 동일한 우선 순위 또는 순서가 있는 경우 지정된 MTP 및 트랜스코더 목록에서 통화에 대한 미디어 리소스를 선택할 때 사용할 최상의 장치를 선택할 수 없습니다. 대신 요청된 기능을 지원하는 첫 번째 장치를 선택합니다. 따라서 통화가 양쪽 다리에서 G711을 사용하는 경우에도 처음 발견된 장치가 트랜스코더이면 해당 장치를 통화에 대한 MTP로 할당하고 목록 아래의 MTP 리소스를 찾지 않습니다.

유니버설 트랜스코더와 일반 트랜스코더가 모두 있는 경우에도 비슷한 동작이 발생합니다. CUCM은 다리 중 하나가 G711인 통화에서 먼저 일반 트랜스코더를 사용한 다음, 통화가 G711이 아닌 코덱을 사용하는 대상으로 호전환되면 실패할 수 있습니다. CUCM은 현재 트랜스코더를 해제하고 통화가 호전환되면 다른 트랜스코더를 가져오지 않기 때문입니다.

이러한 동작을 해결하는 가장 좋은 설계 방법은 모든 MTP 전용 디바이스를 단일 MRG에 할당한 다음, 범용 트랜스코더는 다른 MRG에, 일반 트랜스코더는 세 번째 MRG에 할당하고, MRGL 내에서 동일한 순서로 우선 순위를 지정하는 것입니다. 이제 이 설계는 모든 토폴로지에 대해 작동할 수 없으며, 기본적으로 검토되어야 합니다.

SCCP MTP 메시지

이러한 SCCP 메시지는 DTMF 처리를 위해 CUCM 및 MTP 리소스 간에 교환됩니다.

스테이션 기능
스테이션 업데이트 기능
스테이션 가입Dtmf페이로드요청
StationSubscribeDTMFPayloadErrv
StationSubscribeDtmfPayloadRes
StationUnsubscribeDtmfPayloadErr
스테이션NOTIFYDtmfToneMessage
스테이션DtmfToneMessage 전송
StationUnsubscribeDtmfPayloadReq
StationUnsubscribeDtmfPayloadRes

CUCM과 CUBE 간의 DTMF 릴레이

CUCM SIP 트렁크에서 큐브로의 트래픽

CUBE는 컨피그레이션에 따라 DTMF 메커니즘으로 KPML, NTE 또는 Unsolicited Notify를 지원합니다. 시스템에 여러 엔드포인트가 혼합되어 있을 수 있으므로 MTP 요구 사항을 최소화하기 위해 CUBE에서 여러 방법을 동시에 구성할 수 있습니다.

CUBE에서 sip-kpml 및 rtp-nte를 모두 SIP 다이얼 피어 아래의 DTMF 릴레이 메서드로 구성합니다. 이 컨피그레이션을 사용하면 MTP 리소스 없이 NTE만 지원하는 엔드포인트 및 OOB 방법만 지원하는 엔드포인트를 비롯한 모든 유형의 엔드포인트와 DTMF 교환을 수행할 수 있습니다. 이 컨피그레이션에서는 게이트웨이가 CUCM으로 NTE 및 KPML을 협상합니다. Unified CM 엔드포인트에서 NTE를 지원하지 않으면 DTMF 교환에 KPML이 사용됩니다. 두 방법 모두 성공적으로 협상된 경우 게이트웨이는 NTE를 사용하여 숫자를 수신하고 KPML에 가입하지 않습니다.

CUBE에는 DTMF에 대해 UN(Unsolicited Notify) 메서드를 사용할 수 있는 기능도 있습니다. UN 메서드는 DTMF 톤을 설명하는 텍스트가 포함된 본문이 있는 SIP Notify 메시지를 보냅니다. 이 메서드는 Unified CM에서도 지원되며 sip-kpml을 사용할 수 없는 경우 사용할 수 있습니다. DTMF 릴레이 방법으로 sip-notify를 구성합니다. 이 방법은 Cisco 소유 방식입니다.

NTE 릴레이만을 위해 구성된 CUBE 또는 일부 상호 연동 제한으로 인해 NTE를 지원하지 않는 엔드포인트와 통신할 때 CUCM 측에 할당할 NTE 및 필수 MTP 리소스만 제공할 수 있습니다.

CUCM SIP Trunk MTP 요구 사항에 대한 자세한 내용을 확인할 수 있습니다

CUCM H323 트렁크 - CUBE

CUCM은 H323 트렁크에 대한 DTMF 전송 방법을 동적으로 선택하므로 둘 중 하나를 선택할 수 있는 구성 가능한 옵션이 없습니다. 특정 DTMF 릴레이 방법을 강제하려는 경우 이 트렁크에 대한 CUBE 다이얼 피어 컨피그레이션에서 강제 릴레이를 수행할 수 있습니다.

H323 CUBE가 NTE를 지원하는 경우에도 NTE 옵션은 현재 H.323 게이트웨이/트렁크에 대한 CUCM에서 지원되지 않으므로 사용하지 않아야 합니다. 따라서 CUCM은 H245 미디어 기능이 교환되는 순간에 이 기능을 광고하지 않습니다. CUCM의 기본 옵션은 H.245 Signal입니다.

다른 엔드포인트에 CUCM과 공통된 시그널링 기능이 없는 경우 H.323 CUBE에 대한 통화를 설정하려면 MTP 리소스가 필요합니다. 예를 들어 SIP 스택을 실행하는 Cisco Unified IP Phone 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가 고정 범위를 예약하고 두 호출 레그에서 동일한 페이로드 유형만 협상하도록 허용하므로 제한되었으며, NTE 페이로드의 불일치를 위해 오디오/비디오/NSE 코덱의 불일치를 위해 488 오류 응답(또는 음성 대역 내 G711 DTMF로 대체)을 통해 통화를 거부합니다. 따라서 CUBE는 이 기능을 통해 다른 범위의 페이로드 유형을 사용하는 SIP 제공자 또는 서드파티 디바이스와의 상호 작용을 위해 동적으로 페이로드 유형을 예약 해제하거나 해제할 수 있으며, 이를 지원하지 않거나 특별히 다른 매핑이 필요합니다.

CUBE의 통화 레그는 엔드포인트와 오퍼 및 응답 중에 SDP를 통해 교환되는 페이로드 유형 값을 기반으로 대칭 또는 비대칭으로 간주됩니다.

대칭 엔드포인트는 NTE 이벤트에 대해 동일한 페이로드 유형을 수락하고 전송하거나 통화 레그에 대해 특정 코덱을 전송합니다.
비대칭 엔드포인트는 NTE 이벤트에 대해 서로 다른 페이로드 유형을 수락하고 전송할 수 있으며, 통화 레그에 대해 특정 코덱을 전송할 수 있습니다.

이 명령은 비대칭 페이로드의 사용을 지정하는 데 사용할 수 있습니다. 이 명령은 음성 서비스 voip enter sip config 모드에서 전역적으로 적용하거나 음성 클래스 sip CLI를 사용하여 다이얼 피어 레벨에서 적용할 수 있습니다

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

동적/비대칭 페이로드에 대한 자세한 내용은 DTMF용 동적 페이로드 유형 인터워킹 및 SIP-SIP 통화용 코덱 패킷으로 이동하십시오.

대칭 페이로드 예

다음은 DTMF 톤을 전송하는 동안 SDP가 대칭 페이로드 협상에 대해 어떻게 나타나는지 그리고 debug voip rtp 세션 명명된 이벤트의 출력을 보여주는 예입니다. Cisco IOS를 강제하는 데 사용되는 컨피그레이션에서는 rtp payload-type nte 명령을 사용하는 NTE 이벤트에 대해 다른 페이로드 유형을 사용할 수 있습니다.

DTMF 릴레이 협상

DTMF 릴레이 전송

비대칭 페이로드 예

다음은 DTMF 톤을 전송하는 동안 SDP가 비대칭 페이로드 협상에 대해 어떻게 나타나는지 그리고 debug voip rtp session named event 명령의 출력을 보여주는 예입니다. Cisco IOS에서 NTE 이벤트에 대해 다른 페이로드 유형을 사용하도록 강제하는 데 사용되는 컨피그레이션에서는 rtp payload-type nte 명령 및 음성 클래스 sip 비대칭 페이로드 dtmf CLI를 사용합니다.

DTMF 릴레이 협상

DTMF 릴레이 전송

사용할 DTMF 릴레이 방법

사용할 DTMF-릴레이를 선택할 때 이러한 변수를 고려해야 합니다.

관련된 장치 및 플랫폼.
관련된 VoIP 프로토콜.
미디어 경로 및 지원되는 코덱.
지원되거나 선호하는 DTMF 릴레이 방법입니다.

H.323의 기본 DTMF 릴레이 방법

H323에 대한 바람직한 방법은 거의 모든 시나리오에서 OOB 내지 H.245 영숫자 또는 신호를 사용하는 것이다. CUCM이 포함되지 않은 경우 RFC2833을 사용할 수도 있습니다.

SIP를 위한 기본 DTMF 릴레이 방법

SIP 트렁크를 통신 사업자에게 SIP 공급자에 대한 SIP 트렁크 또는 3과의 상호 작용이 있을 때마다^{세 번째} RFC2833을 통한 대역 내 SIP 디바이스 또는 IVR 시스템이 선호됩니다.
CUCM 또는 CME에 대한 SIP 트렁크 - RFC2833과 KPML을 모두 활성화합니다.
SIP trunk to CUE - CUE의 기본 메서드는 UN이지만 NTE를 사용하도록 구성할 수도 있습니다. NTE는 SIP 공급자에서 CUE 시스템으로 전화가 오는 경우에도 가장 좋은 옵션입니다.

개정	게시 날짜	의견
2.0	15-May-2023	대체 텍스트 및 배경 정보를 추가했습니다. 업데이트된 소개, 브랜딩 요구 사항, SEO, 기계 번역, 스타일 요구 사항, Gerunds 및 서식
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-릴레이 방법

NTE - RFC2833

원치 않는 알림(UN)

KPML(Key Press Markup Language)

정보(INFO)

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(UNSOLICITED NOTIFY) 알림 예

UN(UNSOLICITED NOTIFY) 전송 예

KPML(키 프레스 마크업 언어) A광고 예

KPML T전송 예

DTMF 상호 연동

DTMF를 위해 CUBE에 트랜스코딩 리소스가 필요한 경우

인밴드 G711에서 RFC2833으로의 DTMF 상호 연동

기타 DTMF 인터워킹 옵션

CUCM에 MTP 리소스가 필요한 경우

CUCM에서 지원되는 MTP 디바이스

소프트웨어 MTP(Cisco IP Voice Media Streaming Application)

소프트웨어 MTP(Cisco IOS 기반)

하드웨어 MTP(PVDM2, Cisco NM-HDV2 및 NM-HD-1V/2V/2VE)

하드웨어 MTP(PVDM3이 포함된 Cisco 2900 및 3900 Series 라우터)

소프트웨어 또는 하드웨어 MTP 사용 시기

MTP에 대한 CUCM MRG(Media Resource Group) 및 MRGL(Media Resource Group List) 고려 사항

SCCP MTP 메시지

CUCM과 CUBE 간의 DTMF 릴레이

CUCM SIP 트렁크에서 큐브로의 트래픽

CUCM H323 트렁크 - CUBE

CUBE 동적/비대칭 페이로드

대칭 페이로드 예

DTMF 릴레이 협상

DTMF 릴레이 전송

비대칭 페이로드 예

DTMF 릴레이 협상

DTMF 릴레이 전송

사용할 DTMF 릴레이 방법

H.323의 기본 DTMF 릴레이 방법

SIP를 위한 기본 DTMF 릴레이 방법

관련 정보

개정 이력

Cisco 엔지니어가 작성

이 문서가 도움이 되셨습니까?

지원 문의

이 문서가 적용되는 제품