Tech Bank - VoIP
상태바
Tech Bank - VoIP
  • 승인 2004.11.12 00:00
  • 댓글 0
이 기사를 공유합니다

디자인·연결 상태 변경 선행돼야 … 최대 적은 ‘지연·지터·패킷유실’

“네트워크를 준비된 상태로 만들어라”

VoIP(Voice over IP)는 이제 우리 곁에 있다. 하지만 랜이나 왠에서 VoIP를 돌리고 싶다면 네트워크에 얼마간의 변경을 가할 필요가 있을 수 있으며, 심지어 그 디자인을 다시 해야 할 수도 있다. 달갑게 들리지 않을지 몰라도, VoIP도 다소 독특한 필요조건이 있긴 하지만 하나의 애플리케이션에 불과하다는 사실을 명심해야 한다.

네트워크의 디자인과 용량은 VoIP를 만들 수도 파괴할 수도 있다. 지연, 지터, 패킷 유실 및 비신뢰성은 실시간 애플리케이션에 대한 문제를 야기하기 때문에, 첫 번째 VoIP 스위치나 전화기를 설치하기 전에 먼저 네트워크를 전체적으로 검토해 봐야 한다. 그리고 네트워크에 대대적인 정밀검사가 필요한 경우에는 VoIP를 배치하기 전에 몇 개월 동안 이것을 해야 한다.
네트워크 평가에는 네트워크가 레이어 2 및 레이어 3 QoS(Quality of Service)와 VLAN(Virtual LAN)을 지원하는지 여부를 확인하고, 용량을 측정하며, 네트워크가 VoIP에 필요한 추가 대역폭을 지원하는지 여부를 파악하는 일이 포함된다.
특히 네트워크가 바쁜 시간 동안에 추가 음성 트래픽을 처리할 수 있는지 확인하는 게 중요하다. 최소한 한 달 동안은 데이터 트래픽을 살피면서 조직 내의 모든 그룹에 의해 네트워크 활동의 주기적 변화를 측정해 보아야 한다. 피크 시간 동안의 데이터를 조사하고, 1분이나 심지어 5초, 10초의 피크를 보여주는 작은 데이터 샘플들을 모으라.
또한 PBX의 세부 통화 기록에서 피크 호출 시간을 조사해 보라. 지원해야 할 동시 호출의 수와 VoIP 애플리케이션이 추가시키게 될 대역폭 양을 파악할 수 있어야 한다. 또한 기존의 애플리케이션뿐만 아니라 예상되는 성장에 대비한 공간이 있는지도 확인하라. VoIP용으로 필요한 대역폭을 계산하는 데 대해서는 <코덱: 대역폭+지연 공식>을 참조하라.
스위치와 라우터에도 필요한 VoIP 기능이 있을 수 있지만, 소프트웨어 코드 버전 목록을 만들고, 가장 최근 버전을 갖고 있는지 확인해야 한다. 일부 소프트웨어는 업그레이드를 해야 할 것인데, 이는 모든 장비가 버그 없는 QoS 버전과 함께 VoIP를 지원할 준비를 갖추고 있는 것은 아니기 때문이다. 하지만 QoS에 너무 연연해 할 필요는 없다. QoS는 대역폭을 초과하게 될 때 하나의 보험 정책이라고 생각하면 된다.
많은 VoIP 업체들이 사전 설치된 평가 서비스를 제공하며, 변경을 추천할 것이다. 이러한 종류의 도움을 통해 얼마간의 작업을 줄이고 훗날 문제가 발생했을 때 책임을 최소화할 수 있다.
네트워크는 또한 정기적으로 재평가를 해 보아야 한다. 새로운 애플리케이션이 추가되고, 사람과 부서는 이동을 하며, 네트워크는 재구성된다. 그리고 이런 모든 일들은 트래픽 패턴을 바꿔놓을 수 있다. 네트워크의 용량과 성능을 모니터링함으로써 문제를 피하는 데 도움이 될 것이다. 게다가 VoIP 모니터링 툴은 네트워크가 VoIP를 얼마나 잘 지원하는지를 재평가할 때도 유익할 수 있다.

기본에 충실하자
대부분의 VoIP 업체들은 이중성의 부조화가(이더넷 연결의 한쪽 끝에서는 전이중, 다른 쪽은 반이중이다) VoIP 성능 문제의 가장 큰 원인이라고 말하고 있다. 자신의 연결에서 이중성 설정을 확인하고, 네트워크 관리 시스템을 이용해서 스위치와 라우터 설정을 점검해 보라.
먼저 백본 연결에서부터 시작해야 하는데, 그 이유는 이것이 VoIP의 성능에 큰 영향을 미치기 때문이다. 모든 백본 연결의 양쪽 종단을 수동으로 전이중으로 설정하라. 양쪽 종단이 자동협상을 하도록 설정한다면, 에러 카운터에서 이중성에 대한 단서를 얻을 수 있다. 예를 들어 한쪽 종단에서 충돌이 일어나면, 여기에는 아마 반이중 설정이 돼 있을 것이다. 반대쪽 종단에 많은 CRC(Cyclic Redundancy Check)가 있고 충돌이 전혀 없다면, 이것은 아마도 전이중으로 설정돼 있을 것이다. 대부분의 장비, 특히 스위치와 라우터의 구성을 언뜻 보기만 해도 이중성 설정을 알 수 있다.
NIC과 와이어링 클로짓 스위치를 표준화했다면, 자동협상을 이용해 PC 투 스위치와 전화기 투 스위치 연결을 테스트해보는 게 가장 좋다. 자동협상이 전이중에서 가능한 가장 높은 속도를 얻는다면 그것을 사용하라. 스위치가 내장된 VoIP를 원한다면, 이중성 설정을 바꿀 수 있게 해주는 것들을 선택하라. 전회가의 내장 스위치에서 PC와 에지 스위치로의 연결도 또한 점검해야 한다.
음성 패킷이 우선 대접을 받게 하고 최소한의 패킷 유실과 지연을 경험하도록 보장하려면 네트워크 전체에서 레이어 2(802.1p)와 레이어 3(디프서브) QoS를 켜야 한다. 전화기나 미디어 게이트웨이 등의 VoIP 장비는 QoS를 지원해야 한다. 라우터가 프레임을 다시 만들 때 레이어 2 QoS 설정은 사라진다는 사실을 명심하라. 대부분의 라우터는 패킷을 전송하기 전에 레이어 3 QoS를 이용해 적합한 레이어 2 QoS 정보를 번역할 수 있다(라우터가 이것을 회선 속도로 하는지 확인하라).
데스크톱을 VoIP 전화기에 꽂는다면 PC가 데이터로 인해 접속을 묻어버리지 않도록 하라. 전화기의 내장 스위치와 와이어링 클로짓 스위치가 802.1p를 지원한다면 이것은 문제가 되지 않을 것이다. 그렇지 않을 경우 데이터 전송은 음성 전환을 인터럽트할 수 있다.
결론적으로 말하자면, QoS 정책은 모든 VoIP 트래픽에게 우선순위를 부여해야 하며, 유일한 예외는 라우팅 업데이트와 다른 제어 패킷들이다.

오류 피하기
레거시 전화기 네트워크는 99.999%의 가용성으로 잘 알려져 있다. 하지만 VoIP 애플리케이션은 데이터 네트워크가 지원하는 만큼의 신뢰성만을 갖게 된다.
데이터 네트워크의 신뢰성은 중복성으로 향상시킬 수 있으며, 이는 주로 가장 많은 수의 사용자들에게 영향을 미치는 네트워크 코어에서 이뤄진다. VoIP 서버가 연결된 곳에 중복성을 추가하는 것도 도움이 된다. 최소한 이중 전원공급기와 이중 CPU 카드, 그리고 네트워크의 코어와 에지 모두에서 미러링되는 드라이브가 있어야 한다.
또한 중복 연결을 이용해 건물 스위치로 중복 코어 라우터를 연결해야 한다. 그리고 다운타임을 피하기 위해서는 모든 핵심 부품들을 여분으로 갖고 있어야 한다. 중복 장비를 고 가용성 모드로 구성해 두면 이런 예비 부품들은 몇 초 안에 생산 시스템에 배치될 수 있다(새 장비를 설치하려면 몇 시간이 걸린다).
배치를 하기 이전에 먼저 랩에 있는 고 가용성 방안들을 테스트 해 보라. 어떤 경우에는 주 카드가 오류가 났을 때 코어 라우터에 있는 백업 CPU 카드를 재부팅하는 데 몇 분이 지나야 라우팅 테이블이 뜨기도 한다. 어떤 라우터들은 이런 과정을 보다 신속히 처리해 준다.
물론 중복성이 추가되면 비용도 늘어난다. 이 자금을 확보하는 데 곤란을 겪고 있다면 경영진에게 여기에 내포된 중요성을 이해시키도록 노력하라. 교체나 복구가 필요할 때 네트워크가 얼마나 오래 다운된 채로 있어야 하는지를 얘기해 주라. 얼마 만큼의 다운타임을 수용할 수 있는지를 파악하는 과정에 경영팀이 직접 참가하게 하라.
가능하다면, IETF의 VRRP(Virtual Router Redun-dancy Protocol)나 IEEE의 802.3ad 회선집합 프로토콜 등과 같은 페일오버를 이용해 중복 장비를 에지로 연결하라. 예를 들어 두 개의 코어 라우터가 중복 연결로 돼 있는 데서는 이들이 같은 업체의 제품이기 때문에 상호운용성은 문제가 되지 않을 것이다. 하지만 코어에서 에지로의 연결에서는 표준이 중요한데, 그 이유는 전체 네트워크에서는 서로 다른 업체의 장비가 있을 수밖에 없기 때문이다. 페일오버 시간이 향상된다면 업체 전용의 페일오버 프로토콜이 최선일 수 있겠지만, 업체 전용 방안을 사용할 때와 표준을 사용할 때의 이점을 잘 비교해 봐야 한다.

전원 백업
VoIP에는 랜 환경, IP 전화기, 그리고 VoIP 서버용의 백업 전원이 필요하다. 아마도 데이터 센터 내에 백업 전원이 있을 것이다. 그렇다면 문제는 KVA(Kilo Volt-Amp) 업그레이드로 간단히 좁혀진다.
백업 전원은 전화기와 스위치용의 와이어링 클로짓에서 필수다. IEEE 802.3af PoE(Power over Ethernet) 표준을 이용해 클로짓에서 전화기로 전원을 공급할 수 있으며, 여기서는 카테고리 5 이상의 이더넷 와이어링이 사용된다. 15분의 백업이라 하더라도 몇 번의 전력 저하나 짧은 단전을 거쳐야 할 것이다. 하지만 어떠한 단전이든 스위치나 전화기의 재부팅을 야기시키며, 이러한 단전은 몇 분으로 늘어날 수도 있고 장비에 손상을 줄 수도 있다는 사실을 명심해야 한다. 와이어링 클로짓에 배터리 전원 백업을 두는 것도 좋은 생각이다.
VoIP 시스템은 보호돼 하며, 특히 인터넷 액세스로부터는 더욱 그러하다. VoIP 전화기는 컴퓨터이며, 따라서 해킹이 가능하다. 이들을 전용 전용 어드레스를 이용해 이들만의 가상랜으로 격리시켜 여기서만 VoIP 서버로 액세스를 갖도록 함으로써 전화기를 보호할 수 있다.
물론, 인터넷에서 전화기 및 서버로의 액세스를 거부하고 싶을 것이다. 서비스 거부(Denial of Service) 공격 위험이나 침입의 가능성과는 별도로 요금 사기(toll fraud)도 있을 수 있다. 즉 누군가 전화기를 하이재킹해서 이것으로 통화를 할 수도 있다는 얘기다. 또한 내부 인터넷 안에서의 액세스도 필터링하고 싶을 것이다. 필요한 포트들로만 액세스를 허용하고 회사의 전화 시스템을 집에서 사용하고자 하는 재택근무자들을 위한 인증 및 VPN이 제대로 돼 있는지를 확인하라.
마지막으로, IP 구성을 VoIP 전화기로 로딩하는 데 DHCP를 사용하라. 이것은 또한 TFTP(Trivial FTP)를 통해 새 소프트웨어와 구성을 다운로드하는 전화기와 통신하는 데도 사용될 수 있다. 전화기가 재부팅돼 DHCP 서버에 도달할 수 없다면 이들은 다운되기 때문에, DHCP 서버의 신뢰성과 가용성이 중요하다.
이 기술을 채택하기는 어려운 일이 아니지만, 그 프로세스도 마찬가지로 중요하다. 네트워크에 변경을 가하기 이전에(새 기능을 추가하거나 구성을 변경하는 등), 이것이 VoIP 시스템에 미치는 영향을 먼저 파악해야 한다. 그리고 데이터 네트워크와 VoIP 컴포넌트에 대한 최신 매뉴얼을 철저히 살펴보고 장애관리에 이 정보를 이용할 수 있어야 한다. 그런 다음에야 당신 네트워크에서는 음성 트래픽이 매끄럽게 흘러다닐 수 있게 된다.

Executive Summary

Voice over IP

이제는 아마도 VoIP(Voice over IP)가 가져다 줄 생산성 향상과 비용 절감효과를 누릴 준비가 돼 있을 것이다. 하지만 가장 큰 혜택을 누리기 위해서는 바로 이것을 던져 넣고 이야기를 하는 게 능사가 아니다.
IP 음성은 적절한 네트워크 기반이 있어야 음성 통화가 VoIP의 끔찍한 악마들, 즉 지연, 지터, 패킷 유실 및 전체적인 비신뢰성 등으로 고통받지 않을 수 있다. 첫 번째 IP 전화기를 설치하기 이전에 먼저 네트워크 장비들이 레이어 2 및 레이어 3 QoS(Quality of Service)와 가상 랜을 지원하는지, 그리고 기존의 대역폭이 음성 트래픽을 처리할 수 있는지 여부를 확인하라. 아마도 장비 소프트웨어의 업그레이드가, 그리고 아마도 하드웨어 역시 업그레이드가 필요할 것이다.
이더넷 연결에서 한 쪽은 전이중이고 다른 한 쪽은 반이중인 부조화가 없도록 모든 네트워크 연결을 점검해 보라. 그리고 코어와 전원 모두의 중복성은 유연한 IP 음성 이행에 있어 필수라는 사실을 명심해야 한다. 음성을 보안하기 위해서는 VoIP 전화기를 전용 어드레스를 이용해 이들만의 가상랜에 두고 내부 네트워크로의 액세스를 최소화 및 모니터링해야 한다.
그리고 VoIP 시스템이 설치 및 가동되고 난 후에도 데이터 네트워크와 VoIP 컴포넌트들의 매뉴얼을 최신 것으로 유지해야 IP 음성의 품질을 보장할 수 있다.

VoIP의 세가지, ‘지연·지터·패킷 유실’

delay/jitter/packet loss

네트워크 음성이 크고 선명하게 들리도록 보장하려면 VoIP의 세 가지 적들, 즉 지연, 지터 및 패킷 유실(delay/jitter/packet loss)을 알아둘 필요가 있다.
지연은 데이터가 네트워크의 A 지점에서 B 지점으로 전달되는 데 걸리는 시간이다. VoIP는 지연에 민감한데, 그 이유는 사람의 대화가 실시간으로 일어나기 때문이다. 지연이 대화의 흐름에 영향을 미칠 경우 통화 품질은 저하된다.
ITU G.114는 최대 150ms 단방향 지연, 혹은 300ms의 왕복 지연을 권장하고 있다. 하지만 왕복 지연은 150ms를 넘지 않도록 유지하는 게 가장 좋은데, 이 지점에서부터 대화의 품질이 저하되기 때문이다. VoIP 전화기는 보통 60ms의 지연을 추가하지만, 이 수치는 업체와 지터 버퍼 크기에 따라 달라진다.
좋은 QoS와 충분한 대역폭으로 아키텍처를 만듦으로써 과부하된 라우터 대기열이나 가입초과된 네트워크에서 오는 지연을 막을 수 있다. 보다 느린 왠 회선과 장거리 회선에서의 지연은 특히 해외 접속에서 문제가 될 수 있다. 얼마간 지연을 피할 수는 있겠지만 이것을 완전히 근절할 수는 없다. 지연은 보통 랜은 문제가 안되지만(랜이 적절히 설계됐다고 가정한다면), 속도가 느린 왠 회선은 지연을 추가할 수 있다.
왠 회선에서는 거리만으로도 지연이 늘어난다. 광속은 파이버 100 마일에 최소 5ms의 지연을 추가한다. 따라서 해변에서 해변으로 3천마일이 연결돼 있다면 왕복 30ms의 지연이 있게 되는데, 이것은 그리 문제가 되지 않는 수준이다. 하지만 국가간 거리나 VPN, 혹은 과부하된 네트워크에서의 지연은 느낄 수 있을 정도가 된다.

3가지 문제 해소가 관건
지연은 또한 반향을 증대시킬 수 있으며, 이것은 전통적인 TDM(Time-Division Multiplexing) 네트워크에서도 염려되는 사항이다. VoIP 전화기에는 반향 제거(echo cancellation)가 내장돼 있지만, 원래 음성과 호출자간에 지연이 추가되기 때문에 반향은 보다 분명해진다. 그리고 반향 제거 알고리즘은 반향을 걸러내는 데 더 힘든 시간을 보내게 될 것이다. 반향 제거 기능에 대해 VoIP 업체에게 물어보라. 업체에 따라 사용하는 알고리즘이 다르며 다른 것들보다 좀더 잘 작동하는 것들도 있다.
지터는 지연에서의 변동을 말한다. 이것은 지연과 같은 이유, 즉 음성은 실시간이라는 이유 때문에 악역을 하게 된다. 일부 음성 패킷들이 거의 지연이 없이 도착했다가 이어서 훨씬 더 큰 지연이 따라오면, 수신측 종단의 대화의 일부는 균일치 못하게 된다. 지터 버퍼는 패킷을 버퍼링하고 이들이 어떻게 나오는지를 제어하지만, 지터 버퍼가 너무 클 경우에는 너무 많은 지연을 발생시킨다. 코덱은 또한 음성의 지난 부분들을 반복함으로써 보충해줄 수도 있다.
패킷 유실도 또한 VoIP의 적이 될 수 있지만, 흔히들 생각하듯 그렇게 극적이지는 않다. 음성이 IP 네트워크를 통해 전송되면 음성 애플리케이션은 보통 UDP(User Datagram Protocol)의 가상위에서 돌아가는 RTP 프로토콜을 이용한다. 음성 패킷을 재전송하는 일은 효과가 없는데, 그 이유는 음성이 실시간이고 소리는 작은 청크들로 나눠져 몇 개가 유실돼도 거의 알아채기가 힘들기 때문이다.
일부 VoIP 업체들은 자신들의 시스템이 최고 10%의 패킷 유실을 감당할 수 있다고 말한다.
일반적으로는 왠에서, 그리고 심지어 랜에서도 1~2%의 패킷 유실을 유지하는 게 가장 좋다. DTMF 톤에 의지하고 있다면, 어떠한 패킷 유실도 감당할 수 없을 것이다. 하나의 유실된 패킷이 자동 어텐던트 트리(automated attendant tree)에서 한 사람의 고객이 유실되도록 할 수도 있다. 이런 경우에는 자동 어텐던트를 지원하는 네트워크 영역에서 TDM 트렁킹을 사용하는 편이 낫다. PSTN에서 전화기 시스템으로 전화를 거는 고객은 TDM 접속에서 쉽게 유지될 수 있는데, 그 이유는 이들이 어쨌거나 TDM을 통해 들어오게 되기 때문이다.

코덱 : 대역폭+지연 공식

VoIP용으로는 보통 두 가지 코덱이 사용된다. 네트워크를 계획할 때는 자신이 선택한 VoIP 업체에서 어떤 코덱과 기능을 지원하는지를 먼저 알아둘 필요가 있다. 랜에서 VoIP만을 돌린다면, G.811(85Kbps)가 최선인데, 그 이유는 랜 대역폭이 매우 비싸기 때문이다. 왠에서는 G.729가 보다 효과가 있는데, 그 이유는 이것이 절반도 채 되지 않는 대역폭을 사용하기 때문이다. 문제는 G.729가 더 많은 지연을 추가한다는 사실이다. 아래 표에서는 각각의 종단에서 20ms의 패킷화된 지연이 있고 2ms의 수신 지터 버거가 있는 것으로 가정했다.
일부 업체들은 VAD(Voice Activity Detection)와 음성 트래픽 압축(silence suppression)을 이행하는데, 음성 트래픽 압축이란 사용자가말할 때만 패킷을 전달하며, 이를 통해 대역폭 이용량은 훨씬 더 줄어들 수 있다. 하지만 음성은 VAD나 압축 스위치가 켜지고 꺼질 때 잘릴 수 있다.
음성 호출을 설정하면 추가 트래픽이 만들어진다는 사실을 명심하라. 이는 통계를 추적하는 RTP(Real-time Transport Protocol)용의 패킷을 제어할 때도 마찬가지다. 소프트웨어 애플리케이션을 VoIP에 통합을 해도 또한 트래픽 오버헤드가 추가되기 때문에, 네트워크에서 애플리케이션을 먼저 테스트해야 한다. 피크 호출 시간 동안에 발생할 최대 동시 통화 수뿐만 아니라 기존의 애플리케이션에 대한 피크 트래픽 이용량을 지원하기 충분한 대역폭이 있는지를 확인하라.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.