200 |
SIP: Understanding the Session Initiation Protocol |
8.4.4Filtering
An enhancement to SIP events is to allow the use of filters. A filter is an XML document included in a SUBSCRIBE, which contains information about the type and rate of notifications to be sent during the subscriptions. The filters extension is defined in RFC 4660 [38] while the XML filter format is defined in RFC 4661 [14]. Filters can be defined to apply to a single resource, a set of resources, or all resources in the subscription. Filtering can also be applied to specific domains. Filters can be changed during a subscription by including a new filter in a refresh SUBSCRIBE. A refresh SUBSCRIBE without a filter means continued use of the current filter. Filter removal can be done using the remove=”true” attribute. Figure 8.4 shows an example of filter creation, manipulation, and removal.
For example, consider the SUBSCRIBE containing a filter here:
SUBSCRIBE sip:c.dipisan@authors.org SIP/2.0 Via: SIP/2.0/TCP client.example.com:5060 ;branch=z9hG4bKxjfdsjfk
To: <sip:c.dipisan@authors.org>
From: <sip:jane.austen@southhampton.uk>;tag:12341111 Call-ID: 232432udfidfjmk342
Figure 8.4 Example event filter creation, manipulation, and removal.
Presence and Instant Messaging |
201 |
CSeq: 1 SUBSCRIBE Expires: 3600 Event: Presence
Contact: <sip:jane@chawton.southhampton.uk;transport=tcp> Content-Type: application/simple-filter+xml Content-Length: ...
<?xml version=”1.0” encoding=”UTF-8”?>
<filter-set xmlns=”urn:ietf:params:xml:ns:simple-filter”> <ns-bindings>
<ns-binding prefix=”pidf” urn=”urn:ietf:params:xml:ns:pidf”/>
<ns-binding prefix=”rpid” urn=”urn:ietf:params:xml:ns:pidf:rpid”/>
</ns-bindings>
<filter id=”123” uri=”sip:c.dipisan@authors.org”> <what>
<include type=“xpath“> //pidf:tuple/pidf:status[pidf:basic=“open“]/pidf:basic
</include>
<include type=“xpath“> //pidf:tuple[pidf:status/pidf:basic=“open“]/rpid:class
</include>
<include type=“xpath“> //pidf:tuple[pidf:status/pidf:basic=“open“]/pidf:contact </include>
</what> </filter> </filter-set>
The filter is defined by the Content-Type: application/simple-filter+xml
message body. The filter is contained in the <filter-set> element, which includes a single <filter> element. This filter will result in notifications only being sent that have either the value open inside the <status> element in the PIDF <basic>, <contact> elements, or the RPID <class> element. All other notifications would be suppressed.
8.4.5Conditional Event Notifications and ETags
Another optimization involves the use of conditional notifications as defined in [25]. In the normal operations of SIP events, every SUBSCRIBE will generate an automatic NOTIFY. While the initial NOTIFY usually contains useful initial state, the NOTIFYs sent to refresh SUBSCRIBEs often do not contain any new information. NOTIFYs can be sent with the SIP-ETag header field, which contains an identifier known as the entity-tag for the current state. A subsequent refresh SUBSCRIBE can then include this identifier in a Suppress-If-Match header field. If the entity-tag in the SUBSCRIBE matches the local entity-tag, the automatic NOTIFY will be suppressed and a 204 No Notification response sent. If the entitytag does not match, indicating a change in state, the NOTIFY will be generated. This is shown in Figure 8.5.
202 |
SIP: Understanding the Session Initiation Protocol |
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 8.5 Conditional notifications and ETags.
This mechanism can also be used to poll for state. An example is shown in Figure 8.6.
8.4.6Partial Publication
Another optimization is defined in [23] for the partial publication of presence information. Normally, each time presence information changes, the entire PIDF containing full state must be sent. This extension allows the parts of the PIDF that have changed to be sent. Figure 8.7 shows the basic operation in which first a full publication must be sent. After that, partial publications can be sent. In this flow, the first PUBLISH creates the state information and the second updates it. The third attempts to update it, but the previous state has expired. The full state is then published with the fourth PUBLISH.
For example, consider the partial publication message:
PUBLISH sip:murasaki@kyoto.jp SIP/2.0
Via: SIP/2.0/TCP court.kyoto.jp:15332;branch=z9hG4bKfdDsjfk1 To: Murasaki Shikibu <sip:murasaki@kyoto.jp>
|
|
Presence and Instant Messaging |
203 |
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 8.6 Polling for state.
From: Murasaki Shikibu <sip:murasaki@kyoto.jp> ;tag=v1F23d41111
Call-ID: 8Fd3wfldfa
CSeq: 61 PUBLISH Event: presence
SIP-If-Match: 34616386238299 Expires: 3600
Content-Type: application/pidf-diff+xml Content-Length: ...
<?xml version=”1.0” encoding=”UTF-8”?> <p:pidf-diff xmlns=”urn:ietf:params:xml:ns:pidf”
xmlns:p=”urn:ietf:params:xml:ns:pidf-diff” xmlns:r=”urn:ietf:params:xml:ns:pidf:rpid” entity=”pres:murasaki@kyoto.jp”>
<p:add sel=”presence/note” pos=”before”> <tuple id=”L6erPt47”>
<status>
<basic>open</basic>
</status>
<contact priority=”0.4”>mailto:genji@tales.jp</contact>