Scenario : Loading a rls-services XML file to admin@example.com (XCAP HTTP PUT) : ```xml <?xml version="1.0" encoding="UTF-8"?> <rls-services> <service uri="sip:points@example.com"> <list name="points"> <entry uri="sip:point1@example.com"> <display-name>Point 1</display-name> </entry> <entry uri="sip:point2@example.com"> <display-name>Point 2</display-name> </entry> <entry uri="sip:point3@example.com"> <display-name>Point 3</display-name> </entry> </list> <packages> <package>presence</package> </packages> </service> </rls-services>
``` alice@example.com -> subscribes to event presence on -> point1@example.com bob@example.com -> subscribes to event presence on -> point1@example.com carol@example.com -> subscribes to event presence on -> point1@example.com Waiting some time (10~20 seconds, approx rls, waitn_time option)... dave@example.com -> subscribes to event presence on -> point1@example.com admin@example.com -> subscribes to RLS event presence.winfo for the first time on -> points@example.com
Kamailio sends only partial state as mentioned in "fullState="false"" and "state="partial"" and only for user dave (last one subscribed) with version "5" : ```xml NOTIFY sip:admin@192.168.1.56:7060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 192.168.1.56;branch=z9hG4bKdfb9.fc98d020000000000000000000000000.0 To: sip:admin@example.com;tag=aoW7RQAYSw From: sip:points@example.com;tag=8790d89920d6a95cb6b77ece9ac70b8d-80d4 CSeq: 2 NOTIFY Call-ID: cCiV8exRxM Content-Length: 1050 User-Agent: kamailio (4.4.0-dev2 (i386/linux)) Max-Forwards: 70 Event: presence.winfo Contact: sip:rls@192.168.1.56:5060 Subscription-State: active;expires=8 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml";start="<1438875442.sip:points@example.com.1907048652>";boundary="LQLZpLYXZgJh5s2VPxHXdN1b"
--LQLZpLYXZgJh5s2VPxHXdN1b Content-Transfer-Encoding: binary Content-ID: <1438875442.sip:points@example.com.1907048652> Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0"?> <list uri="sip:points@example.com" xmlns="urn:ietf:params:xml:ns:rlmi" version="2" fullState="false"><resource uri="sip:point2@example.com"><instance id="Scf8UhwQ" state="active" cid="1438875442.sip:point2@example.com.1254686349"/></resource></list>
--LQLZpLYXZgJh5s2VPxHXdN1b Content-Transfer-Encoding: binary Content-ID: <1438875442.sip:point2@example.com.1254686349> Content-Type: application/watcherinfo+xml
<?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="5" state="partial"> <watcher-list resource="sip:point2@example.com" package="presence"> <watcher id="alice-bob-carol-dave" event="subscribe" status="active">sip:dave@example.com</watcher> </watcher-list> </watcherinfo>
--LQLZpLYXZgJh5s2VPxHXdN1b-- ``` If I am reading well RFC 4662 Section 4.5 (https://tools.ietf.org/html/rfc4662#section-4.5) Kamailio should send a full state NOTIFY for initial RLS subscribes and then it can send a partial state for updates.
I think we lose information here, but if a re-subscribe is performed I get a full NOTIFY, which is my current "workaround" :
1 - Initial subscribe 2 - If full state -> OK 3 - If partial state -> re-subscribe
```xml NOTIFY sip:admin@192.168.1.56:7060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 192.168.1.56;branch=z9hG4bK00c9.e11aad40000000000000000000000000.0 To: sip:admin@example.com;tag=AcM3AIKdAx From: sip:points@example.com;tag=8790d89920d6a95cb6b77ece9ac70b8d-6573 CSeq: 1 NOTIFY Call-ID: cCiV8exRxM Content-Length: 3308 User-Agent: kamailio (4.4.0-dev2 (i386/linux)) Max-Forwards: 70 Event: presence.winfo Contact: sip:rls@192.168.1.56:5060 Subscription-State: active;expires=17 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml";start="<1438875460.sip:points@example.com.151089623>";boundary="lxwToHs6uINUYOQjbengkND5"
--lxwToHs6uINUYOQjbengkND5 Content-Transfer-Encoding: binary Content-ID: <1438875460.sip:points@example.com.151089623> Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0"?> <list uri="sip:points@example.com" xmlns="urn:ietf:params:xml:ns:rlmi" version="1" fullState="true"> <resource uri="sip:point1@example.com"> <instance id="Scf8UhwQ" state="active" cid="1438875460.sip:point1@example.com.236018746"/> </resource> <resource uri="sip:point2@example.com"> <instance id="Scf8UhwQ" state="active" cid="1438875460.sip:point2@example.com.720412755"/> </resource> <resource uri="sip:point3@example.com"> <instance id="Scf8UhwQ" state="active" cid="1438875460.sip:point3@example.com.1064774448"/> </resource> </list>
--lxwToHs6uINUYOQjbengkND5 Content-Transfer-Encoding: binary Content-ID: <1438875460.sip:point1@example.com.236018746> Content-Type: application/watcherinfo+xml
<?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="1" state="full"> <watcher-list resource="sip:point1@example.com" package="presence"> <watcher id="796ffdf4-22384@192.168.1.56" event="subscribe" status="active">sip:admin@example.com</watcher> <watcher id="796ffdf4-22381@192.168.1.56" event="subscribe" status="active">sip:admin@example.com</watcher> </watcher-list> </watcherinfo>
--lxwToHs6uINUYOQjbengkND5 Content-Transfer-Encoding: binary Content-ID: <1438875460.sip:point2@example.com.720412755> Content-Type: application/watcherinfo+xml
<?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="1" state="full"> <watcher-list resource="sip:point2@example.com" package="presence"> <watcher id="796ffdf5-22384@192.168.1.56" event="subscribe" status="active">sip:admin@example.com</watcher> <watcher id="alice-bob-carol-dave" event="subscribe" status="active">sip:alice@example.com</watcher> <watcher id="alice-bob-carol-dave" event="subscribe" status="active">sip:bob@example.com</watcher> <watcher id="alice-bob-carol-dave" event="subscribe" status="active">sip:carol@example.com</watcher> <watcher id="alice-bob-carol-dave" event="subscribe" status="active">sip:dave@example.com</watcher> <watcher id="796ffdf5-22381@192.168.1.56" event="subscribe" status="active">sip:admin@example.com</watcher> </watcher-list> </watcherinfo>
--lxwToHs6uINUYOQjbengkND5 Content-Transfer-Encoding: binary Content-ID: <1438875460.sip:point3@example.com.1064774448> Content-Type: application/watcherinfo+xml
<?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="1" state="full"> <watcher-list resource="sip:point3@example.com" package="presence"> <watcher id="796ffdf6-22384@192.168.1.56" event="subscribe" status="active">sip:admin@example.com</watcher> <watcher id="796ffdf6-22381@192.168.1.56" event="subscribe" status="active">sip:admin@example.com</watcher> </watcher-list> </watcherinfo>
--lxwToHs6uINUYOQjbengkND5-- ```
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/276
Can you try replacing the IF condition in the snippet you pasted above with:
``` if(get_to(msg)->tag_value.s==NULL || get_to(msg)->tag_value.len==0) { ```
then re-compile, install and test?
I will look deeper when I get a chance, but for the moment it might be an workaround to get you going.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/276#issuecomment-128692310
Well replacing this :
```C++ if (dbmode != RLS_DB_ONLY) ```
By this : ```C++ if(get_to(msg)->tag_value.s==NULL || get_to(msg)->tag_value.len==0) ```
Which is a detection of initial transaction if I'am understanding well (no to tag). There is such a detection upper in the code (line 610-611) :
```C++ if(get_to(msg)->tag_value.s==NULL || get_to(msg)->tag_value.len==0) { /* initial Subscribe */ ```
But I was afraid that the test dbmode != RLS_DB_ONLY wasn't here for nothing (Maybe performance reasons ?)
I ran my test 10 times and everything seems OK for now.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/276#issuecomment-128709229
Did everything work fine with the patch after all these days? If yes, then I will commit the change.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/276#issuecomment-133701872
Closed #276.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/276#event-405877119
Pushed the change and backported to 4.3.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/276#issuecomment-139216203
-
Daniel-Constantin Mierla -
foucse