<div dir="ltr">agreed. the design of the db and queries are all properly tested, with only milliseconds of query time even for tables as large as millions of rows. i wanted to implement this only for insurance and was wondering if it's doable, theoretically speaking.<div>
<br></div><div>the timer module is promising although lacks dynamic assignment of timeouts. what i have in mind is:</div><div>  - do a timer_enable() after receiving an INVITE. </div><div>  - on timeout, go to rourte[timeout], statelessly send a cancel to callee(if applicable) and 408 to caller.</div>
<div>  - OR upon getting a 200 OK from the callee's leg, disable the timer.</div><div>  - do you think this is worthy of a feature request? something like timer_enable(timer_id, enable_disable, timeout)</div></div><div class="gmail_extra">
<br clear="all"><div>Kelvin Chua</div>
<br><br><div class="gmail_quote">On Thu, Jan 2, 2014 at 2:46 PM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 01/02/2014 01:39 AM, Kelvin Chua wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
those timers are for INVITES sent by kamailio right? starting from<br>
t_relay() of the INVITE<br>
what i am looking for is, when i receive an INVITE, i start counting.<br>
</blockquote>
<br></div>
TM's timers - and anything else TM does - are reliant on a transaction existing.  A transaction is not created until t_relay() is called.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the reason behind is, with all the functions involving several<br>
sql_xquery() involved to find out where to send the t_relay(),<br>
there will be unforeseen delays which might cause a very high PDD for my<br>
callers, i don't want them to wait.<br>
</blockquote>
<br></div>
Even if you had such a timer fire, your database query would still block the SIP worker thread that's handling the request route.<br>
<br>
If you have database calls that could get hung for several hundred milliseconds, or even worse, several seconds, the solution to this problem is to fix your architecture and your database calls. Bluntly speaking, you're doing it wrong. No database calls or other external calls upon which Kamailio relies for call processing should be taking long enough to execute that PDD concerns are warranted, or that you should need timers to deal with them.<span class="HOEnZb"><font color="#888888"><br>

<br>
-- Alex</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Alex Balashov - Principal<br>
Evariste Systems LLC<br>
235 E Ponce de Leon Ave<br>
Suite 106<br>
Decatur, GA 30030<br>
United States<br>
Tel: <a href="tel:%2B1-678-954-0670" value="+16789540670" target="_blank">+1-678-954-0670</a><br>
Web: <a href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.alexbalashov.com/" target="_blank">http://www.alexbalashov.com/</a><br>
<br>
______________________________<u></u>_________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/<u></u>cgi-bin/mailman/listinfo/sr-<u></u>users</a><br>
</div></div></blockquote></div><br></div>