I never saw the first computer I worked on. It was 1975 and I was a senior at Coronado High School in Scottsdale, Arizona. Those of us who took advanced math classes were allowed to sign up for a course in computer programming. I forget the instructor’s name, but I remember that he only had a summer class’ worth of BASIC programming and it didn’t take long before his students became the teachers. We soaked this stuff up like sponges.
That first computer was an HP something or other and physically resided far from campus. We connected to it via 110 baud teletypes with acoustic couplers. Those of you as seasoned (i.e. old) as I am will recall that to connect to a computer you would dial a phone number and then place the telephone receiver in a device that listened to and sent squeaky modem signals. 110 baud sounds dreadfully slow today, but back then it was all we knew and it was truly magic.
A lot has changed since then. At home I have a 50 megabyte connection to the Internet and there are plenty of times when I think it’s too slow. The smart phone I carry in my pocket has an order of magnitude more processing power than that HP mainframe. In my business life, I am constantly thinking about higher performance and the scalability of the systems I help design.
The creators of SIP were concerned with speed and scale, too. They understood that tightly bound systems are inherently difficult to grow. They also understood that separating distinct tasks leads to higher performance across a large number of nodes.
The result of this thinking is that SIP separates signaling from media. In fact, there are distinct protocols that create this separation of church and state. SIP deals with signaling, Session Description Protocol (SDP) deals with media, and both can be dealt with independently.
For a detailed look at SDP, please see my blog, Understanding Session Description Protocol (SDP).
This separation becomes quite clear if you look inside the protocols themselves. Each maintains its own references to IP addresses and ports and there is nothing in SIP that says that the element that processes signaling must also be the element that processes media. They could be different services on the same physical device or they could be completely different devices.
This becomes very apparent with the Avaya Aura Session Manager. A Session Manager deals strictly with SIP signaling and never sees any of the resultant media streams. This allows an Aura system to scale up to 100,000 SIP endpoints and 360,000 Busy Hour Call Completions (BHCC) per Session Manager. As users begin to use multiple SIP devices and more and more applications move to SIP, this kind of scale becomes important to even a medium sized business.
Other communications vendors can take advantage of this separation, too, and those that follow a distributed approach may have similar numbers. However, those that continue to take a more monolithic approach will see lesser speeds and smaller scale.
There are, of course, times when signaling and media will exist on the same box, but even then that logical separation can be used to great advantage. A case in point would be the Session Border Controller. An SBC processes both signaling and media, but can be designed in such a way that each stream has its own set of hardware to allow processing to occur at wire or near wire speeds. Latency and delay can make a VoIP call painful to endure and SIP provides developers with the framework to minimize both.
As communication moves into the cloud, scale and performance become even bigger concerns. While 100,000 endpoints might sound big for most enterprises, a service provider will want numbers in the millions. I can guarantee you that those service providers will build their solutions on SIP and will take full advantage of SIP’s distributed architecture.
Tao, Zen, and Tomorrow 