[asterisk-dev] Difficult transfer problem
David Cunningham
dcunningham at voisonics.com
Thu Feb 10 15:08:39 CST 2022
Thanks for the suggestion. That probably would work, but it would entail
lots of other changes at our application level.
I wonder if there's any other way to prevent the channel from being
optimized out? This is for the Local channel that's created by the atxfer
key defined in features.conf, so we don't have a Dial that we can add a /n
to.
We know that using Monitor will prevent it for example. Is there something
which we can use with no effect on the channel other than preventing
optimization? Recording all calls would be a little heavy-handed for the
purpose.
On Thu, 10 Feb 2022 at 21:48, Dennis Buteyn <dennis.buteyn at xorcom.com>
wrote:
> On 2/9/22 23:29, David Cunningham wrote:
> > The strange thing is that every Dial where we create a Local channel
> > does already have /n on the dial string.
> >
> > There is one other place where a Local channel is created, which is by
> > the transfer using the atxfer key defined in features.conf. The key is
> > ##, and if the user dials ##*7 then Asterisk creates the channel
> > Local/*7 at from-internal-X. How can we make sure that this channel is
> > not optimized out of existence?
>
> I suppose you could always make Local/*7 at from-internal-X Dial() another
> local destination with "/n"? Alternatively you could define them as
> custom features in the [applicationmap] section of features.conf by
> calling application Dial() with "/n". The original local channel will
> likely be optimized out and replaced by the new channel.
>
> --
> Dennis Buteyn
> Xorcom Ltd
>
>
--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20220211/aaa865bc/attachment.html>
More information about the asterisk-dev
mailing list