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

Sangeeta Shah sangeeta.shah at gmail.com
Fri Nov 2 16:58:27 CET 2012


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



More information about the sr-users mailing list