For a call invite from a phone to an load balanced asterisk server farm I can use ds_select_dst with hash over callid for the algorithm. What I don't understand is what happens for a server side invite. Say user A calls user B. The server will send and invite to user B's device. User B's device will reply and ds_select_dst won't have the call id hash so it will choose a random server, which might not be the server sending the invite. How do I mark these server side invites so the call hash is known by kamailio? Or am I thinking about this the wrong way?
Thanks, Ryan
On Wed, Aug 09, 2017 at 01:21:36PM -0400, Ryan Wagoner wrote:
How do I mark these server side invites so the call hash is known by kamailio? Or am I thinking about this the wrong way?
It is the latter, in dialog replies should be routed on headers only. In the "default" config these replies/reINVITES are handled in the WITHINDLG route, the dispatcher should only be called for new dialogs.
Thanks for the explanation! I finally got the dispatcher working in an active / passive Kamailio cluster in front of three FreePBX servers. I was using the Asipto Kamailio and Asterisk real time guide as a starting point so it had the WITHINDLG route. I ended up modifying the TOASTERISK route to call ds_select_dst and the FROMASTERSK route uses an htable for matching IPs off a mySQL view of the Kamailio dispatcher table. I also have some modifications to the REGFWD route. We'll see how performance is today as I did have to use a sqlops query to lookup the dispatcher set ID for TOASTERISK and REGFWD depending on the authentication ID. This setup is responsible for around 1000 extensions with 2000 devices for a high volume call center.
Ryan
On Thu, Aug 10, 2017 at 4:16 AM, Daniel Tryba d.tryba@pocos.nl wrote:
On Wed, Aug 09, 2017 at 01:21:36PM -0400, Ryan Wagoner wrote:
How do I mark these server side invites so the call hash is known by kamailio? Or am I thinking about this the wrong way?
It is the latter, in dialog replies should be routed on headers only. In the "default" config these replies/reINVITES are handled in the WITHINDLG route, the dispatcher should only be called for new dialogs.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Thu, Aug 10, 2017 at 08:51:24AM -0400, Ryan Wagoner wrote:
Thanks for the explanation! I finally got the dispatcher working in an active / passive Kamailio cluster in front of three FreePBX servers. I was using the Asipto Kamailio and Asterisk real time guide as a starting point so it had the WITHINDLG route. I ended up modifying the TOASTERISK route to call ds_select_dst and the FROMASTERSK route uses an htable for matching IPs off a mySQL view of the Kamailio dispatcher table.
Am I interpreting this as: you wanto check if a message is coming from a dispatcher? If yes, take a look at ds_is_from_list: https://kamailio.org/docs/modules/stable/modules/dispatcher.html#dispatcher....
I also have some modifications to the REGFWD route. We'll see how performance is today as I did have to use a sqlops query to lookup the dispatcher set ID for TOASTERISK and REGFWD depending on the authentication ID. This setup is responsible for around 1000 extensions with 2000 devices for a high volume call center.
Shouldn't be a problem.
On Thu, Aug 10, 2017 at 9:05 AM, Daniel Tryba d.tryba@pocos.nl wrote:
On Thu, Aug 10, 2017 at 08:51:24AM -0400, Ryan Wagoner wrote:
Thanks for the explanation! I finally got the dispatcher working in an active / passive Kamailio cluster in front of three FreePBX servers. I
was
using the Asipto Kamailio and Asterisk real time guide as a starting
point
so it had the WITHINDLG route. I ended up modifying the TOASTERISK route
to
call ds_select_dst and the FROMASTERSK route uses an htable for matching IPs off a mySQL view of the Kamailio dispatcher table.
Am I interpreting this as: you wanto check if a message is coming from a dispatcher? If yes, take a look at ds_is_from_list: https://kamailio.org/docs/modules/stable/modules/ dispatcher.html#dispatcher.f.ds_is_from_list
Exactly so the traffic from asterisk is trusted and isn't modified. I just swapped my while loop for that function and it's good to go. I can't believe I didn't see that earlier.
In my REGFWD route I have this chunk of code to lookup the dispatcher IP/port from the same hash table before calling uac_req_send(). The regserver column contains the dispatcher set id. Is there a way I can call ds_select and then access the IP / port variables directly?
#!if WITH_DISPATCHER sql_query("castdb", "select regserver from sipusers where name = '$au'","ra");
if($dbr(ra=>rows)>0) { $var(rip) = $sht(dispatcherHosts=>set::$dbr(ra=>[0,0])[0]); $var(rport) = $sht(dispatcherHosts=>port::$var(rip)); } else { return; }
sql_result_free("ra"); #!else $var(rip) = $sel(cfg_get.asterisk.bindip); $var(rport) = $sel(cfg_get.asterisk.bindport); #!endif
$uac_req(method)="REGISTER"; $uac_req(ruri)="sip:" + $var(rip) + ":" + $var(rport); $uac_req(furi)="sip:" + $au + "@" + $var(rip); $uac_req(turi)="sip:" + $au + "@" + $var(rip); $uac_req(hdrs)="Contact: <sip:" + $au + "@" + $sel(cfg_get.kamailio.bindip) + ":" + $sel(cfg_get.kamailio.bindport) + ">\r\n"; if($sel(contact.expires) != $null) $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + $sel(contact.expires) + "\r\n"; else $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + $hdr(Expires) + "\r\n"; uac_req_send();
Thanks, Ryan
On Thu, Aug 10, 2017 at 04:48:48PM -0400, Ryan Wagoner wrote:
In my REGFWD route I have this chunk of code to lookup the dispatcher IP/port from the same hash table before calling uac_req_send(). The regserver column contains the dispatcher set id. Is there a way I can call ds_select and then access the IP / port variables directly?
ds_* sets $du (and its parts $dd/$dp/?).
You can always add a bit of caching to avoid too many sql queries and improve the performances. Just use the htable module to store in memory the value associated with authid that you fetch from database.
Then you can llok first in htable, and if not found store in htable. You can set a lifetime for values in the htable, so they disappear, forcing a load from db.
Also, you can set/remove values from htable via rpc commands, if you need to do a change immediately.
Cheers, Daniel
On 10.08.17 14:51, Ryan Wagoner wrote:
Thanks for the explanation! I finally got the dispatcher working in an active / passive Kamailio cluster in front of three FreePBX servers. I was using the Asipto Kamailio and Asterisk real time guide as a starting point so it had the WITHINDLG route. I ended up modifying the TOASTERISK route to call ds_select_dst and the FROMASTERSK route uses an htable for matching IPs off a mySQL view of the Kamailio dispatcher table. I also have some modifications to the REGFWD route. We'll see how performance is today as I did have to use a sqlops query to lookup the dispatcher set ID for TOASTERISK and REGFWD depending on the authentication ID. This setup is responsible for around 1000 extensions with 2000 devices for a high volume call center.
Ryan
On Thu, Aug 10, 2017 at 4:16 AM, Daniel Tryba <d.tryba@pocos.nl mailto:d.tryba@pocos.nl> wrote:
On Wed, Aug 09, 2017 at 01:21:36PM -0400, Ryan Wagoner wrote: > How do I mark these server side invites so the call hash is known by > kamailio? Or am I thinking about this the wrong way? It is the latter, in dialog replies should be routed on headers only. In the "default" config these replies/reINVITES are handled in the WITHINDLG route, the dispatcher should only be called for new dialogs. _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel Tryba -
Daniel-Constantin Mierla -
Ryan Wagoner