>>> Hi, >>> >>> I am a newbie to Asterisk; need help understanding three-way >>> conferencing & >>> call-transfer features implemented over standard extensions i.e. on a >>> TDM800P card (4 FXO + 4FXS) >>> >>> In Asterisk I have observed that if an extension is already >>> participating in >>> an active call (e.g. Ext A & Ext B communicating): >>> >>> 1. An incoming call to one of these active extensions would be >>> presented >>> with call-wait beeps (e.g. Ext A receives call-wait beeps as Ext C is >>> attempting to call Ext A). >>> >>> 2. The call waiting may be answered by pressing Hook-Flash, placing >>> the >>> previously active call on hold (e.g. C answered; A & C communicate; B >>> placed >>> on hold). >>> >>> 3. The calls could be toggled by subsequent Hook-Flash's (e.g. A & B >>> communicate; C placed on hold). >>> >>> >> Yes, this is normal behaviour on pretty much every analogue PBX or telco >> switch. >>> >>> >>> >>> Queries: >>> 1. If the extension which received call-wait beeps hangs-up then the >>> call >>> waiting/the call placed on hold returns as a new call. I was >>> expecting >>> the >>> call to be transferred (A hangs-up, B & C communicate), how could the >>> call >>> be transferred? I expected this feature to be available in Asterisk >>> as >>> this >>> is a very normal feature available on any PBX and used extensively in >>> Call >>> Transfer. >>> >>> >>> When you transfer a call, the person initiating the transfer has to be >>> MAKING a call. Example: Ext A receives a call from Ext B. Ext A wants >>> to transfer the call to Ext C. Ext A puts the first call on hold with a >>> hook flash, dials Ext C, then either waits for the Ext C to answer and >>> announces the transfer (e.g. an attended transfer) OR simply hangs up as >>> soon as the call to Ext C starts ringing (e.g. an un-attended or blind >>> transfer). >>> >> The behaviour you explain is not something available on any switch that >> I >> am aware of, and would be highly problematic if it were. If this >> "feature" were available, you could get a circumstance where two people >> who are calling you end up being bridged together on a call, unknown to >> you. As a bad example, your wife and your girlfriend end up talking to >> each other because you hung up while one of them call-waited you while >> you >> were talking to the other. >> > The scenario I was expecting was: > > When Ext. A & B are in speech and A is getting call wait beeps from C. > Now if Ext. A hangs up, C's call will not be transferred to B but will > come > as > a new call to A. Well if A hangs up after answering C (B on hold), then > C's > call > would be transferred to B when A hangs-up. > > Another point to be noted is when A & B are in speech. Either A could call > C > by putting B on hold 'or' C could call A & present itself as a > call-waiting. > The maximum loop count will never exceed 2 i.e. at any time you would > at-most have one active call & one call being held. > > Hence, either ways if the second call be an incoming or an outgoing > transfer > shall > never occur without the will of transferer ;-). >>> >>> >>> 2. How could the extension that received call-wait beeps initiate a >>> three-way conference with the other extensions (A, B & C in three-way >>> conference)? I expected this feature to be available in Asterisk as >>> this is >>> a very normal feature available on any PBX and used extensively in >>> 3-way >>> Call Conference. >>> >>> >> Again, this is NOT a feature available on any analogue PBX that I am >> aware >> of. If it were, this would, again, mean that you may get unwanted >> parties >> connected together. With the above example, you answer your girlfriend's >> call while talking to your wife, and all three of you end up in the same >> conference. >> > What I was expecting is: 3-way conference would never be intiated by > pressing > another flash but with a special key sequence (Feature Access Code / > Flash + some dtmf digit). Suppose A & B were in speech and A is getting > call wait beeps from C. Now if A presses "flash", the call is toggled i.e. > A > & C are > brought in speech and B is placed on hold. Subsequent "flashes", would > also > have a similar behaviour. Well if A dials special key sequence (Feature > Access > Code / Flash + some dtmf digit), then a 3-way conference would be > established. > > Again this can never happen accidentally. > >> Unfortunately, POTS lines do not handle transfering multiple inbound >> calls very well (with call waiting). This is not an Asterisk issue, POTS >> lines were not designed to do anything other than handle a single call at >> a time. You may be able to handle transfering a call-waited call with >> DTMF signalling. I am certain someone else on the list will be able to >> give you a definitive answer on that.
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
