Did you know?This SDK was used to build:
Ozeki Phone System XE - VoIP PBX Software for Developers Which is a high performance PBX system supporting Mobile and Desktop phones.
It was also used to create Ozeki 3D VoIP softphone. A cool SIP client that allows 3D Video calls.
Session Initiation Protocol (SIP)
Session Initiation Protocol (SIP) is IETF signaling protocol used for VOIP and other text and multimedia communication sessions such as voice and video calls over Internet Protocol (IP). In this overview you can find some information about this protocol.
SIP can be used for creating, modifying and terminating two-party (unicast) or multiparty (multicast) sessions. These sessions include Internet telephone calls, multimedia distribution, multimedia conferences, instant messaging, file transfer and online games.
SIP is very much like Hypertext Transfer Protocol (HTTP) as it uses similar model to the HTTP request/response transaction model. It employs similar header structure and text-based formats. Session Description Protocol (SDP) defines the SIP message bodies for phone calls.
In this way SIP transactions consist of a client request that invokes a particular method or function on the server and at least one response. SIP reuses most of the header fields, encoding rules and status codes of HTTP, and providing a readable text-based format.
SIP is primarily employed for setting up and tearing down voice or video calls. However, in the process SIP needs to be adopted with other protocols since SIP is only involved in the signaling portion of a communication session. It assists in the connection of communication channels while the factual connection is created by SDP and RTP protocols. Therefore, voice and video stream communications in SIP applications are transmitted with Real-time Transport Protocol (RTP) while parameters like port numbers, protocols, codecs for these media streams are specified and negotiated with the use of Session Description Protocol (SDP).
Terminology for SIP
|User Agent (UA):||It is a local network endpoint that manages SIP sessions. It can function either as a client (User Agent Client) that establishes calls and sends SIP requests; or as a server (User Agent Server) that monitors incoming calls, receives the requests and returns a SIP response.|
|SIP Proxy Server:||It is a mediator that functions as a server. Its main role is receiving SIP requests and ensuring that these requests will be handled or forwarded to the user.|
|SIP Redirect Server:||It accepts SIP requests, responds to them and transmits these requests to the client.|
|SIP Registrar Server:||It accepts registration requests and locates the addresses of clients to the sign-in name or SIP URI of users.|
|Gateways:||They control calls and translate formats to other ones.|
The identification of users in a SIP network is realized with SIP addresses. The format of these SIP addresses is the following: sip:userID@domain.com. If users want to register they need to do so with the help of a registrar server and they also need to use their SIP addresses mentioned above. After this procedure this information will be available for the location server from the registrar server, if it is requested.
SIP users are also able to move between end systems since the location server makes it possible to locate the end user by protocols. However, it can occur that users login from more than one station or it is also possible that the location server does not have the accurate information. In these cases more than one address could be returned to the user. If a SIP proxy server mediates the request, all the returned addresses will be tested until the proxy server finds the user. If it is a SIP redirect server, it transmits all the returned addresses to the caller in the contact header field of the invitation response.
|INVITE||It establishes a session between user agents and contains information on calling, called users and media to be exchanged.|
|ACK||It is the confirmation of the session establishment.|
|BYE||It terminates a session between two users and can be sent by any user.|
|CANCEL||It terminates pending requests like an outstanding INVITE. If a session is established it can be terminated by BYE.|
|OPTIONS||It requests information about the capabilities about the server, the caller or other devices. With this method media capabilities can be checked before issuing an INVITE.|
|REGISTER||It can be used by clients for login and notify its address with a SIP registrar server.|
Figure 1 - System architecture
- Phone A invites Phone B
- Proxy locates Phone B while responds to Phone A that it is trying to build the session
- Phone B responds to Proxy that the session is in progress - Proxy responds to Phone A that the session is in progress
- Phone B responds to Proxy that it establishes the session - Proxy responds to Phone A that Phone B has established the session
- Phone A acknowledges the session with ACK message - Proxy responds to Phone B that Phone A has acknowledged the session
- RTP stream: it is the phone call/conversation itself
- Phone B hang up and responds message BYE to proxy - Proxy responds message BYE to Phone A
- Phone A confirms with OK to the Proxy - Proxy responds to Phone B that Phone A has confirmed with OK
SIP response types
SIP responses include a Status Code that is a three digit number and can have values from 100 to 699. Response class is indicated by the first digit of the Status Code. Beside Status Code a Reason Phrase is also included that is the text description of the response.
|Provisional (1xx):||Refers to the fact that the request has been received and it is being processed|
|Success (2xx):||The action has been received, processed, and accepted|
|Redirection (3xx):||It signs that additional actions are needed to complete the request|
|Client Error (4xx):||It can refer to a bad syntax in the request or it cannot be executed at the server|
|Server Error (5xx):||A valid request has not been fulfilled by the server|
|Global Failure (6xx):||Any server cannot fulfilled the request|
The following headers occur in SIP messages:
General Headers can be used for both requests and responses and they include basic information such as TO and FROM fields.
Request Headers are for request messages and they include SUBJECT and PRIORITY fields.
Response Headers used in response messages and provide UNSUPPORTED and RETRY-AFTER fields.