Hello,
First, i have 7 years experience with Asterisk, but I started a project
with Kamailio, forgive me in advance if I say silly things...! ;-)
I set up a classic Asterisk / Kamailio configuration:
sip phones -> kamailio -> asterisk -> sip trunks/pstn.
When a call comes from the PSTN side, if I configure Asterisk as follows:
[012345678]
type = friend
username = 012345678
secret = xxxxxxx
host = dynamic
fromdomain = sip.mydomain.com
fromuser = 012345678
Standard mode:
exten => 012345678, 1, Dial(SIP/012345678) -> The call is redirected on the
phone by Kamailio ! :-)
------------------------------------------------------------------------------------------------------------------------------------------------
Trunk mode:
[mytrunk]
type = friend
username = mytrunkUser
secret = xxxxxxx
host = dynamic
fromdomain = sip.mydomain.com
fromuser = mytrunkUser
exten => 012345678, 1, Dial(SIP/mytrunk/012345678) -> The call is rejected
by Kamailio....
exten => 012345679, 1, Dial(SIP/mytrunk/012345679) -> The call is rejected
by Kamailio ....
My question is how to allow the routing of multiple numbers (trunk mode) in
a SIP account with Kamailio?
Best regards,
Mickael
Hello everyone,
My name is Bruno, I'm a student from Portugal studying IMS at the moment. I've been following tutorials online, trying to get Kamailio to work as an IMS core - I'm pretty much a newbie in this field.
Unfortunantly I've been getting several errors and I can't seem to properly configure everything. I was wondering if there is a All-in-One VM that can be downloaded, with Kamailio ready to be used as an IMS core?
Thanks in advance. Best regards,
Bruno C.
For immediate release:
ATLANTA, GA (1 April 2015)--Evariste Systems LLC, an Atlanta-based software
vendor specialising in Kamailio-based service delivery solutions for the
VoIP ITSP market, is pleased to announce that it, in collaboration with
Red Hat Software and Ringfree Communications, has finalised the
absorption of the Kamailio SIP Server into the 'systemd' system management
platform for Linux. The new component shall be called 'systemd-rtc-server',
or 'Systemd Real-Time Communication Server'.
Alex Balashov, principal of Evariste and leader of the tri-vendor
collaboration effort, will officially announce the handover of the reigns
of the Kamailio project to the personal leadership of Lennart Poettering
at the upcoming Systemd Real Time Communications World conference, to be
held in Berlin on 27-29 May of this year.
John Knight, Director of GNOME 3 Integration and part-time usability
consultant at Ringfree Communications, based in Hendersonville, North
Carolina,was quick to summarise the triumphs of the long-standing
integration effort.
Remarked Knight:
"The industry has recognised for years that a SIP proxy is a basic building
block in the 'init' subsystem of any Linux host. In this age of multimedia
communication with voice and video, it was a travesty that systemd handled
time synchronisation, network configuration, login management, logging,
and console, but not SIP message routing."
Sean McCord, a veteran partner at Atlanta-based integrator CyCORE & Docker,
was quick to concur:
"SIP calls are much easier to troubleshoot with binary logs. Combined
with packet captures of TLS-encrypted WebRTC calls, systemd-journald
is the ultimate call setup troubleshooting methodology of the responsive,
kinetic enterprise."
To support the integration of Kamailio into the ecosystem of every major
Linux distribution, Evariste has released new 'dbus_api' and 'pulseaudio'
modules for the project.
Balashov stated, "We fully expect to use the D-Bus API to achieve
gnome-session integration with systemd-rtc-server-usrloc, but we aren't
going to leave Windows users behind; KamailioSvcHost.exe will support
Domain Controller policies for G.722 in Active Directory forests."
Despite an aggressive delivery timeline by the tri-vendor consortium behind
systemd-rtc-server, industry commentators have widely lambasted the fact
that it took so long for Kamailio to become integrated into systemd. Fred
Posner, solutions architect at The Palner Group in Fort Lauderdale, Florida,
recently wrote in a widely-publicised blog post:
"sr-dev have been keeping their heads in the sand for too long. For years
now, it has been completely obvious and self-evident to anyone with half
a brain that all kinds of VoIP software should be included in systemd.
It's a basic building block of the whole OS, having absorbed functionality
previously provided by all kinds of packages like util-linux and
wireless-tools."
John Knight of Ringfree accepted the criticism readily, but advocated a
forward-thinking orientation focused on breaking with the uncertainty of
the past:
"In the absence of a SIP component for routing calls to the PSTN, some
people thought, 'systemd has no clear direction apart from the whims of its
developers, and is a perpetually moving goal post.' Well, a SIP server
should
put an end to that whole discussion; that's exactly what was missing,
and now
that we have systemd-rtc-server, we've eliminated all doubts about the
coherence, conceptual integrity and finality of systemd."
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Good day,
I’m experiencing some problems with our VoiP providers handling of REGISTER requests. We are using a Gigaset PRO N720 as UAC behind a Juniper SSG 140 with SIP-Alg enabled. This setup kind of works with UDP but our provider wants us to use TCP. With TCP enforced incoming calls don’t work. I’ve done some wire tracing and to me it seems that the providers configuration is to blame, but then - there are many RFCs out there and many NAT and UAC bug workarounds. Anyway, I wanted to get the opinion of “the" experts about how the requests send to the UAS SHOULD be correctly interpreted.
The REGISTER requests/responses look like this (outside of the firewall):
Protocol TCP!
client port 19091 <-> server port 5060
REGISTER sip:pbx.peoplefone.ch SIP/2.0
Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bKc1375589832468de63a719eac31156ec
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>
Call-ID: 2825358480@10_10_128_10
CSeq: 1 REGISTER
Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp>
Max-Forwards: 70
User-Agent: N720-DM-PRO/70.089.00.000.000
Expires: 180
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bKc1375589832468de63a719eac31156ec
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.b8fc
Call-ID: 2825358480@10_10_128_10
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="pbx.peoplefone.ch", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy"
Server: kamailio (3.2.1 (x86_64/linux))
Content-Length: 0
REGISTER sip:pbx.peoplefone.ch SIP/2.0
Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>
Call-ID: 2825358480@10_10_128_10
CSeq: 2 REGISTER
Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp>
Authorization: Digest username="90780408050", realm="pbx.peoplefone.ch", uri="sip:pbx.peoplefone.ch", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy", response="764f371a08d258157a249f8d1b852514"
Max-Forwards: 70
User-Agent: N720-DM-PRO/70.089.00.000.000
Expires: 180
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.6bda
Call-ID: 2825358480@10_10_128_10
CSeq: 2 REGISTER
Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp>;q=0;expires=180;received="sip:212.126.160.92:19091;transport=TCP"
Server: kamailio (3.2.1 (x86_64/linux))
Content-Length: 0
The ip:port the firewall is sending those requests from is ip 212.126.160.92 port 19091. So this does NOT match the port from the Contact header. For TCP this seems rather logical to me, as one cant be listening on a TCP port and use it for sending at the same time. The UAC closes this “register connection” with TCP FIN after the register, and so does the firewall.
However unfortunately subsequent requests from the provider (ie UAS) come in on port 19091 (not port 6717 from the Contact header) and the firewall simply drops them.
Observations:
- the server does NOT include received=212.126.160.92 in the Via of the reponse. According to RFC3581 this is mandatory when rport is present in the request, so this is probably an error in the server.
- the server does include received="sip:212.126.160.92:19091;transport=TCP” in the Contact of the response. I didnt see this in any RFC (which means nothing;-) but it could be an error.
- after the client received the 200 OK it closes the TCP connection.
- the server tries several times to re-contact the client (incoming TCP SYN). However not on port 6717 (defined in the Contact header) but on port 19091 (where the REGISTER came from).
RFC3581 defines special behaviour when “rport” is defined in the request (i.e. response should go to the same port the request came from) - however it’s not so clear if this should apply to subsequent (INVITE/OPTIONS) requests from the server to the client. Those are strictly spoken not replies (or are they?).
RFC5626 defines that a “proxy” should keep track of the flows over which it received a registration and send requests over the same flow. It is not clear if RFC5626 should be applied. The RFC5626 defines that a UAC includes an “ob” parameter in the Contact field if it whishes further requests over the same flow. Also the RFC mandates a client to add a "reg-id=x" in the Contact field. Both are not the case here, so in short I think RFC5626 should NOT be applied. In which case conecting to the originating port (instead of the Contact port) would be a server error.
So in short and if I interpret the RFCs correctly, the client is reachable and should be contacted on
Transport: TCP
IP: 212.126.160.92
Port: 6717
If anyone who lives and breathes SIP could enlighten me if the UAS is right to call back on 19091 instead of 6717 I would really appreciate it;-))
Best regards,
Joachim
Hello all,
Just wondering if anyone know any tutorial on setting up HA+DRBD solution for kamailio.
Especially creating partitions, DRBD devices and mount points.
Thanks in advance,
-Sid
"May the light be with you." ______________________________________________
Siddhardha Garige
www.luminepixels.com
Hi,
we have a serious problem with Kamailio v4.2.3, it crashes after some days. We have checked the core dump and the gdb output is the following for bt and full backtrace:
#0 0x0000000000602291 in timer_list_expire (t=1432559962, h=0x7f64eb5b6bd0, slow_l=0x7f64eb5ba328, slow_mark=43873) at timer.c:877
#1 0x0000000000602746 in timer_handler () at timer.c:953
#2 0x0000000000602bb9 in timer_main () at timer.c:992
#3 0x00000000004a833c in main_loop () at main.c:1700
#4 0x00000000004ad857 in main (argc=13, argv=0x7fff96697d38) at main.c:2578
#0 0x0000000000602291 in timer_list_expire (t=1432559962, h=0x7f64eb5b6bd0, slow_l=0x7f64eb5ba328, slow_mark=43873) at timer.c:877
tl = 0x7f64ebc3a908
ret = 0
#1 0x0000000000602746 in timer_handler () at timer.c:953
saved_ticks = 1432559962
run_slow_timer = 0
i = 865
__FUNCTION__ = "timer_handler"
#2 0x0000000000602bb9 in timer_main () at timer.c:992
No locals.
#3 0x00000000004a833c in main_loop () at main.c:1700
i = 4
pid = 0
si = 0x0
si_desc = "udp receiver child=3 sock=127.0.0.1:5060\000\375\362\250/\313\345\v\004\000\000\000\000\000\000\000\004\257\263=\000\000\000\000\200TA\000\000\000\000\000\060}i\226\377\177", '\000' <repeats 19 times>, "{i\226\377\177\000\000\376\366R\000\000\000\000\000\377\377\377\377\377\177\000\000@\350\250\000\000\000\000"
nrprocs = 4
__FUNCTION__ = "main_loop"
#4 0x00000000004ad857 in main (argc=13, argv=0x7fff96697d38) at main.c:2578
cfg_stream = 0x1b94010
c = -1
r = 0
tmp = 0x7fff96699b17 ""
tmp_len = 0
port = 1
proto = 32767
options = 0x703e08 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:"
ret = -1
seed = 2591880768
rfd = 4
debug_save = 0
debug_flag = 0
dont_fork_cnt = 0
n_lst = 0x0
p = 0x7fff96697c50 ""
__FUNCTION__ = "main"
In the logs it can be seen:
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4635]: CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 21
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: ALERT: <core> [main.c:784]: handle_sigs(): child process 4623 exited by a signal 11
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: ALERT: <core> [main.c:787]: handle_sigs(): core was generated
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: INFO: <core> [main.c:799]: handle_sigs(): terminating due to SIGCHLD
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4631]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4628]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4634]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4615]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4617]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4626]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4625]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4624]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4632]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4622]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4621]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4620]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4619]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4618]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4616]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4635]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4614]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4629]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4627]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4633]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4630]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: INFO: <core> [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7f64eca19950/0x7f64eca19988) - ignore
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: INFO: <core> [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7f64ed587f20/0x7f64ed587f58) - ignore
Kamailio runs on Ubuntu trusty. The interesting thing that we run Kamailio 4.2.3 in an other environment (on Debian Squeeze) and it works perfect, no crashes. The main difference is that in Debian environment we have less number of users and the firewall is not so strength. But the configuration and the source is the same for both.
Please help us to solve this problem. Thanks.
Dr. Péter Barabás
Director of Software Development
Arenim Technologies AB.
Mob: +36 70 314 56 57
Tel: +36 1 8 555 602
E-mail: peter.barabas(a)arenim.com<mailto:peter.barabas@arenim.com>
Postal: Sweden - 11435 Stockholm, Stureplan 4c, 4th. Floor
[Arenim_logo]<http://www.arenim.com/>
[CryptTalk_Logo]<http://www.crypttalk.com/>
i have configured msilo module successful but there isn't any voice with
msilo. i debug and compare the call flow with and without msilo. with msilo
in call flow it didn't follow to relay and consequently didnt activate
rtpproxy befor the call is answered. due to which during call there isn't
any voice. please help
--
View this message in context: http://sip-router.1086192.n5.nabble.com/NO-VOICE-AFTER-MSILO-tp137430.html
Sent from the Users mailing list archive at Nabble.com.
is there any way to make deb packages for only 1 of the modules ??
currently it takes a long time to run "make deb"
im simply trying to build and package db_cassandra ( need the package for
my environment )
As a side note, is there any chance db_cassandra could be added to the
kamailio deb packages ?
--
Sincerely
Jay
Hi,
After restarting Kamailio, I got the following errors during the startup:
kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:381]:
db_mongodb_get_columns(): field [caller_sock] not found in result iterator
kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:739]:
db_mongodb_store_result(): failed to set the columns
kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:918]:
db_mongodb_query(): failed to store result
kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:927]:
db_mongodb_query(): failed to do the query
kamailio[12614]: ERROR: dialog [dlg_db_handler.c:257]:
select_entire_dialog_table(): Error while querying database
What may be causing the issue? I should always have a caller_sock in every
dialog document.
Thanks,
Mickael
Hi
I've hit a problem with sht_rm_name_re() in htable module. I was calling it
like this:
sht_rm_name_re("Dlg=>$var(callid)::tenant");
But when I used sipp to generate 600 concurrent calls for example, I called
this function when receiving BYE. But it removed more entries than it
should. Seems when removing removing some entry with callid
1-3798(a)192.168.60.80, it also removed entries for [1-9]1-3798(a)192.168.60.80.
How do I add '^' in front and '$' at the end of the regexp string when
calling this function please? Here I don't really need regexp in fact, just
want to do an exact match. But I didn't find any other functions for
deleting entries.
Thank you!
Yufei
