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

[Bogdan-Andrei Iancu]

Hi Dan,

Dan Pascu wrote:
> On Monday 25 August 2008, Bogdan-Andrei Iancu wrote:
>   
>> Hi,
>>
>> Following the discussions (lists and private), here is the list with
>> what is to be done for OpenSIPS 1.5.
>>
>> The items are grouped in two categories - what should be done for 1.5
>> (mandatory) and what would be nice to have (optional). The list does
>> not cover the contributions (patches), like the MSRP and Xcap-diff
>> modules uploaded by ag-project (which are already done).
>>
>> For the grouping, an important factor was taken into consideration (as
>> you may notice, some important items were set as optional) - there are
>> plans for a complete rework on the opensips architecture that will put
>> things into a new light - a discussion about OpenSIPS 2.0 will be
>> started sooner on a separate thread.
>>
>>
>> Mandatory:
>>
>> 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 retransmissions), 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 ?)
>>     
>
> Maybe a way to make the dialog module send the BYEs when the dialog 
> expires.
>   
[bogdan]
Yes, that is one idea also - to mark the dialog if BYE should be 
generated on dialog timeout.
>   
>> 7) PV - try to find a consistent NULL behaviour for all script
>> variables
>>     
>
> If this would require too much effort, like rewriting large portions of 
> the pvar system, then I think it's not worth it, in the light of this 
> being unnecessary with the new design of 2.0. I would rather put the 
> effort and work in 2.0, since there are workarounds this and it can be 
> lived with.
>   
[bogdan]

that is true - first we will see what is the required effort - if too 
high, it will be skipped.
>   
>> 8) start the work on introducing "context" for message processing - any
>> future work on async processing depends on this.
>>     
>
> same as above. contexts will be unnecessary with the new design of 2.0.
>   
[bogdan]
Well, even in 2.0, some message context will be needed, but on a smaller 
scale - but let's have this discussion when taking about 2.0 :)
>   
>> 9) starting working on a B2BUA module based on TM (like for topology
>> hiding)
>>     
>
> same here. 2.0 would allow this to be built easily, so I'd rather not 
> invest the effort for 1.5.
>   
[bogdan]

design discussions should be started - depending of how it will fit in 
2.0 design, we will see about the implementation.
>   
>> Good to have:
>>
>>
>> 1) dialog integration in NAT and SIPTRACE modules - do control at
>> dialog level instead of transaction level
>>     
>
> nat_traversal and mediaproxy already have dialog integration. dialog 
> integration in siptrace would be nice though.
>
>   
>> 3) db_mysql - prepared statements to speedup a bit
>>     
>
> again, if the effort is too big, not sure if this item is worth pursuing, 
> as 2.0 will not need it (most likely).
>
>   
>> 8) 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))
>>     
>
> same here. too much effort for something that will go away and brings no 
> real enhancements other that some speedups and a simpler way to work with 
> avp aliases.
>   
[bogdan]
Correct - this is the reason for having this items on good-to-have.


Regards,
Bogdan