sr-users November 2009

sr-users@lists.kamailio.org

80 participants
108 discussions

Re: [Kamailio-Users] /usr/local/sbin/kamdbctl create error

by Daniel-Constantin Mierla

please cc the mailing list, otherwise your emails will be ignored. do you have the mysql client installed? Can you connect to the mysql server from terminal with 'mysql' command? Cheers, Daniel On 25.11.2009 19:42 Uhr, YÜKSEL wrote: > Dear Daniel, > > Thanks for your response : Actually I am getting an error below when > I try to create DB with `/usr/local/sbin/kamdbctl create` > > debian:/usr/local/src/kamailio-1.5.0/sip-server# > /usr/local/sbin/kamdbctl create > MySQL password for root: > INFO: test server charset > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 105: mysql: > command not found > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 106: mysql: > command not found > Usage: grep [OPTION]... PATTERN [FILE]... > Try `grep --help' for more information. > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 112: [: =: unary > operator expected > INFO: creating database openser ... > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 71: mysql: command > not found > ERROR: Creating core database and grant privileges failed! > > I`ve applied the instructor one by one but I didn`t understand whay I > am getting this error. > > Regards, > > Yuksel > > > --- On *Wed, 11/25/09, Daniel-Constantin Mierla /<miconda(a)gmail.com>/* > wrote: > > > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > Subject: Re: [Kamailio-Users] /usr/local/sbin/kamdbctl create error > To: "lazturk" <lazturk(a)yahoo.com> > Cc: users(a)lists.kamailio.org > Date: Wednesday, November 25, 2009, 12:33 PM > > Hello, > > > On 25.11.2009 17:59 Uhr, lazturk wrote: > > Hello, > > > > How did you solve this problem bcz I am getting a similar error ; > > > > which one? the one related to no database engine specified or the > one related to mysql socket file? > > First: updated the kamctlrc file -- see the comments inside. > > Second: check if mysql server is running and if yes, check the > mysql config to see where the server is listening and where the > mysql client tries to connect to. They must be the same. > > Cheers, > Daniel > > > > > Thanks for your feedback. > > > > > > vivi-8 wrote: > > > >> Hi all > >> I have specify the wanted db type (DBENGINE=MYSQL) in the > >> /usr/local/etc/kamailio/kamctlrc > >> then I using "/usr/local/sbin/kamdbctl create" to create MySQL > database, > >> but I got this error: > >> > >> > >> > >> ERROR: database engine not specified, please setup one in the > config > >> script > >> > >> root@acer:/usr/local/src/kamailio-1.5.0/sip-server# vim > >> /usr/local/etc/kamailio/kamctlrc > >> > >> root@acer:/usr/local/src/kamailio-1.5.0/sip-server# > >> /usr/local/sbin/kamdbctl > >> create > >> > >> MySQL password for root: > >> > >> INFO: test server charset > >> > >> ERROR 2002 (HY000): Can't connect to local MySQL server through > socket > >> '/var/run/mysqld/mysqld.sock' (2) > >> > >> ERROR 2002 (HY000): Can't connect to local MySQL server through > socket > >> '/var/run/mysqld/mysqld.sock' (2) > >> > >> Usage: grep [OPTION]... PATTERN [FILE]... > >> > >> Try `grep --help' for more information. > >> > >> /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 112: [: =: > unary > >> operator expected > >> > >> INFO: creating database openser ... > >> > >> ERROR 2002 (HY000): Can't connect to local MySQL server through > socket > >> '/var/run/mysqld/mysqld.sock' (2) > >> > >> ERROR: Creating core database and grant privileges failed! > >> > >> > >> > >> Cheers, > >> > >> vivi > >> > >> > >> _______________________________________________ > >> Kamailio (OpenSER) - Users mailing list > >> Users(a)lists.kamailio.org </mc/compose?to=Users(a)lists.kamailio.org> > >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > >> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users > >> > >> > > > > > > -- Daniel-Constantin Mierla > * http://www.asipto.com/ > > -- Daniel-Constantin Mierla * http://www.asipto.com/

14 years, 9 months

[Kamailio-Users] kam 1.5 dispatcher priority usage

by Robert McGilvray

What is the function of the priority field in dispatcher module? The docs are pretty light on the subject and it's not clear to me what it's meant to do. I'm looking for a way to assign a priority to preferred gateways within the same group. Thanks Bob -------------------------------------------------------------------------- This email with all information contained herein or attached hereto may contain confidential and/or privileged information intended for the addressee(s) only. If you have received this email in error, please contact the sender and immediately delete this email in its entirety and any attachments thereto.

14 years, 11 months

[Kamailio-Users] Problem with REGISTER

by Uriel Rozenbaum

Hello guys, I'm having a strange problem with my Kamailio 1.5.3 when trying to register an Audiocodes Gateway. I'm using authentication for REGISTER messages. The GW sends a REGISTER without credentials, so I do a proxy_challenge. Then the GW sends a REGISTER with credentials but the proxy_authorize is returning -4. I did an NGREP to check the messages and they don't seem malformed, can you tell me if there is something on the functions that might be loosing the Proxy-Authorization header? This happens only with this GW, not if i register a softphone (XLITE). Within route block: ... if (is_method("REGISTER")) { route(11); save("location"); exit(); } ... Route(11): route[11] { # ----- AUTENTICACION DE UN MENSAJE ----- if (!proxy_authorize("", "subscriber")) { switch($retcode) { case -1: xlog("L_INFO", "AUTH: Invalid username\n"); sl_send_reply("403", "Forbidden"); exit; case -2: xlog("L_INFO", "AUTH: Invalid password\n"); sl_send_reply("403", "Forbidden"); exit; case -3: xlog("L_INFO", "AUTH: Nonce ambiguo\n"); break; case -4: xlog("L_INFO", "AUTH: No credentials\n"); break; #default: #xlog("L_INFO", "AUTH: Unknown error\n"); #break; } #xlog("L_DBG", "AUTH: -Data- Auth Username = $au\n"); #xlog("L_DBG", "AUTH: -Data- Domain = $fd\n"); #xlog("L_DBG", "AUTH: -Data- From Username = $fU\n"); proxy_challenge("192.168.200.130","0"); exit; }; xlog("L_INFO", "AUTH: Valid username and credentials\n"); consume_credentials(); } NGREP: # U 10.0.1.200:5060 -> 192.168.200.130:5060 REGISTER sip:192.168.200.130 SIP/2.0. Via: SIP/2.0/UDP 10.0.1.200;branch=z9hG4bKac26395445. Max-Forwards: 70. From: <sip:testdevice@10.0.1.200 <sip%3Atestdevice(a)10.0.1.200> >;tag=1c26389068. To: <sip:testdevice@10.0.1.200 <sip%3Atestdevice(a)10.0.1.200>>. Call-ID: 154992670511200004613(a)10.0.1.200. CSeq: 68 REGISTER. Contact: <sip:testdevice@10.0.1.200:5060>;expires=180. Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE. Expires: 180. User-Agent: Audiocodes-Sip-Gateway-/v.5.80A.023.006. Content-Length: 0. . # U 192.168.200.130:5060 -> 10.0.1.200:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 10.0.1.200;branch=z9hG4bKac26395445. From: <sip:testdevice@10.0.1.200 <sip%3Atestdevice(a)10.0.1.200> >;tag=1c26389068. To: <sip:testdevice@10.0.1.200 <sip%3Atestdevice(a)10.0.1.200> >;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.ee1a. Call-ID: 154992670511200004613(a)10.0.1.200. CSeq: 68 REGISTER. Proxy-Authenticate: Digest realm="192.168.200.130", nonce="4b142e8900000000188436d32ee472791b706f36952f4162". Server: Kamailio (1.5.3-notls (i386/linux)). Content-Length: 0. . # U 10.0.1.200:5060 -> 192.168.200.130:5060 REGISTER sip:192.168.200.130 SIP/2.0. Via: SIP/2.0/UDP 10.0.1.200;branch=z9hG4bKac26766380. Max-Forwards: 70. From: <sip:testdevice@10.0.1.200 <sip%3Atestdevice(a)10.0.1.200> >;tag=1c26389068. To: <sip:testdevice@10.0.1.200 <sip%3Atestdevice(a)10.0.1.200>>. Call-ID: 154992670511200004613(a)10.0.1.200. CSeq: 69 REGISTER. Proxy-Authorization: Digest username="testdevice",realm="192.168.200.130",nonce="4b142e8900000000188436d32ee472791b706f36952f4162",uri="sip:192.168.200.130",algorithm=MD5,response="9fa0904b94f94152619a16c46ffa6485". Contact: <sip:testdevice@10.0.1.200:5060>;expires=180. Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE. Expires: 180. User-Agent: Audiocodes-Sip-Gateway-/v.5.80A.023.006. Content-Length: 0. . # U 192.168.200.130:5060 -> 10.0.1.200:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 10.0.1.200;branch=z9hG4bKac26766380. From: <sip:testdevice@10.0.1.200 <sip%3Atestdevice(a)10.0.1.200> >;tag=1c26389068. To: <sip:testdevice@10.0.1.200 <sip%3Atestdevice(a)10.0.1.200> >;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.b7c8. Call-ID: 154992670511200004613(a)10.0.1.200. CSeq: 69 REGISTER. Proxy-Authenticate: Digest realm="192.168.200.130", nonce="4b142e8900000001515ab7891a3d534cc3f15e5627322da3". Server: Kamailio (1.5.3-notls (i386/linux)). Content-Length: 0. . Thanks in advance! Uriel

14 years, 11 months

[Serusers] Via: branch tags from SER for CANCELs/BYEs frequently don't match value in the INVITE

by Frank Durda IV

As you may recall, this is a problem where frequently (well, virtually all of the time) when SER passed a BYE or CANCEL message through, the device receiving such messages from SER would reject them, because the Via: header line that SER added to the BYE or CANCEL message didn't match the one that SER added to the INVITE message sent earlier. I brought this up a couple of times in the list previously. As there was not any response on this point at all, I have done some digging and have a simplified example and analysis of what SER appears to be doing wrong. First, here is an example of the problem occurring. Here are key header lines from the INVITE and a BYE message of a sample call: INVITE INPUT TO SER From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone> Call-ID: 16305237000a0285 CSeq: 252558264 INVITE SER EMITTED THIS INVITE (to called party) Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKe47c.7be033a8ca37f0e8a1c6bfe63b043efe.0 From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone> Call-ID: 16305237000a0285 CSeq: 252558264 INVITE BYE INPUT TO SER (from calling party) Call-ID: 16305237000a0285 From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone>;tag=15358744 CSeq: 252558265 BYE SER EMITTED THIS BYE (to called party) Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKf47c.c79c6922afd022e9b4cdf00110f17fd5.0 Call-ID: 16305237000a0285 From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone>;tag=15358744 CSeq: 252558265 BYE The called switch rejects the BYE with a 481 because top-most Via: in the BYE does not match the one from the INVITE. Here are the two VIAs added by SER that do not match: INVITE Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKe47c.7be033a8ca37f0e8a1c6bfe63b043efe.0 BYE Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKf47c.c79c6922afd022e9b4cdf00110f17fd5.0 A review of how SER constructs the branch=nnnn value reveals where the differences are coming from: #1. e47c vs f47c difference caused by the Cseq: number changing between INVITE and BYE messages. The Cseq: value is supposed to be different in the INVITE and BYE per RFC 3261. The Cseq: should not be used in generating the branch=nnnn value. In this example, the BYE just happened to get the very next sequence number, but it will always be a value other than the sequence number seen in the INVITE. #2. 7be033a8ca37f0e8a1c6bfe63b043efe vs c79c6922afd022e9b4cdf00110f17fd5 is caused by ;tag=15358744 added to BYE To: header line. At minimum, any tags present on the To: and From: header should not be used in generating the branch=nnnn value because of the handling of tags in called-party-BYE situations. Also, there is no requirement in RFC 3261 that the To: nor From: header lines be used in generating the branch=nnnn value at all. Based on what I am seeing, it appears that neither the Cseq: nor the complete To: or From: header lines should have ever been used in constructing a branch=nnnn value, because of the adverse affects on CANCEL and BYE messages. Four things appear to be key to causing the branch=nnnn computation to generate non-compliant results in this example, as well as the case of a CANCEL message sent prior to the completion of the INVITE. (There could be other scenarios.) #1. The Cseq: value of the BYE will be different than the INVITE (per RFC 3261). The Cseq: header line should not ever be used in generation the hash for a branch=nnnn value as it will prevent the branch in BYE from matching the one in the INVITE. #2. If the called party generated the BYE message, the tags on the To: and From: header lines will be exchanged (also per RFC 3261), so the entire To: and From: header line's content cannot be used for generating a hash for a branch=nnnn value that is expected to match earlier messages that had a branch=nnnn value computed prior to the tag swap. #3. If a tag was previously absent on the To:/From:, a BYE from either party will add one. Again, the entire To: and From: header lines cannot be used for generating a hash for a branch=nnnn value that matches earlier messages prior to the addition of any tag. #4. Any deviation in the From: and To: header lines between INVITE and BYE/CANCEL will yield a different branch=nnnn value, even though the parameters of the From: and To: header lines may still be perfectly legal and technically identical. Any deviation may be the result of a sloppy SIP implementation in the calling equipment, but isn't valid grounds for not handling the message correctly. Examples include things like alternate number formats (as in To: sip:8885551212@66.77.88.99:5060 (seen in INVITE) versus To: <sip:8885551212@66.77.88.99:5060> (seen in CANCEL from same calling device), or differences in the amount of whitespace (including trailing whitespace), which is supposed to be ignored in SIP messages but the MD5 generator doesn't appear to know that it should ignore whitespace. Any one or a combination of these items (and possibly others) will cause the current branch=nnnn generation code in SER to generate a different branch=nnnn value and a receiving system who is following RFC 3261 will reject the BYE or CANCEL message that has passed through SER. This is non-compliant behavior. For BYE, you only get into this situation if you are using Record-Route to force the BYE message to pass through SER so that it can tear down the call (unforce_rtp_proxy() and similar actions), but for a CANCEL message, anybody can run into this problem, if syn_branch=0. So, while this defect in the branch=nnnn generation doesn't affect everybody, it still appears to be wrong. Is there by chance a compliant version of char_msg_val() exists that doesn't have these issues? That is, it doesn't use the Cseq: header line, and if it uses the From: or To: header line at all, it computes using only the called/calling digits, and not anything else that may appear on those header lines. I also don't understand why this is being MD5'ed. The RFC only says that the branch must be unique, and there are lots of cheaper has algorithms out there. Thanks for reading this far and thanks in advance for anyone who has fixed this or can come up with a fix.

14 years, 11 months

[Kamailio-Users] Add Reason Header in CANCEL request (forked call)

by heinz huber

Hi everyone, I've the following question: Is it possible to add a reason header in a CANCEL request? This is helpful in the following scenario: A call gets forked by the proxy (since there are more contacts for one AOR). On the of the SIP-destination-UAs accepts the call and sends a 200 OK to the proxy. The proxy afterwards generates the CANCEL request for all open UAC transactions. In this case it would be helpful to add additional infos, like "Call completed" elsewhere, so that the call is not listed in the "missing calls" list in the destinations UAs. I've found a linke in the tracker on http://sourceforge.net/tracker/?func=detail&aid=2581449&group_id=139143&ati… Has this feature been included in the last official kamailio version, or is it still open. thx && br Andy -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

14 years, 11 months

[Kamailio-Users] Kamailio RTP Proxy issues

by General Lee

Hi, I am currently integrating an H323 to SIP gateway with Kamailio and trying to route all calls through RTP Proxy. I have a problem where RTP Proxy treats both the incoming H323 gateway call (Caller) and outgoing SIP call (Callee) as the 'caller' in the RTP Proxy syslog. RTP Proxy doesn't assign a 'callee' therefore not able to setup a call (See syslog below). I have configured Kamailio to accept the 'ACK' with SDP and this is working correctly. When I enable H323 Fast connect and the SDP is included in the INVITE, the call connects correctly and is routed through RTP Proxy. I feel the problem is related to RTP Proxy receiving an INVITE from the H323-SIP gateway without SDP. Can anyone explain why RTP Proxy treats both the incoming H323 Gateway call and outgoing SIP call as the 'caller' in the RTP Proxy syslog. How can I make RTP Proxy treat the incoming H323 call as the 'callee'? Thanks, More information below ******************************************************************************* My H323 endpoints use H323 Slow Connect, so when the H323-SIP Gateway delivers the 'INVITE' to Kamailio there is no SDP included in the INVITE. I added a 'onreply_route' to the Kamailio configuration file which handles the 'ACK' with SDP which is working correctly. All of my SIP calls (Signalling + Media) are forced though RTP Proxy and I would like to force all H323-SIP Gateway calls through RTP Proxy. When placing a call from my H323 endpoint to my SIP UA, the RTP Proxy syslog records the incoming and outgoing call, however RTP Proxy states that the ‘callee’ is actually the 'caller'. The RTP Proxy syslog also states that the caller is the caller so there is no 'callee' (see below). In the syslogs both the ‘callee’ and ‘caller’ are recognised as the ‘caller’ so RTP Proxy has no callee to send the traffic back to. When the INVITE is received the ‘callee’ is populated in the syslogs as the ‘caller’. The H323 Gateway call is not recorded until after the ‘ACK’ with SDP is received from the gateway. Oct 27 17:33:05 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49620 (Should be callee) Oct 27 17:33:05 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49622 (Should be callee) Then after the ‘ACK’ is received from the Gateway, the H323 call is mentioned in the syslog as well as the other caller who is supposed to be the callee. Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 69.72.11.51:10204 Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 69.72.11.51:10214 Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49620 Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49622 -- View this message in context: http://www.nabble.com/Kamailio-RTP-Proxy-issues-tp26112049p26112049.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

14 years, 11 months

[Kamailio-Users] CDRTool Mediaproxy etc.. AG stuff

by Brian Chamberlain

Hi List, Apologies if you get this twice, for some reason the last post didn't seem to appear on the list.. I am running Debian lenny. Can I just change the repos in sources.list from lenny to testing and unstable to get the correct python dependencies etc for the ag-project tools? Thanks, Brian

14 years, 11 months

[Kamailio-Users] 487

by Anders

Hi, This question may belong in a general SIP forum - but I'll drop it here anyway, - hope I stir no big anger ;-) I'm running Kamailio 1.5, - use it for wholesale, and my customers typically send me calls from their Asterisk platform. I'm experiencing a very share of calls ending up in 487. This should be the client terminating the call - but is it my client (the provider with the Asterisk platform) or is it the final client - my client's client? Could Asterisk send a 487 for some reason? I've researched this (maybe not good enough!), but cannot find the answer: Does a 487 always mean that the client gave up and hung up? If this is the case, could high PDD be my problem - it's taking too long and the client gives up? Thanks!

14 years, 11 months

[Kamailio-Users] Binding to multiple IP addresses on the same interface.

by Geoffrey Mina

Hello, I have a Kamailio machine that has multiple IPs assigned to a single interface. eth0 = 1.2.3.4 eth0:1 = 1.2.3.5 In my Kamailio config i have listen=eth0:5060 And it doesn't appear to be binding to my second IP address. What is the proper way to tell the server to bind to all IPs on a single interface? I don't want to specify the IP directly for binding as I use the same config across 4 Kamailio servers. listen=eth0:1:5060 (i think that's not correct) Thanks, Geoff p.s. I would do some testing, but this is a live machine and I don't want to bring it up and down.

14 years, 11 months

Re: [Kamailio-Users] Compiling nonce.o (Auth Module) with TLS=1 fails

by Martin Koenig

Hello Laszlo, Good hint. We are building against openssl-0.9.7f-7.10. For testing purposes I have commented out the INCLUDE of md5.h in nonce.c, now the module compiles with the following warning: gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -Wall -minline-all-stringops -falign-loops -ftree-vectorize -mtune=prescott -Wold-style-definition -Wmissing-field-initializers -Wredundant-decls -DMOD_NAME='"auth"' -DNAME='"kamailio"' -DVERSION='"1.5.3-tls"' -DARCH='"i386"' -DOS='"linux"' -DCOMPILER='"gcc 4.0.2"' -D__CPU_i386 -D__OS_linux -D__SMP_yes -DCFG_DIR='"/usr/local/etc/kamailio/"' -DPKG_MALLOC -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DUSE_LOCAL_ROUTE -DF_MALLOC -DUSE_TLS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -I/usr/local/ssl/include -I/usr/local/include -I/usr/include/openssl -c nonce.c -o nonce.o nonce.c: In function âcalc_nonceâ: nonce.c:116: warning: implicit declaration of function âMD5Initâ nonce.c:126: warning: implicit declaration of function âMD5Updateâ nonce.c:129: warning: implicit declaration of function âU_MD5Finalâ I'll try to see if this is functional now. However, it feels like a "dirty hack". Best regards, Martin ________________________________ Von: voipfreak.net(a)gmail.com [mailto:voipfreak.net@gmail.com] Im Auftrag von Laszlo Gesendet: Montag, 30. November 2009 17:57 An: Martin Koenig Betreff: Re: [Kamailio-Users] Compiling nonce.o (Auth Module) with TLS=1 fails Hi Martin, [...] Which version of openssl you have? You might find this interesting: http://bugs.gentoo.org/146780 (botton of the page) -Laszlo

14 years, 11 months

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 November 2009