Как стать автором
Обновить
23
0
Портнов Алексей Владимирович @boffart

Программист

Отправить сообщение

Поделитесь опытом как Вы смогли добиться отправки inline keyboard от "user" до "user"?

Интересно выглядит заголовок "отправитель" через siptgbot (как то в этом процессе учавствует ваш бот)

Решаю схожу задачу, но отправить клавиатуру от пользователя к пользователю способа не нашел.

Бот не имеет возможности отправлять сообщения пользователю, который на него не подписан (не выболнена команда /start).

Пробовал переадресовать сообщение от бота к пользователю, но кнопки не пересылаются в этом случае.

Спасибо за развернутые ответы. Идею понял, интересно ))
Если уж на то пошло, то я не против Redirect'а, я против связки Redirect/MASTER_CHANNEL и мне кажется очевидным почему.


Явных проблем в конкретном случае я не вижу. В текущем примере MASTER_CHANNEL — это всегда Local канал. Local каналы всегда существуют парами.
Конечно, перед вызовом этой функции следует добавить проверку существования канала, это сделано в develop ветке Mikopbx, тут же примеры описаны упрощенно.

Опять же есть сомнения по поводу «красоты» и правильности итоговых данных в CDR.
Я попробую ваши примеры, но пока не вижу как в них решается задача с множественной регистрацией.

Добро / зло, снова философия... все относительно.

А если серьёзно: буду признателен, если предложите способ решения поставленной задачи без local и redirect. Пока я убеждён, что описал наиболее оптимальный вариант реализации.

Прежде всего, MikoPBX — это бесплатная АТС с открытым исходным кодом.
Данный функционал был реализован исключительно за счет энтузиазма boffart и jorikfon.
Что такое хорошо, что такое плохо — это все философия. Мне нравится позиция:
Получив оповещение о записи разговора, клиент и менеджер будут придерживаться общепринятых норм ведения переговоров, и понимать, что все выданные в процессе разговора обещания должны быть соблюдены


Описанный выше способ будет работать одинаково для входящих и для исходящих вызовов.

Если для входящих не проблема выполнить Playback для звонящего и потом направлять по основному маршруту, то для исходящих все сложнее.

Как писал выше в комментариях оповещение можно проиграть только одной стороне, с незначительными правками, главное передать правильное значение имени канала.

В статье описана упрощенная реализация. В итоговом продукте она еще не увидела релиза и будет выглядеть иначе.
Конкретно наши сотрудники — нет, не должны. А вот «заказчик-иностранец» захотел именно так.
Конкретно в дистрибутиве MikoPBX планирую реализовать опцию, где можно будет указать «Кто будет слышать оповещение».
"Приветствие" обычно проигрывается до соединения с сотрудником.
«Слышали оба» — пока посчитали, что это оптимальный вариант. Ничего не мешает поменять опцию в ChanSpy «B» на «w» и будет слышать только звонящий, но тогда возникает проблема — «сотрудник» не может однозначно узнать, когда оповещение завершится и может начать говорить параллельно оповещению.
В теории можно. Но на текущий момент соответствующий модуль не собран на АТС. Нет функционала генерации dialplan для этого канала.
Все верно подобрали ))
По сути это переопределение параметров для секции с «type=registration»
secret=1234

Глаза режет, нельзя такое писать! Ведь юзеры так и настроят. А без fail2ban это вообще «Добро пожаловать».
К Yandex проблем не было с подключением.
Даже инструкции одно время описал:
wiki.mikopbx.com/providers:yandex:telephony

можно устранить несколькими внутренними номерами и ринг группой

Попробовать можно, но проблемы кроются в деталях. Меня не устраивала история звонков в этом случае. Усложняется анализ / отборы в отчетах. Усложняется администрирование этого «огорода» учетных записей. «Не зашло» такое решение. В PJSIP все выглядит более красиво и правильно.

Неразрешимых проблем с подключением провайдеров не встретил, хотя проектов выполнил не мало.


Да, пока нет, но тот, проект, что я выложил, можно немного допилив реализовать нужный функционал. В итоговом модуле для Askozia это будет.
Спасибо за поправку. Действительно не описал про IP адрес.
224.0.1.75 — это multicast IP (для многоадресной рассылки) «зарезервирован» для SIP серверов

см. networksorcery.com/Enp/protocol/ip/multicast.htm
224.0.1.75 SIP, Session Initiation Protocol (all servers).
networksorcery.com/Enp/protocol/sip.htm

Интерфейса для Askozia пока нет. Не допилили. В ближайшее время постараемся опубликовать рабочую версию с интерфейсом, тогда дополню статью.
Спасибо Вам за комментарии! Проанализирую и учту замечания.

Гдето я такое уже видел.
Правда, там это сделали для исходящих правил.

Идею подсмотрели у Switchvox PBX. У нас это сделано именно для исходящих правил.
Миграцию сейчас никак не учитываем. Но есть нюансы. К примеру звонки на городские номера с Мегафон оплачиваются отдельно, сверх пакета минут, а вот если звонить через Yota, то в пакет минут выходят все исходящие не важно на какой номер.

Есть тонкости в «Домашнем регионе», не все операторы связи включают в пакет минут номера из чужих регионов.

Так и работаем. То есть принадлежность номера к определенному провайдеру на текущий момент не важна. А вот звонить на городские через tele2 или yota выгоднее чем через мегафон.
В целом — да, кейс редкий. Часто достаточно направить вызовы через одного, единственного провайдера (60% внедрений).
На примере нашей компании — используем GSM шлюз с 4 сим картами от разных провайдеров.
распределяем звонки используя эти правила.
Это и сейчас разрешено, можно описать custom-контекст и выполнить произвольный AGI скрипт, не важно SHELL / PHP / GO, на чем на пишете ))

Пример описан тут wiki.mikopbx.com/faq:specific_provider
О кастомизации опишу отдельную статью.

Из минусов — это скрипт придется залить на станцию вручную по SFTP, положить можно к примеру на /storage/usbdisk1
Пожалуйста. Организаторам предоставил все материалы, должны будут участникам разослать.
Дополнительно очень жду видео выступления ))
Следует использовать Local канал:
Пример «Channel»:
Local/number@context

тут:
  • "number" — номер телефона, именно на него придет вызов, как только абонент снимет трубку вызов будет направлен на exten
  • "context" — в этом контексте будет производится набор номера "number"
"УправляемаяФорма" не может быть получена не сервере ни каким образом.
Из справки: метод "ПолучитьФорму" может быть вызван только в контексте "Тонкий клиент, веб-клиент, толстый клиент".

"НаСервере" инициализировать управляемую форму просто так нет возможности.

В итоге: серверный метод управляемой формы в контексте сервера может быть вызван только из этой самой формы.
То есть вызов "ЭтаФорма.ПриватнаяНаСервере();" теряет смысл и равнозначен "ПриватнаяНаСервере();".
1

Информация

В рейтинге
Не участвует
Откуда
Зеленоград, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Fullstack Developer, 1C Developer
Lead
PHP
Linux
Bash