[Asterisk-Users] Call transfering, conferencing

[Philipp von Klitzing]

Hi!

> 1) how can I make call tranfer. Not call parking.
> If I'm talking with some one a I want to tramnfer call to the another
> extension, to the other person.

As it was said: This depends very much on your phone, and also on the 
protocol you use (SIP, MGCP, H.323 etc). Look at the X-Pro (?) software 
from Xten, for example, if you are looking for a soft solution. 

> 2) how can I make call confernece. Not Meetme
> If I'm talking with some one and I want to join another person to our talk .

I attached below a posting taken from the bugtracker concerning MGCP and 
three way calling (this is what you are looking for I think).

By the way, I am just about to obtain two MGCP phones instead of the 
initially planned SIP phones - is that a bad move to make? Why is 
everyone only talking SIP and MGCP appears to be dead?

Greetings, Philipp


[Three way calling and MGCP]
Karl Putland <karl at putland.linux-site.net>

I am fairly satisfied with this implementation.

Most if not all of the kinks in call waiting a three way calling are
worked out.

In order for a call to be a threeway call, the endpoint must originate
both calls otherwise a flash hook just toggles between callers.  If
someone calls you and you want to do a threeway call, park them, call
the other number then retrieve your other caller from parking.  If you
abandon a threeway call, the other parties are connected via a transfer.
In order to do a flash hook transfer, the endpoint must originate at
least one of the calls.  This may produce unintended results.  If A
calls B, C calls A, A talks to C, A hangs up.  B and C might be
connected.  If anyone has suggestions for this, let me know.

If you hookflash from a call to dialtone and back, there's a brief tone
when the mgcp_ss thread times out with no digits.

Call waiting callerid seems to work for me about 7 times out of 10. I
don't know what the problem with that is yet.

point on IRC mentioned that the Cisco phone he's got sends a "hf"
message even if the phone is onhook.  The "hf" code checks for the
hookstate of the endpoint before entering. hookstate is toggled on the
receipt of "hu" and "hd" messages from the endpoint.

This patch also includes some timeout code for mgcp messages from
alex at pilosoft.com.  I verified that the timeout works, but it doesn't
help the endpoint if it's left in a nasty state.

Things that still need to be addressed if someone feels brave.
 1. Pigybacked mgcp messages.
 2. mgcp endpoint and gateway wildcarding.
 3. A way to issue DLCX on stale connection IDs for an endpoint.
 4. Support for digit maps to reduce the chatty nature of the current
    implementation.
 5. The attempt_transfer function probably doesn't do quite the right
    thing, but it works for now.
 6. ADSI doesn't work.  It tries, but I don't have the patience left to
    deal with it right now as I don't need it yet.
 7. Call wait callerID.  Is it us or the dlink?

Unless there are serious issues with this implementation, I'm done.
Please report issues this week.  If there are none, I'll ask Mark to
include this in cvs.

Thanks for everyone who gave input.