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

[Ovidiu Sas]

On Tue, Aug 26, 2008 at 6:23 AM, Bogdan-Andrei Iancu
<bogdan at voice-system.ro> wrote:
> 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.
[ovidiu]
how about going with a more general approachand use a new route: timeout_route.
the admin can decide what to do with respect to that dialog:
 - send a BYE
 - re-arm the timer

>>
>>> 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
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>