[asterisk-dev] design question: handling incoming ETSI partial rerouting request

[Tony Mountifield]

In article <4857770F.9090103 at pernau.at>,
Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> Tony Mountifield schrieb:
> > In article <48568814.7050500 at pernau.at>,
> > Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> >> Tony Mountifield schrieb:
> >>> You should also consider how it would be handled for calls started from
> >>> a call file or the Manager API, when they specify Zap/xx/nnnnnnnn as
> >>> the Channel parameter. In that case, there is no incoming channel that
> >>> originated the call, so nowhere for DIALSTATUS to be set, nor for any
> >>> dialplan decisions to be made about how to handle the redirect.
> >> Hmm. I have not thought about this. How can this be handled?
> > 
> > I don't know - it needs more than a few minutes thought!
> > 
> > I just flagged it up because I could see it was a situation that your
> > approach didn't address.
> 
> You are absolutely right. But many other things have the same problem 
> (e.g. DIALSTATUS, PRI_CAUSE, PRIREDIRECTREASON).

This is true, but they are just used to report information. Unless I have
misunderstood, you were actually proposing to use dialplan logic to
control how the local PRI endpoint should respond to a message from the
other end. I would favour the channel driver making its own decision,
goverened if necessary by channel variable(s) that have already been set.

> I think it could be worked around in the dialplan by using a local channel.

Yes, that's always a possibility, and is an approach I have used too,
in various situations.

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org