| Summary: | ASTERISK-02494: 2342 bug fix breaks chan_zap answer behavior | ||
| Reporter: | izo (izo) | Labels: | |
| Date Opened: | 2004-09-28 15:43:14 | Date Closed: | 2004-10-02 22:04:10 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| 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 | ||