Hi
Please advise have you tried deploying Kamailio (just plain SIP server)
with mysql on Docker.
I was trying the same, using Kamailio & mysql images on
https://hub.docker.com
however there are two issues that I was facing:
1. I ran Wireshark on server & inside container I am getting 403 Not
relaying and SIP client MircoSIP does not connect. Request reaches the
server and the container however it gives 403 Not relaying.
I thought to print myuri value from Kamailio.cfg, to understand the issue
better however then comes the second issue as below:
2. This is a bigger issue: I am not able to generate any logs -no syslogs,
no docker logs (very limited logs get generated). Hence not able to
troubleshoot anything.
Please advise and help.
Thanks and Regards,
Jack.
Hello,
Fosdem 2020 is approaching, there will be a talk from Henning about
Kamailio, many other friends and related projects are presenting in the
RTC Devroom (Giacomo Vacca and Federico Cabiddu, Wazo, Asterisk, Homer,
Janus, Jitsi, CGRateS, Linphone, ...):
* https://fosdem.org/2020/schedule/track/real_time_communications/
I plan to be at the event and wondering if there are enough interested
participants for having the traditional Kamailio/RTC dinner. If yes,
Torrey will help to book a place to accommodate us (first choice could
be the same restaurant like the last year, if available).
Reply if you want to join the dinner and say how many other people are
joining you.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com
Hi,
I'd like to reopen an old thread of discussion:
Using Kamailio 4.4.x latest, when I enable dialog OPTIONS keepalives on
both sides of a call - ka-dst and ka-src dialog params, that is - I get
OPTIONS pings sent to one side with a CSeq value like this:
CSeq: 0 OPTIONS
and the other side:
CSeq: (CSeq of e2e ACK - 1) OPTIONS
The 0 CSeq is acceptable to most UAs--at least, among the small number
I've tested--and they answer 200 OK, but the second one results in a
'500 Server Internal Error'.
I have read the prior literature on this:
https://lists.kamailio.org/pipermail/sr-users/2012-May/073069.htmlhttps://lists.kamailio.org/pipermail/sr-users/2018-April/101096.html
and I (mostly) understand the rationale of keeping this mechanism
stateless.
I tried turning on `track_cseq_updates` to see if it might change the
behaviour, but it does not.
Anyway, a mechanism that deliberately elicits 500 responses from the
endpoint is going to raise some eyebrows and just looks a bit
unprofessional. I'm wondering if there is a better way to go.
My questions are:
1. While I understand the reasoning here:
"it would results de-synchronization of the CSeq values hold in phones
themselves (e.g., a BYE created by caller/callee after a keep alive will
be with lower cseq than the other side would expect and accept)."
Would it be such a problem to use a CSeq value that is
(last highest known CSeq observed) + ($RANDOM % LARGE_VALUE)?
2. In the case that `ka-dst` and `ka-src` are both enabled, why is there
an inconsistency in the behaviour with respect to the upstream and
downstream side (CSeq value of 0 vs. CSeq value of <= CSeq(ACK))?
3. At the risk of inviting some baroque state-keeping that is
runtime-dependent, could there be an implementation where the CSeq of
genuine in-dialog requests from the UA is modified in-flight by
Kamailio, taking advantage of its being in the middle of in-dialog
requests, to the appropriate next highest value?
I ask this because, if I understood the limited documentation for
`track_cseq_updates` correctly,
https://kamailio.org/docs/modules/5.3.x/modules/dialog.html#dialog.p.track_…
"Enable the callbacks for tracking if CSeq number needs to be
updated. It is the case when the INVITE has to be authenticated to
downstream provider using uac_auth() from uac module.
This is done only for requests in downstream direction. The CSeq
difference is stored in $dlg_var(cseq_diff), be sure this variable is
not overwritten via config operation."
it seems like the door to this method might already be open?
Thanks,
-- 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/
Hi,
Im trying to implement kamailio as a Teams SBC as described here :
<https://skalatan.de/en/blog/kamailio-sbc-teams>
https://skalatan.de/en/blog/kamailio-sbc-teams (thanks to the author, I
think hes here)
Im using Kamailio 5.2.1 and I still have a problem to have the SBC active
on the Microsoft side. Im correctly receiving the OPTIONS packet from
Microsoft but I have some doubt on my OK reply.
Heres the dialog captured in sngrep using the siptrace module :
The OPTIONS packet I receive from Microsoft contains a Contact header with a
different port as the original packet. So, Kamailio send the 200 OK back to
this port.
However, when I capture packets using tcpdump, I can see that theres no
connection to 52.114.76.76:5061 :
15:01:35.466926 IP 52.114.76.76.3008 > MY_IP.sip-tls: Flags [.], ack 1, win
2053, length 0
15:01:35.467383 IP 52.114.76.76.3008 > MY_IP.sip-tls: Flags [P.], seq 1:189,
ack 1, win 2053, length 188
15:01:35.467423 IP MY_IP.sip-tls > 52.114.76.76.3008: Flags [.], ack 189,
win 237, length 0
15:01:35.478535 IP MY_IP.sip-tls > 52.114.76.76.3008: Flags [.], seq 1:2881,
ack 189, win 237, length 2880
15:01:35.478771 IP MY_IP.sip-tls > 52.114.76.76.3008: Flags [P.], seq
2881:3017, ack 189, win 237, length 136
15:01:35.498028 IP 52.114.76.76.3008 > MY_IP.sip-tls: Flags [.], ack 2881,
win 2053, length 0
15:01:35.551569 IP 52.114.76.76.3008 > MY_IP.sip-tls: Flags [.], ack 3017,
win 2052, length 0
15:01:35.765965 IP 52.114.76.76.3008 > MY_IP.sip-tls: Flags [P.], seq
189:282, ack 3017, win 2052, length 93
15:01:35.767719 IP MY_IP.sip-tls > 52.114.76.76.3008: Flags [P.], seq
3017:3259, ack 282, win 237, length 242
15:01:35.800634 IP 52.114.76.76.3008 > MY_IP.sip-tls: Flags [P.], seq
282:825, ack 3259, win 2051, length 543
15:01:35.802362 IP MY_IP.sip-tls > 52.114.76.76.3008: Flags [P.], seq
3259:3656, ack 825, win 245, length 397
15:01:35.863823 IP 52.114.76.76.3008 > MY_IP.sip-tls: Flags [.], ack 3656,
win 2050, length 0
If I check the Kamailio log file :
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) exec: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} *** cfgtrace:request_route=[REQINIT]
c=[/etc/kamailio/kamailio.cfg] l=613 a=26 n=sl_send_reply
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/msg_translator.c:162]:
check_via_address(): (52.114.76.76, 52.114.76.76, 0)
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} sl [sl_funcs.c:500]:
sl_run_callbacks(): execute callback for event type 1
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} sl [sl_funcs.c:500]:
sl_run_callbacks(): execute callback for event type 1
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} siptrace [siptrace.c:1364]:
trace_sl_onreply_out(): trace off...
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/tcp_main.c:2225]:
tcpconn_send_put(): send from reader (17837 (25)), reusing fd
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/tcp_main.c:2460]:
tcpconn_do_send(): sending...
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/tcp_main.c:2494]:
tcpconn_do_send(): after real write: c= 0x7f81740edb30 n=397 fd=8
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/tcp_main.c:2495]:
tcpconn_do_send(): buf=
Jan 24 15:01:35 mysbc kamailio[17788]:
#027#003#003#001...M...t.[.._..gu..-3.8D#027#022..J.>..a..H.AË..
..)om.Oh.O.1.A..'.Fa...c.9..M}...#004O..#004
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} siptrace [siptrace_hep.c:498]:
pipport2su(): the port string is 5061
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} siptrace [siptrace_hep.c:498]:
pipport2su(): the port string is 5061
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/proxy.c:264]: mk_proxy():
doing DNS lookup...
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} siptrace [siptrace_hep.c:302]:
trace_send_hep2_duplicate(): setting up the socket_info
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) exec: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} *** cfgtrace:request_route=[REQINIT]
c=[/etc/kamailio/kamailio.cfg] l=614 a=2 n=exit
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/receive.c:353]:
receive_msg(): request-route executed in: 1018 usec
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/usr_avp.c:636]:
destroy_avp_list(): destroying list (nil)
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/xavp.c:495]:
xavp_destroy_list(): destroying xavp list (nil)
Jan 24 15:01:35 mysbc kamailio[17788]: 25(17837) DEBUG: {1 1 OPTIONS
fcde6307-1d3b-42fd-91bd-4547744fa00c} <core> [core/receive.c:457]:
receive_msg(): cleaning up
So, it seems that Kamailio is reusing the existing tls connection and then
sends my 200 OK to the port 3008 and not to the port 5061 as asked in the
contact header. Is my understanding ok?
Is that a normal behavior?
Thanks for your help.
Best regards,
Cyrille
Hello,
Kamailio SIP Server v5.2.6 stable release is out.
This is a maintenance release of the previous stable branch, 5.2, that includes fixes since the release of v5.2.5. There are no changes necessary to database schema or configuration language structure if you are upgrade from an earlier installation of v5.2.x. Deployments running previous v5.2.x versions are strongly recommended to be upgraded to v5.2.6.
For more details about version 5.2.6 (including links and guidelines to download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2020/01/kamailio-v5-2-6-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com<https://gilawa.com/>
Kamailio Merchandising - https://skalatan.de/merchandising/
Hello all,
I'm trying to accomplish the following scenario, and some questions have
been raised during testing: I'd like to be able to fork serially to a
number of downstream destinations in case of failure, but also try several
hosts which are available per destination network before failing over to
the next one. To that end, I'm using something similar to the following:
request_route {
...
$vn(some_var) = "some_value";
$vn(some_other_var) = "some_other_value";
...
$avp(provider_order) = "last_provider";
$avp(provider_order) = "first_provider";
...
t_set_fr(120000, 2000);
route(PROVIDER_SELECTION);
...
}
route[PROVIDER_SELECTION] {
if ( is_avp_set("$avp(provider_order)") ) {
t_on_failure("PROVIDER_SERIAL");
if ( $avp(provider_priority) == "first_provider" )
Hi,
our scenario is the following: We have two clients registered to our
Kamailio server, one with a TLS capable phone, one via websocket. Now,
when a call comes in, the call is forked and is sent out to both
clients. rtpengine handling is done in the branch route, so there are
two offers, and we use the "via-branch" parameter.
Now, when one branch answers the call, what happens to the other
branch? I there a way to delete the other branch? How and in which
route? Or does Kamailio do this automatically?
I'm happy for a hint.
Regards,
Sebastian
--
Sebastian Damm
Voice Engineer
__________________________________________
sipgate GmbH
I'm not sure but with let's encrypt you can create only server
certificate, not client certificate so you can't require and verify
client certificate.
Regards
---
I'm SoCIaL, MayBe
El 24/01/2020 a las 09:01, Bugaian A. Vitalie escribió:
> Ok, thanks.
>
> But my question is still about why verification fails/or what should
> be chked to make it work. Not how to disable it.
>
> Thanks.
>
> Vitalie.
>
> On Fri, Jan 24, 2020 at 2:54 PM Social Boh <social(a)bohboh.info
> <mailto:social@bohboh.info>> wrote:
>
> Hello,
>
> changing:
>
> [client:default]
> #method = TLSv1.2+
> verify_certificate = yes
>
> require_certificate = yes
>
> with
>
> [client:default]
> #method = TLSv1.2+
> verify_certificate = no
> require_certificate = no
>
> ---
> I'm SoCIaL, MayBe
>
> El 24/01/2020 a las 08:46, Bugaian A. Vitalie escribió:
>> Hello list,
>>
>> I have tried to setup my tls config tish LetsEncrypt following
>> this post:
>>
>> https://www.fredposner.com/1836/kamailio-tls-and-letsencrypt/
>>
>> My tls config looks like this:
>>
>>
>> [server:default]
>> method = TLSv1.2+
>> verify_certificate = no
>> require_certificate = no
>> private_key = /etc/letsencrypt/live/sbc.example.net-0001/privkey.pem
>> certificate =
>> /etc/letsencrypt/live/sbc.example.net-0001/fullchain.pem
>> ca_list = /etc/letsencrypt/live/sbc.example.net-0001/ca_list.pem
>> #ca_list = /usr/local/etc/kamailio/tls/cacert.pem
>> #crl = /usr/local/etc/kamailio/tls/crl.pem
>> server_name = sbc.example.net <http://sbc.example.net>
>> server_id = sbc.example.net <http://sbc.example.net>
>>
>> #ca_list = /usr/local/etc/fullchain.pem
>> #ca_list = /usr/local/etc/kamailio/tls/cacert.pem
>> #crl = /usr/local/etc/kamailio/tls/crl.pem
>>
>>
>> # ---
>> # This is the default client domain profile.
>> # Settings in this domain will be used for all outgoing
>> # TLS connections that do not match any other
>> # client domain in this configuration file.
>> # We require that servers present valid certificate.
>> #
>> [client:default]
>> #method = TLSv1.2+
>> verify_certificate = yes
>> require_certificate = yes
>>
>> ===================================
>> My ca_list has all certificates from
>> cat /etc/ssl/certs/ca-certificates.crt >>
>> /etc/letsencrypt/live/sbcc.example.net/ca_list.pem
>> <http://sbcc.example.net/ca_list.pem>
>>
>> I keep getting certificate validation failed see bellow:
>>
>> an 24 08:39:56 sbc.example.net <http://sbc.example.net>
>> /usr/local/sbin/kamailio[6371]: ERROR: tls [tls_util.h:42]:
>> tls_err_ret(): TLS write:error:1416F086:SSL
>> routines:tls_process_server_certificate:certificate verify failed
>> Jan 24 08:39:56 sbc.example.net <http://sbc.example.net>
>> /usr/local/sbin/kamailio[6371]: ERROR: <core>
>> [core/tcp_read.c:1505]: tcp_read_req(): ERROR: tcp_read_req:
>> error reading - c: 0x7f0474421f68 r: 0x7f0474422028 (-1)
>> Jan 24 08:39:56 sbc.example.net <http://sbc.example.net>
>> /usr/local/sbin/kamailio[6370]: ERROR: tls [tls_util.h:42]:
>> tls_err_ret(): TLS write:error:1416F086:SSL
>> routines:tls_process_server_certificate:certificate verify failed
>> Jan 24 08:39:56 sbc.example.net <http://sbc.example.net>
>> /usr/local/sbin/kamailio[6370]: ERROR: <core>
>> [core/tcp_read.c:1505]: tcp_read_req(): ERROR: tcp_read_req:
>> error reading - c: 0x7f0474401cb8 r: 0x7f0474401d78 (-1)
>>
>> =====================
>>
>> What params should I change or where to look for a solution on
>> this one?
>>
>> Thanks.
>>
>> Vitalie A. Bugaian.
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
Hello list,
I have tried to setup my tls config tish LetsEncrypt following this post:
https://www.fredposner.com/1836/kamailio-tls-and-letsencrypt/
My tls config looks like this:
[server:default]
method = TLSv1.2+
verify_certificate = no
require_certificate = no
private_key = /etc/letsencrypt/live/sbc.example.net-0001/privkey.pem
certificate = /etc/letsencrypt/live/sbc.example.net-0001/fullchain.pem
ca_list = /etc/letsencrypt/live/sbc.example.net-0001/ca_list.pem
#ca_list = /usr/local/etc/kamailio/tls/cacert.pem
#crl = /usr/local/etc/kamailio/tls/crl.pem
server_name = sbc.example.net
server_id = sbc.example.net
#ca_list = /usr/local/etc/fullchain.pem
#ca_list = /usr/local/etc/kamailio/tls/cacert.pem
#crl = /usr/local/etc/kamailio/tls/crl.pem
# ---
# This is the default client domain profile.
# Settings in this domain will be used for all outgoing
# TLS connections that do not match any other
# client domain in this configuration file.
# We require that servers present valid certificate.
#
[client:default]
#method = TLSv1.2+
verify_certificate = yes
require_certificate = yes
===================================
My ca_list has all certificates from
cat /etc/ssl/certs/ca-certificates.crt >> /etc/letsencrypt/live/
sbcc.example.net/ca_list.pem
I keep getting certificate validation failed see bellow:
an 24 08:39:56 sbc.example.net /usr/local/sbin/kamailio[6371]: ERROR: tls
[tls_util.h:42]: tls_err_ret(): TLS write:error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed
Jan 24 08:39:56 sbc.example.net /usr/local/sbin/kamailio[6371]: ERROR:
<core> [core/tcp_read.c:1505]: tcp_read_req(): ERROR: tcp_read_req: error
reading - c: 0x7f0474421f68 r: 0x7f0474422028 (-1)
Jan 24 08:39:56 sbc.example.net /usr/local/sbin/kamailio[6370]: ERROR: tls
[tls_util.h:42]: tls_err_ret(): TLS write:error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed
Jan 24 08:39:56 sbc.example.net /usr/local/sbin/kamailio[6370]: ERROR:
<core> [core/tcp_read.c:1505]: tcp_read_req(): ERROR: tcp_read_req: error
reading - c: 0x7f0474401cb8 r: 0x7f0474401d78 (-1)
=====================
What params should I change or where to look for a solution on this one?
Thanks.
Vitalie A. Bugaian.
Hello,
after the release of Kamailio 5.3.2 it is time to also release another minor version for the branch 5.2.
I plan to release Kamailio 5.2.6 next Friday, 24th January 2020, if there are no new reports of relevant issues that make us to reconsider and postpone.
Cheers,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com<https://gilawa.com/>