[SR-Users] Dispatcher alg:7 not working accordingly

SamyGo govoiper at gmail.com
Tue Jun 12 12:01:31 CEST 2012


Thanks Sir,
Doing a static or even a run-time mapping of same UID calls to destination
server is what I thought about this type of case almost an year ago.

What I am thinking is : create a table for UID/Destination Mapping; for a
unique UID see if there is any destination in that table. If it exists just
jump to that server directly. If no UID/destination entry is found for that
UID then invoke Dispatcher; select destination, make call to it, and store
this in UID/destination map table !!

Let me know if there could be any improvement in this.

Thanks
Best Regards,
Sammy G.

On Tue, Jun 12, 2012 at 2:43 PM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:

>  Hello,
>
> if you are using integer UID, I would suggest you use modulo operation to
> select the destination address -- this will require config operations only.
>
> Another option you can map an UID to a dispatcher set id (e.g., via mtree
> or htable) and then you can do the alg 8.
>
> Cheers,
> Daniel
>
>
> On 6/7/12 1:37 PM, SamyGo wrote:
>
> Hi again,
> yes my scenario is quiet simple. I've  lots of users  and groups of those
> users are defined by UIDs, one UID means 70 users of one client whereas
> other UID could've 3 users of another client.
>  So what I am trying to implement here is that calls from one same UID are
> always routed to exactly one same destination server. That'll help in
> issues like call-parking, call-pickup, conference calls etc.
>
>  I hope I've explained the scenario in simpler terms here.
>
>  Regards,
> Sammy Go.
>
>
> On Thu, Jun 7, 2012 at 4:20 PM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>>  Hello,
>>
>> that hash function is intended for hashing alpha-numeric usernames and
>> has a fair distribution for such cases.
>>
>> I don't think is good for hashing numbers, at the end of a day, a number
>> is already like a hash code. You can use in the config file modulo
>> operation to select a particular destination based on a number.
>>
>> Maybe if you explain what is your target to implement, we can provide the
>> right hints to do it.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 6/6/12 6:09 PM, SamyGo wrote:
>>
>> Sorry for late reply: this wasn't very helpful. I think Hashing algo code
>> needs to get bit smarter. If there is any possibility can you please let me
>> know. !
>>
>>
>> On Mon, Jun 4, 2012 at 3:33 PM, Daniel-Constantin Mierla <
>> miconda at gmail.com> wrote:
>>
>>> To make the life easier to spot the hash code in such case, I just
>>> committed a small patch to print it for alg 7:
>>>
>>>
>>> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=83a558fbad700198a8667ef01f756269d7e2c310
>>>
>>> Should be easy to backport if other version is used.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 6/4/12 12:23 PM, Carsten Bock wrote:
>>>
>>>> It's hard to say, most likely not. You find the used hash-function here:
>>>>
>>>>  841 unsigned int ds_get_hash(str *x, str *y)
>>>>
>>>> http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob;f=modules_k/dispatcher/dispatch.c;h=ae0c51b122d34e29b3474957a64b24ff492cfcd5;hb=HEAD
>>>>
>>>> It was originally implemented to distribute usernames to servers,
>>>> which worked fine.
>>>>
>>>> Carsten
>>>>
>>>> 2012/6/4 SamyGo <govoiper at gmail.com>:
>>>>
>>>>> Thanks Sir,
>>>>>
>>>>> Thats what I expected. Do you think this will change if I use only two
>>>>> values with huge difference in each other, lets say {26000,29000} ?
>>>>>
>>>>> Regards,
>>>>> Sammy
>>>>>
>>>>> On Mon, Jun 4, 2012 at 3:05 PM, Carsten Bock <carsten at ng-voice.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> this functionality uses a generic "hash" function to generate an
>>>>>> Integer-Value of the PVAR and then reduces this to the number hosts in
>>>>>> your destination set.
>>>>>> If you have only using two different values of the PVAR and only two
>>>>>> hosts in the dispatcher list, it can likely happen, that the same host
>>>>>> is choosen. You should try a wider range of values for your PVAR...
>>>>>> (e.g. try 1000 different values), then you should see a distribution.
>>>>>>
>>>>>> Carsten
>>>>>>
>>>>>> 2012/6/4 SamyGo <govoiper at gmail.com>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> No, nothing at all. I haven't went too deep into debug logs but no
>>>>>>> internal
>>>>>>> error was appearing. Everything was as calm as ever and I only get
>>>>>>> one
>>>>>>> destination uri.
>>>>>>>
>>>>>>> So maybe what I'm getting from your email is that , for this to work
>>>>>>> the
>>>>>>> way
>>>>>>> I expect is to have more unique and random values in my hash_pvar to
>>>>>>> get
>>>>>>> the
>>>>>>> required functionality.
>>>>>>>
>>>>>>> Thanks once again,
>>>>>>> BR
>>>>>>> SG
>>>>>>>
>>>>>>> On Mon, Jun 4, 2012 at 11:52 AM, Daniel-Constantin Mierla
>>>>>>> <miconda at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> do you get any errors in the log?
>>>>>>>>
>>>>>>>> Be aware that hash functions may return same code for different
>>>>>>>> input
>>>>>>>> values. A hash function is guaranteed to return same code for same
>>>>>>>> input
>>>>>>>> value, but there can be collisions of codes for different values.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Daniel
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/3/12 3:41 PM, SamyGo wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I'm having trouble using algorithm 7 in dispatcher module. Here is
>>>>>>>> my
>>>>>>>> kamailio version. The problem is that despite multiple dispatcher
>>>>>>>> entries
>>>>>>>> corresponding to one set all calls go only to only one destination.
>>>>>>>>
>>>>>>>>
>>>>>>>> [root at control1 ~]# kamailio -V
>>>>>>>> version: kamailio 3.2.3 (x86_64/linux) 59f87e
>>>>>>>> flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
>>>>>>>> USE_RAW_SOCKS,
>>>>>>>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
>>>>>>>> PKG_MALLOC,
>>>>>>>> DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
>>>>>>>> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
>>>>>>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN
>>>>>>>> 16,
>>>>>>>> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
>>>>>>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>>>>>>> id: 59f87e
>>>>>>>> compiled on 18:04:08 Apr 19 2012 with gcc 4.1.2
>>>>>>>> [root at control1 ~]#
>>>>>>>>
>>>>>>>> Here is the dipacther module params.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> # ------- Load-balancer params ------
>>>>>>>> modparam("dispatcher", "db_url", DBURL)
>>>>>>>> modparam("dispatcher", "table_name", "dispatcher")
>>>>>>>> modparam("dispatcher", "setid_col", "setid")
>>>>>>>> modparam("dispatcher", "destination_col", "destination")
>>>>>>>> modparam("dispatcher", "force_dst", 1)
>>>>>>>> modparam("dispatcher", "flags", 3)
>>>>>>>> modparam("dispatcher", "dst_avp", "$avp(i:271)")
>>>>>>>> modparam("dispatcher", "cnt_avp", "$avp(i:273)")
>>>>>>>> modparam("dispatcher", "ds_ping_from", "sip:proxy at 109.XXX.2XX.XX")
>>>>>>>> modparam("dispatcher", "ds_ping_interval",15)
>>>>>>>> modparam("dispatcher", "ds_probing_mode", 1)
>>>>>>>> modparam("dispatcher", "ds_ping_reply_codes",
>>>>>>>> "class=2;code=403;code=404;code=484;class=3")
>>>>>>>> modparam("dispatcher", "hash_pvar", "$avp(i:274)")
>>>>>>>> modparam("dispatcher", "ds_hash_size", 9)
>>>>>>>> modparam("dispatcher", "ds_hash_initexpire", 60)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Below is the function call based on avp(i:274)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> avp_db_query("select uid from uid_did_map where accountcode =
>>>>>>>> '$fU'","$avp(i:274)");
>>>>>>>> xlog("L_INFO","$rm from $fu (IP:$si:$sp) ---------
>>>>>>>> UID:'$avp(i:274)-----------'\n");
>>>>>>>>         ds_load_update();
>>>>>>>>         if(!ds_select_dst("1","7")) {
>>>>>>>>                         sl_send_reply("500", "No destination
>>>>>>>> available");
>>>>>>>>                         xlog("route[MAIN] : $rm : No destinations
>>>>>>>> available for $rd");
>>>>>>>>                         exit;
>>>>>>>>         }
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm getting two different values for avp(i:274) {26,29} but the
>>>>>>>> destination are not hashed on its base.
>>>>>>>>
>>>>>>>> Please help.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Sammy G.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>>>>>> list
>>>>>>>> sr-users at lists.sip-router.org
>>>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Daniel-Constantin Mierla - http://www.asipto.com
>>>>>>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>>>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
>>>>>>>> http://asipto.com/u/katu
>>>>>>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
>>>>>>>> http://asipto.com/u/kpw
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>>>>> list
>>>>>>> sr-users at lists.sip-router.org
>>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carsten Bock
>>>>>> CEO (Geschäftsführer)
>>>>>>
>>>>>> ng-voice GmbH
>>>>>> Schomburgstr. 80
>>>>>> D-22767 Hamburg / Germany
>>>>>>
>>>>>> http://www.ng-voice.com
>>>>>> mailto:carsten at ng-voice.com
>>>>>>
>>>>>> Mobile +49 179 2021244
>>>>>> Office +49 40 34927219
>>>>>> Fax +49 40 34927220
>>>>>>
>>>>>> Sitz der Gesellschaft: Hamburg
>>>>>> Registergericht: Amtsgericht Hamburg, HRB 120189
>>>>>> Geschäftsführer: Carsten Bock
>>>>>> Ust-ID: DE279344284
>>>>>>
>>>>>> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
>>>>>> http://www.ng-voice.com/imprint/
>>>>>>
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>>>> list
>>>>>> sr-users at lists.sip-router.org
>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>>> sr-users at lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.com
>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
>>> http://asipto.com/u/katu
>>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
>>> http://asipto.com/u/kpw
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
>> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>>
>>
>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120612/61ec22ae/attachment-0001.htm>


More information about the sr-users mailing list