[OpenSIPS-Users] Registrar's lookup() function not returning contact with greatest q-value

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed Aug 11 20:10:21 CEST 2010


Hi Pauba,

I'm glad you found out where the problem was.

Regards,
Bogdan

Pauba, Kevin L wrote:
> I wanted to report that I do believe it was my custom module that was affecting the ordering of the contacts and _not_ the standard modules.
>
> I discovered that the contacts are stored in an AVL tree and I was updating the nodes of the tree without "rebalancing" them based on the q-value.  When I changed the code in my custom module to use a module function built specifically for updating the contact information, the lookup() function works as expected.
>
> Thanks go to Bogdan for pointing me in the right direction.
>
>
>
> -----Original Message-----
> From: Pauba, Kevin L 
> Sent: Thursday, August 05, 2010 8:49 AM
> To: OpenSIPS users mailling list
> Subject: RE: [OpenSIPS-Users] Registrar's lookup() function not returning contact with greatest q-value
>
> I don't modify any of the default settings for the usrloc module.
>
> I'll double check my configuration and "heartbeat" module to make sure the q order will be maintained.  There might be something I'm doing to the order when I update the q value (when the responses to the OPTION (heartbeats) are processed).
>
> Thanks for the direction, Bogdan.  I'll report back soon.
>
> L8r
>
> -----Original Message-----
> From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
> Sent: Wednesday, August 04, 2010 5:04 PM
> To: OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] Registrar's lookup() function not returning contact with greatest q-value
>
> Pauba,
>
> Strange...especially that the UL SHOW also shows the wrong order....Do 
> you have the "desc_time_order" param set in USRLOC ?
>
> Regards,
> Bogdan
>
>
> Pauba, Kevin L wrote:
>   
>> Bogdan,
>>
>> I did provide the "b" flag to the lookup() function (see original message below) but it replaced the RURI with the contact with Q=0, not the one with Q=1 as I expected.
>>
>> The only registrar module parameter that I've changed from the default is this:
>>
>> modparam("registrar", "min_expires", 0)                 # turn off checking for minimum expiration time
>>
>>
>> Also, the contacts are saved in the memory cache not in a DB table (using save("location", "m") ).  Might that have an effect on the order in which they're retrieved?
>>
>>
>> Thanks!
>>
>>  
>> -----Original Message-----
>> From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
>> Sent: Wednesday, August 04, 2010 12:11 PM
>> To: OpenSIPS users mailling list
>> Subject: Re: [OpenSIPS-Users] Registrar's lookup() function not returning contact with greatest q-value
>>
>> Hi Pauba,
>>
>> First if you want to get only one contact (even if multiple registered), 
>> see the "b" flag of the lookup() function:     
>>        
>> http://www.opensips.org/html/docs/modules/1.6.x/registrar.html#id271036
>>
>> Also if more than one contact is returned, they are ordered of their 
>> value (highest to lowest).
>>
>> Regards,
>> Bogdan
>>
>> Pauba, Kevin L wrote:
>>   
>>     
>>> Hi,
>>>
>>> According to the registrar documentation module, "... the RURI will be overwritten with the highest-q rated contact ..." when the lookup() function is called.  My testing shows that the first matching contact is used.
>>>
>>> I'm running OpenSIPS V1.6.2.  I should mention that I've written a "heartbeat" module that pings the registered contacts periodically and accepts a "load" value in the response that is used to calculate the q-value.  A few bits in the Cflags are used to keep track of those that respond back and I've modified the show command to report the meaning of the flags.
>>>
>>> Here's the snippet from the output of the "opensipsctl ul show":
>>>
>>>         AOR:: hmp
>>>                 Contact:: sip:sip at 10.27.193.121 Q=0
>>>                         Expires:: 5051
>>>                         Callid:: 1 at 10.27.193.121
>>>                         Cseq:: 78
>>>                         User-agent:: oSIP/wicsip-2.11.MR3519
>>>                         State:: CS_NEW
>>>                         Flags:: 1
>>>                         Cflag:: 34 (hb enabled, 0 unanswered)
>>>                         Socket:: udp:10.27.193.119:5060
>>>                         Methods:: 4294967295
>>>                 Contact:: sip:sip at 10.27.194.54 Q=1
>>>                         Expires:: 6782
>>>                         Callid:: 2 at 10.27.194.54
>>>                         Cseq:: 6
>>>                         User-agent:: oSIP/wicsip-3.4.13
>>>                         State:: CS_NEW
>>>                         Flags:: 1
>>>                         Cflag:: 34 (hb enabled, 0 unanswered)
>>>                         Socket:: udp:10.27.193.119:5060
>>>                         Methods:: 4294967295
>>>
>>> ... and here's a snippet of the openser.cfg file that is related:
>>>
>>>                 $var(aor) = "sip:hmp at wic.west.com";
>>>                 lookup("location","b","$var(aor)");
>>>                 xlog("L_DBG", "sending to hmp: $mb, $ru, $rs\n");
>>>                 switch ($retcode) {
>>>                 case -1:        # no contact
>>>                         xlog("L_ERR", "01000001 $pp Forwarding to HMP failed -- no registered contact. r-uri: $ru, callid: $ci, p-charging-vector: $(hdr(P-Charging-Vector)), contact: $ct\n");
>>>                         sl_send_reply("404", "Not Found");
>>>                         exit;
>>>                 case -3:        # internal error
>>>                         xlog("L_ERR", "01000001 $pp Forwarding to HMP failed. r-uri: $ru, callid: $ci, p-charging-vector: $(hdr(P-Charging-Vector)), contact: $ct\n");
>>>                         sl_send_reply("404", "Not Found");
>>>                         exit;
>>>                 case -2:        # method not supported
>>>                         xlog("L_ERR", "01000001 $pp Forwarding to HMP failed. r-uri: $ru, callid: $ci, p-charging-vector: $(hdr(P-Charging-Vector)), contact: $ct\n");
>>>                         sl_send_reply("405", "Not Found");
>>>                         exit;
>>>                 }
>>>                 if (! t_relay() ) {
>>>                         sl_reply_error();
>>>                 }
>>>                 exit;
>>>
>>> A tcpdump has verified that the first contact listed is the one selected by the lookup() function even though the q-value of that contact is less than the second contact in the list.
>>>
>>> I'm not interested in parallel forking but, instead, want to forward requests to the least-loaded endpoint.  Am I doing something wrong?
>>>
>>> Thanks!
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>   
>>>     
>>>       
>>   
>>     
>
>
>   


-- 
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
20 - 24 September 2010, Frankfurt, Germany
www.voice-system.ro




More information about the Users mailing list