[SR-Users] dispatcher and call transfer
Reda Aouad
reda.aouad at gmail.com
Thu Apr 26 15:34:20 CEST 2012
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.chance at 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-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
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120426/7458f788/attachment-0001.htm>
More information about the sr-users
mailing list