2

In extconfig.conf they have mentioned that 

 "However, note that using dynamic realtime extensions is not recommended anymore as a best practice; instead, you should consider writing a static dialplan with proper data abstraction via a tool like func_odbc."

1) Why asterisk is not recommending dynamic realtime extensions? 2) How to do static dialplan with data abstraction using tool liek func_odbc?

My requirement is having have more extensions (in this case mobile number) coming up, how can I dynamically add them to sip.conf and get it registered to the SIP server

  • Check this one link: http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/getting_funky.html – os11k Jul 15 '16 at 06:29
  • @os11k Thanks for answering. This link http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/installing_configuring_odbc.html says in res_odbc.conf, [asterisk] enabled => yes dsn => asterisk-connector username => asterisk password => welcome pooling => no limit => 1 pre-connect => yes, pooling and limit options are useful and helps us to get multiple connections from db (upto mentioned limit). So shall I change limit to 1 million rather than '1', so that I have more multiple connections. Won't it make my database more scalable? –  Jul 17 '16 at 01:30

1 Answers1

2

There are some issues with dynamic realtime

Most important issue is dialplan.

When/if you use EXACT dialplan like full number match - it work ok. But when you use pattern, it search for pattern in context. To do that it request all records in this context from db EVERY time when you access dialplan. That is really bad, but no easy way fix it. For example you have dialplan of 10 lines for pattern _011. and enother patterns/numbers in same dialplan, overal number of lines 1000. You call 011123456788, it request priority 1 line(db do 1000 rows check), after that priority 2(db do 1000 rows check). So you got 10x1000=10000 db rows for EVERY new call.

If you want dynamic dialplan with hi-load, use db config storage (for dialplan change,reload it for example once every 10 minutes) and check in extension/dialplan for features using func_odbc. That way you have much more control over sql query. Sure that require you understand mysql and able build queries, but no other way for any dynamic pbx with more then 10-20 calls.

sippeers realtime is other thing. It have issues with db update with enabled peer update, or not update peer info if cache enabled. You just have live with that.

arheops
  • 15,544
  • 1
  • 21
  • 27