为什么按星号不推荐动态实时? [英] Why is dynamic real time not recommended as per asterisk?

问题描述

在 extconfig.conf 中他们提到了

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) 为什么星号不推荐动态实时扩展?2) 如何使用liek 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?

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

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

推荐答案

动态实时存在一些问题

最重要的问题是拨号方案.

Most important issue is dialplan.

当/如果您使用完全号码匹配等精确拨号方案 - 它工作正常.但是当您使用模式时，它会在上下文中搜索模式.为此，每次访问拨号计划时，它都会从 db 请求此上下文中的所有记录.这真的很糟糕，但没有简单的方法可以解决它.例如，您的模式 _011 有 10 行的拨号方案.和同一个拨号方案中的其他模式/号码，总行数 1000.您拨打 011123456788，它请求优先级 1 行(db 做 1000 行检查)，然后是优先级 2(db 做 1000 行检查).因此，每次新调用都会得到 10x1000=10000 db 行.

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.

如果你想要高负载的动态拨号计划，使用 db config storage(对于拨号计划更改，例如每 10 分钟重新加载一次)并使用 func_odbc 检查扩展/拨号计划的功能.这样你就可以更好地控制 sql 查询.当然，这需要您了解 mysql 并能够构建查询，但对于具有超过 10-20 次调用的任何动态 pbx 没有其他方法.

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 实时是另一回事.它存在启用对等更新的 db update 问题，或者如果启用缓存则不更新对等信息.你只是忍受了.

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屋！