[Kamailio-Devel] SIP reply

[Daniel-Constantin Mierla]

On 11/27/08 13:56, Andrei Pelinescu-Onciul wrote:
> On Nov 25, 2008 at 19:06, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>   
>> On 11/25/08 18:51, Klaus Darilion wrote:
>>     
>>> Daniel-Constantin Mierla wrote:
>>>       
>>>> Hello,
>>>>
>>>> in relation with this bug:
>>>>
>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2105813&group_id=139143&atid=743020 
>>>>
>>>>
>>>> we should get to a conclusion, so it gets fixed soon and tested till 
>>>> next release.
>>>>
>>>> I would go for a function in TM that will use sl module send reply if 
>>>> the transaction does not exist. Other opinions?
>>>>         
>>> What about importing the signaling module from opensips? It is a 
>>> wrapper which uses either tm or sl module for the reply, depending on 
>>> if a transaction was created or not.
>>>       
>> I see no point of a new module, I suggested tm as most of the modules 
>> affected use tm API anyhow, so they do not need to bind to two modules.
>>
>> The other option of doing it in sl might be easier from the point of 
>> view of changes, they already use this module to send the reply, so 
>> would be transparent for the existing code.
>>
>> At the end, I think we can do it in both modules, so configs and rest of 
>> modules stay the same...
>>     
>
> I think creating a new reply function or modifying t_reply() will only
> lead to more confusion (e.g.: use the new t_reply_with_sl_fallback()
>  and after that going stateful => tm will not know anything about the
>   stateless reply => unexpected behaviour in 90% of the cases).
> Also I don't think is a good idea to create a new function just to
> handle some corner cases, when you can handle them with minimal effort
> using existing functions.
>
> >From the script one can always either know if it's stateless or not from
> the script context (and use the appropriate reply function), or test if a
> transaction exists (t_lookup_request()) or just try t_reply() and if it
> fails use sl_send_reply()  (if (!t_reply()) sl_send_reply(...)).
>   
indeed, one can know, but it is hard to keep track if you have route 
blocks called from request route or failure route. A flag has to be kept 
and based on that use sl_send_reply() or t_reply() -- kind of uglystuff 
everywhere :
if(isflagset(1)) {
    t_reply();
} else {
    sl_send_reply(...);
}

> >From a module, one can always check if a transaction exists (or try
> t_reply and fallback to sl_send_reply).
>   
This means all the time to bind to two modules, duplicate some code, etc..

> In this particular case (if I understand correctly the bug report), the
> fix belongs in the pua module (which IMHO should always use tm
> anyway).
>   
registrar has same issue with save(...)

I do not see what confusion would be by t_reply(...) falling back to 
stateless mode. Eventually a different reply code can be used to signal 
this case, a flags parameter to be used to enforce/relax conditions. I 
am not a fan of functions with similar name and just few differences. It 
is hard to document and IMO creates more confusion.

So, yes, there are alternatives, workarounds, we try to find here the 
best one for the moment.

Cheers,
Daniel

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