4.1.5CANCEL

Table 4.6

Mandatory Header Fields in a CANCEL

Via

To

From

Call-ID

CSeq

Max-Forwards

ties of the user agent or server. A proxy never generates an OPTIONS request. A user agent or server responds to the request as it would to an INVITE (i.e., if it is not accepting calls, it would respond with a 4xx or 6xx response). A success class (2xx)

response can contain Allow, Accept, Accept-Encoding, Accept-Language, and

Supported headers indicating its capabilities. Feature tags (such as audio, video [3], and isfocus [4]) should be included with the Contact header field.

An OPTIONS request may not contain a message body. A proxy determines if an OPTIONS request is for itself by examining the Request-URI. If the RequestURI contains the address or host name of the proxy, the request is for the proxy. Otherwise, the OPTIONS is for another proxy or user agent and the request is forwarded. An example OPTIONS request and response contains:

OPTIONS sip:user@carrier.com SIP/2.0

Via: SIP/2.0/UDP cavendish.kings.cambridge.edu.uk ;branch=z9hG4bK1834

Max-Forwards:70

To: <sip:wiliamhopkins@cam.ac.uk>

From: J.C. Maxwell <sip:james.maxwell@kings.cambridge.edu.uk> ;tag=34

Call-ID: 747469e729acd305 CSeq: 29 OPTIONS Content-Length: 0

SIP/2.0 200 OK

Via: SIP/2.0/UDP cavendish.kings.cambridge.edu.uk;tag=512A6 ;branch=z9hG4bK0834 ;received=192.0.0.2

To: <sip:wiliamhopkins@cam.ac.uk>;tag=432

From: J.C. Maxwell <sip:james.maxwell@kings.cambridge.edu.uk> ;tag=34

Call-ID: 747469e729acd305 CSeq: 29 OPTIONS

Contact: <sip:william@tutors.cam.ac.uk>;audio;video Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, REFER Supported: replaces, join

Accept-Language: en, de, fr Content-Type: application/sdp Content-Length: 170

v=0

o=jc 2590845378 2590945578 IN IP4 tutors.cam.ac.uk s=-

c=IN IP4 tutors.cam.ac.uk

t=0 0

m=audio 32852 RTP/AVP 96 0 a=rtpmap:96 SPEEX/8000 a=rtpmap:0 PCMU/8000 m=video 82852 RTP/AVP 34 a=rtpmap:34 H263/90000

The mandatory headers in an OPTIONS request is listed in Table 4.7.

4.1.7SUBSCRIBE

The SUBSCRIBE method [5] is used by a UA to establish a subscription for the purpose of receiving notifications (via the NOTIFY method) about a particular event. A successful subscription establishes a dialog between the UAC and the UAS. The subscription request contains an Expires header field, which indicates the desired duration of the existence of the subscription. After this time period passes, the subscription is automatically terminated. The subscription can be refreshed by sending another SUBSCRIBE within the dialog before the expiration time. A server accepting a subscription returns a 200 OK response also containing an Expires header field. The expiration timer can be the same as the request, or the server may shorten the interval, but it may not lengthen the interval. There is no UNSUBSCRIBE method used in SIP—instead a SUBSCRIBE with Expires:0 requests the termination of a subscription and hence the dialog. A terminated subscription (either due to timeout out or a termination request) will result in a final NOTIFY indicating that the subscription has been terminated (see Section 4.1.8 on NOTIFY). A 202 Accepted response to a SUBSCRIBE does not indicate whether the subscription has been authorized—it merely means it has been understood by the server.

The basic call flow is shown in Figure 4.5. The client sends a SUBSCRIBE, which is successful, and receives NOTIFYs as the requested events occur at the server. Before the expiration of the subscription time, the client re-SUBSCRIBEs to extend the subscription and hence receives more notifications.

Note that a client must be prepared to receive a NOTIFY before receiving a 200 OK response to the SUBSCRIBE. Also, due to forking, a client must be prepared to receive NOTIFYs from multiple servers (the NOTIFYs will have different To tags

Table 4.7

Mandatory Header Fields in an OPTIONS

Via

To

From

Call-ID

CSeq

Max-Forwards

Figure 4.5 Example SUBSCRIBE and NOTIFY call flow.

and hence will establish separate dialogs), although only one 200 OK response to the SUBSCRIBE may be received.

An example SUBSCRIBE request is shown below:

SUBSCRIBE sip:ptolemy@rosettastone.org SIP/2.0 Via SIP/2.0/UDP proxy.elasticity.co.uk:5060 ;branch=z9hG4bK348471123

Via SIP/2.0/UDP parlour.elasticity.co.uk:5060 ;branch=z9hG4bKABDA ;received=192.0.3.4 Max-Forwards: 69

To: <sip:Ptolemy@rosettastone.org>

From: Thomas Young <sip:tyoung@elasticity.co.uk>;tag=1814 Call-ID: 452k59252058dkfj34924lk34

CSeq: 3412 SUBSCRIBE Allow-Events: dialog

Contact: <sip:tyoung@parlour.elasticity.co.uk> Event: dialog

Content-Length: 0

The type of event subscription is indicated by the required Event header field in the SUBSCRIBE request. Each application of the SIP Events framework [5] defines a package with a unique event tag. Each package defines the following:

•Default subscription expiration interval;

•Expected SUBSCRIBE message bodies;

•What events cause a NOTIFY to be sent, and what message body is expected in the NOTIFY;

•Whether the NOTIFY contains complete state or increments (deltas);

•Maximum notification rate.

A protocol called PSTN and Internet Interworking (PINT) [6] defines methods SUBSCRIBE, NOTIFY, and UNSUBSCRIBE, which have a similar semantic to SIP. A server can distinguish a PINT SUBSCRIBE request from a SIP SUBSCRIBE by the absence of an Event header field in the PINT request. A server should indicate which event packages it supports by listing them in an Allow-Events header field.

If a SUBSCRIBE refresh is sent within a dialog but receives a 481 Dialog Does Not Exist response, this means that the server has already terminated the subscription. The client should consider the dialog and subscription terminated and send a SUBSCRIBE to establish a new dialog and subscription.

An event template package is a special type that can be applied to any other package. The application of a template package to a package is shown by separating the package and template package names with a “.” as in presence.winfo, [7] which is the application of the watcher info template package to the presence package. Table 4.8 lists the current set of SIP event and template packages.

Table 4.9 lists the mandatory header fields in a SUBSCRIBE request. Packages are standardized in the IETF based on the requirements in [5].

Table 4.8

SIP Event Packages