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

Thu Jan 7 03:03:33 CST 2010

7 jan 2010 kl. 05.12 skrev 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.  
great! I appreciate any feedback on AMI - missing parameters, missing commands.
> 
> 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?
well, I think the issue here is more about your (excuse me) knowledge about how Asterisk works. This is after all the developer list, so I took the liberty of going down the technichal path, since you started a few cpu cycles in my brain... Let me try again :-)

It may sound simple to implement "hold" - but what does it really mean and what does it mean for the way we handle calls in Asterisk? What you want from a CSTA standpoing may be another existing feature in Asterisk called something different than hold. Now, you've specified what you want a bit better, so let's look at it again.

In (C) you say "Play music on hold to the held channel and release the holding party". What do you mean with release? I think you mean remote hold, like I mentioned. We don't support that yet in the SIP channel and I haven't tested how the various SIP phones react to that in regards to unholding. It would be interesting to test. I don't see any issues with the phones though, more Asterisk. In the SIP channel we have no sense of who's holding, as we only support being put on hold by the phone. In order to support this, we need to implement a sense of who's holding, us or them and what happens if we've put the phone on hold and the phone requests unhold. We might not allow that, in fact, should not in most cases as the other party has requested hold and is occupied with something else. In your case, with a 3rd party call control putting something on hold, who can release it? Who's the "holding party" ?

In a "normal phone call", we have two phones. Each one has an active "channel" to Asterisk. Asterisk "bridges" the call, i.e. let them talk with each other. Inside Asterisk, the two channels communicate out-of-band, outside of the media channel, by sending AST_CONTROL messages to each other. Some of them are meant for the PBX to act on, some of them for the other channel. If one channel gets a hold request, that's translated to a AST_CONTROL_HOLD and sent to the other side, that decides on what to do for servicing that channel properly. In most cases, we just replace the audio with music on hold music (specified in the AST_CONTROL_HOLD message).

What you want to do is connect a 3rd party app to the PBX and select one of the channels and put it on hold, as if it had put itself on hold, and tell the other channel to entertain itself with music. This way, the channel you put on hold is "released" to do other things. The issue here is 
1) We have not implemented "put myself on hold"
2) If we do that - how do we release the hold, who's allowed to do that?

As a summary, we have no controls today to put a channel on hold and "release the handset" - at least not in SIP. I think that there's a remote hold in Dahdi, at least I've succeeded in sending a hold to my cell phone with it somehow. I don't know about the other channels.

/O

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

---
* Olle E Johansson - oej at edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden