시작하며
UC 디자인 시 119 및 112 긴급 전화 서비스에 대한 고려를 하지 않는 경향이 있습니다. UC 의 만 가지 좋은 기능을 빛내는 것은 기본이 되는 기능을 제대로 갖추는 것입니다. UC의 가장 큰 특징인 IP Phone의 이동성을 효과적으로 활용하기 위해서는 긴급 서비스에 대한 고려가 중요합니다. 긴급 서비스는 사용할 일이 거의 없지만, 필요한 경우에 제대로 동작하지 않는 긴급 전화 서비스는 큰 문제를 유발할 수 있습니다.
이번 글에서는 긴급 전화 서비스에 대해 이야기 해 보겠습니다.
긴급 전화 서비스는 필수
긴급 전화 서비스는 기업이나 가정이나 매우 중요합니다. 우리가 사용하는 핸드폰도 잠금 설정이 되어 있더라도 긴급 전화는 무조건 가능합니다. 즉, 모든 전화기들은 최소한 긴급 전화 서비스를 제공해야 합니다. 예를 들면, 기업의 도어폰 (Door Phone)은 회사 출입구에 설치되어 누구나 사용할 수 있도록 하지만, 제한된 통화 (사내 통화 및 긴급 통화)만 가능하도록 합니다. 만일 도어폰에서 긴급전화를 걸 수 없다면, 정말 위험한 순간에 도움이 되지 못합니다.
긴급전화가 가능하다는 의미는 119 센터에서 발신자의 위치 추적이 가능하다는 것입니다. 발신자는 어린아이, 노약자, 언어에 장애가 있는 자 등 다양한 경우에 대한 대비가 필요하기 때문입니다. 평소 논리적으로 판단하는 성인의 경우에도 위급한 상황에서 119 전화번호를 기억하지 못하는 경우가 있다고 합니다. 따라서, 자신의 정확한 위치를 말로써 설명하는 것은 쉽지 않으며, 이는 발신자를 중심으로 가장 가까운 119 센터로 부터 조치를 받지 못한다는 것입니다. 서울의 발신자가 전화를 하였음에도 부산의 소방서에서 출동을 할 수는 없습니다.
2008년 5월 캐나다의 한 가정에서 화재가 발생하여 5살 어린아이가 인터넷으로 911에 전화 했지만, 구급차가 과거의 집 주소로 출동하는 바람에 신고자를 구하지 못하는 사건이 발생하였습니다. 이 사건을 계기로 미국과 캐나다에서는 기존 통신 사업자와 마찬가지로 인터넷 전화 사업자에게도 긴급 서비스를 제공하는 것을 의무화하고 있습니다. 평생 사용하지도 않을 긴급 전화 서비스이지만, 단 한 번의 사용으로 큰 재앙을 막을 수 있습니다.
기업에서 긴급 전화 서비스에 대응 정책을 마련하는 것이 얼마나 중요한 지를 다시금 강조합니다.
긴급 전화 서비스 개요 및 국내법령
긴급 전화란 “재난 및 안전관리 기본법”에서 규정한 119, 122 (해양 사고) 전화를 의미합니다. 국내의 “위치정보 보호 및 이용에 관한 법률”의 29조에 의거 소방 방재청과 같은 기관이 긴급 전화를 받으면 발신자 주소를 확인할 수 있도록 KT 등 시내 전화 사업자가 가입자 주소를 제공해야 합니다. 이는 긴급 상황 시 주소를 말해 줄 수 없는 위급 상황에서도 긴급 출동이 가능해야 하기 때문입니다.
기존의 PSTN의 E.164 전화번호 체계는 전화기의 물리적 위치와 매핑되어 있습니다. 즉, 기존 아날로그 전화기를 다른 곳으로 옮기게 되면, PBX에 연결된 내선의 위치가 바뀌므로 자동으로 전화번호가 바뀌고, 물리적 위치가 변경됩니다. IP Phone은 다른 곳으로 이동하여도 전화번호는 그대로 사용하며, 물리적 위치가 변경됩니다. 즉, IP Telephony 및 UC를 구축할 경우 발신번호로 발신자의 물리적 위치를 확인하는 것이 어렵습니다.
2005년 070 VoIP 사업자가 선정 시에 긴급 전화서비스는 제공하지 않아도 서비스에 문제가 되지 않았지만, 2008년 인터넷 전화 사업 활성화를 위한 070 인터넷 전화번호와 기존 전화 번호를 혼용하기 위한 번호 이동제를 도입하기로 하면서 긴급 전화 서비스 문제로 인해 난항을 겪은 적이 있습니다. 즉, 인터넷 전화의 특성 상 발신자의 위치확인이 불가능하였기 때문입니다. 이 때문에 VoIP 사업자가 공동으로 100억 이상을 들인 VoIP 위치 정보 시스템을 KT에 구축하여 공용하도록 하였으며, 청약 절차를 통해 가입자 전화 번호와 주소를 일치시키도록 했습니다. 긴급 발생 시에 소방방재청이나 경찰청에서 VoIP 위치 정보 시스템을 검색할 수 있게 된 것입니다.
2011년 7월 현재 인터넷 전화 가입자가 천만을 넘었습니다. 인터넷 전화 가입자가 긴급한 순간에 위치 서비스를 받기 위해서는 이사를 갈 경우에 반드시 SP를 통해 바뀐 주소를 신고해야 합니다. 미 신고 시 발신자의 위치 추적은 불가능하게 됩니다.
기업에서 UC를 도입 중이거나 도입이후에도 반드시 필요한 서비스이므로 디자인 시 고려하시기 바랍니다. 즉, 발신번호를 보내는 것이 목적이 아니라 119 센터에서 위치 정보를 인식할 수 있도록 하는 것이 중요한 사항입니다.
우리나라 소방 방재청의 119 전화 서비스 체계
가정에서 또는 기업에서 기존의 유선 전화를 통한 긴급 통화 시 발신 지역에 따라 자동으로 가장 가까운 소방서로 자동으로 연결됩니다. 긴급 통화 시도 시 전화를 받는 곳을 PSAP (Public Safety Answering Point)라고 합니다. 소방방재청은 2006년 부터 통합 관제 시스템을 국가 표준 시스템으로 개발하여 전국에 확산 보급하고 있습니다. 119 신고 접수를 기존의 소방서 단위에서 응대하던 체계에서 도 단위로 통합하고 있습니다. 즉, 3000 여개의 PSAP 을 20 여개 이하로 줄인 것입니다.
좀 더 자세한 사항을 파악하기 위해 인터넷을 뒤졌지만, 미국의 911 서비스에 대한 자료는 방대하지만, 국내 119 서비스에 대한 자료는 역시나 없었습니다. 미국을 기준으로 국내 119 서비스에 대한 이해를 하도록 하겠습니다. 기본적인 서비스는 미국과 동일하기 때문입니다.
긴급 통화 서비스는 크게 3 단계로 나뉘며, 아래 내용은 “미국의 VoIP 긴급 통화 정책 동향” (http://www.scienceall.com/issue/sciencelibrary.sca?todo=view&classid=CS010004&articleid=35485&bbsid=33&popissue=flash) 이라는 글에서 발췌한 것입니다.
- 기본 911(basic 911) 서비스
가입자가 911로 전화를 건 호(call)를 서비스 제공업체의 교환기에서 보통 전용 긴급 중계 회선을 통해 지리적으로 적절한 해당 단일 공공안전응답센터(PSAP)로 보낸다. 이때, 기본 911 망은 발신자의 위치에 대한 처리를 할 수 없으며, 단지 적절한 공공안전응답센터(PSAP)로 911 전화를 포워딩 할 뿐이다.
- 강화된 911(enhanced 911) 서비스
가입자가 911로 전화를 건 호(call)를 선택 라우터(selective router)를 경유하여 발신자의 위치에 따라 지리적으로 적절한 해당 공공안전응답센터(PSAP)로 보낸다. 이때, E911에서는 수신자인 공공안전응답센터(PSAP)에게 발신자의 전화 번호인 가입자 번호 정보(ANI)와 발신자의 위치 정보를 찾을 수 있는 위치식별 정보(ALI)를 제공한다. 이때, 가입자의 위치 정보는 가입자가 등록한 정보에 의지하여 처리된다.
- 진보된 911(advanced 911) 서비스
가입자의 위치 정보를 가입자에 의지하지 않고 서비스 사업자가 자동으로 확보하여 911 발신자의 가입자 번호정보와 위치 식별 정보를 공공안전응답센터에게 전달할 수 있다는 점이 강화된 911(enhanced 911)서비스와의 가장 큰 차이이다.
현재 미국 은 E911 서비스를 제공하고 있으며, 우리나라도 E911 정도의 서비스를 제공하고 있습니다. 119 센터에서 정확한 사용자의 위치를 확인하기 위해 필요한 요소는 다음과 같습니다.
- 발신번호 (ANI)
- 위치 식별 번호 (ALI)
물론, 위의 정보외에 다른 정보가 추가적으로 제공되지만, 가장 중요한 정보는 위와 같습니다. 긴급 전화가 발생하게 되면, 선택 라우터에 의해 가장 가까운 PSAP을 결정하여 호를 전송합니다. 호를 수신한 공공안전 응답센터 (PSAP)는 통신망 사업자가 제공하는 ALI DB를 이용하여 정확한 위치를 파악합니다. 위치를 파악한 PSAP은 소방차와 구급차를 급파하여 긴급 구조가 가능하도록 합니다.
일반 가정의 인터넷 전화는 ALI를 제공할 수 없기 때문에 발신 번호를 기반으로 선택 라우터를 결정하여 PSAP을 결정합니다. PSAP에서는 발신번호만을 기반으로 발신자의 위치를 추적합니다.
이제 전체적인 긴급 서비스 체계를 이해하였다면, IP Telephony 를 어떻게 설계할 지를 고민해 보겠습니다.
긴급 전화 서비스를 위한 IP Telephony 망 설계 고려 사항
과거 기업에서 긴급 전화 서비스는 문제가 되지 않았습니다. 각 사업장 별로 PSTN 접속 구간을 가지도록 설계 되었기 때문에 긴급 전화는 PSTN을 경유하도록 하여 가장 가까운 소방서나 경찰서로 연결이 가능하였습니다. 따라서, Outbound Call은 자동으로 PSTN을 이용하여 전송하였으므로 일반 통화와 긴급 통화에 대한 구분은 의미가 없었습니다.
요즘 기업들은 발신 호 (Outbound Call) 집중화를 통한 비용 절감을 시도하고 있습니다. PSTN 연동을 위해 본사에서 SIP Trunk 또는 E1 Trunk를 이용합니다. 따라서, 긴급 호 및 일반 호를 구분하지 않고 모든 발신호를 서울 본점에서 일괄적으로 E1 Trunk 또는 SIP Trunk로 전송하므로 긴급 전화 서비스에 문제를 유발할 수 밖에 없습니다. 전국에서 발생하는 긴급호는 동일한 Trunk를 통해 발신번호만을 보내게 되고, ALI가 확인되지 않는 발신 번호를 기반으로 발신자의 위치 추적에 어려움이 있습니다.
또 다른 큰 문제는 전화번호 새롭게 본점에서 일괄적으로 부여 받을 경우 직원이 사용하는 모든 전화 번호는 서울을 기점으로 청약되게 되므로 직원이 긴급 통화를 할 경우 위치는 모두 본점으로 표기되게 됩니다. 따라서, 전화 번호를 지점별로 할당한 후에 위치 정보를 통신사를 통해 업데이트 해야 하며, 직원들이 이동 할 때마다 전화번호를 변경하거나 인터넷 전화를 위한 위치 정보를 항상 변경해야 합니다. 이는 현실적으로 불가능한 것입니다. 직원들이 IP Telephony의 이점을 누리면서 긴급 전화 서비스를 일반 PSTN과 마찬가지로 자동으로 받을 수 있는 방안을 고려해야 합니다.
긴급 전화 서비스를 이해하였고, IP Telephony 망 설계 시에 문제점도 이해하였습니다. 우리가 고려해야 할 사항들을 정리하겠습니다.
- PSTN 망
발신 번호 (ANI) 와 위치 식별 번호 (ALI) 로 위치 확인
위치 식별 번호는 전화국의 PBX에서 전달
전화국의 PBX에 의해 선택 라우터로 전송된 깁급호는 가장 가까운 PSAP을 선택하여 호를 전송
PSAP에서는 ALI를 이용하여 발신자의 위치를 파악
- 인터넷 망
발신 번호와 위치를 매핑한 위치정보 데이타베이스를 유지
가입자에 의한 위치 정보 업데이트가 필요
발신 번호를 기반으로 가장 가까운 PSAP으로 긴급호를 전송
PSAP에서는 발신번호를 기반으로 발신자의 위치를 파악
기업에서 070 인터넷 전화 번호를 사용하거나, 기존 PSTN 번호를 사용하지만 VoIP 번호로 전환하였다면, 반드시 사업자에게 위치 정보의 변화를 통보해야 합니다. 즉, 서울의 직원이 전화 번호를 그대로 가지고 지방으로 이동하였다면, 전화번호를 그 지역 번호로 변경하거나, 사업자에게 해당 전화 번호대한 위치 정보를 변경해 주어야 합니다. 이는 현실적으로 불가능한 일입니다만, 기업에서 호 집중화를 통한 지사의 PSTN 게이트웨이를 제거하므로 발생할 수밖에 없는 일입니다.
국내는 도 단위로 PSAP이 구성되어 있으므로 최소한 도 단위로 PSTN 게이트웨이를 구성해야 합니다. 아직 IP 네트워크를 통해서 PSAP에 접근할 수 는 없습니다. 즉, 대전 지사에 있는 전화기들의 Outbound Call 에서 일반호는 본점을 통해 서비스 받으며, 긴급 호는 도 단위 PSTN 게이트웨이를 이용하는 것입니다. 긴급호는 각 지역 전화국의 PBX에 의해 가장 가까운 PSAP 로 전송됩니다. 하지만, 여전히 ALI 는 문제가 발생하게 됩니다.
마치며
IP Telephony 망을 갖춘 후 위급 상황에서 핸드폰을 이용하는 우를 범하지 말하야 합니다. 핸드폰은 반경 5Km 까지 오차가 발생할 수 있습니다. 핸드폰으로 해결해야 겠다는 생각보다는 체계적인 기준을 갖추는 것이 중요합니다.
미국은 모든 인터넷 전화 사업자가 ANI 및 ALI를 의무적으로 제공하도록 되어 있습니다. 그러나, 제공되는 정보가 정확하게 유지되는 것은 기업의 몫입니다. 이의 정확성을 유지하기 위한 다양한 기술들이 필요합니다. 다음에는 다양한 UC 환경을 바탕으로 체계적인 Dialplan 을 고려해 보겠습니다.
---------------------------------------------------------------------------------------------------------------------------------------
라인하트 (CCIEV #18487)
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/ucwana (라인하트의 트위터 )
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (벤더에 상관없이 UC를 공부하는 사람들이 모인 구글 구룹스)
정리하고 보니 나도 디지털 네이티브 ^______________________________________________________________^
