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
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
On 10/24/10 11:06 AM, Juha Heinanen wrote:
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.
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 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
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
On 11/02/2010 07:42 PM, Henning Westerholt wrote:
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
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
On 11/03/2010 10:47 AM, marius zbihlei wrote:
On 11/02/2010 07:42 PM, Henning Westerholt wrote:
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
Hello all,
Surely the performance has increased a lot(I don't recall the numbers exactly but it was a big improvement).
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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
On Nov 02, 2010 at 18:42, Henning Westerholt henning.westerholt@1und1.de wrote:
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.
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
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt -
Juha Heinanen -
marius zbihlei