my presence server tries to handle subscribe to sip:jh+presence@test.tutpro.com. that service uri is stored in rls-services document of user sip:jh@test.tutpro.com, but for some reason k does not find the service uri.
here is some debug:
May 1 19:08:43 siika /usr/sbin/pres-serv[27355]: INFO: Handling SUBSCRIBE sip:jh+presence@test.tutpro.com May 1 19:08:43 siika /usr/sbin/pres-serv[27355]: INFO: rls [subscribe.c:155]: searching document for user sip:jh@test.tutpro.com May 1 19:08:43 siika /usr/sbin/pres-serv[27355]: INFO: rls [subscribe.c:240]: rls_services document:#012<?xml version='1.0' encoding='UTF-8'?>#012<rls-services xmlns="urn:ietf:params:xml:ns:rls-services"><service uri="sip%3Ajh%2Bpresence%40test.tutpro.com"><resource-list>http%3A//192.98.102.10%3A8080/xcap-root/resource-lists/users/sip%3Ajh%40test.tutpro.com/index/%7E%7E/resource-lists/list%5B%40name%3D%22sipsimple_presence_rls%22%5D</resource-list><packages><package>presence</package></packages></service><service uri="sip%3Ajh%2Bdialog%40test.tutpro.com"><resource-list>http%3A//192.98.102.10%3A8080/xcap-root/resource-lists/users/sip%3Ajh%40test.tutpro.com/index/%7E%7E/resource-lists/list%5B%40name%3D%22sipsimple_dialog_rls%22%5D</resource-list><packages><package>dialog</package></packages></service></rls-services> May 1 19:08:43 siika /usr/sbin/pres-serv[27355]: INFO: rls [subscribe.c:253]: service uri sip:jh+presence@test.tutpro.com not found in rl document for user sip:jh@test.tutpro.com
any idea why the service uri is not found even when it appears to be in the document:
<service uri="sip%3Ajh%2Bpresence%40test.tutpro.com"><resource-list>http%3A//192.98.102.10%3A8080/xcap-root/resource-lists/users/sip%3Ajh%40test.tutpro.com/index/%7E%7E/resource-lists/list%5B%40name%3D%22sipsimple_presence_rls%22%5D</resource-list><packages><package>presence</package></packages></service>
could the escaped chars explain the failure or the fact that resource-list is an uri?
-- juha
Juha Heinanen writes:
could the escaped chars explain the failure or the fact that resource-list is an uri?
i added one more debug statement and got:
May 1 20:53:43 siika /usr/sbin/pres-serv[28224]: INFO: rls [subscribe.c:94]: matching <sip%3Ajh%2Bpresence%40test.tutpro.com> to sip:jh+dialog@test.tutpro.com
it clearly shows that the reason for not finding the uri are the escaped chars in xcap rls-services doc.
does anyone know if escaped chars are valid in rls-services service uri? if yes, then i guess the service uri needs to be unescaped before the comparison.
-- juha
Juha Heinanen writes:
it clearly shows that the reason for not finding the uri are the escaped chars in xcap rls-services doc.
i stole some code from opensips and normalized the rls-services uri. after that, the match was found:
May 1 22:15:45 siika /usr/sbin/pres-serv[29546]: INFO: rls [subscribe.c:213]: searching document for user sip:jh@test.tutpro.com May 1 22:15:45 siika /usr/sbin/pres-serv[29546]: INFO: rls [subscribe.c:298]: rls_services document:#012<?xml version='1.0' encoding='UTF-8'?>#012<rls-services xmlns="urn:ietf:params:xml:ns:rls-services"><service uri="sip%3Ajh%2Bpresence%40test.tutpro.com"><resource-list>http%3A//192.98.102.10%3A8080/xcap-root/resource-lists/users/sip%3Ajh%40test.tutpro.com/index/%7E%7E/resource-lists/list%5B%40name%3D%22sipsimple_presence_rls%22%5D</resource-list><packages><package>presence</package></packages></service><service uri="sip%3Ajh%2Bdialog%40test.tutpro.com"><resource-list>http%3A//192.98.102.10%3A8080/xcap-root/resource-lists/users/sip%3Ajh%40test.tutpro.com/index/%7E%7E/resource-lists/list%5B%40name%3D%22sipsimple_dialog_rls%22%5D</resource-list><packages><package>dialog</package></packages></service></rls-services> May 1 22:15:45 siika /usr/sbin/pres-serv[29546]: INFO: rls [subscribe.c:149]: comparing xcap doc uri sip:jh+presence@test.tutpro.com to uri sip:jh+presence@test.tutpro.com May 1 22:15:45 siika /usr/sbin/pres-serv[29546]: INFO: rls [subscribe.c:154]: uris matched
that, however, didn't get me much further. next i got error:
May 1 22:15:45 siika /usr/sbin/pres-serv[29546]: ERROR: rls [notify.c:1171]: resource list 'http%3A//192.98.102.10%3A8080/xcap-root/resource-lists/users/sip%3Ajh%40test.tutpro.com/index/%7E%7E/resource-lists/list%5B%40name%3D%22sipsimple_presence_rls%22%5D' is unidentifiable
the reason this time is escaped http uri, because uri scheme comparison does not take into account escaped : char. in rls/notify.c:
#define HTTP_PREFIX "http://" #define HTTP_PREFIX_LEN 7 ... if(strncmp(uri, HTTP_PREFIX, HTTP_PREFIX_LEN) == 0)
looks like there is lots of work to be done on rls module before these things are sorted out.
-- juha
looks like kamailio presence and especially rls is lagging behind in development as compared to opensips. it properly handles the escapes that i had trouble with, support external references in presence rules, xcal-diff, etc.
what should we do about kamailio presence modules? junk them and replace with opensips ones or implement the missing stuff ourselves? i personally don't have resources for the latter.
-- juha
On 5/2/13 7:16 PM, Juha Heinanen wrote:
looks like kamailio presence and especially rls is lagging behind in development ...
You statement is simply misinforming and creates confusion without a real foundation ... with a minimum effort you could have spotted a large amount of development that happened lately related to presence extensions, some of then not existing in any other server side software (to my knowledge). Over the past two years, presence probably accounts more than 30% of the development activity.
I run presence services in quite large deployments, going smooth for past few years. I never used rls due to lack of client side support, but presence, xcap server and the other related modules work stable and are up to date.
If you find an issue that you cannot solve, fire a report on the bug tracker. It will be picked up by a developer at some point in spare time, if you are under pressure, you can get to other solutions like finding software consultant to do it for you, it is open source.
what should we do about kamailio presence modules? junk them ...
That will never happen. My business model is to deploy Kamailio based solutions meeting requirements specified by customers, meaning that most of them come when they are sure Kamailio is the right application and there is no better alternative, that happened with last presence services deployments. Try to actually look at the features and even more, do some performance and stability tests of such services over tcp/tls.
Personally I rarely develop features that I don't need, but I fix issues that don't affect me as much as the time allows. My spare time doesn't go in comparing other similar products, there is always something more interesting to do, but I am pretty sure there is no better framework at this time to deploy SIMPLE presence extensions than Kamailio.
Cheers, Daniel
Daniel-Constantin Mierla writes:
i'm sorry about my provocative question about junking kamailio presence. i just got frustrated when i didn't get (and still haven't got) any response on the mailing list about the presence related bugs that i found when i tried to use rls services. i'll commit some patches and see how far i get before hitting more major issues.
-- juha
Juha Heinanen writes:
it clearly shows that the reason for not finding the uri are the escaped chars in xcap rls-services doc.
i just committed a patch to rls module (master version) that added support for escaped chars in rls services document.
is it ok to cherry-pick the commit also to 4.0? to me it looks like a bug fix.
-- juha
Hello,
if it was something that was not working as it should, go ahead and backport if you tested the patch.
Cheers, Daniel
On 5/3/13 7:01 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
if it was something that was not working as it should, go ahead and backport if you tested the patch.
i tested it with xcap documents generated by sipclients, which should be available also for macosx if you need access to rls capable sip client.
-- juha
-
Daniel-Constantin Mierla -
Juha Heinanen