2016-07-14 2 views
2

В extconfig.conf они упоминали, чтоПочему динамическое реальное время не рекомендуется в соответствии со звездочкой?

"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) Почему звездочка не рекомендует динамических расширений в реальном времени? 2) Как сделать статический диалплан с абстракцией данных с помощью инструмента liek func_odbc?

Мое требование имея больше расширений (в данном случае номер мобильного) идет вверх, как я могу динамически добавлять их в sip.conf и зарегистрируйте его на сервер SIP

+0

Проверьте эту ссылку: http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/getting_funky.html – os11k

+0

@ os11k Спасибо, что ответили. Эта ссылка http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/installing_configuring_odbc.html говорит в res_odbc.conf, [звездочка] включена => да DSN => Звездочка разъем username => asterisk password => welcome pooling => no limit => 1 pre-connect => yes, Полезные советы по пули и ограничениям помогают нам получить несколько соединений от db (до указанного предела). Поэтому я должен изменить лимит на 1 миллион, а не на «1», так что у меня будет больше множественных соединений. Разве это не сделает мою базу данных более масштабируемой? –

ответ

2

Есть некоторые проблемы с динамическим в реальное время

Важнейшей проблемой является dialplan.

Когда/если вы используете ТОЧНЫЙ диалплан, как полный номер матча - он работает нормально. Но когда вы используете шаблон, он ищет шаблон в контексте. Для этого он запрашивает все записи в этом контексте из db КАЖДЫЙ раз, когда вы получаете доступ к dialplan. Это действительно плохо, но нелегко это исправить. Например, у вас есть диалплан из 10 строк для шаблона _011. и enother pattern/numbers в том же диалплане, избыточное число строк 1000. Вы вызываете 011123456788, он запрашивает приоритет 1 строки (db выполняет проверку 1000 строк), после этого приоритета 2 (db выполняет проверку 1000 строк). Таким образом, вы получили 10x1000 = 10000 бит строк для КАЖДОГО нового вызова.

Если вы хотите динамический диалплан с hi-load, используйте хранилище конфигурации db (для изменения диалплана, перезагружайте его, например, один раз каждые 10 минут) и проверьте расширение/dialplan для функций с помощью func_odbc. Таким образом, у вас гораздо больше контроля над sql-запросом. Уверенный, что вы должны понимать mysql и способные строить запросы, но нет другого способа для любого динамического pbx с более чем 10-20 вызовами.

sippeers реальное время - это другая вещь. У него есть проблемы с обновлением db с включенным одноранговым обновлением или не обновлять информацию о свертке, если включен кеш. Ты просто живешь с этим.

Смежные вопросы