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

[Kevin P. Fleming]

Olle E. Johansson wrote:

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

Actually, I think you are conflating two different issues here. In a
two-channel call scenario (the normal bridged call in Asterisk) between
endpoints A and B, there are multiple hold-related situations that can
occur:

1) A requests 'hold' by informing Asterisk via protocol-specific
mechanisms (SIP, ISDN PRI/Q.SIG(not DAHDI, DAHDI is not signaling), SS7,
IAX2, etc). This results in Asterisk marking the 'A' channel as being
put on hold by A, and also results in changes to the 'B' channel:

  1.1) In the typical scenario, Asterisk begins playing MOH on the 'B'
channel towards B.

  1.2) In some scenarios (currently only supported on IAX2, but possible
on most signaling protocols), Asterisk would send 'hold' indication over
the 'B' channel, and take no other action. Endpoint B would then react
to this hold indication in some fashion locally; a SIP phone (for
example) would indicate on its display that the current call has been
placed on hold by the remote party. If the hold indication was actually
being sent to another switch (Asterisk or otherwise), the scenario
starts all over again as that switch decides what to do to react to the
hold indication.

  1.3) In either case, the *only* party that can revert the state of the
'A' channel to 'active' from 'hold' is endpoint A; no other party in the
equation can do so.

2) B requests 'hold' by informing Asterisk via protocol-specific
mechanisms (SIP, ISDN PRI/Q.SIG(not DAHDI, DAHDI is not signaling), SS7,
IAX2, etc). This results in Asterisk marking the 'B' channel as being
put on hold by B, and also results in changes to the 'A' channel:

  2.1) In the typical scenario, Asterisk begins playing MOH on the 'A'
channel towards A.

  2.2) In some scenarios (currently only supported on IAX2, but possible
on most signaling protocols), Asterisk would send 'hold' indication over
the 'A' channel, and take no other action. Endpoint A would then react
to this hold indication in some fashion locally; a SIP phone (for
example) would indicate on its display that the current call has been
placed on hold by the remote party. If the hold indication was actually
being sent to another switch (Asterisk or otherwise), the scenario
starts all over again as that switch decides what to do to react to the
hold indication.

  2.3) In either case, the *only* party that can revert the state of the
'B' channel to 'active' from 'hold' is endpoint B; no other party in the
equation can do so.

What is being discussed here in the CSTA/AMI thread (as has been
discussed many times before) is that you want to create scenarios 3 and
4, where a 3PCC agent takes action to cause behavior that is exactly
identical to scenarios 1 and 2, but without requiring the existing
endpoints to do it. This is possible over CSTA with most PBXes today,
because the PBX has the ability to cause the phones it is connected to
to act *as if* the user of the phone had pressed the 'Hold' button, so
this can be done at the request of the 3PCC agent. The 3PCC agent can
also unhold the call, which has the same effect as if the user of the
phone did so (and in fact if the user of the phone does it, the 3PCC
agent is notified of that occurrence so it can update its state properly).

It seems unlikely that this will be possible for Asterisk to do with SIP
devices without using proprietary SIP extensions for each manufacturer's
devices; I'm not aware of any SIP standards, drafts or other proposals
to allow a SIP endpoint to signal to the endpoint it is connected to
that it should initiate hold back towards the requesting endpoint as if
its user had done so.

The best that can be hoped for is that a 3PCC agent could request a
channel be placed on hold and that Asterisk would initiate the hold
state towards that endpoint (and also update the bridged channel as if
that endpoint had requested the hold itself), but in this case *only*
the 3PCC agent will be able to unhold the channel. The endpoints
involved will display/act based on the fat that they have been *placed
on hold*, not as if they *placed the call on hold*. Even implementing
this would require, as Olle said, the ability for Asterisk to signal
hold outwards over a SIP channel, and to remember that it has done so.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming at digium.com
Check us out at www.digium.com & www.asterisk.org