### Description While upgrading to kamailio version 5.5.2 I noticed that the sip reason is not always filled in correctly. In our current setup with kamailio version 4.4 the acc module writes the INVITE, ACK end BYE messages to a postgres database. Also the missed calls are logged. With version 5.5.2 but also with version 5.5.3 the sip reason seems to contain a random 2 digits. It gets even worse when a call is missed and kamailio generates a 408 timeout. Then a random string of 15 characters is written to the database. Sometimes this results in a fatal error because the postgres driver can't escape the string. ### Troubleshooting The relevant part in de code is in the function env_set_code_status in file acc_logic.c if (reply==FAKED_REPLY || reply==NULL) { /* code */ acc_env.code_s.s = int2bstr((unsigned long)code, code_buf, &acc_env.code_s.len); /* reason */ if (acc_env.reason.len == 0) { /* already extracted in case of locally generated replies */ acc_env.reason.s = error_text(code); acc_env.reason.len = strlen(acc_env.reason.s); } The sip reason is only filled in when the len is 0, but once the length is set it looks like it's not being reset to 0 again somewhere. I can fix the problem by removing the if statement, but that is probably not the intention of the programmer. #### Reproduction The wrong reason in the ACK can probably be reproduces with any call, but in my test setup an Asterisk system answers the call. After the "OK" an ACK is received which is seen as a FAKED_REPLY. The reason.len however is still 2 and the reason is not set. The new function "env_set_reason" is not being called in this case. The issue with the 408 can be reproduced by calling an endpoint and let kamailio timeout. This has to be done twice to reproduce the error. This time kamailio wants to write the missed INVITE to the database with a random string of 15 characters for the sip reason. To me it looks like the length of 15 comes from the length of the "Request Timeout" string but the pointer reason.s point to a memory part of a previous transaction which is already gone ? #### Debugging Data #### Log Messages #### SIP Traffic ### Possible Solutions ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.5.2 (x86_64/linux) 55e232 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 55e232 compiled on 15:45:52 Dec 9 2021 with gcc 8.3.0 ``` * **Operating System**: ``` Linux 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2981 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/2981(a)github.com>