[SR-Users] Entries in PUA List and RLS Watchers List

Sat Nov 3 20:22:55 CET 2012

Hi,

The presence server will only send NOTIFYs containing presentities to
authorised entities.  The only way the presence server knows whether an
entity is authorised or not is if the contact is allowed in the
pres-rules.  Therefore, the client _MUST_ update the pres-rules document.

When a pres-rules document is updated the Kamailio XCAP server (if
configured correctly) will run pres_update_watchers().  This updates the
contents of the watchers table based on the new pres-rules document.

If you are using an RCS client (which uses
org.openmobilealliance.pres-rules) you may have a pres-rules document that
contains an <external-list /> entry.  If this is the case it could be that
the client is changing the content of the external list but not the
pres-rules document.  Kamailio does not currently support external lists
for pres-rules (one of your earlier questions was about external lists in
resource-lists which are not supported either).

To add support for <external-list /> in pres-rules you would have to
update the presence and presence_xml modules so that when they load a
pres-rules document containing an <external-list /> and fill in the
watchers table they also download and process the external lists.  This
would fix the problem for both new SUBSCRIBEs and calls to
pres_update_watchers().  You would have the same synchronisation decision
to make (whether to block on retrieval of external document or suspend the
transaction) that I described for resource-list external lists.

Regards,

Peter

> Hello All,
>    I did resolve this by handling the notify properly in the config file.
>
> Now I have a new problem.....and it's something that has been raised
> before in the following thread:
>
> http://web.archiveorange.com/archive/v/jZFTG3ON951Zi1WiCcK9
>
> Would appreciate some input from the Kamailio RLS/Presence architects
> on how to resolve this:
>
> When client A authorizes client B to see it's presence information -
> it adds an entry for client B in its resource list and updates it's
> resource list on the server. This results in a back-end subscription
> being created with A as the watcher and B as the presentity.
>
> They still cannot see each others status because the status in the
> watchers & active_watchers tables is still 2 (pending). It won't
> change to active until the pres-rules document is updated....which is
> what jitsi does but I don't think that's the case with other clients.
>
> So it seems like handle_rls_update needs to do more than just create
> the back-end subscribes.
>
> Any input is appreciated.
>
> Sangeeta
>
> On Wed, Oct 31, 2012 at 9:41 AM, Sangeeta Shah <sangeeta.shah at gmail.com>
> wrote:
>> Hello All,
>>    Did anyone get a chance to look at my question below?
>>
>> Can anyone explain what will happen when the next hop is the rls
>> server address? How will this notify get handled.
>>
>> Thanks,
>> Sangeeta
>>
>> On Tue, Oct 30, 2012 at 5:01 PM, Sangeeta Shah <sangeeta.shah at gmail.com>
>> wrote:
>>> I have another follow up question on RLS behavior/implementation based
>>> on some additional debugging today:
>>>
>>> Client A (8475551001) starts up and registers with the presence server
>>> 1. It sends a subscribe with event=presence.winfo
>>> 2. Puts the following xml documents: pres-rules, rls-services,
>>> resource-list
>>>     Resource list has an entry for the client itself: 8475551001
>>>    - rls_update_subs is called and triggers a backend subscription for
>>> 8475551001
>>> 3. Sends a subscribe with event=presence, supported=eventlist
>>>    - rls_handle_subscribe is called for the subscribe above
>>>    - entry is inserted in the pua and rls_watchers table for the above
>>> subscribe
>>>    - notify is being sent from the rls module with the full state
>>> resource list:
>>>       xmlns=urn:ietf:params:xml:ns:rlmi
>>> 4. Sends a publish
>>>    - handle publish request is called and an entry is inserted into
>>> the presentity table for 8475551001
>>>
>>> I see a notify being generated from the "presence" module (notify.c) -
>>> which I think is triggered from the back end subscription above. The
>>> next hop for this message is the rls server address. What does that
>>> imply? Where is this notify going to end up?
>>> Earlier I thought rls_handle_notify was being called...but I verified
>>> that it's not.
>>>
>>>
>>>  I see the following info in the syslog:
>>> Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG:
>>> presence_xml [notify_body.c:65]: Missy: In preg_add_nobdy
>>>
>>> Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG:
>>> presence_xml [notify_body.c:81]: [user]=8475551001  [domain]=
>>> <server-ip>
>>>
>>> Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG:
>>> presence_xml [notify_body.c:463]: Missy: In aggregate_xmls: 1
>>> 8475551001@<server-ip> <server-ip>
>>>
>>>
>>> Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG:
>>> presence [notify.c:827]: Missy: Notify body: ....
>>>
>>> Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG:
>>> presence [notify.c:1539]: headers:#012Max-Forwards: 70#015#012
>>> Event: presence#015#012Contact:
>>> <sip:<server-ip>:5060;transport=udp>#015#012Subscription-State:
>>> active;expires=3599#015#012Content-
>>> Type: application/pidf+xml#015#012
>>>
>>> Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG:
>>> presence [notify.c:927]: CONTACT = sip:rls@<server-ip>:5060
>>>
>>> ct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG:
>>> tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=<sip:rls@<server-ip>:5060>
>>>
>>> Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG:
>>> tm [uac.c:182]: DEBUG: dlg2hash: 3999
>>>
>>> Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13364]: DEBUG:
>>> <core> [parser/msg_parser.c:624]: SIP Request:
>>> Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: INFO:
>>> presence [notify.c:1576]: NOTIFY sip:8475551001@<server-ip> via
>>> sip:rls@<server-ip>:5060 on behalf of sip:8475551001@<server-ip> for
>>> event presence
>>>
>>> Can anyone please shed any light on where the notify from the presence
>>> module will end up. Maybe it's somehow supposed to make it back to the
>>> rls module which would enter the info in the rls_presentity table and
>>> then trigger the full notify to the client. But that is not happening.
>>>
>>> What is the expected behavior based on what's been described above.
>>>
>>> Again thanks for taking the time to read/respond to the email.
>>>
>>> Sangeeta
>>>
>>> On Mon, Oct 29, 2012 at 6:35 PM, Sangeeta Shah
>>> <sangeeta.shah at gmail.com> wrote:
>>>> Peter/Hugh,
>>>>   After a bit more debugging and playing around with the server, I
>>>> have a few more follow up questions:
>>>>
>>>> 1. Purpose of rls_handle_notify: I understand the purpose of
>>>> rls_handle_subscribe and rls_update_subs. What's the purpose of
>>>> rls_handle_notify? If I have kamailio configured as a presence
>>>> server+rls server with integrated xcap do I need to add code in the
>>>> config file to handle notifies? I had this code and noticed that it
>>>> was being called, Wasn't sure if it is necessary to trigger notifies
>>>> when the resource list is updated?
>>>>
>>>> 2. When I add a contact (8475551004), I see rls_update_subs being
>>>> called and a back end subscription being inserted into the watchers
>>>> table as follows:
>>>>
>>>> | 21 | sip:8475551004 at domain | 8475551001       | domain   | presence
>>>> |      2 |        |    1351545844 |
>>>>
>>>> Does an insertion into this table trigger a notify to the presentity
>>>> to request authorization? I see that only when I restart the client
>>>> for 8475551004.
>>>>
>>>> When 8475551001 is authorized by 8475551004, I see rls_update_subs
>>>> being called for 8475551004 since it updates its resource list, but
>>>> the status of the entry in the watchers table never changes from 2
>>>> (pending) to active? What should trigger that?
>>>>
>>>> Any help is appreciated.
>>>>
>>>> Thanks,
>>>> Sangeeta
>>>>
>>>>
>>>> On Fri, Oct 26, 2012 at 6:03 PM, Peter Dunkley
>>>> <peter.dunkley at crocodile-rcs.com> wrote:
>>>>>> Peter,
>>>>>> I know the weekend is coming up, but I would love seeing this in the
>>>>>> RLS
>>>>>> README. Could you put that on your to-do list? We can't have TOO
>>>>>> MUCH
>>>>>> documentation...
>>>>>>
>>>>>
>>>>> It's all a matter of perspective.  If you are writing the
>>>>> documentation
>>>>> and there is lots to do it can certainly seem like TOO MUCH :-)
>>>>>
>>>>> I'll add it to my list though, probably do something next time I am
>>>>> in there.
>>>>>
>>>>> Peter
>>>>>
>>>>> --
>>>>> Peter Dunkley
>>>>> Technical Director
>>>>> Crocodile RCS Ltd
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>>> list
>>>>> sr-users at lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>>
>>>> --
>>>> Sangeeta Shah
>>>
>>>
>>>
>>> --
>>> Sangeeta Shah
>>
>>
>>
>> --
>> Sangeeta Shah
>
>
>
> --
> Sangeeta Shah
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd