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

[David Villasmil]

Even better, How about being able to send an marked OPTIONS to all in-dialog
UACs and expect an answer, whatever it is to know that the UAC is actually
reachable, hence still on the call?

On Tue, Aug 26, 2008 at 2:36 PM, Ovidiu Sas <osas at voipembedded.com> wrote:

> 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
> >
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20080826/83022468/attachment-0001.htm