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
