Hi Bogdan, I think that multi-part body parsing should be part of the general message parsing. The SDP specific parser will be under ./parser/sdp There's nothing preventing proper support for multi-part body.
I don't have a SIP UA that generates multi-part body to test how it will work ... Regards, Ovidiu Sas On 8/10/07, Bogdan-Andrei Iancu <[EMAIL PROTECTED]> wrote: > Hi Ovidiu, > > are there any plans to support multi-part body? in case SDP in one on > the parts..... > > Regards, > Bogdan > > Ovidiu Sas wrote: > > Hi Cesc, > > > > I just ported some existing parsing functions from the nathelper > > module (just to minimize the impact to the other modules) and enhance > > them. The idea was to follow the openser generic parser. > > > > > > Ovidiu > > > > On 8/8/07, Cesc Santa <[EMAIL PROTECTED]> wrote: > > > >> If I may have a say ... I would include this also in the core. And as > >> pointed by Bogdan, SDP is signalling also ... so I would not see it so bad > >> having the parser functions in the core with the option of the modules > >> modifying the SDP. > >> > >> BTW, Ovidiiu ... in your email I read that you are creating the parser ... > >> from scratch? Would not it be a good idea to hunt for an already existing > >> SDP library and integrate it? > >> > >> Cesc > >> > >> > >> On 8/8/07, Bogdan-Andrei Iancu <[EMAIL PROTECTED]> wrote: > >> > >>> Hi Henning, > >>> > >>> SDP is also signalling part (for media) and we are evaluation _only_ > >>> parsing functions, not functions to manipulate and do SDP changes. > >>> > >>> currently there are 2 modules (nathelper and mediaproxy) parsing SDP and > >>> there is an intense demand for other SDP related functionalities (like > >>> being able to investigate SDP from script, etc); so makes no sense to > >>> have n modules, each implementing a parser. > >>> > >>> We can have a parser in core and the modules will use it for whatever > >>> specific purposes. > >>> > >>> If you make the parser a module, it will be rather a library than a > >>> module and it will create extra inter-module dependencies that we > >>> complicate thinks even more. > >>> > >>> Thanks and regards, > >>> Bogdan > >>> > >>> Henning Westerholt 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 > >>> > >>> > >> _______________________________________________ > >> Devel mailing list > >> Devel@openser.org > >> http://openser.org/cgi-bin/mailman/listinfo/devel > >> > >> > >> > > > > > > _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
