使用C＃和Aster.NET可靠地识别和跟踪Asterisk调用 [英] Reliably identifying and tracking Asterisk calls using C# and Aster.NET
问题描述
我一直在用，使用Aster.NET（从Asterisk.NET原/分支）与Asterisk接口C＃建立一个WinForms桌面应用程序。我们遇到了真正的麻烦可靠地识别和追踪涉及一个个人分机/呼叫用户。
I have been building a WinForms desktop application using C# that interfaces with Asterisk using Aster.NET (formerly/forked from Asterisk.NET). We're having real trouble reliably identifying and tracking calls that are related to an individual extension/user.
我们遇到的问题是由于不可预测/模糊性中/触发的事件被触发的Asterisk，和他们在一起的大型可变具体取决于它击中分机号之前的呼叫路由。
The problem we're having is due to the unpredictable/fuzzy nature of the events fired/triggered by Asterisk, with them being massively variable depending on how the call is routed before it hits an extension.
例如，事件顺序/格式是不同的，当：通话命中让盲人转移之前IVR;如果呼叫击中IVR之前，出席转移;如果呼叫直接进入到用户的扩展。
For example, the event sequence/format is different when: a call hits an IVR before getting blind transferred; if a call hits an IVR before it is attended transferred; if a call goes direct to the user's extension.
这进一步通过该星号跟踪使用不同的唯一ID（呼叫的每一侧的方式阻碍例如呼叫的入射侧具有不同的UID比所接收到的呼叫侧）。虽然我们已经成功地考虑，在（后来丑陋！）代码，我们仍然击中会计为不同的路由路径呼叫可以采取的问题。
This is further hampered by the way that Asterisk tracks each side of the call using a different Unique ID (e.g. the incoming side of the call has a different UID than the received side of the call). Whilst we've managed to account for that in the (subsequently ugly!) code, we're still hitting issues with accounting for the different routing paths the call can take.
因此，我正在寻找任何建议对我们如何才能做到以下几点：
As such, I'm looking for any advice on how we can do the following:
- 可靠地识别来电到用户的扩展
- 我们需要能够识别被称为扩展和主叫方ID（来自外部或者是盲人或参加转移和直接呼叫后）
- 可靠地跟踪的唯一ID的来电，因为它是用来连接通话录音
- 访问具有相同告诫如上记
由于它矗立在我们分有不同操作依赖于应用程序的当前状态事件处理的一个极其复杂的链条。
As it stands at the minute we have an extremely complex chain of event handlers that operate differently dependent on the 'current state' of the app.
要举一个例子：如果我们检测NewStateEvent为6（上）一ChannelState，我们检查，如果在过程中接听来电的和的是，比赛的UID，如果是这样，那么当前呼叫已被应答。如果的UID不匹配，但也有其他因素（如渠道，connectedlinenum，等等），那么我们选择这个了作为是调用（即接收或来电方）的另一面。
To give one example: if we detect a NewStateEvent with a ChannelState of 6 ('Up'), we check if there is an ongoing call in process and that the UIDs match, and if so then the current call has been answered. If the UIDs don't match, but other factors do (e.g. channel, connectedlinenum, etc), then we pick this up as being the 'other side' of the call (i.e. the receiving or incoming side).
我不知道，如果问题出在API或急性心肌梗死 - 但两者是它导致我们一些真正的麻烦
I'm not sure if the problem lies with the API or with AMI - but whichever it is it's causing us some real headaches.
任何意见，不胜感激。
推荐答案
是否有可能为你更新到Asterisk的12？在AMI频道名称现在是稳定的Asterisk的12。
Is it possible for you to update to Asterisk 12? The channel names in AMI are now stable in Asterisk 12.
的 https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification
这篇关于使用C＃和Aster.NET可靠地识别和跟踪Asterisk调用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
