[asterisk-dev] Application timeouts, Periodic and Scheduled Announcements

[Kaloyan Kovachev]

On Wed, 29 Aug 2007 16:08:11 -0500, Tilghman Lesher wrote
> On Wednesday 29 August 2007 15:12:48 Russell Bryant wrote:
> > Tilghman Lesher wrote:
> > > On Wednesday 29 August 2007 14:00:40 Russell Bryant wrote:
> > >> ; Limit conference to 5 minutes
> > >> exten => s,1,Set(TIMEOUT(application)=300)
> > >> exten => s,n,MeetMe(1234)
> > >> ; Turn timeout back off
> > >> exten => s,n,Set(TIMEOUT(application)=0)
> > >
> > > This is inconsistent with how other timeouts currently work.  Other
> > > timeouts jump to a particular extension in the current context, namely
> > > 't' (for response) or 'T' (for absolute).
> >
> > So, do you think it would be better to just redirect the channel to some
> > special extension reserved for "application timeouts" ?
> 
> I don't know if it would be better, just more consistent.  If we make timeouts
> behave differently for some certain cases, then we need to justify why it's
> like that.  So it could be that we jump to a special extension, or it could be
> that we modify the other timeouts to continue in the dialplan in some special
> way.  Or, we could allow certain timeouts, where applicable (i.e. not
> response, but maybe absolute) to continue in the dialplan and fallback to a
> special extension, if no further priorities exist.  I like this third option,
> as it's the most flexible, and further, it justifies why response timeouts
> aren't like that (because by definition, response timeouts only occur when
> there are no more priorities in the extension).
> 

Why not having that jump to special extension as Gosub? This way one may
decide if the call should continue or not.

> -- 
> Tilghman
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev