We’re trying to inhibit diversion through our ARI-based application and we’ve faced an issue. In most cases, the service providers we signal to will do as we expect with the diversion header. We set both the diversion counter to a high enough number and the flag to inhibit diversion. But in some cases the service providers don’t abide to stopping a diversion with these settings, and only reply with a 181 Call is being forwarded. The problem we’re facing with this is that our ARI application doesn’t get notified that the call has been diverted.
We’ve been trying with the forward and forwarded fields, but what we can see they don’t get populated in the received Dial event, which I assume is due to them only getting populated when there is a redirect from the Asterisk itself and not when it’s signaled outside. We’ve used version 18, 20 and 21 with the same results.
We’ve searched the forums and found some similar things but not related to ARI.
Something similar to this would be great if it’s not possible to get it triggered in an ARI event since we can implement some kind of polling solution to query the status.
Just spitballing, but is it possible to solve if we integrate AMI into our application and control channels that way, or will there be some issue due to the channel being owned by ARI? Maybe AMI doesn’t support this either?
We’ve also looked at a couple more topics on this forum and searched around on Google to no avail so any assistance we might receive would be greatly appreciated. I will gladly clarify if there are any questions.
The 181 itself doesn’t produce an event. Redirecting information is updated on the channel, which itself can produce an update internally. This, if I recall correctly, produces no events over ARI and I don’t think it would for AMI either. Functionality would have to be added to do so.
Is this feature something the Asterisk project would appreciate to have? We would gladly make an attempt at implementing it and making a PR to the project. If so, is there anything we should think about? We’ve read the contribution guidelines and the other documents under policies and procedures on the documentation page. Should we post an issue on the GitHub first? If implemented as an event in ARI (or perhaps extending ChannelStateChange or Dial that already has the forward and forwarded parameters), is support in the other interfaces also expected? Is support in sip also expected or only pjsip?
I’m sure people would appreciate it. The only other thing is to also include test coverage for it in the testsuite. An issue isn’t needed until something actually exists. Redirecting support is core, it is not channel driver specific. If you are doing it at that level, it’s not going to be accepted as it is likely incorrect.