[SR-Users] dispatcher and call transfer
Reda Aouad
reda.aouad at gmail.com
Thu Apr 26 16:14:38 CEST 2012
Asterisk is not really a media relay. Asterisk establishes 2 legs for each
call, and I'm not sure what happens in this case.
An improvement you can make is to use a hash table (in-memory) to store the
information you need (call-id, from, to) then lookup in
the htable for existing calls for same users. That should relieve your
database from a query on every invite and increase performance if you have
a large number of calls.
Reda
On Thu, Apr 26, 2012 at 15:52, Charles Chance <charles.chance at sipcentric.com
> wrote:
> ** ** ** **
>
> Hi Reda,****
>
> ** **
>
> Sorry, I should have been more specific – I am referring to instances
> where the media server is for example Asterisk. If first call goes through
> Asterisk 1, second call goes through Asterisk 2, when Asterisk 2 receives
> the REFER it does not know of initial call on Asterisk 1. The only way we
> have found for it to work is to ensure the second call is dispatched to the
> same Asterisk box as the first.****
>
> ** **
>
> I would be pleased to hear of an alternative method.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Charles****
> ------------------------------
>
> *From:* sr-users-bounces at lists.sip-router.org [mailto:
> sr-users-bounces at lists.sip-router.org] *On Behalf Of *Reda Aouad
> *Sent:* 26 April 2012 14:34
>
> *To:* **SIP Router - Kamailio** (OpenSER) and SIP Express Router (SER) -
> UsersMailing List
> *Subject:* Re: [SR-Users] dispatcher and call transfer
> ****
>
> ** **
>
> 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 <%2B49%20179%202021244>
> Office +49 40 34927219 <%2B49%2040%2034927219>
> 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****
>
> ** **
> ------------------------------
>
> 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/d38a70d0/attachment-0001.htm>
More information about the sr-users
mailing list