Download
1 / 14
150 likes | 245 Views
Resource List Server (RLS). SIP Event Notification Extension for Resource lists. Columbia University Yongju Bang (yb2149). Motivation. Environments - wireless network Subscribing to each resource individually is problematic Solution
E N D
Resource List Server (RLS) SIP Event Notification Extension for Resource lists Columbia University Yongju Bang (yb2149)
Motivation • Environments - wireless network • 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 • 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)” <?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> <resource uri="sip:yoomi@delhi.clic.cs.columbia.edu"> <name> Yoomi in delhi</name> </resource> </list>
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
One resource in the Same Domain and Two resources in the Different Domain PUBLISH 200 PUBLISH PUBLISH SUBSCRIBE 200 200 SUBSCRIBE 200 200 NOTIFY 200 NOTIFY 200 NOTIFY SUBSCRIBE 200 200 NOTIFY NOTIFY 200 200 Example Call flow (Test case)
SUBSCRIBE 200 Local RLS Example Call flow (Test case) 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>
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 Example Call flow (Test case) 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.
