1. Resource List Server (RLS)
SIP Event Notification Extension for Resource lists
Columbia University
Yongju Bang (yb2149)

2. Motivation Environments - wireless network Solution
Subscribing to each resource individually is problematic
Solution
Use lists containing a set of URIs, each of which represents a resource for which the subscriber wants to receive information

3. Mechanism for subscribing to a homogenous list of resources
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi“
version="1" fullState="true">
<name xml:lang="en">Buddy List at EDU</name>
<resource
<name> Won </name>
<instance id="juwigmtboe" state="active"
</resource>
<resource
<name> Seikwon in vienna</name>
<resource
<name> Yoomi in delhi</name>
</list>
Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list
Receive NOTIFY when the state of any resources in the list changes
The notifier for the list is “Resource List Server (RLS)”

4. What is RLS? Notifier for the resource list
Accepts SUBSCRIBE to resource list and send NOTIFY to update the state of the resource in the list
RLS creates subscriptions after validation
generates notifications if the resource is in the same domain,
Otherwise, generates back-end subscriptions
For back-end subscription, RLS acts as a Subscriber

5. Operation of List subscriptions (1) - Negotiation of Support for Resource Lists
Client that support ‘event list’ should have ‘Supported: eventlist’ header in the SUBSCRIBE
RLS
Create subscription after validation and authorization
Use 'Require: eventlist' in the NOTIFY and 'Supported: eventlist' in the SUBSCRIBE for back-end subscription
If the header is not included, send 421(Extension required) response message

6. Operation of List subscriptions (1) - Negotiation of Support for Resource Lists
Diagram is to show how RLS works when SUBSCRIBE is received

7. Operation of List subscriptions (1) - Negotiation of Support for Resource Lists
Diagram is to show how RLS works when NOTIFY is received

8. Operation of List subscriptions (2) - RLS Generation of NOTIFY requests
RLS generates a single NOTIFY to the RLS subscriber whenever the state of any resource on the list changes
For resource in the Same Domain
NOTIFY to the subscriber based on its state
For resource in the Different Domain
SUBSCRIBE to another RLS in the Domain in which the resource is
After receiving NOTIFY, RLS can NOTIFY to the list subscriber

9. Example Call flow (Test case)
PUBLISH
200
SUBSCRIBE
NOTIFY
One resource in the Same Domain and Two resources in the Different Domain

10. Example Call flow (Test case)
SUBSCRIBE
200
Local RLS
SUBSCRIBE to Local RLS
SUBSCRIBE SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bKT92FRQwNAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
From:
To:
CSeq: 1 SUBSCRIBE
Call-ID:
Contact:
Content-Type: application/pidf+xml
Event: presence
Expires: 3600
Supported: eventlist
Accept: application/pidf+xml
Content-Length: 0

11. Example Call flow (Test case)
NOTIFY
200
Local RLS
NOTIFY to List Subscriber
NOTIFY SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bKwNyFRQfACgACAAAAAAAAAAAAAAAAAAAAAAAAAAA
From:
To:
CSeq: 2 NOTIFY
Call-ID:
Contact:
Content-Length: 197
Content-Type: application/pidf+xml
Subscription-State: active
Event: presence
Require: eventlist
<presence xmlns:impp="urn:ietf:params:xml:ns:pidf">
<tuple id="efeef223">
<status>
<basic>open</basic>
</status>
</tuple>
</presence>

12. Example Call flow (Test case)
SUBSCRIBE
200
Local RLS
RLS in Vienna
SUBSCRIBE from Local RLS to RLS in Vienna
SUBSCRIBE SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bKwNyFRQfACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
From:
To:
CSeq: 1 SUBSCRIBE
Call-ID:
Contact:
Content-Length: 0
Event: presence
Expires: 3600
Supported: eventlist
Accepted: application/pidf+xml

13. Example Call flow (Test case)
NOTIFY
200
Local RLS
RLS in Vienna
NOTIFY from RLS in Vienna to Local RLS
NOTIFY SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bKxtyFRSHECwAAAAAAAAAAAAAAAAAAAAAAAAAAAA
From:
To:
CSeq: 2 NOTIFY
Call-ID:
Contact:
Content-Length: 202
Content-Type: application/pidf+xml
Subscription-State: active
Event: presence
Require: eventlist
<presence xmlns:impp="urn:ietf:params:xml :ns:pidf">
<tuple id="efeef223">
<status>
<basic>open</basic>
</status>
</tuple>
</presence>

14. Future work Possibility of the ultimate nestings of list URI
Must implement safeguards to prevent such nestings from creating an infinite loop of subscriptions.