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

Thu Jan 7 16:57:31 CST 2010

Thanks for the details Kevin.

Firstly,
Your detailed 1, 1.1, 1.2, 2, 2.1 format of describing call states and call
actions are extremely handy
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?

Secondly, in response to this

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.

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?

Which kind of addresses this:

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.

Have a good weekend folks,

Cheers
Chris

On Fri, Jan 8, 2010 at 2:11 AM, Kevin P. Fleming <kpfleming at digium.com>wrote:

> 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
>
> _______________________________________________
> --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/20100108/69d0a95a/attachment.htm 