|
|
 |
 |
| |
SIP – Stumbling Into Success
SIP History
The SIP protocol represents the future of telecommunications. SIP started off as a university project at the University of Columbia. Jonathan Rosenberg and Henning Schulzrinne are the original authors.
SIP its early beginnings at Columbia and IETF, SIP has taken a life of its own. Its real splash occurred when it entered the wireless world. SIP made its entry into the wireless world with the Push-To-Talk application at major CDMA telecommunications such as Verizon Wireless. That was the stepping stone to much bigger
fields. Where it really landed its ultimate gig was when it entered the GSM 3G arena . Now SIP is playing for keeps.
Poor Design, Inevitable Future
As a protocol, SIP wasn’t prepared for the future role it would play. Born in the dot com environment, it was designed after HTTP, when network bandwidth seemed endless, and text-based protocols were in their heyday. Now that the party is over, the telecom world is paying the price. Nevertheless, the telecom world doesn’t stand back to pick and choose which features in a protocol it will take and which features it will keep. In a protocol, you get what you get.
Still, SIP’s future is certain. SIP is the backbone of IMS, which, in turn, will be the backbone of all future telecommunications networks.
HTTP Roots
Anyone versed in the HTTP protocol, will immediately recognize SIP constructs. It starts off with a command and version:
INVITE sip:somebody.softwareinvent.com SIP/2.0
Initially, the goal was to be simple, easy-to-use, and lightweight. Reminiscent of HTTP’s format:
GET /someplace HTTP/1.1
Initially many of the paradigms followed HTTP. But as SIP began to be deployed in much broader contexts, it rapidly evolved into a more complex beast. Now, SIP messages in IMS networks can be immense messages with multiple, embedded body segments in SDP and a variety of formats.
Troubleshooting SIP Networks
Networks in general can be finicky. They clog up, they wear out, they crash. SIP networks are no different. SIP networks can experience difficulties on a variety of levels. Protocol analyzers are used to troubleshoot problems on these networks. However, the more vast and complex IMS networks become in today’s world, the more difficult they are to deploy and troubleshoot. Typical troubleshooting techniques follow a common set of paradigms. Some of the most common indicators to watch are:
a. Delays between request and response
b. Error response counts, in general
c. 500- and 600-level error counts, in particular
d. High rates of re-transmission counts
e. Large numbers of short-duration calls/sessions
Delays
When an INVITE is sent out, the time it takes for the 100 Trying or 180 Ringing to be sent back is an indicator of network load. If a SIP Proxy is overloaded with other requests, the response time for sending out he Trying or Ringing will be large. This is not so much a problem that an end user will notice as it is a gauge of the overall performance of the SIP network.
Error Counts
When large numbers of error counts are seen on the network, obviously something is not right. However, some level of errors is typically expected and even acceptable. What’s important is that the error level count is within the correct range, and whether or not spikes in error counts are occurring. Spikes can occur, of course, when a burst of network traffic occurs, among other reasons.
500- and 600-Level Errors
500- and 600-level errors typically indicate that something abnormal or unacceptable is occurring on the network. In high-volume traffic networks, these problems can be particularly difficult to solve. It is particularly important in such circumstances to use a more high-powered protocol analyzing solution, such as Agilent Technology’s Distributed Performance Manager, to track down these problems and isolate the cause.
Re-transmissions
When SIP requests receive no response, the protocol is design to try again. If proxy elements are overloaded, the requests may not receive responses. The monitoring of this scenario will help isolate cases that case elements to be overloaded.
Short Duration Calls
Have you ever picked up the phone and heard no dial tone? Or dialed a number and heard to ring. You may have just assumed that you did something wrong, hung up, and tried again. On the second attempt everything went smoothly, so you wrote the whole experience off to hitting a wrong key. In actuality, the telecommunications equipment may have been the culprit. Since users will typically just hang up and try again if a glitch occurs, then the number of such calls is actually a metric that can be used to measure network performance.
Summary
SIP is the protocol of the future. Good, bad, or indifferent, the telecom world will need to get to know its strengths and weaknesses, and how to use it in real-world networks.
Brian Moody
April 2, 2008
Brian is a telecommunications software consultant at Software Invent, Inc.
|
|
