| Summary: | ASTERISK-06315: [patch] app_dial reports CHANUNAVAIL on telco intercept messages | ||
| Reporter: | gkloepfer (gkloepfer) | Labels: | |
| Date Opened: | 2006-02-14 15:21:04.000-0600 | Date Closed: | 2006-04-11 17:41:45 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/app_dial |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) app_dial.patch ( 1) pri_intercept_trace | |
| Description: | Intercept messages from local telco terminate call before call is actually connected,causing app_dial to report CHANUNAVAIL. It is preferable (and appears to be the intent) to report NOANSWER instead. ****** ADDITIONAL INFORMATION ****** Attached is a debug of the PRI trace illustrating the situation. Note that the call is "in progress" while the intercept message is being played, then there is a disconnect before the call is connected. The HANDLE_CAUSE macro is used to set certain flags based on when the call is being prematurely or abnormally terminated due to busy signal, congestion, or no channels available. The default (none of those 3) causes a "no channels" indication to be made. However, in the condition noted above, the cause is actually a "normal clearing" and thus HANDLE_CAUSE reports it as a channel unavailable. The reason HANDLE_CAUSE is being called at all is because the normal clearing termination is occuring while the call is "in progress." The actual place this is happening is in line 651 of app_dial.c. The attached patch causes HANDLE_CAUSE to essentially do nothing when a normal clearing occurs. Tested on SVN 8969, but verified that app_dial.c has not changed between 8969 and 10004. | ||
| Comments: | By: Tilghman Lesher (tilghman) 2006-04-11 17:41:45 Committed to 1.2, merged to trunk. | ||