Summary:ASTERISK-02494: 2342 bug fix breaks chan_zap answer behavior
Reporter:izo (izo)Labels:
Date Opened:2004-09-28 15:43:14Date Closed:2004-10-02 22:04:10
Versions:Frequency of
Description:2342 bug fix breaks chan_zap behaviour,
on answer zt_read sets the state of the channel to AST_STATE_UP then it
sets AST_CONTROL_ANSWER frame which is then returned
to ast_read which thinks that its duplicate !!! and is not passing back the frame itself. It breaks custom developed applications
Comments:By: Mark Spencer (markster) 2004-09-28 16:26:26

huh? I'm not at all getting what you're saying is wrong.

By: izo (izo) 2004-09-28 21:24:22

i have own dial application working on PRI zap channels that expects to get different AST_CONTROL_* frames from ast_read and it is getting AST_CONTROL_RINGING or AST_CONTROL_BUSY singalls nicelly but its not getting AST_CONTROL_FRAME at all because it is "eaten" by "duplicate answer" controller so it looks like a bug to me either in chan_zap.c or channel.c
Either should chan_zap.c sent AST_CONTROL_ANSWER and dont set channel state AST_STATE_UP cause it will be setup later either way in ast_read
or "duplicate answer control" should be made differently

By: Brian West (bkw918) 2004-09-29 09:32:15

Ok let me see if I get this.. you're using your OWN dial app not the one in asterisk and its not working right and you think its a bug in asterisk?  Does it work correctly with app_dial?

By: Mark Spencer (markster) 2004-09-29 10:05:08

Why not check if the channel is up?

By: izo (izo) 2004-09-29 10:29:53

bkw: its inconsistency in design, you are sending back all control frames except "answer" cause you think it was duplicated although it wasnt.
mark: so i can set up call time properly, with channel state scenario i'd have to check it for every null frame received to know exactly when channel was answered
thats why AST_CONTROL_ANSWER is the best choice.

edited on: 09-29-04 10:30

By: Mark Spencer (markster) 2004-09-29 10:57:53

The only way would be to enforce that the control answer is sent without state up being set explicitly.  THat's going to be driver specific.

By: Mark Spencer (markster) 2004-10-02 13:14:53

Okay I took out some of the code so we shouldn't have that situation now.

By: Russell Bryant (russell) 2004-10-02 22:04:10

not included in the 1.0 branch