Инициализация переадресации вызова от имени прицепленной внешней учётки

 

Сервисы Общения Форумы Телефония Инициализация переадресации вызова от имени прицепленной внешней учётки

В этой теме 18 ответов, 4 участника, последнее обновление  tolik 3 года/лет, 8 мес. назад.

Просмотр 19 сообщений - с 1 по 19 (из 19 всего)
  • Автор
    Сообщения
  • #8323

    tolik
    Участник

    На talk37.ru технически возможно для входящих звонков организовать хитрую переадресацию вызова путём инициализации исходящего звонка на заранее вписанный пользователем в настройках talk37.ru SIP-номер от имени дополнительно для этих целей прицепленной к talk37.ru пользователем внешней учётной записи?
    Давно известная и нерешенная проблема на стороне оператора Sipnet: он когда как принимает или не принимает входящие из других сетей.

    #8325

    Demon
    Участник

    Сложно написано… но, если я не ошибаюсь, под этим скрывается абсолютно простая переадресация с настройкой правил исходящих через нужную учётную запись.
    Так в чём проблема? Могу помочь настроить

    #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.

    #8331

    tolik
    Участник

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

    #8332

    tolik
    Участник

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

    #8333

    tolik
    Участник

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

    #8334

    tolik
    Участник

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

    #8337

    Demon
    Участник

    Я дезориентирован 🙂 Слишком много деталей, а цель так и не ясна.
    Можно узнать цель всего этого? Как-то странно.. пользователи сипнета звонят на номер талк37, а оттуда обратно в сипнет… к чему эти метания голоса между серверами?
    Предлагаю определиться.. где же находится основной функционал, который Вы используете.
    Например, если учётную запись сипнета подключить к талк37, а смартфон или хардфон настроить на “устройство” талк37, то все входящие звонки на учётку сипнета Вы без проблем получите на подключенное устройство. Все исходящие звонки при должной настройке так же будут от имени учётки сипнета.
    Каковы же Ваши цели? Может быть описать поведение “на пальцах”?

    #8339

    tolik
    Участник

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

    #8342

    tolik
    Участник

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

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

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

    #8376

    a2group
    Участник

    Задача легко решаема. Регистрируем одну учетную запись sipnet для транзита звонков пришедших из talk37(включая прицепленные к нему внеш учетки). Задаем в правилах исходящих диалплан в котором указано ,что звонки с доп прификсом скажем 02 пойдут через транзитную учет запись сипнет. В правилах входящих устанавливаем переадресацию на номер 021234 где 1234 номер абонента сипнета куда надо переадресовать звонок.

    #8377

    a2group
    Участник

    в правило исходящих прописываем /^02(\d{3,})$/ заменить на: $1

    #8379

    tolik
    Участник

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

    #8380

    Demon
    Участник

    можите написать маршрут звонка? Мне не очень понятно что значит “прохождения звонков внутри Сипнет через эту и другую облачную АТС”.

    #8381

    tolik
    Участник

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

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

    #8383

    Дмитрий
    Участник

    Вот извращенцы)))

    #8385

    tolik
    Участник

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

    #8386

    Demon
    Участник

    Не ссорьтесь, горячие финские парни.
    @tolkien, надеюсь, наш сервис не мешает этим экспериментам? Т.е. он отрабатывает всё должным образом?
    Я вроде бы и стандартов не нарушал… и мало что запрещено в сервисе.

    #8387

    tolik
    Участник

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

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

Для ответа в этой теме необходимо авторизоваться.