3 May
2018
3 May
'18
10:14 a.m.
No, just have to learn to pick the right kinds of instances. I can't tell you what the
right ones are off the top of my head, unfortunately.
On May 3, 2018 10:02:10 AM EDT, Daniel Greenwald <dgreenwald(a)gmail.com> wrote:
So what's the solution? Don't run Kamailio in
AWS? Surely we are not
the
only ones doing that...
On Wed, May 2, 2018 at 5:37 PM, Alex Balashov
<abalashov(a)evaristesys.com>
wrote:
-- Alex
--
Sent via mobile, please forgive typos and brevity.
We have encountered similar in AWS.
Unfortunately, the answer has
turned
out to be "because AWS". Try using
instances more expressly marked
for
network throughput performance. But sometimes
things like this happen
anyway because AWS.
On May 2, 2018 3:49:28 PM EDT, Daniel Greenwald
<dgreenwald(a)gmail.com>
wrote:
>We are using kamailio 5.0 as an inbound dispatcher. Sometimes in
>testing we
>see it take over half a second to relay a 200 OK. The logs show the
new
>dialog being creating for the 200 OK within
.0001 seconds of
receiving
>the
>inbound 200 but it takes another .5 seconds for the relayed 200 to
>actually
>hit the wire. Here is a screenshot showing the timing of the
packets.
> >The
> >box is an EC2 m3.medium under almost zero load (1-2 calls).
> >
> >Is this normal? What should I be looking at?
> >
> >Screenshot below: 10.0.23.34 is the kamailio box. Carrier IP
> >obfuscated.
> >You can see the carrier resends the 200 OK because of the delay.
>
>
> -- Alex
>
> --
> Sent via mobile, please forgive typos and brevity.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>