No subject

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
> 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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

--000e0cd1b76e7f035b04854b112c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable