[Home]

Summary:ASTERISK-17385: [patch] Add Device State Information CCSS for Generic Devices
Reporter:Philippe Lindheimer (p_lindheimer)Labels:
Date Opened:2011-02-10 19:57:55.000-0600Date Closed:2011-04-14 13:22:39
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/CallCompletionSupplementaryServices
Versions:1.8.2 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ccss_devstate_proposal.c
( 1) ccss_devstate.patch
( 2) ccss.trunk.18788.patch
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.

****** ADDITIONAL INFORMATION ******

ccss_devstate_proposal.c being attached which is a combination proposal, all of the functions and structures that I believe are needed to implement this, and a patch showing where some specific calls would be placed.

This is completely un-tested (not even run through a compiler). My C coding is EXTREMELY rusty so I though I would put this out for review and then see if I can recruit someone who knows what they are doing to help make this a reality.
Comments:By: Philippe Lindheimer (p_lindheimer) 2011-02-11 13:20:12.000-0600

new working patch coming that at least has some of this operational and tested :)
By: Philippe Lindheimer (p_lindheimer) 2011-02-11 13:38:35.000-0600

Attached ccss_devstate.patch against 1.8 r307673

tested:

- Hints are generated and updated
- DEVICE_STATE() returns proper state information
- changing default values in configuration file works (well tested one state)
By: Ronald Chan (loloski) 2011-02-11 14:21:53.000-0600

this is good stuff!!, and also a good candidate for inclusion FreePBX 2.9, will test and be back to this shortly :D
By: Philippe Lindheimer (p_lindheimer) 2011-02-11 14:55:07.000-0600

loloski,
thanks, this is being added to FreePBX 2.9 as we speak, I now need to accommodate the DEVICE_STATE() information.

This has been posted to the review board:

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

would be ultra cool if an exception process could be made, being that CCSS is brand new in 1.8, to get this added into 1.8 and not have to wait until 1.10.
By: Ronald Chan (loloski) 2011-02-11 15:24:19.000-0600

indeed!, it would be cool if there's an exception but i have a gut feeling and history tell that it won't it's proven period, but we are still hoping ^_^, anyway thanks for the patch will test momentarily i just need to yank some spare utp in my bat cave for my phone :)

Regards,

Ronald
By: Philippe Lindheimer (p_lindheimer) 2011-02-11 20:30:28.000-0600

loloski, If you are running out of SVN on FreePBX 2.9, you can load up the campon module as I've taken advantage of the patch there to deliver BLF enabled feature codes for all extensions and a toggle code. I'll need to add a configuration setting to turn this off if one does not have the patch but will first wait and see how the review process goes.
By: Richard Lynch (richardlynch) 2011-02-12 12:43:10.000-0600

Seems like this just extends existing functionality, in a way that seems very unlikely to break BC...
By: Telecom & Internet Integrated Solutions (teleweb) 2011-02-15 11:59:43.000-0600

I agree that this should definitely go into the next point release of Asterisk 1.8!
By: Ronald Chan (loloski) 2011-02-15 20:59:46.000-0600

Updates: on my limited testing, this works for me (TM), tested with noname china phone :D
By: Joe McConnaughey (kenn10) 2011-02-24 07:32:11.000-0600

We really need this functionality to give Asterisk more features that the proprietary systems offer.
By: Philippe Lindheimer (p_lindheimer) 2011-02-24 10:24:19.000-0600

Uploaded latest patch consistent against review board version:

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

best to also apply patch from issue:

https://issues.asterisk.org/view.php?id=18763

when testing this as well.
By: Digium Subversion (svnbot) 2011-04-14 13:22:37

Repository: asterisk
Revision: 313744

U   trunk/CREDITS
U   trunk/configs/ccss.conf.sample
U   trunk/main/ccss.c

------------------------------------------------------------------------
r313744 | rmudgett | 2011-04-14 13:22:36 -0500 (Thu, 14 Apr 2011) | 67 lines

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 ASTERISK-17385)
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/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=313744