This section introduces some basic SIP operations using a simple example. Let's examine this message sequence between two user agents in the next image. You can see several other flows associated with session establishment in the RFC3665.
The messages are labeled in sequence. In this example, userA uses an IP phone to call another IP phone over the network. To complete the call, two SIP proxies are used.
userA calls userB using its SIP identity, called the SIP URI. The URI is similar to an e-mail address such as sip:[email protected]. A secure SIP URI can be used too, such as sips:[email protected]. A call made using sips: (secure SIP) will use a secure transport (TLS-Transport Layer Security) between the caller and the callee.
The transaction starts with userA sending an INVITE request addressed to userB. The INVITE request contains a certain number of header fields. Header fields are named attributes that provide additional information about the message. They include a unique identifier, the destination, and information about the session as shown here:
The first line of the message contains the method name. The following lines contain a list of header fields. This example contains the minimum set required. We will briefly describe these header fields as follows:
VIA: This header field contains the address which will be used to send the responses back for this request. It also contains a parameter called branch that identifies this transaction. The Via header defines the last SIP hop as IP, transport, and transaction-specific parameters. Via is used exclusively for routing back the replies. Each proxy adds an additional Via header. It is a lot easier for replies to find their route back using the Via header than to refer back to the location server or DNS.
TO: This contains the name (display name) and the SIP URI (
sip:[email protected]) to the destination originally selected. The TO header field is not used to route the packets.FROM: This contains the name and SIP URI (
sip:[email protected]) that indicates the caller ID. This header field has a tag parameter containing a random string that was added to the URI by the IP phone. It is used for purposes of identification. The tag parameter is used in the TO and FROM fields. It serves as a general mechanism to identify the dialog, which is a combination of the Call-ID along with the two tags—one from each participant in the dialog. Tags can be useful in parallel forking.CALL-ID: This contains a globally unique identifier for this call generated by the combination of a random string and the hostname or IP address from the IP phone. A combination of the TO, FROM, and CALL-ID tags fully defines an end-to-end SIP relation known as a SIP dialog.
CSEQ: The CSEQ or command sequence contains an integer and a method name. The CSEQ number is incremented with each new request inside a SIP dialog and is a traditional sequence number.
CONTACT: This contains a SIP URI, which represents a direct route to contact userA, usually composed by a username and a FQDN (fully qualified domain name). Sometimes, the domains are not registered and thus IP addresses are permitted too. While the VIA header field tells the other elements where to send a response, the CONTACT field tells the other elements where to send future requests.
MAX-FORWARDS: This is used to limit the number of allowed hops a request can make in the path to its final destination. It consists of an integer which is decremented by one each hop.
CONTENT-TYPE: This contains a body message description.
CONTENT-LENGTH: This contains a byte count of the body message.
Session details, such as the media type and codec, are not described using SIP. Instead, SIP uses a session description protocol called SDP (RFC2327). This SDP message is carried by the SIP message, similar to an e-mail attachment.
The phone does not know the location of userB or the server responsible for domainB. Thus, it sends the INVITE request to the server responsible for the domain sipA. This address is configured in the phone of userA or can be discovered by DHCP. The server sipA.com is also known as the SIP proxy for the domain sipA.com. The sequence is as follows:
In this example, the proxy receives the INVITE request and sends a message "100 trying" back to userA, signaling that the proxy receives the INVITE and is working to forward the request. The SIP responses use a three-digit code followed by a descriptive phrase. This response contains the same TO, FROM, CALL-ID, and CSEQ header fields and a parameter "branch" in the Via header field such as the INVITE request. This allows userA's phone to correlate to the INVITE request sent.
ProxyA locates proxyB consulting a DNS server (SRV records) to find out what server is responsible for the SIP domain sipB and forwards the INVITE request. Before sending the request to proxyA, it adds a VIA header field that contains their own address. The INVITE request already had the address of userA in the first VIA header field.
ProxyB receives the INVITE request and responds with a "100 Trying" message back to the proxyA indicating that it is processing the request.
ProxyB consults their own location database for userB's address, and then adds another VIA header field with their own address to the INVITE request and forwards it to userB's IP address.
userB's phone receives the INVITE request and starts ringing. The phone indicates back this condition by sending a message of "180 Ringing".
This message is routed back through both proxies in the reverse direction. Each proxy uses the VIA header field to determine where to send the response and removes their own VIA header from the top. As a result, the message "180 Ringing" can return back to the user without any lookups to DNS or Location Service and without the need for stateful processing. Thus, each proxy sees all messages resulting from the INVITE request.
When userA's phone receives the "180 ringing" message, it starts to ring back, signaling the user that the call is ringing on the other side. Some phones show this in the display.
In this example, userB decides to attend the call. When he or she picks up the handset, the phone sends a response of "200 Ok" to indicate that the call was taken. The "200 Ok" message contains a session description in its body, specifying codecs, ports, and everything pertaining to the session. It uses the SDP protocol for this duty. As a result, an exchange occurs in two phases of messages from A to B (INVITE) and B to A (200 OK), negotiating the resources and capabilities used on the call in a simple "offer/response" model. If userB does not want to receive the call or is busy, the message "200 Ok" won't be sent and a message signaling the condition (that is, "487 busy here") will be sent instead.
The first line contains the response code and description (OK). The following lines contain the header fields. The VIA, TO, FROM, CALL-ID, and CSEQ fields are copied from the INVITE request. There are three Via fields—one added by userA, another by the proxyA, and finally by the proxyB. The SIP phone of userB added a parameter tag on both endpoints inside the dialog and will be included in all future requests and responses for this call.
The CONTACT header field contains the URI with which userB can be contacted directly in their own IP phone.
The CONTENT-TYPE and CONTENT-LENGTH header fields give some information about the SDP header ahead. The SDP header contains media-related parameters used to establish the RTP session.
In this case, the message "200 Ok" is sent back through both proxies and is received by userA, and then the phone stops ringing back indicating that the call was accepted.
Finally, userA sends an ACK message to userB's phone confirming the reception of the "200 Ok" message. In this example, the ACK is sent directly from phoneA to phoneB, avoiding both proxies. ACK is the only SIP method which has no reply. The endpoints learned each other's addresses from the CONTACT header fields during the INVITE process. This ends the INVITE/200 OK/ACK cycle, also known as the SIP three-way handshake.
At this moment, the session between both users starts and they send media packets to each other using a mutually agreed format established by the SDP protocol. Usually, these packets are end-to-end. During the session, the parties can change the session's characteristics by issuing a new INVITE request. This is called a re-invite. If the re-invite is not acceptable, a message "488 Not Acceptable Here" will be sent, but the session will not fail.
At the session's end, userB disconnects the phone and generates a BYE message. This message is routed directly to userA's softphone, bypassing both proxies.
userA confirms the reception of the BYE message with a "200 OK" message ending the session. No ACK is sent. An ACK is sent only for INVITE requests.
In some cases, it can be important for proxies to stay in the middle of the signaling to see all messages between endpoints during the whole session. If the proxy wants to stay in the path after the initial INVITE request, it has to add the RECORD-ROUTE header field to the request. This information will be received by userB's phone and it will send back the message through the proxies with the RECORD-ROUTE header field included too. Record routing is used in most scenarios.
The REGISTER request is the way that proxyB learns the location of userB. When the phone initializes, or at regular time intervals, the softphone B sends a REGISTER request to a server on domain sipB known as "SIP REGISTRAR". The REGISTER messages associate a URI ([email protected]) to an IP address. This binding is stored in a database in the Location server. Usually, the Registrar, Location, and proxy servers are in the same computer and use the same software. OpenSIPS is capable of playing all three roles. A URI can only be registered by a single device at a time.