[Asterisk-Dev] chan_mgcp patch ready for beta testing

[Karl Putland]

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.

-- 
Karl Putland <karl at putland.linux-site.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mgcp_call_features3.patch.gz
Type: application/x-gzip
Size: 18347 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20030422/d1b412ba/mgcp_call_features3.patch.bin