[SR-Users] TM question

[Daniel-Constantin Mierla]

  Hello,

have you added some xlogs to see where it ends the execution for that case?

If you can run the config with devel version, then load debugger module 
and enable execution trace.

Cheers,
Daniel

On 9/7/10 9:42 PM, Alex Balashov wrote:
> 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,
>>>
>>
>
>

-- 
Daniel-Constantin Mierla
http://www.asipto.com