Замена Action URL & URI в SIP-телефонах или управление via websockets?

    SIP-телефоны. Компьютеры с трубкой. По идее с ними очень многое можно что делать, а их используют только для звонков :-)

    Недавно был на конференции АстерКонф, и там вендоры рассказывали о своих телефонах, не будем никого выделять, все хороши, где-то лучше, где-то дешевле, по сути исполняют одно и то же.

    Кто-то из вендоров улучшает качество звука, кто-то прикручивает планшет с андроидом, кто-то пробует добавлять какие-то приложения. И все для того, чтобы мы устанавливали эти телефоны на рабочие столы.

    И может быть телефоны хорошие кандидаты на роль пульта в рамках мира IoT: нажал на кнопку — получил результат. И, на мой скромный взгляд, не хватает простого способа подключать телефоны к своему «Управлятору». В рамках этой статьи я хочу показать как это могло бы выглядеть по-простому на схеме и видео-демонстрации.

    А вы в комментариях поделитесь, пожалуйста, что может быть где-то уже подобное реализовано или дополните своими предложениями и мыслями.

    У телефонов есть интерфейсы Action URL и Action URI.

    Action URL позволяет нам отправлять разные события на какие-либо url. В url мы можем указать предустановленные переменные, которые будут при звонке заполнены реальными данными.

    Так, например, выглядит настройка моего телефона.



    онлайн-конструктор Action URL для Yealink'а

    Action URI позволяет нам принимать команды на IP-адрес телефона, и телефон может совершать вызовы, отвечать вызовы по команде, добавлять громкость, перезагружаться и т.д. на видео ниже можно посмотреть как это все происходит. Мы должны указать адрес, с которого будут приходить команды.



    Все настраивается, в чем проблема, бро?

    Это достаточно функциональные интерфейсы, но… они достаточно сложно интегрируются. Т.е. нам надо совершить 100500 действий чтобы это заработало. Или заполнить 100 полей в настройках аппарата (сами на скрине видите), или заморочиться с провижном и прописать какие-то шаблоны настройки.

    В итоге достаточно много действий, в которых легко ошибиться и не получить желаемого, а затем потратить кучу времени, чтобы разобраться в причинах несоответствующего поведения аппарата. И ладно если вы совладаете с одним, а у вас их пяток-десяток-сотня, да парочка вендоров и еще модели разных поколений. Уф-пуф-пуф…

    Проблема ли это? Надо ли кому-то управлять телефоном абонента? Самому абоненту? Со своего десктопа, лаптопа или смартфона? Технической поддержке? Как внутренней, так и внешней, например, провайдера виртуальной АТС? Нужно ли иметь доступ к телефону иначе, чем просто SIP? Интегрировать телефон с приложениями, минуя IP-АТС?

    Не могу ответить однозначно, есть минусы и плюсы. И для реализации плюсов хотелось бы иметь возможность быстро подключить Action URL и Action URI к своему «Управлятору». Управлятором я называю сервер, с которого я могу централизованно видеть список телефонов, их состояние, и с любого из них совершить какое-то доступное действие.

    Давайте посмотрим схему.



    Представьте, что у нас в телефоне есть websockets-клиент.

    Тогда нам в телефоне необходимо указать только сетевой адрес «Управлятора» и наш телефон к нему подключится. При подключении телефон отправит свой id, имя, mac. Это нам позволит сопоставить его с нашим списком абонентов АТС, например.

    Затем мы подпишемся на события, которые происходят на телефоне. Их там достаточно много, это перерегистрации, ответы на звонки, нажатия кнопок и т.д. Затем мы сможем с нашего Управлятора набрать номер, отправив команду. Или установить DND, или снять DND. Затем отправляю на телефон уведомление или напоминание, устанавливаю новый логотип.

    А как дела с безопасностью? В целом, SIP-телефоны могут работать за NAT, им не нужен внешний адрес. Но если вы выставите порт веб-сервера телефона в сеть Action URI (где еще админка, кстати, работает) — ждите неприятных сюрпризов.

    А вот если телефон будет подключаться к «Управлятору» по websockets, то это его инициатива и его право, может и отключиться, и если вы к удаленному серверу из-за NAT подключитесь, то будет похоже на браузерное соединение.

    Хватит слов, ближе к делу. Я написал небольшой клиент телефона (он по моей идее должен находиться в телефоне), который подключается к серверу по вебсокету. Также к этому серверу подключается браузер, который может принимать сообщения от телефона и посылать туда команды.

    Клиент всего лишь обертка для Action URL и Action URI, который работает с телефоном по привычным ему интерфейсам, а все данные оборачивает в вебсокет. В вебсокетах у нас ходят обычные JSON сообщения, с которыми может работать любой веб-разработчик.

    Посмотрите видео, все достаточно просто. Весь код достаточно минимальный, просто чтобы показать концепцию.


    Что происходит на видео?

    1. запускаем сервер, который принимает соединения по websockets,
    2. запускаем клиент (который работает по Action URL & URI с телефоном)
    3. клиент подключается к серверу
    4. запускаем веб-сервер (со страничкой, где код для подключения из браузера по websockets)
    5. открываем в браузере страничку, страница подключается к серверу
    6. мы со странички отправляем запрос на информацию
    7. запрос проходит по всей цепочке до телефона и возвращается информация о линиях телефона
    8. также мы можем отправлять разные команды
    9. в том числе команду совершить звонок
    10. а затем команду положить трубку
    11. все данные видны в логе на странице, а также в консоли работающего сервера и клиента телефона
    12. затем видно как реагирует на команды со страницы телефон

    Таким образом подключить телефон к Управлятору — достаточно одного лишь адреса. А сообщения из вебсокетов в иное представление и обратно может любой разработчик. В моем случае к Управлятору подключается просто страничка. В общем случае это может быть более сложная система, которая будет обрабатывать команды и отправлять сообщения на телефон.

    Наличие простого способа подключения может быть удобным, а значит более простым в освоении. Через этот интерфейс, по идее, можно присылать и новые конфигурации, и дополнительные сообщения, делая таким образом телефон легко интегрируемым в какую-либо инфраструктуру.

    В общем, это всего лишь мои размышления по итогу просмотра новинок на Астерконфе. Буду рад увидеть в комментариях за и против. И может быть кто-то из производителей увидит в этом рациональное зерно и внедрит фишку :-)

    Проект на гитхабе
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 13

      0
      Люди в свое время внедряли внедряли SRV записи в DNS, а в итоге приехали к websockets. Которые фактически эмулируют обычное tcp/ip соединение. Тут это простите зачем? Может стоит посмотреть различные протоколы автоконфигурации? К примеру тот же TR-069
        0
        Может быть и стоит посмотреть. А вы смотрели TR-069? А пробовали с его помощью выполнять процедуры на устройствах? удаленную диагностику?
          0
          Вот вам от билайна habr.com/ru/company/beeline/blog/244233
            0
            Первый абзац в разделе «Архитектура решения» рассказывает, что будет нелегко ))

            Возможно, я не выразил ясно мысль в статье, но еще раз попробую: решений как сделать управление телефоном полно, может быть есть проще? например, через вебсокеты гонять json?

            реализовать управление через tr-069 с cwmp да на soap я, пожалуй, смогу, но куча народу нет. а могли бы пилить свои программы на javascript'е и покупать телефоны в офисы и звонить, и кофеварками с жалюзями управлять.

            а может и не надо чтоб было просто никому?
              0
              например, через вебсокеты гонять json?

              Вот ровно точно так же родилась спецификация OpenAPI. Сначала люди сказали SOAP это сложно давайте гонять json через REST. Потом когда начали использовать, о нам надо какое-то описание API. В итоге получился OpenAPI который по своей спецификации весьма похож с wsdl из SOAP.
                0
                Вы правы, похож. Но проще, и потому выбирают сначала OpenAPI, а не SOAP.
                  0
                  Никакой разницы на самом деле. И там спеки читать и тут читать.
                    0
                    любой endpoint OpenAPI вы curl'ом легко проверите, в браузере все get'ы проверите, перешлете, обсудите, а SOAP, угу, wsdl-browser сначала найди норм

                    тут стандартная схема: будь проще и люди к тебе потянутся ))
        0
        1. У Avaya это называется Diagnostic Server. Весьма полезная штука.
        2. А этот Action URI где-то формализован?
        3. А он must be implemented?
          0
          Посмотрел описание Avaya Dagnostic Server, да, выглядит функционально. Интересно как внутри это работает.

          Action URI у каждого вендора в отдельной manual pdf описан. Какие реализовать параметры, действия определяется фантазией вендора. Спецификаций не встречал. И реализуется, конечно, на усмотрение вендора, хотя в той или иной мере, наверное, у всех есть.

          0

          Проблема в том, что каждый вендор тянул, тянет и будет тянуть одеяло на себя. Идея унификации не нова и даже очень хороша, но вендоры- это любители посадить на иглу, поэтому действуют в большинстве своём исходя из логики — купите у нас партию задешево, вы вам построим всю архитектуру, а потом, когда вы поймёте, что наше оборудование ломается чаще чем вы его используете, будет уже поздно, так как вся инфраструктура проприетарная и вы уже по уши в ней. И, либо много денег на переезд на другую инфру и переписывать Api на другой, либо сидеть с тем же и есть что дали…

            0
            А здесь нет унификации )) По мне пусть любой из вендоров сделает такую возможность, и я для его телефонов напишу приложения. И одеяло будет на его стороне.
            По поводу проприетарности, тоже плавали-знаем, в итоге всем нашлась ниша и клиент — кто-то выбирает вендорные решения, а кто-то строит на астериске.

            0

            Конкуренция среди вендоров всё агрессивнее, они уже свистелки и перделки в телефоны вкручивают. Любая свежая фишка упрощающая взаимодействие и развязывающая руки — шаг вперёд и конкурентное преимущество. Вполне себе вариант притянуть в простом интерфейсе на управление кофеваркой, светом, громкостью телевизора… Наличие любых возможностей — это плюс, чем минус. Телефоны не перестанут от этого быть телефонами и выполнять свои функции.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое