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

[Kaloyan Kovachev]

Definitely it should be kept as is, not just for the stable branch.
I am one of those folks and i am using the behavior to set "aA" MeetMe options
for the caller. Removing this and not moving the M() (and probably D too) Dial
option to be processed before G() (which is also useful, but may be changed in
trunk), leaves me with not way to separate the caller.

On Fri, 17 Mar 2006 13:13:18 +0000 (UTC), Tony Mountifield wrote
> 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
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev