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

[Richard Revels]

Being able to make changes on a branch and have those changes disappear when the branch does is very handy.

So far, the issue of not being able to change a header in script because it had already been changed in a function call hasn't been a major issue for me either.  I wonder if the example given in another email of needing to add a tag after calling fix_natted_contact couldn't be resolved by changing the fix_natted_contact function to accept a tag parameter.

Fast is good.  At least in this context.

Richard

On Apr 28, 2010, at 1:45 PM, Bogdan-Andrei Iancu wrote:

> Hi Brett,
> 
> Thanks for the feedback - one of the goals of my email was to see how 
> "serious" and "spreading" is the issue with changes being applied at the 
> end. If the users do actually see here no problem, fine with me :)
> 
> Best regards,
> Bogdan
> 
> Brett Nemeroff wrote:
>>> From a user's perspective...
>> I can clearly see the need to pull information from the original 
>> message as well as the "processed, unsent message". I'm aware of this 
>> issue, but I've never ran into an issue where it's really been a 
>> problem. Typically, these issues are resolved by instead of using 
>> something like message headers, using previously set AVPs in the 
>> script. Maybe my assumption is from my lack of running into the 
>> problem, but I *think* it can be resolved by smart scriptwriting...
>> 
>> I don't know a whole lot about how the message is processed under the 
>> hood, but.. from a user perspective, I'd rather change my 
>> scriptwriting to handle these issues (assuming there is a way to 
>> mitigate the issue) than make an architectural change that would 
>> overall impair performance and scalability.
>> 
>> -Brett
>> 
>> 
>> On Wed, Apr 28, 2010 at 5:40 AM, Bogdan-Andrei Iancu 
>> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> 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 <http://www.voice-system.ro>
>> 
>> 
>>    _______________________________________________
>>    Users mailing list
>>    Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>    http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
> 
> 
> -- 
> Bogdan-Andrei Iancu
> www.voice-system.ro
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users