15 May
2008
15 May
'08
2:56 a.m.
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;
}