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

[Bogdan-Andrei Iancu]

Stanisław Pitucha wrote:
> 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=...)
>   

yes, these are the most common problems - when you try to do 2 changes 
over the same text chunk...
>   
>>     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.
>   
indeed - what I have in mind as solution will be splitting the message 
buffer into per-header buffer ; as changes will affect only 1 buffer 
(typically), you will have to re-generate only the buffer for a single 
header (and eventually re-parse it later, on demand).
This approach will limit the impact of the changes and the overhead will 
be less. On the other hand, ops over the entire message buffer (like 
search, replace) will not work anymore, but I do not consider this an 
issue as I think, in SIP, all ops should operate over headers - like the 
hdr is the brick of the SIP message and you should not start playing 
with what is between bricks ;)
>   
>> 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.
>   
yes, I'm aware of that approach, but I do not like it so much - I mean 
is a good hack that solved the problem is the easiest way, but not in 
the best ways because:
- you need (as script level) to be aware of the changes and to trigger 
the merging of the changes into the message - it is something too geek 
and low level for the script level - the script is about SIP. I'm afraid 
people will not have full understanding of that functionality and they 
will not used in the right places or will over-use it (abuse it)
- the penalty is really high - the whole buffer is regenerated and 
completely reparsed.

Regards,
Bogdan

> Stan
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro