VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
ip at izhnet.ru
Guest
|
 Posted: Mon Feb 16, 2015 6:50 am Post subject: [asterisk-users] Asterisk 11.6. SIP realtime lost peers afte |
 |
|
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 |
|
| Back to top |
|
 |
ish at pack-net.co.uk
Guest
|
| Posted: Mon Feb 16, 2015 7:36 am Post subject: [asterisk-users] Asterisk 11.6. SIP realtime lost peers afte |
|
|
On 16 February 2015 at 11:49, Igor Pavlov <ip@izhnet.ru (ip@izhnet.ru)> wrote:
| Quote: |
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'.
--
| Quote: | Ishfaq Malik
Department: VOIP Support
Company: Packnet Limited
t: +44 (0)845 004 4994
f: +44 (0)161 660 9825
e: ish@pack-net.co.uk (ish@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
|
|
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
