tolik

 

Ответы в темах

Просмотр 17 сообщений - с 1 по 17 (из 17 всего)
  • Автор
    Сообщения
  • #8397
    tolik
    Участник

    У меня настроена переадресация с westcall на sipnet

    Скажите, пожалуйста, насколько стабильно-регулярно к Вам проходят вызовы, переадресуемые на Ваш заведомо незанятый текущей активностью номер sipnet?
    В контексте этой темы: https://talk37.ru/topic/переадресация-вызова-с-инициализаци/
    Вы используете Переадресацию или Передачу вызова?

    “Передача вызова” делает несколько иначе, чем “Переадресация”. В сервисе talk37.ru “переадресация” реально нечего не переадресует, а просто делает новый вызов и соединяет линии (мост). “Передача вызова” сделана скорее как тестовая и мало кем используется, она делает Transfer. Цитата: если попытка переадресации вызова происходит до установления соединения, то вызывающему абоненту будет возвращено SIP сообщение “302 Redirect”. Это дает возможность использовать SIP сообщение, предназначенное для переадресации (с кодом 302), для распределения нагрузки по обработке SIP вызовов на несколько серверов.

    #8387
    tolik
    Участник

    Demon, Вам большое спасибо, к Вам и Вашему сервису в любом случае никаких претензий.
    Пока эксперименты не все необходимые проведены – как выше написал: неспешно.
    Учитывая, что разными способами через LV – периодически днём наблюдается та же проблемка, дело вероятно в Sipnet.
    Также через Pbxes простой переадресацией (передачу вызова из одной сети с инициализацией транзитного вызова в другую там не придумал пока как сделать) проверял.

    #8385
    tolik
    Участник

    OffTop/ Мде. Ни слова по сути решения поставленной технической задачи, зато пост “дартаньяна” в заборных традициях.

    #8381
    tolik
    Участник

    Экспериментирую/настраиваю параллельно 2 решения несвязанно друг с другом. Изучаю: где стабильнее получается консолидировать входящие и принимать на Sipnet. Второе решение = LV, там раньше начал. В логах talk37 пока всего поля экспериментов может не быть – часть наблюдений с LV.
    Отключаю передачу АОН. Соответственно, номер на Сипнет приходит Сипнетовский. Но как-то Сипнет в часы дневных пиковых нагрузок просекает и учитывает приоритезацизцию (предположение): если вызов был непростой, а каким-то из способов инициирован посредством другого транзитного SIP-сервиса (хоть просто набор, хоть переадресация/передача вызова и тп) – днём периодически возвращается 486 или 408 код. Возможно, (предположение) что-то где-то кто-то с кем-то несовсем по SIP-стандартам в какие-то моменты начинает взаимодействовать в части телефонной сигнализации: количество ОК-ев и периодичность и тп.

    А если простой вызов внутри Сипнет с устройства на устройство без дополнительных звеньев вызова (без облачных АТС), то проблем нет, как не замечено также проблем при звонках с Сипнет на ТфОП.
    Эксперименты проводятся неспешно несколько дней и по мере наличия времени.

    #8379
    tolik
    Участник

    Спасибо. Идею понял.
    Потестирую. Пока постоянного прохождения звонков внутри Сипнет через эту и другую облачную АТС так и не добился: как-то влияет почему-то, видимо, дневная нагрузка. Хотя при этом внутри Сипнет при вызове напрямую с необлачного устройства – проблем нет.

    #8342
    tolik
    Участник

    Забыл добавить к пояснениям выше.

    Как-то странно.. пользователи сипнета звонят на номер талк37, а оттуда обратно в сипнет…

    Не только пользователи сипнета и в первую очередь не они, и звонят не только на номер талк37, но и на другую прицепленную к талк37 несипнетовскую учётную запись другого провайдера.
    А вызовы эти я буду принимать у себя на сипнет, и по вышеназванной причине надо, чтобы они последней милей пришли от сипнет.

    #8339
    tolik
    Участник

    Sipnet у меня близко получается за счёт пиринга, звонить с него легче мне лично напрямую, а не через посреднический сервер. Схема то есть стабильнее.
    По железу у меня лимит по FXS-портам, поэтому для домашних предпочитаю использовать Ваш облачный сервис, дозваниваясь на него запрограммированной клавишей быстрого доступа, а с другой стороны получать адресованные мне на него входящие направленным мне звонком на Sipnet.
    Ни в коем случае не уговариваю остальных так делать и не умАляю достоинств talk37.
    Пользователи будут мне звонить в основном не юзеры Sipnet, но ценю в первую очередь необходимость стабильности моих исходящих Sipnet не через talk37. От себя напрямую это легче контролировать.

    #8334
    tolik
    Участник

    Ну и голосовое приветствие IVR как-то надо иметь возможность отключать.
    Похоже, что лучше доп Опцию для всего этого, а не в рамках существующего Донабора.

    #8333
    tolik
    Участник

    То есть потребуются разные DialPlan’ы для разных действий – во всяком случае если это реализовывать в рамках 1 учётной записи talk37. Для некоторых входящих – на IVR потребуется свой хитрый с пустым набором по IVR и вызовом c внешней учётной записи пользователя на заранее запрограммированный номер.
    Как-то пока других идей нет.

    #8332
    tolik
    Участник

    Часть решения вижу около опции Донабор: при входящем звонке нужно инициализировать Донабор от имени прицепленной к talk37 внешней учётной записи Sipnet, но обязательным условием нужно получение выхода на программирование юзерского DialPlan’a для Донабора (а выхода этого сейчас не вижу), чтобы автоматически при Донаборе “ничего” посредством DialPlan’а (какой-нибудь символ обозначения этого “ничего” нужно запрограммировать) срабатывало правило вызова на адрес Sipnet от имени прицепленной к talk37 внешней учётной записи Sipnet.

    #8331
    tolik
    Участник

    Слово “окончательное” – лишнее написано.

    #8328
    tolik
    Участник

    Спасибо за отклик. С простыми переадресациями разобрался.
    Допустим, переадресация/передача вызова поступившего звонка на неподцепленную к talk37 учётку адреса Sipnet. Поскольку поступил звонок не из Sipnet, то в половине случаев из-за внутренних проблем Sipnet получаем отлуп.
    Если подцепляем в цепочку к talk37 транзитную внешнюю учётную запись Sipnet, чтобы сначала переадресовать на неё, а потом с неё на адрес конечного назначения Sipnet, то по идее сначала при первой переадресации звонка на транзитную учётку идёт обращения на Sipnet, чтобы как минимум узнать: есть ли и где прошедшая регистрацию активная учётная запись Sipnet онлайн – под одной учёткой же может быть несколько регистраций в разных местах, и в зависимости от программного обеспечения оператора при звонке на его учётку звонить будет последнее зарегистрированное устройство или все сразу. Поскольку к транзитной учётке Sipnet идёт обращение к Sipnet сначала, а не через внутреннюю маршрутизацию talk37, то по идее в порядка половины случаев получаем отлуп.
    То есть при переадресации / передаче вызова нужна проверка: если переадресуется на внешнюю учётную запись Sipnet, подцепленную к talk37.ru, а от неё на другой внешний адрес (Sipnet), то нужна принудительная внутренняя маршрутизация без предварительного обращения к Sipnet: чтобы по пришедшей команде транзитная учётная запись Sipnet сама позвонила на конечную учётку Sipnet, и при успешном прохождении вызова и установлении конечного этапа соединения Sipnet-Sipnet чтобы произошло окончательное транзитное соединение через исключительно внутренний трафик talk37 без инициализирующих обращений к серверу Sipnet.

    #8318
    tolik
    Участник

    Прямой необходимости в конкретную минуту у меня нет и особо не планируется, но, как Вы правильно заметили про Мультифон, в холдинге Мегафон обычно донабор понимается только Inband. Звоня на их городские с других операторов сталкивался.

    #8316
    tolik
    Участник

    3CX – позволяет одновременно 3 метода.
    Поэтому в итоге выставил там на всякий случай 2: AVTO=RFC2833 и Inband на всякий случай.

    #8314
    tolik
    Участник

    Если использовать Info метод вкупе с другим(и) одновременно, то задваивается набор. Решетка как признак окончания и выход на произнесение набранного.

    #8296
    tolik
    Участник

    Пытался несколько часов назад (сейчас не имею возможности) тестировать пропускание в голосе разные стандарты через номер 0203. Как-то мне показалось, что не всё и не всегда там распознаётся.
    * или # там не может служить символом отмены набранного для распознавания?

    #8286
    tolik
    Участник

    Остаётся нерешенным вопрос: Как для целей IVR-talk37-Донабора номера добавить в белый список SIP-адрес, инициирующий звонок, чтобы кто попало не получал этот IVR-доступ через звонок именно мне? Попробовал добавить в белый список SIP-адрес через “Регистрацию собственных контактов”, но там только как e-mail или ТфОП-номер можно.
    И пока доступ на IVR для всех входящих – не включить следующее условие: переадресацию всех входящих кроме добавленного (пока так в итоге и недобавленного) в белый список SIP-номера.
    То есть нужно запрограммировать условие: если входящий SIP из белого списка, то IVR (Донабор), а все прочие иметь возможность переадресовать при включенной опции переадресации и при отсутствии talk37-регистрации.
    Непонятно: зачем опция “Передача вызова” в “Настройке правил обработки входящих звонков”, если там же есть та же и шире по функционалу “Переадресация”?

Просмотр 17 сообщений - с 1 по 17 (из 17 всего)