[SR-Users] Several BYEs conveying Kamailio
Maciej Bylica
mbsip at gazeta.pl
Sun Jul 11 19:08:33 CEST 2010
I think my script is pretty much standard one:
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
if (!method=="REGISTER")
record_route();
else {
sl_send_reply("488","Not Acceptable Here");
exit;
}
if (loose_route()) {
if (is_method("BYE"))
{
#Account BYE transaction
setflag(2);
}
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
if (is_method("INVITE")) {
if (allow_source_address("1")) {
if (from_uri=~"sip:112233 at .*") {
$var(origin) = "from_sip1";
}
else if (from_uri=~"sip:44.*@.*") {
$var(origin) = "from_sip2";
}
else {
$var(origin) = "from_sip3";
}
}
else if (allow_source_address("2")) {
$var(origin) = "from_pstn1";
}
else {
sl_send_reply("403", "Forbidden");
exit;
};
if (!load_gws("$var(origin)")) {
sl_send_reply("503", "Unable to load gateways");
exit;
}
if (!next_gw()) {
sl_send_reply("503", "Unable to find a
gateway");
exit;
}
setflag(2);
setflag(3);
route(1);
exit;
};
t_check_trans();
if (!uri==myself) {
sl_send_reply("488","Not Acceptable Here");
exit;
}
if (uri==myself) {
route(1);
exit;
};
# requests for my domain
if ($rU==NULL) {
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
};
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
};
t_release();
}
route[1] {
t_on_reply("1");
t_on_failure("11");
if (!t_relay()) {
sl_reply_error();
};
exit;
}
onreply_route[1] {
if(!t_check_trans()) {
drop;
}
setflag(2);
}
######################
# "default" failover #
######################
failure_route[11] {
# In case of failure, send it to an alternative route:
if (t_check_status("415|408|404|5[0-9][0-9]")) {
if (!next_gw()) {
t_reply("503", "Service not available, no more
gateways");
exit;
}
else {
t_on_failure("11");
setflag(2);
t_relay();
}
exit;
}
}
Could sb tell me where i made a mistake/how to modify the script to
drop BYEs I've mentioned.
Thanks in advance,
Maciej
2010/7/10 Maciej Bylica <mbsip at gazeta.pl>:
> 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