[OpenSIPS-Users] OpenSIPs 3.1.3 uses TLS for no reason
Hi, I am puzzled by the behaviour of my opensips (3.1.3) server. It 'decided' to send requests from one of accounts via TLS even though not configured to do that. excerpt from my logs (anonymized): Jul 12 14:48:35 sip1 /usr/sbin/opensips[28301]: #528515: Forwarding INVITE request to: Jul 12 14:48:35 sip1 /usr/sbin/opensips[28301]: #528515: new branch at sip:5@192.168.111.222;transport=udp Jul 12 14:48:35 sip1 /usr/sbin/opensips[28301]: ERROR:core:tcp_connect_blocking_timeout: poll error: flags 28 - 4 8 16 32 Jul 12 14:48:35 sip1 /usr/sbin/opensips[28301]: ERROR:core:tcp_connect_blocking_timeout: failed to retrieve SO_ERROR [server=192.168.111.222:5061] (111) Connection refused Jul 12 14:48:35 sip1 /usr/sbin/opensips[28301]: ERROR:proto_tls:tls_sync_connect: tcp_blocking_connect failed Jul 12 14:48:35 sip1 /usr/sbin/opensips[28301]: ERROR:proto_tls:proto_tls_send: connect failed Jul 12 14:48:35 sip1 /usr/sbin/opensips[28301]: ERROR:tm:msg_send: send() to 192.168.111.222:5061 for proto tls/3 failed Jul 12 14:48:35 sip1 /usr/sbin/opensips[28301]: ERROR:tm:t_forward_nonack: sending request failed Jul 12 14:48:35 sip1 /usr/sbin/opensips[28301]: ERROR:tm:w_t_relay: t_forward_nonack failed The routing is done by the drouting module. I have even forced 'transport=udp' and using the udp: socket in the dr_gateways table. And opensips still attempts to send this via TLS, which fails. The worst thing it that is only happening for a customer account on the production server. I cannot enable debug logs there or do any other invasive debugging. The same drouting gataway works properly for traffic of other customers. The other gateways, that are supposed to use TLS, also work as expected. I have checked traffic dumps – there is no attempt to use anything other than TLS there. And the original request looks 100% normal, with no mention of 'tls' or 'sips:' there. Any idea what might be going on there? Or how can I debug it? Looks like some random details is triggering the problem. Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dynamic Routing and TLS
On 30.03.2020 09:53, Jacek Konieczny wrote: Is there any known way to use drouting with TLS and with automated gateway probing/disabling? After peeking into the source code and more trial and error I found a way. And I have tried a lot before sending my previous mail too. I had to add 'sips:' prefix to the 'address' column of the 'dr_gateways' table *and* to set the 'socket' field there (otherwise opensips would fail with 'ERROR:core:get_out_socket: no socket found'). I would prefer not to have any socket addresses in that database (I would keep that in the server configuration), but I can live with it. I find this quite confusing and documentation lacking a bit. Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Dynamic Routing and TLS
Hi, I have been using the drouting module to route SIP requests from my customers to various carriers. This have been working great over the years, but now I want to upgrade one of the trunks to TLS and there seem to be no way to specify transport for a dr gateway. I tried to use attributes in the dr_gateways table to mark a gateway as TLS-enabled, but this does not help much. I am stuck at the gateway monitoring. First, due to https://github.com/OpenSIPS/opensips/issues/2057 I cannot read the gateway attributes in the 'local_route'. Even if that is fixed, it seems I am not able to force TLS transport there. Even after I add 'transport=tls' to the request URI ($ru = $ru + ";transport=tls";) the request still goes over UDP. I have not yet tried to disable the probing and try routing actual requests, but I am afraid I will have similar issued in the 'route' script. I do have t_relay() there as an option to force TLS, though. Is there any known way to use drouting with TLS and with automated gateway probing/disabling? Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [RFC] migration to GIT
On Tue, 19 Feb 2013 15:45:01 +0100 Saúl Ibarra Corretgé wrote: > > - file download system > > Sort of. You can't upload files, but it will generate tar files for > each tag. So it is not very suitable for real releases. There is no way to include generated files that should not go to the repository (like the 'configure' script) and getting the filenames right and download URL nice (important for distribution packagers) is tricky. > > - news system > > Nope. There is a wiki and mechanism to host own static web pages. May be enough for simple news and documentation. > Looks likt there are 3 things missing: > > - News: IMHO that belongs to the project website, not the place where > the code is hosted, so this would not be a problem. I don't think an open software maintainer should need to worry about maintaining a website with news/forums. Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] snmpstats: no OutRequests, but many InResponses
On Mon, Dec 17, 2012 at 11:56:48PM +0400, Bogdan-Andrei Iancu wrote: > If you do: > > opensipsctl fifo get_statistics core: # opensipsctl fifo get_statistics core 404 Statistics Not Found > what do you see for : > rcv_requests > rcv_replies > fwd_requests > fwd_replies # opensipsctl fifo get_statistics all | grep ^core core:rcv_requests = 32 core:rcv_replies = 45 core:fwd_requests = 0 core:fwd_replies = 0 [...] at the same time SNMP gives: OPENSER-SIP-COMMON-MIB::openserSIPSummaryOutRequests.0 = Counter32: 0 OPENSER-SIP-COMMON-MIB::openserSIPSummaryInResponses.0 = Counter32: 45 OPENSER-SIP-COMMON-MIB::openserSIPSummaryInRequests.0 = Counter32: 32 OPENSER-SIP-COMMON-MIB::openserSIPSummaryOutResponses.0 = Counter32: 72 > Also, in your script, do you do stateful (via TM t_xxx) or stateless > (core via forward() ) processing for your calls ? stateful Greets, Jacek > On 12/15/2012 10:16 PM, Jacek Konieczny wrote: > > Hi, > > > > I am setting up OpenSIPs server monitoring using SNMP, first at a > > hardly-used test server. And two values made me wonder: > > > > $ snmpwalk -v 2c -c public localhost > > OPENSER-SIP-COMMON-MIB::openserSIPSummaryOutRequests ; \ > >snmpwalk -v 2c -c public localhost > > OPENSER-SIP-COMMON-MIB::openserSIPSummaryInResponses > > OPENSER-SIP-COMMON-MIB::openserSIPSummaryOutRequests.0 = Counter32: 0 > > OPENSER-SIP-COMMON-MIB::openserSIPSummaryInResponses.0 = Counter32: 441 > > > > How can it be the server sends no requests and gets many responses? Is > > such behaviour expected (like more outgoing responses than incoming > > requests) or is it some kind of bug? If a bug, then is it in snmpstats or > > in my configuration? > > > > Greets, > > Jacek > > > > ___ > > Users mailing list > > Users@lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] snmpstats: no OutRequests, but many InResponses
Hi, I am setting up OpenSIPs server monitoring using SNMP, first at a hardly-used test server. And two values made me wonder: $ snmpwalk -v 2c -c public localhost OPENSER-SIP-COMMON-MIB::openserSIPSummaryOutRequests ; \ snmpwalk -v 2c -c public localhost OPENSER-SIP-COMMON-MIB::openserSIPSummaryInResponses OPENSER-SIP-COMMON-MIB::openserSIPSummaryOutRequests.0 = Counter32: 0 OPENSER-SIP-COMMON-MIB::openserSIPSummaryInResponses.0 = Counter32: 441 How can it be the server sends no requests and gets many responses? Is such behaviour expected (like more outgoing responses than incoming requests) or is it some kind of bug? If a bug, then is it in snmpstats or in my configuration? Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Is auth_db calculate_ha1 parameter documentation wrong?
From
http://www.opensips.org/html/docs/modules/1.8.x/auth_db.html#id250014 :
> 1.3.6. calculate_ha1 (integer)
>
> This parameter tells the server whether it should use plaintext
> passwords or a pre-calculated HA1 string for authentification.
>
> If the parameter is set to 1 and the username parameter of credentials
> contains also “@domain” (some user agents append the domain to the
> username parameter), then the server will use the HA1 values from the
> column specified in the “password_column_2” parameter. If the username
> parameter doesn't contain a domain, the server will use the HA1 values
> from the column given in the “password_column”parameter.
>
> If the parameter is set to 0 then the HA1 value will be calculated from
> the column specified in the “password_column” parameter.
Isn't that the other way round?
I have:
modparam("auth_db", "calculate_ha1", 1)
modparam("auth_db", "password_column", "password")
…'password' column contains the plain password and it works, although it
should not according to the documentation. The source code also looks
like the pre-computed HA1 values are used when calculate_ha1=0.
Greets,
Jacek
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Why is UTF-8 forbidden in the MySQL database?
Hello, I have seen this topic discussed already, but with no definitive answer or reasonable argument for keeping it as it is. http://lists.opensips.org/pipermail/users/2009-March/004107.html http://lists.opensips.org/pipermail/users/2010-September/014723.html opensipsctl will refuse to use UTF-8 charset in the database, although SIP is UTF-8 based and this is a natural choice. This is not a problem as long as MySQL ignores actual data encoding and no other application is sharing the same database, but I am trying to add a Django-base web UI to our SIP proxy and Django, like any other modern framework is encoding-aware and use Unicode internally. I can probably make it work with the data in OpenSIPS table, but still this looks like waiting for a de aster -- OpenSIPS stores UTF-8 strings (as they appear in the SIP requests) in a 'latin1' tables without any conversion. If anything else tries to convert this from the declared latin1 to Unicode problems will appear. The 'latin1' is transparent is not an answer. For storing opaque binary data there are binary data types. For storing UTF-8 strings there is the UTF-8 encoding. Now the questions: are there known problems to be expected if I switch the database encoding to the proper 'utf8'? Does OpenSIPS ever do any encoding transformation (to put 'latin1' data to the database)? Can I expect all the strings in the database are UTF-8 if they came UTF-8 in SIP request or could they have been truncated or in other way destroyed by OpenSIPS? Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Topology hiding, media proxy and the SDP o= line
Hello,
I have an opensips with mediaproxy configured as a SIP gateway between
our PBXes and PSTN trunk providers. I would like to hide our internal
network topology, though I would prefer not to change whole
configuration to B2B. Opensips 1.7 provided the topology_hiding()
function in the dialog module, which mostly does the trick.
Though, a simple detail remained in our requests, that I don't like
– the original IP address in the 'o=' line of the request SDP body ('c='
line is already modified for the media proxy).
Is there any way to do anything about this? It seems this IP address
does not provide any important information.
Greets,
Jacek
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Is OpenSIPS 1.8 still 'beta'
Hello, OpenSIPs 1.8.0 release has been announced some a while ago, so I was considering an upgrade, but when trying to download it I found this: http://opensips.org/pub/opensips/1.8.0/src/opensips-1.8.0-beta_src.tar.gz How should I understand this '-beta' suffix? Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] IPv6<->IPv4, mediaproxy, rtpproxy
Hello, We use opensips with Mediaproxy and CDRTool on our VoIP gateway.We will be introducing IPv6 in our infrastructure too and I would also like to have SIP connectivity available for IPv6. Our upstream SIP links are IPv4 only, so we will need some kind of IPv6 to IPv4 gateway. AFAIK opensips can do IPv6, but Mediaproxy cannot, and due to its design (using Linux kernel connection tracking for media forwarding) it will probably never be able to forward IPv4 media to IPv6. It seem I could use RTPProxy as a IPv4<->IPv6 media gateway, but I cannot replace mediaproxy with rtpproxy, as we rely on the latter for accounting (CDRTool). It seems I would need to use rtpproxy in addtion to mediaproxy… My question is: is that possible at all? I guess it would be possible if I use two opensips instances – the current one for accounting and upstream connectivity and another one, together with rtpproxy, as the IPv4<->IPv6 gateway. Any hints for implementing this? Have anybody done IPv4<->IPv6 with opensips and rtpproxy? Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS failover
On Thu, May 06, 2010 at 12:16:52AM +0530, rajib deka wrote: > I have seen that heartbeat is supporting box level failure but not service > level failure. Means if the box itself is down heartbeat will activate the > VIP of back up server, but if OpenSIPS service is down heartbeat will not > activate backup VIP. If you use Heartbeat with Pacemaker, then you have full service-level control of your HA cluster. Pacemaker does service monitoring and service control – it could, on the OpenSIPs failure, try to restart it, try to start a different instance on the same node or initiate fail-over to other node or nodes. Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] NAT and ACK (private IP/domain)
On Thu, Apr 23, 2009 at 07:50:06PM +0300, Bogdan-Andrei Iancu wrote:
> The ACK will be routed based on Route + RURI info. Route hdr made the
> ACK to get to .201 and the RURI will continue to .71. The RURI from ACK
> is taken from the Contact hdr of the 200 OK reply.
That is true, but Contact header may get corrupted in the way. I was
troubleshooting a NAT & ACK problem today too.
My setup was two SIP ATAs behind a NAT connecting via two chained
opensips proxies (with mediaproxy at one of them).
ATA1 --{NAT}--> PROXY1 --> PROXY2 --{NAT}--> ATA2
And that is what I found:
1. First, I did not have fix_contact() in onreply_route. So, the call
was nearly established, the called party (ATA2) responded with "200 OK",
but it never received the ACK, as it was sent (by PROXY2) to a private
address instead of NAT public IP. The private address was taken by ATA1
from the Contact header of the "200 OK" response.
2. I have added:
if (client_nat_test("3")) {
fix_contact();
}
To both proxy opensips.cfg onreply_route. The same code was used in the
main route. This didn't help much, as the called party still didn't
receive its ACK. This time it was not sent to the private IP, but to the
proxy.
After inspecting the traffic I found out, that both proxies had replaced
Contact header in the "200 OK" response. PROXY2 did it right: replaced
ATA2 private IP with the IP message was received from, so Contact was
valid. But the other proxy rewritten it again, replacing the public NAT
IP with the IP of PROXY2. This caused the ACK to loop inside PROXY2
instead of being sent to ATA2.
It seem client_nat_test("3") in onreply_route matches even if request
came directly (no NAT) from another proxy, which had already do the NAT
fix on Contact. This doesn't seem to be the same way in main route
block.
3. I have replaced client_nat_test("3") with client_nat_test("1") and
this solved the problem.
Greets,
Jacek
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] How to run opensips in the foreground
On Mon, Apr 06, 2009 at 07:31:57PM +0300, Bogdan-Andrei Iancu wrote: > Hi John, > > setting "fork=no" is not an option (you have only one UDP interface, no > TCP, no TLS) > > I think it is an issue with upstart..there are many other apps that > fork at startup... And this fork is just workaround for the issues with SysV-init based systems… The fork is a method to make the init process take care of a daemon. With upstart (and other supervisors, like e.g. daemon-tools) no such magic is need (the init process or supervisor starts the daemon process itself and tries to control it) and the forking only makes things more difficult. upstart 0.5 can handle forking daemons, but that is just a workaround. 'Going into background' should be just an option of services. I would be happy when opensips can properly run in foreground, too. Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_mysql error, crash
On Fri, Apr 03, 2009 at 05:46:30PM +0300, Bogdan-Andrei Iancu wrote: > So, the fix is available on SVN - update and give it another try - it > should work (at least for me it did). I have applied the fix to our opensips server today and, indeed, the bug seems fixed. Thanks a lot! I love that kind of support to Open Source projects. Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_mysql error, crash
On Fri, Mar 27, 2009 at 11:53:47AM +0100, Iñaki Baz Castillo wrote: > 2009/3/27 Jacek Konieczny : > > Hello, > > > > On Wed, Mar 25, 2009 at 09:36:42AM -0400, Jeff Pyle wrote: > >> I woke up this morning to this on Opensips 1.5.0: > > > > Core was generated by `opensips'. > > Program terminated with signal 11, Segmentation fault. > > #0 0xb7b673bd in mysql_stmt_result_metadata (stmt=0x828cb50) at > > libmysql.c:2254 > > 2254 result->methods= stmt->mysql->methods; > > This issue was close but I've also experimented it in the latest version: > > https://sourceforge.net/tracker/?func=detail&aid=2713968&group_id=232389&atid=1086410 No I know how to reproduce it: just restart MySQL while opensips is running. It will soon crash at the very same place. Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_mysql error, crash
Hello, On Wed, Mar 25, 2009 at 09:36:42AM -0400, Jeff Pyle wrote: > I woke up this morning to this on Opensips 1.5.0: The log: Mar 27 08:22:52 gtw1-ms opensips[14929]: ERROR:core:re_init_statement: failed while mysql_stmt_prepare: Unknown prepared statement handler (3) given to mysql_stmt_close Mar 27 08:22:52 gtw1-ms opensips[14929]: ERROR:core:db_mysql_do_prepared_query: failed to re-init statement! Mar 27 08:22:52 gtw1-ms opensips[14929]: ERROR:core:acc_db_request: failed to insert into database Then two requests handled and: Mar 27 08:23:14 gtw1-ms opensips[14949]: CRITICAL:core:receive_fd: EOF on 10 Mar 27 08:23:14 gtw1-ms opensips[14914]: INFO:core:handle_sigs: child process 14931 exited by a signal 11 Mar 27 08:23:14 gtw1-ms opensips[14914]: INFO:core:handle_sigs: core was generated Mar 27 08:23:14 gtw1-ms opensips[14914]: INFO:core:handle_sigs: terminating due to SIGCHLD Mar 27 08:23:14 gtw1-ms opensips[14925]: INFO:core:sig_usr: signal 15 received Mar 27 08:23:14 gtw1-ms opensips[14937]: INFO:core:sig_usr: signal 15 received And what GDB shows on the core file: Core was generated by `opensips'. Program terminated with signal 11, Segmentation fault. #0 0xb7b673bd in mysql_stmt_result_metadata (stmt=0x828cb50) at libmysql.c:2254 2254 result->methods= stmt->mysql->methods; (gdb) bt #0 0xb7b673bd in mysql_stmt_result_metadata (stmt=0x828cb50) at libmysql.c:2254 #1 0xb7cb6f43 in db_mysql_do_prepared_query (conn=0x8191f38, query=0xb7ccdf08, v=0xbfde5608, n=1, uv=0x0, un=0) at dbase.c:432 #2 0xb7cb84a7 in db_mysql_query (_h=0x8191f38, _k=0xbfde5638, _op=0x0, _v=0xbfde5608, _c=0x8195ed0, _n=1, _nc=2, _o=0x0, _r=0xbfde5654) at dbase.c:676 #3 0xb79d6e72 in authorize (_m=0x8194948, _realm=, _table=, _hftype=HDR_AUTHORIZATION_T) at authorize.c:107 #4 0x08054ba3 in do_action (a=0x8183a60, msg=0x8194948) at action.c:962 #5 0x08053903 in run_action_list (a=0x8183a60, msg=0x8194948) at action.c:139 #6 0x08096a57 in eval_expr (e=0x8183ac8, msg=0x8194948, val=0x0) at route.c:1189 #7 0x080965c5 in eval_expr (e=0x8183af0, msg=0x8194948, val=0x0) at route.c:1502 #8 0x08096602 in eval_expr (e=0x8183b18, msg=0x8194948, val=0x0) at route.c:1507 #9 0x08054bd2 in do_action (a=0x8184460, msg=0x8194948) at action.c:689 #10 0x08053903 in run_action_list (a=0x8184460, msg=0x8194948) at action.c:139 #11 0x080571c9 in do_action (a=0x81844c8, msg=0x8194948) at action.c:712 #12 0x08053903 in run_action_list (a=0x8182c80, msg=0x8194948) at action.c:139 #13 0x08057f27 in run_top_route (a=0x8182c80, msg=0x8194948) at action.c:119 #14 0x0808b951 in receive_msg ( buf=0x8157be0 "REGISTER sip:sip-gtw1.axeos.nl SIP/2.0\r\nVia: SIP/2.0/UDP 83.98.196.74:5060;branch=z9hG4bK4aa5f9e2;rport\r\nFrom: ;tag=as14f8aa61\r\nTo: \r\n"..., len=671, rcv_info=0xbfde6544) at receive.c:165 #15 0x080bf625 in udp_rcv_loop () at udp_server.c:449 #16 0x08069e99 in main (argc=1, argv=0xbfde6704) at main.c:779 (gdb) print stmt->mysql $2 = (MYSQL *) 0x0 (gdb) up #1 0xb7cb6f43 in db_mysql_do_prepared_query (conn=0x8191f38, query=0xb7ccdf08, v=0xbfde5608, n=1, uv=0x0, un=0) at dbase.c:432 432 CON_RESULT(conn) = mysql_stmt_result_metadata(ctx->stmt); Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] UTF8 in MySQL database
On Wed, Mar 25, 2009 at 08:15:51AM +0200, Dan Pascu wrote: > On Tuesday 24 March 2009, Jacek Konieczny wrote: > > As I was just doing upgrade from OpenSIPs 1.4.4 to 1.5.0 I took a look > > at the database and found out it was latin1-encode. I didn't like it > > much (if any non ASCII characters are supposed to be allowed in the > > database then why should it be limited to only a few languages in the > > world?). > > Latin-1 is 8 bit transparent. So you can throw at it whatever you like and > it will get you back exactly what you put in, without having to worry > what the input encoding is. ... as long as every application connected to this database is enconding-ignorant and would treat 'latin1' as just a binary string. And that is not a sane way to do things. The problems will start as soon as someone will try to process this data as 'latin1' (according to the declaration on the database), when it is not latin1. > UTF-8 requires you that your input in already formatted UTF-8. But then you know what you have in the database. > > What is the reason for rejecting UTF8? No other setting seems to make > > much sense in an international environment. > > I disagree. Many other settings make sense in an international environment > and latin-1 is the most transparent of them. Then why don't we drop all primary keys, foreign keys and other constraints from the database? Then it would be even more transparent -- we could put anything there. Putting non-latin1 strings in a "latin1" table is like putting non-unique values in an UNIQUE column. Even if the RDBMS in use would not care, it won't seem right. But, back to my original question, as can understand that 'latin1' is ok for some or even most people. My my question was: is there any specific, technical reason, that 'utf8' is forbidden? I don't think OpenSIPs does any SQL queries when multibyte strings would be a problem (like asking for 3 characters only and expecting 3 bytes in the result). I don't know MySQL well (just forced to use it because of CDRTool limitations), but I don't think it would cause any serious problems with that, either. Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] UTF8 in MySQL database
Hello, As I was just doing upgrade from OpenSIPs 1.4.4 to 1.5.0 I took a look at the database and found out it was latin1-encode. I didn't like it much (if any non ASCII characters are supposed to be allowed in the database then why should it be limited to only a few languages in the world?). I have found out that opensipsdbctl reads the MySQL server default charset setting, so I have changed it to utf8… only to find out, that: „WARNING: Your current default mysql characters set cannot be used to create DB. Please choice another one from the following list:” What is the reason for rejecting UTF8? No other setting seems to make much sense in an international environment. Fortunately, most data in the database is not supposed to be human-readable and I can live with ASCII encoding only. I am just wondering where this limitation comes from. Greets, Jacek ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
