10 Jul
2010
10 Jul
'10
11:29 a.m.
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(a)evaristesys.com>om>:
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users