Summary: | ASTERISK-18275: DTMF blind transfer continues in dialplan after transfer. | ||||
Reporter: | Richard Mudgett (rmudgett) | Labels: | |||
Date Opened: | 2011-08-15 13:24:55 | Date Closed: | 2011-10-13 17:55:25 | ||
Priority: | Minor | Regression? | |||
Status: | Closed/Complete | Components: | Features | ||
Versions: | 1.8.5.0 | Frequency of Occurrence | |||
Related Issues: |
| ||||
Environment: | Attachments: | ||||
Description: | Party A calls Party B. Party A DTMF blind transfers Party B to Party C. Party A channel continues to execute dialplan. It is critical for Party A to do the transferring. If Party B transfers Party A to Party C then there is no problem. Found while investigating ASTERISK-15792. The fix is for features.c:builtin_blind_transfer() to return the correct value similar to the fix for ASTERISK-15792. Determining what return value to return will need more investigation to fix correctly since blind transfer has some dialplan goto features for the transferring party. | ||||
Comments: | By: Leif Madsen (lmadsen) 2011-09-20 16:36:20.321-0500 Please provide the dialplan you are executing so we can reproduce this issue. Also I suppose it is implied that you are using built in transfers and not SIP transfers? By: Leif Madsen (lmadsen) 2011-09-20 16:37:55.885-0500 And yes, since you were working in features.c recently, yes, you were using built-in transfers :) By: Richard Mudgett (rmudgett) 2011-09-20 16:42:40.547-0500 Updated the description to indicate DTMF blind transfer and the source file the specified function lives in. :) |