Add Device State Information CCSS for Generic Devices.

Add Asterisk Device State information and callbacks to the Call Completion
Supplemental Services for generic agents.

There are currently not many devices that have native support for CCSS.
Even as the devices become available there may be other reasons why one
may choose to not take advantage of the native abilities and stick with
the generic implementation.  The generic implementation is quite capable
and could be greatly enhanced by adding device state capabilities.  A
phone could then subscribe to the device state with a BLF key in
conjunction with Asterisk hints.

The advantages of the device state information would allow a single button
to: request CCSS, cancel a CCSS request, and display the current state of
a CCSS request.

For example, you may have a single button that when not lit, there is no
active CCSS request.  When you press that button, the dialplan can query
the DEVICE_STATE() associated with that caller to determine whether they
should be calling CallCompletionRequest() or CallCompletionCancel().  If
there is currently a pending request, then the dialplan would cancel it.
This also has the advantage of showing the true state of a request, which
is an asynchronous call, even when CallCompletionRequest() thinks it was
successful.  The actual request could ultimately fail.  Once lit, further
feedback can be provided to the caller about the current state of their
request since it will be updated by the CCSS State Machine as appropriate.

The DEVICE_STATE mapping is configurable since the BLF being used on a
given phone type may vary.  The idea is to allow some level of
customization as to the phone's behavior.

As an example, you may want the BLF key to go solid once you have
requested a callback.  You may then want the LED to blink (typically
ringing) when either the callback is in process, which is a visual
indication that the incoming call is the desired callback.  You may want
it to blink when the callee is ready but you are busy, giving you a visual
indication that the target is available as you may want to get off the
line so that the callback can be successful.

Device state information is sent back via the ast_devstate_prov_add()
callback for any generic CCSS device as it traverses through the state
machine.  You simply provide a map between CC_STATE values and the
corresponding AST_DEVICE state values.

You could then generate hints against these states similar to what is
possible today with Custom Devstates or MeetMe states.  For example, you
may have an extension 3000 that is currently associated with device
SIP/3000.  You could then create a feature code for that extension that
may look something like:

exten => *823000,hint,ccss:sip/3000

You would then subscribe a BLF button to *823000 which would point to the
dialplan that handled CCSS requests/cancels using the available
DEVICE_STATE() information about ccss:sip/3000 to make the decision about
what to do.

(closes issue #18788)
Reported by: p_lindheimer
Patches:
      ccss.trunk.18788.patch uploaded by p lindheimer (license 558)
      Modified with final reviewboard comments.
Tested by: p_lindheimer, loloski

Review: https://reviewboard.asterisk.org/r/1105/


git-svn-id: http://svn.digium.com/svn/asterisk/trunk@313744 f38db490-d61c-443f-a65b-d21fe96a405b

1 files changed, 43 insertions, 1 deletions

diff --git a/configs/ccss.conf.sample b/configs/ccss.conf.sample
index bb78cad0c..2636f7ec9 100644
--- a/configs/ccss.conf.sample
+++ b/configs/ccss.conf.sample
@@ -6,12 +6,54 @@
 ;
 
 [general]
-; There is only a single option that may be defined in this file.
 ; The cc_max_requests option is a global limit on the number of
 ; CC requests that may be in the Asterisk system at any time.
 ;
 ;cc_max_requests = 20
 ;
+; The cc_STATE_devstate variables listed below can be used to change the
+; default mapping of the internal state machine tracking the state of
+; call completion to an Asterisk Device State value. The acceptable values
+; that can be provided are as follows, with a description of what the
+; equivalent device BLF that this maps to:
+;
+;	UNKNOWN      ; Device is valid but channel didn't know state
+;	NOT_INUSE    ; Device is not used
+;	INUSE        ; Device is in use
+;	BUSY         ; Device is busy
+;	INVALID      ; Device is invalid
+;	UNAVAILABLE  ; Device is unavailable
+;	RINGING      ; Device is ringing
+;	RINGINUSE    ; Device is ringing *and* in use
+;	ONHOLD       ; Device is on hold
+;
+; These states are used to generate DEVICE_STATE information that can be
+; included with Asterisk hints for phones to subscribe to the state information
+; or dialplan to check the state using the EXTENSION_STATE() function or
+; the DEVICE_STATE() function.
+;
+; The states are in the format of: "ccss:TECH/ID" so an example of device
+; SIP/3000 making a CallCompletionRequest() could be checked  by looking at
+; DEVICE_STATE(ccss:SIP/3000) or an Asterisk Hint could be generated such as
+;
+; [hint-context]
+; exten => *843000,hint,ccss:SIP/3000
+;
+; and then accessed with EXTENSION_STATE(*843000@hint-context)
+; or subscribed to with a BLF button on a phone.
+;
+; The available state mapping and default values are:
+;
+; cc_available_devstate = NOT_INUSE
+; cc_offered_devstate = NOT_INUSE
+; cc_caller_requested_devstate = NOT_INUSE
+; cc_active_devstate = INUSE
+; cc_callee_ready_devstate = INUSE
+; cc_caller_busy_devstate = ONHOLD
+; cc_recalling_devstate = RINGING
+; cc_complete_devstate = NOT_INUSE
+; cc_failed_devstate = NOT_INUSE
+
 ;
 ;============================================
 ;           PLEASE READ THIS!!!