24 Oct
2010
24 Oct
'10
1:26 p.m.
in some of my tests i get the following udp send related errors, when
request is t_relayed:
Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: INFO: Routing initial
INVITE <sip:+35892223333@test.fi> to
<sip:+35892223333@193.166.3.2;transport=udp>
Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: ERROR: <core> [udp_server.c:566]:
ERROR: udp_send: sendto(sock,0xb2d1f1e8,1190,0,193.166.3.2:5060,16): Invalid argument(22)
Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: : <core> [udp_server.c:571]:
CRITICAL: invalid sendtoparameters one possible reason is the server is bound to localhost
and attempts to send to the net
Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: ERROR: tm [../../forward.h:148]:
msg_send: ERROR: udp_send failed
Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: ERROR: tm [t_fwd.c:1244]: ERROR:
t_send_branch: sending request on branch 0 failed
$du is set to sip:+35892223333@193.166.3.2;transport=udp and the proxy
is listening on many sockets, both 127.0.0.1 and external ip address.
any idea what might cause the errors?
-- juha
24 Oct
24 Oct
2:06 p.m.
Juha Heinanen writes:
$du is set to
sip:+35892223333@193.166.3.2;transport=udp and the proxy
is listening on many sockets, both 127.0.0.1 and external ip address.
any idea what might cause the errors?
looks like that if request comes in via a 127.0.0.1 socket and goes out
to an external ip address, then sr is not smart enough to use its socket
with external ip address. the errors namely went away when i called
force_send_socket() with external ip address argument before t_relaying
the request.
-- juha
6:30 p.m.
On 10/24/10 11:06 AM, Juha Heinanen wrote:
Juha Heinanen writes:
iirc, it was always the same from the time of ser 0.8. If you don;t
change the protocol, the core tries to send from the same socket it
received. You have to use mhomed=1 in order to have detection of
outgoing interface. 3.x has significant improvements for mhomed=1 done
by Marius.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
$du is set to
sip:+35892223333@193.166.3.2;transport=udp and the proxy
is listening on many sockets, both 127.0.0.1 and external ip address.
any idea what might cause the errors?
looks like that if request comes in via a
127.0.0.1 socket and goes out
to an external ip address, then sr is not smart enough to use its socket
with external ip address. the errors namely went away when i called
force_send_socket() with external ip address argument before t_relaying
the request.
6:51 p.m.
Daniel-Constantin Mierla writes:
iirc, it was always the same from the time of ser 0.8.
If you don;t
change the protocol, the core tries to send from the same socket it
received. You have to use mhomed=1 in order to have detection of
outgoing interface. 3.x has significant improvements for mhomed=1 done
by Marius.
yes, i just had forgotten to call force_send_socket() in one particular
case and therefore got the send errors.
i have not used mhomed=1 because of the performance warning on the wiki
page. it that warning still valid?
-- juha
2 Nov
2 Nov
10:42 p.m.
On Sunday 24 October 2010, Juha Heinanen wrote:
[..]
yes, i just had forgotten to call force_send_socket() in one particular
case and therefore got the send errors.
i have not used mhomed=1 because of the performance warning on the wiki
page. it that warning still valid?
Hello Marius,
you did some tests in the past after your improvement(s). Do you think the
performance warning is still valid? Otherwise we should remove it.
Thanks and regards,
Henning
3 Nov
3 Nov
1:47 p.m.
On 11/02/2010 07:42 PM, Henning Westerholt wrote:
On Sunday 24 October 2010, Juha Heinanen wrote:
Hello all,
Surely the performance has increased a lot(I don't recall the numbers
exactly but it was a big improvement). Before deploying mhomed in
production I strongly recommend testing the mhomed=1 parameter in a
environment closest to your network setup for at least a couple of days
before rolling into production.
Marius
[..]
yes, i just had forgotten to call force_send_socket() in one particular
case and therefore got the send errors.
i have not used mhomed=1 because of the performance warning on the wiki
page. it that warning still valid?
Hello Marius,
you did some tests in the past after your improvement(s). Do you think the
performance warning is still valid? Otherwise we should remove it.
Thanks and regards,
Henning
2:01 p.m.
On 11/03/2010 10:47 AM, marius zbihlei wrote:
On 11/02/2010 07:42 PM, Henning Westerholt wrote:
Replying to myself,
I found the numbers I worked on last year. With a rate of 5000 calls/s a
K proxy with the original mhomed implementation had aboud 75-80% CPU
load. With the newest patched mhomed implementation, the load decrease
to about 65%. With 6000 calls/s without the patch the load went up to
100% and a lot of retransmits were generated(thus the load increased via
a avalanche effect), but with the patch the load was about 85-90% so
fewer retransmits were generated. I don't recall the exact cfg, and your
results may very accordingly depending on setup/HW (for example I used a
Quad Core Xeon with 4 GB RAM and a Gigabit Ethernet running a stable 2.6
kernel and Kamailio 1.5).
I must stress the fact that you must first test mhomed before deploying.
I have heard reports (not yet confirmed) that for certain
implementations it behaves badly. I haven't yet managed to
confirm/infirm these reports but I am currently looking into it so you
wait 2-3 days I can get back to you with some findings. When I have
tested mhomed everything went OK.
Marius
On Sunday 24 October 2010, Juha Heinanen wrote:
Hello all,
Surely the performance has increased a lot(I don't recall the numbers
exactly but it was a big improvement). [..]
yes, i just had forgotten to call force_send_socket() in one particular
case and therefore got the send errors.
i have not used mhomed=1 because of the performance warning on the wiki
page. it that warning still valid?
Hello Marius,
you did some tests in the past after your improvement(s). Do you think the
performance warning is still valid? Otherwise we should remove it.
Thanks and regards,
Henning
Before deploying mhomed in
production I strongly recommend testing the mhomed=1 parameter in a
environment closest to your network setup for at least a couple of days
before rolling into production.
Marius
_______________________________________________
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
2:44 p.m.
marius zbihlei writes:
I must stress the fact that you must first test mhomed
before deploying.
I have heard reports (not yet confirmed) that for certain
implementations it behaves badly. I haven't yet managed to
confirm/infirm these reports but I am currently looking into it so you
wait 2-3 days I can get back to you with some findings. When I have
tested mhomed everything went OK.
marius,
thanks for the info. i think i'll stay on the safe side and keep the
small number of force_send_socket calls in my config, which allow me to
leave mhomed feature off.
-=- juha
4 Nov
4 Nov
12:28 p.m.
On Nov 02, 2010 at 18:42, Henning Westerholt <henning.westerholt(a)1und1.de> wrote:
On Sunday 24 October 2010, Juha Heinanen wrote:
While the performance improved a lot (fewer syscalls), it's
still slower then no mhomed (it still does 2 extra syscalls per send),
so I would leave the warning.
We could improve it further, either caching already tried destinations,
or getting a copy of the routing table and using it directly (w/o having
to do syscalls any more).
However I don't think anybody complained loudly about it so far (even
with mhomed on it still can do thousands of calls per seconds), so it
is quite low priority.
Andrei
[..]
yes, i just had forgotten to call force_send_socket() in one particular
case and therefore got the send errors.
i have not used mhomed=1 because of the performance warning on the wiki
page. it that warning still valid?
Hello Marius,
you did some tests in the past after your improvement(s). Do you think the
performance warning is still valid? Otherwise we should remove it.
4931
days inactive
4942
days old
8 comments
5 participants
participants (5)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt -
Juha Heinanen -
marius zbihlei