SIP is very similar to HTTP in the way it works. The SIP address is just like an e-mail address. An interesting feature used in SIP proxies is alias, so you can have multiple SIP addresses such as:
In the SIP architecture, we have user agents and servers. SIP uses a peer-to-peer distributed model with a signaling server. The server handles just the signaling, while the user agent clients and the user agent servers handles signaling and media.This is depicted in the figure below:
In the SIP model, a user agent, usually a SIP phone, will start communicating with its SIP proxy, seen here as the outgoing proxy, to send the call using a message known as INVITE.
The outgoing proxy will see that the call is directed to an outside domain. It will seek the DNS server for the address of the target domain and resolve the IP address. Then, the outgoing proxy will forward the call to the SIP proxy responsible for DomainB.
The incoming proxy will query its location table for the IP address of agentB. If this address was inserted in the location table by a previous registration process, so the incoming proxy can locate the address. Now with this address, it can forward the call to agentB.
After receiving the SIP message, agentB will have all the information required to establish an RTP session (usually audio) with agentA. Using a message such as BYE will terminate the session.
Usually VoIP providers don't implement a pure SIP trapezoid, they don't allow you to send calls to outside domains, because this affects the revenue stream. They implement a topology closer to a SIP triangle.
Below, you can see the main components of the SIP architecture. The entire SIP signaling flows through the SIP proxy server. On the other hand, the media signaling, transported by the RTP protocol, flows directly from one endpoint to another. Some of the components will be briefly explained in the list below.
UAC (user agent client)—Client or terminal that starts the SIP signaling.
UAS (user agent server)—Server that responds to the SIP signaling coming from a UAC.
Proxy Server—It receives requests from a UA and transfers them to another SIP proxy if this specific terminal requested is not under its domain.
Redirect Server—This receives requests and sends back to the caller including data about the destination, instead of sending directly to the callee.
Location Server—This provides the callee's contact addresses to Proxy and Redirect Servers.
The Proxy, Redirect, and Location servers are usually available physically in the same computer and software.
The SIP protocol employs a component called a registrar. It is a server that accepts REGISTER requests and saves the information received in these packets on the Location server for their managed domains. The SIP protocol has a discovery capacity; in other words, if a user starts a session with another user, the SIP protocol has to discover an existing host where the user can be reached. The discovery process is done by a Location server that receives the request and finds where to send it. This is based in a Location database maintained by the Location server per domain. The Registrar server may accept other types of information, not only the client's IP addresses. It can receive other information such as CPL (Call Processing Language) scripts on the server.
Before a telephone can receive a call, it needs to be registered within the location database. In this database we will have all phones associated with their respective IP addresses. In our example, you will see the SIP user <[email protected]> registered at the IP address 200.180.1.1.
RFC3665 defines best practices to implement a minimum set of functionality for a SIP IP communications network. Below are the flows defined according to RFC3665 for the register transactions:
According to RFC3665, there are five basic flows associated with the process of registering a user agent, which are as follows:
A successful new registration—after sending the Register request, the user agent will be challenged against its credentials. We will see this in detail in the chapter dedicated to authentication.
An update of the contact list—Since it is not a new registration, the message already contains the digest and a "401" message won't be sent. To change the contact list, the user agent just needs to send a new register message with the new contact in the CONTACT header field.
Request for current contact list—In this case, the user agent will send the CONTACT header field empty, indicating the user wishes to query the server for the current contact list. In the 200 OK message, the SIP server will send the current contact list in the CONTACT header field.
Cancellation of a registration—The user agent now sends the message with an EXPIRES header field of 0 and a CONTACT HEADER field configured as '*' to apply to all existing contacts.
Unsuccessful Registration—The UAC sends a Register Request and receives a "401 Unauthorized" message, in exactly the same way as the successful registration. In the sequence, it produces a hash and tries to authenticate. The server, detecting an invalid password, again sends a "401 Unauthorized" message. The process will be repeated for the number of retries configured in the UAC.