[asterisk-dev] design question: handling incoming ETSI partial rerouting request
Klaus Darilion
klaus.mailinglists at pernau.at
Mon Jun 16 10:34:44 CDT 2008
Tony Mountifield schrieb:
> In article <48564347.509 at pernau.at>,
> Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
>> Hi!
>>
>> I wonder how I could implement the handling of incoming ETSI Partial
>> Rerouting in Asterisk. What should happen in chan_zap/app_dial if this
>> is received?
>>
>> Should it be handled automatically or manually? I would prefer manually
>> - so that in the dialplan I can decide to handle the redirection or not.
>> E.g. by setting a certain DIALSTATUS and having the redirected number in
>> another variable:
>>
>> Implementation:
>> - chan_zap receives incoming rerouting request (on an outgoing channel)
>> - chan_zap sends a CONTROL frame which indicates redirection
>> - app_dial receives the redirection CONTROL frame on
>> the outgoing channel and sets DIALSTATUS to REDIRECTED and also sets
>> variable which contains the number of the new target, e.g. rdnis (is
>> this the correct one?)
>> - then in the dialplan I can decide how to handle this, e.g. forward
>> upstream using zapCD (bristuff) or make a new call using Dial()
>>
>> exten => _0X.,1,Dial(Zap/12345);
>> exten => _0X.,2,GotoIf($["${DIALSTATUS}" = "REDIRECTED"]?103:3);
>> exten => _0X.,3,Hangup;
>> exten => _0X.,103,zapCD(CALLERID(rdnis));
>>
>> Any comments on this? Would a patch for this be accepted?
>
> 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?
regards
klaus
More information about the asterisk-dev
mailing list