SIP provides the following capabilities for enabling multimedia sessions:

The SIP network typically comprises the following devices:

SIP by itself does not provide all the capabilities that are required to set up an interactive multimedia session. Instead, SIP is a protocol that is part of the framework of standard protocols that builds a multimedia architecture.

SIP agents or applications need other protocols for the following:

Sessions that are established using SIP typically use the following IETF protocols:

The preceding is by no means an exhaustive list of protocols that SIP uses. Depending on the signaling and application requirements, SIP might use other protocols.

SIP does not necessitate the use of the protocols in the preceding list. In the future, if newer or enhanced protocols perform similar functions, SIP will be able to use them with little or no change. Most of the information associated with these protocols is carried in the SIP message body. SIP treats the message body as an opaque container and transports it to the recipient. The SIP protocol layer does not interpret the message body.

SIP signaling is thus independent of the type of session being established. Therefore, from a SIP signaling perspective, the same set of messages is used regardless of whether an audio session, audio-video session, or some other type of session is established.

Figure 12-1 shows a basic SIP network comprising SIP proxies and user agents with connection to public switched telephone network (PSTN). The SIP UA, proxies, and SIP-PSTN gateway are located within an IP network. The SIP-PSTN gateway has SS7/PRI trunks going to a switch in the PSTN.

Figure 12-1. Path Taken by Request and Response Messages in a SIP Network

In Figure 12-1, solid lines represent SIP requests, and dotted lines indicate SIP responses.

SIP addresses identify a user or a resource within a network domain. SIP addresses are typically referred to as SIP URI. A SIP URI is typically an e-mail-type address with a format such as one of the following:

sip:user@domain:port

sip:user@host:port

The user field identifies a user by name, such as john.doe, or by telephone number, such as 4081234567, within the context of a domain or a host. The port is an optional field. If no port is specified, the default port for a SIP URI is 5060. If a port is explicitly specified, you must use it. Examples of SIP URIs are as follows:

sip:[email protected]

sip:[email protected]

The public SIP address of a user or a resource is referred to as an Address-of-Record (AOR). An AOR is a SIP URI that is globally routable and points to a domain whose location service can map the AOR to another SIP URI, where the user might be located.

RFC 3261 specifies a secure SIP URI format also known as a SIPS URI. The format of a SIPS URI is as follows:

sips:user@domain:port

or

sips:user@host:port

The default port for a SIPS URI is 5061.

SIP messages can be broadly divided into SIP requests and responses, as further defined in the sections that follow.

A SIP signaling session between two user agents might be comprised of one or more SIP transactions. A SIP transaction occurs between a UAC and a UAS, which might involve one or more intermediate SIP servers such as proxy or redirect. A SIP transaction comprises all messages that begin with the SIP request initiated from the UAC, until a final response (that is, a non-1xx response) is received from the UAS. A SIP transaction is identified by the Call-ID, via-branch, local tag, remote tag, and CSeq value. Figure 12-2 shows a SIP REGISTER transaction between a UAC and a registrar server. The SIP transaction comprises a SIP request message followed by one or more SIP response messages. In this case, the REGISTER message is a SIP request sent from the UAC to the registrar server. 100 Trying and 200 OK are SIP responses. The user agent server sends SIP responses to the UAC indicating the status of the SIP request.

Figure 12-2. SIP REGISTER Transaction

A SIP transaction can result in the establishment, modification, or termination of a media session. The establishment of a session also results in a SIP signaling relationship between the peers, known as a dialog. A dialog is defined as a peer-to-peer SIP relationship between two or more UAs that persists for the duration of the session. A dialog is the state identified by the Call-ID, the local tag, and the remote tag. Not all SIP transactions affect the state of a dialog. Multiple SIP transactions might take place within the context of a SIP dialog. Each SIP transaction within a dialog has a sequentially increasing integer value in the CSeq header.

A successful INVITE-200 OK transaction results in the establishment of a SIP dialog and an audio or video session between the participants. After the media session is established, you can exchange INVITE messages within the existing dialog context using the same Call-ID and tags to modify the media session parameters. Later, you can tear down the dialog using a BYE transaction or transfer it to another device using a REFER transaction, again within the dialog context.

A successful SUBSCRIBE-200 OK transaction results in the establishment of a dialog. The SUBSCRIBE request is discussed in the “SIP Extensions” section.

Dialog and transaction states are maintained at the SIP UAs or endpoints. SIP servers such as proxy and redirect typically maintain state for the duration of the transaction—that is, they maintain only the transaction state. The transaction state is held for at least 32 seconds per RFC 3261. SIP servers such as proxies and redirect servers maintain the transaction state, but not the dialog state, which enables them to serve many SIP endpoints. Because the network servers maintain only transaction state, a proxy that is going out of service within a cluster affects the transactions that are in progress but has no effect on established dialogs.

SIP transactions use either connection-oriented transport layer protocols such as TCP or Stream Control Transmission Protocol (SCTP) or connectionless protocols such as UDP. For connectionless protocols, SIP specifies that the SIP application start retransmission timers to retry the SIP requests to guarantee end-to-end reliability.

SIP defines a SIPS URI, which indicates the need for securing the end-to-end SIP signaling information in a network. SIP RFC 3261 specifies the use of TLS or IPsec to encrypt the signaling information.

Figure 12-3 illustrates the communication exchange for the INVITE method using the proxy server.

<source>Source: Henning Schulzrinne, Columbia University</source>

Figure 12-3. Proxy Mode of Operation

The operational steps in the proxy mode needed to bring a two-way call to succession are as follows:

Figure 12-4 illustrates the protocol exchange for the INVITE request using the redirect server.

<source>Source: Henning Schulzrinne, Columbia University</source>

Figure 12-4. Redirect Server Mode of Operation

The operational steps in the redirect mode to bring a two-way call to succession are as follows:

RFC 3261 does not define the B2BUA functionality. It describes it as concatenation of UAC and UAS. However, B2BUA forms an important element in providing centralized call control and feature management in SIP networks. Unlike a proxy, B2BUA can initiate new SIP calls and modify and terminate existing calls. SIP calls via a B2BUA server result in creation of two distinct dialogs, which enable it to modify one SIP session without affecting the other session.

B2BUA can act as a third-party call controller (3PCC) and can establish calls between two user agents. Figure 12-5 illustrates B2BUA acting as a 3PCC establishing calls between users A and B. RFC 3725 defines the best current practices for third-party call control in SIP. 3PCC modifies the session characteristics by modifying the Session Description Protocol (SDP) body. SDP is defined in RFC 2327.

Figure 12-5. B2BUA Server Mode of Operation

Figure 12-5 illustrates the steps for call establishment in B2BUA server mode. This illustration is one of the four message flows described in RFC 3725.

The B2BUA function also helps in protocol interworking between SIP devices with other protocols, such as H.323 and Media Gateway Control Protocol (MGCP). B2BUA allows transport layer interworking, such as TCP and User Datagram Protocol (UDP), IPv4/IPv6 address mapping, and topology or address hiding in SIP headers, such as Via, Contact, and Record-Route.

The products that leverage B2BUA functions include SIP-based IP-PBXs, softswitches, firewall/NAT traversal applications, call center applications, and conference servers.

The UA needs the IP address of the registrar or proxy server to register and provide SIP service. The UAC, however, might not have the IP address of a SIP proxy and might require mechanisms to discover the address of a SIP proxy server in its domain.

The UA gets the DNS server address during a DHCP procedure to acquire an IP address. The UA initiates a DNS procedure to discover the servers that provide SIP routing capabilities in its network. This allows the UA to reach peer user agents or services in the SIP network without explicit configuration.

The UAC can use DNS procedures (defined in RFC 3263) such as Naming Authority Pointer (NAPTR) to determine what services are supported in a domain. NAPTR records return a set of terminal DNS records, such as a Service Record (SRV) (defined in RFC 2782), to indicate the services and protocols that are supported within the domain. The UAC should filter those records that point to servers supporting SIP.

DNS SRV records help clients discover servers supporting an application protocol such as SIP by querying for a specific service and underlying transport protocol within a domain. To determine the address of SIP servers that support UDP transport in company.com domain, you need to query a query string _sip_udp.company.com with a DNS server. A DNS SRV query yields DNS A records, which then resolve to a SIP server IP address. The UA then sends the INVITE request to the resolved IP address.

SIP endpoints register with a SIP registrar server. Typically, the registrar and proxy function are implemented within the same server. SIP endpoints involved in the registration process are typically end-user devices such as SIP IP phones or servers providing specialized functions such as voice mail and presence status.

SIP users and services typically have a well-known or public SIP or SIPS URI, also known as an AOR. An AOR should be a globally reachable address. The SIP AOR is just another way to reach a user, similar to a telephone number, and might be on the business card or the home page of a person.

The UA, upon activation, creates a time-limited binding between the user AOR and its current IP address at the proxy server. This process is called registration. The AOR of the user is typically configured on a UA such as an IP phone. The IP address of the phone could vary because it is typically provided via DHCP.

The UA sends a SIP REGISTER request to the registrar within the domain, providing its current address in the Contact header. The UA indicates its AOR in the To header of the REGISTER message. The registrar updates the location service database to bind the AOR of the user to his current address or location. The location of the user is also known as the contact address and is conveyed in the Contact header of the REGISTER message. The location database that the proxy or registrar server uses thus maps an AOR to zero or more contact addresses.

The Contact header has an expires parameter that indicates the duration for which this binding is valid. In the call flow illustrated in Figure 12-6, expires is set to 3600 seconds or an hour. The UA is expected to refresh the registration within the time specified in the expires header to keep this binding intact at the registrar. Therefore, the UA sends periodic registration messages to refresh this information. In the absence of refresh, the registrar deletes this binding.

Figure 12-6. SIP Registration Process

The proxy uses the updated location database to route SIP requests that are addressed to the target SIP AOR.

This mechanism of registering the contact address with the registrar/location service enables SIP to inherently support user mobility. For example, an employee who has a SIP softphone on his laptop might travel to a different site within the company. When the SIP softphone or UA is turned on, it sends a REGISTER message to its configured SIP registrar and updates the location service with the current address at the visited site. The proxy can now seamlessly send calls for this user to the visited location based on the contact address in the location service database. This is also true if the user is traveling or telecommuting and logs on to the company network over a secure VPN connection. Figure 12-6 illustrates the SIP registration process and usage of associated headers.

A UAC that is acting on behalf of a user wants to establish an audio or audio-video session with another user. The INVITE request line has the SIP AOR of the called user for message routing. The UAC is now ready to send the INVITE to a SIP proxy server for routing the SIP message to the intended recipient.

After receiving a SIP request like INVITE, the proxy uses the AOR from the INVITE request line of the called user to look up the destination or next-hop address before forwarding the request.

SIP proxies are elements that route SIP requests to the UAS and SIP responses to the UAC. A request might traverse multiple proxies before it reaches the target UAS. Each proxy on the way makes routing decisions and modifies the request before forwarding the request to the next-hop device. A SIP proxy might rewrite the Request URI and add a Via header before forwarding the request message to the next-hop device. The proxy might insert additional headers like Record-Route in the request. SIP responses make their way through the same set of proxies as the request, but in the reverse order.

In practice, a SIP proxy is collocated with the SIP registrar server—that is, a proxy server usually implements the SIP registrar function. Thus, the proxy has access to the location database that is created during SIP registration. The UA routes the initial request such as INVITE or SUBSCRIBE to the local proxy in its domain. The proxy is then responsible for routing the SIP request based on its location database or static route information. Thus, the proxy serves as the rendezvous point for all SIP UAs and servers within the domain.

If the proxy is responsible for the domain in the request line, it looks up the location service database. This lookup provides zero or more addresses where the called user could be reached. Note that these contact addresses binding are available because of the registration procedure described previously or because of static configuration. If the contact address is a hostname, the procedure described in the previous section, such as using DNS SRV and A records for resolving the contact host-to-IP address, applies. The proxy then forwards the INVITE request to these locations.

If the proxy is not responsible for the domain in the request line, it forwards the request to the host that is specified in the request line.

To summarize, a SIP server such as a proxy or redirect server primarily performs the routing function—that is, it determines the next-hop device to where the SIP message needs to be forwarded. The next hop could be another proxy, redirect server, PSTN gateway, or UA. The SIP servers consult a location database to determine the next-hop address or the contact address of the user. Proxies can also have statically configured routes for devices like gateways into the PSTN or to another domain. A proxy can use DNS SRV or A records to route the message to the next hop.

Subsequent SIP requests within a dialog usually do not traverse SIP proxies. UAs typically use the Contact header received in the dialog-creating transaction to send subsequent requests directly to their peer user agent. For example, the INVITE transaction might get routed to the UA of the called party via one or more proxies. This leads to the establishment of a SIP dialog and an active call. When one of the parties involved in a call hangs up, one UA usually sends the BYE request directly to the other UA. This enables the SIP proxies to scale up to provide service to an extremely large number of UAs.

SIP proxies, however, can indicate their willingness to be in the path of subsequent requests within a dialog by inserting a Record-Route header in the dialog establishing a request such as INVITE or SUBSCRIBE. In that case, following the establishment of a dialog, the UAs generate a Route header based on the combination of Record-Route and Contact headers. The UAs and intermediate proxies then use the Route header to route subsequent transactions.

This is useful if the proxy provides services in addition to routing. The proxy might be generating accounting records for calls such as timestamps, parties involved, and so on. In this case, the proxy wants to process not only the initial INVITE (that is, the establishment of the call) but also the BYE transaction (that is, when the call was terminated). This helps recording of the start time, connect time, and disconnect time of a call.

You can also use the proxy to enforce policies or checks at a central point in the network, in which case the proxy inserts a Record-Route header to ensure that all subsequent requests pass through it.

Figure 12-7 illustrates the message flow for a SIP call setup and termination involving the SIP proxy.

Figure 12-7. SIP Call Setup and Teardown Involving the SIP Proxy

Figure 12-7 shows a SIP call setup from Alice to Bob via proxy. The SIP phones of Alice and Bob belong to the same enterprise, which is company.com. Both of their SIP IP phones are registered with the proxy server in the company.com domain.

The proxy forwards the SIP request to one or more contact addresses either in parallel or in sequence. This feature in SIP is known as forking. During sequential forking, the proxy waits for the final response for the forwarded request before forwarding the request to the next location. During parallel forking, requests are forwarded to all the locations in parallel. In each case, the proxy forwards the best final response to the previous hop device, which is the UAC. For example, if the proxy gets 486 Busy and 200 OK from two forked legs, the 200 OK is forwarded to the UAC. The proxy can use the CANCEL request to cancel the forked legs for which it has not received the final response.

Sequential forking might be used in find-me, follow-me services, whereas parallel forking might be used for group-ringing applications. The find-me, follow-me service lets users have one phone number, which enables them to be contacted on multiple physical phones such as office, home, and mobile phone in a user-defined sequence. A group-ringing application involves all phones in the group ringing simultaneously for an incoming call.

The SIP proxy can also provide enhanced routing capability based on local policy, application-defined scripts, or caller preferences. RFC 3841 is a SIP extension that enables a caller to express his preferences about request handling at the servers.

In the PSTN world, the caller does not have the authority or the capability to indicate how to route his calls or which features he prefers. SIP enables this via caller preference headers. These headers let the caller specify whether to route the call via proxy or redirect server, route the call only to the mobile phone of the called party, or reach the voicemail of the called party without ringing his phone.

Preference headers provide for a highly flexible and customizable call-routing application. This capability is discussed later in this chapter.

SIP continues to evolve, and new capabilities are being proposed through IETF drafts and RFCs. These new RFCs are extensions to the core SIP RFC 3261. To maintain backward compatibility with baseline SIP implementations and facilitate inter-working with devices that do not support the newer extensions, SIP defines the extension negotiation mechanism. The extension negotiation is achieved using the Require and Supported headers.

SIP mandates that SIP entities that receive a SIP message ignore unknown headers. If the UAC insists that the UAS must understand the SIP extension to process a request, the UAC must indicate this using the Require header. The Require header contains option tags that are defined in the SIP extensions.

SIP extensions can define new header fields within existing methods that cannot be reasonably processed by the UAS or proxy that supports the only core SIP RFC. Thus, the SIP extensions need to define option tags. Option tags are populated in Require or Supported headers.

The Require header indicates that the UAC insists that the UAS must understand the extension for processing the request. If the UAS does not support an option tag in the Require header, it must reject the request with the Unsupported header containing the offending option tag. The UAC can resend the request without the extensions, or it can choose to terminate the transaction.

The Supported header is an indication to the UAS that the UAC understands a certain extension. It is up to the UAS to decide whether it wants to use that extension in the response messages. For example, option tag 100rel in the INVITE request indicates that the UAC supports RFC 3262. The UAS can choose to send 18x responses reliably by adding Require:100rel in the 18x responses. UAs that implement SIP extensions usually have configuration options that enable an administrator to control the enabling or disabling of the feature.

The Allow header field lists the set of methods supported by the UA that generated the SIP message. The addition of this header in dialog-initiating transactions such as INVITE or SUBSCRIBE enables the UAS to discover which SIP methods the UAC supports. Similarly, the UAS can send this header in the final responses such as 200 OK to indicate similar information to the UAC. For example, an INVITE request received with the Allow header that does not contain the REFER method might lead to the UAS disabling the “transfer” key on its user interface.

SIP UAs can also send an OPTIONS request to query the capabilities of remote devices such as proxy or UA. The OPTIONS requests include Allow (describes SIP methods), Accept (content-types), and Supported (SIP extensions) headers. The remote device sends back an OPTIONS response (200 OK) containing Allow, Accept, Accept-Language, Accept-Encoding, and Supported headers.

RFC 3841 is a SIP extension that enables a caller to express his preferences about request handling at the intermediate servers. This enables SIP servers to use additional information such as caller preferences for routing a SIP request. This includes matching the capability of the called user end devices with the caller preferences. For example, the caller might want to establish an audio and video session. In that case, the proxy should not route the INVITE request to those contacts that can perform only audio or IM sessions. Similarly, the caller might express an interest to reach the called party on his wireless IP phone only or directly leave a voice-mail message without talking to him.

The UAC indicates its preference in the INVITE or SUBSCRIBE request by adding the Accept-Contact, Reject-Contact, and Request-Disposition header (all defined in RFC 3841).

The Request-Disposition header field lets the caller specify preferences for the way a server should process a SIP request. The caller might indicate whether the server should proxy or redirect the SIP request. In the redirect server mode, all contact locations corresponding to the called party are returned to the UAC in a 3xx response in the Contact header. The UA of the caller can apply customized routing policies on the contact locations it receives from the redirect server.

The user can also specify whether the proxy should forward a request to all possible contact locations in parallel or go through them in sequence, contacting the next address when it has received a non-2xx or non-6xx final response for the previous address. For example:

Request-Disposition: proxy, parallel

During registration, the UA can indicate its capabilities such as support of SIP methods, audio, video, and IM to the proxy server. When a UA registers, it can choose to indicate a feature set associated with a registered contact. (See RFC 3840 for details.) During the message routing process, the proxy tries to match the caller preferences with the callee UA capabilities.

Some examples of usage of the headers added to INVITE or SUBSCRIBE requests are as follows:

RFC 3265 describes the SIP extensions that enable SIP UAs to subscribe for notification from another SIP device when certain events take place. This is a framework by which SIP nodes can request notification from remote peers when monitored events take place. Notifications are generated for network events. Examples of network events include a user registering with or unregistering from the network, a voice mail being deposited in the mailbox of a user or a voice mail being retrieved from the mailbox, or a user changing his online status from idle to busy or away. This is essentially a mechanism to share state information in a distributed system, such as a SIP network. The framework is independent of the events that are being monitored. That is why you can adapt it so easily to a broad range of applications.

For example, a SIP phone might subscribe to the voice-mail status of its user from a SIP-based messaging system. The duration of the subscription is defined by the Expires header in the SUBSCRIBE request.

RFC 3265 defines the subscription and notification framework for SIP using two new SIP methods: SUBSCRIBE and NOTIFY.

A SIP entity acts as a subscriber when it sends a SUBSCRIBE for a specific event type, such as message-summary, to a SIP entity that the Request URI identifies. A new header “Event” defines the event type or the class of event types. The Event header is mandatory for SUBSCRIBE requests. The duration of the subscription is indicated in the Expires header.

The Request URI of a SUBSCRIBE request contains enough information to route the request to the appropriate entity per the request routing procedures that SIP outlines. The Request URI of a SUBSCRIBE request also contains enough information to identify the resource for which the event notification is desired, but not necessarily enough information to uniquely identify the nature of the event. The Event header defines the exact state for which the subscription is requested. For example, Event: presence refers to the presence state of the user, whereas Event: reg refers to the registration status of the SIP entity.

The UAS that is processing the SUBSCRIBE request acts as the notifier; it sends a NOTIFY request back to the subscriber whenever a state change takes place, while the subscription is active. For example, when a voice mail is deposited, the SIP-based messaging system sends a NOTIFY to the subscribing SIP phone. NOTIFY requests must contain a Subscription-State header that indicates whether a subscription is active, pending, or terminated.

If the Subscription-State value is pending in the NOTIFY request, the notifier has received the subscription but not authorized it. This might happen when the notifier is waiting for the end-user input to determine whether to accept a subscription from this subscriber.

If the “Subscription-State” value is active, the notifier has accepted and authorized the subscription. A Subscription-State value of terminated indicates that the notifier has terminated the subscription.

You can also send SUBSCRIBE messages within a preexisting dialog. If you send them outside of the dialog, SUBSCRIBE might cause the establishment of a new dialog. Subsequent NOTIFY messages are sent within the dialog that the SUBSCRIBE message creates. The subscriber can refresh the subscription by sending a new SUBSCRIBE with an Expires value.

Most common uses of this mechanism are for providing voice-mail status notifications, monitoring registration, and showing the presence status of users. You can also use this mechanism to emulate PBX features, which require shared state between devices, such as shared line appearance.

A registration represents a dynamic state that the registrar maintains in the network. Registration state changes when a user registers or unregisters from the network. Applications might be interested in monitoring the registration or online state of users.

For example, the application server subscribes to the registration state of Alice with the registrar. Initially, Alice is not registered, and the registrar indicates that in the initial NOTIFY. Later Alice comes online and registers. The registrar sends a NOTIFY to the application to indicate the new state.

The registration status is carried in the body of the NOTIFY request. It is represented using an XML document in the NOTIFY body. RFC 3680 defines the format of the XML body for the registration state.

Figure 12-8 illustrates the use of subscription to monitor registration status.

Figure 12-8. Monitoring Registration State Using the Subscribe-Notify Framework

RFC 3515 is a SIP extension that defines a new SIP request called REFER. REFER asks the recipient (identified by the REFER Request-URI) to access the resource described in the Refer-To header. The recipient of the REFER method is also required to send notifications to the sender about the progress made in accessing the resource. The notifications are sent using the NOTIFY method. This RFC also describes a new event package “refer” that is used in the notification messages for REFER. Thus, REFER causes an implicit subscription to be established at the recipient.

You can send REFER within an established dialog, such as within an INVITE dialog to trigger call transfer. In this case, the Refer-To header specifies the SIP URI of the transfer target.

If you send REFER outside of an established dialog, it leads to the establishment of a dialog. An application that can possibly use out-of-dialog REFER is the click-to-dial service. In this case, a user clicks on an online directory that causes his phone to call the desired party. The application server for the click-to-dial feature sends a REFER message to the phone of the initiator with a Refer-To pointing to the remote party. After the phone receives the REFER, it alerts its user (initiator of click-to-dial service) and then places a call by sending an INVITE request to the URI provided in the Refer-To header.

You can add third-party participants in a conference by using REFER. A client can send REFER to the participant, asking him to send an INVITE request to the conference URI. In addition, the client can send a REFER request to the conference controller, asking it to send an INVITE to the participant, requesting him to join the conference bridge. These are some sample usages of the REFER request. REFER is a flexible and powerful concept that you can use for a variety of applications.

Presence describes the willingness, availability, and ability of a person to communicate with another. Presence service enables users to publish their availability status and display messages or icons as a form of self-expression. Instant Messaging (IM) refers to the transfer of text messages between users in near real-time.

IM provides the capability of real-time, text-based communication, but it is useful only if the recipient can participate. Presence provides the ability to subscribe to the online status of a person to determine his willingness to engage in IM sessions and calls. When user presence is integrated within the communication infrastructure, it becomes easy to determine the best possible way to reach the target. For example, a busy executive might be in a conference call and might not be available for another call. However, he might be open for an IM session. Similarly, a missed call list on the SIP phone might indicate the current availability status of callers. This enables the user to prioritize the order in which he return the calls.

The presence status of a person is the aggregation of the status from various devices such as desk phone, calendar application, IM client on computer, and cell phone. Presence service collects this information and provides a unified view. This aggregation determines not only the availability of a person, but also the best way to reach him. Presence thus increases the likelihood of success in a call attempt.

A basic presence service enables users to publish and share their information with others to make the communication experience more personalized and productive. The presence service enables users to control who gets access to their presence state and the degree to which information is shared. The presence service can provide a default (also known as polite blocking) status such as unavailable to those subscribers who are denied access.

SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) is an IETF group that works on using SIP and proposing SIP extensions for interoperability across IM and presence services. RFC 3856 defines a presence event package for SIP.

You use the SUBSCRIBE method to subscribe to the presence state of another user. Although you can send subscribes directly to another user, typically you use a presence server to handle presence subscription requests and publish presence status on behalf of a user.

A presence server is a SIP network server that handles presence requests on behalf of the target end users and publishes presence information on behalf of a user. The presence server has an advantage over the peer-to-peer infrastructure because polling is not required to monitor when a remote party has come online. In addition, the server enables the implementation of network-based policy such as security and privacy control.

A UA sends a SUBSCRIBE with a presence event package to subscribe to the presence status of another user. The target user or resource whose presence information is being tracked is known as presentity. Presentity is defined in RFC 2778, which provides a model for presence and instant messaging. A SIP URI typically identifies the presentity.

The SIP proxy routes this SIP request to the presence server in the network. The presence server subscribes to the presentity of the target user or presence status on behalf of the subscriber. The SIP UA or endpoint device of the target user accepts the subscription for presence. This UA is also referred to as the presence agent (PA).

When the target user changes status, the PA notifies the presence server of a presence status change. The SIP NOTIFY request provides the notification, with the presence status contained in an XML body. The presence server subsequently notifies all remote parties subscribing to this presence information.

Because the presence server controls the distribution of sensitive presence information, the presence server must seek permission of the target user whenever a remote party requests subscription to its presence information. If the presence server has a predefined policy, the server uses that to allow or deny the subscription of the presence status. If the server has no such policy, it sends a request to the local user to authorize the subscription or use the default system-wide policy to handle the subscription.

RFC 3428 extends SIP and defines a new SIP request MESSAGE that enables the transfer of instant messages. MESSAGE requests carry the message content in the form of MIME body parts. Similarly, RFC 3903 defines a new SIP request: PUBLISH for publishing event states such as presence state.