[OpenSIPS-Users] Planning next release - Roadmap

Ovidiu Sas osas at voipembedded.com
Tue Aug 12 21:05:08 CEST 2008


Hello Bogdan,

I have in testing phase a module that will keep track of the SDP for
each call.  This new module (qos module) will sit on top of the dialog
and it will provide an API for detecting codec addition, codec update
or codec removal inside an existing dialog.

Also, I will provide technical expertise during the implementation and
testing phase of the new b2bua module.


Regards,
Ovidiu Sas

On Sat, Aug 9, 2008 at 11:30 AM, Bogdan-Andrei Iancu
<bogdan at voice-system.ro> wrote:
> Hi,
>
> I'm crossposting this email as I think both communities are to be
> interested : users - what needs to be added; devel - what to add and how.
>
> In order for us to be as efficient as possible, before starting the work
> on the next release, I want to start a discussion with users and
> developes to :
>    1) get a list with whatever people consider it will be useful for
> the next openSIPS's releases
>    2) to select a sub-list to be addressed for the next release.
>
> We need to agree what what should be done in order to share and unify
> the work effort :).
>
>
> So, Let's start building the list first (later we see what we pick up
> for the next release). Here is a starting version I came up with:
>
>
> 1) TM - cancel processing (Reason header, cancel per branch from script,
> auto processing in script)
>
> 2) TM - transaction building - split in 2 phases to be able to go
> stateful asap (for retransimissions), but to be able to apply changes
> (like lumps, flags, etc) until you do relay.
>
> 3) dialog - more work on BYE (sending byes from script makes sense ?)
>
> 4) dialog integration in NAT and SIPTRACE modules - do control at dialog
> level instead of transaction level
>
> 5) starting working on a B2BUA module based on TM (like for topology hiding)
>
> 6) db_mysql - prepared statements to speedup a bit
>
> 7) add load-balancing logic (to actually make use of load information -
> internal or external) to do be used in traffic dispatching
>
> 8) NAT modules integration - move all signalling NAT related functions
> to nat_traversal and move nathelper into rtpproxy module (only as
> rtpproxy connector)
>
> 9) MI_XMLRPC module - better integration with libxmlrpc-c3 - try to add
> process versus threads runtime switch.
>
> 10) AVPs - use auto aliasing everywhere - aliases in script and IDs
> internally - this will make the AVP easier to use and less confusing
> (having only $avp(name)) and also more efficient (internally all AVPs
> will be $avp(i:id))
>
> 11) ACC radius support - find a way to avoid module recompilling for
> enabling RADIUS support
>
> 12) XMPP - dialog support (along IM and presence)
>
> 13) multi-domain support in RR - let opensips core to learn the set of
> domains loaded by "domains" modules -> solves the RR problem when using
> pre-loaded route.
>
> 14) better blacklists integration - make some routing modules to
> automatically publish blacklists at runtime base
>
> 15) rework diameter support.
>
> 16) PV - try to find a consistent NULL behaviour for all script variables
>
> 17) TCP+TLS rework of : blocking, scalability, nat traversal, performance
>
> 18) start the work on introducing "context" for message processing - any
> future work on async processing depends on this.
>
>
>
>
> Again, I would like all of you to feel free to add whatever they
> consider relevant to this list.
>
>
> Regards,
> Bogdan
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



More information about the Users mailing list