Igor Pavlov
2015-Feb-16 11:49 UTC
[asterisk-users] Asterisk 11.6. SIP realtime lost peers after 'sip reload'
Hi, list. We have a problem with loss peers after 'sip reload', our configuration: Asterisk 11.6-cert1, SIP realtime peers, sip.conf: - rtcachefriends=yes - rtsavesysname=yes - rtupdate=yes - rtautoclear=yes When we do 'sip reload' , peers are removing from available. Before `sip reload` : srv-pbx2*CLI> sip show peers Name/username Host Dyn Forcerport ACL Port Status Description Realtime 303411/303411 172.16.1.12 D 5060 OK (77 ms) Cached RT 467577/467577 172.16.1.22 D 5060 OK (141 ms) Cached RT 561871/561871 172.16.1.32 D 5060 OK (7 ms) Cached RT sip-proxy2 172.16.1.2 5061 OK (1 ms) srv-pbx-in 172.16.1.7 5060 OK (1 ms) After `sip reload`: [Feb 16 14:30:20] DEBUG[1468]: res_config_mysql.c:497 realtime_multi_mysql: MySQL RealTime: Retrieve SQL: SELECT * FROM sipusers WHERE name LIKE '%' AND callbackextension LIKE '%' ORDER BY name [Feb 16 14:30:20] DEBUG[1468]: config.c:1650 config_text_file_load: Parsing /etc/asterisk/sip_notify.conf == Parsing '/etc/asterisk/sip_notify.conf': Found [Feb 16 14:30:20] DEBUG[1468]: chan_sip.c:32383 reload_config: SIP reload_config done...Runtime= 0 sec [Feb 16 14:30:20] DEBUG[1468]: sched.c:546 ast_sched_dump: Asterisk Schedule Dump (12 in Q, 623646 Total, 30 Cache, 42 high-water) [Feb 16 14:30:20] DEBUG[1468]: sched.c:551 ast_sched_dump: ============================================================ [Feb 16 14:30:20] DEBUG[1468]: sched.c:552 ast_sched_dump: |ID Callback Data Time (sec:ms) | [Feb 16 14:30:20] DEBUG[1468]: sched.c:553 ast_sched_dump: +-----+-----------------+-----------------+-----------------+ [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623634 | 0x7f2ebc5415d0 | 0x7f2ea0b95b68 | 000001 : 434169 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623628 | 0x7f2ebc5451c0 | 0x7f2ea0bc5148 | 000004 : 912209 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623639 | 0x7f2ebc5415d0 | 0x7f2ea08a0158 | 000021 : 585476 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623635 | 0x7f2ebc5415d0 | 0x7f2ea0b6bc98 | 000011 : 452094 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623632 | 0x7f2ebc5451c0 | 0x7f2ea0b9b388 | 000017 : 091999 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623643 | 0x7f2ebc5451c0 | 0x2d473d8 | 000055 : 803782 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623511 | 0x7f2ebc527410 | 0x7f2ea0b9b388 | 000266 : 237816 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623640 | 0x7f2ebc5415d0 | 0x7f2ea0baf088 | 000022 : 472571 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623541 | 0x7f2ebc527410 | 0x7f2ea0affa28 | 000650 : 207449 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623600 | 0x7f2ebc527410 | 0x7f2ea0bc5148 | 000794 : 895787 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623638 | 0x7f2ebc5451c0 | 0x7f2ea0affa28 | 000040 : 622455 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623646 | 0x7f2ebc5451c0 | 0x2d4cee8 | 000055 : 902262 | [Feb 16 14:30:20] DEBUG[1468]: sched.c:568 ast_sched_dump: ============================================================ [Feb 16 14:30:20] DEBUG[1468]: chan_sip.c:33170 sip_do_reload: --------------- Done destroying pruned peers [Feb 16 14:30:20] DEBUG[1468]: chan_sip.c:33185 sip_do_reload: do_reload finished. peer poke/prune reg contact time = 0 sec. [Feb 16 14:30:20] DEBUG[1468]: chan_sip.c:33187 sip_do_reload: --------------- SIP reload done srv-pbx2*CLI> sip show peers Name/username Host Dyn Forcerport ACL Port Status Description Realtime sip-proxy2 172.16.1.2 5061 OK (1 ms) srv-pbx-in 172.16.1.7 5060 OK (1 ms) 2 sip peers [Monitored: 2 online, 0 offline Unmonitored: 0 online, 0 offline] Is this normal behavior of SIP realtime ? ----- Best regards, Igor Pavlov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20150216/e5e34e58/attachment.html>
Ishfaq Malik
2015-Feb-16 12:36 UTC
[asterisk-users] Asterisk 11.6. SIP realtime lost peers after 'sip reload'
On 16 February 2015 at 11:49, Igor Pavlov <ip at izhnet.ru> wrote:> Hi, list. > > > > We have a problem with loss peers after ?sip reload?, our configuration: > Asterisk 11.6-cert1, SIP realtime peers, sip.conf: > > - rtcachefriends=yes > > - rtsavesysname=yes > > - rtupdate=yes > > - rtautoclear=yes > > > > When we do ?sip reload? , peers are removing from available. > > > > *Before `sip reload` :* > > srv-pbx2*CLI> sip show peers > > Name/username Host Dyn > Forcerport ACL Port Status Description > Realtime > > 303411/303411 172.16.1.12 > D 5060 OK (77 > ms) Cached RT > > 467577/467577 172.16.1.22 > D 5060 OK (141 ms) > Cached RT > > 561871/561871 172.16.1.32 > D 5060 OK (7 ms) > Cached RT > > sip-proxy2 > 172.16.1.2 > 5061 OK (1 ms) > > srv-pbx-in > 172.16.1.7 > 5060 OK (1 ms) > > > > *After `sip reload`:* > > > > [Feb 16 14:30:20] DEBUG[1468]: res_config_mysql.c:497 > realtime_multi_mysql: MySQL RealTime: Retrieve SQL: SELECT * FROM sipusers > WHERE name LIKE '%' AND callbackextension LIKE '%' ORDER BY name > > [Feb 16 14:30:20] DEBUG[1468]: config.c:1650 config_text_file_load: > Parsing /etc/asterisk/sip_notify.conf > > == Parsing '/etc/asterisk/sip_notify.conf': Found > > [Feb 16 14:30:20] DEBUG[1468]: chan_sip.c:32383 reload_config: SIP > reload_config done...Runtime= 0 sec > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:546 ast_sched_dump: Asterisk > Schedule Dump (12 in Q, 623646 Total, 30 Cache, 42 high-water) > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:551 ast_sched_dump: > ============================================================> > [Feb 16 14:30:20] DEBUG[1468]: sched.c:552 ast_sched_dump: |ID > Callback Data Time (sec:ms) | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:553 ast_sched_dump: > +-----+-----------------+-----------------+-----------------+ > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623634 | > 0x7f2ebc5415d0 | 0x7f2ea0b95b68 | 000001 : 434169 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623628 | > 0x7f2ebc5451c0 | 0x7f2ea0bc5148 | 000004 : 912209 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623639 | > 0x7f2ebc5415d0 | 0x7f2ea08a0158 | 000021 : 585476 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623635 | > 0x7f2ebc5415d0 | 0x7f2ea0b6bc98 | 000011 : 452094 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623632 | > 0x7f2ebc5451c0 | 0x7f2ea0b9b388 | 000017 : 091999 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623643 | > 0x7f2ebc5451c0 | 0x2d473d8 | 000055 : 803782 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623511 | > 0x7f2ebc527410 | 0x7f2ea0b9b388 | 000266 : 237816 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623640 | > 0x7f2ebc5415d0 | 0x7f2ea0baf088 | 000022 : 472571 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623541 | > 0x7f2ebc527410 | 0x7f2ea0affa28 | 000650 : 207449 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623600 | > 0x7f2ebc527410 | 0x7f2ea0bc5148 | 000794 : 895787 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623638 | > 0x7f2ebc5451c0 | 0x7f2ea0affa28 | 000040 : 622455 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:565 ast_sched_dump: |623646 | > 0x7f2ebc5451c0 | 0x2d4cee8 | 000055 : 902262 | > > [Feb 16 14:30:20] DEBUG[1468]: sched.c:568 ast_sched_dump: > ============================================================> > [Feb 16 14:30:20] DEBUG[1468]: chan_sip.c:33170 sip_do_reload: > --------------- Done destroying pruned peers > > [Feb 16 14:30:20] DEBUG[1468]: chan_sip.c:33185 sip_do_reload: do_reload > finished. peer poke/prune reg contact time = 0 sec. > > [Feb 16 14:30:20] DEBUG[1468]: chan_sip.c:33187 sip_do_reload: > --------------- SIP reload done > > > > > > srv-pbx2*CLI> sip show peers > > Name/username Host Dyn > Forcerport ACL Port Status Description > Realtime > > sip-proxy2 > 172.16.1.2 5061 OK (1 > ms) > > srv-pbx-in > 172.16.1.7 5060 OK (1 > ms) > > 2 sip peers [Monitored: 2 online, 0 offline Unmonitored: 0 online, 0 > offline] > > > > *Is this normal behavior of SIP realtime ?* > > > > ----- > > Best regards, > > Igor Pavlov > > > > >This will always happen. When using ARA, peers will only go into the realtime cache when one tries to register or be dialled. At that point the settings will be taken from the DB and put into the realtime cache. A SIP reload will clear the realtime cache. One way to mitigate this effect to use 'sip show peer <peername> load'. -- Ishfaq Malik Department: VOIP Support Company: Packnet Limited t: +44 (0)845 004 4994 f: +44 (0)161 660 9825 e: ish at pack-net.co.uk w: http://www.pack-net.co.uk Registered Address: PACKNET LIMITED, Duplex 2, Ducie House 37 Ducie Street Manchester, M1 2JW COMPANY REG NO. 04920552 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20150216/dbe838a6/attachment.html>
Maybe Matching Threads
- Problems with chan_sip
- smbd: PANIC (pid xxxxx): internal error -- ? causes?
- [Bug 1468] New: [netdev] dropping ether type vlan frames drops ICMPv6 type 134
- syslinux.efi pxeboot across multiple subnets
- [Bug 1468] New: sshd does not log failed attempts using key-based authentication only