Hi,
I am using kamailio 5.8.3 as an IMS-PCSCF. On handling SIP INVITE (and
response), it sends Rx AAR to PCRF for bearer establishment.
For mobile-terminated call, it was found that the call was dropped by
handset within several seconds after ringing for some handsets.
The corresponding pcap capture is attached for reference.
From the pcap capture, it was found that in the Rx AAR request sent (packet
11), in the Media-Sub-Component Flow-Description,
the "permit out from ip/port" and "permit in to ip/port" were set to
202.0.169.182 port 24428 instead of 10.51.0.15 port 31124.
202.0.169.182 port 24428 is the one in the incoming INVITE sdp from
S-CSCF (packet 2);
10.51.0.15 port 31124 is the one in the processed INVITE sdp sent to UE
(packet 5);
Also, the sdp data of "offer" inside AAR was set to the sdp in the incoming
INVITE from S-CSCF instead of the sdp in the processed INVITE sent to UE.
Is that correct? Please advice.
Thank you.
Regards,
Hong
How can I set the destination URI for an INVITE to be a
websocket-secure destination? Is it possible?
Summary
I've a proxy with tcp_connection_match=1, but websocket URIs always
have transport=ws (never transport=wss) in them, so relaying a call to
a WSS connection always fails.
I tested running kamailio 6.0.0-dev2 compiled from a commit made this
week. This proxy server uses nathelper rather than outbound module.
Detail
We know that "transport=ws" is used for both WS and WSS. I've a proxy
server that receives an INVITE for a WSS destination, and this proxy
supports both WS and WSS.
This proxy server must have core parameter tcp_connection_match=1 set,
and this leads the t_relay() to fail.
When an INVITE comes, these are the steps.
- The URI is something like
sip:user@anonymous.invalid;alias=198.51.100.10~52833~6;transport=ws.
- First handle_ruri_alias() removes the alias (which has ~6 in it, for
wss) and sets the $du to something like
sip:198.51.100.10:52833;transport=ws.
- Then loose_route_preloaded() processes the Route header fields and
forces the outbound socket to the TLS websocket one.
- Then t_relay() fails to relay the INVITE and responds with 477 or 500.
If, however, there's a non-TLS websocket connection open to the proxy,
the INVITE would be erroneously relayed over that (using the wrong
kamailio-side TCP port).
I can go deeper with testing if required. I wonder whether this is a bug.
James
Hi,
I am using kamailio 5.8.3. I just found that strange result is returned from variable $stat(total_size).
In the example script under "misc/examples/ims/pcscf/kamailio.cfg", there is a line,
$var(used) = 1 - ($stat(free_size) / $stat(total_size));
The trace log said that $stat(total_size) was returning 0, and got a log like this
ERROR: <core> [core/rvalue.c:1434]: long_longop2(): rv div by 0
Any idea on this? Please advise.
Thank you.
Regards,
Hong
Hi,
I am using kamailio 5.8.3. I just found that strange result is returned from variable $stat(total_size).
In the example script under "misc/examples/ims/pcscf/kamailio.cfg", there is a line,
$var(used) = 1 - ($stat(free_size) / $stat(total_size));
The trace log said that $stat(total_size) was returning 0, and got a log like this
ERROR: <core> [core/rvalue.c:1434]: long_longop2(): rv div by 0
Any idea on this? Please advise.
Thank you.
Regards,
Hong
Hello,
We try to introduce a small websocket sidecar to our Kamailio servers, which runs on the same host. It connects to the regular TCP socket of our Kamailios, and in the XHTTP request route, we do just this:
if path == "/sidecar":
KSR.websocket.handle_handshake()
return 1
On every new connect, Kamailio logs a parse error for the reply it generates.
Sep 11 15:42:35 sipproxy /usr/sbin/kamailio[552]: ERROR: <core> [core/parser/parse_fline.c:272]: parse_first_line(): parse_first_line: bad message (offset: 22)
Sep 11 15:42:35 sipproxy /usr/sbin/kamailio[552]: ERROR: <core> [core/parser/msg_parser.c:790]: parse_msg(): ERROR: parse_msg: message=<HTTP/1.1 101 Switching Protocols
Sia: SIP/2.0/TCP 100.74.11.1:46422
Sec-WebSocket-Protocol: sip
Upgrade: websocket
Connection: upgrade
Sec-WebSocket-Accept: 60dPbzcRW6up7z92kDlxkqL2WlY=
Content-Length: 0
>
Sep 11 15:42:35 sipproxy /usr/sbin/kamailio[552]: ERROR: <core> [core/msg_translator.c:3402]: build_sip_msg_from_buf(): parsing failed
I saw this error in other questions from a while ago, but without a solution. What could be the reason for this?
Thanks in advance,
Sebastian
Hi,
I just tried to send numbers of SIP register to kamailio (release 5.8.2). It is reported that there are some memory leakage in shared memory after the expiry of all the registration sessions. After drill down the code. function save_pending(...) is called. (in ims_registrar_pcscf/save.c). Inside that function, it seems that "sec_verify_params" is not deallocated upon the function completes.
Findings:
- sec_verify_params uses the result from function cscf_get_security_verify(...)
- Function cscf_get_security_verify(...) returns the result of function parse_sec_agree(...)
- Function parse_sec_agree(...) returns "params" where "shm_malloc(...)" is called
It seems that the memory pointed by 'sec_verify_params' is not further referenced by others. Should shm_free(...) be called when leaving function save_pending(...) in order to free the unused memory of 'sec_verify_params'?
Please advice.
Thank you.
Regards,
Hong
Hello,
I was wondering if icc or suncc compilers are still used in the
community, and by that if it still worth trying to support them via
Makefiles and compile time flags (defines). Personally I haven't had to
deal with them for more than 10-15 years, I have no access with a system
offering them. Furthermore, I am not even sure if the code compiles with
them.
Maybe someone (or many) in the community use one or the other and
confirm that they still worth to be kept.
If not, maybe we can consider them for removing, it can be a good task
to be done during Kamailio development meeting planned in Dusseldorf,
Germany during November.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, October 8-10, 2024 -- asipto.com
Hi,
I just tried to use kamailio 5.8.3 as an IMS-PCSCF. After handling SIP registration, it seems that value of port in the "via" header in the request sent from PCSCF to UE is a bit strange.
When using uac_req to send OPTIONS to UE, it is found that in the OPTIONS sent out from kamailio, the value of port inside the "via" header is set to port_pc (pcscf ipsec client port). Is this correct? Or should the via header port be set to port_ps (pcscf ipsec server port) instead?
Also, in uac_req, is the value of via port header configurable?
Please advise.
Thank you.
Regards,
Hong
Hello,
I'm using async task group to handle some pourcentage of the traffic, while testing with traffic of 1200cps I got the following error :
ERROR: {1910812149 INVITE 6785db25bc3f2478@ip} <core> [core/async_task.c:439]: async_task_group_push(): failed to pass the task [0x7f4000c3a5c0] to group [async_group_name].
conf:
async_workers_group="name=async_group_name;workers=45;nonblock=1;usleep=100"
If someone can help please?
Hello!
I need to disable topos for one specific SIP trunk (in-out), it looks like
it’s enough to use event_route with IP address filtering.
But for some reason, the incoming INVITE from the peer still gets processed
by topos and I also don’t see a mention of [msg-incoming] in the logs, only
this:
WARNING: <script>: [msg-outgoing] OPTIONS/you/1.1.1.1
Code snippet:
loadmodule "topos.so"
modparam("topos", "db_url", DBURL)
modparam("topos", "contact_mode", 1)
modparam("topos", "header_mode", 1)
modparam("topos", "methods_noinitial", "OPTIONS,SUBSCRIBE,PUBLISH")
modparam("topos", "dialog_expire", 7210)
modparam("topos", "rr_update", 1)
modparam("topos", "event_mode", 5)
/*
1 - execute event_route[topos:msg-outgoing]
2 - execute event_route[topos:msg-sending]
4 - execute event_route[topos:msg-incoming]
8 - execute event_route[topos:msg-receiving]
*/
request_route {
....
event_route[topos:msg-outgoing] {
if ( $sndto(ip) == "1.1.1.1" ) {
xlog("L_WARN","[msg-outgoing] $rm/$rU/$sndto(ip) \n");
drop;
}
}
}
event_route[topos:msg-incoming] {
if ( $si == "1.1.1.1" ) {
xlog("L_WARN","[msg-incoming] $rm/$rU/$si \n");
drop;
}
}
# kamailio -v
version: kamailio 5.7.1 (x86_64/linux) 1cf389-dirty
--
BR,
Denys Pozniak
