Summary:ASTERISK-05509: [branch] Patch to allow Dial() to ignore call forward
Reporter:John Lange (johnlange)Labels:
Date Opened:2005-11-08 11:55:48.000-0600Date Closed:2008-01-15 16:06:22.000-0600
Versions:Frequency of
Environment:Attachments:( 0) asterisk_allowcallforward.patch
( 1) ignorecallforward.27270.patch
Description:When dialing a group of phones it is often desirable to have Asterisk ignore any "302 Redirect" requests it might receive.

For example: after hours a business may want the general number to ring multiple extensions so that anyone thats still around can answer it. However, one of those people may have set their phone to call-forward to their voicemail or cell phone.

The following patch applies against 1.0.9 and adds another option to the Dial command.

"i" tells asterisk to ignore any 302 Redirects and continue on dialing the rest of the extensions.

Brief example: phone at 2000 is set to forward.


exten => 2000,1,Dial(SIP/2000&SIP/2002,20,i)

CLI output:

   -- Executing Dial("SIP/2001-eece", "SIP/2000&SIP/2002|20|i") in new stack
   -- Called 2000
   -- Called 2002
   -- SIP/2002-d46a is ringing
   -- Got SIP response 302 "Moved Temporarily" back from
   -- Now forwarding SIP/2001-eece to 'Local/8850872@from-sip' (thanks to SIP/2000-d08d)
   -- Forwarding SIP/2001-eece to 'Local/8850872@from-sip' prevented by dial option 'i'
Nov  8 11:34:19 NOTICE[27509]: app_dial.c:240 wait_for_answer: Unable to create local channel for call forward to 'Local/8850872@from-sip'
 == Spawn extension (from-sip, 2000, 1) exited non-zero on 'SIP/2001-eece'
Comments:By: BJ Weschke (bweschke) 2005-11-08 12:34:34.000-0600

johnlange: do you have a disclaimer on file? this is a new feature, and as such, the patches also need to be against the CVS-HEAD tree before they'll be considered for inclusion in the Asterisk tree. Sounds like a useful option though, so thank you for contributing it!

By: Serge Vecher (serge-v) 2005-11-08 13:12:01.000-0600

second that. johnlange: please make sure you use tabs instead of spaces for formatting.

By: John Lange (johnlange) 2005-11-09 02:04:11.000-0600

What do you mean by disclaimer? Do you mean regarding copyright or ?

Also, I'll see what I can do to make this work against CVS. If someone else wants to pick it up and give it a shot, please feel free. I just don't think I'll get to it any time soon because I don't expect to run 1.2 for at least a few months after its released. (CVS-HEAD is 1.2 right?)

By: BJ Weschke (bweschke) 2005-12-14 21:30:30.000-0600

I've posted an updated patch based on the /trunk code in svn in http://svn.digium.com/svn/asterisk/team/bweschke/bug_5657

Please test it if you're interested in the feature and let me know if it works as you'd expect.

By: opsys (opsys) 2005-12-30 18:19:55.000-0600


Bugs have simular qualities all use SIP Header Diversion reason.

By: Matt O'Gorman (mogorman) 2006-01-11 18:44:30.000-0600

johnlange do you have a disclaimer on file?  if not we can not look at this patch and be forced to close this patch.

By: John Lange (johnlange) 2006-01-11 22:03:42.000-0600

If you read the notes you would see I asked for more information about what you meant by a disclaimer but nobody replied. So to answer your question, no you don't have a disclaimer on file for me and I have no clue what you are even taking about.

Rather than taking a dismissive superior tone in your note, why don't you offer to help and provide me with the required information so that the patch can be accepted and Asterisk can get better?

By: opsys (opsys) 2006-01-11 22:34:43.000-0600

This is from the bugs.digium.com Homepage.

I included it for your information. Please fill oout a disclaimer and send it via the methods described below.

Disclaimers - 08-03-03 13:45 - markster  
In order to keep copyright clean, contributed code needs to be disclaimed. Disclaimers can be found at http://www.digium.com/disclaim.changes [^] or http://www.digium.com/disclaimer.txt [^] (both documents are fine, just whichever you are more comfortable with) and should be faxed to +1-256-864-0464 and/or snail mailed to:

150 West Park Loop Suite 100
Huntsville, AL 35806

Either is fine, just choose the one that makes you most comfortable. Thanks!

By: Matt O'Gorman (mogorman) 2006-01-11 23:15:15.000-0600

im sorry john. that was not my intent.  It is on the front end of the site.  I am sorry if I came off as dissmisive.  We appreciate all contributions.  Once again, it was not my goal to offend anyone ever.

By: opsys (opsys) 2006-02-05 23:12:43.000-0600


Do whe have a discliamer yet??

By: John Lange (johnlange) 2006-02-05 23:39:40.000-0600

Just faxed it. Sorry for the delay.

By: Serge Vecher (serge-v) 2006-02-07 07:57:49.000-0600


May I add a little suggestion?: I think it would be clearer if the following lines of code:
ast_verbose(VERBOSE_PREFIX_3 "Dial option prevent forwarding set 'On'\n");
ast_verbose(VERBOSE_PREFIX_3 "Dial option prevent forwarding set 'Off'\n");
mentioned the 'i' option by name, instead of 'prevent forwarding', i.e. "Dial option 'i' set to On/Off"

By: opsys (opsys) 2006-03-10 15:36:04.000-0600


Can we confirm disclaimer has been faxed?
Anyone moving on this?

By: Olle Johansson (oej) 2006-03-14 01:30:56.000-0600

The call_forward functionality is used by many channels, not only SIP. If you want to have a flag to disallow SIP 302 redirects, it's better handled in chan_sip. This is a global flag to disallow ALL call_forward settings from any channel, so I would suggest you change the explanation in your patch for app_dial() - otherwise zap channel users will not understand.

The patch also needs to be updated to current svn trunk. Thanks!

By: John Laur (gork) 2006-03-19 15:20:36.000-0600

I attempted to test bweschke's updated patch, but it does not seem to work. I get the following error trying to dial a SIP endpoint when the 'i' option is specified:

-- Executing Dial("SIP/5060-08164390", "SIP/2000|30|i") in new stack
-- Forwarding SIP/5060-08164390 to '' prevented by dial option 'i'
== Everyone is busy/congested at this time (0:0/0/0)

In this case the endpoint is NOT issuing a 302 redirect; I did not test with one issuing a redirect because obviously something is broken. I'd be very interested in seeing this implemented; the feature would be of enormous use to me.

Tested on trunk and also backported patch to 1.2.5; results are the same.

By: John Lange (johnlange) 2006-03-20 13:17:00.000-0600

I am once again actively working with the client who originally asked me for this patch which means there is a good chance I can do some further work on it in the near future.

A 302 redirect is the most common method I've seen endpoints use for call forwarding but obviously this patch should try and capture as many of them as possible.

Does anyone have any documentation on the most common methods?

By: John Laur (gork) 2006-03-20 13:26:33.000-0600

It seems to me that it is not necessary at all for this patch to determine how or to where a call is forwarded; that is the job of the channel driver for each technology. The 'i' option to Dial() and the current implementation are agnostic as to the method of forwarding -- if the channel driver says the call needs to be forwarded and this option is specified then it simply doesn't get forwarded. Although this was posted as SIP-specific, it's actually generic, even if that was not the intent.

If chan_sip needs to be extended to respect a different type of call forward or redirect other than 302, that's fine but it's belongs in a new bug.

AFAIK, this patch or bweschke's updated work just needs to be fixed and tested against SVN trunk.

By: opsys (opsys) 2006-03-30 17:07:05.000-0600


Since this appears to be Technology agnostic can we assume that the SIP and IAX functionality would not need to be added?

Has onyone else been testing this?

By: Olle Johansson (oej) 2006-03-30 17:45:26.000-0600

If you read my comment, I only suggested changing the documentation for app_dial to not talk about SIP, but all call forwarding.

By: John Lange (johnlange) 2006-05-16 01:35:13

Ok! FINALLY here it is. The patch against trunk which I downloaded via SVN just this evening before I started working on this. According to "asterisk -V" this is Asterisk SVN-trunk-r27270M. Please test it and get it into trunk asap before something else changes and it takes me 6 months to re-work it again ;)

By: John Lange (johnlange) 2006-05-26 17:37:05

Nudge? I understand the 1.4 feature freeze is coming up next week. Can this make it? AFAIK this is ready to go but we should have more testing so can this make it into the main branch or whatever is required?

By: John Laur (gork) 2006-05-26 17:57:35

I have tested this patch and verified that it works as expected. From reading the code I cannot see any possibility of it causing problems and have encountered no issues using it. It works as expected and will cause Dial to fail whenever there are SIP redirects or Zaptel forwards (and presumably any other channel drivers that have a forward/redirect mechanism as well, though I only have SIP and zap to test).

The patch does need to document the 'i' option in the Dial command, though. I have backported the patch to 1.2 for anyone interested. I am out of town for the weekend and do not have access to my work from here, but I will post the patch Monday or Tuesday. My backport does include some simple documentation in the 'show application Dial' help t hat we are welcome to use for the trunk patch if you like it. I am disclaimed as well.

By: BJ Weschke (bweschke) 2006-05-31 10:53:31

Committed to /trunk. Thanks!

By: Serge Vecher (serge-v) 2006-06-07 15:37:41

bweschke: don't forget to delete the branch too :)

By: Digium Subversion (svnbot) 2008-01-15 16:06:22.000-0600

Repository: asterisk
Revision: 7454

U   team/bweschke/bug_5657/apps/app_dial.c

r7454 | bweschke | 2008-01-15 16:06:22 -0600 (Tue, 15 Jan 2008) | 1 line

Code update/import for this issue. Original bug ASTERISK-5509. Objective: provide an additional option in Dial to prevent Asterisk upon acting on call forward requests when it receives them.


By: David Cunningham (dcunningham) 2013-12-04 23:28:13.183-0600

Trace attached.