<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/2042/1/7/_/styles/combined.css?spaceKey=AST&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/AST/Device+State+information+for+the+CCSS+generic+agent.">Device State information for the CCSS generic agent.</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~lmadsen">Leif Madsen</a>
</h4>
<div id="versionComment">
<b>Comment:</b>
Update some additional formatting inline.<br />
</div>
<br/>
<h4>Changes (5)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >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. <br> <br></td></tr>
<tr><td class="diff-changed-lines" >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 <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>DEVICE_STATE()<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> associated with that caller to determine whether they should be calling <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>CallCompletionRequest()<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> or <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>CallCompletionCancel()<span class="diff-added-chars"style="background-color: #dfd;">}}</span>.</span> 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 <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>CallCompletionRequest()<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> 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. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-changed-lines" >The <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>DEVICE_STATE<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> 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. <br></td></tr>
<tr><td class="diff-unchanged" > <br>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. <br> <br></td></tr>
<tr><td class="diff-changed-lines" >Device state information is sent back via the <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>ast_devstate_prov_add()<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> callback for any generic CCSS device as it traverses through the state machine. You simply provide a map between <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>CC_STATE<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> values and the corresponding <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>AST_DEVICE<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> state values. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-changed-lines" >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 <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>SIP/3000<span class="diff-added-chars"style="background-color: #dfd;">}}</span>.</span> You could then create a feature code for that extension that may look something like: <br></td></tr>
<tr><td class="diff-unchanged" > <br>{noformat} <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >{noformat} <br> <br></td></tr>
<tr><td class="diff-changed-lines" >You would then subscribe a BLF button to <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{\</span>*823000<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> which would point to the dialplan that handled CCSS requests/cancels using the available <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>DEVICE_STATE()<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> information about <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">{{</span>ccss:sip/3000<span class="diff-added-chars"style="background-color: #dfd;">}}</span></span> to make the decision about what to do. <br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<p>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.</p>
<p>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.</p>
<p>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 <tt>DEVICE_STATE()</tt> associated with that caller to determine whether they should be calling <tt>CallCompletionRequest()</tt> or <tt>CallCompletionCancel()</tt>. 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 <tt>CallCompletionRequest()</tt> 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.</p>
<p>The <tt>DEVICE_STATE</tt> 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.</p>
<p>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.</p>
<p>Device state information is sent back via the <tt>ast_devstate_prov_add()</tt> callback for any generic CCSS device as it traverses through the state machine. You simply provide a map between <tt>CC_STATE</tt> values and the corresponding <tt>AST_DEVICE</tt> state values.</p>
<p>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 <tt>SIP/3000</tt>. You could then create a feature code for that extension that may look something like:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>exten => *823000,hint,ccss:sip/3000
</pre>
</div></div>
<p>You would then subscribe a BLF button to <tt>*823000</tt> which would point to the dialplan that handled CCSS requests/cancels using the available <tt>DEVICE_STATE()</tt> information about <tt>ccss:sip/3000</tt> to make the decision about what to do.</p>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;">
<a href="https://wiki.asterisk.org/wiki/users/viewnotifications.action" class="grey">Change Notification Preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/AST/Device+State+information+for+the+CCSS+generic+agent.">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=13076180&revisedVersion=4&originalVersion=3">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/Device+State+information+for+the+CCSS+generic+agent.?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>