[OpenSIPS-Users] [OpenSIPS-Devel] Planning next release - Roadmap

Adrian Georgescu ag at ag-projects.com
Sun Aug 10 05:43:00 CEST 2008


Hi Bogdan,

We have code now in testing phase that we would like to add in the  
next release in the form of discrete modules:

1. MSRP chat server (the conference focus and presence part)

It combines many IETF/OMA specifications, a short description is  
available here:

http://www.msrprelay.org/wiki/MSRPChatDesign

2. Xcap-diff support in presence agent

Allows end points to subscribe and receive notifications for changes  
in XCAP documents for a given presentity

http://www3.tools.ietf.org/html/draft-ietf-simple-xcap-diff-09
http://tools.ietf.org/html/draft-urpalainen-sip-xcap-diff-event-03

Adrian

On Aug 9, 2008, at 6:30 PM, Bogdan-Andrei Iancu 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
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




More information about the Users mailing list