Hi, if you look at the docs of the dispatcher module, you'll find this:
alg - the algorithm used to select the destination address. The parameter can be an integer or a variable holding an interger. - “0” - hash over callid (http://kamailio.org/docs/modules/devel/modules_k/dispatcher.html#id2498492) But probably you should look into record/loose_route for your setup. Since REFER is normally an in-dialog request (belongs to another voice-session), it should take the same route as the initial INVITE. This is normally achieved by the record/loose-route mechanisms described in RFC3261. In the example config of Kamailio you find an configuration example (below). It is not a bug in the dispatcher module, it's how you use it. So long, Carsten 455 # handle requests within SIP dialogs 456 route(WITHINDLG); [...] 473 # record routing for dialog forming requests (in case they are routed) 474 # - remove preloaded route headers 475 remove_hf("Route"); 476 if (is_method("INVITE|SUBSCRIBE")) 477 record_route(); and the relevent parts in the "WITHINDLG" route: 566 # Handle requests within SIP dialogs 567 route[WITHINDLG] { 568 if (has_totag()) { 569 # sequential request withing a dialog should 570 # take the path determined by record-routing 571 if (loose_route()) { [...] 580 route(RELAY); 581 } else { [...] 587 if ( is_method("ACK") ) { 588 if ( t_check_trans() ) { 589 # no loose-route, but stateful ACK; 590 # must be an ACK after a 487 591 # or e.g. 404 from upstream server 592 t_relay(); 593 exit; 594 } else { 595 # ACK without matching transaction ... ignore and discard 596 exit; 597 } 598 } 599 sl_send_reply("404","Not here"); 600 } 601 exit; 602 } 603 } 2012/4/26 Asgaroth <00asgarot...@gmail.com>: > Hi All, > > Currently we are running kamailio in a loadbalanced fashion whereby calls > come in via the loadbalancers and distribute calls accross 2 media servers. > We have come accross and issue whereby call transfers may be distributed > accross two media servers and when the REFER message comes along to transfer > the call, in some cases (if we're lucky) the message arrives at the wrong > media server (transaction leg doesnt exist). > > Some googling later and it appears that dispatcher doesnt play nice when it > comes to this scenario. Some suggestions popped up in my previous searches > saying that a potential work around is to use the dialog module to check if > a call is eastablished and then to send all calls to the same media server > based on the dialog already being established. > > I'd appreciate some input from the guru's out there that have come accross > this same issue and, if possible, some suggestions on how to work around the > problem, does the dispatcher module have a hashing algorithm that can be > suited for this particular scenario? > > Thanks in advance for any tips or sugestions. > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@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:cars...@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/ -- Meet ng-voice at LinuxTag 2012 in Berlin - May 23rd - 26th, 2012. Save the date! _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
