[SR-Users] dispatcher and call transfer

[Charles Chance]

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-bounces at lists.sip-router.org
[mailto:sr-users-bounces at 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 <00asgaroth00 at 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 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/

-- 
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 at 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