В план звонков Vega Vega 50 6x4 fxs, fxo и bri & Vega 400




Дата15.04.2017
Размер0.74 Mb.
Просмотров60
Скачиваний0


Введение в план
звонков Vega
Vega 50 6x4 FXS, FXO и BRI & Vega 400
Vega dial plans (планы звонков) позволяет шлюзу маршрутизировать, аутентифицировать и применять трансляцию номеров для входящих звонков и направлять их по маршруту. Этот документ обеспечивает введение в конструирование записей плана звонков для обеспечения функциональных требований.
Приложение в конце предоставляет несколько примеров плана звонков.
Введение в план звонков.
В VoIP, установка, маршрутизация, аутентификация и трансляция номеров, могу производиться SIP proxy, привратником H.323, или правилами в шлюзе Vega (известными как записи плана звонков
Vega). Эти записи могут фактически быть полезны даже когда основная маршрутизация, аутентификация и трансляция номеров производятся SIP proxy или привратником H.323, планировщик звонков Vega может использоваться, например для трансляции местных телефонных номеров в стандарт, используемый в VoIP сети – то есть для международных сетей. Vega может предопределять код страны в caller ID и набранные номера внутри страны для звонков приходящих на телефонный интерфейс, и цифры кода другой страны для звонков, приходящих с VoIP сети как их пересылать на телефонный интерфейс. Когда планировщик звонков Vega используется таким путем, SIP proxy или привратник H.323 только должен набирать полностью адаптированные интернациональные номера. Презентация ниже показывает обзор планировщика звонков Vega, и объясняет, используя примеры, как писать план звонков.

План звонков…
-
Встроен в маршрутизатор o
Список входных условий и выходных указаний
-
Планы и профили o
До 200 планов o
До 20 профилей o
До 50 планов на профиль o
Профили могут быть включены или выключены
-
Основной формат o
Source
=IF:iiii, дальнейшие условия o
Distanation
=IF:jjjj, дальнейшие детали
Шлюзы Vega обладают встроенными способностями маршрутизации, которые основаны на физическом интерфейсе, на который пришел звонок, набранном номере телефона, и другой информации, принятой шлюзом. Шлюз может решить, как и куда направить звонок. Как часть возможностей маршрутизации, планировщик звонков Vega может указать трансляцию номеров и другую модификацию данных, такую как добавление или удаление префиксов телефонных номеров. Когда шлюз Vega принимает информацию Caller ID, он может так же разрешить или запретить звонки, основываясь на номере телефона, с которого был произведен звонок.
Маршрутизатор, так же известный, как планировщик звонков, использует маршрутизацию, основанную на правилах, известных как записи планировщика звонков, используемых для указания, как маршрутизировать звонки. Каждое правило (запись) содержит входные условия — которые являются фильтром, через который проходят только звонки, которые поддерживаются правилом, и даются соответствующие выходные указания, которые определяют, как направить звонок к абоненту.
Если параметры входящего звонока совпадают со входными условиями, соответствующие выходные указания используются для маршрутизации звонка.
Шлюзы Vega поддерживают до 200 записей. Эти записи могут группироваться в профили.
Концепция профиля — облегчить использование и управление планом звонков. Лучший путь использования профилей — использовать их для группирования записей с общей темой, то есть, один может быть использован для звонков в/из Лондона, 2-й для звонков в/из Сан Франциско и третий для Бангладеш. Если позже потребуются изменения в плане звонков, это облегчит поиск требуемой для модификации записи.
Vega поддерживает до 25 профилей, и каждый профиль может содержать до 50 записей планировщика звонков.
Однако, отдельные записи в плане звонков не могут быть включены или выключены, каждый профиль может быть включен или выключен. Если профиль включен, все записи в этом профиле участвуют в процессе маршрутизации; если профиль выключен, все его записи игнорируются.
Профили не ассоциированы ни с какими приоритетами, поэтому, если запись плана во включенном профиле она будет использована наравне с другими записями плана во включенном профиле.
Записи планировщика звонков имеют следующий формат:
Source
= интерфейс (IF:), за двоеточием следует интерфейс ID (например 0101 для порта
FXS1).
Звонки с этого интерфейса соответствует поддерживаются планом, и далее идет пассмотрение следующих условий, например таких как номер звонящего абонента, полученный с помощью Caller ID.

Destination
= интерфейс (IF:), за двоеточием следует интерфейс ID (например 0202 для порта FXO2), на который звонок должен быть отпарвлен.
Выражение Source ограничивает диапазон входящих звонков до соответствующих правилу.
Выражение Destination указывает, что делать со звонком, совпадающим с входным (source) выражением.
Если входящий звонок не совпадает с выражением в плане звонков, то звонок отбрасывается.
Интерфейс ID показаны выше. Шлюзы используют 4 цифры для обозначения интерфейс ID, где первые 2 цифры обозначают тип интерфейса и вторые 2 цифры обозначают номер интерфейса.
С версии R8.0, Vega 400 использует 4 цифры для ID интерфейса: 0401, 0402, 0403, 0404 для обозначения потоковых интерфейсов Е1, и идентификаторы с 9901 до 9905 или идентификатор
0501 для обозначения IP/Ethernet интерфейса. Идентификаторы с 9901 по 9905 выбирают подходящий SIP профиль, для маршрутизации SIP звонков.
Однако, в версии R8.0 все входящие SIP звонки будут приняты на интерфейс 9901, следующие сборки будут разделять звонки на 9901, 9902 и так далее, в зависимости от их источника. Планы звонков для поддержки входящих SIP должны быть записаны в поддерживаемые звонки с любых
99xx интерфейсов, то есть для выражения source, используйте IF:99..
Информация, используемая в записях плана звонков, указана как TOKEN. Значения TOKEN могут быть приемлемы или нет, в зависимости от того, какое это выражение, source или destination. Так же это может быть телефонный интерфейс или VoIP интерфейс. Иллюстрация ниже показывает действительные TOKEN для SIP шлюза Vega.

TOKEN должны быть записаны ЗАГЛАВНЫМИ буквами и за ними должны следовать (:)
TOKEN имеют следующие значения:
IF:
- интерфейс
TEL: - телефонный номер
TELC:
- телефонный номер звонящего (Caller ID)
TA:
- транспортный адрес (IP адрес, на который нужно послать звонок VoIP) . Включая порт, например 192.168.1.52:5070
TAC: - транспортный адрес звонящей стороны (IP адрес устройства, посылающего звонок)
DISP: -
Поле со значением для индикации на дисплее оконечного устройства
NAME: -
Имя, используемое для соединения с абонентом
NAMEC: -
Имя звонящего
CAPDESC: - описание возможностей, позволяет выбрать кодек для звонка.
QOS: -
Quality Of Service для этого звонка. Актуально, когда используется 802.1q (VLAN)
Все TOKEN — дополнительные параметры. Строго рекомендовано, чтобы IF: был определен для каждой записи плана звонков. В основном, только TEL: и TA: необходимы (TA: только на исходящие VoIP звонки).
Для входящих звонков на телефонный интерфейс:
IF: определяет приемлемый номер интерфейса для данного плана звонков
TEL: определяет набранные телефонные номера/диапазон номеров, которые будет обрабатывать данная запись плана звонков
TELC: не типично использовать, но если есть, то это ограничивает, с каких номеров приемлемо звонить.
Очень полезно когда разрабатываются новые планы звонков на живой системе. Записываются новые планы звонков с TELC: в выражении source которое совпадает с Вашим тестовым
телефонным номером – поэтому, только звонки с этого телефона будут использовать эту запись плана. Звонки с других телефонов будут использовать существующие записи. Когда новый план будет проверен, TELC: в выражении source может быть удалена.
Для исходящих VoIP звонков:

IF:
05 или 0501 для H.323 и 99 или с 9901 по 9905 для SIP.
TEL: телефонный номер, который будет использован для исходящего звонка (номер удаленного абонента)
TA:
IP адрес (+ порт) для посылки звонка (удаленный шлюз / SIP прокси / привратник H.323)
DISP: информация, для показа на дисплее принимающего устройства, если оно имеет дисплей
NAME: имя абонента для звонка, имя может быть использовано вместо TEL:
TELC: по умолчанию Caller ID который был принят при входящем звонке будет передан на исходящий звонок. TELC: позволяет переписать информацию caller ID в исходящем звонке
CAPDESC:
Список кодеков
QOS:
QOS профиль – определяет VLAN ID для посылки VoIP звонка
Для входящих VoIP звонков

IF: будет 05 или 0501 для H.323 и 99 или от 9901 до 9905 для SIP.
TEL: определяет набранный телефонный номер / диапазон номеров, поддерживаемых записью плана.
TELC: это ограничивает, с каких телефонов можно совершать звонки
DISP: проверяет, что информация для дисплея, содержит указанное значение
TAC: ограничивает поддерживаемые устройства по IP
NAME: определяет набранное имя NAME которое поддерживает данная запись
NAMEC: ограничивает имена звонящих, приемлемые для записи данного плана
QOS:
QOS профиль – указывает VLAN ID для приема звонка
Для исходящих звонков на телефонный интерфейс:
IF:
ID телефонного интерфейса
TEL: телефонный номер, набранный для исходящего звонка
DISP:
ISDN имеет возможность указать информацию для дисплея принимающего устройства.
TELC: по умолчанию Caller ID который был принят при входящем звонке и будет передан на исходящий звонок. TELC: позволяет переписать информацию caller ID в исходящем звонке.
План звонков…
-
Регулярные выражения для source: o
. единичный символ o
< > перехватывает последовательность символов в угловых скобках и хранит их o
[abc] единичный символ из списка внутри квадратных скобок o
[x-y] единичный символ из диапазона от x до y o
[^abc] единичный символ, за исключением указанных в скобках o
* повторение предыдущего символа ноль или более раз o
+ повторение предыдущего символа один или более раз o
? повторение предыдущего символа ноль или один раз o
\ передача следующего символа в литеральном значении, даже если он имеет специальное значение.

Для разрешения маршрутизации групп телефонных номеров в одном плане набора, шлюзы Vega поддерживают несколько регулярных выражений (regexp) которые могут быть использованы в части source плана звонков.
Для примера опишем телефонную систему компании. Мы запишем несколько записей плана звонков для Vega 400 (SIP) который получает входящие звонки на интерфейс 0401. Предположим, что план звонков уже написан в шлюзе назначения, который пересылает звонки принимаемые им, на АТС пользователя.

Для начала взгляните на план набора на Vega 400 для маршрутизации принятого номера,
01344 784 900
, на другой шлюз
Source = IF:0401,TEL:01344784900




Destination = F:9901,TEL:01344784900,TA:w.x.y.z
Звонок, принятый на интерфейсе 0401, который имеет номер 01344784900 будет обработан этим планом звонков. Эти звонки будут направлены через интерфейс 9901, так же будет передан номер телефона 01344784900, и пойдет посылка на IP адрес w.x.y.z (адрес удаленного шлюза).
Сейчас с 350 планами звонков мы можем явно обработать 350 номеров. На практике мы часто хотим поддержать много больше номеров, чем здесь описано, и эти номера группируются в наборы. Мы можем использовать регулярные выражения в части source для указания группы телефонов. Например, компания хочет маршрутизировать группу из 10 номеров: от 01344 784 900 до 01344 784 909 на шлюз назначения.
Мы можем использовать ‘.’ для индикации последней цифры (0 — 9).
Source = IF:0401,TEL:0134478490.
Теперь задача стоит в пробросе набранного телефонного номера. Если мы следуем примеру выше и запишем TEL: с явным номером, все звонки 01344 784 90x посылались бы на 01344 784 900 – это не то что нам нужно!
Нам нужно сделать планировщик звонков который должен использовать номер который совпадает с регулярным выражением в части source и передаст его в выражение destination. Мы делаем это, используя угловые скобки ‘<’ и ‘>’. Угловые скобки вокруг цифр и регулярных выражений в части source говорят планировщику звонков что он должен входящее значение, совпадающее с диапазоном, указанным в скобках, поместить в локальное хранилище. Каждая запись плана звонков имеет собственное локальное хранилище которые начинаются с ID 1 (системе записи плана не нужно знать что используются другие хранилища других планов звонков, каждая запись плана звонков начинается с ID = 1).
В выражении destination сохраненное значение используется помещением номера хранилища между угловыми скобками, например, для хранилища 1, используется <1>
Поэтому мы можем записать наш план звонков, следующим образом:
Source = IF:0401,TEL:<0134478490.>
Destination = IF:9901,TEL:<1>,TA:w.x.y.z
Звонки, приходящие на интерфейс 0401, с номером 0134478490 и следующей одной цифрой будут обработаны этим планом. Цифры 0134478490 и дополнительная цифра будут сохранены в хранилище 1. Звонки совпадающие с выражением source будут направлены на интерфейс 9901, будет так же передан телефонный номер, хранящийся в 1 (0134478490 + 1 цифра), и вызов будет послан на IP адрес w.x.y.z
Следующее пояснение для 100 номеров из группы с 01344 784 900 до 01344 784 999
Мы можем использовать ‘..’ (2 точки) для индикации 2 последних цифр (0 - 9)
Source = IF:0401,TEL:<013447849..>
Destination = IF:9901,TEL:<1>,TA:w.x.y.z
Следующее пояснение для 200 номеров из группы 01344 784 800 - 01344 784 999
Используем ‘..’ для 2 последних цифр (0 — 9) и для индикации того, что предыдущая цифра 8 или
9, используем выражение [89]

Source = IF:0401,TEL:<01344784[89]..>
Destination = IF:9901,TEL:<1>,TA:w.x.y.z
Цифры между квадратными скобками показывают набор действительных цифр, расположенных в последовательности.
Например:
[1246] значит, что цифры 1 или 2 или 4 или 6 действительны для этой записи, и записываются данной последовательностью.
Есть другие короткие форматы записи:
[5678] ≡ [5-8] ≡ [^123490] набор 5, 6, 7, 8 то же, что набор с 5 до 8, который то же, что набор НЕ 1, 2, 3, 4, 9, 0.
До этого момента, все наши планы звонков были написаны для телефонных номеров фиксированной длины. Это, однако, не всегда возможно, особенно, например, где необходима поддержка международных звонков, например, различная длина номеров поддерживается в сети
Германии.
Выгода плана фиксированной длины в том, что Vega знает точно, когда закончен набор. С переменной длиной номера, Vega должна запускать таймер (так как это сделано на АТС и телефонных коммутаторах) для принятия решения об окончании набора. Истечение времени таймера означает конец набора номера.
Типичный пример использования номера переменной длины — всеобъемлющий план, разрешающий номера любой длины, и маршрутизирующий звонки через оператора:
Source = IF:0401,TEL:.*
Destination = IF:9901,TEL:01344784900,TA:w.x.y.z
Символ ‘*’ действует как множитель любой предыдущей цифры или регулярного выражения, позволяя их 0 или более вхождений. Работа регулярных выражений видна на следующем примере:
Символ
* + ?
Вхождение
Ноль или более раз
Один и более раз
Ноль или один раз
Пример
TEL:123*4 TEL:123+4 TEL:123?4
Совпадения
124 124
1234 1234 1234
12334 12334
123....34 123....34
Последнее регулярное выражение - это ‘\’, используется не часто, но иногда, например в приложении кол-центра, где телефонные номера имеют 2 и более наборов информации, это может быть определено с помощью * или #. План с TEL:123*4 не работает, требуется TEL:123\*4
Обратный слеш выключает специальное значение *, и Vega рассматривает *, как DTMF символ, а не как повторение предыдущей цифры 3. Регулярные выражения действительны в любых полях выражения source, включая TEL:, IF:, TELC:, TAC:.
Они не действительны в выражениях destination – шлюзу Vega нужно сказать точно, как отправить исходящий звонок (смотри далее действительные регулярные выражения для destination плана).
Заметьте, что пробелы НЕ допустимы в записях планов звонков. Пробелы рассматриваются как терминирующие символы, и если они найдены, следующие детали пропускаются. В выражении
DISP: пробел может использоваться.
Source = IF:0401,TEL:<013447849..>


Destination = “IF:9901,TEL:<1>,TA:w.x.y.z,DISP:External Call”

Когда используется переменная длина номера, возможно настроить Vega на определение тона обозначающего конец набора номера и не будет необходимости ждать конца работы таймера. По умолчанию Vega настроена на использование DTMF # тона. Нажатие # после набора номера позволяет шлюзу послать его немедленно.
В выражении destination только 3 типа регулярных выражений могут использоваться. Это , где n=номер хранилища, служит для переноса информации из выражения source в выражение destination.
Второе - тильда ‘
’ вставляет паузу на FXO внешний набор (только), то есть для посылки звонка наружу через порт 0201 — FXO:
Source = IF:99..,TEL:9<.*> Destination = IF:0201,TEL:9
<1>

Этот план использует ведущую 9 чтобы знать, что звонки предназначены для PSTN через подключение к АТС. ‘
’ работает так же как ‘,’ при установке модема на PC.
A ‘
’ вставляет паузу = 1 периоду DTMF (около 250ms). Если требуется большая задержка, может быть использовано множество ‘
’ символов.
Третье — обратный слеш, который экранирует следующий символ (как описано в регулярных выражениях source).
Больше примеров смотри в Annex 1

Во время написания плана звонков, разумно, чтобы диапазоны телефонных номеров, обрабатываемые разными планами звонков, накладывались друг на друга, особенно, когда один из планов - всеобъемлющий.
К счастью, Vega имеет метод приоритезации планов звонков. По умолчанию, когда план звонков создан, он создается с приоритетом ‘cost’ = 0. Это вызывает использование шлюзом Vega ‘longest matching’ (наиболее длинное совпадение) — алгоритма принятия решения, какой план является лучшим в указанном сценарии. Больше ‘explicit digits’ (явных цифр) определяют большую длину соответствия, приписанную записи плана звонков.
С планами звонков

IF:01..,TEL:<1234>

IF:01..,TEL:<123.>

IF:01..,TEL:<.*>

Алгоритм наиболее длинного совпадения будет смотреть на TEL: и брать длину соответствия 4 явных цифры для <1234>, 3 явных цифры для <123.> и 0 явных цифр для <.*>
Во время маршрутизации звонка Vega будет использовать план, который имеет самое длинное совпадение информации в выражении source.
Поэтому, если входящие звонки приходят на IF:0101 с номером 1234, то все, показанные выше записи плана звонков совпадают с этим входящим звонком, информация наиболее длинного совпадения, это IF:01..,TEL:<1234>, и этот план звонков будет использоваться.
Если входящие звонки приходят на IF:0101 с набранным номером 1235, первый план не совпадает, но следующие два - совпадают. План звонков, имеющий наибольшую длину совпадения, это
IF:01..,TEL:<123.>, и он будет использован.
Если входящие звонки приходят на IF:0101 с набранным номером вне диапазона 123x, то совпадает только план звонков IF:01..,TEL:<.*>, и он будет использован.
То есть, шлюз делает «разумный» выбор. Более близко совпадающее определение плана звонков с
входящей информацией, говорит о том, что наиболее вероятно, что данный план будет использоваться.
Если Вы хотите изменить назначение сделанное алгоритмом наиболее длинного совпадения, используйте параметр ‘cost’.
Нижнее значение cost, раньше будет сравниваться со входящей информацией из списка плана звонков. 1 — самый ранний в списке, 2 - второй, 9 - девятый и 0 — десятый и последний.
В основном, так как алгоритм наиболее длинного совпадения делает разумный выбор, иногда нужно изменение порядка с помощью ‘cost’. В случае, если выражения source одинаковые, вам нужно указать шлюзу Vega порядок использования планов. Каждый план должен иметь уникальный cost.
Cost с 1 по 9 не использует алгоритм наиболее длинного совпадения для приоритезации записей на одинаковых cost, поэтому для получения корректного порядка использования, для каждого набора накладывающихся планов звонков, должен быть только один план с cost 1, один план с cost 2, ..., один с cost 9, и затем много планов звонков требуются с cost 0.
Написанные планы звонков будут показаны командой ‘show plan’, или ‘show paths’ (доступно из
CLI и через web browser).
Show plan показывает список планов звонков в профиле в порядке их расположения.
Show paths может быть более полезен, он показывает планы в порядке приоритета интерфейса source.
‘Show paths’ показывает планы подходящие ко всем портам. ‘ Show paths nnnn’ показывает планы звонков подходящие для входящих портов nnnn.
Для проверки записей планов звонков не делая звонков с физического телефона, используйте команду try.
Как параметры команды, берутся TOKEN в том же формате, как они используются в плане звонков. Если нужно посмотреть что случилось если пришел звонок на порт Vega IF:0103 с
набранным номером 1234, введите:
Try IF:0103,TEL:1234
Vega покажет упорядоченный список записей плана звонков которые могут совпадать с входящим вызовом. Первый показанный план звонков будет с высшим приоритетом и эта запись будет использоваться для маршрутизации звонка .
Если произошел сбой звонка по определенной причине, планировщик звонков может быть настроен на переустановку вызова с другим адресом назначения, например с другим интерфейсом или другим номером телефона.
Например, если есть банк шлюзов Vega, через которые делаются звонки в PSTN, Vega принимающая инициирующий звонок, пошлет его на первый шлюз в банке. Первая Vega в банке, приняв звонок постарается сделать исходящий звонок на телефонный транковый интерфейс 0401.
Если транк заполнен (вернулся код cause 34) то Vega может попытаться использовать интерфейсы
0402, 0403 и последний 0404. Если все они заполнены (вернулся код cause 34 от каждого) то шлюз отбрасывает звонок назад к отправляющей Vega кодом cause 34. Отправляющая Vega может постараться переустановить звонок на вторую Vega в банке, и делать это, пока звонок не будет успешным – в этом случае, звонок происходит как ожидалось, или, при всех занятых транках, входящие звонки будут отброшены с кодом cause 34 (Сеть занята).
Тот же стиль может быть использован для переустановки звонков на аналоговые телефоны подключенные к портам FXS на Vega 50, если например телефон назначения не найден или занят
(код cause 17). Это полезно, когда есть множество пользователей на приеме входящих звонков, например служба поддержки.

Расширенный план звонков…
-
Перенаправление звонков o
Написание плана звонков для каждого маршрута o
Помещение планов звонков в группы
-
Установка групп с указанными кодами отказа
Для настройки переустановки звонков,
1. Установить группу (на странице планов звонков через web browser). Установить имя, обозначающее, для чего эта группа – например represent_on_busy. Затем установите подходящий код случая (cause code), например 17. Если переустановка требуется для нескольких случаев, они должны быть введены через запятую, например 3,34,41.
2. Для каждого назначения (направления), для которого нужно переустанавливать звонок, напишите план звонков для обработки входящих звонков и посылки их в пункт назначения.
Типично, выражение source будет тем же для каждой записи плана звонков.
3. Настройте каждый план звонков, как член группы.
4. Настройте значения приоритета для каждого плана звонков для каждой записи плана для определения порядка представления.
Например, если шлюз маршрутизирует звонки начиная с префикса 01344 на один из 4-х IP адресов назначения транковых шлюзов, запись плана звонков будет выглядеть следующим образом:
Source = Destination = Group = 1 Cost = 1
IF:04..,TEL:<01344.*> IF:9901,TEL:<1>,TA:Vega_1_IP
Source = Destination = Group = 1 Cost = 2
IF:04..,TEL:<01344.*> IF:9901,TEL:<1>,TA:Vega_2_IP
Source = Destination = Group = 1 Cost = 3
IF:04..,TEL:<01344.*> IF:9901,TEL:<1>,TA:Vega_3_IP
Source = Destination = Group = 1 Cost = 4
IF:04..,TEL:<01344.*> IF:9901,TEL:<1>,TA:Vega_4_IP

Где группа 1 настроена для переустановки звонков по cause code 34.
На этом шлюзе Vega, для нескольких транковых шлюзов, все выражения source одинаковы, в выражениях destination отличаются только IP адреса шлюзов и Cost определяются в порядке перебора шлюзов назначения (1 - первый, 2 - второй ... и т.д.).
Расширенный план звонков…
-
Группа перенаправления звонков
-
Режим перебора o
Линейный o
Циклический o
Случайный
-
Назначение o
Список физических интерфейсов
На диаграмме выше показаны web настройки и план звонков для группового вызова на номер 500 через все 8 портов FXS.
Call Presentation Groups (группы представления звонков) были введены для переназначения звонков на множество телефонных интерфейсов напрямую. Call presentation groups создают виртуальный интерфейс который создан из нескольких физических (телефонных) интерфейсов.
Call Presentation Group - виртуальный интерфейс, который должен быть использован только в выражениях destination (регулярные выражения ‘.’ и ‘[wxy]’ используемые в source выражении для указания множества интерфейсов).
Для активации call presentation group, на странице планов звонков, выберете Call presentation groups. Добавьте новую запись, если требуется и выберете изменения.

Сначала в секции Destinations выберете номера физических интерфейсов из этого виртуального интерфейса. Обратите внимание, что это физические интерфейсы, а не виртуальные и не IP.
Выберете enable для активирования. Будьте уверены, что номер интерфейса уникален.
Режим последовательности определяет как шлюзу Vega следует использовать физические порты:
- linear up
... всегда начинает с первого интерфейса в списке, другой используется в случае не успешного звонка, при совпадении кода проблемы с указанным кодом cause или по time out .
- round robin
... каждый звонок начинается со следующего интерфейса в списке.
- random
... случайный выбор физического интерфейса для старта.
Max destination attempts позволяет использовать количество интерфейсов, меньшее, чем количество определенное в списке Destinations (заметьте, что Vega будет пытаться использовать только интерфейсы из списка destinations, даже если используется Max Destination Attempts больше чем количество интерфейсов в списке Destinations).
Cause = код случая или разделенные запятой коды в списке, которые Vega будет использовать для решения о перенаправлении вызова другому интерфейсу или сброса вызова. Это то же значение кода случая которое используется в группах плана набора.
Destination timeout максимальное время для попытки звонка на любой физический интерфейс.
Destination timeout action указывает, что делать по событию timeout, либо использовать следующий интерфейс, либо повесить трубку.
Для интерфейсов FXS , типовые настройки будут следующими:
-
Destination будут интерфейсы в ‘hunt group’
- cause -
17 (занят конечный абонент)
- destination timeout action - ‘try next interface’
- destination timeout около 20 seconds
Эта конфигурация перенаправляет звонки на другие интерфейсы, если вызов остался без ответв в течении времени ‘destination timeout’ или если телефон занят.
Для Vega 400 и Vega BRI с транковыми интерфейсами типовая настройка будет выглядеть так:
-
Destination будут интерфейсы в ‘group’ для посылки звонков во вне, для шлюза Vega между
PSTN и PBX 0x01 и 0x03 будут в одном CPG и 0x02 и 0x04 будут во втором CPG .
- cause -
34,41 (нет цепи / канал доступен, но временно не исправен)
- destination timeout - ‘hang up’
- destination timeout - около 180 секунд
Эта конфигурация перенаправляет звонки на другие свободные интерфейсы транков в случаях, указанных в case. Если вызов остался без ответа в течение ‘destination timeout’, звонок будет сброшен.

Секция Group на странице плана звонков может быть использована для других целей, также как и переустановка звонков.
Active Times разрешает работу планов звонков в определенные периоды времени:
Active times представлены в формате hhmm-HHMM, где hh часы начала работы, mm минуты начала работы, HH часы окончания рботы и MM минуты окончания работы. План, назначенный в этой группе, будет доступен в этот период времени.
Заметьте, отсутствует поддержка дня недели – если это требуется это должно поддерживаться на proxy или gatekeeper.
Priority
Приоритет используется только для плана звонков, который отправляет вызовы в FXO резервные порты (на шлюзах Vega FXS с 2 FXO).
Резервные порты FXO могут быть использованы для поддержки звонков в местную PSTN а так же для маршрутизации экстренных вызовов (911, 112 и т.д.). Это важно, однако, даже если местный звонок был сделан на FXO интерфейс, когда пришел экстренный вызов, он будет обработан. Это достигнуто ассоциированием плана звонков обработки экстренных вызовов с группой, где установлен план приоритета.
Когда звонок был обработан планом звонков, который ассоциирован с такой группой, если существующий звонок не приоритетен, то Vega сбросит его, и будет сделан приоритетный звонок.

Примечания:
1.
С помощью шлюзов Vega звонки могут быть маршрутизируемы из телефонной сети в VoIP, из VoIP в телефонную сеть и из телефонной в телефонную. Звонки из VoIP в
VoIP не поддерживаются. Если это нужно сделать , сделайте петлю на ISDN или CAS транках.
2.
На аналоговых шлюзах Vega 50, возможен звонок или переадресация между телефонными портами на том же шлюзе Vega, план звонков должен быть написан через LAN интерфейс:
IF:9901,TEL:<1>,TA:
... и второй план звонков используется для маршрутизации вызовов с LAN на телефонный интерфейс назначения (это будет нужно в любом случае для звонков приходящих с другого IP устройства). Стек SIP который дополнительно обрабатывает переадресацию звонков на канале остается только дополнительный сервис, если звонок завернут через LAN – он не остается активным, если звонок завернут через телефонный интерфейс напрямую.
Звонки завернутые таким путем, будут завернуты внутри контроллера LAN, эти звонки не занимают полосу пропускания на LAN.
3. Как много записей плана звонков нужно написать? Типично, 1 запись нужно на телефонный интерфейс на шлюзе Vega (для обработки звонков из VoIP на телефоны) плюс 1 план для IP назначения на LAN (для обработки телефонных звонков в VoIP). Больше записей будет нужно, если различным телефонным портам нужно поддерживать звонки в разных направлениях.

Annex 1. Примеры настроек.
Следующие примеры даны ниже:
1.
Примеры добавления и удаления префиксов
2.
Использование DNS для разрешения единственному плану звонков обрабатывать много IP телефонов с несоизмеримыми IP адресами .
3.
Vega 100 между PSTN и PBX, используя VoIP для доступа к SIP телефонам и транковым шлюзам
4.
Дополнительная цифра 9 для выхода на внешнюю линию
1. Примеры добавления и удаления префиксов
Преобразование 11-и значного номера 01344 78 4xxx в 4-х значный номер 4xxx (из SIP интерфейса в IF:0401)
Source = IF:99..,TEL:0134478<4...> Destination = IF:0401,TEL:<1>
Звонки приходящие на интерфейс 99xx, имеющие номер 01344784 следующие 3 цифры будут обработаны этим планом звонков. Цифра 4 и следующие 3 цифры будут сохранены в store 1.
Совпадение звонков в выражении source будут направлены через интерфейс 0401, перенося телефонный номер, хранящийся в store 1 (цифра 4 + 3 цифры).
Преобразование 4-х значного номера 4xxx в 11-и значный номер добавлением префикса 01344 78
(с SIP интерфейса на IF:0401)
Source = IF:99..,TEL:<4...> Destination = IF:0401,TEL:0134478<1>
Звонки приходящие на интерфейс 99xx, имеющие номер 4 + 3 цифры будут обработаны этим планом. Цифра 4 и следующие 3 цифры будут сохранены в store 1. Совпадающие звонки в выражении source будут направлены через интерфейс 0401, перенося телефонный номер 01344 78 и следующие цифры, хранящиеся в store 1 (цифра 4 + 3 дополнительные цифры).

2. Использование DNS для разрешения единственному плану звонков обрабатывать
много IP телефонов с различными IP адресами .

Где существует множество различных конечных точек с разными IP адресами, нормальный стиль написания плана звонков подразумевает один план звонков для каждой конечной точки, что ограничивает нас 350 конечными точками. Более эффективный метод – с точки зрения обеспечения необходимого количества планов набора – это позволить DNS серверу разрешать IP адреса.
DNS может быть вынесен на хранилище Vega (таблица lan.hosts) или на внешний DNS сервер
(убедитесь, что IP адреса DNS серверов присутствуют на странице LAN settings). Когда Vega ищет
IP адрес по имени, она сначала проверяет lan.hosts, и если не находит совпадений, ищет на внешнем DNS сервере (если IP адреса не 0.0.0.0)

Установленные DNS записи будут:
Name IP
Phone_001 w.x.y.z
Phone_002 a.b.c.d
Phone_nnn g.h.i.j
План звонков будет записан следующим образом:
Source = IF:0401,TEL:<01344784><...>




Destination = IF:9901,TEL:<1><2>,TA:Phone_<2>
Звонки приходящие на интерфейс 0401, которые имеют телефонный номер 01344 784 и следующие
3 цифры, будут обработаны этим планом. Цифры 01344784 сохранены в store 1 а следующие 3 цифры в store 2. Звонки соответствующие выражению source будут направлены через интерфейс
9901, перенося весь телефонный номер (store 1 + store 2). IP адрес для посылки звонка получаем из
DNS по имени ‘Phone_’ + 3 конечные цифры телефонного номера.
3.

Vega 400 между PSTN и PBX, используя VoIP для доступа к 2 SIP телефонам и
транковому шлюзу



Для этой конфигурации, нам нужен один план звонков для посылки вызовов на SIP телефон 8497, один для посылки вызовов на SIP телефон 8498, один для посылки вызовов на направление 01344 xxx xxx и всеобъемлющий план звонков для посылки остальных вызовов на локальную PSTN.
Нужно так же правило для направления звонков из локальной PSTN на PBX.
Source = IF:0401,TEL:<8497>

Destination = IF:9901,TEL:<1>,TA:IP_phone_<1>
Source = IF:0401,TEL:<8498>

Destination = IF:9901,TEL:<1>,TA:IP_phone_<1>
Source = IF:0401,TEL:<01344......>
Destination = IF:9901,TEL:<1>,TA:gateway_01344
Source = IF:0401,TEL:<.*>
Destination = IF:0402,TEL:<1>
Source = IF:0402,TEL:<.*> Destination = IF:0401,TEL:<1>

Если требуется, может быть написано больше правил для обеспечения прямого набора номеров из
PSTN на SIP телефоны (через Vega 400).
4.

Дополнительная цифра 9 для выхода вне
С новыми системами VoIP, нужно обычно набирать 9 (или любую другую цифру) для выхода на внешнюю линию. В офисах, обычно используется 9 для выхода на внешнюю линию, дома можно просто набрать нужный номер.
В новых системах, это однако полезно для разрешения пользователям напрямую набирать внешние телефонные номера, или через префикс, например 9. Это может быть достижимо, используя регулярное выражение ‘?’. Например, рассмотрим следующий план звонков:
Source = IF:99..,TEL:9?<.*> Destination = IF:1001,TEL:<1>
Вызовы поступающие на SIP интерфейс могут иметь в номере дополнительную цифру 9 и далее любой номер телефона. Звонок будет послан с виртуального интерфейса 1001 (определяется Call
Presentation Group), и телефонный номер, который будет набран, будет номером, принятым с SIP за исключением ведущей цифры 9.
Будьте осторожны в отношении экстренных номеров, которые начинаются с той же цифры, как и цифра выхода на внешнюю линию. Если это так, удостоверьтесь, что явные правила для экстренных вызовов написаны. Например, для США - 911 написан в правиле:
Source = IF:99..,TEL:<911> Destination = IF:1001,TEL:<1>
Source = IF:99..,TEL:9<911> Destination = IF:1001,TEL:<1>

Используйте show paths чтобы удостовериться что эти 2 ‘emergency’ правила имеют приоритет над основными правилами выше.
Annex 2. Расширенные регулярные выражения.
Регулярные выражения шлюзов поддерживают группы, они расширяют возможности шлза Vega в использовании плана звонков одной записи для обработки множества различных входящих вызовов. Группы позволяют, например, чтобы не последовательные диапазоны номеров обрабатывались одним правилом плана звонков.
Например, для обработки вызовов из региональных кодов 505, 917 и 614, могут быть написаны 3 плана звонков:
Source = IF:0402,TEL:<505><.*> Destination = IF:9901,TEL:<1><2>
Source = IF:0402,TEL:<917><.*> Destination = IF:9901,TEL:<1><2>
Source = IF:0402,TEL:<614><.*> Destination = IF:9901,TEL:<1><2>
Альтернатива - использование единого плана звонков и группы:

Source = IF:0402,TEL:<(505)|(917)|(614)><.*>
Destination = IF:9901,TEL:<1><2>

Annex 3. Расширенные TOKEN.

Низкоуровневый ISDN номерной план, типы номеров, представление и показ номеров на экране.
План звонков Vega так же поддерживает некоторые дополнительные Token для низкоуровневого управления ISDN номерами вызывающего и вызываемого абонентов. Эти значения могут быть использованы только в записи destination, и подходят только к Vega 400 и Vega BRI:
PLAN: -
Указывает ‘Numbering Plan Information’ для набранного номера (TEL:)
PLANC: -
Указывает ‘Numbering Plan Information’ для звонящего номера (TELC:)
TYPE: -
‘Type Of Number’ для набранного номера (TEL:)
TYPEC: -
‘Type Of Number’ для звонящего номера (TELC:)
PRESC: -
Может ли вызывающий номер (TELC:) быть предоставлен абоненту
SCRNC: - может ли звонящий абонент (TELC:) быть показан на экране
Приемлемы следующие значения:
PLAN: & PLANC: isdn_telephony, data, telex, national, private, unknown
TYPE: & TYPEC: national, international, network_specific, subscriber, abbreviated, unknown
PRESC: allowed, not_available, restricted
SCRNC: failed (не валидно для ETSI), not_screened, passed, network
Расширенное поле SIP From: поддерживаются поля
From: Steve Hight ;tag=0082-
00000982-05cd
В этом примере
• Display name: Steve Hight
• callerID: +441344784917;pn=4917
Когда принят звонок с этим заголовком From:, Vega будет распространять TOKEN следующим образом:
• NAMEC: будет содержать все цифры, буквы и любые ‘+’ из части callerID
• TELC: содержит все ведущие цифры и ‘+’ из части callerID из URI
• DISP: содержит имя для индикации
Для примера выше:
• NAMEC: = +441344784917pn4917
• TELC: = +441344784917
• DISP: = Steve Hight

Document Outline

  • Введение в план
  • Vega 50 6x4 FXS, FXO и BRI & Vega 400
  • Введение в план звонков.
  • Для входящих звонков на телефонный интерфейс:
  • IF: определяет приемлемый номер интерфейса для данного плана звонков
  • Для исходящих VoIP звонков:
  • Для входящих VoIP звонков
  • Для исходящих звонков на телефонный интерфейс:
  • IF: ID телефонного интерфейса
  • Source = IF:0401,TEL:01344784900
  • Destination = F:9901,TEL:01344784900,TA:w.x.y.z
  • Source = IF:0401,TEL:0134478490.
  • Source = IF:0401,TEL:<01344784[89]..>
  • Destination = IF:9901,TEL:<1>,TA:w.x.y.z
  • Source = IF:0401,TEL:<013447849..>
  • Destination = “IF:9901,TEL:<1>,TA:w.x.y.z,DISP:External Call”
  • С планами звонков
  • IF:01..,TEL:<1234>
  • IF:01..,TEL:<123.>
  • IF:01..,TEL:<.*>
  • Try IF:0103,TEL:1234
  • Priority
  • IF:9901,TEL:<1>,TA:
  • Source = IF:99..,TEL:0134478<4...> Destination = IF:0401,TEL:<1>
  • Source = IF:99..,TEL:<4...> Destination = IF:0401,TEL:0134478<1>
  • Source = IF:0401,TEL:<01344784><...>
  • Destination = IF:9901,TEL:<1><2>,TA:Phone_<2>
  • PLAN: & PLANC: isdn_telephony, data, telex, national, private, unknown
  • PRESC: allowed, not_available, restricted
  • Расширенное поле SIP From: поддерживаются поля
  • 00000982-05cd


Поделитесь с Вашими друзьями:


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал