[asterisk-users] Understanding Call Handling In Asterisk

varun.rapelly at spectross.com varun.rapelly at spectross.com
Mon Jun 8 23:33:32 CDT 2009



>>>    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.




More information about the asterisk-users mailing list