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