<div>Thanks for the details Kevin.</div><div><br></div><div>Firstly,</div><div>Your detailed 1, 1.1, 1.2, 2, 2.1 format of describing call states and call actions are extremely handy</div><div>Do they exist in some kind of documentation for asterisk or parts thereof? Or did you whip this out from the top of your head?</div>
<div><br></div><div><br></div><div>Secondly, in response to this</div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">It seems unlikely that this will be possible for Asterisk to do with SIP<br>
devices without using proprietary SIP extensions for each manufacturer's<br>devices; I'm not aware of any SIP standards, drafts or other proposals<br>to allow a SIP endpoint to signal to the endpoint it is connected to<br>
that it should initiate hold back towards the requesting endpoint as if<br>its user had done so.</blockquote><div><br></div><div><br></div><div>This being the case, and without testing, could I just spoof the address of the phone and send the SIP message myself and fool asterisk into placing the channel on hold and create pseudo-3PCC?</div>
<div><br></div><div>Which kind of addresses this:</div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">The best that can be hoped for is that a 3PCC agent could request a</span><br>
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">channel be placed on hold and that Asterisk would initiate the hold</span><br><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">state towards that endpoint (and also update the bridged channel as if</span><br>
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">that endpoint had requested the hold itself), but in this case *only*</span><br><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">the 3PCC agent will be able to unhold the channel. The endpoints</span><br>
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">involved will display/act based on the fat that they have been *placed</span><br><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">on hold*, not as if they *placed the call on hold*. Even implementing</span><br>
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">this would require, as Olle said, the ability for Asterisk to signal</span><br><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">hold outwards over a SIP channel, and to remember that it has done so.</span></blockquote>
<div><br></div><div><br></div><div>Have a good weekend folks,</div><div><br></div><div>Cheers</div><div>Chris</div><br><br><div class="gmail_quote">On Fri, Jan 8, 2010 at 2:11 AM, Kevin P. Fleming <span dir="ltr"><<a href="mailto:kpfleming@digium.com">kpfleming@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Olle E. Johansson wrote:<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>
</div>Actually, I think you are conflating two different issues here. In a<br>
two-channel call scenario (the normal bridged call in Asterisk) between<br>
endpoints A and B, there are multiple hold-related situations that can<br>
occur:<br>
<br>
1) A requests 'hold' by informing Asterisk via protocol-specific<br>
mechanisms (SIP, ISDN PRI/Q.SIG(not DAHDI, DAHDI is not signaling), SS7,<br>
IAX2, etc). This results in Asterisk marking the 'A' channel as being<br>
put on hold by A, and also results in changes to the 'B' channel:<br>
<br>
1.1) In the typical scenario, Asterisk begins playing MOH on the 'B'<br>
channel towards B.<br>
<br>
1.2) In some scenarios (currently only supported on IAX2, but possible<br>
on most signaling protocols), Asterisk would send 'hold' indication over<br>
the 'B' channel, and take no other action. Endpoint B would then react<br>
to this hold indication in some fashion locally; a SIP phone (for<br>
example) would indicate on its display that the current call has been<br>
placed on hold by the remote party. If the hold indication was actually<br>
being sent to another switch (Asterisk or otherwise), the scenario<br>
starts all over again as that switch decides what to do to react to the<br>
hold indication.<br>
<br>
1.3) In either case, the *only* party that can revert the state of the<br>
'A' channel to 'active' from 'hold' is endpoint A; no other party in the<br>
equation can do so.<br>
<br>
2) B requests 'hold' by informing Asterisk via protocol-specific<br>
mechanisms (SIP, ISDN PRI/Q.SIG(not DAHDI, DAHDI is not signaling), SS7,<br>
IAX2, etc). This results in Asterisk marking the 'B' channel as being<br>
put on hold by B, and also results in changes to the 'A' channel:<br>
<br>
2.1) In the typical scenario, Asterisk begins playing MOH on the 'A'<br>
channel towards A.<br>
<br>
2.2) In some scenarios (currently only supported on IAX2, but possible<br>
on most signaling protocols), Asterisk would send 'hold' indication over<br>
the 'A' channel, and take no other action. Endpoint A would then react<br>
to this hold indication in some fashion locally; a SIP phone (for<br>
example) would indicate on its display that the current call has been<br>
placed on hold by the remote party. If the hold indication was actually<br>
being sent to another switch (Asterisk or otherwise), the scenario<br>
starts all over again as that switch decides what to do to react to the<br>
hold indication.<br>
<br>
2.3) In either case, the *only* party that can revert the state of the<br>
'B' channel to 'active' from 'hold' is endpoint B; no other party in the<br>
equation can do so.<br>
<br>
What is being discussed here in the CSTA/AMI thread (as has been<br>
discussed many times before) is that you want to create scenarios 3 and<br>
4, where a 3PCC agent takes action to cause behavior that is exactly<br>
identical to scenarios 1 and 2, but without requiring the existing<br>
endpoints to do it. This is possible over CSTA with most PBXes today,<br>
because the PBX has the ability to cause the phones it is connected to<br>
to act *as if* the user of the phone had pressed the 'Hold' button, so<br>
this can be done at the request of the 3PCC agent. The 3PCC agent can<br>
also unhold the call, which has the same effect as if the user of the<br>
phone did so (and in fact if the user of the phone does it, the 3PCC<br>
agent is notified of that occurrence so it can update its state properly).<br>
<br>
It seems unlikely that this will be possible for Asterisk to do with SIP<br>
devices without using proprietary SIP extensions for each manufacturer's<br>
devices; I'm not aware of any SIP standards, drafts or other proposals<br>
to allow a SIP endpoint to signal to the endpoint it is connected to<br>
that it should initiate hold back towards the requesting endpoint as if<br>
its user had done so.<br>
<br>
The best that can be hoped for is that a 3PCC agent could request a<br>
channel be placed on hold and that Asterisk would initiate the hold<br>
state towards that endpoint (and also update the bridged channel as if<br>
that endpoint had requested the hold itself), but in this case *only*<br>
the 3PCC agent will be able to unhold the channel. The endpoints<br>
involved will display/act based on the fat that they have been *placed<br>
on hold*, not as if they *placed the call on hold*. Even implementing<br>
this would require, as Olle said, the ability for Asterisk to signal<br>
hold outwards over a SIP channel, and to remember that it has done so.<br>
<font color="#888888"><br>
--<br>
Kevin P. Fleming<br>
Digium, Inc. | Director of Software Technologies<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
skype: kpfleming | jabber: <a href="mailto:kpfleming@digium.com">kpfleming@digium.com</a><br>
Check us out at <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
</font><div><div></div><div class="h5"><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>