I said that I would move the current 2.9 alpha to beta stage “later this week” and here we already slipping the schedule… No, I was not off getting my last fix on My Favorite Sail Boat before she finds a new home, though that would not have been a bad idea 🙂 I’ve been busy cranking on some of the Asterisk 1.8 features that we’ve discussed, more on that…
As I’ve mentioned in past blogs, there are a lot of really cool features that were introduced in Asterisk 1.8. One of them is the CONNECTEDLINE() function and underlying SIP update abilities that now allow us to deliver reverse CallerID. This means things like a call pickup can show you who the caller was on your CID, or if someone transfers a call on you, you can see who they transferred it to.
The main feature that I’ve been working on is the Call Completion Supplemental Services, or Camp-On. Being a new feature that is quite sophisticated in nature, I naturally ran into a handful of bugs or short comings. Mark Michelson has been a great help adding in a few bits and pieces where there were minor short comings in the implementation. I have hit a couple bugs (Asterisk 18763 and Asterisk 18772) that have an impact on the FreePBX implementation. One of them I provided a fix for, the other one requires a temporary work-around kludge that I have added to FreePBX for now until it can get resolved.
My big distraction, but in a good way, has been to implement Device States for Camp-On. I wouldn’t exactly call the lack of this a bug in the feature, but it is clearly a ‘huge missing piece’ that would otherwise make this feature code join the long list of cryptic features that no one uses because unless there is a button on the phone, with good feedback, it won’t be used.
So what am I talking about wrt to all this Device State stuff? Well the CCSS team who implemented this feature did so with a lot of foresight and for that I commend them! They designed the feature to work in conjunction with native technology abilities so as to maximize the usage and flexibility of CCSS. What does this mean? It means, if your phone supports the Camp-On feature and the channel driver has been modified to handle it natively, then you can reap the benefit of CCSS in conjunction with native phone capabilities! This usually translates into very usable features with dedicated buttons on the phones, subscriptions by the phones to be updated about availability or to update the CCSS core about their availability, etc. The good news is at this time both SIP and ISDN channels support native CCSS implementations. The bad news is that I’m not aware of any SIP phones that actually support it:(
Knowing that we can’t count on technology specific capabilities the team also created a generic agent and monitor type. An agent is the person trying to make a call and camping on the ‘victim’ where as the monitor is the ‘victim’ who we are stalking! The implementation takes advantage of the great Device State subsystem that Asterisk has, watching the various states of monitors and when they come available, informing agents if they themselves have not become busy. This works great from the testing that I’ve done! It’s also possible, at the CLI, to see what state various agents are in since all of this is implemented with an internal state machine in Asterisk.
Now all of this works great but as I mentioned, there is no feedback today. I can camp on to an extension that I am trying to reach, but we can’t provide any feedback on the phone showing that there is an active callback pending. That also means we can’t provide a single button that would let you camp onto the last call made, and with the same button, cancel that callback request. What we would like to do is the following. Upon making a call and not reaching our party (or their line ringing busy), press a single button to request a callback from them. Once done, the light on the button lights up. This gives us a visual indication and reminder that we are currently waiting on a callback. If we decide to cancel the callback, we can simply press the same button and a cancellation is put through, turning off the light. Taking this a step further, while we are waiting on a request, we happen to be talking to someone else when our party becomes available. Our Call Camping light now begins to blink rapidly, giving us a visual indication that our party has become available, since we might want to take the opportunity to end the current call so we can get connected to our otherwise hard to reach victim! Similarly, even if we are not on the phone, our light rapidly blinks in conjunction with the call completion callback that rings our phone so that we can connect with our party.
As you can see from this description, we have taken a great phone feature and made it extremely usable in the above scenarios. I’ve implemented this capability in Asterisk with the addition of DEVICE_STATE information to CCSS such that with this patch, generic devices can now have a BLF enabled button that allows them to toggle camp-on requests on and off for the last call made, show visual feedback that a request is pending, show visual feedback that a callback is now possible if you are on the phone, as well as visual feedback when receiving a call back that the incoming call is a callback! Do you think that this capability is important for a proper implementation of call camping? If so, please help test out this patch and post feedback on the ticket. If you are a developer, your feedback on the Code Review board would also be great. I’d like to make sure at a minimum this gets introduced into Asterisk 1.10. To the extent that one could make an argument that this is really ‘lacking’ in the current implementation and could be considered a border line ‘bug’ then maybe one could make the argument to actually get it introduced into the 1.8 branch as a ‘bug fix.’ (And just to be clear, from what I have so far tested, I think the developers of this did a great job implementing this, and this is simply the Open Source process taking a good thing and making it great!)
Ok … enough of that, a couple book keeping items. I’ll try to get the move from alpha to beta this weekend so as to get caught up. Another thing I want to get back to is the Community conference call that I mentioned a few blogs back. In order to get a feel for what size bridge we may need, any of you reading this who would definitely plan on joining the call, please reply to this thread so I can try to be prepared for the onslaught. Then I’ll try to schedule and work out the logistics soon.
Philippe – on behalf of the FreePBX Team!