[SR-Users] Several BYEs conveying Kamailio

[Alex Balashov]

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 at 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/