[Devel] Towards OpenSER libification

[Sebastien Tricaud]

Henning Westerholt wrote:
> On Friday 20 April 2007 17:49, Sebastien Tricaud wrote:
>   
>> [..]
>> * What I would like to do:
>>     - Make sure each component is usable individually: I would like to use
>> a high performance SIP parser. The OpenSER one fills the room. I am sure
>> this is one way to have this library having more users, which mean
>>         used in ways OpenSER could not imagine, leading to discovering
>> new bugs and have OpenSER avoid SIP parsing troubles [1].
>>     
>
> Hello Sebastien,
>
> i clearly understand the usecase for a isolated openser parser, but why do 
> think that this would solve eventual security problems for OpenSER? 
>   
I am not saying that there is something bad about current SIP parsing.
Just that the more we have users of OpenSER components, the best it is
as a whole. And more users mean code looked by more people, which could
avoid a possible security issue. Sure, I am talking about security
because I work in the field, one can say more people can optimize the thing.

>   
>>     - Maybe replace useless(!) things like memory management, which is
>> what most C-written projects do. I think the base library could be Apache
>>         libAPR [2]. Maybe this is not the best choice, and if you have a
>> better idea please let me know.
>>     
>
> The reason for the custom memory management is that the system memory manager 
> don't fulfil the performance requirements of OpenSER in the past. Perhaps 
> this is now different. The SER people did sometime ago memory performance 
> tests [1], you'll find also on the mailling list some discussion about this. 
>   

I totally agree with this. I think this is also the same reason why you
wrote an other SIP parser. It goes with the high performance logic...
and that's why I am interested in it now.

> I think that the libAPR is also highly optimized, the requirements for an web 
> server and for an SIP server should be somewhat the same. If we would change 
> the memory management, i would go with libAPR.
>
> It would be interesting to know how different is the libAPR memory interface 
> from the current used is. I don't think that there is much acceptance for an 
> rewrite of the whole code base just for an different memory manager. 
>
>   
Actually maybe libAPR will not fulfill OpenSER expectations. This is
mostly a matter of having this possibility latter. I guess that's part
of an other discussion, once the current OpenSER is libified.