Hi Openser,
My question is regarding case-handling of SIP usernames with Openser 1.3.1 presence modules. I'm using a stand-alone presence server with pua/pua_usrloc modules. This is the test case:
1. user "sip:1234@10.10.90.51" sends SUBSCRIBE for user "sip:Jane@10.10.90.51" 2. user "sip:Jane@10.10.90.51" sends REGISTER
After 2, watcher does not receive NOTIFY from Openser/presence. DB contents is as follows:
active_watchers/presentity_uri contains "sip:Jane@10.10.90.51" pua/pres_uri contains "sip:jane@10.10.90.51" presentity/username contains "jane". location/username contains "jane" location/contact contains "sip:Jane@10.10.90.51:10001"
I'm not sure why case is different in these tables, and whether this causes the missed NOTIFY. Can anyone suggest what might be wrong? Here's the Openser route block:
route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; };
if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); exit; };
# we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (is_method("SUBSCRIBE|PUBLISH")) route(2); if (method == "REGISTER") { pua_set_publish();
save("location"); exit; } }
route[2] { # presence handling if (! t_newtran()) { sl_reply_error(); exit; };
if(is_method("PUBLISH")) { handle_publish(); t_release(); } else if( is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); };
exit; }