Telegramm <-> Asterisk

[Ferrum]

Касательно данной темы, есть ли на данной момент альтернативные уже готовые бесплатные решения (пакеты, исходники) в общем доступе, для совместной работы Телеграмм и Астериск ?
Собственно описание самой проблемы https://www.sip.tg/docs/tg2sip

[ded]

Рассчитываете что команда SIP.TG выложит в открытый доступ своё решение Шлюза для приема и совершения звонков с единого Telegram-аккаунта и лишится честного заработка?

[Ferrum]

Нет, просто надеюсь что поисковиком пользоваться не умею и меня как котенка ткнут носом в исходники ))

[gaspaarr]

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

P.S. В связке АБОНЕНТ1(МОБ.ОПЕРАТОР) >ВЫЗОВ> АБОНЕНТ2(МОБ.ОПЕРАТОР) > БЕЗУСЛОВНАЯ ПЕРЕАДРЕСАЦИЯ > АБОНЕНТ3(SIP.ОПЕРАТОР) - в заголовках SIP номер абонента 2 никак получить нельзя? Никто из SIP операторов не передает эти данные?

[ded]

Избавимся от наследия АОНа?

А О Н - это технология, а не сам номер. Автоматическое Определение Номера, технология обратного вызова, советской эпохи,
Информация о номере вызывающего абонента передаётся в виде кода, носящего название «Безынтервальный Пакет» (код 2 из 6) в виде одновременной передачи 2 частот из 6 доступных в этом коде в интервале от 700 до 1700 Гц, посылаемый телефонной станцией вызывающего абонента при одновременном ответе на исходящий вызов и получении сигнала запроса (с входящей стороны) в виде однотональной посылки 500 Гц. Данный метод передачи номера вызывающего абонента распространён в телефонных сетях, построенных на оборудовании бывшего СССР. Не являлся услугой АТС, поскольку не был предназначен для абонентов.

https://ru.wikipedia.org/wiki/%D0%90%D0%9E%D0%9D
устаревшая, и задействованная только ещё на старых телефонах Panasonic, где есть выбор - включить определение номера:
А О Н или Caller ID.

Не все, но некоторые операторы используют для этой цели поле Diversion
Запрос INVITE, поступающий на Asterisk будет такой:

Код: Выделить всё

INVITE sip:2057004@10.200.104.12:5172;user=phone SIP/2.0
Accept: application/sdp;q=0.3
Accept: application/ISUP;q=0.2
Accept: multipart/mixed;q=0.1
Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS,REGISTER,REFER,SUBSCRIBE,MESSAGE,PUBLISH
Call-ID: 41a5c682bgw882nql@10.200.101.11
Contact: "3303030" <sip:3303030@10.200.101.11:5060;user=phone>
CSeq: 298 INVITE
Expires: 3600
From: "3303030" <sip:3303030@10.200.101.11:5060;user=phone;cpc=ordinary>;tag=t8uu0piu60
To: "205704" <sip:2057004@10.200.104.12:5172;user=phone>
Organization: IskraTel
User-Agent: SI3000
Via: SIP/2.0/UDP 10.200.101.11:5060;branch=z9hG4bK-8uhf0-9alb1
Max-Forwards: 69
Subject: Call from CS6111
Diversion:"910123000"<sip:9101230000@10.200.101.11:5060>;reason=unconditional;privacy=full;counter=1
Content-Length:  233
Content-Type: application/sdp
Content-Disposition: session;handling=required

http://r00ssyp.blogspot.com/2016/02/div ... erisk.html

[gaspaarr]

Любопытно, SIP.TG предлагают бесплатный форвард звонков (бесплатная альтернатива роумингу), для этого нужно сделать переадресацию на один из их номеров, в списке один номер на город, значит все указывают один и тот же, следовательно Diversion массово поддерживается операторами моб. связи (раз нет оговорок в тексте).

[ded]

Операторы моб. связи обязаны стыковаться и стыкуются по протоколу ОКС-7 (SS7), где поле Divert явяется штатным.
Передача этих и других специфических полей, ISUP messages, в базовый протокол SIP не предусматривалась, поэтому были разработаны две дублирующие друг-друга модификаций - SIP-T и SIP-I
https://ru.wikipedia.org/wiki/%D0%9F%D1 ... 0%B8_SIP-I
Поэтому, если SIP.TG поключен как оператор связи, они всё получают и всё могут передавать.

[gaspaarr]

Поле Diversion, в теории, не имеет ограничений? Т.е. весь каскад переадресаций должен там отображаться?

[ded]

Не факт. Новый RFC 6044 вступил в силу относительно недавно, в 2015 году, заменив собой устаревший RFC 4244 (History-Info header), вряд ли разработчики учли это в новом софте для всех софтсвичей, и операторы связи у себя его обновили.

Код: Выделить всё

3.2.  Diversion Header Syntax

   The following text is restating the exact syntax that the production
   rules in [RFC5806] define, but using [RFC5234] ABNF:

    Diversion = "Diversion" HCOLON diversion-params
                                 *(COMMA diversion-params)

    diversion-params    = name-addr *(SEMI (diversion-reason /
                          diversion-counter / diversion-limit /
                          diversion-privacy / diversion-screen /
                          diversion-extension))
    diversion-reason    = "reason" EQUAL ("unknown" / "user-busy" /
                          "no-answer" / "unavailable" / "unconditional"
                          / "time-of-day" / "do-not-disturb" /
                          "deflection" / "follow-me" / "out-of-service"
                          / "away" / token / quoted-string)
    diversion-counter   = "counter" EQUAL 1*2DIGIT
    diversion-limit     = "limit" EQUAL 1*2DIGIT
    diversion-privacy   = "privacy" EQUAL ("full" / "name" / "uri" /
                          "off" / token / quoted-string)
    diversion-screen    = "screen" EQUAL ("yes" / "no" / token /
                          quoted-string)
    diversion-extension = token [EQUAL (token / quoted-string)]

   Note: The Diversion header could be used in the comma-separated
   format, as described below, and in a header-separated format.  Both
   formats could be combined a received INVITE as recommended in
   [RFC3261].

   Example:

   Diversion:

   diverting_user2_addr; reason="user-busy"; counter=1; privacy=full,
   diverting_user1_addr; reason="unconditional"; counter=1; privacy=off

https://datatracker.ietf.org/doc/html/rfc6044

[lipun]

https://git.zhirov.kz/forks/tg2sip не знаю починили или нет. Только наткнулся