When most of us think about PBX systems, we usually associate these with cumbersome usage, confusing dialing codes and in most cases – a PBX system is automatically associated with the annoying task of transferring a call from one handset to another. Lately, I’ve been thinking deeply about how people use PBX systems, is this really the only way to use a PBX system? is there something else to the mix? can we really enrich one of the oldest operational paradigms in the world? – and for that matter, can the public be re-educated to assimilate a new breed of PBX systems or services?

As to answering the question of re-educating the public, I guess I’ll have to leave that question to the head shrinks. As to answering the latter, enriching the PBX experience is both achievable and advisable. When I say enriching, I mainly talk about your ability to bring to the IP phone functionality usually not associated with it. Imagine to have the ability to receive a stock exchange RSS feed to your phones idle screen, notice that you stock is either rising or falling, and by the flick of a button – either sell or buy. We’ve all come accustomed to IP phones that look like the one of the right. A whole bunch of buttons, that in most cases have no direct use when our phone is utilized using a single account. However, these buttons can be externally re-assigned and re-programmed to achieve greater functionality – surpassing the normal behavior of just making phone calls.

The technology involved exists on almost every high-end IP phone on the market (well, at least those made by SNOM, Aastra, Cisco and Polycom – most of the Chinese makers don’t have this) – it’s called a Mini Browsers. Mini Browsers are exactly what they are called, these are simplified versions of your typical Internet browser. Some vendors had produced their own XML based Mini browser markup language (SNOM, Cisco, Aastra) while others had decided to provide a sub-set of XHTML (Polycom). The variations between the vendors are at the neck deep of the problems of using Mini Browsers, and that is that the formats are considerably different. Sure, SNOM had more or less adopted Cisco’s general structure, however, it still varies.

Through the utilization of this technology, it is possible to create phone based browser applications, that seem native to the phone user, as the general interface resembles the native phone interface. It is now the developers job to make the web interface displayed to the user as seamless and as native as possible, keeping in mind that the developer must remain agnostic to the information retrieval layer. Most companies leave their phone systems and these tasks to their system administrators and infrastructure team, however, this task is far beyond their capabilities and skill set. Creating an agnostic IP phone minibrowser dislplay layer, capable of utilizing multiple vendors and models, is a question of content management and content rendering, very must similar to the content transcoding problem that is common to the mobile content world – in other words, a sys-admin will create an ad-hoc solution, a programmer will create a proper, well structured, well designed solution that carry the enterprise beyond its initial needs and requirements.

A short example of how these interfaces work can be found here – on my company blog.

Today I got the chance to speak at a Polycom half-day convention, mainly to speak about Asterisk and HDvoice. Now, putting aside the part about HDvoice (I’m getting a post about that on its own), I gotten to the point where I believe that I’m currently perceived as being an eccentric.

So, why am I eccentric? very simple, I’ve reached a point where I can say things that may be perceived as rude – and write it off an being an eccentric quirk.

I’ve talked about Asterisk ability to support Video, while the current Polycom VVX1500 video phone isn’t yet supported at its fullest. One of the people in the crowd mentioned some sleezy,al-cheapo, SIP Video phone (to be more exact, he’s the local distributor) – and I claimed that I don’t count that phone as a comparison to Polycom or other VoIP Video phones, simply because in my view it’s not a worth while comparison. Comm’on, let’s be realistic, can you compare a Polycom VVX1500 (an HDvoice Video phone) with some shitty sub-VGA SIP Video phone from China? the mere comparison is simply insulting for Polycom.

Shortly after negating that phone, the person stood up and left the room. At the break, a friend said to me that I shouldn’t have said that, in order to come out the bigger man. Common, the guy is surely making a joke of himself. I commented: “I’ve said what I said, I stand by my opinion – besides, you know I’m eccentric – eccentric people say eccentric things” – he agreed that I’m eccentric, after all, you can’t be an Open Source evangelist without being an eccentric – now can you?

As a part of my job, I manage and maintain customer platform – usually operating in the Calling Cards and VoIP services market. Over the course of time, I’ve learned to rely on some providers in this world, knowing that they work 99.999% of the time.

For example, i like working with DID numbers provided by Level3, GlobalCrossing and Voxbone. I have a fair dislike for DIDX and the like, simply due to the fact that their reliability, not the DIDX platform, but the providers themselves is questionable – at best.

So, why is this post called: “Battliing the GlobalCrossing CallerID blues”? simple, because the list that appeared before is now missing GlobalCrossing. Over the course of time, I’ve learned to live with the various quirks of GlobalCrossing, mainly, their inability to provide a proper e164 number as a part of the SIP headers. Usually, I would receive headers from global crossing that look like this:

FROM HEADER: <sip:3054230103@xxx.xxx.xxx.xxx>;tag=as54cf6928

Now, I new that in general, that didn’t post much of a problem, as long as it was consistent. However, starting today, some of the requests started looking like this:

FROM HEADER: <sip:13054230103@xxx.xxx.xxx.xxx>;tag=as1213141

However, to make things weird, one INVITE request would carry the non-valid e164 numbering, while the second INVITE may carry the correct format. In other words, there is no way to know exactly if the number is provided in full e164 or not. So, I tried doing some header mangling using Asterisk and other tools, however, nothing helped. Surely the format changed along the way, however, when I changed one side of the system, another side of the system broke – simply because it relied on something else – in other words, a fuck’n mess.

At this point, the problem is not yet resolved and i’m working with my DID provider to remedy the situation – after investigating it, the DID provider is currently bashing the heads at GlobalCrossing to fix the issue on their side. I will report back once I have more information.

If you suffered similar problems with other DID providers, I’d love to hear about it.

One of the biggest questions in the world of Asterisk is: “How many concurrent channels can be sustained with an Asterisk server?” – while many had tried answering the question, the definitive answer still alludes us. Even the title of this post says “3500 concurrent channels with Asterisk” doesn’t really say much about what really happend. In order to be able to understand what “concurrent channels” really means in the Asterisk world, let us take a look at some tests that were done in the past.

Asterisk as a Signalling Only Switch

This scenario is one of the most common scenarios in the testing world, and relies upon the basic principle of allowing media (RTP) to traverse from one end-point to the other, while Asterisk is out of the loop regarding anything relating to media processing (RTP). Examine the following diagram from one of the publicly available OpenSER manuals:

Direct Media Path between phones via a SIP Proxy

As you can see from the above, the media path is established between our 2 SIP endpoints.

This classic scenario had been tested in multiple cases, with varying codec negotiations, varying server hardware, varying endpoints, varying versions of Asterisk – no matter what the case was, the results were more or less the same. Transnexus had reported being able to sustain over 1,200 concurrent channels in this scenario, which makes perfect sense.

Why does it make sense? very simple, as Asterisk doesn’t manage or mangle RTP packets, Asterisk performs less work and the server also consumes less resources.

Asterisk as a Media Gateway

Another test that people had done numerous times is to utilize Asterisk a Media Gateway. People used it as a SIP to PSTN gateway, SIP to IAX2 gateway, even as a SIP to SIP transcoder gateway. In any case, the performance here varied immensly from one configuration to another, however, they all relied on a simple call routing mechanism of routing calls between endpoints and allowing Asterisk to handle media proxy tasks and/or handle codec translation tasks.

Depending on the tested codec, I’ve seen reports of sustain over 300 concurrent channels of media on a single server, while other claim for around the 140 concurrent channels mark – this again mostly relied on various hardware/software/network configurations – so there is nothing new in there.

These tests tell us nothing

While these tests are really nice in the theoretical plane of thinking, it doesn’t really help us in the design and implementation of an Asterisk system – no matter if it is an IVR system, a PBX system or a time entry phone system for that matter – it simply doesn’t provide that kind of information.

The Amazon EC2 performance test

In my previous post, Rock Solid Clouded Asterisk, I’ve discussed the various mathmatics involved in calculating the RoI factors of utilizing Cloud computing. One thing the article didn’t really tell us, did it really work?

Well, here are some of the test results that we managed to validate:

• Total number of Asterisk based Amazon EC2 instances used: 24
• Total number of concurrent channels sustained per instances (including media and logic): 80
• Average length of call: 45 seconds
• Total number of calls served: 2.84 Million dials
• Test length: approximately 36 hours

According to the above data, each server was required to dial an approximate 3300 dials every hour. So, let’s run the math again:

• 3300 Diales per hour
• 55 Dials per minute
• As each call is an average of 45 seconds, this means that each gateway generates 20 calls
  per second, and within 4 seconds fills the 80 channels limit per server.

According to the above numbers that we’ve measured, each of the Amazon EC2 instances used was utilized to about 50% of its CPU power, while consuming a load average of 2.4, which was mostly caused by I/O utilization for SIP and RTP handling.

Conclusion

When asking for the maximum performance of Asterisk, the question is incorrect. The correct question should be: “What is the maximum perfromance of Asterisk, utilizing X as the application layout?” – where X is the key factor for the performance. Asterisk application performance can vary immensly from one application to another, while both appear to be doing the exact same thing.

When asking your consultant or integrator for the top performance, be sure to include your business logic and application logic in the Asterisk server, so that they may be able to better answer your question. Asterisk as Asterisk is just a tools, asking for its performance is like asking how many stakes a butcher’s knife can cut – it’s a question of what kind’a steaks you intend on cutting.

Session Border Controllers (SBCs) are utilized as a means to providing both load balancing and security structures for VoIP networks. To be completely honest, 90% of my customers utilize SBC appliances, be it Acme Packet, Juniper, NexTone or others.

According to a report by Transnesus, a combination of OpenSER and Asterisk can be utilized as a Back-To-Back-User-Agent (B2BUA) structure – however, the general configuration and setup isn’t clear and straight forward. I’ve been thinking to myself: “Why hadn’t anyone written and Open Source SBC? could it be? usually there’s an Open Source alternative to any commercial product”.

Like any other search on the net, I’ve pointed my Firefox to Google, and typed the phrase “Open Source SBC”, aparently, such a thing exists from a company called Solegy – over at the web address: http://www.opensourcesip.org. So, I downloaded the source code, and after a 30 minute compilation phase (bearing in mind working on a Virtual server running under VMWARE Server) – the compilation completed.

Compiling was one thing, running it was a completely different thing – took me a while to realize where the binary is located and how the configuration works out – once I did that was a breeze. On my system, after compilation the binary was located according to the following:

[root@opensbc obj_linux_x86_r]# pwd
/root/OpenSBC-1.1.5-RC1-Bundle/opensbc/obj_linux_x86_r
[root@opensbc obj_linux_x86_r]# ./opensbc -x

Message from syslogd@ at Thu Nov 13 23:15:35 2008 ...
tvms OpenSBC[18900]: Starting service process "OpenSBC" v1.1.5-25

Per the information provided by Solegy, the OpenSBC project supports several modes of operations, ranging according to the following:

Full Mode - By default OpenSBC runs in full mode exposing its capability both as a
relay SIP proxy, Registrar and as a B2B User Agent. When OpenSBC receives an INVITE
or a REGISTER request it would follow the following procedure to make a decision how
to route a request:

● If the Request-URI resolves to a remote domain, the request will be relayed. If a
relay route is available, the request is sent to that route. If a relay route is not
available, then the URI is resolved via DNS.
● If the Startline-URI resolves as a local address and port, the To URI is checked
if it resolves to a local domain and port. If not, the request would be proxied
using Relay Routes or via DNS resolution. The Request URI would be rewritten to point
to the resolved route.
● INVITE: If both Request URI and To URI resolves to a local listener and port, the
B2BUA Route is used to route the INVITE.
● REGISTER: If both Request URI and To URI resolves to a local listener and port, the
local Registrar will process the registration. This would include Authorization of
the user.

B2BOnly Mode - This mode removes the relay capability but exposes the Registrar and
the B2BUA functionalities. This mode does not do the checks performed by Full Mode. It
will always process REGISTER and INVITE as local.

● INVITE: This mode always use B2BUA Route to route calls. If there is not corresponding
route found, a DNS resolutions is done against the Request URI or the To URI in case the
Request-URI resolves to a local address.
● REGISTER: Registrations are always handled by the local registrar.

Proxy Only Mode - This mode removes the B2BUA functionality but exposes Registrar and the
relay SIP Proxy functionalities
● Always uses Relay Routes for all messages including REGISTER. If a relay route is not
configured, Requests will be relayed using DNS resolution. If a registrations is resolved
as local, the registrar would handle the registration including authorization

B2BUpperReg Mode - This is almost the same as the B2BOnly mode but with the additional
capability of relaying registrations to upper registrars.

● INVITE: This mode always uses B2BUA Route.
● REGISTER: For registrations, it performs the Request URI and To URI checking and relay
for a remote domain or process the registration locally for local domains.
● Upper-Registration: This mode also has the capability to hijack-registrations towards
upstream registrars.

Per the above, I didn’t completely understand what I should use for normal IP phones operations, so, I guess I’m more or less on my own on this one. My general understanding says that I need to use the B2BupperReg mode, however, I can’t say I’m totally sure about it – I’ll be experimenting with OpenSBC and the virtual Asterisk servers i’ve written before over the couple of months.

Lately I’ve come to the realization, that we are to blame for our own inability to promote Open Source and the adaptation of Open Source proficiency. Being an Open Source evangelist and consultant, this is very weird to be said by one like myself, however, this is my realization – and I will explain.

In the early days of Open Source adaptations (late 90′s, early 2000), Open Source software was a somewhat magical solution that meant: pay nothing, get more. Software packages like Linux, Apache, mySQL, PostgreSQL and programming languages like PERL and PHP had lowered the bar on the adaptation of new technologies, and enabled a prolific number of solutions and services.

I still remember the early days, when a Windows based Mail Relay would cost anything between 800$ to 1200$, and I would come in with a Linux based solution that would do the same thing for FREE – amazing. As time progressed, so did the technology and the penetration of Open Source into new fields. CRM, ERP, Telecoms, management – all of these now enjoy a diverse number of Open Source solutions. However, the original concept of ‘Open Source = Magical FREE Solution’ had still remained in the minds of managers and business people.

Today we are confronted with ‘would-be’ Open Source solution experts, which adopt and develop upon Open Source products and project various applications. In example, let’s take a look at Asterisk. Asterisk has a multitude of Open Source solutions, ranging from PBX system, Prepaid calling cards, Wholesale routing platforms, Attendance system, Presence systems – and even a plant watering solution. The problem with this ever growing number of solutions is that Asterisk is immediately considered to be: “A magical solution” capable of solving any problem – when it’s not even remotely related to Asterisk. For example, a friend of mine had been asked to develop an Asterisk based solution, that would support a total of 250 concurrent call initiations and up-to 3000 concurrent calls on the system. Any Asterisk developer would take a look at this, and would immediately say: “Hmmm…. this requires several servers, but hey, what about the application itself? that would also have an impact”. Now, the customer of the project has a ‘would-be’ Asterisk tech in his company which said: “I was able to initiate 200 concurrent SIP invites to Asterisk via SIPP, no problem’ – HELLO! STUPID! where’s the application? where’s the database? where’s the user information flow? comm’on, are you listening to yourself speak? or simply are filled with the gasses coming out of your ass that are affecting your brain?

Now, once the customer learns that Asterisk is most probably not the right solution for the problem, he becomes angry. Why? because he now learns that he needs to spend about 10 times more money than he anticipated for the creation of this tool – well, that’s life when you have no idea what you are doing/saying, and you believe in magical solutions. However, we – “The Open Source Community – is the one to blame for this scenario, because we got the world accustomed to the idea that Open Source is like magic – flip the Linux magic wand, and the rest will solve itself.

I’d like to open the floor for discussion on this, as I believe most of you will have something to say about this.

To those of you familiar with the SIP signalling protocol or any other VoIP protocol for all that matter, you are most probably familiar with the issue of traversing DTMF (Dual Tone Multi Frequency) tones correctly over a VoIP link. The main issue is that there is no one standard for doing this. While in the old days of H323, most gateways were utilizing inband signalling (that means sending the tones as part of the media stream), in modern day systems and protocols (such as SIP), most of the time vendor conform to either rfc2833, in-band or SIP-INFO.

Lets not talk about in-band signalling, as this is not interesting, lets talk about rfc2833 for a second. As the RFC document states (http://www.faqs.org/rfcs/rfc2833.html), rfc2833 is defined as “RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals”. Now, while an RFC is a wonderful thing to have, the main issue is that most vendors tend to mess up when dealing with RFC documents. This is why browsers like IE are unable to utilize AJAX or DOM correctly, although the same code will work like a charm on Firefox. Each vendor has its own interpretation of what the RFC means. While most of the basic functionality will be done correctly, room for interpretation causes each vendor to simply create a slight variation of the the standard – meaning, interoperability may not always work correctly.

Now, you are most probably asking: “what the hell is he rambling about now? just test what you need and use it!” – so I did just that. If you are using Asterisk, and you would like to test a new SIP device for proper DTMF compatibility with Asterisk, you are welcome to use my Asterisk based DTMF tester. The DTMF tester enables you to test each of the DTMF signalling method, all from the comfort of your IP device. Simply follow the below testing procedure and you will be able to determine what is the best DTMF mode for you IP device, to be used with Asterisk:

• Register your IP device with my DTMF testing server:
  • SIP Server: venus.greenfieldtech.net
  • SIP Outbound Server: venus.greenfieldtech.net
  • Username: dtmftester
  • Password: dtmftester
  • Codecs: g711u, g711a, gsm and g729
• Once you are registerd, simply dial the following:
  • Dial 100 for SIP-INFO testing
  • Dial 101 for INBAND testing
  • Dial 102 for rfc2833 testing

If you had found usage for this DTMF tester, you are welcome to spread the word about it and also tell me what you think. If you believe additional tools are needed, feel free to leave me a note, I always like to write new tools.