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.s...@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.s...@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.s...@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@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.dunk...@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
