Hi, I have a somewhat unusual log entry after some calls: Sep 3 09:12:23 kamgw01 /usr/local/sbin/kamailio[542]: WARNING: tm [t_lookup.c:1551]: WARNING: script writer didn't release transaction These calls fail in that they are processed instantly, but no time is ever given to receive a response from the upstream gateway. For instance, the above call's initial INVITE was received at 09:12:23, a final request URI was resolved, and then this message, all in < 1 second. Trace on upstream gateway shows that the initial request was never received from Kamailio. There is one additional aspect to how these calls are being processed in script that almost certainly has a bearing on this, though I don't know what it is: They are handled through a gateway route route called route[OUTBOUND-ROUTE-TRY] that is, under normal circumstances reflecting its name, initially called from the request route, and subsequently from a failure route meant to advance it. Normal operation mode is like this: route { ... route(OUTBOUND-ROUTE-TRY); } route[OUTBOUND-ROUTE-TRY] { if(dialog_count_of_vendor_gw < limit) { t_on_failure("OUTBOUND-ROUTE-FAILURE"); if(!t_relay()) { sl_reply_error(); } exit; } else { ... # Advance index of AVP array to next gateway, etc. # if(!t_lookup_request()) t_newtran(); route(OUTBOUND-ROUTE-TRY); exit; } } ... # Armed in OUTBOUND-ROUTE-TRY with t_on_failure(). failure_route[OUTBOUND-ROUTE-FAILURE] { ... # If we have more routes to retry, call # OUTBOUND-ROUTE-TRY again. route(OUTBOUND-ROUTE-TRY); } However, what is happening to cause this error is a little different from the usual scenario. On the initial attempt, the dialog limit check you see in OUTBOUND-ROUTE-TRY is failing, so the route adds a new transaction and calls itself again once. Now, the reason I am creating a new transaction is because in certain failure modes when a transaction was never created (like, if the call also fails on the next attempt), it is otherwise not possible to send a stateful failure reply to the originating endpoint from the failure route, which is a requirement (one cannot issue stateless replies from failure routes). So, because this routine is called both from the failure route and from the request route, I create a new transaction in order to make it possible to send stateful replies (t_reply()) from within this route regardless of the type of the parent route calling it, whether it is failure route or request route. So, again, what is happening in the scenario in which I get the above log message is: 1. INVITE is received 2. Master request route runs OUTBOUND-ROUTE-TRY request route 3. OUTBOUND-ROUTE-TRY checks gateway limit, finds it is exceeded 4. OUTBOUND-ROUTE-TRY checks request against existing transaction, and if not found, creates a new one with t_newtran() 5. OUTBOUND-ROUTE-TRY calls itself again. 6. OUTBOUND-ROUTE-TRY succeeds this time, but evidently, t_relay() fails with the above message, or above message appears sometime before t_relay() is called. Any insight is appreciated! Thanks, -- 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/