No subject

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.