Call Camp-On in 2.9 and “I Thought Alpha was going to go Beta this week”

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!

10 thoughts on “Call Camp-On in 2.9 and “I Thought Alpha was going to go Beta this week”

  1. no there isn’t that I am aware of

    however, I don’t know much about the ISDN native technology modes of the CCSS capability, so it may be that this is possible if you happen to have ISDN lines and that is supported at the trunk level with them.

  2. Let’s say I am repeatedly calling an OUTSIDE number, and it’s busy. (they don’t have call waiting, etc) and I just want the system to redial, and then call my extension when the outside destination is no longer busy. Is there a feature for this, or can it be done?

    THanks!

    ANd thanks for all you do for FreePBX and Asterisk.

  3. Hi,

    I tried to install the camp-on module but I’m getting:

    •Camp-On cannot be installed:
    â—¦Requires engine asterisk (>= 1.8), you have: asterisk 1.8
    Please try again after the dependencies have been installed.

    Is this because FreePBX just doesn’t recognise trunk?

    thepbx2*CLI> core show version
    Asterisk SVN-trunk-r310288M built by root @ mybox on a i686 running Linux on 2011-03-11 14:44:04 UTC
    thepbx2*CLI>

    I seem to remember that being an issue before…

  4. well it says you have 1.8 so it could be we need to improve our algorithm.

    why don’t you file the bug on the issue with the above so we can have a look.

    In the mean time, you can force the version in Advanced Settings to override what we auto-detect.

  5. bpps,

    yes and no:

    See: #4701

    GameGamer43 is suppose to be finishing this off, at the same time he will address: #4818 and get those added also. I’m hoping he can get to them in the next day or two. If you feel like coding though, I’m sure he would not object if you want to add it and submit it.

    The crux is that the underlying plumbing is there, it needs to be added to the GU and then the described dialplan in #4701 needs to be generated. If you want to get an early jump on testing, you could also manually add the described dialplan to a queue manually and test it out.

  6. Call Confirmation ability added to Queues, such that external off PBX numbers can be forced to confirm the Queue call prior to the queue passing on the customer to the answered line. (This will also force confirmation on for any Follow-me that is pursued). The queue can also override the call confirmation message with one specified by the queue, even if ending up in someone’s follow-me that has their own message configured

    was this implemented yet I don’t see it anywhere?

  7. kenn10,

    The CCSS in conjunction with the referenced patch and the other features that I have implemented in FreePBX gives you all of those abilities as described with AUTO CALLBACK.

    You can Set an Alert-Info and/or a CID prepend and I have the dialplan so that the CID on a callback is that of the person you were trying to call (plus any prepend you may choose if any). In addition, I have also allowed for an Alert-Info and CID Prepend to be configured for the person ‘being stalked’ in case they want to know a ‘creep’ is calling them:)

    The first request though, the ability to transfer someone to a user is effectively a form of ‘private queue’ and is not what CCSS is about. We have not yet implemented anything like that though clearly with the use of queue functionality it could be done. Of course there is also parking but of course that is not quite the same either.

    The ideas and feedback is great though! For now, ALL of the BLF functionality requires the patch. I have implemented and published a beta version of the Camp-On module which adds all the required settings to the Extension Configuration page plus a host of other settings and defaults in the Advanced Settings section. For now, the module assumes you have the patch though if not, you will still be able to use most settings though the toggle and BLF related functionality will not work.

    I’ll see what happens with the patch to decide if we need to add settings that hides all the ‘good’ stuff unless you tell it you have the patch. It would be great NOT to have to do that!

  8. In the older Bell terms, camp-on used to refer to the ability of the switchboard to “camp” a caller onto a busy extension and let them wait for that busy station to hang up. The caller would hear music until the call went through. Once the extension hung up, the call completed. There was timing on the camp-on so after the wait period expired, the call returned to the attendant for service. A camped call did not go to voice mail. I’d love to see that feature in FreePBX. It would be a tremendous help for busy receptionists.

    Likewise, several proprietary PBX’s initiated a form of auto-callback who’s features were much as you are describing your camp-on feature. If you dialed an extension and it either did not answer, went to voice-mail or was busy, you could either flash switchhook (on analog phone) and dial a code, or on a digital phone, press a button labeled “AUTO CALLBACK” which monitored the destination and rang back when available. The function allowed you to stalk someone who had not been in the office but as soon as they used the phone, the change of state initiated the callback to you. The lamp on the “AUTO CALLBACK” button worked as you have described plus the display would show CID of who you called plus “CLBK” or something to show it was a callback call. On any phones, it did a triple ring to indicate a special call (and I know bellcore rings are not standard on all phones so that’s an issue.)

    So this is two variations of using the new features to bring Asterisk more into line with proprietary PBX’s. Does any of this sound useful or fit in with what you are doing?

    One thing Asterisk might do that propriety non-SIP systems can’t would be to query the network to see if a remote phone is busy. Does Asterisk 1.8 have the ability to do that for callback of a busy or non-answering phone outside of the Asterisk system?

    Does anyone else in the community like the sound of these features?

  9. This installed OK for me on stock Asterisk 1.8.3 and FreePBX 2.9.0.7. However, whilst I can see the CallCompletionRequest executing, no callbacks occur.

    Do I need some particular combination of Call Waiting or Voicemail disabled? Or maybe a different Technology Mode or install an asterisk patch? Perhaps a How-to guide exists, that’s so far escaped my googling…

Leave a Reply