2008년 9월에 “CUCM 6.1의 새로운 기능” 이라는 글을 쓴 지 벌써 9개월이 넘었습니다. 오래동안 시스코의 IP PBX인 CUCM (Cisoc Unified Communications Manager)의 기능에 대해 신경쓰지 않았는 데, 얼마전에 데이타시트를 보다보니 새로운 기능들이 많이 추가된 것을 보니 한 번 즈음 정리를 해야 겠다는 생각이 들었습니다. 오늘에서야 간단하게 정리를 하게 되었습니다.
이 글은 “Cisco Unified Communications Mnager Version 7.0 데이타시트” 및 CUCM 7.x SRND를 기초로 작성되었습니다.
개요
CUCM 7.0은 아래그림과 같이 언제 어디서나 누구와도 효과적 협업이 가능하도록 크게 세가지 요소를 중심으로 개발되었습니다.
- Open System
SIP를 통한 Line side 및 Trunk side 기능을 강화하여 상호 운영성 및 표준화를 확장합니다. 따라서, SIP를 이용한 사용자 기능이 확대되고, IBM Sametime 및 MOC (Microsoft Office Communicator)와 통합이 증대되도록 개발되었습니다.
- Improved TCO
Local Route Group 또는 “+” Dialing 등과 같은 기능들을 통해 관리적인 부담을 최소화하도록 개발되었습니다. 기존의 Dialplanning은 사이트가 늘어날수록 기하급수적으로 늘어나는 Route pattern, Route List, Route Group을 최소한으로 줄일 수 있도록 되어 있습니다.
- User Experience
Unified Mobility 기능 강화 및 Phone Designer 와 같은 개인화 기능에 초점을 두어 사용자가 쉽고 재미있게 사용할 수 있습니다.
이러한 세 가지 사항을 중심에 두고 개발한 다양한 기능들을은 점점 협업에 대한 사용자 요구를 충족하며, 관리적 부담을 최소화하도록 개발되었습니다. 대부분의 기능은 CUCM 6.0 데이타시트의 이해 연재에 기술되어 있으므로, 여기에서는 추가된 기능을 위주로 알아보고, 용어나 잘 모르는 내용은 기존의 연재를 참조하시기 바랍니다.
For Easier Administration, Saving You Time and Resources
- Calling party number normalization
발신번호에 대한 조작이 쉽게 이루어질 수 있으므로, 사용자는 Call logs나 부재중 호 리스트에서 전화번호를 바로 선택하므로 다이얼링이 가능합니다. 즉, 기존에 사용자가 “Edit dial”을 통해 조작했던 부분이 많이 줄어 들수 있습니다. 아래 그림처럼 044208001로 부터 전화가 들어왔지만, 이 번호를 외부 발신 국제호로 변경하여 Call logs에 기록되도록 합니다.
이는 게이트웨이나 트렁크를 통해 들어오는 호에 대한 발신번호를 일반적인 포맷 (E.164 방식)으로 변경하도록 하는 것을 CUCM 7.0에서 지원하기 때문에 가능합니다. 수신 호의 number-type 따라 변환방식을 따로 지정할 수 있으며, number-type은 Unknown, Subscriber, National, International로 구분됩니다.
H.323 게이트웨이 및 Trunk에서는 각 Number-Type에 따른 Prefix digits을 사용할 수 있습니다. 안타깝지만 SIP의 경우 Number-type을 시그널링을 통해 전송할 수 없으므로, Calling party number nomalization을 사용할 수 없습니다. 그래서, SIP 게이트웨이에서 이를 미리 수행하여 전송해야 합니다. 아래는 간단하게 게이트웨이에서 수행할 수 있는 calling party number nomalization의 예제입니다.
voice translation-rule 1
rule 1 // /+4940/ type subscriber subscriber
rule 2 // /+49/ type national national
rule 3 // /+/ type international international
...
voice translation-profile 1
translate calling 1
...
dial-peer voice 300 voip
translation-profile outgoing 1
destination-pattern .T
session protocol sipv2
- E.164 with “+” dialing
대부분의 GSM 네트워크에서는 국제 통화를 할 경우 +로 시작하는 전화번호를 사용합니다. 우리나라에서는 익숙하지 않은 것이지만, 싱가폴 같은 곳에서는 익숙한 패턴이며 출장을 가보신 분들은 한국으로 전화걸기 위해서 항상 “+” 넣고 다이얼링 했던 것을 기억하실 것입니다. 또한, Microsoft의 OCS 2007같은 서버에서도 +표시를 사용합니다. “+” 사인을 전화기의 키패드를 통해서 입력할 수는 없지만, 전화기 상에서 스피트다이얼 및 Call logs (수신호, 부재중 호, 발신호)에 표시는 가능하며, 전화번호에 대한 Transulation이 가능해서 트렁크 연결 구간에서 유용하게 사용할 수 있습니다.
- Local route groups and transformation
CUCM 7.0에 있어서 가장 대표적인 기능이라면, Local Route Group을 들 수 있습니다. 기존의 CUCM으로 Dial Plan을 해 보신 분들은 얼마나 복잡하게 구성되는 지를 이해하실 것입니다. 만일 100개의 사이트가 있고 10여개의 Route Pattern이 있다고 한다면, 1000개의 Route Pattern이 필요하게 되고, 100개의 Route List, 100개의 Route Group이 필요하다는 것을 이해하실 것입니다. 이를 획기적으로 줄여줄 수 있는 것이 바로 Local Route Group입니다.
예를 들면, 9001로 시작하는 국제호는 하나의 패턴으로 정의 될 수 있습니다. 9001 이라는 Route Pattern에 매치되면, 발신 전화기에 매핑된 Local Route Group을 통해 호가 이루어지는 것입니다. 부산에 있는 전화기는 부산 게이트웨이를 통해서, 대구에 있는 전화기는 대구 게이트웨이를 통해서 호가 이루어지는 것으로 사이트가 아무리 많아도 하나의 Route Pattern으로 모든 호를 처리할 수 있는 것입니다.
위의 그림에서 보듯이 세 개 지역의 전화기들이 같은 Route Pattern을 사용할 경우 Local Route Group 을 이용하여 각 지역의 게이트웨이를 통해 호가 이루어지는 것을 나타냅니다. 기존의 방식으로 위 그림과 같이 표현할 려면, 같은 패턴의 Route Pattern이 3개 필요하고, 각각의 Route List와 Route Group이 필요했었습니다.
Local Route Group은 Device Pool과 연계되어 있습니다. 따라서, 각 사이트마다 다른 Device Pool을 사용하는 것이 일반적이므로 쉽게 구성이 가능합니다. 이는 Device Mobility를 쉽게 구현할 수 있도록 해줍니다. 사용자가 Cisco Wireless IP Phone 7925G를 들고 서울에서 부산으로 이동하게 되면, IP address를 통해 자동으로 부산의 Device Pool을 적용받게 되어 쉽게 부산의 게이트웨이를 사용하게 됩니다.
착신 및 발신 번호 변경 (Transformation Pattern)의 경우 기존에 Route Pattern 또는 Route List에서 변경이 가능했습니다. 따라서, 같은 Route Pattern이라도 서로 다른 게이트웨이를 타는 경우 Prefix를 다양하게 붙여되는 문제점이 있었습니다. 이는 TEHO (Tail End hop off)의 경우 비일비재하게 발생했던 문제입니다 이를 numbering-type과 연계하므로 인해서 호 라우팅별로 별도의 prefix digits을 삽입 또는 제거하지 않게 되었습니다. 아래 그림에서 보듯이 RTP로 나가야 할 호가 게이트웨이 Fail 똔느 회선 혼잡으로 인해 San Jose로 우회해야 할 경우 착 발신 번호가 변경되어야 합니다만, Transformation pattern에 의해 쉽게 가능합니다. 기존의 관리적 부담이 최소화 되었다고 할 수 있습니다.
- Trustd relay point (TRP)
TRP는 기존의 ISR 라우터 상에 실행되는 MTP (Media Termination Point)와 비슷합니다. 몇몇 특정한 기능을 위한 미디어 스트림에 대한 앙커(anchor) 포인트로 사용됩니다. 예를 들면, Trusted VLAN Traversal 또는 QoS Enforcement 와 같은 기능입니다. 즉, MTP는 단순히 실제 RTP 종단에 그 의미를 부여할 수 있다면, TRP는 그와 연계하여 새로운 부가기능을 추가할 수 있습니다.
일반적으로 IP Telephony망을 디자인할 경우 Voice VLAN과 Data VLAN을 분리하거나, 별도의 VRF를 통해 완벽하게 분리되는 경우가 종종있습니다. 이는 PC 또는 데이타 트래픽이 Voice 망에 대한 접근하지 못하도록 설정하여 음성망에 대한 보안을 유지하기 위함입니다. 그러나, 현재 대부분의 IPT 네트워크에서는 IP Communicator 또는 CUPC와 같은 Software-based UC Application을 사용합니다. 이들과 데스크탑 전화기와의 통화가 필요하게 됩니다. 기존의 보안정책을 유지하면서, 통화하기 위해 이러한 TRP와 같은 것이 필요하게 됩니다. 아래그림은 QoS Enforcement와 Trusted VLAN Traversal에 대해 간략히 이해할 수 있도록 되어 있는 그림입니다.
향후에는 TRP를 통해 전화기의 IP address Hiding, Call Monitoring and Recording, 음성 품질 분석, IPv4-IPv6 변환, unicast-multicast 변환, SRTP-RTP 변환 등에 사용될 수 있습니다.
여기서, MTP와 TRP를 잠시 짚어보겠습니다. MTP를 설정하기 위해서는 CUCM에서 “MTP Required”를 선택해야 하지만, SIP 및 H.323 device에 대해 설정이 가능했습니다. TRP는 Media를 종단하는 모든 단말에 대해 “Use TRP” 설정이 가능합니다.
- Intelligent bridge seleciton
Cisco IPT 네트워크에서는 사용자가 음성 또는 영상 다자간 회의를 구성할 때 MGRL을 이용합니다. 그래서, 사용자가 다자간 회의를 구성하게 되면, 항상 MGRL의 리스트에 따라 자원을 사용하게 됩니다. 음성 참가자와 영상 참가자가 동일한 리소스를 할당받음으로 인해 자원 낭비를 초래하게 됩니다. CUCM은 Intelligent Bridge Seletion 을 통해 참가자가 음성만을 쓰는 지 영상도 함께 다자간 회의를 하는 지를 확인하고 자동으로 리소스를 할당하도록 합니다. CUCM의 리소스를 이용하는 Meet-me나 Phone 기반의 Barge같은 경우에는 이 기능을 지원하지 않습니다.
마치며
LRG 나 TRP 같은 경우에는 따로 내용을 만들어도 될 만큼 방대한 내용이기에 생각보다 길어졌습니다. 이 글도 쓰다보니 몇편의 연재로 만들어야 겠습니다. 시간나는 대로 조금씩 올리도록 하겠습니다. 이 글 전에 CUAE 및 In-line power switch라는 글을 올렸는 데 영 반응이 없습니다. 아마도 많은 분들이 폭 넓게 UC를 바라보고 있지는 않은 듯합니다. CUAE도 연재로 생각했었는 데 영 포기해야 할 모양입니다. -,-:?
