So far, we have seen what the core capabilities of SIP are. These capabilities need to be present in any SIP-compliant implementation. Therefore, any SIP UA can always assume that the UA it is communicating with (or trying to communicate with) will always support the core SIP.
In some cases, new applications appear for which it makes a lot of sense to use SIP, but that requires some kind of extension to the protocol. Foreseeing these situations, the core SIP specification defined built-in mechanisms to allow protocol extension while not disrupting the core SIP behavior.
In this chapter, we will first describe what these mechanisms are. Then we will present some of the general-purpose SIP extensions. In subsequent chapters, we will introduce additional extensions that are needed for new applications or for SIP to work in specific environments.
The SIP core protocol can be extended in order to support new applications or solve known problems. The design of a new extension needs to follow a specific set of guidelines as specified in [RFC 4485]. These guidelines intend to assure that new extensions fit into the scope of the protocol and that they conform to the general SIP architecture model.
As we have seen, SIP is a protocol for initiating, modifying, and terminating multimedia communication sessions; therefore, if someone would propose an extension to the protocol for using it as a way to remotely control, say, a refrigerator,[1] such an extension would not fit within SIP’s scope.
Also, new extensions must not break the SIP key architectural principles—such as the fact that SIP is independent of the session it establishes, that it is transactional, and so forth. Therefore, a new extension that forces SIP to be aware of the type of session being established, or a new method that is not transactional, would not be accepted as a valid SIP extension.
[RFC 4485] summarizes the primary architectural assumptions that underlie SIP. New SIP extensions should comply with these principles:
Session independence: SIP is independent of the session it establishes. SIP operation should not depend on the characteristics of the media.
SIP and session independence: The set of routers traversed by SIP messages is unrelated to the set of routers traversed by the media packets.
Multiprovider and multihop: SIP assumes that its messages will traverse the Internet—that is, it works through multiple networks administered by different service providers. SIP messages may traverse many hops (proxies).
Transactional: SIP messages follow the request/response model.
Proxies can ignore bodies: This allows proxies to scale well.
Proxies don’t need to understand the method: This is one of the key aspects to assure extensibility of the protocol. Proxies just pass the new method on.
INVITE requests carry full state: New applications should not require data to be collected from multiple INVITEs within the same session. Each INVITE within the session carries all the necessary information.
Generality over efficiency: General-purpose components are preferred even if slightly less efficient.
The Request-URI is the primary key for forwarding: New extensions should not change the semantics of the Request-URI.
Heterogeneity is the norm: New extensions should not assume universal support for such extension. The SIP environment is quite heterogeneous, and SIP devices that support the new extension will have to live together with other SIP devices that do not support it.
SIP is an extensible protocol. It can be extended by adding new headers, methods, parameters, or bodies. [RFC 3427] defines the change process for the SIP protocol.
SIP was designed in such a way that extending the protocol would not mean a huge impact on existing systems. For instance, proxies do not need to understand the SIP method apart from the three special ones (INVITE, CANCEL, and ACK). This means that the addition of new methods would have no impact on proxies. The same applies to content types because proxies are not supposed to care about the SIP body.
Still, in the SIP architecture, there are other entities apart from proxies. Moreover, the protocol can also be extended by adding new headers; therefore, when adding new features into the protocol, there appears the generic issue of compatibility and protocol interoperability. How can the entities that support the new extensions live with the “older” ones that do not support these extensions? SIP was designed with the following rule in mind: “Be strict when sending; be loose when receiving.” This rule makes SIP forward compatible as much as possible. For instance, RFC 3261 states that if a SIP UA receives a header field that it does not understand, the UA should ignore it. However, this does not solve the problem in all cases. Let us see why.
Let us consider, for instance, the case of a request that contains an already-existing method (e.g., INVITE), but with a new header field. Two cases may arise:
The extension is backward compatible—that is, a request containing the new header can be processed reasonably by a proxy or UA without understanding the new header.
The extension is not backward compatible, which occurs when the request cannot be processed reasonably without understanding the semantics of the new header.
Fortunately, SIP has built-in mechanisms in order to minimize possible interoperability breaks that might arise in the second case. We will see now what these mechanisms are for all the possible cases of SIP extensions: new headers, new methods, and new content types.
When adding new header fields or header-field parameters that are not backward compatible into the protocol, there are mainly two possible ways to handle the possible interoperability break:
The first approach consists of having the UA use the new header only when the UA knows beforehand that the header will be supported by the other involved SIP entities. This approach can be implemented in two different scenarios: from client to server, and from server to client.
From client to server: A client, before sending a request with a new header, might want to send an OPTIONS request to learn about the support of such a header in the server (see Chapter 6). It will not include a header in subsequent requests if the header is not supported by the server. This is shown in Figure 15.1.
From server to client: A client declares in the SIP request what extensions it supports. In that way, the server is prevented from including in the response a new header that the client does not understand.
A UAC would implement this behavior by including a Supported header in the outgoing request. The Supported header would list all the extensions that the client supports. When the request gets to the server, several situations may occur:
The server might see that a specific extension is supported by the client, and then might answer, including such an extension in the response. This is shown in Figure 15.2.
Another possibility is that the server intends to respond using an extension, but sees that it is not supported by the client, and then falls back to baseline SIP. This is depicted in Figure 15.3.
A third situation would happen if the server is unable to respond without using an extension that the client does not support. In this case, the server would answer with a 421 (Extension required), including a Require header that lists the extensions required by the server. Figure 15.4 shows this situation. This behavior is not recommended because it will generally break interoperability.
In the second approach, a client would straightforwardly send the request including the new extension, but it would state that the server is not to process the request if it does not understand the new header.
The way to implement this is by using two headers: Require and Proxy-Require, defined in the base SIP specification. A UAC will include the Require and/or Proxy-Require headers in outgoing requests if it wants to indicate to the UAS or to a proxy, respectively, that the extensions listed as parameters in those headers must be supported by them.
If the UAS or proxy does not support the extensions, the UAS or proxy will send back a 420 (Bad Extension) response. In the 420 response, the server or proxy will include an Unsupported header field indicating which extensions that were required are actually not supported. At this point, the UAC has two options: to assume that the service cannot be delivered because there is an interoperability problem, or to revert to baseline SIP and issue the request again.
As an example of the previous discussion, let us consider an example of extension negotiation between John and Alice.
John’s UA supports the extensions ext1, ext2, ext3, and ext4. He wants to use ext1 in the session, so he includes it in the Require header field. The Supported header field would include ext1, ext2, ext3, and ext4. He sends the initial INVITE to Alice. Alice’s UA supports ext1, ext3, and ext4, and she wants to use ext3 in the response as well. So, at this point, Alice’s UA knows that:
It must use ext1 in the response because it was required by John’s UA.
It may use ext3 in the response because it is supported by John’s UA.
So Alice sends a response that uses extensions ext1 and ext3, and includes a Supported header stating that she supports ext1, ext3, and ext4. This will give John additional information as to the extensions that he can use in subsequent requests to Alice.
This is shown in Figure 15.5.
In the previous examples, we have needed to refer to SIP extension in the Require, Proxy-Require, or Supported header fields. This is done by using option tags, which are unique identifiers used to designate new extensions in SIP.
A specific type of SIP extensions is referred to as a “private” extension. Private headers include the “P-” prefix. These are extensions that are “either not ready for standards track, but might be understood for that role after some running code, or are private or proprietary in nature, because a characteristic motivating them is usage that is known not to fit the Internet architecture for SIP” [RFC 3427].
P-headers are typically defined for SIP usage in non-Internet, controlled-network scenarios such as those occurring in telecom operators’ networks. When we deal with IMS in Chapter 24, we will see various examples of P-headers.
In order to handle the possible interoperability break caused by the introduction of new methods, the only approach is to use the new method only if the client knows beforehand that it will be understood by the server. There are two possible ways to achieve this:
Use the OPTIONS request before sending a new method. The response to the OPTIONS request will indicate in the Allow header which methods are supported by the server.
Indicate in the outgoing requests what new methods are supported by the UAC. This would be implemented by having the client include an Allow header field that lists the methods supported by the client. The UAS would also include an Allow header in the response. At this point, both UAC and UAS would know what are the methods allowed by each other, and therefore they would avoid sending not-allowed methods in new requests.
In order to handle this scenario, there are two possible approaches:
A UA uses a specific body only if it knows that the body will be supported by the peer UA. There are two ways to discover this:
Use the OPTIONS request before sending a message including a new content type. The response to the OPTIONS request will indicate in the Accept, Accept-Encoding, and Accept-Language whether the content type, encoding, and language are supported by the server.
Indicate in the outgoing requests and responses what new content types are supported by the UA. This would be implemented by having both UAC and UAS include an Accept header that lists the content types supported by them.
In addition to the previous approach, the UA, when including a new content type in the SIP body, may include a Content-Disposition header with a parameter that indicates that support for the new content is optional.
We have seen what the mechanisms are in SIP to handle new extensions. Let us now review some of the most common ones.
We saw in previous chapters that SIP defines two types of responses: final and provisional. Final responses convey the result of the request processing, whereas provisional responses, sent within an INVITE transaction, just provide information about the progress of the session establishment.
We also saw that core SIP [RFC 3261] includes mechanisms in order to assure the reliability of final responses. However, the core SIP spec does not include any mechanism to deliver provisional responses reliably. This is shown in Figure 15.6, where a 180 provisional response is lost and no corrective action is taken by the UAS.
There are cases, though, where it would also be important to assure the delivery of a provisional response. For instance, imagine an application that applies a particular action (e.g., playing an announcement) when the call is being forwarded or queued. Such an application may require that the 181 (Call Is Being Forwarded) or 182 (Queued) provisional responses are delivered reliably because they signal the condition for playing the announcement.
Another case where a provisional response would need to be sent reliably occurs when the provisional response contains an SDP answer as a result of an SDP offer sent in an INVITE request. Effectively, the core SIP specification states that “if the initial SDP offer is in an INVITE, the SDP answer must be in a reliable non-failure message.” If the SDP answer is carried in the 200 OK response, there is no problem because this message is delivered reliably by core SIP—but if we wanted to carry an SDP in a provisional response, core SIP does not include mechanisms to deliver the response reliably.
An example of a scenario where SDP may need to be sent in a provisional response is an early-media scenario. In early-media scenarios, the media is established before the call has been accepted (i.e., before 200 OK is sent). These scenarios are typical in the PSTN, where it is common to play announcements to the caller before the call is answered. In this case, early media would flow from called to caller. In other scenarios, it is also necessary to let early media flow from caller to called. An example of these could be the toll-free routing services that prompt the user for the telephone number before routing the call. In this case, the caller would typically need to send DTMF tones before the call has been answered.
Early-media scenarios in SIP are typically implemented by having the called party send back a 183 (Session progress) provisional response that includes an SDP. If the early media needs to flow from caller to called, the SDP would contain the address where media needs to be sent by the caller. If the early media needs only to flow from called to caller (e.g., an early announcement), then the SDP would indicate to the caller the address where RTCP reports need to be sent.
Another scenario where SDP needs to be sent in a provisional response is a SIP call establishment with QoS preconditions. This scenario will be explained in Chapter 21, and it also requires that provisional responses are delivered reliably.
In order to cope with the general issue of assuring reliability in provisional response, the IETF has defined an extension to the SIP protocol. This extension is specified in [RFC 3262], and introduces a new SIP method (PRACK) and an option tag for this extension (100rel).
Let us imagine, for instance, that John makes a call to his voice-mail system in order to listen to his stored messages. In a typical setup, the voice mail first plays a welcome announcement and then accepts the call (i.e., sends 200 OK). Once the call is accepted, the voice mail starts playing the stored messages. In this case, the welcome announcement is a form of early media. Let us see how this works in detail.
John’s UA would generate an INVITE request that includes a Supported header with the option tag 100rel. When receiving the INVITE, the voice mail sends back a 183 (Session progress) provisional response containing the SDP answer. This response needs to be sent back reliably, so the voice mail includes in the response a Require header that contains the option tag 100rel.[2] The response also contains a new header field called RSeq, which will also be present in the subsequent PRACK. RSeq allows the voice mail to know what provisional response the PRACK is acknowledging.
When John’s UA receives the 183 response, it generates a PRACK request that contains the received RSeq header field. When the PRACK request reaches the voice mail, the voice mail is sure that the 183 response was delivered to the UAC. The voice mail sends a 200 OK response to the PRACK. The voice mail plays the welcome announcement, and when the announcement is done, the voice mail sends a 200 OK final response to the INVITE (i.e., answers the call) and starts playing the stored messages. This is shown in Figure 15.7, where we are assuming that the first 183 response was lost.
Readers may wonder what is the use of the 200 OK response to the PRACK request. The 183 response is already acknowledged with the PRACK request, so why generate another message? This has to do with our discussion at the beginning of the chapter. New SIP extensions have to comply with the SIP architectural principles. One such principle is the Transactional principle, which states that new messages added to SIP should comply with the request-response model. This is important because many of the rules of operation in SIP are based on general processing of requests and responses. This includes reliability mechanisms, routing mechanisms, and state maintenance rules. For instance, if we add a new method such as PRACK, we also need to consider that it will need to have its corresponding response. By doing this, for instance, we assure that proxies do not need to be modified to handle the PRACK. Proxies are prepared to handle all new methods in the same way, provided they follow the request-response mechanism.
In this case, the solution is less efficient (one more message), but it is more general, and therefore allows us to benefit from underlying SIP rules of operation and to leverage its extensible design.
Following up on the previous example, let us imagine that while John is listening to the voice-mail welcome announcement, he wants to put the call on hold. We saw in Chapter 9 that, in order to put the call on hold, the UAC should send a re-INVITE request with the SDP sendonly attribute. Because the re-INVITE request modifies the dialog state, RFC 3261 forbids a UAC to send a re-INVITE request if the previous INVITE transaction is not completed.
Therefore, there is no way in RFC 3261 to put a stream of early media on hold because the dialog initiating INVITE request has not yet been completed.
In order to solve this type of issue and others, a new SIP extension [RFC 3311] has been defined. This extension introduces the UPDATE method, which allows us to update parameters in the session while it does not change the dialog state (unlike INVITE, which can be used to update parameters in the session, but does modify the dialog state).
The UPDATE method is very useful whenever we want to update session parameters within an early dialog.
Following up on our previous example, let us assume that John makes a call to the voice mail. When he is listening to the welcome announcement, he receives a new call from Alice, so he decides to take the new one and put on hold the call to the voice mail. Let us see how this works.
John sends an initial INVITE that includes an Allow header field listing the UPDATE method. When receiving the INVITE, the voice mail, if it is capable of receiving the UPDATE method, would include an Allow header field listing the UPDATE method in the provisional 183 response. When John’s UA receives that response, it knows that it can use the UPDATE method toward the voice mail if John desires to update some session parameters.
The voice mail starts playing the welcome announcement, but then John receives another call, and he decides to take the new call and put the call to the voice mail on hold. In order to put the call on hold, he issues an UPDATE request with the SDP sendonly attribute. When the voice mail receives the request, it acknowledges the request by sending a 200 OK. Some seconds later, John wants to retrieve the call, so he sends a new UPDATE with the SDP sendrecv attribute. He then resumes the communication with the voice mail.
This example is shown in Figure 15.8.
In communication systems, there is sometimes the need for end users or applications to receive a notification of an event related to the state of some communication resource. For instance, if John calls Alice, and he gets a busy signal because Alice is already engaged in another conversation, he might then want to be notified as soon as Alice becomes free, so that he can call her again. In another scenario, John might be interested to know when new messages arrive to his voice mail.
The core SIP specification defines how to set up, modify, and release communication sessions. Core SIP does not include any mechanism to allow UAs or applications to be notified of communication-related events.
[RFC 3265] defines a new SIP extension that provides a framework for asynchronous event notification in the context of SIP-based communication systems. It is important to understand that this framework is not intended to be a general-purpose infrastructure for all classes of event subscription and notification. On the contrary, it is SIP specific, and focused on complementing the key communications functionalities enabled by the core SIP. Therefore, this extension is considered to fit into SIP’s solution space.
The extension provides a framework that allows SIP nodes to request notification from remote nodes indicating that certain events have occurred. User Agents can, in the remit of this framework, play the following roles:
Subscriber: The User Agent that subscribes to specific events and receives notifications when these events occur.
Notifier: The User Agent that receives the subscription requests and generates the notifications toward the subscriber
The extension also defines two new SIP methods:
SUBSCRIBE: This request is sent by a subscriber in order to subscribe to an event or class of events. It may include a body that contains a filter for the class of events being requested. The SUBSCRIBE request creates a SIP dialog.[3]
NOTIFY: This request is sent by the notifier in order to inform the subscriber about the occurrence of an event. The request includes a body that contains the description of the state of the monitored resource.
The operation of event subscription and notification is quite simple. A UA (subscriber) interested in being informed about the state information of a communication resource sends a SUBSCRIBE message to the UA (notifier) responsible for that communication resource. In the SUBSCRIBE request, the subscriber includes a new header field, called Event, that indicates the event or class of events that it is subscribing to. If the notifier accepts the subscription, it responds to the SUBSCRIBE request with a 200 OK. Then the notifier immediately constructs and sends to the subscriber a NOTIFY request including the state information required. From then on, until the subscription is terminated, the notifier will send new NOTIFY requests whenever a change in the requested state information is produced.
In the SUBSCRIBE request, the subscriber includes an Expires header field that indicates the duration for the subscription. The subscription is refreshed whenever a new SUBSCRIBE message is received on the same SIP dialog. A subscription is terminated either because the subscriber sends a SUBSCRIBE request with an Expires header field set to “0” or because the subscription timer expires.
In Figure 15.9, we see the basic operation for the event subscribe and notification.
The operation of the SUBSCRIBE and NOTIFY methods is detailed in RFC 3265. However, this RFC does not describe an extension that may be used directly; it needs to be extended by other documents, referred to as an event package. Event packages provide more information on the syntax and semantics of the state information for a particular class of events, as well as additional information about the operation of subscribers and notifiers specific to that particular class of events. There are separate RFCs that define event packages for different types of events. For instance:
User agents indicate support for the SIP notification framework and specific event packages by adding an Allow-Events header field in all methods that initiate dialogs and in the responses to these methods. The Allow-Events headers field contains a list of tokens indicating the event packages supported by the User Agent. For instance:
Allow-Events: reginfo, conference
Such a header field indicates that the UA supports the event packages for registration events and conferencing events.
The RFCs for event packages contain, among other things, the following information related to a particular class of events:
Event package name: It identifies the event package. The Event header field in a SUBSCRIBE request will contain the name of the event package being subscribed. Furthermore, a UA wanting to indicate support for a particular event package will include the name of the UA in the Allow-Event header field of dialog-initiating requests and their responses.
SUBSCRIBE bodies: SUBSCRIBE requests may contain bodies that represent a filter to be applied to the subscription.
NOTIFY bodies: NOTIFY requests contain bodies that include the state information for the class of events. The state information may be expressed as an XML document, as plain text, or other.
Additional processing of SUBSCRIBE and NOTIFY requests: Includes details on how to perform the authentication and authorization, detailed information about what events shall cause a NOTIFY to be sent, and so forth.
Others
By way of example, we will look a bit more in detail at some of these event packages.
In some cases, a SIP entity may be interested to be informed about the registration status of a User Agent. Consider, for instance, a “welcome news” application such as the sort that is quite typical in mobile networks. When users turn on their phone in a foreign country, they receive a welcome message that provides them with general information about the country.
In a SIP environment, such a service might be implemented by having an application server subscribe to the registration state of the user. When the user turns on the phone, the phone will generate a registration toward the REGISTRAR. The REGISTRAR would then send a NOTIFY request to the “welcome” application server, which might then take the action to send the welcome message to the user. The welcome message might be sent as a SIP page-mode instant message, as we will see Chapter 16.
In Figure 15.10, we can see the message flow for this example.
The name for the registration event package is “reginfo.” The state information contained in the body of NOTIFY messages is expressed as an XML document.
The first NOTIFY request contains a body that indicates that John is not yet registered:
<?xml version=“1.0”?><reginfo xmlns=“urn:ietf:params:xml:ns:reginfo” version=“0” state= “full”> <registration aor=“sip:[email protected]” id=“a7” state=“init”/></reginfo>
The body in the second NOTIFY request reflects the fact that John has registered:
<?xml version=“1.0”?><reginfo xmlns=“urn:ietf:params:xml:ns:reginfo” version=“1” state=“partial”> <registration aor=“sip:[email protected]”id=“a7” state=“active”> <contact id=“76” state=“active” event=“registered” duration-registered=“0”> <uri>sip:[email protected]</uri> </contact> </registration></reginfo>
Another interesting event package allows a User Agent to receive notifications of dialog-related events occurring in other User Agents. These events include dialog initiation, termination, and so forth. The name of the event package is “dialog.”
Let us consider the following scenario: John calls Alice, but she is actually engaged in another call. John gets a busy signal. John wants to know when Alice becomes free again, so he sends a SUBSCRIBE request to Alice. The Event header field in the SUBSCRIBE is:
Event: dialog
Alice’s UA responds with a 200 OK, and generates an initial NOTIFY request that indicates that Alice is busy. Later on, Alice becomes free, and her UA sends another NOTIFY request, indicating this change in the dialog state. John receives the NOTIFY, and immediately calls Alice again. Now she is free and takes the call.
This call flow is shown in Figure 15.11.
The SIP event package for dialogs is expressed in XML format. As an example, the first NOTIFY in our previous example might look like:
<?xml version=“1.0”?><dialog-info xmlns=“urn:ietf:params:xml:ns:dialog-info” version=“1” state=“full” entity=“sip:[email protected]”> <dialog id=“rv7ew84js” call-id=“gs8j44l3d8fdj4” local-tag=“8493948539” remote-tag=“iw32p” direction=“initiator”> <state>confirmed</state> </dialog></dialog-info>
The body of the second NOTIFY indicates that the dialog is terminated:
<?xml version=“1.0”?><dialog-info xmlns=“urn:ietf:params:xml:ns:dialog-info” version=“2” state=“partial” entity=“sip:[email protected]”> <dialog id=“rv7ew84js” call-id=“gs8j44l3d8fdj4” local-tag=“8493948539” remote-tag=“iw32p” direction=“initiator”> <state reason=“remote-bye”>terminated</state> </dialog></dialog-info>
SIP proxies and B2BUAs may change the Request-URI of a request, therefore changing the target of the request. Such a process is called retargeting. In the process of retargeting, old routing information can be lost. There are cases where, in order to apply a service, it is necessary to know how the call arrived at a particular application—that is, it is necessary to know how the Request-URI was modified in the different processes of retargeting that the call went through. In other words, there is a need to know the “request history” of the call. This request history information would allow an application to know how and why the application arrived at the application/user.
Let us think, for instance, of a simple call-forwarding application implemented in a proxy. John calls Alice, but Alice is busy, so her inbound proxy forwards the call to the voice mail. In order to do so, the proxy removes the original Request-URI, [email protected], and sets it to vms.pacific.com. Therefore, the information about the original destination of the call is lost. The call then reaches the voice mail. The voice mail should access Alice’s mailbox, but the Request-URI no longer points at Alice, so the voice-mail system does not know what mailbox to access.
This problem would be resolved if the information about the original recipient or destination of the call were maintained when retargeting the request in the proxy.
[RFC 4244] defines a SIP extension that allows us to capture the request history information of a call. It is based on a new header field called History-Info, which is updated every time retargeting occurs.
The mechanism is quite simple. A UAC that desires to receive the History-Info in responses includes a Supported header with the option tag “histinfo” in outgoing requests. Additionally, the UAC originating the request can also add a History-Info header with a value equal to that of the Request-URI. As a result, intermediaries and the UAS can know what the original Request-URI was.
Whenever retargeting occurs, the SIP entity implementing the retargeting may, provided that this entity supports History-Info and based on local policy, add the new target to the History-Info header field.
Finally, the UAS will copy the received History-Info into the response it sends back to the UAC.
A SIP request or response may contain a list of History-Info header fields. Each header field must contain at least two elements:
The new Request-URI in the retargeted request
An index, which reflects the chronological order of the information.
In addition, each header field may also contain a Reason parameter that indicates the Reason for the retargeting, and a Privacy parameter that indicates if a specific History-Info header may be forwarded.[7]
Figure 15.12 depicts the previously described scenario with the voice mail.
We have seen in previous chapters that a user is identified, for SIP purposes, by the address-of-record (AOR), which typically has the form of a SIP URI (e.g., sip:john@ sea.com). The AOR identifies the user, but the user may have more than one device (PC, laptop, mobile, and so on), all of them corresponding to the same user, the same AOR. When the UA in a device is turned on, it registers its contact address for the AOR. If, say, three User Agents, one in each device (PC, laptop, and mobile), are registered, the registrar would show an AOR connected to three different contact addresses. This situation is depicted in Figure 15.13.
The situation just described is perfectly supported by the core SIP specification.
In order to determine how calls destined to the AOR are terminated, different approaches might be followed. For instance, each contact address might have a different priority assigned to it so that the authoritative proxy tries some devices before others. It is also possible that all contact addresses have the same priority, thus forcing the proxy to perform parallel ringing. This scenario is shown in Figure 15.14.
The usual case, though, is that the call termination logic for these kinds of scenarios is handled by an application server in the form of a B2BUA that can take into consideration a number of factors (not just the priority in the contact header), such as presence, time of day, subscriber data, and so forth. This type of service is commonly known as multidevice service. Figure 15.15 shows an arrangement where a B2BUA controls the termination of calls destined to the multidevice user.
The question that is raised here is: How can the proxy or the application server force the routing to specific instances of the same AOR—that is, to a specific device?
In the case of the proxy, the answer is clear. The authoritative proxy uses the bound contact address to perform the routing; each device has a different contact address, so the proxy just needs to select the appropriate contact address corresponding to the device that is to be reached and put it into the Request-URI of the outgoing request.
The same solution might be applied in the case of the application server; however, this might pose a problem because contact addresses typically contain IP addresses that may not be routable if there are NAT devices or firewalls in between. When the NAT is placed between the proxy and the UA, there are solutions to address the NAT traversal problem, as we will see in Chapter 22. However, it is not possible to assure that contact addresses are routable from any point of the Internet.
We have just depicted a particular scenario, but there are several other use cases[8] that justify the need for a globally routable identifier for a UA instance that can be used by arbitrary external clients. As of the time of writing, there is work in progress in the IETF [draft-ietf-sip-gruu] to specify a SIP extension that defines such an identifier, called GRUU.
Even if it is still an Internet draft, we have purposely included it in this chapter alongside other extensions published in official RFC documents because we believe the GRUU concept has considerable relevance.
From a high-level point of view, it is quite easy to understand how the GRUU extension is used.
First of all, when a UA that performs a registration procedure supports the GRUU extension, it indicates so by including the “gruu” option tag in the Supported header field. In addition, the UA provides, as part of the address in the Contact header field, an instance ID value in the new “+sip.instance” parameter.
When the registrar receives such a REGISTER request, if the request supports the GRUU extension, the registrar will construct a GRUU. Then the registrar associates the GRUU with the corresponding instance ID and contact address. It also communicates the GRUU back to the UA in a specific parameter (pub-gruu) in the Contact header field of the 200OK response.
The GRUU generated by the registrar is a SIP URI that includes a “gr” parameter with a value chosen by the registrar that identifies the particular UA instance. For example, a GRUU for John might look like:
sip:[email protected];gr=yd72394h9374d3
The easiest way for the registrar to construct a public[9] GRUU is to take the address of record, and place the actual value of the instance ID into the contents of the “gr” URI parameter.
Figure 15.16 shows a registration process when GRUU is supported.
Once a UA is registered, if an incoming request destined for the GRUU reaches the authoritative proxy, it will query the location service and retrieve the contact address associated to the specific UA instance that the GRUU refers to. It will then forward the request to that contact address.
User Agents that have obtained a GRUU will indicate its value in the Contact header field of any non-REGISTER request that they generate. This would allow other SIP entities to learn about the GRUU of the UA instance so as to use it in subsequent requests that need to be targeted to that particular instance. Another approach for external SIP entities (such as application servers) to learn about the GRUU of a particular UA instance could be to use an extension to the SIP-registration event package that includes the GRUU value [draft-ietf-sipping-gruu-reg-event]).
In this chapter, we presented the way SIP can be extended, and we also introduced some important general-purpose extensions. There are many other SIP extensions that are used in specific scenarios. In the next chapters, we will look into specific areas of applicability of the SIP protocol. While doing so, we will also highlight what new SIP extensions are needed in those specific areas. We will start in the next chapter by examining the presence and instant messaging services together with the SIP extensions needed to implement them.
[1] Funny as it may seem, using SIP for the control of networked appliances such as home devices was actually proposed sometime ago (draft-tsang-appliances-reqs), but was discarded and never became an RFC.
[2] The voice mail knows that it can require John’s UA to use PRACK because John signaled in the request that this extension is supported.
[3] In [RFC 3261], the only dialog-creating request was the INVITE request. [RFC 3265] defines a new method, called SUBSCRIBE, that can also create a SIP dialog. Some people are confused by this because they tend to associate “dialog” with “session,” although these are completely different concepts, as was explained in previous chapters. A SUBSCRIBE request does not initiate any session.
[4] The REFER method will be examined in Chapter 17.
[5] SIP conferencing will be analyzed in Chapter 19.
[6] Media servers will be explained in Chapter 19.
[7] The decision to forward or not a particular History-Info header field may depend on the value of the Privacy header, on local policy, and on whether the request is being forwarded to a Request-URI associated with a domain for which the processing entity is responsible.
[8] Actually, the example that is commonly shown to illustrate the need for the GRUU is the blind-transfer application. Readers can find the explanation on that use case in [draft-ietf-sip-gruu]. In the text, I have preferred to use the multidevice example, which also presents a practical scenario where there is a need for the GRUU.
[9] There are two types of GRUUs: public and temporary. Both of them must be constructed by the registrar and returned to the UA in the REGISTER response. In this high-level introduction to the GRUU concept, we are referring just to public GRUUs. Our aim is that readers can get just an overall understanding of this SIP extension. For a clear explanation on the differences between public and temporary GRUUs, readers are referred to [draft-ietf-sip-gruu].