Let's examine this message sequence between two user agents as shown in the following figure. You can see several other flows associated with the session establishment in RFC 3665:
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.
The 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, Transport Layer Security (TLS), between the caller and 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 and include a unique identifier, the destination, and information about the session.
The first line of the message contains the method name and request URI. The following lines contain a list of header fields. This example contains the minimum set required. The header fields have been described as follows:
Method and Request-URI: In the first line, you have the request URI also referred to as RURI. It contains the current destination of the message and is often manipulated by the proxies to route a request. It is the most important field in a SIP request.
Via: This contains the address to which userA will be waiting to receive responses to this request. It also contains a parameter called
branchthat identifies this transaction. The Via header defines the last SIP hop as IP, transport, and transaction-specific parameters. Via is used exclusively to route 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 go again in the location server or DNS.To: This contains the name (display name) and SIP URI (that is,
<sip:[email protected]>) in the destination originally selected. The To header field is not used to route the packets.From: This contains the name and SIP URI (that is,
<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 the 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 the 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 it may contain the hostname or IP address of the UAC. 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 to each new request in 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 of a user name and fully qualified domain name (FQDN). It is usual to use the IP address instead of the FQDN in this field. While the Via header field tells the other elements where to send a response, the Contact tells the other elements where to send future requests.
Max-Forwards: This is used to limit the number of allowed hops that a request can make in the path to their final destination. It consists of an integer decremented by each hop.
Content-Length: This contains a byte count of the body message.
Session details such as the media type and codec are not described in SIP. Instead, it uses the Session Description Protocol (SDP) (RFC 2327). 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 DNS. 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 100 Trying reply back to userA, indicating that the proxy received INVITE and is working to forward the request. The SIP reply uses a three-digit code followed by a descriptive phrase. This response contains the same To, From, Call-ID, and CSeq header fields and a
branchparameter in the header field, Via. This allows for the userA's phone to correlate the INVITE request that is sent.ProxyA locates ProxyB consulting a DNS server (NAPTR and SRV records) to find which 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 its own address. The INVITE request already has the address of userA in the first Via header field.
ProxyB receives the INVITE request and responds with a 100 Trying reply to ProxyA indicating that it is processing the request.
ProxyB consults its own location database for userB's address and then it adds another Via header field with its own address to the INVITE request and forwards this to userB's IP address.
The userB's phone receives the INVITE request and starts ringing. The phone responds to this condition by sending a 180 Ringing reply.
This message is routed back through both the proxies in the reverse direction. Each proxy uses the Via header fields to determine where to send the response and removes its own Via header from the top. As a result, the message 180 Ringing can return to the user without any lookups to DNS or Location Service and without the need for stateful processing. Thus, each proxy sees all the messages resulting from the INVITE request.
When userA's phone receives the 180 Ringing message, it starts to ring back in order to signal 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 they pick up the handset, the phone sends a response of 200 OK to indicate that the call was taken. The 200 OK message contains in its body a session description specifying the 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 200 OK won't be sent and a message signaling the condition (that is, 486 Busy Here) will be sent instead.
The first line contains the response code and a description (OK). The following lines contain the header fields. The Via, To, From, Call-ID, and CSeq fields are copied from the INVITE request and the To tag is attached. There are three Via fields: one added by userA, another by ProxyA, and finally, ProxyB. The SIP phone of userB adds a tag parameter for the To and From headers and will include this tag on all the future requests and responses for this call.
The Contact header field contains the URI by which userB can be contacted directly in its own IP phone.
The Content-Type and Content-Length header fields give some information about the SDP header. The SDP header contains media-related parameters used to establish the RTP session.
After answering the call, the following occurs:
The 200 OK message is sent back through both the proxies and received by userA and then the phone stops ringing, indicating that the call was accepted.
Finally, userA sends an ACK message to userB's phone confirming the reception of the 200 OK message. When record routing is not involved, the ACK is sent directly from phoneA to phoneB avoiding both the proxies. ACK is the only SIP method that has no reply. The endpoints learn each other's addresses from the CONTACT header fields during the INVITE process. This ends the cycle, INVITE/200 OK/ACK, also known as the SIP three-way handshake.
At this moment, the session between both the 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 characteristics issuing a new INVITE request. This is called a reinvite. If the reinvite is not acceptable, a 488 Not Acceptable Here message will be sent, but the session will not fail.
At the end of the session, userB disconnects the phone and generates a BYE message. This message is routed directly to userA's SIP phone, bypassing both the proxies.
The 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 the proxies to stay in the middle of the signaling to see all the messages between the 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 will send back the message through the proxies with the Record-Route header field included too. Record-routing is used in most scenarios. Without record-routing, it is not possible to account the calls and there is no control of the SIP dialog in the proxy.
The REGISTER request is the way that ProxyB learns the location of userB. When the phone initializes or in regular time intervals, the SIP phoneB 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 such as OpenSIPS. A URI can only be registered by a single device at a certain time.