asterisk.ru

Здравствуйте, уважаемые форумчане! Давно читаю этот форум, но не было необходимости регистрироваться. "Книгу" читал). Прошу помочь разобраться в интересной ситуации с поведением 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 - все становится работоспособным. Почитал всякие форумы\гуглы, не вижу такого чтобы это влияло как то на маршрутизацию звонка, ведь это транспорт, он "ниже" АТС. Подскажите, может есть неочевидные для меня моменты?

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

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

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

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 - данные есть.

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()

Сделал как Вы написали, все, конечно же, работает. Но при смене 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 настраиваю. На всякий случай тоже проверил.

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

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

# 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

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

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 и действительно каждые две минуты он регистрируется и получает ОК от Мультифона, возможно это решит мою проблему с отвалами с которой вся суета и началась.
Спасибо за участие, товарищи!

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

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

register_retry_403=yes

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

asterisk.ru

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

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

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

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

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

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

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

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

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

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

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