SIP reload takes some time and not responding

Asterisk Asterisk SIP
1

I’m new to Asterisk. would like to check if there is any way to speed up the reload process.
A server has been set up and running Asterisk 14 with static realtime for SIP (not dynamic realtime). There are over 50k dynamic peers in the db. It is a mysql db. When we run “sip reload”, it takes some time and during that period, registered peers can’t make call and those originally connected peer can’t register again until reload done. Is this normal?

Enabled debug during sip reload, it kept writing below debug log for different peers.
[2018-01-16 03:28:09] DEBUG[128]: db.c:376 db_get_common: Unable to find key ‘2000001’ in family ‘SIP/Registry’
[2018-01-16 03:28:09] DEBUG[128]: chan_sip.c:31809 build_peer: Not an IPv4 nor IPv6 address, cannot set port.
[2018-01-16 03:28:09] DEBUG[128]: chan_sip.c:31814 build_peer: Not an IPv4 nor IPv6 address, cannot get port.
[2018-01-16 03:28:09] DEBUG[128]: chan_sip.c:31817 build_peer: Not an IPv4 nor IPv6 address, cannot set port.
[2018-01-16 03:28:09] DEBUG[128]: chan_sip.c:31819 build_peer: Not an IPv4 nor IPv6 address, cannot get port.
[2018-01-16 03:28:09] DEBUG[128]: chan_sip.c:31822 build_peer: Not an IPv4 nor IPv6 address, cannot set port.

below is the db value of that peer.
|id|cat_metric|var_metric|commented|filename|category|var_name|var_val|
|583636|837967|0|0|sip.conf|20000001|deny|0.0.0.0/0.0.0.0|
|583637|837967|1|0|sip.conf|20000001|permit|0.0.0.0/0.0.0.0|
|583638|837967|2|0|sip.conf|20000001|host|dynamic|
|583639|837967|3|0|sip.conf|20000001|type|friend|
|583640|837967|4|0|sip.conf|20000001|defaultuser|20000001|
|583641|837967|5|0|sip.conf|20000001|dtmfmode|rfc2833|
|583642|837967|6|0|sip.conf|20000001|trustpid|yes|
|583643|837967|7|0|sip.conf|20000001|sendpid|pai|
|583644|837967|8|0|sip.conf|20000001|nat|force_rport,comedia|
|583645|837967|9|0|sip.conf|20000001|port|5060|
|583646|837967|10|0|sip.conf|20000001|qualify|5000|
|583647|837967|11|0|sip.conf|20000001|qualifyfreq|60|
|583648|837967|12|0|sip.conf|20000001|transport|udp,tcp|
|583649|837967|13|0|sip.conf|20000001|avpf|no|
|583650|837967|14|0|sip.conf|20000001|force_avp|no|
|583651|837967|15|0|sip.conf|20000001|session-timers|accept|
|583652|837967|16|0|sip.conf|20000001|icesupport|no|
|583653|837967|17|0|sip.conf|20000001|encryption|no|
|583654|837967|18|0|sip.conf|20000001|dial|SIP/20000001|
|583655|837967|19|0|sip.conf|20000001|secret|Secret|
|583656|837967|20|0|sip.conf|20000001|context|Testing|

Kindly advise. Thank you in advance

2

The chan_sip module does reloads in the same thread that handles network traffic, so reloads do block that activity. If for some reason it takes awhile (such as having to resolve an address and it taking a long time) then you’d see what you are seeing.

3

Thanks for your response. Is there any way to make chan_sip to reload in another thread so that it won’t block the activity?

4

It is written that way, the repercussions of changing that in code are unknown.

5

Moreover, as you can see that we are using dynamic host, it should not need to resolve the address?

6

That was one of the reasons that it could block. The act of processing that many SIP peers will also cause it to block for some time and as qualify is enabled that can also take time as it handles that. It all adds up.

7

since we will add/drop extension dynamically, possibly 4,5 times a day. Multiple reloads will affect the services. Do you have any suggestion? dynamic realtime SIP peers? Due to we have a large number of peers, wondered it will query the database a lot and causing other issue.

8

Historically, one of Asterisk’s big problems has been crashes due to failing to get he locking logic wrong. I would say that locking out other SIP processing whilst rebuilding the configuration is the only really sensible way of managing that risk.

9

There’s other ways - which chan_pjsip uses and the new core data layer. Things are immutable so you don’t have to lock them to protect access, and the act of reloading creates new ones which only replace the current set once all processed and ready. In practice it works well.

10

You are in uncharted territory so I don’t really have advice. 50k dynamic peers is very much outside of what normal people do.

11

Do you mean migrating to PJSIP helps to reduce or eliminate the reload time?
I checked that there is no PJSIP reload and the cli_aliases for PJSIP reload is to reload the PJSIP related modules. will it stop service while reload?

12

I was responding to David. The PJSIP implementation took a different approach which does not suffer the same blocking problem that chan_sip does. If qualify is enabled it can still take awhile, but that problem is being worked on.

13

From a voip consultant we were told that ordinary server hardware should run up to 5000 peers. We have some more than 1000 peers and so far reload took about a second. I am not really an asterisk expert but I would not expect asterisk to be the right platform for your amount of peers.