SIP Request Messages |
91 |
Failed response. To modify the existing state, a PUBLISH would be sent containing the SIP-If-Match header field and a new message body. To remove the published state, a PUBLISH with the SIP-If-Match header field with an Expires:0 and no message body would result in the information being removed. Figure 8.7 shows an example of conditional publications.
Note that entity-tags are defined in HTTP [18]. However, the syntax and exact meaning are slightly different for SIP than HTTP.
Multiple presence UAs can publish for the same AOR to an ESC. In this case, the ESC will put the information together in an event specific way before generating notifications to subscribers. This process is referred to as state aggregation or composition.
4.1.10 REFER
The REFER method [14] is used by a user agent to request another user agent to access a URI or URL resource. The resource is identified by a URI or URL in the required Refer-To header field. Note that the URI or URL can be any type of URI: sip, sips, http, pres, and so forth. When the URI is a sip or sips URI, the REFER is probably being used to implement a call transfer service. REFER can also be used to implement peer-to-peer call control.
A REFER request can be sent either inside or outside an existing dialog. A typical call flow is shown in Figure 4.7. In this example, a UAC sends a REFER to a UAS. The UAS, after performing an authentication and authorization decides to accept the REFER and responds with a 202 Accepted response. Note that this response is sent immediately without waiting for the triggered request to complete. This is important because REFER uses the non-INVITE method state machine,
Figure 4.7 REFER example call flow.
92 |
SIP: Understanding the Session Initiation Protocol |
which requires an immediate final response, unlike an INVITE which may take several seconds (or even minutes) to complete. Since the Refer-To URI in this example is a sip URI, the UAC sends an INVITE setting the Request-URI to the Refer-To URI. This INVITE is successful since it receives a 200 OK response. This successful outcome is communicated back to the UAC using a NOTIFY method (described in Section 4.1.8). The message body of the NOTIFY contains a partial copy of the final response to the triggered request. In this case, it contains the start-line SIP/2.0 200 OK. This part of a SIP message is described in the ContentType header field as a message/sipfrag [19]. Note that this implicit subscription can be cancelled by including the Refer-Sub: false [20] header field in the REFER. If the 2xx response to the REFER also contains the Refer-Sub: false header field, no NOTIFYs will be sent.
An example of a REFER message is shown here:
REFER sip:m.rejewski@biuroszyfrow.pl SIP/2.0 Via SIP/2.0/UDP lab34.bletchleypark.co.uk:5060
;branch=z9hG4bK932039 Max-Forwards: 69
To: <sip:m.rejewski@biuroszyfrow.pl>;tag=ACEBDC From: Alan Turing <sip:turing@bletchleypark.co.uk>
;tag=213424
Call-ID: 3419fak3kFD23s1A9dkl CSeq: 5412 REFER
Refer-To: <sip:info@scherbius-ritter.com> Content-Length: 0
Another example is the use of REFER to “push” a Web page. In the example of Figure 4.8, the UAC sends a REFER to the UAS with a Refer-To set to an HTTP URL or a Web page. This causes the UAS to send a 202 Accepted then
Figure 4.8 REFER example showing Web page push.
SIP Request Messages |
93 |
send an HTTP GET request to the Web server identified by the URL. After the Web page has loaded, the UAS sends a NOTIFY containing a body and HTTP/1.0
200 OK.
A REFER and the SIP request triggered by the REFER may contain the Referred-By header field, which contains information about who requested the request.
Figure 4.9 shows an advanced use of REFER to implement a common PSTN or PBX feature known as attended transfer [21]. In this feature, the transferor is assumed to be in a dialog (in a session) with the transferee. The transferor sends an INVITE to another party, called the transfer target. After the session is established between the transferor and the transfer target, the transferor sends a REFER to the transferee, which causes the transferee to generate a new INVITE (called
Figure 4.9 Use of REFER and Replaces to perform attended transfer feature.
94 |
SIP: Understanding the Session Initiation Protocol |
a triggered INVITE) to the target. The successful INVITE replaces the existing session between the transferor and the transfer target. When the transferee receives notification that the transfer was successful, the session between the transferor and the transferee is terminated with a BYE. This application uses escaped header fields in the Refer-To URI. That is, certain SIP header fields are specified and prepopulated in the URI, which are then copied into the triggered INVITE. In this case, the transferor generates the Replaces header field necessary in the triggered INVITE to make the transfer succeed. The transferee copies the escaped Replaces header and places it in the INVITE.
The acceptance of a REFER with a 202 Accepted response creates an implicit subscription (a subscription without sending a SUBSCRIBE request; see Section 4.1.7). After sending the 202 Accepted, the target must send an immediate
NOTIFY with the status 100 Trying and Subscription-State: active;expires=60,
which indicates that the subscription will expire in 60 seconds (the expiration value is chosen by the notifier). The Subscription-State header contains the expiration time of the subscription. If that time period expires before the triggered request has completed, both sides terminate the subscription, with the notifier sending a final notification as discussed next.
The subscription is terminated when the transfer target (the party that accepted the REFER) sends a final notification (a NOTIFY with Subscription-State: terminated;reason=noresource). Usually, this is after the transfer target has received a final response to the triggered request. However, a transfer target that does not wish to establish a subscription and provide a final result of the REFER may send an immediate NOTIFY indicating that the subscription has been terminated. Each REFER sent creates a separate subscription. If more than one REFER is sent within a dialog, the resulting notifications (and subscriptions) are identified by an id parameter in the Event header field. The id parameter is optional in REFER triggered NOTIFYs except when multiple REFERs have been accepted, in which case it is mandatory.
The optional Referred-By header field can be included in a REFER request. The Refer-To header field can also contain feature tags [22] which tell the REFER recipient about the resource being referenced. Table 4.12 lists the mandatory header fields in a REFER request.
4.1.11 MESSAGE
The MESSAGE method [23] is used to transport instant messages (IM) using SIP. IMs usually consists of short messages exchanged in near-real time by participants engaged in a text conversation. MESSAGEs may be sent within a dialog or outside a dialog, but they do not establish a dialog by themselves. The actual message content is carried in the message body as a MIME attachment. All UAs
SIP Request Messages |
95 |
Table 4.12
Mandatory Header Fields in a REFER
Via
To
From
Call-ID
CSeq
Max-Forwards
Refer-To
that support the MESSAGE method must support plain/text format; they may also support other formats such as message/cpim [24] or text/html, as shown in Table 8.10.
A MESSAGE request normally receives a 200 OK response to indicate that the message has been delivered to the final destination. An IM response should not be sent in the message body of a 200 OK, but rather a separate MESSAGE request sent to the original sender. A 202 Accepted response indicates that the request has reached a store-and-forward device and will likely eventually be delivered to the final destination. In neither case does the 2xx response confirm that the message content has been rendered to the user. For this, the delivery notification mechanism is used, which will be discussed later in Section 8.5.2.
A MESSAGE request may use the im (instant message) URI scheme [25] in a Request-URI, although a client should try to resolve to a sip or sips URI.
An example MESSAGE call flow is shown in Figure 4.10.
Note that the MESSAGE method is not the only application of instant messaging with SIP. It is also possible to use SIP to establish an instant message
Figure 4.10 A SIP MESSAGE call flow showing instant message transport.