[Kamailio-Devel] SIP reply

[Andrei Pelinescu-Onciul]

On Nov 27, 2008 at 15:24, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> 
> 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(...);
> }

Then use: if (!t_reply()) 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(...)

Which can be solved another way (e.g. write the reply in an avp or pvar and
 explicitly use t_reply() or sl_send_reply(), see
 http://siprouter.teigre.com/doc/trunk/modules/auth.html nonce_count
 example for the way we did it in ser).

> 
> 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.

The confusion would be if you use this new function before going
stateful.
Regarding registrar save(): if you use one-time-nonces (or how they are
called in kamailio) you must be stateful or you'll challenge
retransmissions too. So a normal save() using t_reply() or
sl_send_reply() internally will be quite confusing: if you use it and
forget t_new_tran() it will send a reply, but it will be wrong because you
 must use stateful mode anyway. It's much better to either use a save()
 writing the reply in an avp/pvar and t_reply() or a new t_save().
That at least _will_ fail if you are not in stateful mode and 
 you will see an error message.

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

IMHO the best alternative is not to fix it and hide it under some
wrapper (in how many places would you use it anyway?).

Andrei