Did you have time to look at our issue? Is it a stupid question? Thank you for your help
Andrés 2010/4/29 Andres2 Cores2 <[email protected]> > Thanks Anca > > I have another issue with RLS Subscription expiration. I send a Subscribe > to RLS and I expect a final (Subscription Ste=terminated) Notify when the > subscriptione expires. But I receive no such message. > On the other hand, after a few hours it seems indeed the subscription is > not active anymore. > > Sorry to bother you on this, maybe it is a configuration issue. > > Best regards > > Andrés > > > > 2010/4/28 Anca Vamanu <[email protected]> > >> Andres2 Cores2 wrote: >> > Thank you Anca >> > >> > In fact I am using the user-agent (picked it up from one config file), >> > either my client either opensips. >> > if($hdr(User-Agent) =~ "me") >> > { >> > xlog("L_DBG","RLS subscribe"); >> > $var(ret_code)= rls_handle_subscribe(); >> > if($var(ret_code)== 10){ >> > handle_subscribe(); >> > } >> > } >> > else >> > { >> > xlog("---- route 2 subscribe normal --- \n"); >> > handle_subscribe(); >> > } >> > >> > Now, after some fixes of the configuration, it seems the flow is >> > correctly managed. >> > There is still one point I am not sure. I had some issues with the >> > NOTIFY sent by PS to RLS >> > that was not correctly managed and I fixed it by adding this condition >> > for NOTIFY >> > >> > if >> > ((is_method("SUBSCRIBE")||is_method("NOTIFY")) && $rd == "10.62.0.155") >> { >> > # in-dialog subscribe requests >> > route(2); >> > exit; >> > } >> > >> > Where route(2) invokes rls_handle_notify() for NOTIFY requests. >> > >> > Do you think it is fine? It is not perfectly clear what is called the >> > "in-dialog" subscribe requests. >> > >> Yes, the check is all right. The most common check is if "uri == >> myself", because then it is sure that the Notify is addressed to >> OpenSIPS. The stricter check is uri== "what you set in server_address >> prameter for module rls". >> That comment line with in-dialog requests is put there because that if >> you look in the default configuration file - initial and in-dialog >> rquests are processed separately. The type is determined at the >> beginning and there are two different block for the two types of >> messages. So, for Subscribes route(2) is called in two places in the >> script - once for the initial ones and also for the in dialog ones. >> Anyhow that comment is not something you should worry about. >> >> Regards, >> >> -- >> Anca Vamanu >> www.voice-system.ro >> >> >> > Thanks for all. >> > Andrew >> > >> > >> > 2010/4/28 Anca Vamanu <[email protected] <mailto:[email protected]>> >> > >> > Hi Andrew, >> > >> > Thanks for your appreciation. >> > The thing that you need to take care with RLS are the Subscribe >> > messages >> > sent by the RLS server ( because this is the mechanism - when >> > receiving >> > a Subscribe for RLS the rls server will send more Subscribe >> > messages to >> > the presence server, and I see that you have the presence server >> > collocated with rls). You need to make sure that these are handled >> by >> > the presence server and that they do not go into rls again. For >> > this you >> > can check the source of the message and if it is the same machine >> just >> > call handle_subscribe. >> > >> > if(is_method("SUBSCRIBE") && si == "_local_ip_") >> > handle_subscribe(); >> > >> > If you watch the network trace and log where each subscribe goes for >> > processing and still notice this errors, post again an email on >> > the list. >> > >> > Regards, >> > >> > -- >> > Anca Vamanu >> > www.voice-system.ro <http://www.voice-system.ro> >> > >> > >> > >> > >> > Andres2 Cores2 wrote: >> > > Hi, >> > > >> > > First of all we would like to thank the whole opensips team. For >> > > testing our client, we are mainly interested in the presence and >> rls >> > > topics and found that a pretty good set of features is available >> > right >> > > now, so thanks for your job. >> > > >> > > During our tests we encountered an issue running opensips 1.6 in >> > > rls-server mode (simple presence works fine). It seems to us it is >> > > just a configuration issue or a bug in the routing rules, but we >> > can't >> > > find out it. >> > > >> > > From the client point of view I cannot succeed in receiving >> presence >> > > Notify messages body, only rlmi parts are provided. >> > > >> > > In fact it seems rls_handle_subscribe has issues when trying to >> send >> > > Subscribes to Presence on behalf of rls. I have systematically >> > errors >> > > "presence:get_stored_info: record not found in hash_table" and >> > > sometimes "Duplicate entry >> > > 'sip:[email protected]' for >> > key 2" >> > > >> > > Typically: >> > > Apr 26 13:45:57 [20047] ERROR:db_mysql:db_mysql_do_prepared_query: >> > > driver error: Duplicate entry >> > > 'sip:[email protected]' for >> > key 2 >> > > Apr 26 13:45:57 [20047] ERROR:presence:update_db_subs: >> unsuccessful >> > > sql insert >> > > Apr 26 13:46:01 [20045] ERROR:presence:get_stored_info: record not >> > > found in hash_table >> > > Apr 26 13:46:01 [20045] ERROR:presence:handle_subscribe: getting >> > > stored info >> > > Apr 26 13:46:11 [20045] ERROR:presence:get_stored_info: record not >> > > found in hash_table >> > > Apr 26 13:46:11 [20045] ERROR:presence:handle_subscribe: getting >> > > stored info >> > > Apr 26 13:46:21 [20045] ERROR:presence:get_stored_info: record not >> > > found in hash_table >> > > Apr 26 13:46:21 [20045] ERROR:presence:handle_subscribe: getting >> > > stored info >> > > Apr 26 14:25:40 [20586] ERROR:presence:get_stored_info: record not >> > > found in hash_table >> > > Apr 26 14:25:40 [20586] ERROR:presence:handle_subscribe: getting >> > > stored info >> > > Apr 26 14:25:45 [20586] ERROR:presence:get_stored_info: record not >> > > found in hash_table >> > > Apr 26 14:25:45 [20586] ERROR:presence:handle_subscribe: getting >> > > stored info >> > > Apr 26 14:25:50 [20586] ERROR:presence:get_stored_info: record not >> > > found in hash_table >> > > Apr 26 14:25:50 [20586] ERROR:presence:handle_subscribe: getting >> > > stored info >> > > Apr 26 14:25:55 [20586] ERROR:presence:get_stored_info: record not >> > > found in hash_table >> > > Apr 26 14:25:55 [20586] ERROR:presence:handle_subscribe: getting >> > > stored info >> > > Apr 26 14:26:05 [20586] ERROR:presence:get_stored_info: record not >> > > found in hash_table >> > > Apr 26 14:26:05 [20586] ERROR:presence:handle_subscribe: getting >> > > stored info >> > > Apr 26 14:26:09 [20586] ERROR:presence:get_stored_info: record not >> > > found in hash_table >> > > Apr 26 14:26:09 [20586] ERROR:presence:handle_subscribe: getting >> > > stored info >> > > >> > > My main settings for presence and rls modules are: >> > > >> > > modparam("presence|presence_xml", >> > > "db_url","mysql://opensips:opensip...@localhost/opensips") >> > > modparam("presence", "server_address", >> > "sip:[email protected]:5060 <http://sip:[email protected]:5060> >> > > <http://sip:[email protected]:5060>") >> > > modparam("presence", "clean_period", 30) >> > > modparam("presence_xml", "integrated_xcap_server", 1) >> > > >> > > modparam("pua", "db_url", >> > > "mysql://opensips:opensip...@localhost/opensips") >> > > >> > > # -- rls parameters -- >> > > modparam("rls","db_url", >> > "mysql://opensips:opensip...@localhost/opensips") >> > > modparam("rls", "server_address", "sip:[email protected]:5060 >> > <http://sip:[email protected]:5060> >> > > <http://sip:[email protected]:5060>") >> > > modparam("rls", "integrated_xcap_server", 1) >> > > modparam("rls", >> > "xcap_root","http://promethee.test.com:8888/xcap-root"; ) >> > > modparam("rls", "presence_server", "sip:[email protected]:5060 >> > <http://sip:[email protected]:5060> >> > > <http://sip:[email protected]:5060>") >> > > modparam("rls", "to_presence_code", 10) >> > > modparam("xcap_client","periodical_query",1) >> > > modparam("xcap_client","query_period",10) >> > > modparam("xcap_client","db_url", >> > > "mysql://opensips:opensip...@localhost/opensips") >> > > >> > > I can send you the routing rules if neeeded. >> > > >> > > Could you please help us? >> > > >> > > Many thanks >> > > >> > > Andrew >> > > >> > >> ------------------------------------------------------------------------ >> > > >> > > _______________________________________________ >> > > Users mailing list >> > > [email protected] <mailto:[email protected]> >> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > >> > >> > _______________________________________________ >> > Users mailing list >> > [email protected] <mailto:[email protected]> >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > >> > ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Users mailing list >> > [email protected] >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
