Summary:	ASTERISK-11287: Call transfer with 4 and more participants
Reporter:	Maxim A. Telegin (aiker)	Labels:
Date Opened:	2008-01-23 15:02:11.000-0600	Date Closed:	2008-06-05 14:07:45
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_features
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I have issues with current state of attended call transfer. My example: A1 - abonent No1 A2 - abonent No2 A3 - abonent No3 A4 - abonent No4 # - my custom button for attended call transfer 1. A1 calls A2 2. Call established 3. A2 presses # and enter extention number for A3 4. A2 to A3 call established 5. A1 goes in music on hold state 6. A2 presses # again (wants transfer call not to A3, but to A4) 7. A3 goes in MUSIC ON HOLD state!!! (not nangup!) 6. A2 to A4 call established 7. A2 hangup 8. A1 to A4 bridge established A1 and A4 is talking each other, A2 is hangup, but A3 remains in music on hold state!!! Is this right behavior? I think if A3 is wrong target for call transfer it should be hangup.
Comments:	By: jmls (jmls) 2008-05-03 14:27:56 is this still a problem with the latest trunk ? By: Jeff Peeler (jpeeler) 2008-05-15 17:49:59 I actually don't know if this is "proper" transfer behavior, but assuming so it is still a problem. By: Jeff Peeler (jpeeler) 2008-05-15 18:31:23 This is not a bug, but has prompted thinking towards making a change in behavior. By: Steve Murphy (murf) 2008-05-16 08:57:56 Hmmm. This is jpeeler's bug, and I don't have enough analog phones to test this right now, but... does the channel driver need to stack such things? Should a callback to A2 be done to put him back to A3 after A2 hangs up? And other related scenarios kick in: The kids in Burlington, WY (serviced by a small but savvy telco) have been known to create fairly massive conference calls using the 3-way feature of their phones. Kid A calls B, I think, and B hookflashes and calls C, B hookflashes again for a 3-way. C hookflashes, and calls D, then hookflashes again to get a three-way. D hookflashes, calls E, and so on, till like 10 kids are conferenced together... I don't have enough analog phones to test this out here right now. And here's another one, maybe fairly common... A1 calls A2; they talk. A3 calls A2, A2 hears call waiting beeps, and hookflashes, A1 should get MOH, A2 and A3 should be able to talk. A4 calls A2, and A2 hookflashes again. Should get A4? Can A2 somehow get back to A1? to A3? By: Jeff Peeler (jpeeler) 2008-05-20 11:08:32 I tested with Polycom phones as A1 and A2. When A2 presses the transfer button the second time, the transfer is considered complete, A2 is hung up, and A1 and A3 are talking. A2 can not start another assisted transfer in the middle of another transfer, which perhaps is the correct behavior. If A2 starts to transfer to A3 by mistake when really the intended target is A4, it seems that a disconnect is required. Then a new assisted transfer can be made to A4. I need feedback if this is the way things really are supposed to work. By: Jeff Peeler (jpeeler) 2008-06-05 14:07:44 Changing the code to make this behavior change is just not architecturally compatible currently.