[asterisk-dev] Re: branch 1.2 r12927 - /branches/1.2/apps/app_dial.c

[Tony Mountifield]

See below...

In article <20060314184110.3E2C0A949EB at abita.digium.internal>,
 <svn-commits at lists.digium.com> wrote:
> Author: russell
> Date: Tue Mar 14 12:41:05 2006
> New Revision: 12927
> 
> URL: http://svn.digium.com/view/asterisk?rev=12927&view=rev
> Log:
> when using the G() option to Dial, fix sending the called channel to 1 priority
> beyond what was specified (issue #6523)
> 
> Modified:
>     branches/1.2/apps/app_dial.c
> 
> Modified: branches/1.2/apps/app_dial.c
> URL:
> http://svn.digium.com/view/asterisk/branches/1.2/apps/app_dial.c?rev=12927&r1=12926&r2=12927&view=diff
> ==============================================================================
> --- branches/1.2/apps/app_dial.c (original)
> +++ branches/1.2/apps/app_dial.c Tue Mar 14 12:41:05 2006
> @@ -1414,7 +1414,6 @@
>  			}
>  			ast_parseable_goto(chan, opt_args[OPT_ARG_GOTO]);
>  			ast_parseable_goto(peer, opt_args[OPT_ARG_GOTO]);
> -			peer->priority++;
>  			ast_pbx_start(peer);
>  			hanguptree(outgoing, NULL);
>  			LOCAL_USER_REMOVE(u);

I'd like to offer the opinion that it would be better to revert this
change and instead document the behaviour. Here are my reasons:

1. It is potentially very useful to be able to distinguish easily between
the calling and called legs of the call. For example, I have an
application where it would be useful to use G() to transfer the caller and
callee to a conference, but to give different MeetMe options to each. By
putting a Goto at context^exten^priority, I can then have the two legs
processed independently. Applications that want both legs to do the same
just need to put NoOp there instead, and they will both continue at
priority+1.

Without this feature, I would have to do GotoIfs on channel variables to
distinguish, if indeed there are any suitable variables to test.

The feature was originally submitted as bug #3786 by anthm. I don't know
whether he intended the dual-priority behaviour or whether it is a happy
serendipity, but I think it's worth preserving.

2. Changes to a Stable branch should not change how a dialplan is executed.
There may be folks who discovered the actual behaviour and now rely on it.

Comments?

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