No subject

Thu Jan 29 11:41:19 CET 2009

rmation from the original message as well as the "processed, unsent me=
ssage". I'm aware of this issue, but I've never ran into an is=
sue where it's really been a problem. Typically, these issues are resol=
ved by instead of using something like message headers, using previously se=
t AVPs in the script. Maybe my assumption is from my lack of running into t=
he problem, but I *think* it can be resolved by smart scriptwriting...<br>

<br>I don&#39;t know a whole lot about how the message is processed under t=
he hood, but.. from a user perspective, I&#39;d rather change my scriptwrit=
ing to handle these issues (assuming there is a way to mitigate the issue) =
than make an architectural change that would overall impair performance and=

<br>-Brett<br><br><br><div class=3D"gmail_quote">On Wed, Apr 28, 2010 at 5:=
40 AM, Bogdan-Andrei Iancu <span dir=3D"ltr">&lt;<a href=3D"mailto:bogdan at v=">bogdan at</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px=
 solid rgb(204, 204, 204); padding-left: 1ex;">

sorry for crossposting, but I thing this topic is interesting both for<br>
users (as experience) and for developers (as solution).<br>
So, right now the code for 2.0 got to a stage were we need to &quot;apply&q=
changes on the received messages (like adding VIA headers, changing<br>
headers, etc). And before starting the work on this area, I would like<br>
to get some opinions on the available options:<br>
 =A0 =A01) keep the current mechanism for changing the SIP messages by usin=
lumps that are applied only when the message is sent out :<br>
 =A0 =A0 =A0 Advantages: code is there and works; the mechanism is very fas=
t ;<br>
no need to re-parse the message after the parsing<br>
 =A0 =A0 =A0 Disadvantages : from script or code, you are not able to see t=
previous changes you did on the message, like:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if you remove a hdr, it will be marked to =
be removed,<br>
but you will still see it there after the removed<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if you add a new hdr, you will not be able=
 to see it<br>
(it will be actually added only when the message will be sent out)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if you replace the contact hdr (like after=
fix_nated_contact() ) will not see the new contact, but the old one<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 trying to apply 2 changes in the same area=
changing twice the contact) will result in bogus result.<br>
 =A0 =A02) find a new approach that will allow to push in realtime the<br>
changes on messages<br>
 =A0 =A0 =A0 Advantages: the change will take affect instantly, so all the<=
disadvantages from 1) (as user experience in operating opensips) will<br>
disappear .<br>
 =A0 =A0 =A0 Disadvantages : the code will probably be slower (the changes<=
part), but will speed up other parts of the code (where you need to<br>
manually identify the prev changes);<br>
 =A0 =A0 =A0 =A0 =A0 =A0 changed parts of the SIP message will require re-p=
(so the code will have to check the state of a header (if parsed or not)<br=
before each usage)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 you will not be able to undo changes on the SIP me=
ssages in<br>
an easy way (for example during the parallel and serial forking on<br>
per-branch changes)<br>
So this is the dilemma: if the current mechanism (with applying changes<br>
at the end) such a bad user experience (scripting) in order to try for<br>
2.0 a different approach ?<br>
I would like to hear some opinions from both people writing scripts and<br>
people writing code.<br>
Thanks and regards,<br>
Bogdan-Andrei Iancu<br>
<a href=3D"" target=3D"_blank">www.voice-system.r=
Users mailing list<br>
<a href=3D"mailto:Users at">Users at</a><br=
<a href=3D"" target=


More information about the Devel mailing list