[OpenSIPS-Users] [RFC] OpenSIPS 2.0 - changes on the SIP messages

[Stanisław Pitucha]

On 28/04/10 11:40, Bogdan-Andrei Iancu wrote:
> So, right now the code for 2.0 got to a stage were we need to "apply" 
> changes on the received messages (like adding VIA headers, changing 
> headers, etc). And before starting the work on this area, I would like 
> to get some opinions on the available options:
> 
>     1) keep the current mechanism for changing the SIP messages by using 
> lumps that are applied only when the message is sent out :

The problem for me was that sometimes you want to change things that are
affected by by previous calls you have to do. For example you cannot
easily fix the contact and the apply a parameter to the end. You cannot
put those 2 changes together, since one comes from the script logic and
the other from the internal function. (problem I run into in the nat
proxy - after masking I cannot add ;expires=...)

>     2) find a new approach that will allow to push in realtime the 
> changes on messages

There's some middle ground here, where you can at least use fast string
operations (yay - yet another string type!). I'm not sure if this would
play well with custom allocators, but a couple of years ago I was using
http://www.and.org/vstr/ - it promises modifications without realloc()
calls (does something like lumps internally).
Afair it was good quality and not modified for a long time.
But you'd still have to find a way of quick reparsing the message...
region invalidation, so you don't reparse more than needed?
first-known-dirty, first-known-good pointers? Most people don't need
reading the changes back really, so if you only marked the range of
headers as invalid, it could create a nice lazy-reparsing solution.

> So this is the dilemma: if the current mechanism (with applying changes 
> at the end) such a bad user experience (scripting) in order to try for 
> 2.0 a different approach ?

I like changing changes and I like the speed... hard choice. If partial
reparsing is not realistic, maybe you could just approach it from a
completely different prespective. Since the new routing is available
from a normal programming language anyways, maybe just exporting the
interface to lumps is enough? This way you could do the change of a
change if you *really* wanted it.
Or what the kama/s-r guys are doing - add a function that "flattens" the
message and reparses it on request.

Stan