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

[Ovidiu Sas]

This is a little bit tricky, because you need to keep tracking of the
cseq for the received and sent message (each OPTION will increase the
sent cseq number).  Each in dialog request that will come from the far
end UAC will need to have the cseq altered to be in synch with the
previous sent OPTION.
It can be done, but it is more work.  Sending OPTIONS from the dialog
module itself is quite easy.  I implemented and tested that, but then
I got lazy in implementing the cseq mangling stuff.

Regards,
Ovidiu Sas

On Tue, Aug 26, 2008 at 8:52 AM, David Villasmil
<david.villasmil.work at gmail.com> wrote:
> 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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>