[Asterisk-Dev] AST_FLAG_DEFER_DTMF (would like dialogic-r4like semantics)

[Steven Critchfield]

On Thu, 2005-12-01 at 11:04 -0500, Greg Lim wrote:
> Sorry to be a bother, but I'm seeking *understanding* here, not a quick
> fix.

Then this is a good place to be.

>  I have 1000's of lines of code
> from an
> already-written non-asterisk solution that I am trying to port to
> Asterisk.

You are already on a self imposed uphill battle then. 

> AST_FLAG_DEFER_DTMF is apparently not documented, and the one nonobvious
> comment in
> the sourcecode appears to not match what the code is actually doing.
> Further, it has been
> that way since before ast_test_flag() was a macro.

I don't think your app should be going down into channel specific flags.
Ideally, you should be working with the frames passed back and forth if
you are writing an asterisk application or you should be working on the
agi interface otherwise. 

> I did not know about app_externalivr before. That's new info to me.
> Thank you. It'll be
> another good place to look at behavior like that. I don't think I can
> use that directly,
> because it would require rewriting the logic for my "scripts" in dozens
> of places. 

Unfortunately that is the breaks sometimes when porting though. You may
well be able to write an AGI to dialogic wrapper that could make AGI
behave and send commands more like you are expecting.  

> Also,
> a dialplan is not really the correct place to do this, as there's a ton
> of code that
> talks directly to proprietary in-house TCP-socket apps.

That isn't too hard to build up in a small app in the dial plan. Look at
app_pgsql, it builds a postgres connection up and allows you to do
database queries from the dial plan. But I know, it will make you
rewrite your logic  in the scripts.

> Again, sorry to be a bother; I thought the asterisk-dev list would be
> the correct place
> to ask about one of the internal channel flags. If I am mistaken in
> that, could someone
> please correct me?

It is the best place to ask the question, but you will find many people
want to understand the problem they are helping you solve and point out
better ways of going about solving the problem. Working solutions are
great, but many of us would like to help create optimal solutions with
you. So many times our answers may be in a different direction than you
are wishing but only because we are suggesting a different route to the
goals we see.

You will see where Tilghman is trying to build up enough applications in
asterisk to keep us from having to shell out to any external apps to
drive asterisk through a user experience. Eventually I see trying to
rebuild one of our big asterisk agi apps with apps from Tilghman and
AEL. I know it should be able to trim about 1 second or more per call
between the time we receive the call and the time we can start our menus
to the user.

-- 
Steven Critchfield <critch at basesys.com>