sr-users January 2020

sr-users@lists.kamailio.org

80 participants
93 discussions

Kamailio/RTC dinner at Fosdem 2020

by Daniel-Constantin Mierla

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.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com

4 years, 3 months

CSeq values in dialog OPTIONS keepalives

by Alex Balashov

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.html https://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/

4 years, 3 months

TLS and TCP port question

by Cyrille Demaret

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

4 years, 3 months

Kamailio v5.2.6 released

by Henning Westerholt

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/

4 years, 3 months

Implicit branch creation and private variables questions

by George Diamantopoulos

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" )

4 years, 3 months

Parallel forking and rtpengine handling

by Sebastian Damm

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

4 years, 3 months

Re: [SR-Users] TLS verification error LetsEncrypt

by Social Boh

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 >

4 years, 3 months

TLS verification error LetsEncrypt

by Bugaian A. Vitalie

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.

4 years, 3 months

Releasing Kamailio v5.2.6

by Henning Westerholt

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/>

4 years, 3 months

Ideas to reject a call due to RTPEngine failure when handling the 200Ok

by Patrick Wakano

Hello list, Hope you all doing well! I have a setup of Kamailio + RTPEngine (so no B2BUA), and I've come to a situation which I can't really figure out the best decision..... The case is a late SDP negotiation that the 200Ok with the SDP offer fails to engage the RTPEngine (for example no RTPEngine available). Also, the same problem can happen with a normal SDP negotiation, in case the INVITE goes through normally but then when engaging the SDP answer for the 200Ok, the RTPengine answer request fails for any reason... In these cases, I can't generate a proper SDP for the 200OOk so the call will connect normally, but the media path will be broken... So for such cases, I am thinking it is reasonable to fail the call. However, failing a call during the 200Ok stage is tricky, at this point we can't convert the 200Ok to a 50X. I tried and Kamailio doesn't allow and also RFC wise this is a no no for a SIP proxy.... I could completely remove the SDP body and forward the 200Ok. This will force a failed SDP negotiation and leave it for the endpoints the task to terminate the call. Is that acceptable? Has anyone faced such situation? Any idea is much appreciated! Kind regards, Patrick Wakano

4 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users January 2020