VoIP: fundamentals of SIP and related topics - part #1 basic concepts of SIP
5 min read
Here we are with the second appointment with the mini-series about VoIP.
You can find the pilot here:
In this episode I’ll talk about the basic concepts of SIP:
- Session Initiation Protocol
- Transaction, dialog e session
- Request e response
- B2BUA, server e proxy SIP
SIP: Session Initiation Protocol
SIP is an application layer protocol; it can establish, modify and terminate a multimedia session, such as a VoIP call. SIP mainly uses 5 features in managing a communication session:
- user location: to determine the location of the user to communicate with
- user availability: to determine the willingness of the called user to participate in the communication
- user capabilities: to determine the parameters to be used for the media stream
- session setup: to establish the session between two or more users
- session management: to manage transfers, modification of session parameters and session termination.
However, SIP is not a complete communication system, it is only one of the components to be used for complete communication. SIP is usually used together with the SDP protocol (for the description of the multimedia session) and RTP (for the real-time transport of the multimedia streaming). We will discuss about it in part #3: SDP & RTP article.
The main 4 stages of a SIP session are:
- location: search for the location of an endpoint
- signal: signaling the willingness to communicate with it
- negotiation: negotiation of session parameters
- teardown: session closure
The registration of the VoIP account (done through the REGISTER packets) is the way in which SIP servers can acquire the location information (IP addresses, ports and contacts) of their users; during registration, the location server receives the REGISTERS from its users and saves (usually in a database) the association of IP address: port and contact, through a binding operation. This data will be useful to the SIP server when it has to contact the user to route a direct call to him (location stage).
In SIP, therefore, registration is used for the routing of incoming calls while it has no role in the authorization of outgoing calls, which is done with the Proxy-Authorization mechanism inserted within the INVITE.
Transaction, dialog e session
SIP is a transactional protocol based on a REQUEST / RESPONSE model, similar to the HTTP model. Each SIP transaction consists of a single REQUEST and at least one RESPONSE (0 or more provisional and one or more final responses) to it. The transaction will be destroyed after sending the final response.
A SIP dialog is a peer-to-peer relationship between two UA (user agents) that persists for a certain time and it’s a series of transactions between this two SIP peers. The INVITE is the only SIP packet that can establish a dialog and the response can be either 2xx or 101–199 with To tag (a failure response does not establish a dialog). A SIP dialog is uniquely identified by From-tag, To-tag and Call-id.
A SIP session is a collection of participants and media streams between them; it is participated by clients (such as SIP phones, softphones, etc) and by servers (such as SIP registrar, SIP location, SIP proxy).
Request e response
A SIP request is identifiable by the Request-Line as the first line of packet. The Request-Line contains the method name, the Request-URI and the protocol version.
INVITE sip: email@example.com SIP / 2.0
The main methods are 6:
- REGISTER: is used by the UA to indicate its physical location to a SIP registrar server
- INVITE: is used to start a session (or to update one in progress)
- ACK: is used to confirm that a final response to an INVITE has been received
- CANCEL: is used to terminate a pending INVITE, which did not receive a final response
- BYE: is used to end the session
- OPTIONS: is used to make a request to servers about their capacity other common methods are SUBSCRIBE, NOTIFY, PUBLISH, INFO.
A SIP response is identifiable by the Status-Line as the first line of packet. The Status-Line contains the protocol version followed by the Status-Code in numerical form, followed by the reason phrasees
SIP / 2.0 200 OK
The are 6 types of responses (divided in 2 macro categories): PROVISIONAL RESPONSE
- 1xx provisional response: show the receipt of the request, its processing and the status of the server
FINAL RESPONSE (indicate to the UAC the final response of the UAS, resulting from the processing of the REQUEST)
- 2xx success: indicate the positive reception, understanding and acceptance of the request
- 3xx redirection: indicate that further actions are required to complete the request
- 4xx client error: tell that the request contains incorrect syntax or that it cannot be satisfied by this server
- 5xx server error: tell that this server cannot fulfill an apparent valid request
- 6xx global error: tell that the request cannot be satisfied by any server
B2BUA, server e proxy SIP
A B2BUA (back to back user agent) is a logical entity that receives SIP requests and processes them as if it were a UAS (user agent server), therefore as if it were the ultimate recipient of the request. To know how to respond to the request, a B2BUA also acts simultaneously as a UAC (user agent client) and generates new requests; it will then manage a dialog with the UAC from which the requests arrive and a dialog with the final UAS that must receive them. A B2BUA maintains the status of the dialog and will have to participate in every request of that dialog. Why use a B2BUA: it is used when you need to have full control of the requests arriving on your SIP server in order to build on it the business logic (for example a billing system).
A SIP server is a network element that receives SIP requests and sends replies. Some examples of SIP servers: proxy, UAS, registrar server.
A SIP proxy is an intermediary entity that acts as a server and client with the purpose of getting requests to clients. The tasks of a proxy are:
- routing management: its job is to find the way to get the request to the right client
- policy compliance management: for example checking that a user can make the call
That’s all for this episode too.
Let me know what you think about it.
Thanks a lot for reading, sharing and comment this article.
Thanks to undraw.co for the beautiful illustration I used in the header
To be continued in " part #2: the basic SIP headers " …
Did you find this article valuable?
Support Giovanni Tommasini by becoming a sponsor. Any amount is appreciated!