[SR-Users] INVITE Retransmission Causes Limiting Simultaneus Calls for Subscribers

Bayram Karagoz karagoz.bayram at gmail.com
Tue Feb 12 10:12:38 CET 2013


Thanks for quick response Daniel,

My kamailio version is 3.2.3 (x86_64/linux) .
I want to use dlg_manage() before but not sure which side of my call
limitation route code block.
can you advise me where to use dlg_manage() in my routing?
here is my route block defined below;


route[QUOTA] {

        if (is_method("INVITE") && $fU == $avp(s:username)) {

        avp_db_query("select quota from subscriber where
username='$avp(s:username)'", "$avp(s:quota)");

        $var(SIZE) = 0;
        get_profile_size("callquota", "$avp(s:username)", "$var(SIZE)");
                xlog("L_INFO", "CALL_KAMAILIO:Call originated from =
$fd\n");
                xlog("L_INFO", "Active call amount for $fU is $var(SIZE) ,
call-id=$ci, quota=$avp(s:quota)\n");
        if( $var(SIZE) >= $avp(s:quota) ){
               sl_send_reply("403", "Simultaneous calls limit reached");
               xlog("L_INFO", "QUOTA:Limit of $var(SIZE) active calls has
been reached for user=$avp(s:username), call-id=$ci,
quota=$avp(s:quota)\n");
               exit;
        }
        set_dlg_profile("callquota","$avp(s:username)");
        }
}


2013/2/12 Daniel-Constantin Mierla <miconda at gmail.com>

>  Hello,
>
> what version of kamailio are you using?
>
> State 1 is for dialogs that were not relayed (or they haven't received any
> reply yet). That means you create the dialog and don't relay the INVITE.
> Try to us dlg_manage() just before relaying the INVITE.
>
> Cheers,
> Daniel
>
>
> On 2/12/13 9:37 AM, Bayram Karagoz wrote:
>
> Hi,
>
>  is there any advise about my problem?
> I'm using kamailio in my production environment and this issue started to
> reproduce a lot.
> is there any way to discard retransmitted INVITE messages from counting
> dialog?
>
>
> 2013/2/9 Bayram Karagoz <karagoz.bayram at gmail.com>
>
>>  thanks for the response Daniel,
>>
>>  has_totag not solved my problem.
>>
>>  in a deep search I realized that these retransmission INVITE dialogs
>> are waiting in dialog list as state = 1. one example is below;
>> is there any way to clear these dialog which state is waiting for state =
>> 1 or any other solution is welcome for me?
>>
>>  dialog::  hash=246:499719317
>>         state:: 1
>>         ref_count:: 1
>>         timestart:: 0
>>         timeout:: 0
>>         callid:: 1356619-3569384775-474862 at GBSBC-1.mydomain.com
>>         from_uri:: sip:02165151057 at xxx.xxx.xxx.xxx
>>         from_tag:: 3569384775-474868
>>         caller_contact:: sip:02165151057 at xxx.xxx.xxx.xxx:5060
>>         caller_cseq:: 2
>>         caller_route_set::
>>         caller_bind_addr:: udp:xxx.xxx.xxx.xxx:5060
>>         callee_bind_addr::
>>         to_uri:: sip:4115667 at xxx.xxx.xxx.xxx
>>         to_tag::
>>         callee_contact::
>>          callee_cseq::
>>         callee_route_set::
>>
>>
>>
>>
>> 2013/2/4 Daniel Tryba <daniel at pocos.nl>
>>
>>> On Sunday 03 February 2013 12:58:02 Bayram Karagoz wrote:
>>> > I'm trying to limit all subscriber's active call according to setting
>>> their
>>> > simultaneous use setting defined in database.
>>> > But having problem when one subscriber's INVITE message goes to
>>> > retransmission. When retranmission occures INVITE messages don't
>>> complete
>>> > with BYE and subscriber simultaneus use amount will hung.
>>> > My example code block is below.
>>> > Does anyone advice me for overcome INVITE retransmissions?
>>>
>>>  I haven't implemented it myself yet, but all examples I've seen check
>>> for
>>> !has_totag() in the INVITE when doing call limit accounting. So
>>> if (is_method("INVITE") && $fU == $avp(s:username) && !has_totag())
>>> in your case. But that only works if the device received the initial 100
>>> Trying with a tag from Kamailio.
>>>
>>> But might it not be better to just do the count in the INVITE and
>>> adding/deleting of dialogs in the dialog event routes?
>>> http://kamailio.org/docs/modules/stable/modules_k/dialog.html#id2556156
>>> Problem here is that if the limit is 5 and and there are more than 5
>>> concurrent INVITES you'd have to drop calls with a 200 OK response.
>>>
>>> --
>>>
>>> POCOS B.V. - Croy 9c - 5653 LC Eindhoven
>>> Telefoon: 040 293 8661 - Fax: 040 293 8658
>>> http://www.pocos.nl/   - http://www.sipo.nl/
>>> K.v.K. Eindhoven 17097024
>>>
>>
>>
>>
>>   --
>>  *Bayram KARAGÖZ*
>>
>> *NGN Engineer*
>>
>> *-----------------------------------------*
>>
>> *@*   bayram at bayramkaragoz.org
>>
>> *:**  *www.bayramkaragoz.org
>>
>> *-----------------------------------------*
>>
>
>
>
>  --
>  *Bayram KARAGÖZ*
>
> *NGN Engineer*
>
> *-----------------------------------------*
>
> *@*   bayram at bayramkaragoz.org
>
> *:**  *www.bayramkaragoz.org
>
> *-----------------------------------------*
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio World Conference, April 16-17, 2013, Berlin
>  - http://conference.kamailio.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
>
>


-- 
*Bayram KARAGÖZ*

*NGN Engineer*

*-----------------------------------------*

*@*   bayram at bayramkaragoz.org

*:**  *www.bayramkaragoz.org

*-----------------------------------------*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130212/78aa1cb7/attachment-0001.htm>


More information about the sr-users mailing list