CUBE 작업, 구성, 문제 해결 설명서를 통한

다운로드 옵션

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

업데이트:2013년 9월 12일

문서 ID:116392

편견 없는 언어

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

이 번역에 관하여

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

소개

이 문서에서는 Cisco CUBE(Unified Border Element)를 통한 MMoH(Multicast Music-on-Hold)의 작업, 구성 및 문제 해결 정보에 대해 설명합니다.

이 문서의 핵심은 멀티캐스트 MoH(Music-on-Hold)이지만 MoH의 일반적인 작동 방식을 설명하는 데 상당한 부분이 사용됩니다.이 추가 정보를 통해 초급 학습자가 MoH 관련 문제를 더 잘 인식하고 인식하도록 기본 지식을 구축할 수 있습니다.

참고:원칙은 동일하지만 Cisco CUBE-SP(Unified Border Element-Service Provider Edition)는 이 문서의 범위에 속하지 않으며 Cisco CUCM(Unified Communications Manager)과 관련이 없는 환경에서도 CUBE 사용을 금지합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

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

배경

참고:H.323에 대해 설명한 몇 가지 시나리오를 제외하고 이 문서의 대부분의 모든 부분에서 SIP(Session Initiation Protocol) 신호 처리가 사용됩니다.

MoH 개요

MoH는 발신자가 대기 상태일 때마다 재생됩니다.통화 보류는 통화 착신 전환 또는 호전환과 같은 보조 서비스 프로세스가 구현될 때 사용자 또는 네트워크에 의해 시작됩니다.이 전자를 사용자가 시작한 보류, 사용자 보류 또는 사용자 보류라고 합니다.후자는 네트워크에서 시작한 보류, 네트워크 보류 또는 네트워크 보류로 표시됩니다.

MoH가 TDM(Time Division Multiplexing) 게이트웨이와 어떻게 연동되는지 살펴보겠습니다.이 그림에서는 통화 보류 시나리오와 관련된 구성 요소 및 연결을 보여 줍니다.

통화를 대기 상태로 전환하려면 2단계 프로세스가 필요합니다. 이 그림에서는 다음 두 단계를 보여 줍니다.

팁:MoH 구성을 정렬하고 문제를 해결하려고 할 때 이 2단계 프로세스를 기억하십시오.

MoH 소스

보류된 통화를 발신자를 홀더라고 하며, 보류된 사용자(MoH를 듣고 MoH를 받는 사용자)를 홀드라고 합니다. 각 측은 재생되는 음악의 특정 측면을 결정합니다.

음악 출처는 홀더에 의해 결정됩니다.결정은 이 계층 구조를 따릅니다.

DN(도메인 이름)에 구성된 음악 소스
디바이스에 구성된 음악 소스
디바이스 프로필의 음악 소스(사용자 보류 음악 소스만 해당)
글로벌 레벨의 음악 소스(서비스 매개변수 또는 예)

사용자 보류 및 네트워크 보류라는 두 가지 음악 소스가 있습니다.음악 소스에 대한 참조를 만들 때마다 사용자 보류 또는 네트워크 보류 음악 소스를 의미할 수 있습니다.

MoH 엔드포인트

MoH의 경우 CUCM 측의 엔드포인트는 MoH 서버입니다.코덱의 결정(영역 간 코덱의 컨피그레이션 기반)은 다음을 기반으로 하므로 이 점을 이해하는 것이 중요합니다.

MoH 서버 영역
트렁크/게이트웨이 영역

일반적인 권장 사항은 MoH 서버에 전용 영역을 할당하여 해당 지역과 다른 모든 영역 간의 영역 간 코덱이 g.711(또는 MoH를 위해 스트리밍할 기타 코덱이 되도록 합니다.

CUCM 관점에서 통화에 관련된 엔드포인트는 두 전화기가 아니라

CUCM에 등록된 IP 전화
게이트웨이/CUBE

따라서 CUCM은 문제의 게이트웨이/CUBE를 가리키는 트렁크를 엔드포인트로 취급하며, 음악 스트림을 렌더링하는 방법을 결정하기 위해 해당 트렁크와 관련된 리소스를 살펴봅니다.

MoH VoIP 프로토콜

MoH는 본질적으로 단방향 오디오 대화입니다.신호 표시 방법은 사용된 VoIP 프로토콜에 따라 달라집니다.예를 들어, SIP에서는 direction 특성을 통해 전달됩니다.H.323에서 CUCM은 0000000을 네트워크 주소로 지정하고 0을 H.245 OLCAck(Open Logical Channel Ack) 메시지에서 MoH 서버의 포트(tsapIdentifier)로 지정합니다.

참고:Moh의 경우 CUCM은 멀티캐스트 주소(예: 239.1.1.1)을 네트워크 주소로 전송합니다.

CUBE와 관련된 통화 흐름에서 CUCM은 CUBE와 ITSP(Internet Telephony Service Provider) 간의 통화 레그에 대해 알지 못합니다. CUCM은 IP 전화와 SIP 트렁크(CUBE로 이동) 간의 통화 레그에만 사용됩니다.

MoH를 위한 신호 처리 과정은 범위가 축소되어 새로운 대화를 위한 시그널링과 유사합니다.예를 들어, SIP에서는 이미 존재하는 대화 상자 컨텍스트 내에서 대화가 이루어집니다.[1]

미디어 스트림 비활성화

앞서 언급한 2단계 프로세스의 첫 번째 단계는 미디어 스트림을 비활성화하는 것입니다.

이 이미지는 SIP에서 미디어 스트림을 비활성화하는 방법을 보여줍니다.

SIP 구현은 하나 또는 둘 다 특성(?a=?및 ?C=IN ?)은 미디어 스트림이 비활성화되었음을 나타내는 데 사용됩니다.

이 그림에서는 H.323에서 미디어 스트림을 비활성화하는 방법을 보여 줍니다.

MoH에 연결

앞서 언급한 2단계 프로세스의 두 번째 단계는 MoH에 연결하는 것입니다.오디오 스트림이 비활성화되면 CUCM은 홀더가 MoH 소스를 수신하게 하는 단방향 MoH 대화에 신호를 보냅니다.

이 프로세스의 일부로서 CUCM은 트렁크와 연결된 홀더의 미디어 기능 및 MRGL(Media Resource Group List)을 고려하면서 스트리밍 매개변수를 결정합니다.따라서 이에 대한 신호 처리는 항상 Delayed Offer(DO)[2](SIP)입니다.

실제 INVITE 트랜잭션 수는 다릅니다.예를 들어, CUCM은 DO INVITE 트랜잭션을 하나만 사용하여 홀드를 MoH에 연결합니다.또는 DO INVITE를 사용하여 홀더의 미디어 기능을 수집하고 후속 EO INVITE를 사용하여 홀드를 MoH에 실제로 연결합니다.

이 그림에서는 SIP에 대한 트랜잭션을 보여 줍니다.

이 그림에서는 H.323에 대한 트랜잭션을 보여 줍니다.

이 이미지는 상호 작업 환경에서 신호 메시지 시퀀스를 보여 줍니다(예: CUBE의 한 쪽이 SIP이고 다른 쪽이 H.323인 경우).

통화에 미디어 리소스를 사용하는 경우

미디어 리소스(MTP(MediaTermination Point) / Transcoder)는 대부분의 부분에 대해 CUBE-to-IT 서비스 공급자(ITSP) 호출 레그를 보호합니다.미디어 리소스가 CUBE를 통한 통화에 사용되는 경우 MoH에 대한 신호에는 CUCM과 미디어 리소스 간의 SCCP(Skinny Client Control Protocol) 메시지가 주로 포함됩니다.CUBE 트렁크가 아닌 보류된 미디어 리소스입니다.MTP/Transcoder가 MoH(SIP로 가정)를 수신 대기하도록 신호를 받은 후 CUCM은 SIP UPDATE 메시지를 CUBE에 보냅니다.이렇게 하면 분기 매개 변수가 업데이트되며, 이는 새 트랜잭션(MOH 대화)을 식별합니다.

통화 다시 시작

재시작 프로세스는 주문이 취소된다는 점을 제외하면 보류 프로세스와 유사합니다.

현재 오디오 스트림을 사용할 수 없습니다.
통화를 보류한 전화기에 보류를 다시 연결하기 위해 다른 DO 재초대가 전송됩니다.

SDP 특성

SDP(Session Description Protocol)의 X-cisco-media:umoh 특성이 ICT(Inter-Cluster Trunks)[3]을 통한 MoH 신호 처리를 간소화하기 위해 도입되었습니다.서로 다른 프로토콜을 사용하는 엔드포인트 간의 상호 운용성을 통해 CUCM은 종종 직관적이지 않은 어설프고 중간 시그널링을 수행합니다.추측에 의한 작업을 방지하고 시그널링 컨텍스트를 명시적으로 지정하기 위해 X-cisco-media라는 전용 SDP 특성이 사용됩니다.

CUCM 버전 8.5 이상에서는 MoH가 Unicast Music on Hold(UMoH) 또는 MoH로 설정된 이 속성으로 신호를 받을 수 있습니다. 이 속성은 보류 중인 대상에 대한 MoH 시나리오를 나타내기 위해 위조 포트 값에 의존하지 않습니다.

참고:이는 CUBE를 사용한 MoH 신호에는 영향을 주지 않습니다.

CUBE의 MoH

CUBE에서는 기본 프로세스가 동일하게 유지됩니다.그러나 [5] CUBE는 Cisco IOS가 MoH를 변환하지 않는 한 반드시 고려해야 합니다^.버전 15.3T.즉, 트랜스코더가 필요하지 않도록 CUCM-to-CUBE 레그의 코덱을 선택하는 데 영향을 주는 요인을 주의해야 합니다.

참고:여기서 참조하는 트랜스코더는 CUCM과 반대로 CUBE에서 삽입됩니다. CUCM에 관한 한 CUCM은 대상이며 MOH Server-to-CUBE 경로에 트랜스코더가 포함되지 않습니다.

Codec 고려 사항

일반적으로 CUCM-to-CUBE 레그에 사용되는 코덱에 몇 가지 요소가 영향을 주지만 MoH에는 다음 고려 사항이 적용됩니다.

MoH를 코드 변환할 수 없습니다.[5]
MoH는 G.711에서만 사용할 수 있습니다.

참고:이 항목은 코덱에 대한 여러 가지 좋은 문서가 이미 있으므로 이 문서의 범위를 벗어납니다. 이 부분에서는 이 항목을 다루기에는 중복됩니다.

시간

참고:지금까지 이 문서에 설명된 대부분의 정보는 MoH가 유니캐스트 또는 멀티캐스트 IP 패킷으로 스트리밍되는지 여부와 관련이 있습니다.

OH는 시스템 리소스와 대역폭을 유지합니다.멀티캐스트를 사용하면 여러 사용자가 동일한 오디오 소스 스트림을 사용하여 대기 중인 음악을 제공할 수 있습니다.대역폭 절약이 중요한 기업 네트워크에서는 MH가 바람직합니다.

다음은 CUBE가 인터넷을 통해 ITSP로 MooH를 전달할 때 발생하는 몇 가지 문제 및 문제입니다.

멀티캐스트 트래픽 도달 범위 - Cisco는 멀티캐스트 음악에 239.0.0.0~239.255.255.255 범위를 사용합니다.이 범위는 관리적으로 범위가 지정된 주소라고 합니다.이 블록은 비공개로 간주되므로 엔터프라이즈 네트워크에서 사용되며 기업 외부로 전달해서는 안 됩니다.일반적으로 경계 라우터는 그에 따라 구성됩니다.
VPN을 통한 멀티캐스트 - 기본적으로 IP 보안은 MMoH를 지원하지 않습니다.

CUBE는 다음과 같이 MMoH를 지원합니다.

CUBE는 MoH 서버에서 MoH 패킷을 수신합니다.
패킷을 유니캐스트 IP 패킷으로 변환합니다.
CUBE는 패킷을 ITSP로 전달합니다.

SIP 방향 특성 조작

RFC 3264에 설명된 대로:

"세션 설명에 수신(송신)으로만 나열된 멀티캐스트 미디어 스트림이 포함된 경우, offerer 및 answer를 포함한 참가자가 해당 스트림에서 수신(송신)만 받을 수 있음을 의미합니다.이는 방향이 오프러와 수퍼바이저 사이의 미디어 흐름을 나타내는 유니캐스트 보기와는 다릅니다.이러한 명확한 설명 외에도, 제공된 멀티캐스트 스트림의 의미 체계는 RFC 2327 [1]에 설명된 것과 정확하게 동일합니다."

따라서 CUCM이 멀티캐스트 IP 주소로 재초대하는 경우 direction 특성을 recvonly로 설정합니다.그러나 CUBE는 멀티캐스트 패킷을 유니캐스트 패킷으로 변환하므로 direction 특성을 ITSP를 사용하는 레그에서 sendonly로 설정해야 합니다.

이 그림에서는 논리를 보여 줍니다.

주소 조작

ITSP 발신자를 MoH 소스에 연결하기 위해 전송된 DO[6] 재초대에서 CUBE는 SIP SDP C=IN 필드에 고유한 IP 주소를 보냅니다.유니캐스트 주소입니다.

이 이미지는 엔드 투 엔드 뷰를 제공합니다.

참고:MH를 지원하려면 CUBE에서 Cisco IOS 버전 15.2(2)T 이상을 실행해야 합니다.

플래시에서 스트림

TDM 게이트웨이를 사용하면 게이트웨이에서 바로 멀티캐스트 음악을 스트리밍하여 추가적인 WAN 대역폭을 절감할 수 있습니다.따라서 MoH 서버가 본사에 있고 게이트웨이가 WAN 연결을 통해 원격 지점에 있는 경우 MoH를 전송하는 멀티캐스트 트래픽은 WAN을 통과하지 않고(본사에서 지사로) 귀중한 WAN 대역폭을 사용할 필요가 없습니다.

CUBE는 로컬 플래시 또는 아날로그 TDM 인터페이스를 통해 제공되는 MMoH를 스트리밍할 수 없는 트렁크 측 디바이스입니다.여전히 WAN 대역폭을 실현할 수 있습니다.이 작업은 원격 브랜치에서 MooH 스트림의 소스로 다른 음성 지원 라우터를 사용하여 수행됩니다.이 라우터는 플래시에서 MMoH를 스트리밍합니다.그런 다음 CUBE를 통해 해당 패킷을 수신하고 변환한 다음 유니캐스트 패킷으로 전달할 수 있습니다.

라이브 피드에서 스트림

라이브 피드에서 스트리밍하려면 이전 섹션에서 설명한 대로 CUBE가 라인 측 디바이스가 아니므로 다른 라우터를 구성해야 합니다.

OH 구성

이 섹션에서는 CUBE, CUCM 및 L3 지원 스위치에서 MOH를 구성하는 방법에 대해 설명합니다.

CUBE에서 MH 구성

다음 명령을 사용하여 CUBE에서 MMoH를 구성합니다.

ccm-manager music-on-hold
ip multicast-routing

CUCM에서 MH 구성

CUCM에서 MmH를 구성하려면 다음 단계를 수행합니다.

MoH 소스, MoH 서버 및 MRG(Media Resource Group)에서 멀티캐스트 기능을 활성화합니다.
1단계에서 MRG가 구성된 트렁크에 MRGL을 지정합니다.
IP 음성 스트리밍 응용 프로그램 서비스 매개 변수에서 코덱을 구성합니다.

참고:자세한 구성 단계는 Cisco Unified Communications System 9.0 SRND - 미디어 리소스 문서의 대기 중 음악 섹션을 참조하십시오.

L3 지원 스위치에 MMoH 구성

L3 지원 스위치에서 MMoH를 구성하려면 다음 명령을 사용합니다.

ip routing
ip multicast-routing

통화에 MTP를 사용하는 경우

MTP는 멀티캐스트 음악을 지원하지 않습니다.홀더는 공기만 수신합니다.[7]

참고:트랜스코더 역시 MTP입니다.

성능 고려 사항

모든 MMOH 패킷은 Cisco IOS에서 프로세스 스위칭됩니다.이는 소규모 구축에는 적합하지만 대규모 설치의 CUBE 성능에 큰 영향을 미칩니다.

제한 사항

다음은 MooH 사용에 대한 제한 목록입니다.

CUBE는 Cisco IOS 버전 15.2(2)T 이상이어야 합니다.
MmH는 AS54xx에서 지원되지 않습니다.
MH는 ISR-G1에서 지원되지 않습니다(28xx, 38xx 시리즈).
지원되는 코덱에 유의하십시오.

문제 해결

이 섹션을 사용하여 MmH 문제를 해결하십시오.

명령 표시 및 디버그

다음은 show 및 debug 명령의 목록과 그 의미입니다.

Show ccm-manager music - CUBE가 멀티캐스트 음악 패킷 수신 및 수신 여부도 알고 있는지 확인할 수 있습니다..

R1#show ccm-manager music
Current active multicast sessions : 1

 Multicast       RTP port   Packets       Call   Codec    Incoming

 Address         number     in/out        id              Interface

===================================================================

239.176.201.1     16384   956/956          237  g711ulaw  Se0/1/0

Show ip igmp members - 멀티캐스트 음악을 수신하라는 신호를 받은 경우 CUBE가 멀티캐스트 그룹에 성공적으로 참여했는지 확인하기 위해 사용됩니다.

이 세 가지 명령은 협상된 코덱과 엔드포인트의 IP 주소 및 포트 번호를 확인하는 데 사용됩니다.

Show call active voice compact
Show voip rtp conn
Show sip calls

다음은 첫 번째 명령의 출력 예입니다.

R1#show call active voice compact

 <callID>  A/O FAX T<sec> Codec       type        Peer Address       IP R<ip>:<udp>

Total call-legs: 2

       236 ANS     T53    g711ulaw    VOIP        P1003    239.176.201.1:16384

       237 ORG     T53    g711ulaw    VOIP        P919789362814    200.200.200.2:17808

통화 활성 음성 개요 표시 - 통화가 보류 중일 때 rx/tx 수가 증가하는지 확인하기 위해 이 명령을 실행합니다.

0    : 236 29262010ms.1 (*22:34:23.659 UTC Fri May 10 2013)
 +4190 pid:1000 Answer 1003 connected
 dur 00:01:38 tx:919/147040 rx:918/146880 dscp:0 media:0 audio tos:0xB8 video tos:0x0
 IP 239.176.201.1:16384 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
 g711ulaw TextRelay: off Transcoded: No
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a

0    : 237 29262010ms.2 (*22:34:23.659 UTC Fri May 10 2013)
 +4190 pid:2000 Originate 919789362814 connected
 dur 00:01:38 tx:8910/1425600 rx:919/147040 dscp:0 media:0 audio tos:0xB8 video tos:0x0
 IP 200.200.200.2:17808 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
 g711ulaw TextRelay: off Transcoded: No
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a

Show perf query class "Cisco MOH Device" - 이 CUCM CLI 명령은 MoH 리소스가 할당되었는지, 어떤 종류(유니캐스트 또는 멀티캐스트)를 신속하게 확인하기 위해 사용됩니다. 통화가 보류되고 다시 시작될 때 카운트가 동적으로 변경되므로 이 명령은 보류되지 않은 통화가 여러 개 있는 경우 유용하지 않습니다.

admin:show perf query class "Cisco MOH Device"

==>query class :

 - Perf class (Cisco MOH Device) has instances and values:

    MOH_2           -> MOHHighestActiveResources      = 0

    MOH_2           -> MOHMulticastResourceActive     = 0

    MOH_2           -> MOHMulticastResourceAvailable  = 250000

    MOH_2           -> MOHOutOfResources              = 1

    MOH_2           -> MOHTotalMulticastResources     = 250000

    MOH_2           -> MOHTotalUnicastResources       = 250

    MOH_2           -> MOHUnicastResourceActive       = 0

    MOH_2           -> MOHUnicastResourceAvailable    = 250

Debug ccm-manager music-on-hold - 이 명령은 통화 레그의 변경 방법을 추적하고(예: 현재 오디오를 비활성화하고 MoH를 연결할 때) CUCM이 지시하는 대로 IGMP(Internet Group Management Protocol) 그룹에 가입하는지 확인하는 데 사용됩니다.
Debug ip packet - 이 명령은 Wireshark의 대안으로 사용됩니다.그러나 이 명령은 CPU를 빠르게 압도할 수 있습니다.꼭 필요한 경우에만 사용하십시오.콘솔 로깅을 끄고 1초 이상 실행하지 마십시오.

시나리오 1

증상 - PSTN(Public Switched Telephone Network)에서 거는 통화는 양방향 오디오를 사용하여 양호합니다.그러나 IP 전화기에서 PSTN 발신자를 보류 상태로 설정한 다음 통화를 다시 시작하면 단방향 오디오 결과가 표시됩니다.IP 전화기에서 PSTN의 오디오를 듣지만 PSTN 사용자는 IP 전화를 들을 수 없습니다.

먼저 문제의 SIP 트렁크에서 Require SDP Inactive Exchange for Mid-Call Media Change(중간 통화 미디어 변경을 위한 SDP 비활성 교환 필요)가 비활성화되지 않도록 합니다[5].이렇게 하면 CUCM이 존재하는 미디어 경로를 끊기 위해 SDP에서 a=inactive로 다시 초대할 수 있습니다.

통화가 보류되면 CUCM은 SIP 트렁크[8]에 대해 Send-receive SDP in mid-call INVITE 확인란이 활성화된 경우 미디어 경로를 끊기 위해 비활성 SDP가 있는 재초대를 보내지 않습니다.미디어 모드가 비활성으로 설정된 후 전체(전송-수신) 서비스를 제공할 수 없는 디바이스에 대해서만 해당 컨피그레이션이 선택됩니다.

다음은 사용 가능한 확인란을 보여주는 이미지입니다.

참고:자세한 내용은 Cisco 버그 ID CSCtx84013을 참조하십시오.

시나리오 2

증상 - 발신자가 MMoH 대신 대기 상태일 때만 신호음이 표시됩니다.

일반적으로 이는 CUCM이 MMoH를 할당하지 않았음을 나타냅니다.

show perf query class?Cisco MOH Device?MOHOutOfResources 카운트가 증가하는지 확인하기 위한 CUCM CLI 명령입니다.
MMoH 소스, 서버 및 그룹에서 멀티캐스트가 활성화되었는지 확인합니다.

시나리오 3

증상 - 발신자가 대기 상태인 경우에만 데드-에어가 들립니다.

다음을 확인합니다.

멀티캐스트 라우팅은 CUBE 및 오디오 경로의 다른 라우터에서 활성화됩니다.
IP 라우팅 및 멀티캐스트 라우팅은 오디오 경로의 L3 스위치에서 활성화됩니다.
ttl(hop count)은 CUCM의 MoH 서버에 구성되며 홉을 수용할 만큼 큽니다.
트랜스코더가 필요한 경우 성공적으로 할당됩니다.
IP 음성 스트리밍 응용 프로그램에 구성된 코덱은 MoH에 사용되는 코덱을 지원합니다.

시나리오 4

증상 - 통화 보류 및 재시작을 위한 통화 주변 모드에서 통화가 실패합니다.

흐름 회선을 지원하려면 IPGW에서 다시 초대하거나 업데이트를 보내야 합니다.그러나 현재 지원되지 않습니다.따라서 DO-EO 통화의 흐름 회전은 지원되지 않습니다.마케팅에서 이러한 통화 흐름 요구 사항이 있을 경우 지원 고려 사항이 적용됩니다.Cisco 버그, SIP SIP SS DO-EO:통화 보류 및 재시작을 위한 통화 흐름 주변 모드에서 통화 실패는 향후 고려 사항으로 표시됩니다.