Opened 8 years ago
Closed 8 years ago
#214 closed задача (готово)
Маршрутизация вызовов
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 1 очередь |
| Component: | VE-01 | Keywords: | |
| Cc: |
Description
Уже, как минимум, 2 пользователя и 1 Артём просили о реализации данной функции в плате VE.
Зачем: пользователей устраивает внутренняя коммутация абонентов средствами шлюза, но они хотели бы, чтобы абоненты одного шлюза могли вызывать абонентов другого шлюза, но при этом внутренняя коммутация абонентов шлюза была независима от состояния и доступности другого шлюза.
( Сейчас, в качестве временного решения для маршрутизации вызовов они используют функцию "Групповой вызов".)
Артём в качестве аргумента "нужности" приводит примеры реализации в подобной аппаратуре других производителей.
На картинке кусочек из инструкции настройки Маршрутизации вызовов в Voip шлюзе одного "китайского" производителя.
Attachments (1)
Change History (10)
by , 8 years ago
follow-up: 3 comment:2 by , 8 years ago
Правильно ли я понял?
Сценарий на примере:
- Допустим, я хочу со своей VE-01 отправлять все вызовы с префиксом <9> на 192.168.0.111 .
- Задаю в настройках дефлектора
/^9(.*)$/\1@192.168.0.111 - Вызываю на своём шлюзе 9123,
- ua посылает инвайт
- uri из инвайта матчится и дефлектор даёт ответ 302, поместив в поле контакт 123@192.168.0.111"
- ua получив 302, посылает инвайт на 192.168.0.111
comment:5 by , 8 years ago
Я совсем забыл, что есть другое, альтернативное решение.
Начиная с прошивки ревизии 22 в плате VE-01 есть прокси-сервер, в качестве которого используется repro. У этого repro уже есть некая таблица маршрутизации вызовов, реализованная в виде таблицы в базе данных. Подробнее можно посмотреть здесь.
С технологической точки зрения это решение лучше, так как это реальная, настоящая маршрутизация - прокси-сервер форвардит исходный запрос юзер-агента согласно таблице, в результате он (прокси) остается в курсе последующего диалога - был ли вызов отвечен, когда завершился. Соответственно, будут генерироваться правильные CDR и т.п...
Чтобы получить доступ к веб-интерфейсу прокси-сервера надо в файле /etc/users.txt раскомментировать строку admin:repro:587c67fddee5b46eef47c36d93016965 и перезапустить плату. Пароль будет тоже admin. HTTP-сервер слушает порт 80.
follow-up: 8 comment:7 by , 8 years ago
альтернативное решение.
Да, работает.
Для полного счастья нужно добавить настройку маршрутов в нашу веб-морду, аналогично настройке sip-пользователей.
comment:8 by , 8 years ago
Replying to san:
Для полного счастья нужно добавить настройку маршрутов в нашу веб-морду,
У меня на Нижнем cамурае сделано управление таблицей маршрутов через веб-морду.
Посмотри, пожалуйста, и если все OK - "узаконим" эту фичу.
Заодно подумай, как можно переформулировать названия полей в веб-форме маршрута - как сейчас мне не нравится...
Replying to san:
Не могу не заметить, что с точки зрения формальной логики реализация данной функции в подобной аппаратуре не является аргументом аргументом ее "нужности".
Теперь по сути. Есть такая штука, которую я условно назвал "дефлектор" (DEFLECTOR). Это такое специальное канальное окончание, которое на любой INVITE, матчащийся с его регулярным выражением вызова, дает ответ 302, помещая в Contact результат замены выражения (предполагается, что регулярное выражение с заменой). Причем сами платы такие окончания поддерживают уже очень давно, просто в веб-интерфейсе SW-01 их поддержки. Так вот, устроит ли использование этого дефлектора?