At this time, Session Initiation Protocol (SIP) is probably the most commonly used VoIP signaling protocol. SIP does nothing more than set up, tear down, or modify connections in which RTP can transfer the audio data. SIP was designed by Henning Schulzrinne (Columbia University) and Mark Handley (University College of
London) in 1996. Since that time, it’s gone through several changes. SIP is a lightweight protocol and is similar in many ways to HTTP (Hyper-Text Transport Protocol). Like HTTP, SIP is completely text-based.This makes debugging easy and reduces the complexity of the protocol.To illustrate SIP’s simplicity, let’s use HTTP
“conversation” as an example.
At your workstation, fire up your favorite Web browser. In the URL field, type http://www.syngress.com/Help/Press/press.cfm. Several things happen between your Web browser and the Syngress Web server. First off, your local machine does a DNS (Domain Name Service) lookup of www.syngress.com.This will return an IP address of the Syngress Web server. With this IP address, your browser and computer know how to “contact” the Syngress Web server.The browser then makes a connection on TCP port 80 to the Syngress Web server. Once the connection is made, your Web browser will send a request to “GET” the
“/Help/Press/press.cfm” file.The Syngress Web server will respond with a “200 OK”
and dump the HTML (Hyper-Text Markup Language) to your Web browser and it’ll be displayed. However, let’s assume for a moment that the “press.cfm” doesn’t exist.
In that case, the Syngress Web server will send to your browser a “404 Not Found”
Message. Or, let’s assume that Syngress decided to move the “press.cfm” to another location. In that case, your Web browser might receive a “301 Moved Permanently”
message from Syngress’s Web server, and then redirect you to the new location of that file.
The 200, 404, and 301 are known as “status codes” in the HTTP world. Granted, the HTTP example is a very basic breakdown, but this is exactly how SIP works.
When you call someone via SIP, the commands sent are known as “SIP Methods.”
These SIP methods are similar to your browser sending the GETcommand to a remote Web server.Typically, these SIP methods are sent on TCP port 5060. See Table 5.1.
Table 5.1SIP Methods
INVITE Invite a person to a call.
ACK Acknowledgment. These are used in conjunction with INVITE messages.
BYE Terminates a request
CANCEL Requests information about the remote server. For example,
“what codecs do you support?”
OPTIONS This “registers” you to the remote server. This is typically used if your connection is DHCP or dynamic. It’s a method for the remote system to “follow you” as your IP address changes or you move from location to location.
Continued
Table 5.1 continuedSIP Methods
REGISTER This “registers” you to the remote server. This is typically used if your connection is DHCP or dynamic. It’s a method for the remote system to “follow you” as your IP address changes or you move from location to location.
INFO This gives information about the current call. For example, when “out-of-band” DTMF is used, the INFO method is used to transmit what keys where pressed. It can also be used to
transmit other information (Images, for example).
As stated before, response codes are similar and extend the form of HTTP/1.1 response codes used by Web servers. A basic rundown of response codes is shown in Table 5.2.
401 Unauthorized: Used only by registrars. Proxies should use Proxy authorization 407.
402 Payment required (reserved for future use)
403 Forbidden
404 Not found (User not found)
405 Method not allowed
Continued
Table 5.2 continuedResponse Codes
Code Definition
406 Not acceptable
407 Proxy authentication required
408 Request timeout (could not find the user in time)
410 Gone (the user existed once, but is not available here any more) 413 Request entity too large
414 Request-URI too long
415 Unsupported media type
416 Unsupported URI scheme
420 Bad extension (Bad SIP protocol extension used. Not understood by the server.)
493 Undecipherable (could not decrypt S/MIME body part) 500 Server internal error
501 Not implemented (The SIP request method is not implemented here.)
502 Bad gateway
503 Service unavailable
504 Server timeout
505 Version not supported (The server does not support this version of the SIP protocol.)
Table 5.2 continuedResponse Codes
Inter-Asterisk eXchange (IAX) is a peer-to-peer protocol developed by the lead Asterisk developer, Mark Spencer.Today, when people refer to IAX (pronounced eeks), they most likely mean IAX2, which is version 2 of the IAX protocol.The orig-inal IAX protocol has since been depreciated for IAX2. As the name implies, IAX2 is another means to transfer voice and other data from Asterisk to Asterisk.The pro-tocol has gained some popularity, and now devices outside of Asterisk’s software sup-port the IAX2 protocol.
The idea behind IAX2 was simple: build from the ground up a protocol that is full featured and simple. Unlike SIP, IAX2 uses one UDP port for both signaling and media transfer.The default UDP port is 4569 and is used for both the destination port and the source port as well.This means signaling for call setup, tear down, and modification, along with the UDP datagrams, are all sent over the same port using a single protocol. It’s sort of like two protocols combined into one! This also means that IAX2 has its own built-in means of transferring voice data, so RTP is not used.
When IAX was being designed, there where many problems with SIP in NAT (Network Address Translation) environments. With SIP, you had signaling happening on one port (typically TCP port 5060) and RTP being sent over any number of UDP ports.This confused NAT devices and firewalls, and SIP proxies had to be developed. Since all communications to and from the VoIP server or devices happen over one port, using one protocol for both signaling and voice data, IAX2 could easily work in just about any environment without confusing firewalls or NAT-enabled routers.
This alone is pretty nifty stuff, but it doesn’t stop there! IAX2 also employs var-ious ways to reduce the amount of bandwidth needed in order to operate. It uses a different approach when signaling for call setup, tear down, or modification. Unlike