DTMF 릴레이 및 CUBE에서의 인터워킹
목차
소개
이 문서에서는 Cisco CUBE(Unified Border Element) Enterprise에 대한 DTMF(Dual-Tone Multi-Frequency) 릴레이를 구성하는 프로세스에 대해 설명합니다.또한 CUBE에서 지원하는 다른 VoIP 게이트웨이 프로토콜에 대해 DTMF 릴레이를 구성, 확인 및 트러블슈팅하는 방법에 대한 정보와 명령도 제공합니다.
기고자: Michael Mendoza, Cisco TAC 엔지니어
사전 요구 사항
요구 사항
Cisco에서는 이러한 주제에 대해 알고 있는 것이 좋습니다.
- DTMF 신호음 기본 지식
- Cisco IOS 음성 구성 및 사용 방법에 대한 기본 지식(예: 다이얼 피어)
- CUBE 구성 및 사용 방법에 대한 기본 지식
- SIP 및 H323 프로토콜에서 사용되는 시그널링에 대한 기본 지식
- H323 및 SIP와 같은 VoIP 프로토콜을 디버깅하는 방법에 대한 기본적인 지식
사용되는 구성 요소
이 문서의 정보는 이러한 소프트웨어 및 하드웨어 버전을 기반으로 합니다
- IOS에서 실행되는 Cisco Unified Border Element
- Cisco Unified Communications Manager 7.x 이상
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 규칙을 참조하십시오.
CUBE에 대해 지원되는 DTMF 릴레이 메서드
CUBE는 H.323 및 SIP(Session Initiation Protocol) 신호 프로토콜의 대역 내 및 OOB(Out-of-Band) 모두에 대해 다양한 DTMF 릴레이 방법을 지원합니다.
지원되는 인밴드 DTMF 릴레이 방법
- 대역 내 감사 DTMF - G711
- RFC2833
지원되는 대역 외 DMTF 릴레이 방법
- H.245 영숫자
- H.245 신호
- SIP 원치 않는 알림
- SIP KPML
- SIP 정보
G711에서 대역 내 오디오 DTMF 지원
Voice In-band 오디오 또는 G711 DTMF는 음성 오디오 스트림을 통해 음성 신호음을 전송하는 것을 의미하며, 통화를 정상적으로 설정하고 G711Ulaw/Alaw 코덱을 사용하여 오디오를 끝까지 전달하는 것 이외에 신호 프로토콜 또는 전송을 위한 DSP를 추가로 사용하지 않습니다.즉, CUBE/IOS는 일반 음성 오디오처럼 한쪽 끝에서 다른 쪽 끝으로 들어오는 신호음의 오디오만 전달합니다.이 방법을 사용하는 중요한 방법은 특히 오디오를 압축하는 코덱을 사용하는 경우(G711 이외의 코덱은 DTMF 신호음을 왜곡하고 수신 끝까지 인식할 수 없는 경우) G711Ulaw/Alaw 코덱을 사용하여 통화가 설정되도록 하는 것입니다.고압축 코덱에서 사용되는 압축 알고리즘은 DTMF 신호음이 아닌 사람의 음성을 인식하고 예측하도록 설계되었기 때문입니다.
대역 내 오디오/G711 DTMF는 모든 VoIP 신호 프로토콜에서 지원되며 엔드 투 엔드 통화에 대해 G711 코덱만 시행해야 합니다.또한 LBR(low-bit-rate) 코덱에서 G711로의 트랜스코딩 처리도 신호음을 왜곡할 가능성이 높습니다.
H323에서 지원되는 DTMF 릴레이 방법
H.245 영숫자
DTMF 숫자는 음성 스트림에서 분리되고 RTP 채널을 통해 전송되는 대신 H.245 신호 채널 OOB를 통해 전송됩니다.신호음은 H.245 사용자 입력 표시 메시지로 전송됩니다.H.245 신호 채널은 신뢰할 수 있는 채널이며 DTMF 신호음을 전송하는 패킷은 전달될 수 있습니다.dtmf-relay h245 영숫자 명령을 지원하려면 H.323 버전 2 호환 모든 시스템이 필요합니다.그러나 dtmf-relay h245-signal 명령의 지원은 선택 사항입니다.
H.245 신호
H.245 영숫자와 유사한 OOB 방법을 사용하면 신호음 지속 시간 정보를 전달할 수 있으므로 다른 공급업체의 시스템과 상호 작용할 때 영숫자 방법을 사용할 때 잠재적인 문제를 해결할 수 있습니다.
NTE(Named Telephony Events) - 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 코덱을 사용하여 엔드 투 엔드 방식으로 전달되는 일반 오디오 신호음을 의미합니다.
NTE와 H323에 대한 다른 흥미로운 사실:
- H.323은 V4의 RFC2833을 지원합니다.
- 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)
RFC4730에 따라 숫자가 가입/알림 메시지 내에서 XML을 사용하여 OOB로 전송됩니다.CUCM 또는 CME에 등록된 SIP 엔드포인트뿐 아니라 ITSP에도 주로 사용됩니다.
정보(정보)
끝의 OOB SIP INFO 메시지로 숫자가 릴레이됩니다.이 방법은 구성이 필요하지 않으며 CUBE에서 자동으로 수락하고 관련됩니다.
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 SUBCRIBE/NOTIFY sip-NOTIFY DTMF Relay via SIP NOTIFY messages
DTMF 릴레이 숫자 삭제 구성
대역 내 및 대역 외 메서드를 통해 동일한 DTMF 숫자를 대역 내(특히 RTP-NTE)에서 대역 외 방법으로 상호 작용하는 통화에 대한 발신 레그로 릴링하여 중복 숫자를 방지하려면 인바운드 다이얼 피어에서 dtmf-relay rtp-nte digit-drop 명령과 발신 다이얼 피어에서 원하는 대역 외 방법을 구성합니다.그렇지 않으면 대역내 및 OOB에서 동일한 숫자가 전송되며 수신 끝에 의해 중복 숫자로 해석됩니다.
digit-drop 옵션이 인바운드 레그에 구성된 경우 CUBE는 NTE 패킷을 억제하고 아웃바운드 레그에 구성된 OOB 방법을 사용하는 숫자만 릴레이합니다.
이 이미지에 표시된 대로 digit-drop 옵션은 이러한 DTMF 릴레이 방법 간에 상호 작용하는 경우에만 사용할 수 있습니다.
예를 들어, RFC2833을 통해 SIP 레그의 발신 자릿수에 대한 인바운드 다이얼 피어에서 dtmf-relay rtp-nte digit-drop 명령을 구성한 다음 아웃바운드 H.323 측에서 dtmf-relay h 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 신호 기능을 광고하는지 확인하려면 debug h245 asn1을 사용하여 H.245 TCS(Terminal Capability Set) 메시지 내에서 이 행을 확인합니다.
capability receiveUserInputCapability : dtmf : NULL
H.245 신호 전송 예
이것은 H245 신호 방법을 사용하여 지속 시간이 100msec인 숫자 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가 있는 엔드포인트는 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 릴레이 확인
요청되지 않은 NOTIFY(UN) 광고 예
엔드포인트가 UN(Unsolicited NOTIFY) 기능을 광고하는지 확인하려면 INVITE 메시지 내에서 이 줄을 찾고, INVITE에 대한 응답 메시지를 디버그 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“
요청되지 않은 NOTIFY(UN) 전송 예
UN 메서드는 숫자를 NTFY 메시지 내에 이진 데이터로 전송합니다.따라서 디버그 ccsip 메시지를 사용하여 어떤 숫자가 전송되는지 확인할 수 없습니다.PCAP(packet capture)가 필요하거나 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(Key Press Markup Language) Advertisement 예
KPML 기능은 Allow-Events SIP 헤더 내에 나열됩니다.KPML 숫자 전송의 경우 전송 엔드포인트는 먼저 KPML 서비스에 서브스크립션을 보내야 합니다.기능을 요청하는 SUBSCRIBE 메시지가 전송됩니다.KPML 이벤트의 서브스크립션 상태를 활성으로 표시하는 수신 끝의 NOTIFY 메시지
기능을 광고하는 초기 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 메시지와 KPML 이벤트를 사용하여 XML을 통해 숫자를 전송할 수 있습니다.전송되는 숫자 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 Interworking Support에 대한 자세한 내용은 CUBE Configuration Guide의 DTMF Interoperability Table 섹션을 참조하십시오.
DTMF를 위해 CUBE에 트랜스코딩 리소스가 필요한 경우는 언제입니까?
CUBE에는 이러한 시나리오에서 로컬로 등록된 트랜스코딩 리소스가 필요합니다.
- RFC2833과 Voice In-band 간의 상호 작용
- OOB 메서드와 RFC2833 간의 상호 작용을 통해 플로우 주변 호출 수행
CUBE는 트랜스코더 없이 플로우 스루 호출과 다른 모든 DTMF 릴레이 메서드 간에 상호 작용할 수 있습니다.
인밴드 G711과 RFC2833 간의 DTMF 인터워킹
CUBE는 인밴드 G711 DTMF(원시 오디오 신호음) 간에 RFC2833에 상호 작용할 수 있습니다. 그러나 이러한 요구 사항을 충족해야 합니다
- 사용된 코덱은 G711 엔드 투 엔드 이어야 합니다.이는 LBR 코덱을 사용해야 할 경우 압축 손실 때문에 신호음이 왜곡되기 때문에 제한됩니다.
- 트랜스코딩 리소스를 사용할 수 있어야 하며 그에 따라 CUBE에 등록해야 합니다.이는 CUBE가 트랜스코딩 리소스를 할당해야 하기 때문입니다(특히:미디어 RTP 스트림에 대한 DSP 리소스)를 사용하여 오디오 스트림 내에서 신호음을 삽입하거나 들을 수 있습니다.
- 인밴드 신호음 레그의 다이얼 피어는 구성된 DTMF 릴레이 명령이 없어야 합니다.
- RFC2833 레그의 다이얼 피어는 dtmf 릴레이 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 리소스가 필요한 시기는 언제입니까?
MTP 리소스는 CUCM이 두 디바이스 간에 서로 다른 DTMF 메서드를 상호 운용해야 할 때 필요합니다. 이 중 하나는 RFC2833 메서드를 특별히 사용하고 다른 하나는 OOB 메서드를 사용합니다.이 시나리오에서는 두 끝 간의 DTMF 릴레이 불일치로 인해 CUCM이 대역 내 신호음을 전송 및/또는 탐지하는 데 필요한 리소스를 할당해야 합니다.
MTP의 역할은 RTP 트래픽을 모니터링하고 RFC2833 레그에서 NTE 이벤트를 탐지하거나 CUCM이 요청하는 경우 NTE 이벤트를 RTP 스트림에 삽입하는 것입니다.MTP가 RFC2833만 지원하는 엔드포인트에서 인바운드 NTE 이벤트를 탐지하면 CUCM에 SCCP StationNOTIFYDtmfToneMessage를 보내 스트림에서 탐지된 신호음을 알립니다.그러면 CUCM은 OOB(signaling protocol)를 사용하여 동일한 숫자를 다른 끝으로 전송합니다.CUCM이 OOB DTMF 엔드포인트에서 OOB DTMF 신호를 수신하면 MTP가 NTE 이벤트 형식으로 요청된 신호음을 RTP 스트림에 삽입할 수 있도록 SCCP StationSendDtmfToneMessage를 MTP로 보냅니다.
CUCM에서 지원하는 MTP 디바이스
소프트웨어 MTP(Cisco IP Voice Media Streaming Application)
소프트웨어 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 및 passthrough에서 하나만 구성할 수 있습니다.이 중 일부는 CUCM 구현과 관련이 없습니다.
라우터 컨피그레이션은 최대 1,000개의 개별 스트림을 허용하며, 10MB의 트래픽을 생성하는 트랜스코딩 세션 500개를 지원합니다.Cisco ISR G2s 및 ASR 라우터는 이보다 훨씬 더 많은 수를 지원할 수 있습니다.
이 MTP는 CPU 사이클을 사용하여 작동합니다.CPU 성능에 영향을 주고 높은 CPU 사용률을 트리거할 수 있으므로 활성화된 세션 수를 기록합니다.
하드웨어 MTP(PVDM2, Cisco NM-HDV2 및 NM-HD-1V/2V/2VE)
이 하드웨어는 PVDM-2 모듈을 사용하여 DSP를 제공합니다.
하드웨어 MTP(Cisco 2900 및 3900 Series 라우터(PVDM3 포함)
이 라우터는 마더보드나 PVDM2에서 기본적으로 PVDM3 DSP를 사용하며, 마더보드나 서비스 모듈에는 어댑터가 있습니다.
소프트웨어 또는 하드웨어 MTP는 언제 사용해야 합니까?
네트워크에서 구축할 MTP의 유형은 통화 흐름의 엔드포인트, 게이트웨이 및 트렁크에서 지원하는 특정 코덱의 매개변수에 따라 달라집니다
- 사용할 코덱의 종류
- 사용할 코덱의 패킷 크기(패킷 크기)
- T.38 팩스 사용(Codec Pass-Through 지원 필요)
이러한 매개변수에 따라 네트워크에 필요한 올바른 리소스를 안전하게 선택하고 구축할 수 있습니다.
표에 나와 있는 것처럼, 서로 다른 MTP 및 트랜스코더 유형에서 지원하는 다양한 기능
| 유형 |
동일 코덱스 |
다른 코덱스 |
다른 패킷 |
Codec 통과 |
참고 |
| CUCM SW MTP |
예 |
아니요 |
예 |
아니요 |
G711 Alaw-Ulaw 트랜스코딩 및 리커티화 |
| IOS HW MTP |
예 |
아니요 |
아니요 |
예 |
동일한 패킷화만 지원하면 모든 코덱과 동일한 맛이 지원됩니다.트랜스코딩이 없습니다. |
| IOS SW MTP |
예 |
아니요 |
아니요 |
예 |
동일한 패킷화만큼 코덱과 같은 맛을 지원합니다.트랜스코딩이 없습니다. |
| IOS Regular Xcoder |
예 |
예 |
예 |
예 |
G711u/G711a가 한 개 이상 있는 경우, 모든 리코딩 및 트랜스코딩을 지원합니다. |
| IOS Universal Xcoder |
예 |
예 |
예 |
예 |
모든 코덱에서 패킷 및 트랜스코딩 지원 |
CUCM의 MTP 컨피그레이션에 대한 자세한 내용은 Media Termination Point 컨피그레이션 예를 참조하십시오.
MTP에 대한 CUCM MRG(미디어 리소스 그룹) 및 MRGL(미디어 리소스 그룹 목록) 고려 사항
MRG(Media Resource Groups) 및 MRGL(Media Resource Group Lists)에 미디어 리소스를 생성하고 할당할 때 특정 통화 흐름에 대한 최상의 리소스를 초과 구독하지 않고 그에 따라 우선 순위를 지정할 수 있습니다. CUCM은 통화에 사용할 최상의 장치를 선택할 수 없기 때문입니다. 통화에 대해 미디어 리소스를 선택할 때 MTP 및 트랜스코더 목록에 동일한 우선 순위 또는 순서가 있는 경우 해당 장치를 선택할 수 없기 때문입니다.대신 요청된 기능을 지원하는 첫 번째 디바이스를 선택합니다.따라서 통화가 두 레그에서 G711을 사용하는 경우에도 첫 번째 디바이스가 트랜스코더인 경우 이를 통화에 대한 MTP로 할당하고 MTP 리소스를 더 이상 찾지 않습니다.
또 다른 유사한 동작은 범용 트랜스코더와 일반 트랜스코더가 모두 있을 때 발생합니다.CUCM은 먼저 레그 중 하나가 G711인 통화에서 일반 트랜스코더를 사용하고, 통화가 G711 이외의 코덱을 사용하는 대상으로 전송될 때 실패할 수 있습니다. CUCM은 통화가 전송될 때 현재 트랜스코더를 릴리스하지 않고 다른 트랜스코더를 가져올 것이기 때문입니다.
이러한 동작을 해결하는 가장 좋은 설계 방법은 모든 MTP 전용 디바이스를 단일 MRG에 할당한 다음, 범용 트랜스코더를 다른 MRG에, 일반 트랜스코더를 세 번째 MRG에 할당하는 것입니다.MRGL 내에서 동일한 순서로 우선순위를 지정합니다.이제 이 설계는 모든 토폴로지에 사용할 수 없으며, 사례별로 검토해야 합니다.
SCCP MTP 메시지
이러한 SCCP 메시지는 DTMF 처리를 위해 CUCM과 MTP 리소스 간에 교환됩니다
- 역기능자원
- 스테이션 업데이트 기능
- StationSubscribeDtmfPayloadReq
- StationSubscribeDTMFPayloadErrv
- 스테이션SubscribeDtmf페이로드Res
- StationUnsubscribeDtmfPayloadErr
- 스테이션NOTIFYDtmfToneMessage
- 스테이션 전송 dtmf신호음메시지
- StationUnsubscribeDtmfPayloadReq
- StationUnsubscribeDtmfPayloadRes
CUBE에 대한 CUCM SIP 트렁크
CUBE는 구성에 따라 DTMF 메커니즘으로 KPML, NTE 또는 Unsolicited Notify를 지원합니다.시스템에 엔드포인트가 혼합되어 있을 수 있으므로 MTP 요구 사항을 최소화하기 위해 CUBE에 여러 방법을 동시에 구성할 수 있습니다.
CUBE에서 sip-kpml 및 rtp-nte를 SIP 다이얼 피어 아래에 DTMF 릴레이 방법으로 구성합니다.이 컨피그레이션은 MTP 리소스 없이 NTE만 지원하는 엔드포인트 및 OOB 방법만 지원하는 엔드포인트를 포함하여 모든 유형의 엔드포인트와 DTMF 교환을 활성화합니다.이 컨피그레이션에서는 게이트웨이가 CUCM과 NTE 및 KPML을 모두 협상합니다.NTE가 Unified CM 엔드포인트에서 지원되지 않는 경우 DTMF 교환에 KPML이 사용됩니다.두 방법을 모두 성공적으로 협상하면 게이트웨이는 NTE를 사용하여 숫자를 수신하고 KPML에 가입하지 않습니다.
CUBE에는 DTMF에 대해 UN(Uninsolicited Notify) 메소드를 사용할 수도 있습니다.UN 메서드는 DTMF 신호음을 설명하는 텍스트가 포함된 본문과 함께 SIP Notify 메시지를 보냅니다.이 방법은 Unified CM에서도 지원되며 sip-kpml을 사용할 수 없는 경우 사용할 수 있습니다.DTMF 릴레이 방법으로 sip-notify를 구성합니다.이 방법은 Cisco 독점 방식입니다.
NTE 릴레이에만 대해 구성된 CUBE는 NTE를 지원하지 않는 엔드포인트와 통신할 때 CUCM 측에서 할당되는 NTE 및 필수 MTP 리소스만 제공할 수 있습니다.
CUCM SIP 트렁크 MTP 요구 사항에 대한 자세한 내용은
CUBE에 대한 CUCM H323 트렁크
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가 필요하므로 H245 영숫자를 H323 레그에서 사용할 수 있습니다.
CUBE 동적/비대칭 페이로드
IOS 버전 15.1(1)T(CUBE 1.4)부터 DTMF용 동적 페이로드 유형 인터워킹 및 SIP-SIP 호출용 코덱용 패킷에 대한 지원이 도입되었습니다.
이 기능을 사용하면 CUBE에서 다음 상호 작업을 처리할 수 있습니다.오디오/비디오 코덱을 위한 동적 페이로드 유형, NSE 및 DTMFIOS가 고정 범위를 예약하고 동일한 페이로드 유형을 두 통화 레그에서 협상할 수 있도록 허용하며, 일치하지 않는 오디오/비디오/NSE codecs(또는 일치하지 않는 NTE 페이로드를 위해 음성 인밴드 G711 DTMF로 대체)에 대해 488 오류 응답으로 통화를 거부하므로 이 시점까지의 제한이 있었습니다.따라서 이 기능을 사용하면 CUBE가 SIP 공급자 또는 다른 페이로드 유형을 사용하는 서드파티 디바이스와의 상호 연동을 위해 동적으로 페이로드 유형을 예약 해제하거나 사용 가능하게 할 수 있습니다. 이 디바이스는 서로 다른 페이로드 유형을 지원하지 않거나 특별히 다른 매핑을 필요로 합니다.
CUBE의 통화 레그는 제안 및 엔드포인트와의 응답 중에 SDP를 통해 교환되는 페이로드 유형 값에 따라 대칭 또는 비대칭으로 간주됩니다.
- 대칭 엔드포인트는 NTE 이벤트에 대해 동일한 페이로드 유형 또는 통화 레그에 대한 특정 코덱을 수락하고 전송합니다.
- 비대칭 엔드포인트는 NTE 이벤트 또는 통화 레그에 대한 특정 코덱에 대해 서로 다른 페이로드 유형을 수락하고 전송할 수 있습니다.
이 명령은 비대칭 페이로드의 사용량을 지정하는 데 사용할 수 있습니다.이 명령은 음성 서비스 voip에서 sip config 모드를 입력하거나 음성 클래스 sip CLI를 사용하여 다이얼 피어 수준에서 전역적으로 적용할 수 있습니다.
asymmetric payload {dtmf | dynamic-codecs | full | system}
동적/비대칭 페이로드에 대한 자세한 내용은 DTMF용 동적 페이로드 유형 인터워킹 및 SIP-SIP 호출용 코덱형 패킷으로 이동하십시오.
대칭 페이로드 예
다음은 SDP가 대칭 페이로드 협상을 위해 어떻게 보이는지 그리고 DTMF 신호음이 전송되는 동안 debug voip rtp 세션에서 event라는 출력을 출력하는지 보여주는 예입니다.IOS를 강제 적용하는 데 사용된 컨피그레이션에서는 rtp payload-type nte 명령을 사용하여 NTE 이벤트에 대해 다른 페이로드 유형을 사용해야 합니다.
DTMF 릴레이 협상
DTMF 릴레이 전송
비대칭 페이로드 예
다음은 SDP가 비대칭 페이로드 협상을 위해 어떻게 보이는지, DTMF 신호음이 전송되는 동안 debug voip rtp session named event command의 출력을 보여줍니다.IOS가 rtp 페이로드 유형 nte 명령 및 음성 클래스 sip 비대칭 페이로드 dtmf CLI를 사용하여 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을 통한 인밴드(in-band) 방식을 선호합니다.
- CUCM 또는 CME로 SIP 트렁크 - RFC2833 및 KPML을 모두 활성화합니다.
- CUE로 SIP 트렁크 - CUE의 기본 방법은 UN이지만 NTE를 사용하도록 구성할 수도 있습니다.SIP 공급자에서 CUE 시스템으로 통화가 전달되는 경우에도 가장 좋은 옵션입니다.
관련 정보
IP-IP 게이트웨이에 대한 Universal Voice Transcoding 지원
Unified Border Element 트랜스코딩 컨피그레이션 예
Cisco Unified Communications Manager를 사용하여 트랜스코딩 및 미디어 종료 지점 구성
피드백