[Devel] [ openser-Bugs-1680615 ] REGISTRAR & USRLOC: unable to unregister a user properly

SourceForge.net noreply at sourceforge.net
Wed May 9 17:29:09 CEST 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: Closed
>Resolution: Invalid
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-05-09 18:29

Message:
Logged In: YES 
user_id=1275325
Originator: NO

A new bug was opened for the real issue.

----------------------------------------------------------------------

Comment By: Kovalevich Victor (vkc1974)
Date: 2007-03-20 13:14

Message:
Logged In: YES 
user_id=490489
Originator: YES

So that save() function returns "Ok" state when really following error has
occured: no appropriate contact has been found to be deleted from
"location" DB, there are no warning/error messages in the log, 200 Ok reply
is sent to client site (it is not true as unregistaration has really
failed), furthermore invalid contact keeps to be in "location" DB.

----------------------------------------------------------------------

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