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 >> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > Bogdan-Andrei Iancu > www.voice-system.ro > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
