|
The Basics Of How SIP (Session Initiation Protocol) Drives Your VoIP System Design And Function Hold on to your seat. Finally....here's a particular explanation of SIP (Session Initiation Protocol) in laymans terms. it is pretty basic.... but should be just what you need to understand how the VoIP application fits into your VoIP system design plans including function. Afterall, not everyone in the business world should talk or understand techie speak. SIP - Session Initiation Protocol. It is exactly that - the main purpose of SIP is to set up including tear down media (audio/video/etc data) sessions, including additionally to manage endpoints including other things. SIP devices communicate (usually) on UDP port 5060. at the time 1 device wants to start a call to another, it sends a particular INVITE message. Included in the is the SDP, session description protocol, which explains exactly what form the data could take (audio/video/etc, what codec, etc). at the time they agree including 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 including choose acceptable ports on each side. Sip additionally does a few other thing such as REGISTER. Register allows a SIP device with a dynamic IP to recieve calls. A common use is a particular ATA (vonage type box) - at the time you plug it in, it registers to its server, including 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 should be used to pass assorted data to a particular endpoint (many IP phones could reboot at the time you NOTIFY them with the data 'check-sync'). NOTIFY is additionally used for MWI. There is additionally SUBSCRIBE, which allows a particular extension to subscribe to notifications pertaining to the status of a voice mail box (for MWI) or a particular extension/channel (for BLF....(busy lamp field, the thing which makes a guy's button light up at the time he is on the phone). There are a handful of other SIP functions, for example REFER (transfer), BYE (hangup), etc. SIP has 3 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 could 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 additionally a set of extensions called SIMPLE (Sip Instant Messaging, Presence, including Location Extensions). Put simply, the 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 including destination IP addresses where media should be sent to, which are not always correct. For example - if you have a particular ATA behind NAT, it could use its own IP (192.168) at the time creating the SDP. NAT could correctly translate the header, so the packet is addressed from the network's external IP. However the contents pertaining to the packet still have a 192.168 IP as the destination, which the server absolutely cannot send media to. the commonly results in calls which work except 1 or both parties absolutely cannot hear each other. There are 2 ways to solve the - 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 including what kind of NAT it is behind. It should then write the SDP correctly including negotiate the RTP session so the NAT could 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) the 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 including arms you with enough to be able to ask the right questions....for the right reasons...at the right time.
|