VoIP in-depth: An introduction to the SIP protocol, Part 2 , 3-4

Things can become more complex in scenarios other than those outlined above. For example, you might use PRACK (defined in RFC 3262), which is a provisional response acknowledgement. There are some cases in which we would like to guarantee the delivery of a provisional response different than 100, such as 180 ringing (you may recall that TCP isn't enough to know the message reached the other end, as a proxy along the path may send the response over UDP). For that reason, a device sending a reliable provisional response would receive a PRACK, acknowledging the response, and because PRACK is a request, it would respond to that request with 200 OK. This does not mean a call was established--just that one party has received the PRACK; the INVITE transaction is still pending a final response. However, the provisional response may include an SDP answer to the original offer. Furthermore, a PRACK may have a new offer. To make things more complex, even after the PRACK offer-answer, you might send an UPDATE that includes, once again, a new offer.

Why make it so complex? The former scenario usually involves early media, such as ring-back tone (the music you hear when calling a person subscribed to this service) or interworking with PSTN. The later scenario may involve resource reservation. These scenarios, by definition, require setting and changing the media properties as the call begins, and this forces SIP to take a complex path to support them.

The following flow demonstrates a complex INVITE scenario. For clarity purposes, each transaction has a different color.

After the initial negotiation, you might also change the media attributes. For example, during a voice call, one party may ask to receive a fax, or to add or remove video. To do that, the party sends an INVITE request on the dialog (contrary to a new INVITE, this INVITE already has a tag parameter in the "To" header). Thus, the INVITE looks like any request that you send within the existing dialog, but it can contain SDP that changes the media behavior. This request type is often referred as re-INVITE.

Sometimes you might use UPDATE rather than re-INVITE. The reason is that re-INVITE is also a target refresh request. We have seen that the device stores the dialog remote target; because the remote target is set at the initial negotiation, a device would ignore the “Contact” header value of a request on the existing dialog. This is not true for target refresh requests that may prompt a change in the remote target. UPDATE may contain SDP with a new offer, similar to re-INVITE, but it is not a target refresh and thus affects only the media negotiation.

A very common scenario for changing media in an active call is placing the call on hold. Hold, in SIP/SDP terms, means that the one placing the call on hold no longer receives media, but it may decide to send media. For that reason, each media stream has an attribute that can be send-receive, send-only, receive-only or inactive. By default, a stream is send-receive. When you place a stream on hold, you change the stream to send-only and its peer changes it to receive-only. If both participants place the stream on hold, it becomes inactive.

Older hold scenario examples did not use these attributes, but rather changed the IP address to 0.0.0.0. This may seem equivalent to "inactive," but it also means that the RTCP cannot be used either. That means that devices that use the RTP/RTCP to know the call is still active would not receive any packets and thus would have no indication of the status of the call.

The variety of different cases and quirks, some of which are described above, have created many interoperability questions. In fact, some questions remain unanswered even today. Nevertheless, to cope with this, the IETF provided SDP offer/answer examples in RFC 4317 and, perhaps more importantly, there is a draft that attempts to provide guidance on many of these questions. So, if you're looking for cases in which SIP did not manage to keep things simple, offer-answer is definitely ranked high.

Extensions

We mentioned numerous times that SIP supports extensions. Obviously, different implementations will support different extensions. It's a question of network policy as to whether specific extensions are mandatory, allowed, or forbidden. For that reason, SIP uses option-tags. An option-tag is a short string that indicates support for a specific extension. When an RFC defines a new extension it may define a new option-tag and register its name in IANA's registry. For example, PRACK has an option-tag named "100rel." If a client sending an INVITE supports PRACK, it will include the following header:

Supported: 100rel

A device that receives this INVITE request and wants to send a provisional response reliably using this extension can now send it with the following header:

Require: 100rel

Since the original UAC indicated it supports "100rel," it is expected to send PRACK for that provisional response. The INVITE could have also included the 100rel in the "Require" header. If the recipient does not support this extension, it should send back a 420 (Bad Extension) response with the names of the extensions it does not support in the "Unsupported" header. Headers that include these option-tags may appear multiple times, or include several comma-separated values and therefore one may indicate several extensions in a single message.

Extensions may also define new methods. To indicate the supported methods, you place this in the "Allow" header. Furthermore, to indicate which message bodies are supported, their names are included in the "Accept" header. To figure out, prior to a session, the capabilities of a device, it’s possible to send an OPTIONS request. The request includes in the "Accept" header the message body it wishes to query (obviously most commonly this would be "application/sdp"). A successful response would include the following:

• The option-tags in the "Supported" header.
• Methods supported in the "Allow" header (except a proxy generates the response in which case proxies should not limit the method type).
• The body type in the "Accept" header.
• Languages supported (for text such as response reason phrase) in the "Accept-Language" header.
• Body encoding (such as compression via gzip) in the "Accept-Encoding" header. It is not common practice to compress the body.
• The body itself indicating its capabilities. For SDP, this would include the different media types in each "m"-line and the codecs with their capabilities in corresponding attributes.

  Extending SIP

  SIP does not stop with the INVITE request. RFC 3265 defines a SIP-based infrastructure for event notification, and one of the most common event notifications is presence (i.e., you have a list of contacts in a presence client, and you get notifications when a contact goes online, offline, leaves to lunch, etc.). Therefore, the presence client would send a SUBSCRIBE request to a presence server. Once it receives a 2xx response to the SUBSCRIBE request, a new dialog is formed. The server can now generate a NOTIFY request on the dialog that indicates the user status has changed.

  The IETF knew that there might be many scenarios aside from presence that include this mechanism, so they defined this infrastructure on top of SIP. For example, when a phone is busy, you can use a call completion feature to be notified when the person is available for the call. This, once again, involves subscribing to an event and receiving status notifications.

  To support a specific event, you should implement an event package that defines the event name, parameters, status types, and bodies a message may include. A SUBSCRIBE request would include the event name in the "Event" header, so that a single user can send out multiple SUBSCRIBE requests, even to the same target. To check which event packages are supported, a new header called "Allow-Events" was defined. Subscriptions have an expiration time, and a subscriber that wishes to keep the subscription open must send another SUBSCRIBE request within the dialog before it expires. This dialog closes when the notifier sends a NOTIFY request with a terminated status.

  There are numerous examples of event-notification extensions, such as RFC 3856 defining presence, RFC 3680 that sends a notification for user registrations and RFC 4730 defining signaling DTMF events. One event-notification extension, which is more related to calls, is call transfer. To this end, RFC 3515 defines the REFER method.

  Suppose participants A and B have a call, and participant A wants to transfer the call to participant C. A would send out a REFER request to B with C's address. B sends out an INVITE request to C, specifying it was referred by A. REFER uses implicit subscription, which helps A know whether the transfer has completed successfully. B then sends NOTIFY requests to A, indicating the status of the transfer. This is illustrated in the following flow:

  

  A different possible transfer scenario is to send a REFER request from A to C. C would then send an INVITE to B. The INVITE would include the dialog details of A and B to specify which dialog is being replaced. It is also possible for A to have two concurrent INVITE dialogs, one with B and one with C prior to the REFER; this is also known as attended transfer

  Let's assume one sends a REFER within an existing dialog. Often, that makes sense because A probably has an INVITE dialog with B and thus, it may send a REFER on the existing dialog instead of creating a new one. In the REFER diagram above, we have colored each dialog usage with a different color. You can see that despite the fact that BYE was sent, we still have communication between the two parties. If the REFER was sent on the same dialog as the INVITE, the NOTIFY and 200 OK are also sent on this dialog. This is because the subscription still exists.

  Having call and subscription on the same dialog may seem harmless at first, but sometimes it's not trivial. For example, what should you do when an error response arrives? Some responses affect just the transaction, some affect just the specific usage (INVITE or REFER), and some, such as 404 not found, may affect both INVITE and REFER (suddenly the user does not exist, although the dialog was established). In addition, the dialog remains open even after a BYE request (if the REFER notifications are still active), but many implementations tend to close the dialog when seeing a BYE simply because this multiple usage on a single dialog was not clearly defined. RFC 5057 attempts to address that by defining the desirable behavior of multiple usages on a single dialog. It also discourages using this ability since it recognizes many of the complications. In fact, RFCs published after the REFER RFC do not define multiple usages or implicit subscriptions.

  Readers who want to learn more in-depth details about the event notifications are encouraged to open the RFC, as its language is rather clear. I should mention that there is a new draft updating RFC 3265, which addresses many issues that have come up in recent years. Some changes clarify the text, others alter some definitions (e.g., the dialog is now created only when the NOTIFY transaction completes). Other changes also discourage multiple usages on a single dialog.

  Finale

  Part 1focused on the SIP foundations and showed the protocol's simplicity. Part 2 has described the more complex areas of SIP that require more attention to detail. If you've survived this primer then you should have a good baseline for understanding this protocol. It might be a good idea to look at RFC 5359, which provides excellent examples to many SIP services scenarios. If you want to extend your knowledge of SIP even further, I would recommend reading the base SIP RFC, as well as following the many extensions, some of which are mentioned in this primer. Finally, the IETF forums are very friendly to any person who has a question, including newcomers. You can find many answers in the forum's archive, and you can post any question on any related matter.