[asterisk-bugs] [Asterisk 0018788]: [patch] Add Device State Information CCSS for Generic Devices

Asterisk Bug Tracker noreply at bugs.digium.com
Wed Mar 16 16:32:33 CDT 2011


The following issue has been ASSIGNED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18788 
====================================================================== 
Reported By:                p_lindheimer
Assigned To:                rmudgett
====================================================================== 
Project:                    Asterisk
Issue ID:                   18788
Category:                   Core/CallCompletionSupplementaryServices
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     confirmed
Target Version:             1.10
Asterisk Version:           SVN 
JIRA:                       SWP-3120 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 307669 
Request Review:              
====================================================================== 
Date Submitted:             2011-02-10 19:57 CST
Last Modified:              2011-03-16 16:32 CDT
====================================================================== 
Summary:                    [patch] Add Device State Information CCSS for
Generic Devices
Description: 
CCSS Asterisk Device States Proposal

Proposal to 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
and
even as they come available there may be other reasons why one may choose
not
to take advantage of the native abilities and stick with the generic
implementation which is quite capable and could be greatly enhanced by
adding
device state capabilities that a phone could subscribe to with a BLF key
in
conjuction with Asterisk hints.

The advantages of this would allow a single button that could be
programmed to
trigger a CCSS related feature code that can be used to both Request and
Cancel CCSS requests as well as display the current state of a CCSS
Request.

By example, I may have a single button that when no lit, there is no
active 
CCSS request. When I press that button, my dialplan can query the state
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 and even when Request() thinks it was successful, the
actual
request could ultimately fail. Once lit, further feedback can now 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 mappings should be configurable since the BLF being 
used on a give phone type may vary. The idea is to allow some level of 
customization as to the phone's behavior.

As an example, I may want my BLF key to go solid once I have requested a
callback. I may then want my 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, or I may want it to blink when the callee is ready
buy I
am busy, giving me a visual indication that the target is available as I
may
want to get off the line so that the callback can be successful.

The proposal is to send device state information back via the
ast_devstate_prov_add callback for any device (or at least generic
device)
as they traverse through the state machine. We simply provide a map
between CC_STATE values and corresponding AST_DEVICE state values.

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

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

One would then subscribe a blf button to *823000 which would point to the
dialplan 
that handled my CCSS Requests/Cancels using the available DEVICE_STATE() 
information about ccss:sip/3000 to make the decsions what to do.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-03-16 16:32 lmadsen        Assigned To               => rmudgett        
2011-03-16 16:32 lmadsen        Target Version            => 1.10            
2011-03-16 16:32 lmadsen        Description Updated                          
2011-03-16 16:32 lmadsen        Additional Information Updated                  
 
======================================================================




More information about the asterisk-bugs mailing list