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: [email protected] > [mailto:[email protected]] 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: [email protected] >> [mailto:[email protected]] 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:[email protected] Q=0 >>> Expires:: 5051 >>> Callid:: [email protected] >>> 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:[email protected] Q=1 >>> Expires:: 6782 >>> Callid:: [email protected] >>> 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:[email protected]"; >>> 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 >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> >> >> > > > -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 20 - 24 September 2010, Frankfurt, Germany www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
