[OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Drafting OpenSIPS 1.10.0 TODO list

Saúl Ibarra Corretgé saul at ag-projects.com
Mon Feb 11 12:38:00 CET 2013


Hi Bogdan and team,

On Feb 9, 2013, at 7:40 PM, Bogdan-Andrei Iancu wrote:

> Hi all,
> 
> According the the release policy (http://www.opensips.org/Development/Development), I would like to call for a brainstorming, ideas, discussion, etc regarding what should be the roadmap for OpenSIPS 1.10 - more or less, what new goodies should be in 1.10 release (next major release).
> 
> The page is already ready (http://www.opensips.org/Main/Ver1100) and pre-populated with the pending items from 1.9 release plus some items from my side .
> 
> 
> I would like to stat the discussion here, on the mailing list first, to get from all community ideas on what should be done in 1.10 - things to improve, supporting new RFC/drafts, new functionalitites, etc.
> 
> So, please do not be shy and make your points here ;).
> 
> Also we plan a second round of discussion / selection via an IRC meeting (probably in 2 weeks or so).
> 

You asked for it :-)

Here are 3 big items I think we should have in OpenSIPS:

1. Non-blocking TCP operations (this is already on the list)
2. "Outbound" support (RFC5626) - supporting this may affect the design of point 1.
3. WebSocket transport

As for bug fixes, there are a few that come to mind:

1. Proper routing of in-dialog messages when GRUU is used. (the dialog should remember the path and loose_route should route the message to the right place even if an AoR is found in the contact, which happens when GRUU is used. This is a problem if a user re-registers while on a call and she chooses a different inbound proxy, as the in-dialog requests would now follow a different path).
2. PUA module should refresh outgoing subscriptions until told otherwise
3. presence_xml should validate incoming PIDF documents (validate them against the schema, that is). Right now it doesn't, and if a client sends a broken document then the aggregated PIDF document will also be broken. Those broken docs should not be stored.

I can elaborate on any of the points in case there are any doubts :-)


Thanks for letting us fill-up your TODO list ;-)

--
Saúl Ibarra Corretgé
AG Projects






More information about the Devel mailing list