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 <abalas...@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 > _______________________________________________ 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
