[Kamailio-Devel] SIP reply

[Jerome Martin]

Hi All,

Following this thread from the start and having myself given it some
thinking since I saw the openSIPS additionnal send_rteply module to
acheive the same think, I would like to share my own conclusions :

- In order to stay backward compatible, no new function names should be
used, both for the scripting language and the C functions used by
modules
- I suggest, in order to asses full compatibility and avoid unexpected
results, to use a fallback approach for both tm and sl, but to control
this with module parameters, set to NO fallback in order to keep the
default behavior. This parameter should impact both C exported function
behavior and script exported functions.

Result: By default, everything remains the same. In order to have
fallback both ways (from TM -> SL and SL ->TM), just make sure both
modules are loaded and set the module parameter to 1 for both. And
voila, automagically all modules and script using either SL or TM
benefit from the fallback.

On Thu, 2008-11-27 at 15:20 +0100, Klaus Darilion wrote:

> 
> Daniel-Constantin Mierla schrieb:
> > 
> > On 11/27/08 13:56, Andrei Pelinescu-Onciul wrote:
> 
> >> >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 
> 
> So, you suggest adding the feature to tm module and then changing pua to 
> use t_reply?
> 
> klaus
> 
> 
> > 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
> > 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel


Jérôme Martin | LongPhone
Responsable Architecture Réseau
122, rue la Boetie | 75008 Paris 
Tel :  +33 (0)1 56 26 28 44
Fax : +33 (0)1 56 26 28 45
Mail : jmartin at longphone.fr
Web : www.longphone.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/devel/attachments/20081127/bb25a305/attachment.htm