[OpenSER-Devel] Request for comments: sdpparser: module or integrated into the core

[Ovidiu Sas]

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 <bogdan at voice-system.ro> 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 <cesc.santa at gmail.com> 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 <bogdan at voice-system.ro> 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 at openser.org
> >>> http://openser.org/cgi-bin/mailman/listinfo/devel
> >>>
> >>>
> >> _______________________________________________
> >> Devel mailing list
> >> Devel at openser.org
> >> http://openser.org/cgi-bin/mailman/listinfo/devel
> >>
> >>
> >>
> >
> >
>
>