Hi Henning,
Integrating an SDP parser into the core or into a new module is irrelevant for someone who wants to add more media stream related functions in OpenSER. I already have a module prototype which provides only helper functionality for parsing the SDP (no memory allocation). It means that each module that is dealing with SDP must use it's own parsing function (based on the API exported by the module). This is not optimal if more then one module will deal with SDP. If there isn't enough interest from the community in such functionality in openSER, we can always leave it as is. The only real consumers of this new API would be the nathelper and the mediaproxy. Don't know if the maintainers of this modules would like to switch to a common API for parsing the SDP. Regards, Ovidiu Sas On 8/2/07, Henning Westerholt <[EMAIL PROTECTED]> wrote: > On Tuesday 31 July 2007, Bogdan-Andrei Iancu wrote: > > Hi Ovidiu, > > > > If this will be a collection of functions for parsing, I see no reason > > for not trying to include them in core. But for such a decision, more > > info will be needed. > > Hello, > > integrating SDP parser functionality into the core would be the start for > providing more and more SDP and media stream related functions in OpenSER. > > I think we should try to stay on focus. > > - OpenSER is a multi-functional, multi-purpose SIP server: router, switch, > registrar, application server, redirect server, gateway, etc.. > - OpenSER is only about signaling, but there are media adds-on > > (some quotes of a VON talk of Bogdan) > > In my opinion we're quite good in this area. But we've already enough problems > to support SIP and all the strange implementations out there. I don't think > its a good move to add to much SDP to our problem set. > > So i think a module implementation of a sdp parser would make more sense. > > Cheers, > > Henning > _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
