* не может зарегистироваться после перезагрузки роутера

[gaspaarr]

если выхожу из консоли астериска в cli, и делаю ping hostname.ru, все работает, и резолв и ответы на пинг

[Vlad1983]

может есть peer с пустым host

[ded]

А я не выхожу из консоли Астериск! Зачем? И делаю
CLI> ! dig http://www.ru
CLI> ! dig peername.provider.biz
чтобы увидеть сколько милисекунд занимает запрос-ответ. Это может тупить даже модуль dnsmgr в самом Астериске.
Попробуйте указать пир провайдера и регистрацию на него в виде ИП адреса а не FQDN.

[gaspaarr]

Вот опять отловил глюк, в sip show registry показывает все транки как зарегистрированные (для одного из них даже есть открытое соединение в НАТ таблице роутера)

Host dnsmgr Username Refresh State Reg.Time
sipnet.ru:5060 N XXX 104 Registered Sat, 06 Dec 2014 18:17:31
qwerty.cnt.ru:5060 N XXX 345 Registered Sat, 06 Dec 2014 18:17:01

localhost*CLI> sip set debug peer BAZA
Unable to get IP address of peer 'BAZA'

localhost*CLI> sip set debug peer SIPNET
Unable to get IP address of peer 'SIPNET'

localhost*CLI> ! dig qwerty.cnt.ru

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> qwerty.cnt.ru
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9965
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;qwerty.cnt.ru. IN A

;; ANSWER SECTION:
qwerty.cnt.ru. 18955 IN A 213.85.168.52

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Dec 6 18:19:09 2014
;; MSG SIZE rcvd: 47

localhost*CLI> ! dig sipnet.ru

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> sipnet.ru
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10283
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sipnet.ru. IN A

;; ANSWER SECTION:
sipnet.ru. 18657 IN A 212.53.40.40

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Dec 6 19:06:03 2014
;; MSG SIZE rcvd: 43

При входящих соответственно получаю:
chan_sip.c:25418 handle_request_invite: Failed to authenticate device

Т.е. по факту никакой регистрации к транкам у него нет, то что указано в sip show registry не соответствует действительности.

В то же время я вижу на роутере, что к одному из транков он регулярно шлет qualify запросы, тут значит никаких проблем с резолвом IP адреса у него нет, а как дело доходит до дебага или регистрации -- значит есть?

[ded]

http://lists.digium.com/pipermail/aster ... 68999.html
http://bit.ly/1G2YpgQ

При входящих соответственно получаю:
chan_sip.c:25418 handle_request_invite: Failed to authenticate device

Это из другой оперы. Укажите на пире insecure=invite

[gaspaarr]

Обижаете, разумеется на всех пирах-транках указан invite

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

type=peer
secret=...
nat=yes
insecure=invite
host=sipnet.ru
fromdomain=sipnet.ru
dtmfmode=rfc2833
disallow=all
directmedia=no
defaultuser=...
context=from-trunk
allow=alaw&ulaw&g729
fromuser=...
canreinvite=no

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

[ded]

CLI> core set verbose 10
CLI> core set debug 10

статус registered получен после первого запроса, и будет оставаться таким в течение действия таймера register expire.

Предположу, что в момент регистрации резольвер дал ИП адрес sipnet.ru = 212.53.40.40, статус установился в Registered, потом запись
sipnet.ru по каким-то причинам перестала резольвиться (но статус не меняется, это независимый процесс). У вас резольвер то локальный - 127.0.0.1? Может он козлит?

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

Asterisk config dnsmgr.conf
This file is used to configure whether Asterisk should perform DNS lookups on a regular basis, and how often those lookups should be performed.

Syntax of the config file is as follows:

[general]
enable=yes             ; enable creation of managed DNS lookups
                       
refreshinterval=1200   ; refresh managed DNS lookups every <n> seconds
                        ;   default is 300 (5 minutes)

пробуте с ним поиграться?

А видеть пакеты регистрации в простой картине можно через
tcpdump host 212.53.40.40 and port 5060 -s0 -A
или в Астериске
CLI> sip set debug ip 212.53.40.40

Когда
chan_sip.c:25418 handle_request_invite: Failed to authenticate device
при входящем будет пакет invite, вот его тоже посмотрите как вверху указано.

[gaspaarr]

Новый выкидыш...

NOTICE[2424]: chan_sip.c:15289 transmit_register: Strange, trying to register 20002@tel.moscow.rt.ru when registration already pending

И все, sip reload не помогает, дебагом соответственно даже не вижу попыток зарегистрироваться...

На роутере активных NAT сессий тоже нет. Если включить qulify то он отлично проходит и ответы на него идут, а вот с регистрацией болт, она ведь pending...

Притом:
24 Request Sent Sun, 14 Dec 2014 20:11:06
24 Request Sent Tue, 23 Dec 2014 11:21:24

Пробовал прописать host=ip, ничего не изменилось

После core restart gracefully регистрация прошла. Outbound Registration: Expiry for tel.moscow.rt.ru is 30 sec

Если на роутере режу доступ к IP адресу пира, то в консоли вижу:

Retransmitting #1...7 (NAT)

Видимо с какого-то момента он перестает делать попытки зарегистрироваться, даже не смотря на то, что registerattempts=0?

[TVMaker]

У меня иногда вылазит такая же фигня с "already pending". Как правило, на транке мультифона. Складывается такое ощущение, что "зависон" на стороне провайдера, ибо иногда даже перезагрузка астера не помогает. А иногда само проходит Поскольку астер у меня домашний, то нет ничего страшного перезагрузить саму машину плюс роутер на всякий случай - как правило, помогает

[gaspaarr]

Разобрался, в чем проблема...

Если во время того, как идут попытки перерегистрации сделать sip reload, то после этого получаем указанный глюк. Т.е. больше он не пытается перерегистрироваться...

Вот тут что-то похожее https://reviewboard.asterisk.org/r/2171/diff/ (но 11 ветка, а не 13 и 2 года назад):
While working on a patch submitted by Kirill Katsnelson, I failed to notice that I introduced a somewhat breaking change against SIP reloads where the registry would be pruned and couldn't be brought back without either restarting Asterisk or fully unloading and reloading the chan_sip module. The problem occured when I moved the peer destruction marker callback to below the general section, at the time not having considered that peers could be created within the general section.

Еще: https://issues.asterisk.org/jira/browse/ASTERISK-20611