<div dir="ltr"><font color="#3366ff"><font><font face="tahoma,sans-serif">Hi,<br><br>@Carsten<br>Dispatcher algorithm 0 based on call-id should do it in your case of re-invite within dialog with same call-id.<br><br>@Charles<br>
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.<br>
</font></font></font><div dir="ltr"><font color="#3366ff" face="tahoma, sans-serif"><br></font><div><font color="#3366ff" face="tahoma, sans-serif">Reda</font></div></div><br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 26, 2012 at 14:30, Charles Chance <span dir="ltr"><<a href="mailto:charles.chance@sipcentric.com" target="_blank">charles.chance@sipcentric.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Actually, this won't help for attended transfers where another call is<br>
initiated first then the two are joined together by REFER. In this case, the<br>
second INVITE must be routed to the same media server as the existing call<br>
for the transfer to work.<br>
<br>
What we do is store the dialogs in DB, then when a new call comes in, prior<br>
to doing ds_select_dst we query DB for existing call involving same user. If<br>
we find one, we simply replace destination host with that from the contact<br>
(to/from depending on direction of call).<br>
<br>
It may not be the most elegant way but it works for us :)<br>
<br>
Charles<br>
<div><div class="h5"><br>
<br>
-----Original Message-----<br>
From: <a href="mailto:sr-users-bounces@lists.sip-router.org">sr-users-bounces@lists.sip-router.org</a><br>
[mailto:<a href="mailto:sr-users-bounces@lists.sip-router.org">sr-users-bounces@lists.sip-router.org</a>] On Behalf Of Carsten Bock<br>
Sent: 26 April 2012 13:25<br>
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -<br>
UsersMailing List<br>
Subject: Re: [SR-Users] dispatcher and call transfer<br>
<br>
Hi,<br>
<br>
if you look at the docs of the dispatcher module, you'll find this:<br>
<br>
alg - the algorithm used to select the destination address. The<br>
parameter can be an integer or a variable holding an interger.<br>
- “0” - hash over callid<br>
(<a href="http://kamailio.org/docs/modules/devel/modules_k/dispatcher.html#id2498492" target="_blank">http://kamailio.org/docs/modules/devel/modules_k/dispatcher.html#id2498492</a>)<br>
<br>
But probably you should look into record/loose_route for your setup.<br>
Since REFER is normally an in-dialog request (belongs to another<br>
voice-session), it should take the same route as the initial INVITE.<br>
This is normally achieved by the record/loose-route mechanisms<br>
described in RFC3261.<br>
In the example config of Kamailio you find an configuration example (below).<br>
<br>
It is not a bug in the dispatcher module, it's how you use it.<br>
<br>
So long,<br>
Carsten<br>
<br>
455 # handle requests within SIP dialogs<br>
456 route(WITHINDLG);<br>
<br>
[...]<br>
<br>
473 # record routing for dialog forming requests (in case<br>
they are routed)<br>
474 # - remove preloaded route headers<br>
475 remove_hf("Route");<br>
476 if (is_method("INVITE|SUBSCRIBE"))<br>
477 record_route();<br>
<br>
and the relevent parts in the "WITHINDLG" route:<br>
<br>
566 # Handle requests within SIP dialogs<br>
567 route[WITHINDLG] {<br>
568 if (has_totag()) {<br>
569 # sequential request withing a dialog should<br>
570 # take the path determined by record-routing<br>
571 if (loose_route()) {<br>
[...]<br>
580 route(RELAY);<br>
581 } else {<br>
[...]<br>
587 if ( is_method("ACK") ) {<br>
588 if ( t_check_trans() ) {<br>
589 # no loose-route, but stateful<br>
ACK;<br>
590 # must be an ACK after a 487<br>
591 # or e.g. 404 from upstream<br>
server<br>
592 t_relay();<br>
593 exit;<br>
594 } else {<br>
595 # ACK without matching<br>
transaction ... ignore and discard<br>
596 exit;<br>
597 }<br>
598 }<br>
599 sl_send_reply("404","Not here");<br>
600 }<br>
601 exit;<br>
602 }<br>
603 }<br>
<br>
2012/4/26 Asgaroth <<a href="mailto:00asgaroth00@gmail.com">00asgaroth00@gmail.com</a>>:<br>
> Hi All,<br>
><br>
> Currently we are running kamailio in a loadbalanced fashion whereby calls<br>
> come in via the loadbalancers and distribute calls accross 2 media<br>
servers.<br>
> We have come accross and issue whereby call transfers may be distributed<br>
> accross two media servers and when the REFER message comes along to<br>
transfer<br>
> the call, in some cases (if we're lucky) the message arrives at the wrong<br>
> media server (transaction leg doesnt exist).<br>
><br>
> Some googling later and it appears that dispatcher doesnt play nice when<br>
it<br>
> comes to this scenario. Some suggestions popped up in my previous searches<br>
> saying that a potential work around is to use the dialog module to check<br>
if<br>
> a call is eastablished and then to send all calls to the same media server<br>
> based on the dialog already being established.<br>
><br>
> I'd appreciate some input from the guru's out there that have come accross<br>
> this same issue and, if possible, some suggestions on how to work around<br>
the<br>
> problem, does the dispatcher module have a hashing algorithm that can be<br>
> suited for this particular scenario?<br>
><br>
> Thanks in advance for any tips or sugestions.<br>
><br>
> _______________________________________________<br>
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
> <a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
><br>
<br>
<br>
<br>
--<br>
Carsten Bock<br>
CEO (Geschäftsführer)<br>
<br>
ng-voice GmbH<br>
Schomburgstr. 80<br>
D-22767 Hamburg / Germany<br>
<br>
<a href="http://www.ng-voice.com" target="_blank">http://www.ng-voice.com</a><br>
mailto:<a href="mailto:carsten@ng-voice.com">carsten@ng-voice.com</a><br>
<br>
Mobile <a href="tel:%2B49%20179%202021244" value="+491792021244">+49 179 2021244</a><br>
Office <a href="tel:%2B49%2040%2034927219" value="+494034927219">+49 40 34927219</a><br>
Fax <a href="tel:%2B49%2040%2034927220" value="+494034927220">+49 40 34927220</a><br>
<br>
Sitz der Gesellschaft: Hamburg<br>
Registergericht: Amtsgericht Hamburg, HRB 120189<br>
Geschäftsführer: Carsten Bock<br>
Ust-ID: DE279344284<br>
<br>
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:<br>
<a href="http://www.ng-voice.com/imprint/" target="_blank">http://www.ng-voice.com/imprint/</a><br>
<br>
--<br>
Meet ng-voice at LinuxTag 2012 in Berlin - May 23rd - 26th, 2012. Save the<br>
date!<br>
<br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br>
</div></div>-----<br>
No virus found in this message.<br>
Checked by AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a><br>
Version: 2012.0.1913 / Virus Database: 2411/4959 - Release Date: 04/25/12<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</div></div></blockquote></div><br></div></div>