[Devel] [ openser-Bugs-1680615 ] REGISTRAR & USRLOC: unable to
unregister a user properly
SourceForge.net
noreply at sourceforge.net
Thu Mar 15 13:51:19 CET 2007
Bugs item #1680615, was opened at 2007-03-14 15:10
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1680615&group_id=139143
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.2.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kovalevich Victor (vkc1974)
Assigned to: Nobody/Anonymous (nobody)
Summary: REGISTRAR & USRLOC: unable to unregister a user properly
Initial Comment:
It looks like save() function of REGISTRAR module does not remove a registration entry for a user while REGISTER request with Expires: 0 header processing. Such entry is kept within location table (database access schema was set to 3 (DB-Only scheme, see http://www.openser.org/docs/modules/1.2.x/usrloc.html). So that an entry in location table (in internal cache as well) is removed only when it has expired. While time term (since registrations has processed by registration entry will have been removed as time expiration) OpenSER considers that unregistered user as really registered. REGISTRAR module provides two methods using access to usrloc: lookup() and registered() which return true if there is an entry for a contact in the table discussed below.
There are a part of openser.cfg script and appropriate part of log are below:
xlog("L_DBG", "*** $rm *** Look for valid contact for $ru ($rU)\n");
lookup("location");
switch ($retcode)
{
case -1:
xlog("L_DBG",
"*** $rm *** There is no registaration for $ru in usrloc, try to store given message as offline\n");
#
# MSILO - storing as offline message
if (avp_check("$avp(s:source_site)", "eq/Asterisk PBX"))
{
remove_hf("User-Agent");
}
#
# This is amessage to a user in off-line state - try to store it
xlog("L_DBG", "*** $rm *** m_store(\"$ru\")\n");
if (m_store("$ru"))
{
xlog("L_DBG", "*** $rm *** a message has been stored in off-line mode\n");
sl_send_reply("202", "Accepted, message has been stored");
xlog("L_DBG", "*** $rm *** [202, Accepted] has been sent to $fu($fU)\n");
}
else
{
xlog("L_DBG", "*** $rm *** Unable to store a message for $ru\n");
sl_reply_error();
}
avp_delete("$avp(s:source_site)");
return();
case -2:
xlog("L_DBG", "*** $rm *** There is a valid contact for $ru but it does not support $rm\n");
sl_reply_error();
avp_delete("$avp(s:source_site)");
return();
case -3:
xlog("L_DBG", "*** $rm *** Internal error has occured\n");
sl_reply_error();
avp_delete("$avp(s:source_site)");
return();
}
xlog("L_DBG", "*** $rm *** $ru ($rU) looks to be on line (has been registered within usrloc)\n");
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: *** MESSAGE *** Look for valid contact for sip:1446721212 at 192.168.4.44 (1446721212)
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: parsed uri: type=1 user=<1446721212>(10) passwd=<>(0) host=<192.168.4.44>(12) port=<>(0): 0 params=<>(0) headers=<>(0)
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: uri params: transport=<>, val=<>, proto=0
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: user-param=<>, val=<>
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: method=<>, val=<>
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: ttl=<>, val=<>
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: maddr=<>, val=<>
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: lr=<>
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: grep_sock_info - checking if host==us: 12==9 && [192.168.4.44] == [127.0.0.1]
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: grep_sock_info - checking if port 5060 matches port 5060
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: grep_sock_info - checking if host==us: 12==12 && [192.168.4.44] == [192.168.4.44]
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: grep_sock_info - checking if port 5060 matches port 5060
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: rewrite_uri: Rewriting Request-URI with 'sip:1446721212 at 192.168.5.55;LINEID=0fe75b47c6bc'
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: parsed uri: type=1 user=<1446721212>(10) passwd=<>(0) host=<192.168.5.55>(12) port=<>(0): 0 params=<LINEID=0fe75b47c6bc>(19) headers=<>(0)
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: uri params: transport=<>, val=<>, proto=0
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: user-param=<>, val=<>
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: method=<>, val=<>
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: ttl=<>, val=<>
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: maddr=<>, val=<>
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: lr=<>
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: xl_printf: final buffer length 133
Mar 14 14:35:54 lin-3 /usr/local/openser-1.2.0/sbin/openser[16099]: *** MESSAGE *** sip:1446721212 at 192.168.5.55;LINEID=0fe75b47c6bc (1446721212) looks to be on line (has been registered within usrloc)
Please pay your attention that 1446721212 is really in "off line" state and REGISTER with Expires: 0 header has been sent from 1446721212 user.
Described situation can be reproduced on openser v1.0.x and v1.2.0.
Please find attached file with detailed log and openser configuration script I used.
----------------------------------------------------------------------
>Comment By: Bogdan (bogdan_iancu)
Date: 2007-03-15 14:51
Message:
Logged In: YES
user_id=1275325
Originator: NO
Hi,
thanks for your troubleshooting - I seet that according to RFC3261 the
missing port is equivalent to 5060, but fixing this wil only complicate
thinks (imho) - probably the same problem appears when using the transaport
parameter (transport=udp versus no param). I found a bit buggy from the
client to use different contacts (even if echivalent from RFC point of
view) during same session.....
As the bug actually resides in a different place as orifinally tbought,
please open a new bug report for "contact matching in usrloc" and I will
close this one.
thanks and regards,
bogdan
----------------------------------------------------------------------
Comment By: Kovalevich Victor (vkc1974)
Date: 2007-03-15 14:24
Message:
Logged In: YES
user_id=490489
Originator: YES
Client application I use is based on SipX library v2.0. It construct
Contact header field for
- request #1 (Expires: 3600)
REGISTER sip:192.168.4.44 SIP/2.0
From:
"%56%69%63%74%6F%72%20%4B%6F%76%61%6C%65%76%69%63%68"<sip:1446721212 at 192.168.4.44>;tag=19c77107
To:
"%56%69%63%74%6F%72%20%4B%6F%76%61%6C%65%76%69%63%68"<sip:1446721212 at 192.168.4.44>
Call-Id: ecb028194d55f44897661b73666b7270
Cseq: 101 REGISTER
Contact:
"%56%69%63%74%6F%72%20%4B%6F%76%61%6C%65%76%69%63%68"<sip:1446721212 at 192.168.5.55;LINEID=0fe75b47c6bc>
Expires: 3600
Date: Thu, 15 Mar 2007 12:07:51 GMT
Max-Forwards: 70
User-Agent: Glooip 1.1.21.0 (WinNT)
Accept-Language:
Supported: replaces
Via: SIP/2.0/UDP 192.168.5.55;branch=z9hG4bK-e243b8fa0b52;rport
Content-Length: 0
- request #2 (Expires: 0)
REGISTER sip:192.168.4.44 SIP/2.0
From:
"%56%69%63%74%6F%72%20%4B%6F%76%61%6C%65%76%69%63%68"<sip:1446721212 at 192.168.4.44>;tag=19c77107
To:
"%56%69%63%74%6F%72%20%4B%6F%76%61%6C%65%76%69%63%68"<sip:1446721212 at 192.168.4.44>;tag=329cfeaa6ded039da25ff8cbb8668bd2.003e
Call-Id: ecb028194d55f44897661b73666b7270
Cseq: 102 REGISTER
Expires: 0
Date: Thu, 15 Mar 2007 12:07:56 GMT
Max-Forwards: 70
User-Agent: Glooip 1.1.21.0 (WinNT)
Accept-Language:
Supported: replaces
Via: SIP/2.0/UDP 192.168.5.55:5060;branch=z9hG4bK-85a580ea1819;rport
Contact: <sip:1446721212 at 192.168.5.55:5060>;LINEID=0fe75b47c6bc
Content-Length: 0
Pay your attention to the values of Contact header in both messages:
Contact:
"%56%69%63%74%6F%72%20%4B%6F%76%61%6C%65%76%69%63%68"<sip:1446721212 at 192.168.5.55;LINEID=0fe75b47c6bc>
Contact: <sip:1446721212 at 192.168.5.55:5060>;LINEID=0fe75b47c6bc
According to RFC3261 given values are equivalent. But OpenSER extracts a
substring between '<' and '>' symbols and considered it as a value
(additional parameters beyond '<' '>' are ignored).
So that update_contact() routine (module/registrar/save.c) cannot delete
appropriate entry from user location DB table.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1680615&group_id=139143
More information about the Devel
mailing list