A Local channel actually consists of two channels in Asterisk: Local/XXX,1 and Local/XXX,2. The Local/XXX,2 channel traverses the dialplan starting at the context and extension I provide.
The issue is that when I originate the call to the local channel it actually makes two calls, which the SIP provider has pointed out to me… Is there a way to still use the local channel but stop the second call from being made?
It would only behave as described if you made the same DIal the application for the originate, or included it in an originate to an extension. Your quote of the originate parameters are incomplete as you have neither an application nor an extension.
Thanks for your reply, I dont have an extension or application parameter included in my AMI Originate request. I just want to originate the local channel in the ‘dialout’ context where the dialplan in here uses the EXTEN to Dial out to the number I want to ring.
But because the Local channel generates 2 channels essentially there are two calls being placed to the same number. Is there any way round this or am I using the local channel wrongly?
There has to be an application or extension provided to an AMI Originate. An originate is “dial this device (in this case Local channel) and once answered execute this or go here”.
That is for the outgoing leg. Not for where to send the call once it is answered. It may be easier to think about how this works without Local channels (Local channels are nothing special to Originate).
If I originate a call to SIP/alice that SIP phone rings and once answered goes to where I provide in the originate (application or extension).
And what do you do in the macro? If it’s anything but setting dialplan variables or something quick then you are fighting against the primitives of Asterisk and how things should be done.
The macro just places the call into a defined queue waiting to be answered. But the second call is being placed almost instantly after the first call before it even gets into any of the other macro contexts.
You can’t place it into a queue like that in the macro. You should specify an extension (or the Queue application) in the AMI Originate which places it into the queue. That macro option is for running quick things before the channel is bridged.
Thanks jcolp, doing this with the macro does work, but I will take a look at changing this for a better way of working. However this part isnt causing the behavior regarding the 2 calls being made.
The application is a predictive dialler, it makes the calls out to the recipients and when answered drops the calls into a queue with the waiting agents. It appears to have been working for the past 3 years, however the client changed to a new SIP provider who highlighted that there were duplicate calls being made.
Doing a bit of debugging I can see that the culprit appears to be that the local channel spawns 2 channels, both of which make a call to the supplied number in the originate request.
There’s no guarantee that part isn’t the source. You are using things in an unsupported and bad manner, so there’s no telling what kind of repercussions that has.
I’d also suggest providing the COMPLETE AMI Originate. It may even be that your originate itself is sending the other call into the dialplan. Full console output would also be useful.
Hi Jcolp, I’ve done a bit of testing and it only seems to be the answered calls that end up with a duplicate call. Which makes total sense now what you have been saying. Because there isnt an extension or application provided in the originate when the call is answered the second leg of the local channel then seems by default to follow in the same context as the outgoing leg, hence dialling the number a second time. So yes bad design and a lack of understanding at the time of implementing this. Thanks for your help.