[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