Hi, @Carsten Dispatcher algorithm 0 based on call-id should do it in your case of re-invite within dialog with same call-id.
@Charles In the case of attended transfers, shouldn't both media servers be relaying media between them? I didn't understand why your are obliged to dispatch to the same media server since they are 2 different calls with different call-ids. Reda On Thu, Apr 26, 2012 at 14:30, Charles Chance <charles.cha...@sipcentric.com > wrote: > Hi, > > Actually, this won't help for attended transfers where another call is > initiated first then the two are joined together by REFER. In this case, > the > second INVITE must be routed to the same media server as the existing call > for the transfer to work. > > What we do is store the dialogs in DB, then when a new call comes in, prior > to doing ds_select_dst we query DB for existing call involving same user. > If > we find one, we simply replace destination host with that from the contact > (to/from depending on direction of call). > > It may not be the most elegant way but it works for us :) > > Charles > > > -----Original Message----- > From: sr-users-boun...@lists.sip-router.org > [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Carsten Bock > Sent: 26 April 2012 13:25 > To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > UsersMailing List > Subject: Re: [SR-Users] dispatcher and call transfer > > 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 > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1913 / Virus Database: 2411/4959 - Release Date: 04/25/12 > > > _______________________________________________ > 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 >
_______________________________________________ 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
