[SR-Users] TM question

[Alex Balashov]

Daniel,

Thank you.  In that case, perhaps I should ask the question differently:

Why would the relay not be happening in this situation?

Cheers,

-- Alex

On 09/07/2010 03:02 PM, Daniel-Constantin Mierla wrote:

> Hi Alex,
>
> this warning is given when the transaction is created but no stateful
> reply or relay was done.
>
> Cheers,
> Daniel
>
>
> On 9/7/10 6:41 PM, Alex Balashov wrote:
>> 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/