So voip-info.org's wiki page on CPL-C notest that the XML processing is resource consuming and thus common features can be implemented in other OpenSER modules.
I was under the impression that the upload of a CPL script into openser caused a binary compile of the script that gets used at runtime to eliminate the terrible overhead of libxml, etc...
Or am I completely off base?
--Chris
Chris Heiser a écrit :
So voip-info.org's wiki page on CPL-C notest that the XML processing is resource consuming and thus common features can be implemented in other OpenSER modules.
I was under the impression that the upload of a CPL script into openser caused a binary compile of the script that gets used at runtime to eliminate the terrible overhead of libxml, etc...
Or am I completely off base?
You're right. :)
The binary representation is available in the CPL table.
--Chris
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi Chris,
the XML processing is not the only drawback with CPL - another important one is the fact that the CPL processing is encapsulated (transparent and uncontrollable from script) and very difficult to integrate with other functionalities from the openser script (like simple NAT traversal).
regards, bogdan
Chris Heiser wrote:
So voip-info.org's wiki page on CPL-C notest that the XML processing is resource consuming and thus common features can be implemented in other OpenSER modules.
I was under the impression that the upload of a CPL script into openser caused a binary compile of the script that gets used at runtime to eliminate the terrible overhead of libxml, etc...
Or am I completely off base?
--Chris
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
(the following all theoretical only, no practice with CPL yet)
it's possible to forward requests needed to process by CPL to another OpenSER instance (OpenSER AS) running on the same box. So the main instance will process requests and take care about routing logic, NAT and other things while OpenSER AS will run CPL (or SEMS or something else). All requests from OpenSER AS unconditionally forwarded to main OpenSER.
Bogdan-Andrei Iancu wrote:
Hi Chris,
the XML processing is not the only drawback with CPL - another important one is the fact that the CPL processing is encapsulated (transparent and uncontrollable from script) and very difficult to integrate with other functionalities from the openser script (like simple NAT traversal).
regards, bogdan
Chris Heiser wrote:
So voip-info.org's wiki page on CPL-C notest that the XML processing is resource consuming and thus common features can be implemented in other OpenSER modules.
I was under the impression that the upload of a CPL script into openser caused a binary compile of the script that gets used at runtime to eliminate the terrible overhead of libxml, etc...
Or am I completely off base?
Yes, theoretically this might be possible, but personally, I also haven't tried it.
Regards, Bogdan
Victor Gamov wrote:
(the following all theoretical only, no practice with CPL yet)
it's possible to forward requests needed to process by CPL to another OpenSER instance (OpenSER AS) running on the same box. So the main instance will process requests and take care about routing logic, NAT and other things while OpenSER AS will run CPL (or SEMS or something else). All requests from OpenSER AS unconditionally forwarded to main OpenSER.
Bogdan-Andrei Iancu wrote:
Hi Chris,
the XML processing is not the only drawback with CPL - another important one is the fact that the CPL processing is encapsulated (transparent and uncontrollable from script) and very difficult to integrate with other functionalities from the openser script (like simple NAT traversal).
regards, bogdan
Chris Heiser wrote:
So voip-info.org's wiki page on CPL-C notest that the XML processing is resource consuming and thus common features can be implemented in other OpenSER modules.
I was under the impression that the upload of a CPL script into openser caused a binary compile of the script that gets used at runtime to eliminate the terrible overhead of libxml, etc...
Or am I completely off base?