[SR-Users] Several BYEs conveying Kamailio

Maciej Bylica mbsip at gazeta.pl
Sat Jul 10 17:29:22 CEST 2010


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



More information about the sr-users mailing list