Summary: | ASTERISK-16927: atxfer fails to read data if Dial exetes macro or gosub | ||
Reporter: | John Harris (jmharris) | Labels: | |
Date Opened: | 2010-11-08 04:54:33.000-0600 | Date Closed: | |
Priority: | Major | Regression? | No |
Status: | Open/New | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) asterisk_1.6.2.13_issue_18274_atxfer_fail_with_dial_option_U ( 1) asterisk_1.6.2.13_issue_18274_atxfer_success_with_no_dial_func | |
Description: | We wish to execute commands after a call has connected, so testing using the M() and U() options to the Dial command. However if either of these are used (even if the the subroutine only issues NoOps) the inbuilt transfer functionality can seemingly no longer read the DTMF tones correctly. This appears to the callee as: * Phone rings, and the call is connected. * Asterisk successfully executes the subroutine. * Call recipient issues #1 (or #2) which are defined as the blind transfer and attended transfer features codes respectively. * Caller hears MOH. * Call recipient hears 'extension?' prompt and dialtone. * Call recipient presses first digit of the extension. * Asterisk plays beeper error tone and reconnects the call immediately. * Asterisk log contains 'features.c:1444 builtin_atxfer: Did not read data.' Varying the speed of typing the digits does not matter. It should be noted that the feature digit timeout and transfer digit timeouts are set, and that the transfers work just as expected so long as we do not add an M() or U() to the Dial options. ****** ADDITIONAL INFORMATION ****** Please see attached logs. One shows a working transfer, the second with Notes on the dialplan scenario: * Incoming call is on an analog DAHDI channel. * Call is passed to a ring group to simultaneously ring a couple of SIP phones (using a macro setup by the Digium Asterisk GUI). * In the working example a blind transfer was initiated. * In both the call is ended by hanging up the analog end. | ||
Comments: | By: John Harris (jmharris) 2010-11-08 04:58:38.000-0600 Please note in the failure log that a transfer was tried twice. The notes about being unable to find an extension, after features.c has reported an error, coincide with the user continuing to attempt to dial the transfer extension even though asterisk has stopped the dial tone. By: John Harris (jmharris) 2010-11-08 04:59:36.000-0600 In the description it was meant to say that the asterisk log reports 'features.c:1444 builtin_atxfer: Did not read data.' By: John Harris (jmharris) 2010-11-08 05:01:31.000-0600 For reference, the dial command is as follows (where DIALOPTIONS = tk): exten = s,n,Dial(SIP/122&SIP/121,8,${DIALOPTIONS}U(postdial^${CALLERID(num)})) And the subroutine: [postdial] exten = s,1,NoOp(Test routine for channel: ${CHANNEL}) exten = s,n,NoOp(Routine completed.) The caller ID was being passed for testing purposes. By: Daniel Journo (journo) 2011-06-29 12:42:45.054-0500 I've got exactly the same issue with 1.4.35. Searching on Google has shown that a large number of people have this issue, with multiple versions of Asterisk. By: Daniel Journo (journo) 2011-06-29 12:49:13.841-0500 It also happens when using a Local channel in the Dial command. |