为什么不建议根据星号进行动态实时? [英] Why is dynamic real time not recommended as per asterisk?

问题描述

在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进行带有数据抽象的静态Dialplan?

我的要求是要有更多的扩展名(在这种情况下为手机号码)，我如何动态地将其添加到sip.conf并将其注册到SIP服务器上

解决方案

动态实时存在一些问题

最重要的问题是拨号计划.

当/如果您使用完全数字匹配之类的EXACT拨号计划，则可以正常工作.但是，当您使用模式时，它将在上下文中搜索模式.为此，它每次访问Dialplan时都会从db请求此上下文中的所有记录.那真的很糟糕，但是没有简单的方法可以解决它.例如，对于模式_011，您有10行拨号计划.以及同一拨号计划中的其他模式/数字，总行数为1000.您呼叫011123456788，它要求优先级1行(db执行1000行检查)，之后要求优先级2(db执行1000行检查).因此，每个新呼叫都有10x1000 = 10000 db行.

如果要通过动态加载进行动态拨号计划，请使用db config存储(用于更改拨号计划，例如每10分钟重新加载一次)，然后使用func_odbc在扩展名/拨号计划中签入功能.这样，您就可以更好地控制sql查询.当然，这要求您了解mysql并能够构建查询，但是对于具有超过10到20个调用的任何动态pbx，没有其他方法.

sippeers实时是另一回事.在启用对等更新的情况下，数据库更新存在问题；如果启用了缓存，则不更新对等信息.你只是活着了.

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

解决方案

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.

这篇关于为什么不建议根据星号进行动态实时?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！