THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#327 - bugs in uac_redirect module
User who did this - Federico Cabiddu (lester)
----------
Hi Daniel,
this part is a workaround for when acc_db_set_table_name is called with tables which have different name length.
The db_table_name_buf is static and it's copied (as a pointer) into acc_env.text which is then used to call use_table.
In my case I am using db_flatstore so it's flat_use_table which is …
[View More]being called.
I have db accounting enabled for calls and for missed calls, and I have as table names "completed_calls" and "acc" (default one for uac_redirect).
When get_redirects is called for the first time the db accounting is called with "acc" as table name, db_table_name_buf contains "acc", the id for the pool is created with this table name and everything is fine.
Then once the call is answered the db accounting is called again, this time with "completed_calls" as table name, db_table_name_buf contains the good value but, at the same time the previous id contains the new table value.
Now at the next redirection, even if the table name is "acc" db_table_name_buf contains "accleted_calls" and all the id created using db_table_name_buf are changed and, due to the way the ids are created and compared, the CDRs is written in the "completed_calls" file.
So, putting '\0' at the end of the buffer helps at least to have the correct table name and to write to the correct file.
It's a rough solution.
Maybe the static db_table_name_buf can be avoided, as shown in the new attached patch.
Best regards,
Federico Cabiddu
----------
One or more files have been attached.
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=327#comment1029
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
[View Less]
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#328 - Parser doesn't eliminate linebreaks when logging bad packets, breaks syslog
User who did this - Sebastian Damm (sdamm)
----------
No I haven't. And in fact, those systems are running different debian versions, and thus different syslog-ng versions as well. Didn't think of syslog-ng as the source of the problems.
Could you please close this as "not a bug"?
----------
More information can be …
[View More]found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=328#comment1028
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
[View Less]
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#328 - Parser doesn't eliminate linebreaks when logging bad packets, breaks syslog
User who did this - Daniel-Constantin Mierla (miconda)
----------
I did a diff to relevant files between 3.1 and 4.0, respectively:
parser/msg_parser.c
dprint.c
dprint.h
Nothing was changed in regard to what you see. There was no stripping at any time of linebreaks from the message and the logging functions were not …
[View More]changed as well.
Have you run the two versions on the same host?
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=328#comment1027
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
[View Less]
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Sebastian Damm (sdamm)
Attached to Project - sip-router
Summary - Parser doesn't eliminate linebreaks when logging bad packets, breaks syslog
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - Low
Priority - Normal
Reported Version - 4.0
Due in Version - Undecided
Due Date - Undecided
Details - When sending …
[View More]broken packets to a Kamailio 4.0, the parser logs the complete packet. In Kamailio 3.1 it eliminated line breaks before logging, so that one line with the the packet was written to the correct logfile. In Kamailio 4.0 only the first line of the broken packet is written to the logfile, the rest of the packet is written to the main syslog file (probably since no syslog facility is specified).
Comparison:
Kamailio 3.1
kamailio.log
Jul 25 06:26:00 hostname /usr/sbin/kamailio[5452]: ERROR: <core> [parser/msg_parser.c:714]: ERROR: parse_msg: message=<REGISTER sip:Dach GXP2100 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.209:5468;branch=z9hG4bK1668961676;rport From: <sip:1234567e20@Dach GXP2100>;tag=1685573665 To: <sip:1234567e20@Dach GXP2100> Call-ID: 1720384019-5468-1(a)BJC.BGI.A.CAJ CSeq: 28699 REGISTER Contact: <sip:1234567e20@192.168.0.209:5468>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B823AFF6E>" X-Grandstream-PBX: true Max-Forwards: 70 User-Agent: Grandstream GXP2100 1.0.1.110 Supported: path Expires: 600 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0 >
Kamailio 4.0
kamailio.log
Jul 25 06:26:00 hostname /usr/sbin/kamailio[13036]: ERROR: <core> [parser/msg_parser.c:705]: parse_msg(): ERROR: parse_msg: message=<REGISTER sip:Dach GXP2100 SIP/2.0
syslog
Jul 25 06:26:00 hostname Via: SIP/2.0/UDP 192.168.0.209:5468;branch=z9hG4bK1668961676;rport
Jul 25 06:26:00 hostname From: <sip:1234567e20@Dach GXP2100>;tag=1685573665
Jul 25 06:26:00 hostname To: <sip:1234567e20@Dach GXP2100>
Jul 25 06:26:00 hostname Call-ID: 1720384019-5468-1(a)BJC.BGI.A.CAJ
Jul 25 06:26:00 hostname CSeq: 28699 REGISTER
Jul 25 06:26:00 hostname Contact: <sip:1234567e20@192.168.0.209:5468>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B823AFF6E>"
Jul 25 06:26:00 hostname X-Grandstream-PBX: true
Jul 25 06:26:00 hostname Max-Forwards: 70
Jul 25 06:26:00 hostname User-Agent: Grandstream GXP2100 1.0.1.110
Jul 25 06:26:00 hostname Supported: path
Jul 25 06:26:00 hostname Expires: 600
Jul 25 06:26:00 hostname Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Jul 25 06:26:00 hostname Content-Length: 0
Jul 25 06:26:00 hostname >
How to reproduce:
Configure Kamailio to log into a syslog facility, then send a broken packet to that kamailio.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=328
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
[View Less]
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#319 - Possible memory leak in srdb1
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Not a bug
Additional comments about closing: Re-open if having clear details pointing to the source code files and lines.
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=319
You are receiving this message because you have requested …
[View More]it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
[View Less]