Ozeki VoIP SDK - Product Guide
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.
Introduction
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.
SIP Commands
| Method | Description: |
|---|---|
| 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. |
Architecture diagram
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 li>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 |
SIP Messages
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.
Related Pages
People who read this also read...
User Datagram
Protocol (UDP)
Real-time Transport Protocol (RTP)
Session Description Protocol (SDP)