26 Apr
2012
26 Apr
'12
2:25 p.m.
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 <00asgaroth00(a)gmail.com>om>:
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(a)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@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!