Thanks So does it mean that placing t_check_trans() inside loose_route() part of the script should solve my issue? Of course i do have record_route() for all non-REGISTER messages. Thx, Maciej. 2010/7/9 Alex Balashov <abalashov@evaristesys.com>:
If the BYEs are genuine retransmissions, they should be dampened using t_check_trans() before they are processed by TM and therefore ACC.
On 07/09/2010 08:03 AM, Maciej Bylica wrote:
Dear ALL,
I have configured Kamailio 1.5 from svn with radius (radiusclient-ng) support for acc. All seem to work okay, except one thing. From time to time I am receiving following radius error (debug from radius server on different ip) Fri Jul 9 12:22:58 2010 : Error: rlm_sql (sql): Couldn't update SQL accounting STOP record - Column 'AcctStartTime' cannot be null Fri Jul 9 12:23:08 2010 : Error: rlm_sql (sql): Couldn't update SQL accounting STOP record - Column 'AcctStartTime' cannot be null Fri Jul 9 12:23:18 2010 : Error: rlm_sql (sql): Couldn't update SQL accounting STOP record - Column 'AcctStartTime' cannot be null
A few lines from radiusclient.conf # time to wait for a reply from the RADIUS server radius_timeout 10 # resend request this many times before trying the next server radius_retries 3
After closer look at this, it turned out that there is one START request and four STOPs with the same CallID (Acct-Session-Id). START and first STOP are treated as a pair, the next ones are odd.
Taking about sip i do have following scenario: MGW(1)---Kamailio(2)---SIP_Provider(SER based)(3) The call flow that generate aforemtioned errors looks like below (debug on kamailio) 1 - (2) is receiving INVITE from (3) 2 - (2) is sending Giving a Try to (3) 3 - (2) is sending INVITE to (1) 4 - (2) is receiving Trying from (1) 5 - (2) is receiving Ringing from (1) 6 - (2) is receiving OK from (1) 7 - (2) is sending OK to (3) 8 - (2) is receiving ACK from (3) 9 - (2) is sending ACK to (1) ---- call---- 10 - (2) is receiving BYE from (1) (tearing down from (1) side, STOP radius request is generated) 11 - (2) is sending BYE to (3) 12 - (2) is receiving BYE from (3) (second STOP is generated, radius_retries 3, radius_timeout 10) 13 - (2) is sending BYE to (1) 14 - (2) is receiving OK from (1) 15 - (2) is sending OK to (3) 16 - (2) is receiving OK to (3) 17 - (2) is sending OK to (1)
For sure there is sth wrong with SIP_Provider but how Kamilio should behave is such situation. Should second BYE (p.12) with the same callid as in p.10 be continued with p.13?
Thanks in advance, Maciej.
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users