[SR-Users] Kamailio ​ds_ping_interval Performance

[Atul Thosar]

Thanks all for your responses.


I am new to Kamailio, so appreciate if some one can help me with sample
code where kamailio routes call to another FreeSWITCH server if 1st
FreeSWITCH server does not respond in some time, say 3 sec. Btw I have a
query on this approach. Consider a following scenario -

0. kamailio is configured w/ 2 FreeSWITCH servers in dispatcher and with
configuration where on not receiving response to INVITE in 3 sec, kamailio
will forward the call to another FreeSWITCH server.
1. kamailio receives INVITE and forwards INVITE to FreeSWITCH #1
2. FreeSWITCH #1 receives INVITE, but 100 trying response could not reach
to kamailio bec of network break, say for 4 sec.
3. So After 3 sec, since kamailio does not receive any response from
FreeSWITCH #1, it forwards INVITE to FreeSWITCH #2
4. FreeSWITCH #2 responds with 200 OK and kamailio receives it.
5. After 4 sec, when network recovers, FreeSWITCH #1 sends 200 OK to
kamailio. How kamailio would behave here? Will it drops the call w/
FreeSWITCH #1?


--
​Thanks,
Atul Thosar



On 7 April 2018 at 21:46, Julien Chavanton <jchavanton at gmail.com> wrote:

> Hi,
>
> I would set it to a low value to make sure you avoid sending calls a
> Freeswitch server facing problems, in the case of Freeswitch the same GW
> will also handle media, if it is having hardtime repliyng to SIP OPTIONS it
> will very likely have problem handling the media.
>
> It may also get worst during the call even stop responsding and loose
> transaction in progress or in dialog transactions later like session timers
> and BYEs.
>
> Off loading it may able help other calls already using it.
>
>
> You may push your strategy further thinking about :
>
> - The risk is that you run out of GW, could be handled when ds_select is
> returning nothing.
> - Another side effect, would be that you are sending more traffic to other
> GW, they must be able to handle the extra load.
>
> In kamailio 5 there is a new algorithm that behaves better when one GW is
> put out of service.
>
> “11” - use relative weight based load distribution. You have to set the
> attribute 'rweight' per each address in destination set. Active host usage
> probability is rweight/(SUM of all active host rweights in destination
> group).
>
> Regards
> Julien
>
> On Mon, Apr 2, 2018 at 6:06 PM, Atul Thosar <atulthosar at gmail.com> wrote:
>
>> Hi All,
>> I am using Kamailio
>> ​*​*
>> *v4.4.x* to load balanced traffic to FreeSWITCH servers. I have query
>> regarding ds_ping_interval and ds_probing_threshold. We have very high
>> traffic (around 200-400
>> ​ (CPS)​
>> calls per sec) hitting on Kamailio which then distribute it to 2-3
>> FreeSWITCH servers.
>> ​ ​
>> What is the optimal value should I set to ds_ping_interval and
>> ds_probing_threshold?
>>
>> If I set
>> ​​
>> ds_ping_interval=2 and
>> ​​
>> ds_probing_threshold=1 then in every 2 sec, I would come to know if my
>> ​​
>> FreeSWITCH server is down/up. But by setting such low values, I afraid
>> there would
>> ​be ​
>> lot of SIP traffic on network.
>> ​ If I set high (say
>> ​
>> ds_probing_threshold=5) then I may loose high number of calls (200 CPS, I
>> will loose 1000 calls) in case
>> ​
>> FreeSWITCH server is down. ​
>>
>>
>> As I said earlier we have very high traffic hitting on Kamailio, can't
>> kamailio use INVITE itself to probe FreeSWITCH server is down/up? In case
>> of low traffic can't it switch over to OPTION mechanism?
>>
>> --
>> ​Thanks in Advance​
>> ,
>> ​​
>> Atul
>> ​​
>> ​​
>> ​​
>>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180408/b1b03dee/attachment.html>