Подключение внешнего сервиса в качестве клиента
- В этой теме 42 ответа, 5 участников, последнее обновление 9 лет, 4 месяца назад сделано
.
-
Сообщения
-
Вот у меня как раз Астериск подключён как провайдер, и как раз может принимать CID.
Теперь понял.
Т.е. у вас для каждой линии свой логин на talk37? И у каждой свой четырёхзначный номер, выданный сервисом?
Да, раньше было именно так. Но потом Дмитрий произвел изменения, и дополнительные учетные записи я смог удалить. Номер у всех общий, 2067 четырехзначный.
Как так я сделал, сходу вспомнить не могу, но если я не ошибаюсь у меня каждая линия Гигасет 610 подключена как отдельное устройство, по терминологии здесь https://talk37.ru/helpme/%D0%BE%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B5%D0%BA/%D1%83%D1%87%D0%B5%D1%82%D0%BD%D1%8B%D0%B5-%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B8
Можно создать дополнительное устройство, присвоить ему внутренний номер и указать, какое CID это устройство будет передавать.
Но, устройству присваивается трехзначное число, вн. номер.Как внешние провайдеры у меня подключены провайдеры. Так же подключен Либерал. Причем подключен и как устройство и как провайдер. Но сейчас Либерал не работает к сожалению.
Можно создать дополнительное устройство, присвоить ему внутренний номер и указать, какое CID это устройство будет передавать.
В настройках учётных записей я такого не нашёл (не считая двух вариантов, общих для всего моего аккаунта). А CID, заданный на самом устройстве, игнорируется.
Но, устройству присваивается трехзначное число, вн. номер.
Вот он-то как раз и передаётся без вариантов, причём только при внутренних звонках. А “наружу” идёт один из трёх вариантов “глобального” CID, определяющегося опять же только аккаунтом.
Так же подключен Либерал. Причем подключен и как устройство и как провайдер. Но сейчас Либерал не работает к сожалению.
С Либералом всё было хорошо, кроме того, что при большинстве звонков не было отбоя и периодически отпадала регистрация линий из-под двойного NAT…
Извиняюсь что долго не отвечаю. В выходные стараюсь больше времени уделять семье.
Я всё читаю на смартфоне, но не всегда отвечаю 🙂На внешние шлюзы передаются не всегда один и тот же CID, а именно “определяющий устройством”, т.е. тот, который указан как “исходящий” у устройства. Но это не “внутренний номер”, а номер сервиса (четырёхзначный). Потому что, как тут правильно заметили, звонки в шлюзы и внешние учётные записи считаются как “внешние”. Внутренние звонки сейчас используются только при звонках между устройствами.
В другой ветке Вы писали что вряд ли стоит менять сервис только для Ваших нужд. Но… всё что есть в сервисе и реализовано как удовлетворение чьих-то нужд 🙂 Иного у меня и нет 🙂
Но… реализация не всегда происходит в том виде, в котором запрашивается… Я стараюсь “встроить” эти требования в “архитектуру” и идеологию сервиса. Но “потребности” должны выполняться.Правильно ли я понимаю что основная задача: идентификация устройства при звонке через шлюз? Тогда надо искать решение..
Но зачем такая задача? В шлюзе прописана логика? Почему вся эта логика не находится в рамках сервиса? Может быть было бы гораздо проще…1. Если устройств будет не сильно много, то можно надобавлять номеров сервиса и настроить на каждое устройств свой собственный номер сервиса. Тогда будет идентификация
2. Если бы был свой домен… то можно было бы и номера добавлять совсем произвольные, а не те, которые выдаёт сервис
кстати.. номерами CID могут быть не только номера сервиса, но и сотовые номера… и городские.@demon спасибо, что находите время/возможность как-то на всё это реагировать 🙂
Попробую более связно описать задачу, т.к. из отдельных кусков возможно неясно, что и зачем хочется реализовать. Ни в коем случае не предлагаю это рассматривать, как какие-то требования по изменению сервиса, просто информация “as is”.
Итак, есть собственная тел. сеть, обслуживающая в основном членов семьи. Построена на базе системы Asterisk 1.4, подключение к которой в основном происходит напрямую по локальной сети или через VPN. Собственные номера сети – четырёхзначные. Назовём это “внутренним сегментом” сети.
Всё бы замечательно, но часто бывает потребность получения доступа к этой сети с точек, где нет возможности развернуть VPN – с мобильного, с дачи, из офиса. Для этого хочется организовать т.н. “внешний сегмент” сети (с использованием Вашего замечательного сервиса). Технические условия для этого сегмента очень простые:
– четырёхзначная нумерация в формате 5ххх, последние цифры могут быть любые;
– полная прозрачность: свободное прохождение звонков и определяемость номеров как внутри сегмента, так и между сегментами (дабы абонент не должен был задумываться, в каком сегменте он в данный момент находится и куда звонит);
– крайне желательна поддержка кодека g729.Данная схема в разное время и без каких-либо сложностей была успешно реализована с использованием сервисов pbxes.org и liberalvoip.net. К сожалению, от первого по ряду причин пришлось отказаться, а второй сейчас переживает не лучшие времена. Поэтому и ищется альтернатива.
А можно поподробнее про домены? Если речь про обычный домен (для сайта, например), то их есть в количестве N штук, да и можно новых организовать. Я только не понял, как их с SIP-сервисом увязать и какое они будут иметь отношение к нумерации линий.
А Вы уже добавили свой домен.
к сожалению, сейчас только я могу добавлять контакты (номера или логины) с других доменов (внутренние механизмы есть, а на сайте пока не поддержано).
Если напишите номера или логины Вашего домена (можно через личные сообщения), то я их добавлю.. и Вы сможете использовать на устройствах, в правилах…Ещё маленький вопросик: как в шаблоне номеров (для правил) указать определённую длину номера? Например, 6NNN – четырёхзначные, начинающиеся на 6.
Нужно использовать регулярное выражение. Проверить его работу можно здесь https://regex101.com/
Если я не ошибаюсь, регулярное выражение должно быть вида
/^6(\d{3})$/@Dominique, под правило “%” должны попадать любые звонки.
В сервисе используется “всего” два формата шаблонов для номеров и адресатов:
а) простой: через “%”
б) сложный: через регулярные выражения
делать третий формат.. а нужно ли? 98% случаев хватает пункта “а”. А в остальных случаях пользователи либо сами могут разобраться, либо спрашивают и получают ответ.
Формат циски заточен исключительно на номерные звонки. А сип протокол (да и не только он) куда богаче…Почему сразу циски? Астериск ведь тоже использует нечто подобное для диалпланов, я думал, что это де-факто стандарт. В любом случае шаблон 1ХХХ куда понятнее и читабельнее, чем /^1\d{3})$/ (кстати, спасибо Sayone, оно работает :)). А про эти регулярные выражения я толком и не нашёл, как они формируются, хотя бы ссылочка бы была.
Номерные звонки – разумеется не догма, но пока что являются как ни крути основными, например те же телефоны гигасет просто не позволяют звонить на неномерные SIP ID. Да и реальная телефонная сеть ещё нескоро перейдёт на буковки в телефонных номерах…
По регулярным выражениям ещё есть пара ссылок. В принципе по ним разобрался, правда не сразу. Может кому пригодятся ссылки
По ссылке открывается что то совсем другое. Видимо домен больше не работает.
А редактировать сообщения вроде нельзя тут..@Dominique, не смотря на все терминологические споры… удалось ли реализовать передачу CID на свой Asterisk?
В обратную сторону, надеюсь, тоже?@Dominique, можно реализовать и 1XXX. Вот только как этот шаблон отличить от не шаблона?
Регулярное выражение я отличаю через символ “/” в начале и конце. Этот символ запрещён в SIP адресации.
А как мне отличить шаблоны типа XXX, ZZZZ? Есть предложения?P.S. Редактировать сообщение можно, но только в течении 10 минут после публикации. Этого времени мало? А сколько нужно?
1) Звонки ходят и CID передаётся в обе стороны, спасибо – всё замечательно! Есть только проблема со звонками внутри сервиса, о которой я создал отдельную тему.
2) Насколько я понимаю, в том же Астериске для отличия шаблона от не_шаблона используется префикс _. Т.е. ХХХХ – это номер “ХХХХ”, а “_ХХХХ” – это шаблон из 4 знаков.
3) Да пусть хотя бы 10 минут, я просто не вижу, как это сделать? У сообщения есть только ссылки QUOTE и REPLY.У меня аналогичная ситуация – не расскажете как настроить подключение и правила входящих-исходящих для внешней PBX ?
@multigems, я вижу что Вы добавили уже и внешние учётные записи и некоторые простые правила входящих и исходящих.
Так в чём всё же вопрос? Лучше конкретные вопросы…Собственно вопрос самый базовый – как правильно настроить правила (вх-исх) чтобы внешний звонок (сейчас подключен Дисконт телеком) уходил на внешний сервис ? А исходящие от SIP – клиентов, подключенных к Вашему сервису, уходили через публичные номера и в случае невозможности, через Дисконт-телеком…
Спасибо1. Часть настроек Вы уже сделали, но странно. Для “сквозного прохождения” надо во входящих сделать переадресацию на номер от имени устройства. А в исходящих сделать правило, в котором на этот номер или на это устройство указать направление, в котором нужная учётная запись (или не одна).
Вы же, почему-то, указали переадресацию на имя другой вашей учётной записи.2. Всё так же делаем правила исходящих по нужным критериям (устройства?). А в направлении указываем действия:
– приоритет 10, включить направление “Все публичные”
– приоритет 20, Ваши учётные записиЯ смог помочь?
Спасибо, что откликнулись… Но у меня не работает “сквозное прохождение” по описанию как Вы указали… Видимо потому что я “ненастоящий сварщик” (С)
Попробуйте меня поправить, если не сложно, в чем ошибка.
1. Во входящих создаю действие Переадресация srv_d17733 (входящий транк с городским номером на кот звонят) от имени устройства multigems
2. Во входящих создаю правило обработки входящих звонков – выбираю устройство srv_d17733 Выполнить набор действий п.1
3. В исходящих создаю направление srv_d17726(транк внешняя АТС-talk37)
4. В исходящих создаю правило устроиство multigems маршрутизировать на направление п.3
Иии не работает…Исходящие почему то тоже не хотят выходить – “no route to destination” через моего оператора – видимо какую то настройку надо… А через Ваши публичные работает, но качество раз на раз не приходится…
- Для ответа в этой теме необходимо авторизоваться.