More Progress With Some of the Asterisk 1.8 Features

Despite the busy past week with ITEXPO and luckily missing all the air traffic disruptions across the country, there's been some good progress on a few of the Asterisk 1.8 features that we are still targeting for version 2.9. Of course being in Miami by the beach brought back memories of my Favorite Sail Boat which looks like it may just be that, memories. (If you ever wonder where my avatar picture comes from, that's it, and as you can see if you take a peak, she's a beautiful and fun boat!)

We've had a few more Alpha testers hit 2.9 and so far have not heard much concern so I'll probably move it up to Beta status some time this coming week and see about getting more eyes on it. There are still a handful of tickets queued up in the milestone that we are working towards but the one's I've been hitting on this past week are two new Asterisk 1.8 features, Call Completion Supplemental Services (CCSS, Call Camping, Camp-On, or what ever your favorite name is for this feature) and the CONNECTEDLINE() Reverse Caller ID updating ability.

The Camp-On feature has been sought after for quite a long time, ticket 778 in the tracker and we are currently up to 4800. It looks like the Asterisk developer did a fairly nice job providing for a lot of flexibility in the configuration of this feature which has come in handy as we try to wrap FreePBX around it. There are a handful of issues of which some look like Asterisk bugs and others might be great opportunities where some small additions could go a long way to making the feature even more useful! I’ve got an email into the Asterisk author of CCSS to discuss these with him but either way, it will be rolling out soon with a new Camp-On module.

The CONNECTEDLINE() functionality, enabled in conjunction with proper settings of ‘sendprid’ and ‘trustprid’ that match your phone, and of course the phone’s ability to support this feature has turned out to work quite well so far. If you’ve been testing this on your own, with no code changes you may find you are getting CID’s that look like “device” <device_num> sent back to your calling phone. This has to do with the fact that FreePBX stores it’s CIDs in AstDB and in fact the device level CIDs are simply an identifier that we use to map the device to the actual user/extension. As a result, getting these CIDs updated properly requires some “fine tuning” by sprinkling a handful of calls to the CONNECTEDLINE() function in strategic locations within the dialplan so as to update the CIDs back to the calling parties with the proper CID and Display Name.

So far in my testing, with the above enhancements, I’ve been able to get the Calling Phone (testing with Aastra 55is right now) to get the proper CID information when making normal calls, upon a blind transfer going through (so you know who is on the other end of the transfer), in call pickup tests with *8 (have not tested directed call pickup yet), and when calling a Ring Group (upon an extension answering the Ring Group call, their CID information is sent back to the calling phone so they know who picked up). So far, so good. We’ll look forward to your testing as there will certainly be more convoluted calling scenarios where the information ends up breaking so when you run into one of these, please provide LOTS of details as to the calling sequence so we can re-produce it and continue to fine tune.

Other work continues on the various other fronts that I’ve blogged about related to 2.9 as some of the other guys have been quite busy such as tm1000 on the End Point manager, mickecarlsson looks like he has been busy with the Extension Settings module he’s been working on (and a whole lot of other stuff), and mbrevda has been laying low on the visible 2.9 front but has been doing some really awesome work that we have planned to introduce in the 2.10 Milestone, of which some of it may even find it’s way into 2.9 still!

So … for now, I ask you to load up 2.9 and help get us more exposure. In the meantime, we should be cranking out a good chunk of the remaining ‘bigger’ items that are still pending in the tickets (like some planned Queue features and a handful of other stuff) over the next week or so, and as mentioned, we’ll evaluate the move from Alpha to Beta. (As of this writing, there have been about 130 systems that we’ve been able to track touching 2.9, we’d like to bump that up a bit which should happen when we move up the confidence latter!)

Philippe - On behalf of the FreePBX Team!

thanx for the reply im using sip over tcp and tls since (almost a year ago with excellent results and sip srtp encryption in 1.8 asetrisk since october with excellent results also as new changes are merely a new item in config to populate with yes or no options it should not include any inestabilty to freepbx or asterisk …
best regards


there have been other blogs over the last couple months to solicit ideas, not to say that we are not always open to more.

However, please make sure to file these requests in the trac ticket system or they will be quickly missed. We’ll also evaluate the relative stability of various new features prior to putting them in. It’s always possible to use the ‘custom’ sip.conf files we provide if you need to do more ‘experimental’ work.

My understanding is the sip/tcp is still quite a bit in the experimental state even in 1.8. Any information wrt to the relative stability of some of these would be helpful to decide what we expose.

Hi philippe there are some important asterisk 1.6 and 1.8 items forgotten and with simple solution

for example the optional use in extensions of srtp encryption and tls or sip over tcp support
in .conf files its as simple as adding for each extension encryption=yes or transport=tls / tcp it should be the same as adding those fields in extensions page

the other items should be easily updated as more fields (already there )in sip general config but right now we can t put any options in one or many extensions

Best regards