Resources.Rls HistoryShow minor edits - Show changes to markup April 26, 2013, at 12:37 PM
by
- Changed lines 1-191 from:
Resources -> Documentation -> Presence -> Resource List ServerResource List Serverwritten by Anca Vamanu OpenSIPS has a Resource List Server implementation following the specification in RFC 4662 and RFC 4826. Features:
DescriptionAs mentioned in the previous section, the RLS server is independent from the presence server. Its task is to handle Subscribe messages that have as a target a list and generate Notifies for them with the aggregated state of the entries in the list. For example, The RLS server might get a Subscribe message from 'alice' to her buddy list named 'alice-list'. SUBSCRIBE sip:alice-list@opensips.org SIP/2.0. Via: SIP/2.0/UDP 192.168.2.7:42521;rport;branch=z9hG4bKPjbcrHyV7gv7ksDabu36LZHlNnLEO-aXvc. Max-Forwards: 70. From: sip:alice@opensips.org;tag=3Rx6IkYlLyY88snX9vGQnhdUbsLk0Fck. To: sip:alice-list@opensips.org. Contact: <sip:0OAcbgzCkI@192.168.2.7:42521>. Call-ID: eY-mlt.Enp1zYoMpWBBYT7rblVtStXHY. CSeq: 9492 SUBSCRIBE. Event: presence. Expires: 300. Accept: multipart/related, application/rlmi+xml, application/pidf+xml. Allow-Events: presence.winfo, message-summary, xcap-diff, presence. User-Agent: ag-projects/sipclient-0.3.0-pjsip-1.0-trunk. Supported: eventlist. Content-Length: 0. Processing steps:
ConfigurationThe server is implemented in rls module. You can configure this module by setting its parameters:
See a configuration file example. DatabaseIt uses 2 tables in database: rls_presentity and rls_watchers rls_presentity
CREATE TABLE `rls_presentity` ( `id` int(10) unsigned NOT NULL auto_increment, `rlsubs_did` varchar(512) NOT NULL, `resource_uri` varchar(128) NOT NULL, `content_type` varchar(64) NOT NULL, `presence_state` blob NOT NULL, `expires` int(11) NOT NULL, `updated` int(11) NOT NULL, `auth_state` int(11) NOT NULL, `reason` varchar(64) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `rls_presentity_idx` (`rlsubs_did`,`resource_uri`), KEY `updated_idx` (`updated`) ) ENGINE=MyISAM; rls_watchers
CREATE TABLE `rls_watchers` ( `id` int(10) unsigned NOT NULL auto_increment, `presentity_uri` varchar(128) NOT NULL, `to_user` varchar(64) NOT NULL, `to_domain` varchar(64) NOT NULL, `watcher_username` varchar(64) NOT NULL, `watcher_domain` varchar(64) NOT NULL, `event` varchar(64) NOT NULL default 'presence', `event_id` varchar(64) default NULL, `to_tag` varchar(64) NOT NULL, `from_tag` varchar(64) NOT NULL, `callid` varchar(64) NOT NULL, `local_cseq` int(11) NOT NULL, `remote_cseq` int(11) NOT NULL, `contact` varchar(64) NOT NULL, `record_route` text, `expires` int(11) NOT NULL, `status` int(11) NOT NULL default '2', `reason` varchar(64) NOT NULL, `version` int(11) NOT NULL default '0', `socket_info` varchar(64) NOT NULL, `local_contact` varchar(128) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `rls_watcher_idx` (`presentity_uri`,`callid`,`to_tag`,`from_tag`) ) ENGINE=MyISAM ; (:commentboxchrono:) to:
(:redirect Documentation/Tutorials-RLS quiet=1:) May 12, 2011, at 12:28 PM
by
- Comments CleanupDeleted lines 189-194:
May 11, 2011, at 10:55 PM
by
- Comment addedAdded lines 190-195:
February 11, 2011, at 03:49 PM
by
- Added lines 3-4:
written by Anca Vamanu March 03, 2009, at 01:18 PM
by
- Added lines 187-189:
(:commentboxchrono:) March 02, 2009, at 05:36 PM
by
- Deleted line 16:
Changed lines 52-53 from:
to:
[@ <?xml version="1.0" encoding="UTF-8"?> Changed lines 66-68 from:
</rls-services> @]\\ to:
</rls-services> @] March 02, 2009, at 05:03 PM
by
- Changed lines 45-46 from:
The first necessary condition is having 'eventlist' as a value in a 'Supported' header.\\ to:
The primary condition is having 'eventlist' as a value in a 'Supported' header. March 02, 2009, at 05:02 PM
by
- Deleted line 45:
\\ March 02, 2009, at 04:43 PM
by
- Deleted lines 68-69:
Added lines 70-72:
Changed line 75 from:
to:
March 02, 2009, at 04:42 PM
by
- Changed lines 68-70 from:
The second step is to send an immediate Notify with the presence information of the entries in the list. The RLS will check to see if it has any information stored and will send that in a Notify with a multi-part body. For the first SUBSCRIBE message, the server will not have any information stored and The Notify will contain no presence state.
to:
The second step is to send an immediate Notify with the presence information of the entries in the list. The RLS will check to see if it has any information stored and will send that in a Notify with a multi-part body. For the first SUBSCRIBE message, the server will not have any information stored and The Notify will contain no presence state.
March 02, 2009, at 04:41 PM
by
- Changed line 62 from:
</list> to:
</list> March 02, 2009, at 04:39 PM
by
- Changed lines 54-55 from:
[@ <?xml version="1.0" encoding="UTF-8"?> to:
[@<?xml version="1.0" encoding="UTF-8"?> Changed lines 67-68 from:
</rls-services> @]\\ to:
</rls-services> @]\\ March 02, 2009, at 04:38 PM
by
- Added line 44:
\\ Added line 46:
\\ Added line 48:
\\ Changed lines 52-53 from:
to:
Changed line 69 from:
@] to:
@]\\ Changed lines 72-73 from:
to:
March 02, 2009, at 04:34 PM
by
- Added lines 45-46:
The second is that the list definition exists on the server( in fact on the XCAP server from that domain). You probably already know that the client stores the list definition on an XCAP server and the SIP RLS server has to get the list from the XCAP server. OpenSIPS can communicate with an XCAP server in two modes - that you can configure with the 'integrated_xcap_server' parameter. First, there is the common method defined by the XCAP protocol that evolves HTTP requests for retrieving information from the XCAP server. You will have the server working in this mode if you don't set the 'integrated_xcap_server' parameter, but you have to set the 'xcap_root' parameter with the addresses of the XCAp servers( you can set this more that once in case you use more XCAP servers). Then, you have a special communication mode, more efficient, that uses database as a intermediary: the XCAP server writes in a database table and the RLS server reads from there. The known XCAP server that can work in this mode is OpenXCAP. If you user this in your platform, you can set the 'integrated_xcap_server' parameter. March 02, 2009, at 04:32 PM
by
- Changed lines 43-48 from:
The first necessary condition is having 'eventlist' as a value in a 'Supported' header. The second is that the list definition exists on the server( in fact on the XCAP server from that domain). You probably already know that the client stores the list definition on an XCAP server and the SIP RLS server has to get the list from the XCAP server. OpenSIPS can communicate with an XCAP server in two modes - that you can configure with the 'integrated_xcap_server' parameter. First, there is the common method defined by the XCAP protocol that evolves HTTP requests for retrieving information from the XCAP server. You will have the server working in this mode if you don't set the 'integrated_xcap_server' parameter, but you have to set the 'xcap_root' parameter with the addresses of the XCAp servers( you can set this more that once in case you use more XCAP servers). Then, you have a special communication mode, more efficient, that uses database as a intermediary: the XCAP server writes in a database table and the RLS server reads from there. The known XCAP server that can work in this mode is OpenXCAP. If you user this in your platform, you can set the 'integrated_xcap_server' parameter. Using the means conform to the mode of operation, the RLS server will look for the list definition. If none is found, the RLS server will assume that the SUBSCRIBE message is not for him, even though it contains 'eventlist' in Supported header, and should forward the message to the presence server (from the script file). The rls_handle_suscribe function will return a code( the default one is '10', but it can also be configured through the parameter 'to_presence_code') when it deduces that the SUBSCRIBE message might be for the presence server. As you will see in the configuration file example, in this case the message should be handled by the presence server( calling handle_subscribe method if the server is collocated with the RLS server, or forwarding it to the presence server).
to:
March 02, 2009, at 04:25 PM
by
- Changed line 43 from:
to:
Changed lines 48-49 from:
to:
Changed lines 68-69 from:
to:
Changed line 72 from:
to:
March 02, 2009, at 04:23 PM
by
- Changed line 43 from:
1) The first step is to check if the subscription should really be handled by the RLS server. to:
Changed lines 48-49 from:
2) To continue with our example, let's consider that the list has the following description: to:
Changed lines 68-69 from:
3) The RLS server has to get the presence information from the presence servers. The next step is to send SUBSCRIBE messages on behalf of alice for the presence state of the entries in the list: bob and claire. The reason for which the RLS server sends for entry in the list a Subscribe message on behalf of the requester is related to the privacy authorization rules. Let's consider that there is another subscription from 'tom' to a list that also contains 'bob' as an entry. The RLS server might already have stored the presence state of bob due to the subscription that it already sent on behalf of alice, but it can not use this. The reason for this is that the RLS server does not know if tom is allowed to see the presence state of bob, or if this should be transformed according to some rules that bob has defined. Therefore, the RLS server has to send a SUBSCRIBE for each entry in every list and use only those responses when constructing the aggregated Notify. to:
Changed line 72 from:
4) Constructing Notify messages when receiving Notifies from presence servers with status updates. to:
March 02, 2009, at 04:22 PM
by
- Changed line 7 from:
to:
Changed lines 18-20 from:
to:
DescriptionChanged lines 70-71 from:
For this case, the OpenSIPS RLS server will send two SUBSCRIBE messages: to bob and clare, to the presence server in the local domain. If you set the 'presence_sever' parameter, the address in there will be used as an outbound proxy for the Subscribe messages. to:
For this case, the OpenSIPS RLS server will send two SUBSCRIBE messages: to bob and claire, to the presence server in the local domain. If you set the 'presence_sever' parameter, the address in there will be used as an outbound proxy for the Subscribe messages. It will the receive Notifies from the presence server. It is easy to detect this in the configuration file, since they have as a target the RLS server( have the RLS's server address in R-URI). This should be handled by the rls module by calling rls_handle_notify function. Added lines 73-74:
Due to a performance considerations, the RLS server will not send immediate RL Notifies when receiving a status update. It will wait a configurable amount of time( through the module parameter 'waitn_time') hoping to receive some more updates in the mean time and send more information in one Notify. March 02, 2009, at 04:11 PM
by
- Changed lines 66-72 from:
to:
The second step is to send an immediate Notify with the presence information of the entries in the list. The RLS will check to see if it has any information stored and will send that in a Notify with a multi-part body. For the first SUBSCRIBE message, the server will not have any information stored and The Notify will contain no presence state. 3) The RLS server has to get the presence information from the presence servers. The next step is to send SUBSCRIBE messages on behalf of alice for the presence state of the entries in the list: bob and claire. The reason for which the RLS server sends for entry in the list a Subscribe message on behalf of the requester is related to the privacy authorization rules. Let's consider that there is another subscription from 'tom' to a list that also contains 'bob' as an entry. The RLS server might already have stored the presence state of bob due to the subscription that it already sent on behalf of alice, but it can not use this. The reason for this is that the RLS server does not know if tom is allowed to see the presence state of bob, or if this should be transformed according to some rules that bob has defined. Therefore, the RLS server has to send a SUBSCRIBE for each entry in every list and use only those responses when constructing the aggregated Notify. For this case, the OpenSIPS RLS server will send two SUBSCRIBE messages: to bob and clare, to the presence server in the local domain. If you set the 'presence_sever' parameter, the address in there will be used as an outbound proxy for the Subscribe messages. 4) Constructing Notify messages when receiving Notifies from presence servers with status updates. March 02, 2009, at 03:56 PM
by
- Changed line 24 from:
@@ to:
[@ Changed lines 40-41 from:
@@ to:
@] Changed lines 49-50 from:
=xml [= to:
[@ Changed line 65 from:
=] to:
@] March 02, 2009, at 03:54 PM
by
- Added line 7:
Changed line 13 from:
to:
Added lines 16-66:
Message Flow DescriptionAs mentioned in the previous section, the RLS server is independent from the presence server. Its task is to handle Subscribe messages that have as a target a list and generate Notifies for them with the aggregated state of the entries in the list. For example, The RLS server might get a Subscribe message from 'alice' to her buddy list named 'alice-list'. @@ SUBSCRIBE sip:alice-list@opensips.org SIP/2.0. Via: SIP/2.0/UDP 192.168.2.7:42521;rport;branch=z9hG4bKPjbcrHyV7gv7ksDabu36LZHlNnLEO-aXvc. Max-Forwards: 70. From: sip:alice@opensips.org;tag=3Rx6IkYlLyY88snX9vGQnhdUbsLk0Fck. To: sip:alice-list@opensips.org. Contact: <sip:0OAcbgzCkI@192.168.2.7:42521>. Call-ID: eY-mlt.Enp1zYoMpWBBYT7rblVtStXHY. CSeq: 9492 SUBSCRIBE. Event: presence. Expires: 300. Accept: multipart/related, application/rlmi+xml, application/pidf+xml. Allow-Events: presence.winfo, message-summary, xcap-diff, presence. User-Agent: ag-projects/sipclient-0.3.0-pjsip-1.0-trunk. Supported: eventlist. Content-Length: 0. @@ Processing steps: 1) The first step is to check if the subscription should really be handled by the RLS server. The first necessary condition is having 'eventlist' as a value in a 'Supported' header. The second is that the list definition exists on the server( in fact on the XCAP server from that domain). You probably already know that the client stores the list definition on an XCAP server and the SIP RLS server has to get the list from the XCAP server. OpenSIPS can communicate with an XCAP server in two modes - that you can configure with the 'integrated_xcap_server' parameter. First, there is the common method defined by the XCAP protocol that evolves HTTP requests for retrieving information from the XCAP server. You will have the server working in this mode if you don't set the 'integrated_xcap_server' parameter, but you have to set the 'xcap_root' parameter with the addresses of the XCAp servers( you can set this more that once in case you use more XCAP servers). Then, you have a special communication mode, more efficient, that uses database as a intermediary: the XCAP server writes in a database table and the RLS server reads from there. The known XCAP server that can work in this mode is OpenXCAP. If you user this in your platform, you can set the 'integrated_xcap_server' parameter. Using the means conform to the mode of operation, the RLS server will look for the list definition. If none is found, the RLS server will assume that the SUBSCRIBE message is not for him, even though it contains 'eventlist' in Supported header, and should forward the message to the presence server (from the script file). The rls_handle_suscribe function will return a code( the default one is '10', but it can also be configured through the parameter 'to_presence_code') when it deduces that the SUBSCRIBE message might be for the presence server. As you will see in the configuration file example, in this case the message should be handled by the presence server( calling handle_subscribe method if the server is collocated with the RLS server, or forwarding it to the presence server). 2) To continue with our example, let's consider that the list has the following description: =xml <?xml version="1.0" encoding="UTF-8"?> <rls-services xmlns="urn:ietf:params:xml:ns:rls-services" xmlns:rl="urn:ietf:params:xml:ns:resource-lists" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <service uri="sip:alice-list@opensips.org"> <list name="alice-list"> <rl:entry uri="bob@opensips.org"/> <rl:entry uri="claire@opensips.org"/> </list> <packages> <package>presence</package> </packages> </service> </rls-services> July 29, 2008, at 04:17 PM
by
- Changed line 10 from:
[[#rls_features] to:
Changed lines 31-32 from:
[ [#rls_database]] to:
July 29, 2008, at 04:16 PM
by
- Changed lines 6-10 from:
to:
[[#rls_features] Added line 16:
Changed lines 31-32 from:
to:
[ [#rls_database]] July 29, 2008, at 04:14 PM
by
- Changed lines 18-30 from:
to:
July 29, 2008, at 04:13 PM
by
- Added lines 4-5:
OpenSIPS has a Resource List Server implementation following the specification in RFC 4662 and RFC 4826. Changed lines 9-10 from:
OpenSIPS has a Resource List Server implementation following the specification in RFC 4662 and RFC 4826. to:
Changed lines 25-30 from:
to:
July 29, 2008, at 03:49 PM
by
- Changed lines 16-28 from:
to:
Changed line 115 from:
] to:
@] July 29, 2008, at 03:37 PM
by
- Added line 14:
ConfigurationChanged lines 35-51 from:
to:
CREATE TABLE `rls_presentity` ( `id` int(10) unsigned NOT NULL auto_increment, `rlsubs_did` varchar(512) NOT NULL, `resource_uri` varchar(128) NOT NULL, `content_type` varchar(64) NOT NULL, `presence_state` blob NOT NULL, `expires` int(11) NOT NULL, `updated` int(11) NOT NULL, `auth_state` int(11) NOT NULL, `reason` varchar(64) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `rls_presentity_idx` (`rlsubs_did`,`resource_uri`), KEY `updated_idx` (`updated`) ) ENGINE=MyISAM; Added lines 76-103:
[@ CREATE TABLE `rls_watchers` ( `id` int(10) unsigned NOT NULL auto_increment, `presentity_uri` varchar(128) NOT NULL, `to_user` varchar(64) NOT NULL, `to_domain` varchar(64) NOT NULL, `watcher_username` varchar(64) NOT NULL, `watcher_domain` varchar(64) NOT NULL, `event` varchar(64) NOT NULL default 'presence', `event_id` varchar(64) default NULL, `to_tag` varchar(64) NOT NULL, `from_tag` varchar(64) NOT NULL, `callid` varchar(64) NOT NULL, `local_cseq` int(11) NOT NULL, `remote_cseq` int(11) NOT NULL, `contact` varchar(64) NOT NULL, `record_route` text, `expires` int(11) NOT NULL, `status` int(11) NOT NULL default '2', `reason` varchar(64) NOT NULL, `version` int(11) NOT NULL default '0', `socket_info` varchar(64) NOT NULL, `local_contact` varchar(128) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `rls_watcher_idx` (`presentity_uri`,`callid`,`to_tag`,`from_tag`) ) ENGINE=MyISAM ; ] July 29, 2008, at 03:34 PM
by
- Added lines 19-21:
rls_presentity Changed lines 32-58 from:
to:
rls_watchers
July 29, 2008, at 03:32 PM
by
- Added line 19:
July 29, 2008, at 03:29 PM
by
- Changed lines 2-28 from:
Resource List Serverto:
Resource List Server
OpenSIPS has a Resource List Server implementation following the specification in RFC 4662 and RFC 4826. Features:
The server is implemented in rls module. You can configure this module by setting its parameters: DatabaseIt uses 2 tables in database: rls_presentity and rls_watchers
July 29, 2008, at 02:46 PM
by
- Changed lines 1-2 from:
Resources -> Documentation -> Presence -> Presence ServerPresence Serverto:
Resources -> Documentation -> Presence -> Resource List ServerResource List ServerJuly 29, 2008, at 02:45 PM
by
- Added lines 1-2:
Resources -> Documentation -> Presence -> Presence ServerPresence Server |