tolik
Ответы в темах
-
АвторСообщения
-
20.04.2015 в 20:52 #8397tolikУчастник
У меня настроена переадресация с westcall на sipnet
Скажите, пожалуйста, насколько стабильно-регулярно к Вам проходят вызовы, переадресуемые на Ваш заведомо незанятый текущей активностью номер sipnet?
В контексте этой темы: https://talk37.ru/topic/переадресация-вызова-с-инициализаци/
Вы используете Переадресацию или Передачу вызова?“Передача вызова” делает несколько иначе, чем “Переадресация”. В сервисе talk37.ru “переадресация” реально нечего не переадресует, а просто делает новый вызов и соединяет линии (мост). “Передача вызова” сделана скорее как тестовая и мало кем используется, она делает Transfer. Цитата: если попытка переадресации вызова происходит до установления соединения, то вызывающему абоненту будет возвращено SIP сообщение “302 Redirect”. Это дает возможность использовать SIP сообщение, предназначенное для переадресации (с кодом 302), для распределения нагрузки по обработке SIP вызовов на несколько серверов.
14.04.2015 в 10:34 #8387tolikУчастникDemon, Вам большое спасибо, к Вам и Вашему сервису в любом случае никаких претензий.
Пока эксперименты не все необходимые проведены – как выше написал: неспешно.
Учитывая, что разными способами через LV – периодически днём наблюдается та же проблемка, дело вероятно в Sipnet.
Также через Pbxes простой переадресацией (передачу вызова из одной сети с инициализацией транзитного вызова в другую там не придумал пока как сделать) проверял.14.04.2015 в 09:11 #8385tolikУчастникOffTop/ Мде. Ни слова по сути решения поставленной технической задачи, зато пост “дартаньяна” в заборных традициях.
11.04.2015 в 13:59 #8381tolikУчастникЭкспериментирую/настраиваю параллельно 2 решения несвязанно друг с другом. Изучаю: где стабильнее получается консолидировать входящие и принимать на Sipnet. Второе решение = LV, там раньше начал. В логах talk37 пока всего поля экспериментов может не быть – часть наблюдений с LV.
Отключаю передачу АОН. Соответственно, номер на Сипнет приходит Сипнетовский. Но как-то Сипнет в часы дневных пиковых нагрузок просекает и учитывает приоритезацизцию (предположение): если вызов был непростой, а каким-то из способов инициирован посредством другого транзитного SIP-сервиса (хоть просто набор, хоть переадресация/передача вызова и тп) – днём периодически возвращается 486 или 408 код. Возможно, (предположение) что-то где-то кто-то с кем-то несовсем по SIP-стандартам в какие-то моменты начинает взаимодействовать в части телефонной сигнализации: количество ОК-ев и периодичность и тп.А если простой вызов внутри Сипнет с устройства на устройство без дополнительных звеньев вызова (без облачных АТС), то проблем нет, как не замечено также проблем при звонках с Сипнет на ТфОП.
Эксперименты проводятся неспешно несколько дней и по мере наличия времени.11.04.2015 в 10:12 #8379tolikУчастникСпасибо. Идею понял.
Потестирую. Пока постоянного прохождения звонков внутри Сипнет через эту и другую облачную АТС так и не добился: как-то влияет почему-то, видимо, дневная нагрузка. Хотя при этом внутри Сипнет при вызове напрямую с необлачного устройства – проблем нет.03.04.2015 в 03:10 #8342tolikУчастникЗабыл добавить к пояснениям выше.
Как-то странно.. пользователи сипнета звонят на номер талк37, а оттуда обратно в сипнет…
Не только пользователи сипнета и в первую очередь не они, и звонят не только на номер талк37, но и на другую прицепленную к талк37 несипнетовскую учётную запись другого провайдера.
А вызовы эти я буду принимать у себя на сипнет, и по вышеназванной причине надо, чтобы они последней милей пришли от сипнет.02.04.2015 в 22:10 #8339tolikУчастникSipnet у меня близко получается за счёт пиринга, звонить с него легче мне лично напрямую, а не через посреднический сервер. Схема то есть стабильнее.
По железу у меня лимит по FXS-портам, поэтому для домашних предпочитаю использовать Ваш облачный сервис, дозваниваясь на него запрограммированной клавишей быстрого доступа, а с другой стороны получать адресованные мне на него входящие направленным мне звонком на Sipnet.
Ни в коем случае не уговариваю остальных так делать и не умАляю достоинств talk37.
Пользователи будут мне звонить в основном не юзеры Sipnet, но ценю в первую очередь необходимость стабильности моих исходящих Sipnet не через talk37. От себя напрямую это легче контролировать.02.04.2015 в 21:27 #8334tolikУчастникНу и голосовое приветствие IVR как-то надо иметь возможность отключать.
Похоже, что лучше доп Опцию для всего этого, а не в рамках существующего Донабора.02.04.2015 в 20:56 #8333tolikУчастникТо есть потребуются разные DialPlan’ы для разных действий – во всяком случае если это реализовывать в рамках 1 учётной записи talk37. Для некоторых входящих – на IVR потребуется свой хитрый с пустым набором по IVR и вызовом c внешней учётной записи пользователя на заранее запрограммированный номер.
Как-то пока других идей нет.02.04.2015 в 20:36 #8332tolikУчастникЧасть решения вижу около опции Донабор: при входящем звонке нужно инициализировать Донабор от имени прицепленной к talk37 внешней учётной записи Sipnet, но обязательным условием нужно получение выхода на программирование юзерского DialPlan’a для Донабора (а выхода этого сейчас не вижу), чтобы автоматически при Донаборе “ничего” посредством DialPlan’а (какой-нибудь символ обозначения этого “ничего” нужно запрограммировать) срабатывало правило вызова на адрес Sipnet от имени прицепленной к talk37 внешней учётной записи Sipnet.
02.04.2015 в 20:10 #8331tolikУчастникСлово “окончательное” – лишнее написано.
02.04.2015 в 17:31 #8328tolikУчастникСпасибо за отклик. С простыми переадресациями разобрался.
Допустим, переадресация/передача вызова поступившего звонка на неподцепленную к talk37 учётку адреса Sipnet. Поскольку поступил звонок не из Sipnet, то в половине случаев из-за внутренних проблем Sipnet получаем отлуп.
Если подцепляем в цепочку к talk37 транзитную внешнюю учётную запись Sipnet, чтобы сначала переадресовать на неё, а потом с неё на адрес конечного назначения Sipnet, то по идее сначала при первой переадресации звонка на транзитную учётку идёт обращения на Sipnet, чтобы как минимум узнать: есть ли и где прошедшая регистрацию активная учётная запись Sipnet онлайн – под одной учёткой же может быть несколько регистраций в разных местах, и в зависимости от программного обеспечения оператора при звонке на его учётку звонить будет последнее зарегистрированное устройство или все сразу. Поскольку к транзитной учётке Sipnet идёт обращение к Sipnet сначала, а не через внутреннюю маршрутизацию talk37, то по идее в порядка половины случаев получаем отлуп.
То есть при переадресации / передаче вызова нужна проверка: если переадресуется на внешнюю учётную запись Sipnet, подцепленную к talk37.ru, а от неё на другой внешний адрес (Sipnet), то нужна принудительная внутренняя маршрутизация без предварительного обращения к Sipnet: чтобы по пришедшей команде транзитная учётная запись Sipnet сама позвонила на конечную учётку Sipnet, и при успешном прохождении вызова и установлении конечного этапа соединения Sipnet-Sipnet чтобы произошло окончательное транзитное соединение через исключительно внутренний трафик talk37 без инициализирующих обращений к серверу Sipnet.30.03.2015 в 23:50 #8318tolikУчастникПрямой необходимости в конкретную минуту у меня нет и особо не планируется, но, как Вы правильно заметили про Мультифон, в холдинге Мегафон обычно донабор понимается только Inband. Звоня на их городские с других операторов сталкивался.
30.03.2015 в 23:21 #8316tolikУчастник3CX – позволяет одновременно 3 метода.
Поэтому в итоге выставил там на всякий случай 2: AVTO=RFC2833 и Inband на всякий случай.30.03.2015 в 22:58 #8314tolikУчастникЕсли использовать Info метод вкупе с другим(и) одновременно, то задваивается набор. Решетка как признак окончания и выход на произнесение набранного.
30.03.2015 в 12:38 #8296tolikУчастникПытался несколько часов назад (сейчас не имею возможности) тестировать пропускание в голосе разные стандарты через номер 0203. Как-то мне показалось, что не всё и не всегда там распознаётся.
* или # там не может служить символом отмены набранного для распознавания?30.03.2015 в 03:51 #8286tolikУчастникОстаётся нерешенным вопрос: Как для целей IVR-talk37-Донабора номера добавить в белый список SIP-адрес, инициирующий звонок, чтобы кто попало не получал этот IVR-доступ через звонок именно мне? Попробовал добавить в белый список SIP-адрес через “Регистрацию собственных контактов”, но там только как e-mail или ТфОП-номер можно.
И пока доступ на IVR для всех входящих – не включить следующее условие: переадресацию всех входящих кроме добавленного (пока так в итоге и недобавленного) в белый список SIP-номера.
То есть нужно запрограммировать условие: если входящий SIP из белого списка, то IVR (Донабор), а все прочие иметь возможность переадресовать при включенной опции переадресации и при отсутствии talk37-регистрации.
Непонятно: зачем опция “Передача вызова” в “Настройке правил обработки входящих звонков”, если там же есть та же и шире по функционалу “Переадресация”? -
АвторСообщения