The Basics Of How SIP (Session Initiation Protocol) Drives Your VoIP System Design And Function

Hold on to your seat. Finally....here's an explanation of SIP (Session Initiation Protocol) in laymans terms. It's pretty basic.... but should be just what you need to understand how this VoIP application fits into your VoIP system design plans and function. Afterall, not everyone in the business world can talk or understand "techie speak".

SIP - Session Initiation Protocol. It is exactly that - the main purpose of SIP is to set up and tear down media (audio/video/etc data) sessions, and also to manage endpoints and other things.

SIP devices communicate (usually) on UDP port 5060. When one device wants to start a call to another, it sends an INVITE message. Included in this is the SDP, session description protocol, which explains exactly what form the data will take (audio/video/etc, what codec, etc). When they agree and are ready to start exchanging media (data), RTP (realtime transport protocol) is used to actually exchange the data. RTP functions on any range of ports, which are assigned to each endpoint. The endpoints negotiate and choose acceptable ports on each side.

Sip also does a few other thing such as REGISTER. Register allows a SIP device with a dynamic IP to recieve calls. A common use is an ATA (vonage type box) - when you plug it in, it registers to its server, and renews the registration every XXX seconds to keep the server up to date (in case its IP changes).

SIP has a handful of other functions. For example NOTIFY can be used to pass assorted data to an endpoint (many IP phones will reboot when you NOTIFY them with the data 'check-sync'). NOTIFY is also used for MWI. There is also SUBSCRIBE, which allows an extension to subscribe to notifications of the status of a voice mail box (for MWI) or an extension/channel (for BLF....(busy lamp field, the thing which makes a guy's button light up when he is on the phone).

There are a handful of other SIP functions, for example REFER (transfer), BYE (hangup), etc.

SIP has three ways of dealing with DTMF signals sent while the call is in progress:

* Inband- Send the tones as audio in the media stream. Only works with G.711 ulaw/alaw codec, other codecs will distort the DTMF.

* RFC2833- Send the tones out of band but still attached to the audio stream via RTP.

* INFO- send the tones as SIP INFO packets along the control channel.

RFC2833 is probably the most common.

There is also a set of extensions called SIMPLE (Sip Instant Messaging, Presence, and Location Extensions). Put simply, this is a way to use SIP for instant messaging type uses.

SIP does not play nice with NAT routers, mostly because of RTP - the SDP includes the source and destination IP addresses where media should be sent to, which are not always correct.

For example - if you have an ATA behind NAT, it will use its own IP (192.168) when creating the SDP. NAT will correctly translate the header, so the packet is addressed from the network's external IP. However the contents of the packet still have a 192.168 IP as the destination, which the server cannot send media to. This commonly results in calls which work except one or both parties cannot hear each other.

There are two ways to solve this - media gateways (sip-aware router that rewrites the SDP) or more commonly, STUN (Sip Traversal Under NAT). STUN is a protocol which allows a SIP device to, with the help of a STUN server, discover its own external IP and what kind of NAT it is behind. It can then write the SDP correctly and negotiate the RTP session so the NAT will not bother it.

SIP shares many response codes with HTTP. IE- 404=extension not found, 401=unauthorized, etc.

Lastly in case you are ever looking at a SIP transcript - SIP performs authentication (where passwords are used) using digests. Thus, a typical authenticated session looks like this:

device tries to connect (INVITE)....
server responds trying....
server responds 401 unauthorized with some auth info....
device responds OK....
device tries to connect (INVITE) this time with hashed auth data....
server responds trying....
server responds ok (and other phone starts to ring)....

Hopefully the above gives you a basic understanding and arms you with enough to be able to ask the right questions....for the right reasons...at the right time.