Dear List,
I am trying to achieve a scenario where I can recognize the original
peer and mask it as peer from subnet 10.0.7.0/24 with kamailio. Basic IP
connectivity is established with the following network configuration
(Debian9):
auto lo:1
iface lo:1 inet static
address 10.0.0.0/24
And of course I have routed 10.0.0.0/24 to servers public IP address
(hereby known as x.x.x.1) in my router.
Please consider the following scenario:
- Peer1 192.168.0.1 is sending INVITE to kamailio at IP x.x.x.1
- Kamailio sends INVITE to peer2 at 172.10.0.1 from socket 10.0.0.1
- Peer2 receives the INVITE and knows that since it came from IP
10.0.0.1 it means that INVITE is originally from peer1
- IF peer2 sends INVITE to kamailio, it should be sent to peerX from
socket 10.0.0.2
This works if I list both 10.0.0.1 and 10.0.0.2 with 'listen=' parameter
but things get out of hand if I have multiple peers. In my tests I have
noticed that 60 peers equals 60 listen parameters which equals roughly
500 kamailio processes. At some point there are just too many processes
and everything melts. If I omit the listen parameter altogether,
kamailio has only one socket from /24 subnet and it is 10.0.0.0.
Error message when listen parameter is omitted:
[pv_core.c:2612]: pv_set_force_sock(): no socket found to match [10.0.0.1]
My kamailio has the following configuration in request_route:
$avp(e_private) = $(sht(get_private=>$si));
$fs = $avp(e_private);
I know that the case is a bit confusing and totally something normal
people won't do. If you have any questions I am happy to answer.
Best Regards,
Joonas Keskitalo
Hello!
I need to separate Kamailio's dmq_usrloc by server_id and will be much
easily if server_id can accept string values also, like:
server_id="192.168.100.100"
But currently it accepts only integer:
https://www.kamailio.org/wiki/cookbooks/5.1.x/core#server_id
Syslog:
0(11488) CRITICAL: <core> [core/cfg.y:3447]: yyerror_at(): parse error in
config file /etc/kamailio/global.cfg, line 126, column 11-24: syntax error
0(11488) CRITICAL: <core> [core/cfg.y:3447]: yyerror_at(): parse error in
config file /etc/kamailio/global.cfg, line 126, column 11-24: number
expected
--
BR,
Denys Pozniak
Hi all,
I'm trying to understand why some Kamailio processes become Connor MacLeod
and go to live forever causing high # of aborted connections.
While watching in time over *SHOW PROCESSLIST*, some 12 kamailio
connections in *SLEEP* state, most of them are reused over time (time value
gets reset). However, a select few go on to SLEEP forever for as much as
the mysql's *wait_timeout* allows them to. Default was 28800 sec, that's
how long they lived. If I lower this to say 600 sec, even higher abort rate
is observed.
I suppose my questions are:
1. Is this normal to have so many SLEEPing connections?
2. What is the recommended MySQL *wait_timeout* value under Kamailio?
3. Any other suggestions as to why such a high rate of aborted
connections?
Merci!
Hi,
I have Kamailio in a weird interop/adaptation layer role with the
following call flow:
SUBSCRIBE to Kamailio with Expires: 0 --->
<-- immediate 200 OK from Kamailio
[some time passes]
<-- NOTIFY with additional info from Kamailio
200 OK to Kamailio --->
The NOTIFY follows a series of lengthy async HTTP interrogations, so
it's constructed at a later point in time with $uac_req(...).
The problem is that the standard which regulates this is extremely
eccentric in the following way: despite the immediate expiration of the
subscription, the NOTIFY is expected to conform to the format of an
in-dialog request as if a dialog existed.
Don't ask. It's as idiotic as it sounds. But it's a Broadsoft "standard".
I can match the To URI / To-tag by capturing it from the incoming From
header on the SUBSCRIBE and reproducing it into the outgoing To header
on the NOTIFY.
The issue is that my From-tag on the NOTIFY does not match the To-tag on
the 200 OK for the SUBSCRIBE. So, from the point of view of the
subscriber, the NOTIFY is "From" a different party to the one that
"initiated" a "dialog" in response to its subscription.
I'm just sending the "200 OK" for the SUBSCRIBE like this:
---
append_to_reply("Event: $hdr(Event)\r\n");
append_to_reply("Expires: $hdr(Expires)\r\n");
append_to_reply("Contact: <sip:$sel(cfg_get.domain.sip_domain):$Rp>\r\n");
send_reply("200", "OK");
---
I am not aware of anything like an onsend_route that I can use to gain
access to the To header of this reply. Nor am I aware of any means of
removing headers from a reply and injecting my own To header with a
self-generated To-tag I can later mimic in the From tag of the NOTIFY.
Any creative workarounds would be appreciated!
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Hello,
I have kamailio and rtpproxy running on the same server located behind a
router with NAT just like below.
UA(internet)---public ip---router(NAT)--Kamailio+RTPproxy(private
ip)--UA(private network)
There are several issues like one way audio.
I need users on the internet to communicate with each other, users on the
private network to communicate with each other, and users on the internet
and the private network to communicate with each other.
What is the best approach?
Best regards,
Clarence
Hi!
I noticed a minor problem when I set up the STUN config of my phone.
When the server is set, I am unable to reach the endpoint from kamailio
(Phone1 -> Kamailio -> Asterisk -> same Kamilio -> no outgoing SIP flow to
Phone2).
If I do not set it, it seems to fallback to it's RFC1918 address which is
then detected by nat_uac_test() and I can reach the phone.
During my tests with Asterisk directly, this did not make any difference.
Seems like Asterisk checks more than FLAG 19/8 in nat_uac_test().
If I am right, I strictly used the SIP source port for answers instead of
any self-detection using STUN or similar.
My kamailio node is connected to the internet directly and 95 percent of
(planned) phones are behind random NATs.
In example kamailio.cfg there are these settings:
# Caller NAT detection
> route[NATDETECT] {
> #!ifdef WITH_NAT
> force_rport();
> if (nat_uac_test("19")) {
> if (is_method("REGISTER")) {
> fix_nated_register();
> } else {
> if(is_first_hop()) {
> set_contact_alias();
> }
> }
> setflag(FLT_NATS);
> }
> #!endif
> return;
> }
AND (modified for direct RTP flow):
# RTPProxy control and signaling updates for NAT traversal
> route[NATMANAGE] {
> #!ifdef WITH_NAT
> if (is_request()) {
> if(has_totag()) {
> if(check_route_param("nat=yes")) {
> setbflag(FLB_NATB);
> }
> }
> }
> if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return;
> if(nat_uac_test("8")) {
> fix_nated_sdp("15");
> if (is_request()) {
> if (!has_totag()) {
> if(t_is_branch_route()) {
> add_rr_param(";nat=yes");
> }
> }
> }
> if (is_reply()) {
> if(isbflagset(FLB_NATB)) {
> if(is_first_hop())
> set_contact_alias();
> }
> }
> #!endif
> return;
> }
I checked the docs but I am not sure which FLAGs are safe to use (or break
things).
Any thoughts or hints are welcome.
Thank you very much!
Kind regards
Kevin
Thanks, that was very helpful.
But now I get an "ERROR: <core> [tcp_main.c:4070]: handle_tcpconn_ev(): connect <Client IP>:<Port> failed" displayed when trying to register.
The SIP client establishes the connection to the proxy via TCP, but does not receive an answer.
Could this indicate a faulty NAT-ALG?
I just made a test and, for sure, clang warns about unused variables:
$ clang -Wunused-variable -I/usr/include/re -I/usr/include/baresip -lbaresip -lrem -lre baresip.c
baresip.c:48:6: warning: unused variable 'unused' [-Wunused-variable]
int unused;
^
1 warning generated.
-- Juha
Hello friends and collegues,
A nice get together has been organized for evening Wednesday 10th at 7pm
The idea is to have drinks and chitchat about opensource telephony and
webrtc, and all opensource project founders, members, and practitioners are
invited.
Please join me, as distinguished participants too!
Check it out at http://party.officering.com
(no animals has been harmed in this mail)
-giovanni
--
Sincerely,
Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
