Нужно проверить баг с переименованием пиров в sip.conf, Asterisk 1.4.24.1
| Код: |
| 102/102 192.168.1.248 D N 27864 UNREACHABLE 101/101 192.168.1.174 D N 26024 OK (101 ms) 125/125 (Unspecified) D N 0 UNKNOWN 199/199 xxx.xxx.xxx.xxx D N 5063 OK (37 ms) alterfon/xxxxxxxx 83.219.240.148 N 5060 UNREACHABLE sipnet/xxxxxxx 212.53.40.40 N 5060 UNREACHABLE 76 sip peers [Monitored: 5 online, 71 offline Unmonitored: 0 online, 0 offline] iris*CLI> iris*CLI> iris*CLI> -- Got SIP response 405 "Method Not Allowed" back from 83.219.240.148 [Jun 4 18:12:44] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_1' is now Reachable. (15ms / 2000ms) [Jun 4 18:12:44] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_2' is now Reachable. (15ms / 2000ms) [Jun 4 18:12:48] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'sipnet' is now Reachable. (15ms / 2000ms) [Jun 4 18:12:48] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'alterfon' is now Reachable. (15ms / 2000ms) iris*CLI> |
Попробуйте воспроизвести.
1. заводишь пару пиров-френдов с qualify... каким-нибудь, или 0
2. sip reload
3. sip show peers
4. переименовываешь пиры в конфиге
2. sip reload и сразу
3. sip show peers
4. должно выскочить.
Позже у меня повлялось:
| Код: |
| -- Got SIP response 405 "Method Not Allowed" back from 83.219.240.148 [Jun 4 18:12:44] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_1' is now Reachable. (15ms / 2000ms) [Jun 4 18:12:44] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_2' is now Reachable. (15ms / 2000ms) [Jun 4 18:12:48] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'sipnet' is now Reachable. (15ms / 2000ms) [Jun 4 18:12:48] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'alterfon' is now Reachable. (15ms / 2000ms) [Jun 4 18:13:48] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer 'trunk_1' is now UNREACHABLE! Last qualify: 15 [Jun 4 18:13:48] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer 'trunk_2' is now UNREACHABLE! Last qualify: 15 [Jun 4 18:13:52] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer 'sipnet' is now UNREACHABLE! Last qualify: 15 [Jun 4 18:13:52] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer 'alterfon' is now UNREACHABLE! Last qualify: 15 [Jun 4 18:14:47] NOTICE[23967]: chan_sip.c:7715 sip_reg_timeout: -- Registration for 'xxxxxxxxxxx@sipnet.ru' timed out, trying again (Attempt #1) -- ast_get_srv: SRV lookup for '_sip._udp.sipnet.ru' mapped to host sipnet.ru, port 5060 [Jun 4 18:15:07] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'sipnet' is now Reachable. (15ms / 2000ms) [Jun 4 18:15:07] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'alterfon' is now Reachable. (15ms / 2000ms) [Jun 4 18:15:11] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_1' is now Reachable. (14ms / 2000ms) [Jun 4 18:15:11] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_2' is now Reachable. (15ms / 2000ms) |
_________________
Человек мира. RHCE + clustering.
_________________
OpenSUSE 11.2 / Asterisk-trunk / Celeron 1100 (512mb) / chan_lcr / Linksys / Aastra 9112i
http://igorg.ru
_________________
Человек мира. RHCE + clustering.
А вообще переводи все что написал в первом сообщении на инглиш и отправляй на issues.asterisk.org
_________________
OpenSUSE 11.2 / Asterisk-trunk / Celeron 1100 (512mb) / chan_lcr / Linksys / Aastra 9112i
http://igorg.ru
_________________
Человек мира. RHCE + clustering.
Анализируя код chan_sip я выяснил что рассылкой OPTIONS пакетов занимается функция sip_poke_peer. Причем один раз попав туда обратного пути уже нет, так как она начинает сама добавлять себя в scheduler для посылки очередного пакета. Например, в случае не прихода ответа от пира вызывается sip_poke_noanswer которая в любом случае планирует запуск sip_poke_peer через фиксированный интервал времени DEFAULT_FREQ_NOTOK. И ей наплевать что пира уже может не существовать, потому что , насколько я понял, они делают reference на пир и сами его хранят. Так что даже если chan_sip уберет пир из своего списка, то sip_poke_peer все равно будет хранить эту ссылку в scheduler.
Скорее всего разработчики где то пропустили очистку scheduler'а при перезагрузке или удалении пиров.
Дмитрий
Added after 2 hours 25 minutes:
ddv, thanks
_________________
Человек мира. RHCE + clustering.
AST_SCHED_DEL(sched, reg->expire);
добавить
AST_SCHED_DEL(sched, reg->pokeexpire);
По идее это должно отменить вызов следующего sip_poke_peer при удалении пира из sip registry.
Дмитрий