안녕하세요, 지난번 CUPS 블로깅을 할 때, 너무 오랜만에 글을 써서인지 툴 사용에 익숙하지 않아서 이미지에 문제가 있었는데요, 이번 글에는 클릭의 압박에서도 벗어나서, 아래 이미지를 클릭하면 시원시원한 화면을 보실 수 있을 겁니다. 그동안 넓은 부분을 한눈에 보여드리지 못해 항상 아쉬웠었는데, 해결되서 기분이 좋네요.
이번에는 현업에서 종사하시는 분이나 CCIE 준비하시는 분 모두 해당되는 내용인데요,
Multi Site Centralized Model일 경우에 Dial Plan이 예상과는 달리 많이 복잡해지고, 중복작업을 해야 하는 경우가 상당수 있었던 걸로 기억합니다.
실제로 분석해보면 Dial Plan의 최적화를 하지 못하게 하는 요소가 크게 두가지 인데요, 여러개의 Voice Gateway가 있는 경우와 다양한 콜권한(CSS)이 복합적으로 구성되는 경우입니다.
아래 그림은 CUCM이 본사에 있고, 각 지역의 사무실별로 VG가 있는 Multi Site Centralized Model입니다.
간단한 예로, 서울에 있는 직원이 119를 누를때는 서울 VG를 통해서 호가 나가고, 부산직원은 부산VG를 통해 전화를 걸도록 해야겠죠?
결국 아래와 같은 call routing pattern이 만들어져서 서울직원은 윗쪽 패턴을, 부산직원은 아래쪽 패턴을 타야겠죠.
119->VG-SEL
119->VG-PSN
만일 사무실이 서울,부산외에 각 지역별로 더 있다면 사무실 갯수만큼 위의 패턴이 늘어날 것이고, 119뿐만 아니라,
각 지역별 시내전화 구간, 시외전화 구간, 핸드폰번호,특수번호 등.. 각각의 경우에 따른 패턴이 중복적으로 생길 것입니다.
그런데 다들 아시겠지만, 동일한 전화번호 패턴이 두개 이상 존재할 수 없기 때문에, 우리는 파티션을 분리해서 설정합니다.
119(PT-SEL)->VG-SEL
119(PT-PSN)->VG-PSN
.
.
.
010XXXXXXXX(PT-SEL)->VG-SEL
010XXXXXXXX(PT-PSN)->VG-PSN
.
.
.
<이하생략>
국내 지역별 전화번호 패턴은 한국의 전화번호체계정리(http://www.nexpert.net/95) 를 참고하시면 됩니다. 이 많은 패턴들을 반드시 다 넣어줘야 되냐구요? 그것도 각 지역별 파티션을 분리해서요? 파티션을 분리해서 중복적으로 넣어줘야 하는 건 당연하구요, 그럼 9.!(!-모든 패턴을 의미)를 각 파티션별로만 넣어주면 되겠네요..
9.!(PT-SEL)->VG-SEL
9.!(PT-PSN)->VG-PSN
.
.
.
네, 위와 같이 해도 전화가 안되는 것은 아니지만, 모든 사용자가 Inter digit timeout(디폴트 15초)을 항상 기다려야 하겠죠.
15초를 기다리지 않는 방법은 다음과 같습니다.
1. 타이머를 줄인다. – 하지만, 너무 줄이면 번호를 다 누르기도 전에 조금만 주저하면 곧바로 Reorder Tone이 떨어지니 불편합니다. 약간의 차이는 있겠지만, 평균적으로 4~5초를 많이 사용합니다.
2.End of digit을 의미하는 #을 인식하도록 설정하고, 사용자한테 전화번호를 다 누른 후 마지막에 마치 애연가들 식후땡 하듯이 항상 #을 누를 수 있도록 충분한 교육을 하면 됩니다.
3.각 전화번호 패턴을 전부 입력해서 마지막 유효번호를 누르자마자 전화가 걸릴 수 있도록 하는 방법입니다. 초기 설정작업량의 부담이 있긴 하나, 한번 적용하면 바꿀 일이 거의 없기에 가장 권장하는 방법입니다.
얘기가 약간 옆으로 샜는데요, 아무튼 각 사이트별로 패턴을 가져가야 하는 중복작업은 피할 수 없습니다.
여기서, 한발 더 나아가 대부분의 사이트에서 적용하고 있는 CSS가 적용되어 있다면 파티션이 단순한 PT-SEL이 아닌
PT-SEL-Local
PT-SEL-LD
PT-SEL-INT
PT-SEL-Cell
.
.
이렇게 사이트별로 위와 같은 파티션이 만들어지고, 그에 해당하는 CSS가 추가로 필요하게 됩니다.
각 사이트별로 콜 권한이 4개가 필요할 경우 사이트가 8개라면 CSS만 10*4=40개가 필요하다는 것이겠죠? 물론 Partition도 그만큼 필요하게 될 것입니다
이를 도식화 하면 아래와 같습니다.
사이트의 갯수 : N
권한의 갯수 : C
Dial Pattern의 갯수 : D
CSS의 갯수 : N*C
Partition의 갯수 : N*C
Dial Pattern의 갯수 : N*D
아래 그림에서 보면, 각 사이트에서 나눠지는 권한이 기본적으로 4개라고 가정했을 때, 사이트 별 VG가 하나씩 할당이 되면 그 CSS가 4 * N(사이트 개수)만큼이 나오게 됩니다. 뿐만 아니라 중간에 녹색으로 보이는 Partition도 사이트1에서도(2+4)개, 사이트 2에서도 (2+4), 사이트 N에서도 (2+4)개만큼 나오기 때문에 4*N+2만큼이 나오게 됩니다. 여기서 2는 On Cluster와 Shared로써 각 사이트 별 공통적으로 적용되는 부분이죠. 물론 각 파티션 별로 몇 개의 Routing Pattern이 있는지는 표시되지 않은 상태입니다.
실제로 사이트를 구축해보면 그 웅장함(?)을 실감하실 수 있을 겁니다.
여기서 우리는
1. CSS와 Partition의 개수(N*C)를 줄여야 하며,
2. dial pattern의 갯수(N*D)를 줄여서
콜 라우팅을 최적화시켜보도록 하겠습니다.
먼저 CSS와 Partition의 개수를 줄여보도록 하죠. 아래 그림처럼 모든 호가 나갈 수 있는 Partition(PSTN partition)과 그와 연결되는 CSS를 만들어서 Device에 적용을 합니다. 그리고, 전화번호 별로 권한을 제한할 수 있는 Partition과 CSS를 만들어서 Line에 적용을 합니다.
이때, PSTN Partition이라는 것은 사이트 별로 하나씩만 만들어두면 됩니다.(사실 이 부분도 최적화시킬 수 있는 방법이 있는데 그 부분은 나중에 2.dial pattern의 개수(N*D)를 줄이는 방법에 대해 논의를 하겠습니다.) 그리고, Line에 적용할 CSS와 그 CSS가 lookup하게 될 Partition(여기서는 Blcok Int’l Partition)은 어차피 호가 제한될 부분이기 때문에 각 VG와 연결될 필요도 없어서 사실 Route Pattern을 이용해서 집어 넣지 않고 Translation Pattern을 이용하게 되는데요, 어쨌든 VG별 특성을 타는 것이 아니기 때문에 사이트와 무관하게 공통적으로 사용하면 됩니다.
좀더 확장된 그림으로 보시면 다음과 같습니다. Partition의 개수는 N+2(에 추가적으로 Line CSS가 참조하게 될 Partition 4개를 더하면 실제로 N+6) 되구요,(위에서는 N*4+2 였음을 확인해보세요), CSS는 N+4가 됩니다.(위에서는 N*4였죠?) 
두 가지 방법을 다시 한번 비교해봤습니다.
아래 그림은 Block Int’l partition에 9.011!이라는 국제전화번호패턴을 차단하는 예제입니다.
CUCM에서는 CSS를 전화를 걸 수 있는 객체(전화기,전화번호,Trunk 및 GW의 Inbound 나 Translation Pattern등)에 줄 수 있습니다. 이때 IP Phone은 전화번호와 전화기에 설정되어 있는 CSS를 계층적으로 적용받을 수 있습니다.즉, 적용Order가 명확하여, LineCSS를 먼저 조사하는데, 이 LineCSS는 공통으로 사용할 수 있다는 데에 촛점을 맞추셔야 합니다.
사실 제가 수업 진행할 때 많은 분들이 CSS가 줄어드는 효과에 대해 이해하는데 불편해 하셨었는데요, 딱 들어맞는 예는 아니지만, 조금이나마 도움이 될까 싶어 ACL의 개념을 비유하면서 설명 드리겠습니다. ACL도 순차적으로 검색하다가 특정 엔트리에 매치가 되면 검색을 중단하게 되잖아요. 그래서 필요에 따라 ACL의 형태가 바뀝니다.
예를 들면 telnet과 HTTP만 block 하고 싶을 땐 어떻게 하세요?
access-list … deny 23
access-list … deny 80
access-list … permit any
다른 예를 들어볼까요? SIP만 허용하고 싶으면 아래처럼 한 줄만 입력합니다. 왜냐하면 이 한 줄에 매치가 안되면 implicit deny룰에 적용받게 될 테니까요.
access-list permit SIP
단지 개념 이해만을 위해 자세한 명령어는 생략했는데요, 요점은 다음과 같습니다.
허용할 내용이 많고, 차단할 내용이 상대적으로 적다면 위의 예제처럼 차단 위주의 acl을… 허용할 내용이 비교적 적다면 아래 예제처럼 허용 위주의 acl을 생성하잖아요…
CUCM도 마찬가지입니다. 각각 콜의 권한을 분리시켜서 달리 적용해야 하고, 그 내용이 많다면, 부정위주의 설정을 하고, 마지막에 permit any에 해당하는 CSS를 적용시켜주면 되겠죠? 물론 부정위주의 설정은 공통적으로 사용할 수 있으면 더욱 좋겠죠? 그래서, 부정위주의 설정을 Line CSS에 적용을 하고, 이에 적용 받지 않는 call dialing은 Device CSS에 정의되어 있는 permit any 위주로 설정하게 되면 전체적인 CSS와 Partition의 개수가 줄어 들 수 있겠죠.
이해하기 힘들다면 그냥 원래 방식대로 사용하셔도 되긴 하지만, 문제는 단순히 중복작업이 많고, 테이블의 사이즈가 커지기만 하는 것이 아니고, 나중에 언급드릴 기회가 있겠지만 Device Mobility를 구현하는데 많은 제약을 받게 됩니다.
다시 말해, Device Mobility기능을 사용하지 않는 실제 사이트에서 사이트의 개수가 그다지 많지 않다면 원래 방식대로 사용하시면 되구요, CCIE Voice를 준비하시는 분들은 Device Mobility가 나오니 반드시 숙지하셔야 함에 주의하십시요.
자 그럼 두 번째 솔루션인 dial-pattern의 개수를 줄여보는 방법을 살펴보겠습니다. 편의상 위에 있는 그림을 다시 나타냈습니다. Partition이 사이트개수만큼 나왔었잖아요(파란부분), 이 부분을 과감히 통합시킵니다. 몇 개로요? 한 개로….
그럼 911을 누르면 어느 사이트에서 발생한 콜인지 인지해서 해당 사이트 VG로 내보내는 작업은요? 물론 그 작업도 당연히 처리되어야 할 문제인 것이죠.
이때 사용되는 기능이 CUCM 7.0에서 소개된 Local Route Group입니다.
위에서 언급했던 내용과 비슷한 그림인데요, LRG 설정전과 설정 후를 비교해보겠습니다.
그림을 잘 보시면 아시겠지만, Device Pool 설정할 때 이미 각 사이트에서 사용하게 될 VG를 지정하는데요, 실제로 사이트 내에서도 여러 VG를 사용할 수도 있기 때문에, VG를 assign하는 것이 아니고, 해당 VG를 한데 묶어서 Route Group으로 만들고, 이 Route Group을 Device Pool 설정 시 Local Route Group항목에 assign을 하게 됩니다.
결국, 기존방식에서는 Partition별로 분리되어 있는 Route pattern을 lookup하면 그때서야 어떤 게이트웨이를 탈지 지정했었던 반면, 이제는 이미 자신의 게이트웨이를 알고 있으니 공통의 Partition의 911을 눌러도 서울 사용자가 누르면 알아서 서울 VG로, 부산 사용자가 누르면 자동으로 부산 VG를 통해 나가는 것입니다. 결국 필요한 Partition의 개수는 N+6에서 1+6이 되어 사이트가 몇 개가 되더라도 동일하게 7개가 적용될 것입니다. 파란부분이 한 개라는 사실에 주목하시면 됩니다.
Local Route Group설정은 의외로 간단합니다.
Call Routing->Route/Hunt->Route Group에서 각 사이트 별 Route Group을 지정하신 다음에 각 사이트 별 별도로 사용하게 될 Device Pool에 이 Route Group을 연결만 끝이구요,
나중에 Route Pattern 만들 때, Local Route List만들어서 지정해주면 끝납니다.
Call Routing->Route/Hunt->Route List 에서 Route List를 만들고, LRG를 assign하고, Route Pattern에서 사용하면 되겠죠.
실제로 LIneCSS와 DeviceCSS를 적절히 사용하는 것만 한두 번 연습한다면 다른 것은 그다지 어렵지 않고서 복잡한 라우팅을 간단히 끝낼 수 있을 것 같습니다.
다음에는 Device Mobility를 소개해 드리도록 하겠습니다.
솔민아빠(CCIE R&S, Voice)