You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My websocket TLS server is full of these kinds of messages:
Jan 18 18:10:26 ws0 /usr/sbin/kamailio[19701]: NOTICE: <script>:
http:217.120.x.x:55386: WS connection closed
...
Jan 18 18:10:26 ws0 /usr/sbin/kamailio[19689]: WARNING: <core>
[msg_translator.c:2506]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found
Jan 18 18:10:26 ws0 /usr/sbin/kamailio[19689]: ERROR: <core>
[msg_translator.c:1722]: build_req_buf_from_sip_req(): could not create Via header
Jan 18 18:10:26 ws0 /usr/sbin/kamailio[19689]: ERROR: tm
[t_fwd.c:527]: prepare_new_uac(): could not build request
Jan 18 18:10:26 ws0 /usr/sbin/kamailio[19689]: ERROR: tm
[t_fwd.c:1773]: t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches
Jan 18 18:10:26 ws0 /usr/sbin/kamailio[19689]: ERROR: sl
[sl_funcs.c:387]: sl_reply_error(): ERROR: sl_reply_error used: No error (2/SL)
(repeat these last errors for a bunch of attempted NOTIFY forwards)
The route block does basically something like this:
# add_contact_alias(); # only for requests from the outside
loose_route();
if (!t_relay()) {
sl_reply_error();
}
The problem arises here:
}else if (send_info->proto==PROTO_WS){
...
con = tcpconn_get(send_info->id, &ip, port, from, 0)
...
if (con == NULL) {
LM_WARN("TCP/TLS connection (id: %d) for WebSocket could not be found\n", send_info->id);
The NULL failure status gets returned up to prepare_new_uac in t_fwd.c:
shbuf=build_req_buf_from_sip_req( i_req, &len, dst, BUILD_IN_SHM);
if (!shbuf) {
LM_ERR("could not build request\n");
ret=E_OUT_OF_MEM;
goto error01;
}
At this point, ser_error will become E_OUT_OF_MEM while it should be something like E_SEND.
And E_OUT_OF_MEM gets translated to 500 No Error because we're not running in DEBUG mode.
What causes the connection to drop in the first place, you ask?
Where you see that the FIN is initiated by 195.35.x.x which is the Kamailio websocket server.
The cause (probably) is the WS client closing the connection. In this case after re-subscribing with Expires:0. The presence server attempts to reply with a bunch of NOTIFYs with Subscription-State: terminated;reason=timeout but they bounce on the broken connection. If Kamailio would return a nice "477 Unfortunately error on sending to next hop occurred" it'd be prettier.
Getting less "error" messages (a total of 6 per expired/unsubscribed subscription) after this error --which is apparently very common -- would be beneficial too.
As for fixing:
We could change the via_builder to set ser_error (and check that in build_req_buf_from_sip_req), or
add error-code-out-parameters to all calls from build_req_buf_from_sip_req and down.
I'm not sure if either is the best way.
As for the excessive error reporting, would looking at ser_error before printing (another) error be an acceptable fix?
Cheers,
Walter Doekes
OSSO B.V.
The text was updated successfully, but these errors were encountered:
What version are you using? The lines reported in logs are not matching latest 4.2 or master branches.
Using ser_error should work to differentiate on what happened inside via_builder() is ok. You can make a patch for that and if works for you, submit it here.
Not sure I get how you would protect with ser_error against excessive logging, but perhaps when I see the code it will be more clear. Make this a second patch to be reviewed separately, allowing the first to be merged without dependency on this one.
My websocket TLS server is full of these kinds of messages:
The route block does basically something like this:
The problem arises here:
The NULL failure status gets returned up to
prepare_new_uac
int_fwd.c
:At this point, ser_error will become
E_OUT_OF_MEM
while it should be something likeE_SEND
.And
E_OUT_OF_MEM
gets translated to500 No Error
because we're not running in DEBUG mode.What causes the connection to drop in the first place, you ask?
Where you see that the FIN is initiated by
195.35.x.x
which is the Kamailio websocket server.The cause (probably) is the WS client closing the connection. In this case after re-subscribing with Expires:0. The presence server attempts to reply with a bunch of NOTIFYs with
Subscription-State: terminated;reason=timeout
but they bounce on the broken connection. If Kamailio would return a nice "477 Unfortunately error on sending to next hop occurred" it'd be prettier.Getting less "error" messages (a total of 6 per expired/unsubscribed subscription) after this error --which is apparently very common -- would be beneficial too.
As for fixing:
via_builder
to setser_error
(and check that inbuild_req_buf_from_sip_req
), orbuild_req_buf_from_sip_req
and down.I'm not sure if either is the best way.
As for the excessive error reporting, would looking at
ser_error
before printing (another) error be an acceptable fix?Cheers,
Walter Doekes
OSSO B.V.
The text was updated successfully, but these errors were encountered: