Summary:	ASTERISK-02232: chan_zap allows you to bridge the two subchannels of a single master
Reporter:	twisted (twisted)	Labels:
Date Opened:	2004-08-17 20:22:50	Date Closed:	2011-06-07 14:10:11
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Zaptel currently allows you to bridge the subchannels of one existing master channel, ie, Zap/30-1 and Zap/30-2 can be bridged on the same device, and asterisk believes they are both up, bridged together.  MOH is heard during the transfer, but after * believes the channels are bridged, MOH stops until a new flashhook is introduced. ****** ADDITIONAL INFORMATION ****** Scenario: Call from a zap channel to a SIP phone.  answer the call on the sip phone, then transfer the call back to the phone it came from.  flash over when you hear the call waiting beep.  The sip phone will hangup, and you will be talking to yourself, bridged together on two subchannels of your Zap channel. Zap/1 calls SIP/100.  Sip/100 transfers Zap/1-1 to Zap/1.  Zap/1 flash-hooks and there is now a bridge between Zap/1-1 and Zap/1-2, and inline (#) transfers can transfer the second leg back out.
Comments:	By: Mark Spencer (markster) 2004-08-17 22:33:04 What exactly would you think the behavior should be? By: twisted (twisted) 2004-08-17 23:22:39 I would assume that instead of bridging the two subchannels, either we send back busy if the call being transferred to it belongs to the same master channel, or instead of bridging on the flash to answer call waiting, which can be quite confusing, as you flash and get nothing, we immediately place the first subchannel on hold.   Is this actually the intended behaviour? By: Mark Spencer (markster) 2004-08-18 17:18:46 It is the most accurate behavior.  If you want to try something you could see what happens if you do this on a real phone, but it would be highly unreasonable to try to figure out that whole path.