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

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

Mechanism for subscribing to a homogenous list of resources <?xml version="1.0" encoding="UTF-8"?> <list xmlns="urn:ietf:params:xml:ns:rlmi“ uri="sip:yb2149-buddies@seoul.clic.cs.columbia.edu" version="1" fullState="true"> <name xml:lang="en">Buddy List at EDU</name> <resource uri="sip:won@seoul.clic.cs.columbia.edu"> <name> Won </name> <instance id="juwigmtboe" state="active" cid="bUZBsM@cs.columbia.edu"/> </resource> <resource uri="sip:seikwon@vienna.clic.cs.columbia.edu"> <name> Seikwon in vienna</name> <resource uri="sip:yoomi@delhi.clic.cs.columbia.edu"> <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)”

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

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

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

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

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

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

Example Call flow (Test case) SUBSCRIBE 200 Local RLS SUBSCRIBE to Local RLS SUBSCRIBE sip:yb2149-buddies@seoul.clic.cs.columbia.edu SIP/2.0 Via: SIP/2.0/UDP 128.59.15.32:5060;branch=z9hG4bKT92FRQwNAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA From: <sip:yb2149@seoul.clic.cs.columbia.edu>;tag=3697317275 To: <sip:yb2149-buddies@seoul.clic.cs.columbia.edu> CSeq: 1 SUBSCRIBE Call-ID: 2825265966@128.59.15.32 Contact: <sip:yb2149@128.59.15.32:5060> Content-Type: application/pidf+xml Event: presence Expires: 3600 Supported: eventlist Accept: application/pidf+xml Content-Length: 0

Example Call flow (Test case) NOTIFY 200 Local RLS NOTIFY to List Subscriber NOTIFY sip:yb2149@128.59.15.32:5060 SIP/2.0 Via: SIP/2.0/UDP 128.59.15.47:5060;branch=z9hG4bKwNyFRQfACgACAAAAAAAAAAAAAAAAAAAAAAAAAAA From: <sip:yb2149-buddies@seoul.clic.cs.columbia.edu>;tag=3288140409 To: <sip:yb2149@seoul.clic.cs.columbia.edu>;tag=3697317275 CSeq: 2 NOTIFY Call-ID: 2825265966@128.59.15.32 Contact: <sip:yb2149-buddies@128.59.15.47:5060> Content-Length: 197 Content-Type: application/pidf+xml Subscription-State: active Event: presence Require: eventlist <presence entity="pres:won@seoul.clic.cs.columbia.edu" xmlns:impp="urn:ietf:params:xml:ns:pidf"> <tuple id="efeef223"> <status> <basic>open</basic> </status> </tuple> </presence>

Example Call flow (Test case) SUBSCRIBE 200 Local RLS RLS in Vienna SUBSCRIBE from Local RLS to RLS in Vienna SUBSCRIBE sip:seikwon@vienna.clic.cs.columbia.edu SIP/2.0 Via: SIP/2.0/UDP 128.59.15.47:5060;branch=z9hG4bKwNyFRQfACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA From: <sip:yb2149@seoul.clic.cs.columbia.edu>;tag=3288140409 To: <sip:seikwon@vienna.clic.cs.columbia.edu> CSeq: 1 SUBSCRIBE Call-ID: 199984251@128.59.15.47 Contact: <sip:yb2149@128.59.15.47:5060> Content-Length: 0 Event: presence Expires: 3600 Supported: eventlist Accepted: application/pidf+xml

Example Call flow (Test case) NOTIFY 200 Local RLS RLS in Vienna NOTIFY from RLS in Vienna to Local RLS NOTIFY sip:yb2149@128.59.15.47:5060 SIP/2.0 Via: SIP/2.0/UDP 128.59.15.31:5060;branch=z9hG4bKxtyFRSHECwAAAAAAAAAAAAAAAAAAAAAAAAAAAA From: <sip:seikwon@vienna.clic.cs.columbia.edu>;tag=3894676096 To: <sip:yb2149@seoul.clic.cs.columbia.edu>;tag=3288140409 CSeq: 2 NOTIFY Call-ID: 199984251@128.59.15.47 Contact: <sip:seikwon@128.59.15.31:5060> Content-Length: 202 Content-Type: application/pidf+xml Subscription-State: active Event: presence Require: eventlist <presence entity="pres:seikwon@vienna.clic.cs.columbia.edu" xmlns:impp="urn:ietf:params:xml :ns:pidf"> <tuple id="efeef223"> <status> <basic>open</basic> </status> </tuple> </presence>

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