Богдан Ясинецкий

   В предыдущих статьях было рассказано о построении корпоративного сервера и рассмотрены некоторые вопросы корпоратизации компьютерной системы - базовые элементы построения внешней части интранет инфраструктуры:
 - Подключение к Интернет 
 - Регистрация доменного имени 
 - Структура почтовой системы 
 - Построение виртуальных каналов между разнесенными офисами 

Сейчас рассмотрим вопросы более тесного связывания офисов в единую сеть предоставлением сервисов корпоративной телефонии. 

   Некоторые предварительные замечания о структуре телефонной сети, применяемом оборудовании и направлениях действий. В данной статье будет описано построение заведомо более сложной системы, чем можно было бы сделать, но в данной заведомо более сложной схеме реализации существует определенная гибкость системы и возможность достаточно простого расширения без перестройки всех устройств системы путем только наращивания оборудования. Все о чем идет дальше работает только в среде DTMF нумерации.

   Самый простой вариант - полное отсутствие какой бы то ни было телефонной инфраструктуры в подразделениях. Случается. Часто. Но звонить надо, поэтому ставятся городские телефоны или люди просто используют корпоративные мобильные пакеты. Сейчас этого добра уже достаточно и в перспективе будет еще больше. Чем хорош такой подход - делать ничего не надо. Оно работает. Чем плох - дорого. Как можно расправиться с корпоративным пакетом - запихнуть его в GSM гейт. О чем идет речь - существует оборудование которое можно использовать для GSM телефонии и к нему подключать или обычные телефоны или офисные АТС. Удобно в случае если нужна телефонная линия, а физически доступна только сеть мобильной связи. Есть альтернативный вариант - если офис подключен к Интернету и существует нормальный интернет-канал - настроить телефонное взаимодействие офисов через Интернет. Мы говорим о канале более 128 кб/с. 

   Что для этого требуется - оборудование перевода телефонного сигнала в Интернет-формат и программное обеспечение управления всем этим оборудованием. Задачу ставим следующим образом: есть 3 офиса, территориально разнесенные на большое расстояние, подключенные к Интернет и между офисами настроены виртуальные сети как это описано в предыдущей статье или какие-либо иные схемы. Главное условие - мы не выходим с адресами этих сетей непосредственно в Интернет.

   Какое выбираем оборудование - здесь будет дан пример выполнения телефонии на оборудовании H.323. Существует более новый стандарт - SIP. Пускай существует. Мы работаем с H.323. Пока в подробности не вдаемся. Основная наша задача пока - помнить что стандартов несколько и сосредотачиваться на чем-то одном.

   Считаем, что внутри офисов существуют локальные телефонные станции. Для станций ряда Panasonic - проблем не возникает. Для Siemens - немного по другому. Серии Hicom-120/125 по программному обеспечению не позволяют (по крайней мере мы не нашли варианта) для формирования тоновых посылок с системного телефона на внутренний телефонный номер. То есть, при звонках через внешний порт АТС (в город) путем последовательного нажатия кнопок “*” и “#” после этой комбинации в порт выдаются DTMF посылки - можно управлять устройствами на внешнем канале. Это не получается при звонках с системного телефона на внутренний порт. После длительных переговоров с различными телефонными гуру - решения вопроса не было. То ли не того уровня гуру нам попадались, то ли это действительно из-за древности идеологии Hicom-120/125 - нам было разъяснено что она этого не может. Мы говорим только о системном телефоне. С обычным телефоном вообще этих вопросов не возникает. Ставишь его под DTMF и работаешь. В связи с этим принято решение - перейти на HiPath. Там это делается сразу, но при заказе станции необходимо указать это условие как обязательное в техническом задании - все «супер» гуру очень хорошо умеют считать деньги и постоянно- чего-то недоговаривать, оставляя себе сладенький кусочек на перспективу. Смотришь клиент проснется - и чего-то еще отломится. Это и есть причина почему такого класса требования надо писать на бумаге и, особенно, когда чувствуете какое-то неудобство при ведении переговоров с потенциальным поставщиком или инсталлятором АТС (да и любого другого сложного оборудования) до того как уплатить деньги требовать подписи подобного документа потенциальным исполнителем / поставщиком. В противном случае - придется платить деньги еще и за «сложное конфигурирование» а то и воевать по поводу полного возврата оборудования из-за его функциональной непригодности.

    Что мы делаем - ставим достаточно простое оборудование. Какое. Какое существует. Какое продается. В принципе для наших условий существует два интерфейса VoIP оборудования - FXO и FXS. Что это - это два типа подключений - FXS порт изображает из себя порт АТС - то есть он в состоянии только выдавать напряжение звонка в линию, соответственно - это эмуляция той телефонной пары которая приходит с городской АТС - к нему подключается обычный телефон, способный по умолчанию работать в DTMF. Другой тип порта - FXO - он эмулирует пользовательский телефонный аппарат в части того, что он может «снимать трубку», отвечать и набирать номер. Так как это телефонный интерфейс - он также может воспринимать набор, передаваемый ему в DTMF. Этот порт подключается к порту телефонной станции как обычный телефон или факс. Телефонная станция конфигурируется для работы по этому порту в DTMF. Это нам и надо. 

   Кто производители оборудования - их много. Список можно найти например здесь http://www.gnugk.org/interoperability.html и здесь http://www.gnugk.org/interoperability-2.html Список внушает уважение, но не более. Наш выбор невелик - Dynamix или NSG. Кто-то может добыть Micronet. Не будем вдаваться в подробности этих устройств - общее у них - версия прошивки. Это базовое устройство одного производителя и во все эти устройства заливается одинаковое программное обеспечение. Что еще с этими устройствами полезного на перспективу - перезаливкой программного обеспечения эти устройства можно перевести с протокола работы H.323 на протокол SIP. Кто знает как со временем сложатся требования - может придется переходить на SIP - тогда что-то при подобном выборе можно будет сэкономить. Почему мы не говорим о DLink ? Да, DLink существуют, они определились что более не поддерживают H.323 - не будем с ними спорить. Очень полезно по поводу DLink зайти на http://www.dlink.ru в раздел Форум и почитать статьи на предмет формата и спектра задаваемых вопросов и качества ответов. Если Вам будут настраивать систему телефонии сторонние фирмы и они полностью будут нести ответственность за работоспособность строящейся системы - всегда пожалуйста, но мы должны строить сами.

   Выберем для примера Dynamix 0004/H. Это 4-х портовая VoIP FXO система. Так как подобные устройства обычно как пирожки на лотке не продаются , то в фирме в которой мы их будем покупать попросим перешить их сразу под прошивку 2m4fxo118b. Это последняя стабильно работающая прошивка для этого класса устройств. Что потребуется еще - FreeBSD. Считаем что она настроена и работает. VPN подняты. Там есть место для инсталляции и настройки GateKeeper - программного обеспечения управления телефонными каналами.

Технология предполагается следующая - есть 3 офиса. В каждом офисе устанавливается VoIP устройство. Для каждого офиса определяем его «код дозвона» - то есть при наборе номера «код дозвона» будет определять то устройство на котором мы хотим прийти для последующего донабора на внутренней АТС.

Как будет производиться звонок: 
 - допустим мы находимся в офисе А и звоним в о. Б на номер 206 
 - набираем внутренний номер порта на телефонной станции 118 офиса А 
 - слышим голосовое приветствие 
 - набираем код офиса Б - 5 
 - набираем нужный номер - 206 
 - завершаем набор символом «#» 

или

 - допустим мы находимся в офисе С и звоним в о. А на номер 106 
 - набираем внутренний номер порта на телефонной станции 318 
 - слышим голосовое приветствие 
 - набираем код офиса А - 2 
 - набираем нужный номер - 106 
 - завершаем набор символом «#» 

   Приниматься звонок обычно будет на последний подключенный порт VoIP устройства. Что можно оговорить при конфигурировании офисной АТС - создать группу для звонков на VoIP устройство. Примерно вот как: определяемся - что мы звоним на номер 118 - он занят - звонок сразу же маршрутизируется на 119. То есть все пользователи знают только один номер обращения к устройству, а дальше сама АТС определяет на какой свободный порт перебросить этот звонок.

То есть логически достаточно ясная схема работы. Может предложенная схема и не «прозрачна» - в таком случае вам необходимо идти по направлению стекирования используемых АТС. Но это другие масштабы, другие деньги и другие затраты на обслуживание. Технически могут быть и другие вариации использования оборудования и схем организации телефонии, которые может будут более технологичны, но мы реализуем описанный выше подход. Особенности этого подхода:
 - ясная схема использования для сотрудников 
 - простота реализации 
 - возможность контроля звонков 
 - возможность блокирования определенных направлений или номеров для дозвона 
 - возможность перенаправления звонков 

С чего начинаем. Берем в аренду нужное количество устройств с прошивкой 2m4fxo118b. 
   Если не удалось получить именно с этой прошивкой - не страшно. Начинаем с тем что у нас есть. Или идем на http://www.micronet.info или на сайт производителя и скачиваем 2-х мегабайтный образ прошивки. Дополнительно потребуется TFTP сервер под Windows, компьютер с COM - портом. Найдите в документации на устройство порядок подключение HyperTerm (стандартная компонента Windows/Communications) - в части точного описания параметров, выставляемых для COM-порта в HyperTerm. Устройство поставляется с кабелем подключения к COM-порту.
   Если что-то не получилось или мы не дождались полной перепрошивки устройства и оно больше не грузится. В общем случае - не страшно. Еще не все потеряно. Данные устройства сконструированы так, что первоначально загружается загрузчик, а только потом загружается сама прошивка. Нам нужно будет перезалить прошивку находясь не на уровне самой прошивки - не в ее программном окружении - а на более низком уровне - на уровне загрузчика. Техподдержка отлично знает порядок действий в этом случае и стандартные пароли загрузчика устройства. В противном случае - http://www.micronet.info вопрос 23 разъяснит многое. 

Дальше. Рисуем схему сети:

Действуем в соответствии со схемой:
 - Через HyperTerm / COM-порт на всех трех устройствах меняем необходимые IP, Gateway, проверяем маски и обязательно проверяем наличие чего-то логически удобоваримого в MAC адресе. Устройство работоспособно при невыставленном MAC.

Устанавливаем устройства в их сетях. Проверяем доступность устройств как по Telnet так и по HTTP. Нам понадобятся и первое и второе.
Что делается по Telnet:

1-А  - программируем интерфейсы (если это до конца не сделано из консоли - через COM-порт). DNS указан в файле конфигурации, проставим его, но ничего сказать об его практическом использовании мы не можем. Блок от PPPoE user name - до конца - не трогаем вообще. Что стоит - то и стоит. 

1-Б

1-С

2. Системные параметры: 
 - Inter-Digits time - время в секундах от момента набора последней цифры в телефонный порт устройства до момента
   завершения приема набранной посылки, формирования задания и отправки задания по соединению на обработку. 
   Для «тугодумов», которые не помнят «на взлет» набираемый номер - этот фактор может стать определенной проблемой.
   Это одна из причин почему в системе принято стандартом завершать набор указателем «законченности» набора
    номера « # »
 - User defined prefix disable - код нашего офиса: А-2, Б-5, С-9, убираем префикс при принятии звонка
 - Local generate ring back tone - в момент выполнения соединения - хотим чтобы трубка не молчала а выдавала подобие
    гудков дозвона
 - Ring before answer - количество гудков с PBX после которых устройство снимает трубку
 - End of dial - требование восприятия символа # как завершение команды и немедленного набора номера 

1-А

1-Б

1-С

3. Конфигурирование H.323 

3-А

3-Б

3-C

4. Устанавливаем параметры голосового (телефонного) сигнала и кодеки. 
   Эта страница приводится как справочная. Все указанные параметры намного удобнее делать из HTTP интерфейса. Что мы здесь корректируем - порядок следования кодеков и громкость приема/передачи. DTMF громкость оставляем без изменений. С громкостью особо увлекаться не стоит - может искажаться звук. Все для всех устройств одинаково.

5. Различные протоколы - так как не являются для нас приоритетными - не рассматривались. Остаются как есть. Будем с ними разбираться позже. Когда будет все работать. А то и вообще перейдем на E-Mail. 

6. Phone. Не трогаем. Как работает - пусть так и работает. 
7. Tone. Вот с этим нам может придется повеселиться. 

   Одной из задач функционирования устройства IP телефонии является точное идентифицирование тонов занятости (Busy) со стороны телефонной станции. Для начала сконфигурируем полностью телефонную систему, и потом в случае если эта часть не будет работать - будем настраивать и ее. Если работает - забываем этот раздел и говорим себе - хорошо, пронесло. Что значит работает - не работает. Если после окончания разговора устройство не «ложит трубку» в сторону PBX более 5 секунд - значит не работает. Надо настраивать.
    Порядок настройки. Настройка (программирование) устройства ведется из HTTP интерфейса. Что нам понадобится из оборудования - микрофон, компьютерные колонки, провод соединяющий VoIP устройство и PBX к которому в центре можно подключить напрямую компьютерную колонку (с блоком питания у усилителем) и через нее услышать искомый сигнал «занято». То есть фигурально выражаясь - делаем провод для «прослушки» и «прослушиваем» на компьютерную колонку. Микрофон подносим к колонке и пишем сигнал «занято» в звуковой файл на компьютер в виде WAV файла. Это можем сделать даже средствами Windows - Sound Recorder. C:\WINDOWS\System32\sndrec32.exe. Дальше - ставим SoundForge. Подойдет даже какая-нибудь древняя версия. По примеру с 4.5 делаем следующее: считываем записанный файл, прямо на экране определяем временные параметры включения/выключение сигнала «занято» - перемешаем курсор к началу/концу сигнала и записываем время (справа внизу в формате 00:00:05.455). Записываем показания примерно 5-6 импульсов и в табличке определяем их длительность (А на рисунке). 

  Делаем подобные вычисления точнее и принимаем средние значения - пауза/сигнал. 

   Теперь, в том же SoundForge - отмечаем курсором сигнал занятости, потом - Tools - Spectrum Analyses. В окне спектрального анализа выставляем в Options-Settings пределы анализируемых частот - скажем от 350 до 450 гц. Программа выдаст пик частот. Можем дать Update. В результате мы получили временные и частотные параметры сигнала «занято». На рисунке записан анализ для Hicom-125.

  Что дальше - ставим в соответствующем окне HTTP интерфейса настройки устройства.
  Записано в первой строке следующее - частота - 425 гц, скважность сигнала - 350 мс. Это стандартной значение для станций HiPath-3000.

   Таблица большая из предположения, что станция сильно умная и на каждый вариант она может выдавать свой отличный от другого сигнал. Мы работаем только с одной строкой. В большинстве случаев этого достаточно.

И последнее - настраиваем TOS. Это выставление приоритетов прохождения VoIP сигнала по Ethernet сетям.
Делается одинаково для всех устройств.

   Не будем вдаваться в подробности максимально значения параметра TOS. Выставим 6.
   Как было сказано ранее - мы не говорим простейшие вещи по конфигурированию - но один раз напомним - команды Commit / Reboot. В документации об этом написано. 
   Итак, считаем что Hardware инфраструктура готова. Проверяем доступность до всех устройств из офиса С (там будет размещаться GateKeeper). Пробуем, перегружаем, слушаем голос вежливой барышни со всех сторон и думаем что будем делать дальше. А дальше - ставим GNU GateKeeper.
   Так как ранее мы ориентировались в построении всей инфраструктуры на FreeBSD - продолжим в том же духе. У нас есть FreeBSD 5.4. 
Ставим
/usr/ports/net/gatekeeper
Make
Make install

Или то же самое делаем через pkg_add - но будьте готовы к тому, что достаточно много вспомогательных пакетов будет устанавливаться. Теоретически можно ставить самый распоследний GateKeeper - но начать надо с анализа одной странички и размышлений о привязанности этого пакета к большому числу вспомогательных пакетов: http://www.gnugk.org/compiling-gnugk.html. Занимательный документ. Ясно написано для FreeBSD что надо крепко ковыряться для получения работающей системы. Тихо об этом забываем и ставим то, что скомпилировано в дистрибутиве и по уверению разработчиков FreeBSD работает. Теоретически существует версия для Windows. Да. Существует. Только одна особенность, никем со стороны разработчиков GNUGK не признаваемая - Dynamix с GNUGK под Win-2000 сервер или Win-2003 сервер не работает. Суть вот в чем. Оно работает. Но падает. С периодичностью от 20 мин до 2-х недель совершенно бессистемно. После длительных разборок (и с техподдержкой Dynamix) общее мнение, удовлетворяющее обе стороны, следующее: видимо какие-то проблемы у Динамиксов с разбором TCP/IP пакетов производства Microsoft, сформированных Win-2003. Разбираться с этим - не представляется возможным - нерегулярные падения. Нельзя идентифицировать стабильный момент зависания устройства. Зависает оно по Ethernet стороне. Решение - ставить только в Unix окружении. Так и ставим.

Развернули. Поставили. Нарисуем файл /usr/local/etc/gnugk.ini
Оставлено то что для нас существенно. Комментарии прилагаются. Все дано для примеров устройств выше.

; comments may start with # (only unix) or ; (unix or windows)
;; Boolean values.
;; Boolean Values are retresented by a case insensitive string
;; - "t"..., "y"... or "1" for TRUE
;; - all other for FALSE

;; NOTE: This parameters may be loaded at program startup and not influenced by the HUP signal.
[Gatekeeper::Main]
;; 'config is present' indicator. Has to be 42. - Это всегда так, как пароль
Fourtytwo=42 
; Includes in some RAS-Msgs
Name=GK-OFC
; overwritten from command line parameter
Home=192.168.60.252
;NetworkInterfaces=
TimeToLive=300
;TotalBandwidth=100000
;StatusPort=7000
;StatusTraceLevel=2
;UseBroadcastListener=0
;;
;; Failover support
;;
;AlternateGKs=1.2.3.4:1719:false:120:OpenH323GK2
;Sendto=1.2.3.4:1719
;EndpointIDSuffix=_gk1
;SkipForwards=4.3.2.1
;RedirectGK=Calls > 50
;;
;; You should never need to change any of the following values.
;; They are mainly used for testing or very sophisticated applications.
;;
;UnicastRasPort=1719
;MulticastPort=1718
;MulticastGroup=224.0.1.41
;EndpointSignalPort=1720
;ListenQueueLength=1024
;TimestampFormat=RFC822


[LogFile]

; hourly - once per hour
; daily - once per day,
; weekly - once per week,
; monthly - once per month
Rotate=hourly
; For weekly rotation:
; Mon, Tue, Wed, Thu, Fri, Sat, Sun
; Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday
; 1, 2, 3, 4, 5, 6, 0
;RotateDay=Sun
; For monthly rotation (31th of each month, or the last day of the month
; if it has less than 31 days)
; RotateDay=31
; For daily, weekly and monthly rotation (rotation will be performed at 4:00)
RotateTime=15
; For hourly rotation (rotation will be performed at 0:59, 1:59, ...)
;RotateTime=59


;; Здесь может быть одна заминка - проверьте соответствие портов на устройстве в разделе h323 и здесь
;; по умолчанию - могут быть разные порты
[RoutedMode]
GKRouted=1
H245Routed=0
CallSignalPort=1720
CallSignalHandlerNumber=1
RemoveH245AddressOnTunneling=0
AcceptNeighborsCalls=1
AcceptUnregisteredCalls=1
SupportNATedEndpoints=1
DropCallsByReleaseComplete=1
;RemoveCallOnDRQ=1
;SendReleaseCompleteOnDRQ=0
;ScreenDisplayIE=
;ScreenCallingPartyNumberIE=
;ScreenSourceAddress=
;ForwardOnFacility=1
;ShowForwarderNumber=1
;Q931PortRange=20000-20999
;H245PortRange=30000-30999
;ConnectTimeout=180000
;SetupTimeout=8000
TcpKeepAlive=1


[Proxy]

;Enable=1
;InternalNetwork=10.0.1.0/255.255.255.0,127.0.0.0/8
;T120PortRange=40000-40999
;RTPPortRange=50000-59999
;ProxyForNAT=1
;ProxyForSameNAT=0 


;[Endpoint]
;Gatekeeper=no
;Gatekeeper=auto
;Gatekeeper=210.58.112.188
;Type=Gateway
;H323ID=CitronProxy
;E164=18888600000
;Password=
;Prefix=18888600,1888890003
;TimeToLive=900
;RRQRetryInterval=10
;UnregisterOnReload=0
;NATRetryInterval=60
;NATKeepaliveInterval=86400
;Discovery=1
;GatekeeperIdentifier=ParentGKId
;UseAlternateGK=1
;EndpointIdentifier=ChildGKId

;[Endpoint::RewriteE164]
;188889000=9


;;
;; Prefixes of e164 numbers for gateways.
;; A dot (.) matches any digit, ! at the beginning disables the prefix
;; Separate list elements by one of " ,;\t".
;; @see RasTbl::addPrefixes
;; This parameters should consider a HUP signal.
[RasSrv::GWPrefixes]
;; Test-Gateways



[RasSrv::RRQFeatures]

;OverwriteEPOnSameAddress=1
;AcceptEndpointIdentifier=1
;AcceptGatewayPrefixes=1


[RasSrv::ARQFeatures]

ArjReasonRouteCallToSCN=0
ArjReasonRouteCallToGatekeeper=1
CallUnregisteredEndpoints=1
RemoveTrailingChar=#
RoundRobinGateways=1 


;; Routing polices define how the message destination is located
;; and where the call is routed. Currently the following policies
;; are implemented:
;;
;; explicit (only ARQ,Setup,Facility)
;;
;;    If destCallSignalAddress is specified by the message,
;;    the call is routed to this address - aliases, prefixes,
;;    parent, neighbors are not further checked.
;;
;; internal
;;
;;    A local GK registration table is checked for matching alias.
;;
;; parent
;;
;;    A parent gatekeeper (if this GK is registered as a child GK)
;;    is queried with ARQ or LRQ.
;;
;; dns
;;
;;    Routing request aliases are scanned for presence of 'name@domain'
;;    alias types - if such an alias is found, domain part is removed
;;    and the call is routed to the endpoint 'name' at domain:1720.
;;
;; vqueue (only ARQ)
;;
;;    Destination alises are checked for match with a virtual queue name
;;    (configure via CTI::Agents). If there is a match, RoutingRequest
;;    is signalled and the call is routed to the destination specified
;;    by some external application (like ACD).
;;
;; neighbor
;;
;;    The gatekeeper neighbors are queries with LRQ for the destination
;;    of this routing request. 


[RoutingPolicy]

default=explicit,internal,parent,neighbor

;[RoutingPolicy::OnARQ]
;h323_ID=vqueue,internal
;default=explicit,internal

;[RoutingPolicy::OnLRQ]
;0048=internal
;default=neighbor

;[RoutingPolicy::OnSetup]
;dialedDigits=internal,neighbor
;default=explicit,internal,parent,neighbor

;[RoutingPolicy::OnFacility]
;default=internal

[RasSrv::RRQAuth]

;; On a RRQ the h323-alias is queried from this section.
;; If there is an entry the endpoint is authenticated against the given rules.

;; If there is no entry the default action is performed. The default action
;; is to confirm the RRQ, unless the parameter "default=reject" is given.
;;
;; Notation:
;;     <authrules> := empty | <authrule> "&" <authrules>
;;    <authrule> := <authtype> ":" <authparams>
;;    <authtype> := "sigaddr" | "sigip"
;;    <autparams> := [!&]*
;; The notation and meaning of <authparams> depends on <authtype>:
;; - sigaddr: extended regular expression that has to match agains the
;;    "PrintOn(ostream)" representation of the signal address of the request.
;;     Example: "sigaddr:.*ipAddress .* ip = .* c3 47 e2 a5 .*port = 1720.*"
;; - sigip: specialized form of "sigaddr". Write the signalling ip adresse
;;    using (commonly used) decimal notation: "byteA.byteB.byteC.byteD:port"
;;    Example of the above sigaddr: "sigip:195.71.226.165:1720"
;;
;; This parameters should consider a HUP signal.


;; Это и есть наши устройства
ofa=sigip:192.168.40.251:1720
ofb=sigip:192.168.41.251:1720
ofc=sigip:192.168.60.251:1720

default=confirm



;; The parameter "rule" may be one of the following:
;; - "forbid" disallow any connection (default when no rule us given)
;; - "allow" allow any connection
;; - "explicit" reads the parameter ;"<ip>=<value>"; with ip is the ip4-address
;; if the peering client. ;<value>; is resolved with ;Toolkit::AsBool;. If the ip
;; is not listed the param "default" is used.
;; - "regex" the ;<ip>; of the client is matched against the given regular expression.
;; First the ip-rules (like "explicit") are tested. Olny of no such param exists
;; the regex is tried.
;; Example: "regex=^195\.71\.(129|131)\.[0-9]+$"
;; - "password" queries remote user for login/password combination and checks
;; it against username/password stored in this section. Passwords are encrypted
;; with addpasswd utility using KeyFilled encryption key. DelayReject defines
;; delay before reject is sent.

[GkStatus::Auth]

rule=allow
;regex=^(195\.71\.(129|100)\.[0-9]+)|(62\.52\.26\.[1-2][0-9][0-9])$
; only used when "rule=explicit"
;default=forbid
;Shutdown=0
;KeyFilled=123
;DelayReject=5
;LoginTimeout=120 

;;
;; Beside other things every number to rewrite has its
;; own key/value-line. The implemententation is such that
;; all numbers that shell be rewritten have to begin
;; with a common prefix given by 'Fastmatch'.
;;
;; Doc From the code:
;;   // Do rewrite to ;newE164;. Append the suffix too.
;;   // old: 01901234999
;;   // 999 Suffix
;;   // 0190 Fastmatch
;;   // 01901234 prefix, Config-Rule: 01901234=0521321
;;   // new: 0521321999
;;
;; The rewrite-numbers function take care of reloads/a HUP signal.



[RasSrv::RewriteE164]

;; Only if an e164 number begins with ;Fastmatch; the
;; the further rewriting is done. Only one #Fastmatch# can be given.
;Fastmatch=
;0190703100=052418088663
;01903142=
0521178260
;5241908601903142=521178260
;7777.=.
;%%%%48=48



;; Это пошли запреты и замены
;; запретим звонить на номер 2-115, просто заменим эту посылку на 0, устройство обрежет звонок

Fastmach=2115
2115=0
;; звонок на номер 5-115 переведем на 5-105
Fastmach=5115
5115=5105

;; звонок на номер 9-112 переведем на 2-102

Fastmach=9112
9112=2102


;---------------------------------------------------------

[FileAcct]
; a full path to a file where CDRs will be logged
;; пишем лог звонков
DetailFile=/var/log/gkkbp.log
; 1 to use status interface compatible CDRs, 0 to build CDR from CDRString
StandardCDRFormat=1
; parametrized CDR format string
CDRString=%s|%u|%{Calling-Station-Id}|%{Called-Station-Id}|%d|%c
; timestamp format for CDR strings
TimestampFormat=ISO8601
; hourly - once per hour
; daily - once per day,
; weekly - once per week,
; monthly - once per month
Rotate=hourly
; For weekly rotation:
; Mon, Tue, Wed, Thu, Fri, Sat, Sun
; Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday
; 1, 2, 3, 4, 5, 6, 0
;RotateDay=Sun
; For monthly rotation (31th of each month, or the last day of the month
; if it has less than 31 days)
; RotateDay=31
; For daily, weekly and monthly rotation (rotation will be performed at 4:00)
;RotateTime=4:00
; For hourly rotation (rotation will be performed at 0:59, 1:59, ...)
RotateTime=46 

Запускаем Гейткипер 

>/usr/local/bin/gnugk -c /usr/local/etc/gnugk.ini

Проверяем работоспособность

$ ps ax| grep gnugk
97349 p0 S+ 0:00.01 /bin/sh -c ps ax| grep gnugk
97351 p0 S+ 0:00.01 grep gnugk
39198 v3 S+ 34:18.77 /usr/local/bin/gnugk -c /usr/local/etc/ gnugk.ini
Press any key to continue...


   Что дальше - заходим на это же машину по порту 7000 - получаем консоль гейткипера.
   По команде « ? » получаем список всех подключенных устройств.
   Дальше - видим какие порты (сканируем, в крайнем случае) и адреса (сами ставили) используются и обслуживаются гейткипером и соответственного - думаем что делать с Firewall, оставляя доступ только с VoIP устройств и тех машин на которых надо настроить MS NetMeeting. 
   Мы заведомо не занимались вопросами защиты - после установки системы системный администратор самостоятельно для себя должен решить что разрешается а что нет. Это не описание Call-центра. Это простая корпоративная система телефонии.

  Результат: система работает.  
   Осматриваемся, читаем документацию, звоним, смотрим самостоятельно ПРИ РАБОТАЮЩЕЙ СИСТЕМЕ что можно сделать лучше.


B. Yasynetskyy
iasb@yahoo.com

M.Yasynetska
marsha@list.ru

6.11.2005

Оригинал статьи приведен на :
http://www.opennet.ru/opennews/art.shtml?num=6659
http://iasb.narod.ru/voip.htm