Voip tcp telegram что это
Перейти к содержимому

Voip tcp telegram что это

  • автор:

Занятная приоритизация голосового трафика в Telegram

Наверное, многим интересно, как же команде Telegram удалось сделать популярную для мессенджеров функцию голосовых звонков уже сразу после запуска разительно отличающейся по качеству в лучшую сторону перед многими другими VoIP — сервисами.

Во время изучения работы Telegram Calls я обратил внимание на интересную техническую деталь, которая используется на сетевом уровне и помогает уменьшить задержки при прохождении пакетов, когда при соединении используются релейные сервера.

Если взглянуть на дамп трафика, который проходит при звонке, в котором использовался релейный сервер, можно заметить, что трафик определяется протоколом RIP. IP на 91. — это сервер Telegram. Я снимал дамп трафика на своём VPN — сервере, поэтому адрес клиента из локальной подсети.

А вот скриншот из дебага клиента, но уже при P2P. Стоит отметить, что 520 порт назначен только серверам, поэтому этот метод работает тогда, когда P2P — соединение между клиентами невозможно и один из серверов из списка выступает в роли релея.

Вспомним, что нам известно про протокол RIP?
RIP — протокол маршрутизации. RIP работает на 3 уровне (сетевой) стека TCP/IP, используя UDP порт 520. UDP, то есть доставка, не требующая подтверждения приёма, как известно, сам по себе отлично подходит для трафика реального времени, коим является голос.

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

Эта приоретизация реализуется в маршрутизаторах с помощью DSCP — кодов ( Differentiated Services Code Point ), и по-умолчанию, например, в Cisco согласно RFC 791 и RFC 2474 протоколы маршрутизации RIP/RIP2/OSPF/EIGRP маркируются кодом 6. А это, на минуточку, предвысший, Internetwork Control приоритет.

Кроме приоритизации DSCP, Cisco IOS также имеет внутренний механизм PAK_priority, который служит для предоставления приоритета для важных датаграмм именно в момент их прохождения через роутер. PAK_priority designation был задуман разработчиками Cisco (и, можно предположить, некоторыми другими) оборудования как критически важный для корректной работы Cisco IOS, и поэтому его никак нельзя конфигурировать. Что исключает возможность администраторам как-либо влиять на приоритетный пропуск трафика, имеющего для системы характеристики Control.

Похоже, вспомнив про древний протокол и особенности его работы (полезный UDP, существование возможности Unicast — обмена), архитекторы Telegram использовали его порт, тем самым заставили многие маршрутизаторы на пути следования пакетов обрабатывать их трафик как очень важный, тем самым, очевидно, несколько сократив задержки.

Вроде бы небольшая деталь в мире мощных кодеков, но, как говорится, дьявол кроется в мелочах — так почему бы не заставить эти мелочи работать на благо конечной цели?

Мобильный протокол MTProto

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

Связанные статьи

Общее описание

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

Протокол разбит на три почти независимых части:

  • Высокоуровневая часть (язык запросов к API) — определяет, каким образом запросы к API и ответы на эти запросы преобразуются в двоичные сообщения.
  • Криптографическая (авторизационная) прослойка — определяет, каким образом сообщения шифруются перед передачей через транспортный протокол.
  • Транспортная часть — определяет, каким образом передаются сообщения между клиентом и сервером поверх какого-либо другого существующего сетевого протокола (например, http, https, tcp, udp).

Примечание 1: Каждое текстовое сообщение, которое нужно зашифровать через MTProto, всегда содержит следующие данные, которые проверяются расшифровкой, чтобы сделать систему устойчивой против известных проблем с компонентами:

  • server salt (соль сервера) (64-битная)
  • session id (идентификатор сессии)
  • message sequence number (порядковый номер сообщения)
  • message length (длина сообщения)
  • time (время)

Краткий обзор компонентов

Высокоуровневая часть (язык RPC-запросов/API)

С точки зрения высокоуровневой части, клиент и сервер обмениваются сообщениями в рамках некоторой сессии. Сессия привязана к клиентскому устройству (вернее, приложению), но не к конкретному http/https/tcp-соединению. Кроме того, каждая сессия привязана к идентификатору пользовательского ключа, по которому фактически производится авторизация.

Может быть открыто несколько соединений к серверу; сообщения в ту или иную сторону могут идти по любому из них (ответ на запрос не обязан прийти по тому же соединению, по которому был отправлен сам запрос, хотя чаще всего это так; однако ни в коем случае сообщение не может быть возвращено в соединении, принадлежащем другой сессии). При использовании UDP-протокола может случиться, что ответ на запрос приходит не с того IP, на который был отправлен запрос.

Сообщения бывают нескольких типов:

  • RPC-вызовы (от клиента к серверу) — обращения к методам API
  • RPC-результаты (от сервера к клиенту) — результаты RPC-вызовов
  • Подтверждение приема сообщений (вернее, уведомление о состоянии набора сообщений)
  • Запрос состояния сообщений
  • Составное сообщение или контейнер (контейнер, содержащий несколько сообщений; нужен, например, чтобы по HTTP-соединению можно было отправить несколько RPC-вызовов сразу; кроме того, контейнер может поддерживать gzip).

С точки зрения протоколов более низкого уровня, сообщение — это поток двоичных данных, выровненный по границе 4 или 16 байтов. Первые несколько полей сообщения фиксированы и используются системой криптографии/авторизации.

Каждое сообщение, отдельное или внутри контейнера, состоит из идентификатора сообщения (64 бита; см. ниже), порядкового номера сообщения в сессии (32 бита), длины (тела в байтах; 32 бита) и тела (любой размер, кратный 4 байтам). Кроме того, при отправке контейнера или одиночного сообщения, в его начало дописывается внутренний заголовок (см. ниже), после чего все это шифруется, и в начало зашифрованного сообщения добавляется внешний заголовок (64-битный идентификатор ключа и 128-битный ключ сообщения).

Тело сообщения обычно состоит из 32-битного типа сообщения, за которым следуют параметры, зависящие от типа. В частности, каждой RPC-функции соответствует свой тип сообщения. Более подробно читайте в статье про двоичную сериализацию данных и служебные сообщения.

Все числа записываются как little-endian. Однако очень большие числа (2048-битные), используемые в RSA и DH, записываются как big-endian, потому что так делает библиотека OpenSSL.

Авторизация и криптография

Перед передачей сообщений (или составных сообщений) по сети посредством транспортного протокола они шифруются определенным образом; при этом перед сообщением приписывается внешний заголовок: 64-битный идентификатор ключа (однозначно определяющий авторизационный ключ для сервера, а также пользователя) и 128-битный ключ сообщения. Пользовательский ключ вместе с ключом сообщения определяют реальный 256-битный ключ, которым и зашифровано сообщение посредством шифра AES-256. Начало тела незашифрованного сообщения содержит некоторые данные (сессию, идентификатор сообщения, порядковый номер сообщения в сессии, серверную соль); ключ сообщения должен совпадать с младшими 128 битами SHA1 от тела сообщения (включая сессию, идентификатор сообщения и т.п.). Составные сообщения шифруются как единое целое.

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

Примечание от переводчика: по некоторым сведениям, в последних обновлениях этот ключ меняется через каждые 100 отправленных сообщений — https://twitter.com/durov/status/539489480676085760

Основной недостаток протокола — в том, что злоумышленник, пассивно перехватывающий сообщения, а затем каким-либо образом заполучивший авторизационный ключ (например, украв устройство) получит возможность расшифровать все перехваченные сообщения post factum. Вероятно, это не слишком серьезно (украв устройство, можно получить и всю закешированную на нем информацию, ничего не расшифровывая), однако для преодоления этих проблем можно сделать следующее:

  • Сессионные ключи, генерируемые по протоколу Диффи-Хелмана, и используемые совместно с авторизационным ключом и ключом сообщения для выбора параметров AES. Для их создания клиент должен первым действием после создания новой сессии отправить серверу специальный RPC-запрос («сгенерировать сессионный ключ»), сервер ответит на него, после чего все последующие сообщения сессии шифруются с учетом и сессионного ключа.
  • Защищать ключ, хранимый на клиентском устройством, (текстовым) паролем; этот пароль никогда не хранится в памяти и вводится пользователем при запуске приложения или чаще (в зависимости от настроек приложения).
  • Данные, хранимые (кэшируемые) на пользовательском устройстве, можно также защищать, шифруя с помощью авторизационного ключа, который, в свою очередь, надо защитить паролем. Тогда без ввода пароля невозможно будет получить доступ даже к этим данным.

Синхронизация времени

Если время на клиенте сильно отличается от времени на сервере, может так получиться, что сервер начнет игнорировать сообщения клиента, или наоборот, из-за некорректного значения идентификатора сообщения (которое тесно связано с временем создания). В таких ситуациях сервер шлет клиенту специальное сообщение с правильным временем, содержащие, помимо него, некую 128-битную соль (либо явно присланную клиентом в специальном RPC-запросе синхронизации, либо равную ключу последнего сообщения, полученного от клиента в рамках данной сессии). Такое сообщение может быть первым в контейнере, содержащим и другие сообщения (если рассинхронизация существенна, но еще не приводит к игнорированию клиентских сообщений).

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

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

Транспорт

Позволяет доставлять уже зашифрованные контейнеры вместе с внешним заголовком (в дальнейшем — полезную нагрузку) от клиента к серверу и наоборот. Есть три типа транспорта:

  • HTTP
  • TCP
  • UDP

Рассмотрим первые два типа.

Передача по HTTP

Реализуется поверх HTTP/1.1 (с keepalive), запущенного поверх классического TCP-порта 80. HTTPS не используется; используется криптографическая схема, объясненная выше.

HTTP-соединение привязывается к сессии (вернее, сессии + идентификатору ключа), указанной в последнем пришедшем пользовательском запросе; обычно во всех запросах сессия одинакова, однако хитрые HTTP-прокси могут это испортить. Сервер может вернуть сообщение в HTTP-соединение только в том случае, если оно принадлежит той же сессии, и если сейчас очередь сервера (был получен HTTP-запрос от клиента, на который еще не было отправлено ответа).

Общая схема такова. Клиент открывает одно или несколько keepalive HTTP-соединений к серверу. При необходимости отправки одного или нескольких сообщений из них составляется полезная нагрузка, после чего делается POST-запрос на URL /api , в качестве данных которому и передается полезная нагрузка. Кроме того, допускаются HTTP-заголовки Content-Length , Keepalive , Host .

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

Кроме того, есть специальный longpoll RPC-запрос (действительный только для http-соединений), в котором передается максимальное время ожидания T. Если у сервера есть сообщения для этой сессии, они возвращаются сразу же; в противном случае происходит ожидание до тех пор, пока у сервера не появится сообщение для клиента, либо не пройдет T секунд. Если за T секунд не произошло никаких событий, возвращается фиктивный ответ (специальное сообщение).

Если серверу надо отправить сообщение клиенту, он проверяет, нет ли HTTP-соединения, принадлежащего нужной сессии, и находящегося в состоянии «выполнения HTTP-запроса» (включая long poll), после чего сообщение добавляется в контейнер ответа этого соединения и отправляется пользователю. В типичном случае происходит небольшое дополнительное ожидание (50 миллисекунд), на тот случай, если у сервера вскоре появятся еще сообщения для этой сессии.

Если ни одного подходящего HTTP-соединения нет, сообщения ставятся в очередь отправки для данной сессии. Впрочем, они туда попадают в любом случае, пока явно или косвенно не подтверждено получение клиентом. Для http-протокола неявным подтверждением считается отправка следующего запроса по тому же HTTP-соединению (уже нет — и для HTTP-протокола необходимо слать явные подтверждения); в остальных случаях клиент должен прислать явное подтверждение за разумное время (его можно добавить в контейнер для следующего запроса).

Важно: если подтверждение вовремя не пришло, сообщение может быть перепослано (возможно, в составе другого контейнера). Стороны должны быть морально готовы к этому и хранить идентификаторы последних полученных сообщений (и игнорировать такие дубли, а не повторять действие). Для того, чтобы не хранить идентификаторы вечно, есть специальные сообщения сборки мусора, эксплуатирующие монотонность идентификаторов сообщений.

Если очередь отправки переполняется, или сообщения ждут в ней больше 10 минут, то сервер их забывает (или отправляет в своп — дурное дело нехитрое). Это может случиться и быстрее, если у сервера заканчиваются буферы (например, из-за серьезных проблем в сети, приведших к разрыву большого количества соединений).

TCP-транспорт

Очень похож на HTTP-транспорт, может быть реализован тоже на порт 80 (чтобы проходить все фаерволы) и даже на те же ip-адреса серверов. В этом случае сервер понимает, нужно ли использовать HTTP или TCP-протокол для данного соединения по первым четырем пришедшим байтам (для HTTP это будет POST).

При создании TCP-соединения оно приписывается сессии (и авторизационному ключу), переданному в первом сообщении пользователя, и потом используется исключительно для данной сессии (схемы мультиплексирования не допускаются).

При необходимости отправки полезной нагрузки (пакета) от сервера к клиенту или от клиента к серверу она инкапсулируется следующим образом: спереди дописывается 4 байта длины (включая длину, порядковый номер и CRC32; всегда делится на четыре) и 4 байта с порядковым номером пакета внутри данного tcp-соединения (первый отправленный пакет помечается 0, следующий — 1 и т.д.), а в конце — 4 байта CRC32 (длины, порядкового номера и полезной нагрузки вместе).

Существует сокращённая версия этого протокола: если клиент отправляет первым байтом (важно: только перед самым первым пакетом данных) 0xEF , то после этого длина пакета кодируется одним байтом ( 0×01..0×7E = длина данных, делённая на 4; либо 0×7F , а затем 3 байта длины (little-endian), делённой на 4), а далее идут сами данные (порядковый номер или CRC32 не добавляются). Ответы сервера в этом случае имеют тот же вид (при этом сервер не отсылает первый байт 0xEF ).

В случае, если требуется выравнивание 4-байтовых данных, может быть использована промежуточная версия оригинального протокола: если клиент отправляет 0xEEEEEEEE как первый инт (int) (четыре байта), то длина пакета зашифрована всегда четырьмя байтами как в оригинальной версии, но порядковый номер и CRC32 опускаются, таким образом уменьшая итоговый /общий размер пакета на 8 байт.

В полной и в сокращённой версии протокола есть поддержка быстрых подтверждений. В этом случае клиент устанавливает старший бит длины в пакете с запросом, а сервер отсылает в ответ специальные 4 байта, представляющие собой самостоятельный пакет. Они представляют собой старшие 32 бита SHA1 от зашифрованной части пакета, с установленным старшим битом, чтобы было понятно, что это не длина обычного пакета с ответом сервера; если используется сокращённая версия, то к этим четырём байтам применяется bswap.

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

В случае возникновения ошибки сервер может прислать пакет, полезная нагрузка которого состоит из 4 байтов — кода ошибки. Например, код ошибки −403 соответствует ситуациям, в которых через HTTP-протокол вернулась бы соответствующая HTTP-ошибка.

Сайт про Telegram на русском (неофициальный).

Здесь собраны приложения на базе MTProto, переведена некоторая документация с официального сайта, а также работает Webogram.

Peer to peer что это в телеграмме

На протяжении месяца творцы мессенджера трудились, не покладая рук, чтобы порадовать вас новой качественной услугой от Telegram. Теперь в Telegram доступны звонки, и эта опция соответствует ряду параметров:

  • высокое качество;
  • летающая скорость без запинок и прерываний;
  • секретная система защиты персональных данных.

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

Безопасность

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

Скорость

Создали максимум возможностей для общения без сбоев и лагов, а остальное зависит именно от качества Интернет — соединения. Для экономии трафика, нами была придумана занятная фишка — использование однорангового (Peer-to-peer) соединения, которое использует массу инновационных аудиокодеков.

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

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

Умная система

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

  • скорость передачи голосовой информации;
  • наличие/отсутствие задержек (их причина);
  • наличие пересоединения;
  • часть потери пакетов.

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

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

Конфиденциальность

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

Еще один благоприятный момент в том, что программка обладает искусственным интеллектом и сама способна задавать параметры для звонка, касающиеся трафика. Все звонки автоматически подстраиваются под имеющийся источник соединения, но вы тоже можете сэкономить трафик, воспользовавшись вспомогательной опцией «Use Less Datа». Данная опция немного снизит качество звука, но поможет вам сэкономить 25 — 30% трафика.

Простота

Создатели считают, что простота в мессенджере — это вовсе не плохой признак, ведь нет смысла тратить силы на интерфейс, если «начинка» бедная. Именно по этой причине, не будут перегружать главное окно дополнительными ссылками и вставками. Таким образом, чтобы совершить звонок, необходимо открыть вкладку «Calls», которая находится в «Recent Calls», и найти нужного абонента. Если же вы не совершали звонков ранее, то можете пойти легким путем: зайти в нужный чат и кликнут на символ в виде трубочки.

В Telegram обнаружили уязвимость, из-за которой IP-адреса пользователей раскрывались во время звонков через мессенджер. Об этом рассказал эксперт безопасности Дхирадж Мишра (Dhiraj Mishra) в своем блоге.

Утечка происходила из-за прямого однорангового соединения между абонентами (peer-to-peer, или P2P), которое стоит в звонках Telegram по умолчанию. В мобильных версиях этот параметр можно изменить в настройках, однако в десктопных программах разработчики изначально не предусмотрели такую функцию.

При использовании P2P IP-адреса обоих участников разговора отображаются в логах. Эта уязвимость позволяла раскрыть местоположение пользователя, тем самым создавая угрозу его конфиденциальности.

Мишра сообщил о найденной утечке представителям Telegram. Разработчики быстро добавили возможность отключения P2P-звонков в десктопных версиях программы, а также заплатили эксперту 2 тысячи евро (около 152 тысяч рублей) в качестве награды.

В конце августа стало известно, что Telegram согласился выдавать спецслужбам данные пользователей. Позднее основатель мессенджера Павел Дуров пояснил, что это условие не касается российских ведомств.

Телеграм — один из самых быстрых и популярных мессенджеров с неисчислимым количеством функций. Одной из них является голосовое общение посредством звонков. Многие пользователи сталкивались с тем, что связь прерывается раз в несколько минут и программа пытается восстановить соединение. Почти всегда безуспешно.

Причина этого — направление сигнала через серверы Telegram. Это позволяет вам сохранить анонимность (ваш IP никто не узнает)

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

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

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

Также напоминаем, что с 10 октября 2017г. в мобильной версии Telegram доступен русский язык . В связи с этим инструкция по восстановлению стабильной связи будет изложена как на английском, так и на русском языках.

Как настроить стабильные звонки в Телеграм — инструкция

  1. Откройте меню программы (три горизонтальные полоски в верхнем левом углу экрана)
  2. Нажмите Settings / Настройки
  3. Перейдите в раздел Privacy and Security / Конфиденциальность и безопасность
  4. Пролистайте страницу вниз до самого конца
  5. В строке Calls / Звонки, Peer-to-Peer: деактивируйте функцию, переместив качельку влево.

Теперь качество связи будет несравнимо лучше. Если вам потребуется сохранить свою анонимность при общении через Telegram в дальнейшем, проделайте действия в том же порядке, в конце переместив качельку вправо (тем самым вновь активируя технологию Peer-to-Peer.

Полезно знать

Есть еще одна полезная настройка в десктопной версии программы Telegram.

Каналы и группы, которые находятся в режиме MUTE (беззвучном) отвлекают числом непрочитанных сообщений, возникающим на иконке Телеграм в трее или на панели задач.

Чтобы получать уведомления только о сообщениях в интересующих вас группах, перейдите в настройки Телеграм и уберите галочку в строке Include muted chats in unread count блока Notifications.

Установка и настройка SIP шлюза для Telegram

Telegram — кроссплатформенный мессенджер, позволяющий обмениваться сообщениями и медиафайлами многих форматов. Так же данный мессенджер позволяет осуществлять аудио звонки между пользователями Telegram, благодаря разработки с открытым исходным кодом https://github.com/Infactum/tg2sip появилась возможность взаимодействия между Asterisk и Telegram по SIP протоколу. В рамках данной статьи будет рассмотрено как выполнить установку и настройку SIP шлюза для Telegram. Возможности […]

Telegram — кроссплатформенный мессенджер, позволяющий обмениваться сообщениями и медиафайлами многих форматов. Так же данный мессенджер позволяет осуществлять аудио звонки между пользователями Telegram, благодаря разработки с открытым исходным кодом https://github.com/Infactum/tg2sip появилась возможность взаимодействия между Asterisk и Telegram по SIP протоколу.

В рамках данной статьи будет рассмотрено как выполнить установку и настройку SIP шлюза для Telegram. Возможности SIP шлюза:

  1. Звонки из Telegram на внутренний номер Asterisk
  2. Звонки из Asterisk пользователю Telegram по никнейму или номеру телефона

При написании статьи так же использовались следующие библиотеки и программные продукты с открытым исходным кодом:

  1. Кроссплатформенная библиотека для построения клиентов Telegram — <td-master.zip>
  2. Библиотека для организации PJSIP медиа стека — <pjproject-master.zip>
  3. Библиотека для логирования — <spdlog-1.x.zip>
  4. SIP шлюз для Telegram – <tg2sip-master.zip>
  5. Скрипт установки кроссплатформенной системы автоматизации сборки программного обеспечения из исходного кода Cmake — <cmake-3.9.6-Linux-x86_64.sh>
  6. Кодек OPUS – <codec_opus-13.0_current-x86_64.tar.gz>

Инструкция:

1. Перейдём в WEB панель управления FreePBX через интернет обозреватель(Opera, Firefox, Google Chrome, Yandex Browser….) по ссылке вида: http://IP_адрес_сервера_Asterisk/ В примере ссылка имеет вид: http://192.168.1.231/

WEB панель FreePBX.

WEB панель FreePBX.

2. Пройдём авторизацию во FreePBX, нажмём «FreePBX Administration», введем «username и password» и нажмём «Continue»

 Авторизация во FreePBX.

Авторизация во FreePBX.

3. Перейдем в меню Connectivity → Trunks → Add Trunk(SIP) и заполним ключевые параметры транка:

1) Trunk Name – наименование транка на вкладке General
2) Trunk Name — наименование sip пира на вкладке «sip Settings»
3) PEER Details – параметры транка. В примере SIP шлюз будет установлен на тот же сервер, что и Asterisk(т.е. локально), IP сервера 192.168.1.231 и порт шлюза должен быть отличным от используемого порта в Asterisk(в примере 5062)

Добавление SIP транка без регистрации

Добавление SIP транка без регистрации

Добавление SIP транка без регистрации

Добавление SIP транка без регистрации

Добавление SIP транка без регистрации

Добавление SIP транка без регистрации

4. Для возможности звонков на telegram с использованием коротких внутренних номеров, рассмотрим вариант создания Custom номеров, для этого перейдем в меню Applications → Extensions → Add Extension → Add New Custom Extension и заполним ключевые параметры:

1) User Extension – короткий внутренний номер, на вкладке General.
2) Display Name – имя внутреннего номера, на вкладке General.
3) Dial – строка вызываемого номера, на вкладке Advanced. Для звонка по никнейму должна иметь вид: SIP/tg#<ник>@192.168.1.231:5062. Для звонка по номеру мобильного должна иметь вид: SIP/ [email protected] :5062.

Добавление Custom внутреннего номера.

Добавление Custom внутреннего номера.

Добавление Custom внуреннего номера.

Добавление Custom внутреннего номера.

Добавление Custom внутреннего номера.

Добавление Custom внутреннего номера.

5. Для взаимодействия с Telegram необходимо выполнить регистрацию приложения и получить APP ID и API HASH, для этого перейдем на страницу https://my.telegram.org/auth и пройти авторизацию с использование мобильного номера

Авторизация в Telegram.

Авторизация в Telegram.

По смс или на авторизованный клиент Telegram-а придет сообщение с кодом авторизации, скопируем его и введем на странице авторизации. После успешного прохождения авторизации нам станет доступен раздел «API development tools», перейдем в него

Код подтверждения авторизации

Код подтверждения авторизации

Личный кабинет Telegram

Личный кабинет Telegram

Для регистрации приложения необходимо заполнить следующие поля:

1) App title – название приложения
2) Short name – упрощенное наименование приложения
3) URL – ссылка на сайт проекта
4) Platform – платформа создаваемого приложения, т.к. наше приложение не попадает не под один из критериев то выберем Other
5) Description – описание создаваемого приложения

Регистрация приложения Telegram

Регистрация приложения Telegram

После успешного заполнения формы система сгенерирует автоматически необходимые значения APP ID и API HASH, скопируем данные значения для последующей настройки.

APP ID и API HASH

APP ID и API HASH

6. Выполним подключение по SSH к серверу IP АТС Asterisk. В зависимости от используемой системы(Windows, Linux, MacOS), подключение по SSH можно выполнить с использованием различного дополнительного программного обеспечения(Putty), либо системного терминала.

7. Прежде чем приступить к установке шлюза, нам необходимо выполнить установку ряда зависимостей, для этого в SSH консоли на сервере Asterisk выполним команды:

Установка зависимостей

Установка зависимостей

Установка зависимостей

Установка зависимостей

Установка зависимостей

Установка зависимостей

Установка зависимостей

Установка зависимостей

8. Для сборки из исходников ряда зависимостей и SIP шлюза для Telegram, потребуется кроссплатформенная система автоматизации сборки программного обеспечения из исходного кода Cmake 3.9.6, для установки Cmake в SSH консоли на сервере Asterisk выполним команды:

Установка Cmake

Установка Cmake

9. Одной из необходимых зависимостей является кроссплатформенная библиотека для построения клиентов Telegram «Tdlib», приступим к её сборке и установке, для этого в SSH консоли на сервере Asterisk выполним команды:

Сборка и установка Tdlib

Сборка и установка Tdlib

Сборка и установка Tdlib

Сборка и установка Tdlib

Сборка и установка Tdlib

Сборка и установка Tdlib

10. Так же необходимой зависимостью является библиотека для организации PJSIP медиа стека «PJProject», приступим к её сборке и установке, для этого в SSH консоли на сервере Asterisk выполним команды:

Сборка и установка библиотеки для организации PJSIP медиа стека «PJProject»

Сборка и установка библиотеки для организации PJSIP медиа стека «PJProject»

Сборка и установка библиотеки для организации PJSIP медиа стека «PJProject»

Сборка и установка библиотеки для организации PJSIP медиа стека «PJProject»

Сборка и установка библиотеки для организации PJSIP медиа стека «PJProject»

Сборка и установка библиотеки для организации PJSIP медиа стека «PJProject»

11. Последней необходимой зависимостью является библиотека для организации логирования в C++ SPDlog, приступим к её сборке и установке, для этого в SSH консоли на сервере Asterisk выполним команды:

Сборка и установка библиотеки для организации логирования SDPlog

Сборка и установка библиотеки для организации логирования SDPlog

Сборка и установка библиотеки для организации логирования SDPlog

Сборка и установка библиотеки для организации логирования SDPlog

Сборка и установка библиотеки для организации логирования SDPlog

Сборка и установка библиотеки для организации логирования SDPlog

12. Успешно завершив сборку и установку всех вышеописанных зависимостей, приступим к сборке и установке SIP шлюза для Telegram, для этого в SSH консоли на сервере Asterisk выполним команды:

Сборка и установка Tg2SIP

Сборка и установка Tg2SIP

Сборка и установка Tg2SIP

Сборка и установка Tg2SIP

Сборка и установка Tg2SIP

Сборка и установка Tg2SIP

13. Успешно выполнив сборку и установку SIP шлюза для Telegram, приступим к его настройке, для этого в SSH консоли на сервере Asterisk выполним команду:

И приведем конфигурационный файл к виду:

где ключевые параметры для изменения:

  1. logging — уровни логирования(0-трасировка 2-информационные 4-ошибки 6-отключено 1-отладка 3-warn 5-критические)
  2. port — порт который будет слушать шлюз, должен быть отличным от порта Asterisk, в примере данной статьи используем 5062 порт
  3. id_uri — SIP ID, строка должна иметь вид: [email protected] _Asterisk
  4. callback_uri – uri строка для организации входящего звонка на Asterisk(sip: [email protected] _Asterisk:Port_Asterisk)
  5. api_id– ID зарегистрированного приложения(п.5 данной статьи)
  6. api_hash — HASH зарегистрированного приложения(п.5 данной статьи)
  7. use_proxy – использование прокси для работы клиентской части Telegram клиента в SIP шлюзе, может принимать два значения «true» или «false»
  8. proxy_address – адрес прокси сервера
  9. proxy_port — порт прокси сервера
  10. proxy_username — имя пользователя прокси
  11. proxy_password — пароль пользователя прокси

Настройка SIP2TG шлюза

Настройка SIP2TG шлюза

14. Для корректного прохождения голоса потребуется установка OPUS кодека, для этого в SSH консоли на сервере Asterisk выполним команды:

Скачивание кодека OPUS

Скачивание кодека OPUS

Приведем конфигурационный файл к виду:

Настройка кодека OPUS

Настройка кодека OPUS

Выполним подключение кодека:

Подключение кодека OPUS

Подключение кодека OPUS

15. Т.к. SIP шлюз не позволяет в строку callback_uri подставлять разные внутренние номера, то для удобства созвона с нужным внутренним номером направим входящий звонок для экстена telegram в контекст быстрого голосового набора рассмотренного в статье

Добавим контекст вида:

alt=»Контекст быстрого голосового набора» width=»1024″ height=»71″ />Контекст быстрого голосового набора

16. На этом установка и подготовка завершены, выполним запуск SIP шлюза. Для первого раза единожды необходимо будет запустить gen_db для заведения базы необходимой созданному клиенту Telegram, для этого в SSH консоли на сервере Asterisk выполним команды:

Генерация базы для клиента Telegram

Генерация базы для клиента Telegram

 Запуск SIP шлюза для Telegram

Запуск SIP шлюза для Telegram

17. Звонок с Telegram на внутренний номер

Звонок с Telegram на внутренний номер

Звонок с Telegram на внутренний номер

Звонок с Telegram на внутренний номер

Звонок с Telegram на внутренний номер

18. Звонок с внутреннего номера на кастом внутренний номер с закрепленным за ним никнеймом telegram пользователя

Звонок с внутреннего номера на Telegram

Звонок с внутреннего номера на Telegram

Звонок с внутреннего номера на Telegram

Звонок с внутреннего номера на Telegram

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *