Поведение Asterisk при transport=tcp

[debauchery]

Здравствуйте, уважаемые форумчане! Давно читаю этот форум, но не было необходимости регистрироваться. "Книгу" читал). Прошу помочь разобраться в интересной ситуации с поведением Asterisk при изменении вида транспорта с UDP на TCP. Входные данные:
OS: Ubuntu 20.04.4 LTS
Asterisk 16.2.1
Оператор SIP - Мегафон(Мультифон)

Конфиги простейшие:
SIP.CONF

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

[general]
tcpenable=yes
srvlookup=yes
useragent=XXXX Asterisk
register => 8999LOGIN:PASSWORD@NAME.megapbx.ru
language=ru

[megafon8999]
username=8999LOGIN
secret=PASSWORD
host=NAME.megapbx.ru
type=peer
qualify=yes
context=IN_Megafon
fromdomain=NAME.megapbx.ru
fromuser=8999LOGIN
disallow=all
allow=alaw
allow=ulaw
insecure=port,invite
dtmfmode=inband
nat=force_rport, comedia
maxexpiry=180
;transport=tcp

[sklad](!)
type=friend
qualify=yes
host=dynamic
context=local

#include "/etc/asterisk/sklad/ipphone.ael"

extensions.conf
[general]
[global]
[local]
----опустим-----
[IN_Megafon]
exten => s, 1, Answer()
exten => s, n, NoOp()
exten => s, n, Background(/var/lib/asterisk/sounds/custom/CallNumber)
exten => s, n, WaitExten(10)
------далее несущественно-------

При данной конфигурации, как видно, закомментирован transport=tcp, и всё работает так как надо - исходящий звонок с IP-трубки происходит, входящий на сотовый номер Мультифона попадает в необходимый экстеншн IN_Megafon -> s.
Но, настраивая по рекомендации с сайта https://multifon.megafon.ru/config/?type=АТС&id=8 пытаюсь включить TCP, пытаясь решить проблему с отвалами от провайдера(но это тема для другого топика) я, при раскомментировании transport=tcp получаю странную проблему, которую не могу понять и решить, а именно что

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

> 0x7f1180039a70 -- Strict RTP learning after remote address set to: 193.201.230.144:37784
[Aug 17 00:04:51] NOTICE[95874][C-00000007]: chan_sip.c:26695 handle_request_invite: Call from '' (193.201.230.178:5060) to extension 's' rejected because extension not found in context 'default'.

Хотя - я пытался указывать экстеншн в строке регистрации через / используя различные варианты = s, 7999ХХХХХХХ, IN_Megafon...вижу в SNGREP что пакет регистрации улетел в Мультифон, после на входящем передается нужный экстеншн, но

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

 > 0x7f11800373c0 -- Strict RTP learning after remote address set to: 193.201.230.150:45084
[Aug 17 00:02:44] NOTICE[95874][C-00000006]: chan_sip.c:26695 handle_request_invite: Call from '' (193.201.230.178:5060) to extension 's' rejected because extension not found in context 'default'.

или

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

 > 0x7f62380bf6a0 -- Strict RTP learning after remote address set to: 193.201.230.150:49864
[Aug 16 22:45:49] NOTICE[1922][C-0000005e]: chan_sip.c:26695 handle_request_invite: Call from '' (193.201.230.178:5060) to extension 'IN_Megafon' rejected because extension not found in context 'default'.

Борясь с этим я удалил на всякий случай дефолтные файлы в директории которые создают экстеншены из LUA, вывод dialplan show показывает что по-факту у меня два диалплана - local и IN_Megafon. Никакого default он не видит. Но упорно пытается туда запихать звонок. Я изучил вывод SNGREP и tcp\udpdump - ничего подозрительного, ничем не отличается, никаких изменяющихся параметров...
перезапускал сервис, перезагружал ОС - без толку. При закомментировании TCP - все становится работоспособным. Почитал всякие форумы\гуглы, не вижу такого чтобы это влияло как то на маршрутизацию звонка, ведь это транспорт, он "ниже" АТС. Подскажите, может есть неочевидные для меня моменты?

[ded]

1) приведите здесь свой контекст IN_Megafon -

2) пробуйnе добавить на пире параметр
defaultuser=7999ХХХХХХХ

3)
register => 8999LOGIN:PASSWORD@NAME.megapbx.ru/7999ХХХХХХХ

[debauchery]

1) Он примитивен

[IN_Megafon]
;Звонок на склад по внешней линии
;Берем трубку, таймаут
;Устанавливаем уведомление что абонент внешний
;Проигрываем ему "Привет", ждем цифрового ответа
;Если более 2х символов - играем неверный номер и сброс
;Если номер с 1 или 2 и другие цифры то включаем запись и отправляем в набор.
;Если не набрали - играем отбойник и сброс.

exten => s, 1, Answer()
exten => s, n, NoOp()
;exten => s, n, Set(CALLERID(name)=Внешний абонент)
exten => s, n, Background(/var/lib/asterisk/sounds/custom/CallNumber)
exten => s, n, WaitExten(10)
exten => _63XX., n, Playback(BadNumber)
exten => _63[1-9]X, 1, MixMonitor(/call/incall_8999/${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}_${CALLERID(num)}_${CALLERID(dnid)}.wav)
exten => _63[1-9]X, n, Dial(SIP/${EXTEN})

exten => t, 1, Playback(/var/lib/asterisk/sounds/custom/NoCall)
exten => t, n, Hangup()

exten => i, 1, Playback(/var/lib/asterisk/sounds/custom/Bad)
exten => i, n, Hangup()


2) Я так понимаю что в описании - Peer этот параметр влияет на то, как я представляюсь на исходящих, но на входящие он не влияет? Только в случае friend? Но, я пробовал данный вариант - не помогло.

3) пробовал, поведение при этом такое же

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

      > 0x7fe6e801b250 -- Strict RTP learning after remote address set to: 193.201.230.150:31434
[Aug 16 23:19:25] NOTICE[93540][C-00000001]: chan_sip.c:26695 handle_request_invite: Call from '' (193.201.230.178:5060) to extension '79384238999' rejected because extension not found in context 'default'.

меня смущают эти кавычки одинарные, не нашел пояснения почему так происходит в логе если в пакете FROM - данные есть.

[ded]

Call from '' (193.201.230.178:5060) - это from Unknown peer.
То, что у вас фигурирует как host=NAME.megapbx.ru не резольвится в 193.201.230.178, поэтому входящий не ассоциируется с указанным пиром и не попадает в указанный контекст. Попробуйте

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

[megafon8999]
type=peer (это принципиально)
username=8999LOGIN
secret=PASSWORD
host=193.201.230.178
; qualify=yes - не надо вам Мегафон квалифаить, он надёжнее, чем ваш узел.
context=IN_Megafon
insecure=invite

И контекст лучше с номером, а не s

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

[IN_Megafon]
exten => 79384238999,1,Answer()
exten => 79384238999,n,NoOp(=Внешний абонент=)
exten => 79384238999,n,Background(custom/CallNumber)
exten => 79384238999,n,WaitExten(10)
exten => _63XX.,n,Playback(BadNumber)
exten => _63[1-9]X,1,MixMonitor(/call/incall_8999/${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}_${CALLERID(num)}_${CALLERID(dnid)}.wav)
exten => _63[1-9]X,n,Dial(SIP/${EXTEN})
exten => t,1,Playback(/var/lib/asterisk/sounds/custom/NoCall)
exten => t,n,Hangup()
exten => i,1,Playback(/var/lib/asterisk/sounds/custom/Bad)
exten => i,n,Hangup()

[debauchery]

Сделал как Вы написали, все, конечно же, работает. Но при смене transport=tcp, опять те же грабли

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

   > 0x7f9fb804b9b0 -- Strict RTP learning after remote address set to: 193.201.230.172:44142
[Aug 18 08:48:34] NOTICE[128615][C-00000067]: chan_sip.c:26695 handle_request_invite: Call from '' (193.201.230.178:5060) to extension '7938ХХХХХХХ rejected because extension not found in context 'default'.

Не понимаю, откуда берется контекст default ведь его нет в диалплане?
Имя хоста, кстати, разрешается, это первое что делаю на свежей ОС - DNS настраиваю. На всякий случай тоже проверил.

случайно "спалил" номер выше, копипастил - поспешил)

[ded]

входящий не ассоциируется с указанным пиром и попадает в дефолтный контекст.

# asterisk -rx 'sip show settings' | grep Context
Context: default

host=193.201.230.178

RTP learning after remote address set to: 193.201.230.172:44142

[Zavr2008]

allowguest=yes ?
Если так, то если по каким то причинам во входящем инвайте искажаются данные отправителя (NAT или еще что), то звонок прилетает в default.
Обычно allowguest=no ставят по причинам фрода.

[debauchery]

ded, Ваш пост мне очень сильно помог про # asterisk -rx 'sip show settings' | grep Context, в совокупности с комментарием Zavr2008 натолкнуло на мысли и я проверил - запретив гостевые звонки действительно перестало работать, астериск за NAT, возможно действительно какая-то сетевая ерунда...
Но, решил всё следующим способом, так как у меня такой оператор(Мультифон) один, то я в конфиге sip.conf в секции
[general] добавил context=IN_Megafon переопределив дефолтный маршрут. Звонки стали прилетать, но, возможно, не самый изящный способ.
Далее, разобрался с TCP - добавив в секцию настроек оператора transport=tcp и поменяв строку регистрации на
register => tcp://8999LOGIN:PASSWORD@NAME.megapbx.ru/7938XXXXXXX
Это привело к тому что пир стал в состояние Unmonitored. Но звонки работали исправно, пришлось вернуть в конфиг qualify=yes. Теперь пир опрашивается и ОК.
Это заставило исходящие и входящие звонки действительно ходить по TCP, что видно в заголовке пакета в поле VIA. Более того, кажется нормально заработала перерегистрация, в поле пакета Expires: 120 и действительно каждые две минуты он регистрируется и получает ОК от Мультифона, возможно это решит мою проблему с отвалами с которой вся суета и началась.
Спасибо за участие, товарищи!

[ded]

Не надо бояться состояния Unmonitored. Это просто мы его не мониторим, он ведь надёжней, чем мы? Это ему бы надо нас мониторить, а не наоборот. Звонки всё равно будут ходить.
Вот если было бы состояние Unreacheable - вот это проблема была бы.

[Zavr2008]

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

register_retry_403=yes

Советую добавить в general, мультифон бывает чудит - это чтобы No authentication в sip show registry не вылезало.