27 Apr
2012
27 Apr
'12
1:44 p.m.
Thanks all for the suggestions.
@Charles
Yes that is correct, that is the scenario that is occurring, we are
using asterisk, when a call is initiated via asterisk 1, the second call
then routes through to asterisk 2, asterisk 1 then gets the REFER but
doesn't know about the 2nd call.
@Reda
I like this option of using the hash table (I'd like to exclude a
database lookup for each initial invite), however, would I be forced to
use a database in the case of 2 loadbalancers, surely some shared state
would need to exist between the loadbalancers to make this decision on
where to route the call if it already exists. I suspect the hashtable
suggestion may work perfectly in a single loadbalancer scenario, unless
I'm missing something. For example, the initialy call may go via
loadbalancer 1 however the second call may go through loadbalancer 2,
that way loadbalancer 2 may not know of an existing call already been setup.
In keeping with the hashtable train of thought, is it really neccessary
to keep a reference to the callid, as the second call in the transfer
scenario described by Charles, the callid of the second call is
different to the original call.
Just as an FYI, I am currently using dispatcher algorithm 0 which is a
hash over callid.
Thanks again all for the suggestions/tips
On 26/04/12 16:12, Charles Chance wrote:
Yes, I realise Asterisk is not a media relay, but I don't think the OP
is using a pure media relay, otherwise the REFER message would not be
sent to it, would it?
Thank you for the hash table suggestion by the way.
Charles
------------------------------------------------------------------------
*From:*sr-users-bounces@lists.sip-router.org
[mailto:sr-users-bounces@lists.sip-router.org] *On Behalf Of *Reda Aouad
*Sent:* 26 April 2012 15:15
*To:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
UsersMailing List
*Subject:* Re: [SR-Users] dispatcher and call transfer
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(a)sipcentric.com <mailto:charles.chance@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@lists.sip-router.org
<mailto:sr-users-bounces@lists.sip-router.org>
[mailto:sr-users-bounces@lists.sip-router.org
<mailto:sr-users-bounces@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 <mailto:charles.chance@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(a)lists.sip-router.org
<mailto:sr-users-bounces@lists.sip-router.org>
[mailto:sr-users-bounces@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 <00asgaroth00(a)gmail.com
<mailto:00asgaroth00@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(a)lists.sip-router.org <mailto:sr-users@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 <mailto:carsten@ng-voice.com>
Mobile +49 179 2021244 <tel:%2B49%20179%202021244>
Office +49 40 34927219 <tel:%2B49%2040%2034927219>
Fax +49 40 34927220 <tel:%2B49%2040%2034927220>
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 <mailto:sr-users@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 <http://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 <mailto:sr-users@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 <http://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 <mailto:sr-users@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 <http://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