Hi Dan, what you are saying is similar with the idea I suggested (keeping the new message per header - each header has its own buffer ) - see http://lists.opensips.org/pipermail/users/2010-April/012401.html
Regards, Bogdan Dan Pascu wrote: > 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 >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel >> >> > > > -- > Dan > > > > > > > > _______________________________________________ > 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
