[asterisk-dev] AMI call on hold (new topic)

[Chris Mylonas]

Thanks for your time in replying /O

What I'd like to do is port my CSTA stack to AMI - make call, hangup are all
simple - I got stuck on the Hold command - I was a bit surprised that AMI
didn't have a HoldCall function.

I'm doing a project at the moment where I'm collecting CSTA events and
rewriting them to Asterisk-Java like Manager Events.  I may as well go the
whole way and just implement CSTA for asterisk.  In a sense, you write your
application to work with opencsta, it'll work with Siemens Hipath 3000
series PBXs and asterisk, without any code changes in the application's
code.

It's a bit premature, but I've got a "Handy CSTA Test Tool" which I need to
upload the source code for - its' a GUI that controls phone calls on the
Siemens.

What I'd like to do is be able to press "Hold" on my "Handy CSTA Test Tool"
that works with the Siemens handset on a Hipath and make it work exactly the
same as Asterisk with a SIP endpoint - without the extra
transfer/parked-call etc... and be able to retrieve the call from pressing
the same hold/retrieve button on the "Handy CSTA Test Tool" GUI.

I don't completely understand the bridge vs non-bridge stuff you have said
about AST_CONTROL_HOLD frames.

If I can't put a call on hold, I'd expect to receive an error response from
AMI.  If I try and put a call on hold through AMI or CSTA in these
scenarios:

a)  The call doesn't exists -> return error
b)  The call cannot be placed on hold -> return error
c)  Established call + Hold request -> play music on hold to held channel
and release the holding party.  The call is still on the handset though,
through the Hold/Retrieve buttons that handsets have.  Moving control of the
call from the handset to the PBX is "Parking" behaviour rather than
"Holding" behaviour.  (Although it's way better to use parking, I just want
to make Hold behave the same on both a Snom/Polycom/Zoiper on Asterisk as an
Optipoint on a Hipath).


Am I making sense?
Is there some kind of limitation within AMI that cannot see what the state
of both sides of a call are?


Look forward to your reply,
Chris




On Wed, Jan 6, 2010 at 9:55 PM, Olle E. Johansson <oej at edvina.net> wrote:

>
> 6 jan 2010 kl. 11.40 skrev Chris Mylonas:
>
> > I would like to request an AMI command for placing a call on hold.  I
> understand that "Hold" is done with SIP messages, but if we could get an AMI
> command to do something similar (without having to transfer calls to a queue
> or to a park extension, and keep the call on the handset) that would be
> awesome!!
>
> From a SIP standpoint, we accept being put on hold by a remote device, but
> we never put another device on hold. What's happening from a technichal
> standpoint is that we receive a hold request and we alert the pbx and the
> pbx will play musiconhold on the bridged channel - if it's configured to do
> that.
>
> Now, an AMI command can send a AST_CONTROL_HOLD message to a channel and
> force musiconhold until the channel is released from hold. What do we now do
> with the other end of the bridge? It might still send voice frames.
>
> In order to implement this, we need to find out what to do with a channel
> without a bridge, one that's involved in a bridge and one that is not in up
> state at all (ringing).
>
> A transfer is more clean, because then you will have to make a decision
> about what to do with each call.
>
> Another option would be to implement a SIP remote hold option, where we
> actually request a hold on a SIP call, and send a AST_CONTROL_HOLD frame
> across the bridge. This can also be done in ISDN I guess, but I can't answer
> for the rest of the channels.
>
> In this case you would send ami_hold action on a channel where you want
> Asterisk to request a hold and entertain the other end of the bridge with
> music (if there's a bridge).
>
> So, what's your opinion on this long essay? What do you really want to do?
> :-)
>
> /O
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100107/9742604c/attachment.htm