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

[Dan Pascu]

IMO lumps should go. They're a hackish solution that caused enough  
problems already.
As I see it, we must have the original message and the current message  
(original plus all changes applied in realtime) so one can get at any  
moment the original message and the modified message without any  
complication (modified message should be per branch of course). Re- 
parsing can be kept to a minimum or even avoided completely in certain  
circumstances if the modified message is kept as a dictionary of SIP  
header name/value pairs, plus some extra info about the first line in  
the message and the content.
In other words while the original message is kept both parsed and  
unparsed, the current modified messages are only kept parsed and are  
reconstructed in a text buffer only when sent out.

On 28 Apr 2010, at 13:40, Bogdan-Andrei Iancu wrote:

> Hi,
>
> sorry for crossposting, but I thing this topic is interesting both for
> users (as experience) and for developers (as solution).
>
> 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 :
>       Advantages: code is there and works; the mechanism is very  
> fast ;
> no need to re-parse the message after the parsing
>       Disadvantages : from script or code, you are not able to see the
> previous changes you did on the message, like:
>                 if you remove a hdr, it will be marked to be removed,
> but you will still see it there after the removed
>                 if you add a new hdr, you will not be able to see it
> (it will be actually added only when the message will be sent out)
>                 if you replace the contact hdr (like after
> fix_nated_contact() ) will not see the new contact, but the old one
>                 trying to apply 2 changes in the same area (like
> changing twice the contact) will result in bogus result.
>
>    2) find a new approach that will allow to push in realtime the
> changes on messages
>       Advantages: the change will take affect instantly, so all the
> disadvantages from 1) (as user experience in operating opensips) will
> disappear .
>       Disadvantages : the code will probably be slower (the changes
> part), but will speed up other parts of the code (where you need to
> manually identify the prev changes);
>             changed parts of the SIP message will require re-parsing
> (so the code will have to check the state of a header (if parsed or  
> not)
> before each usage)
>             you will not be able to undo changes on the SIP messages  
> in
> an easy way (for example during the parallel and serial forking on
> per-branch changes)
>
> 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 would like to hear some opinions from both people writing scripts  
> and
> people writing code.
>
> Thanks and regards,
> Bogdan
>
> -- 
> Bogdan-Andrei Iancu
> www.voice-system.ro
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


--
Dan