New subject: dispatcher and call transfer

26 Apr 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 &lt;charles.chance(a)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(a)lists.sip-router.org [mailto:
 sr-users-bounces(a)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(a)sipcentric.com&gt; 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(a)lists.sip-router.org
 [mailto:sr-users-bounces@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 &lt;00asgaroth00(a)gmail.com&gt;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 <%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(a)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(a)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(a)lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users