sr-users

sr-users@lists.kamailio.org

42 participants
37517 discussions

dispatcher/carrierroute and branches across SBC and remote peer
by Nathan Ward 28 Nov '17

28 Nov '17

Hi, We use Kamailio as a SIP server, and SEMS as an SBC. We have a need to use the dispatcher/carrierroute modules to provide HA/load sharing across two different parts of our environment: 1) Our SBCs 2) Our peer’s SIP servers We have pairs of SBCs (for now) and they have the same network connectivity - different IPs of course, but they can reach the same things. Our peer’s network has 2 SIP servers (again, for now) reachable through either SBC. We select which SBC pair to use based on where the calls are going, in a branch route. In some cases, we use parallel forking, in others we use serial forking (i.e. to a media server for a prompt, then sending the call to wherever it needs to go). Right now there is no automatic failover or load sharing, so this is all simple logic - if call is to x peer or y customer, use x SBC or y SBC. I’m trying to add the failover/loadbalancing now. I have a few half baked ideas about how to achieve a network like this, but thought I’d ask if anyone else had done this first before I went too overboard. Currently I’m thinking of calling cr_route to figure out which peer SIP server, from there figuring out which SBC pair, and then calling ds_select_dst to select which SBC in the pair to set $du. I’m being tripped up though, as I can’t call cr_route or ds_select_dst in a branch route, but, as far as I’m aware that’s where I’d need to do so in order to handle this for multiple branches. Should I be looping the request through the SIP server to achieve this (i.e. force $du = 127.0.0.1 in my branch_route), or, can I avoid that complexity? -- Nathan Ward

1 0

Kamailio didn't start before increasing fork_delay
by igor.potjevlesch＠gmail.com 27 Nov '17

27 Nov '17

Hello, We suddenly had an issue on one Kamailio instance: we were not able to restart. Kamailio started to boot and fork and suddenly crashed. The last logs reported a failure regarding the ability to connect to one MySQL instance. I finally succeed to restart after increasing: fork_delay=5000 to fork_delay=9000. How this could happen suddenly? We already restarted Kamailio on this server. Regards, Igor.

2 5

Does Kamailio support RFC4117?
by Ye, Charlie (NSB - CN/Qingdao) 27 Nov '17

27 Nov '17

Hi Friends, Does Kamailio support RFC4117? Do you have any suggestions if I want support RFC4117 through Kamailio? Thanks and Best Regards, Charlie

2 2

Dispatcher with kam & fs behind nat
by Daniel Greenwald 27 Nov '17

27 Nov '17

Dispatcher is sending inbound calls to Freeswitch boxes. Both the FS boxes and Kam are behind the same nat. What is the correct way to pass calls to the FS boxes so that all SIP between FS & Kam use local IP's? Should Kam put two record-route headers on, one with PUBLICIP and one with PRIVATEIP? How is this accomplished? Thanks

2 3

Kamailio 5.0 Android Calling Not working
by Zeeshan M 25 Nov '17

25 Nov '17

Hello Friends, I had successfully installed and configured Kamailio 5.0 on linux machine. And tried it with linphone app & following are the issues i am facing, 1) IOS to Android Calling not working with timeout error on server end when we checked logs 2) Android to Android calls also not working same error. Kindly let me know what could be the issue. Regards, Zeeshan.

1 0

Re: [SR-Users] sipML5 through kamailio
by Wilkins, Steve 24 Nov '17

24 Nov '17

I just verified that I do have logging in all pertinent areas. I added tls and I do see "TLS accept successful" in the kamailio logs, however, I see no log being generated in route[xhttp:request], and I do have logging in the first line of this route. I don't think it is getting there. Also, I noticed I have event_route[xhttp:request] not route[xhttp:request]. Thank you, -Steve

1 0

sipML5 through kamailio
by Wilkins, Steve 24 Nov '17

24 Nov '17

Hello, I am attempting to use sipML5 to test WebRTC. I have not been successful in getting messages through to Kamailio though. I am running Kamailio 5.0.3 on Cento 7. My listen's in the kamailio configuration file are => listen=tcp:112.22.3.108:5060 advertise 34.226.187.61:5060 listen=udp:112.22.3.108:5060 advertise 34.226.187.61:5060 listen=tcp:112.22.3.108:10443 (which I will use in the sipML5 Expert mode) My sipML5 settings are => Public Identity - sip:user1@112.22.3.108 Realm - 112.22.3.108 Export mode setting are => WebSocket Server URL - wss://112.22.3.108:10443 (I have also tried wss://112.22.3.108:10443/ws) SIP outbound Proxy URL - udp://112.22.3.108:5060 (I have also left this blank) When I make a call I see no Kamailio activity (I have logging at the start of request_route) so I am not sure where the configuration error is. If I change the sipML5 configuration IP Address to use the asterisk IP Address, sipML5 works. My goal is to go WebRTC Client => Kamailio => Asterisk and eventually through some sort of media proxy. Thank you, -Steve

2 5

Re: [SR-Users] Cannot disable EC Diffie Hellman cipher suite
by otron2016＠gmail.com 24 Nov '17

24 Nov '17

Just a guess but maybe later entries [like +HIGH:+MEDIUM:+LOW] put it back. Try switching the order so that !ECDHE and the others you're trying to exclude come after. Sent from Samsung Mobile -------- Original message -------- From: Ilyas Keskin <ilyask92(a)gmx.de> Date: 11/24/2017 10:19 AM (GMT-08:00) To: miconda(a)gmail.com,"Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Subject: Re: [SR-Users] Cannot disable EC Diffie Hellman cipher suite Hi Daniel, yes I am using the tls.cfg file. I tried your suggestion to add the cipher suite string (notice the !EDCHE which I also added to the httpd ssl.conf) but nothing changed. [server:default] method = TLSv1 cipher_list = !DH:!ECDHE:!EDH:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL verify_certificate = no require_certificate = no private_key = /etc/letsencrypt/live/webrtc.ddnss.de/privkey.pem certificate = /etc/letsencrypt/live/webrtc.ddnss.de/fullchain.pem #ca_list = ./modules/tls/cacert.pem #crl = ./modules/tls/crl.pem Also here is a log snippet from tls module section of kamailio initialization. Notice first two lines. Also it seems to me the module actually ignores the local openssl installation and uses its own which has been compiled with the module itself (?). Other than that it seems to be accepting the cipher_list value just fine: Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_mod.c:355]: mod_init(): With ECDH-Support! Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_mod.c:358]: mod_init(): With Diffie Hellman Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_init.c:587]: init_tls_h(): tls: _init_tls_h: compiled with openssl version "OpenSSL 1.0.1e-fips 11 Feb 2013" (0x1000105f), kerberos support: on, compression: on Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_init.c:595]: init_tls_h(): tls: init_tls_h: installed openssl library version "OpenSSL 1.0.1e-fips 11 Feb 2013" (0x1000105f), kerberos support: on, zlib compression: compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_ Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: WARNING: tls [tls_init.c:649]: init_tls_h(): tls: openssl bug #1491 (crash/mem leaks on low memory) workaround enabled (on low memory tls operations will fail preemptively) with free Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: <core> [cfg/cfg_ctx.c:613]: cfg_set_now(): INFO: cfg_set_now(): tls.low_mem_threshold1 has been changed to 7864320 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: <core> [cfg/cfg_ctx.c:613]: cfg_set_now(): INFO: cfg_set_now(): tls.low_mem_threshold2 has been changed to 3932160 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: WARNING: tm [tm.c:594]: fixup_routes(): WARNING: t_on_branch("MANAGE_BRANCH"): empty/non existing route Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: WARNING: tm [tm.c:594]: fixup_routes(): WARNING: t_on_reply("MANAGE_REPLY"): empty/non existing route Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: WARNING: tm [tm.c:594]: fixup_routes(): WARNING: t_on_failure("MANAGE_FAILURE"): empty/non existing route Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: <core> [udp_server.c:175]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: <core> [udp_server.c:225]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:275]: fill_missing(): TLSs<default>: tls_method=12 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:287]: fill_missing(): TLSs<default>: certificate='/etc/letsencrypt/live/webrtc.ddnss.de/fullchain.pem' Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:294]: fill_missing(): TLSs<default>: ca_list='(null)' Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:301]: fill_missing(): TLSs<default>: crl='(null)' Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:305]: fill_missing(): TLSs<default>: require_certificate=0 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:312]: fill_missing(): TLSs<default>: cipher_list='!DH:!ECDHE:!EDH:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL' Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:319]: fill_missing(): TLSs<default>: private_key='/etc/letsencrypt/live/webrtc.ddnss.de/privkey.pem' Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:323]: fill_missing(): TLSs<default>: verify_certificate=0 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:326]: fill_missing(): TLSs<default>: verify_depth=9 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:670]: set_verification(): TLSs<default>: No client certificate required and no checks performed Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:275]: fill_missing(): TLSc<default>: tls_method=12 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:287]: fill_missing(): TLSc<default>: certificate='(null)' Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:294]: fill_missing(): TLSc<default>: ca_list='(null)' Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:301]: fill_missing(): TLSc<default>: crl='(null)' Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:305]: fill_missing(): TLSc<default>: require_certificate=1 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:312]: fill_missing(): TLSc<default>: cipher_list='(null)' Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:319]: fill_missing(): TLSc<default>: private_key='(null)' Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:323]: fill_missing(): TLSc<default>: verify_certificate=1 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:326]: fill_missing(): TLSc<default>: verify_depth=9 Nov 24 18:56:20 kamailio-sip /usr/sbin/kamailio[2864]: INFO: tls [tls_domain.c:655]: set_verification(): TLSc<default>: Server MUST present valid certificate Would it be possible to compile the tls module with certain openssl config switches (i.e. no-ec no-dh)? Any other ideas? Best regards, Ilyas Keskin Am 24.11.2017 um 15:45 schrieb Daniel-Constantin Mierla: Hello, On 23.11.17 22:42, Ilyas Keskin wrote: Hi there, I have set up a Kamailio 4.2.0 SIP server (centOS 7) for a university project regarding WebRTC comunication. While kamailio handles the signaling path I use the SIP.js demo phone js application (hosted on the same machine as kamaillio) for actual WebRTC stuff. For a deeper understanding and documetation purposes I have been trying to sniff the traffic with wireshark but failed due to the fact that kamailio uses Elliptic Curve Diffie Hellmann cipher suite (see wireshark snippet below) which is not decryptable. Secure Sockets Layer TLSv1.2 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 89 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 85 Version: TLS 1.2 (0x0303) Random: b8916e4e0f7c712503a77afcf4c9228598092c166353be50... Session ID Length: 32 Session ID: b0a31a6699a001b7991645dc61064ca4c4b073eff6913f26... Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Compression Method: null (0) Extensions Length: 13 Extension: renegotiation_info (len=1) Extension: ec_point_formats (len=4) I already tried importing captured SSLKEYLOG pre master secret from chrome and private key file issued by letsencrypt without success. On top of that I set this line SSLCipherSuite !DH:!ECDH:!EDH:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL in /etc/httpd/conf.d/ssl.conf and compiled openssl with no-ec no-dh (which worked see below). [admin@kamailio-sip ~]$ openssl ciphers SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:PSK-AES128-CBC-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA [admin@kamailio-sip ~]$ Setting modparam("tls", "cipher_list", "AESCCM") (or different ciphers) in /etc/kamailio/kamailio.cfg seems to have no effect on the actual negoiated cipher suite. Am I missing something? Any help or pointers into the right direction will be much appreciated. are you also using tls.cfg? If yes, there is an attribute for chiper list in it as well, try and see if works with it. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

2 1

Re: [SR-Users] sipML5 through kamailio
by otron2016＠gmail.com 24 Nov '17

24 Nov '17

"So, tls is required for wss?" Yes, as of the last rfc. It can work without it if the client software (browser) will accept it though by now most will treat it as insecure. I forget whether sipML5 will but my guess would be no. -------- Original message -------- From: "Wilkins, Steve" <swwilkins(a)mitre.org> Date: 11/24/2017 9:57 AM (GMT-08:00) To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Subject: Re: [SR-Users] sipML5 through kamailio Hello SamyGo, So, tls is required for wss? I thought that when I set a listen to Kamailio-Server-IPAddress:10443 and I sent a request through that IP and Port, that Kamailio would at least see the request and attempt to do something with it. I will go add tls and try again. Thank you! From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of SamyGo Sent: Thursday, November 23, 2017 12:40 PM To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> Subject: Re: [SR-Users] sipML5 through kamailio Can you clarify the IP addressing scheme as you've mentioned. There is no TLS interface? Advertised address for 5060 but not for WSS interface. Both listen and advertise are public IPs ? Also,you're handling WSS requests. Do you've xlog ines in the route[xhttp:request] to view when a request lands.! My config has this: #!substdef "!MY_IP_ADDR!123.134.156.167!g" #!substdef "!MY_WS_PORT!6010!g" #!substdef "!MY_WSS_PORT!6011!g" listen=tcp:MY_IP_ADDR:MY_WS_PORT listen=tls:MY_IP_ADDR:MY_WSS_PORT Then the xhttp event route: ``` event_route[xhttp:request] { set_reply_close(); set_reply_no_connect(); #Deny any HTTP requests on any port other than WS/WSS ports. if ($Rp != MY_WS_PORT && $Rp != MY_WSS_PORT ) { xlog("L_WARN", "HTTP request received on $Rp\n"); xhttp_reply("403", "Forbidden", "", ""); exit; } #Handle HTTP(s) onwards. xlog("L_INFO", "HTTP Request Received\n"); ``` On Thu, Nov 23, 2017 at 12:18 PM, Wilkins, Steve <swwilkins(a)mitre.org> wrote: Hi Sammy, First of all, thank you for taking the time to respond. Yes, port 10443 is opened. I have used this port before as asterisk’s WebRTC port and iptables shows it as open. No, I can’t even get a registration using the configuration I listed. I have an xdbg log statement right after the request_route, and I see nothing. I do know that my xdbg logs are working though because, if I register or make a call using any sip tool, I see all my logging and everything works correctly. -Steve From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of SamyGo Sent: Thursday, November 23, 2017 12:00 PM To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> Subject: Re: [SR-Users] sipML5 through kamailio Hi Steve, Can you confirm that port 10443 is reachable behind the NAT to Kamailio server, validate iptables too Does your SIPml5 demo client register successfully to Kamailio? are there enough xlog lines to print out if anything lands in Kamailio. Regards, Sammy On Thu, Nov 23, 2017 at 11:34 AM, Wilkins, Steve <swwilkins(a)mitre.org> wrote: Hello, I am attempting to use sipML5 to test WebRTC. I have not been successful in getting messages through to Kamailio though. I am running Kamailio 5.0.3 on Cento 7. My listen’s in the kamailio configuration file are => listen=tcp:112.22.3.108:5060 advertise 34.226.187.61:5060 listen=udp:112.22.3.108:5060 advertise 34.226.187.61:5060 listen=tcp:112.22.3.108:10443 (which I will use in the sipML5 Expert mode) My sipML5 settings are => Public Identity - sip:user1@112.22.3.108 Realm - 112.22.3.108 Export mode setting are => WebSocket Server URL - wss://112.22.3.108:10443 (I have also tried wss://112.22.3.108:10443/ws) SIP outbound Proxy URL - udp://112.22.3.108:5060 (I have also left this blank) When I make a call I see no Kamailio activity (I have logging at the start of request_route) so I am not sure where the configuration error is. If I change the sipML5 configuration IP Address to use the asterisk IP Address, sipML5 works. My goal is to go WebRTC Client => Kamailio => Asterisk and eventually through some sort of media proxy. Thank you, -Steve _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

1 0

Cannot disable EC Diffie Hellman cipher suite
by Ilyas Keskin 24 Nov '17

24 Nov '17

Hi there, I have set up a Kamailio 4.2.0 SIP server (centOS 7) for a university project regarding WebRTC comunication. While kamailio handles the signaling path I use the SIP.js demo phone js application (hosted on the same machine as kamaillio) for actual WebRTC stuff. For a deeper understanding and documetation purposes I have been trying to sniff the traffic with wireshark but failed due to the fact that kamailio uses Elliptic Curve Diffie Hellmann cipher suite (see wireshark snippet below) which is not decryptable. Secure Sockets Layer TLSv1.2 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 89 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 85 Version: TLS 1.2 (0x0303) Random: b8916e4e0f7c712503a77afcf4c9228598092c166353be50... Session ID Length: 32 Session ID: b0a31a6699a001b7991645dc61064ca4c4b073eff6913f26... Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Compression Method: null (0) Extensions Length: 13 Extension: renegotiation_info (len=1) Extension: ec_point_formats (len=4) I already tried importing captured SSLKEYLOG pre master secret from chrome and private key file issued by letsencrypt without success. On top of that I set this line SSLCipherSuite !DH:!ECDH:!EDH:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL in /etc/httpd/conf.d/ssl.conf and compiled openssl with no-ec no-dh (which worked see below). [admin@kamailio-sip ~]$ openssl ciphers SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:PSK-AES128-CBC-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA [admin@kamailio-sip ~]$ Setting modparam("tls", "cipher_list", "AESCCM") (or different ciphers) in /etc/kamailio/kamailio.cfg seems to have no effect on the actual negoiated cipher suite. Am I missing something? Any help or pointers into the right direction will be much appreciated. Best regards, Ilyas Keskin

2 2

Jump to page:

2025

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