Thanks again /O<br><br>You're correct, I'm not very familiar with the internals of AMI.<br>I think from your last description, what I am after IS remote hold.<br><br>Happy to hear it got you thinking :)<br><br>Just to re-iterate what you've said, it sounds like asterisk happily obliges with a hold request from a handset and happily plays music on hold to the other channel (held party). The holding party then gets released to do whatever, and the hold button or line key flashes.<br>
<br>I'll come back to this list after I get the initial MakeCall, ClearConnection functions down and some events. The remote-hold isn't holding back my development for initial CSTA functionality.<br><br>remote hold is a handy thing to have for 3rd party call control - hopefully we can see it in 2010 :)<br>
<br><br>Happy January!<br>Cheers<br>Chris<br><br><br><br>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 :-)<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.<br>
<br>
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" ?<br>
<br>
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).<br>
<br>
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<br>
1) We have not implemented "put myself on hold"<br>
2) If we do that - how do we release the hold, who's allowed to do that?<br>
<br>
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.<br>
<br>
/O<br>
<div class="im"><br>
<br>
><br>
><br>
> Look forward to your reply,<br>
> Chris<br>
><br>
><br>
><br>
><br>
> On Wed, Jan 6, 2010 at 9:55 PM, Olle E. Johansson <<a href="mailto:oej@edvina.net">oej@edvina.net</a>> wrote:<br>
><br>
> 6 jan 2010 kl. 11.40 skrev Chris Mylonas:<br>
><br>
> > 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!!<br>
><br>
> >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.<br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
> A transfer is more clean, because then you will have to make a decision about what to do with each call.<br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
> So, what's your opinion on this long essay? What do you really want to do? :-)<br>
><br>
> /O<br>
> _______________________________________________<br>
> --Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>
><br>
> asterisk-dev mailing list<br>
> To UNSUBSCRIBE or update options visit:<br>
> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
><br>
> _______________________________________________<br>
> --Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>
><br>
> asterisk-dev mailing list<br>
> To UNSUBSCRIBE or update options visit:<br>
> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
<br>
</div>---<br>
<div class="im">* Olle E Johansson - <a href="mailto:oej@edvina.net">oej@edvina.net</a><br>
</div>* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden<br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
_______________________________________________<br>
--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br>