Re: [OpenSIPS-Users] Preparing new major release 1.7.0 - UPDATE
Re SST: Yep, everything you said is true. I was using SST to verify the endpoints were still alive. At the same time, i wanted to kill the call at some specified point regardless if both endpoints were still there. For instance, I want to limit all calls to 15 minutes but at the same time check every 45 seconds to insure the endpoints are still on the network. With the addition of the dialog ping I think this problem is solved. I also can't think of a valid reason to want SST module at the proxy outside of this. I guess the answer to your question is "I don't need it - not sure what I was thinking". : > Richard On Jun 24, 2011, at 9:22 AM, Bogdan-Andrei Iancu wrote: > Hi Richard, > > On 06/22/2011 04:36 PM, Richard Revels wrote: >> >> Bogdan and all, >> >> Greetings. I have been using revision 7602 in Production and have found it >> quite stable w/ most of the functionality I need. Everything else aside >> though, the support for an Event socket is going to be enough to cause me to >> start the update process. > This is good feedback :) >> >> One thing I would really like to see in a release would be a separation of >> the Dialog Timeout timer and the SIP Session Timer. The Dialog ping will go >> a long way toward handling this problem in that there is less need to >> support session timers. However, there are still times when I would like to >> set the dialog timeout based on some criteria, like credit or whatever, and >> at the same time allow endpoints to make use of the SIP Session Timer. At >> the moment that over-rides the value I place on the Dialog Timeout. Is the >> Dialog Timeout variable able to be modified via the management interface? I >> don't remember. If not, that would be neat too. > Maybe I'm missing something, but why using SST module if you are not > interested in terminating the dialog when Session Timer is up ? more or less > if you want to control the dialog lifetime by your own values, then you have > to ignore SST; if you ignore SST, why using ? AFAIK, SST on opensips is just > controlling the dialog lifetime and terminates the call if no re-INVITE. > > >> >> I like the idea of having a beta period for a new release before it is >> declared a stable release. It may help focus a lot of testing and debug >> over that 12 day time period that would normally drag out over a >> couple of months as people try to make time to deal with issues they had >> found "work-arounds" for. > > More or less these were the arguments that made me come to this approach: if > it is not released, people are not too eager to use/test ; if it is released, > they expect to be fully stable release . So we could not take the advantage > of the community testing the code (of course, without risks). > > Regards, > Bogdan > >> >> Richard >> >> On Jun 21, 2011, at 5:20 AM, Bogdan-Andrei Iancu wrote: >> >>> Hi, >>> >>> coming back with the timing for the new 1.7 major release: >>> >>> 30th of June - SVN freeze - at the time, all new things and known bugs are >>> to be committed into SVN and tested ; at this point the testing phase will >>> start. >>> >>> 12th of July - release date - the 1.7 beta will be officially release. >>> >>> >>> The list of changes for 1.7 will be fully available starting with 30th of >>> June, when SVN will be freeze. >>> >>> Best regards, >>> Bogdan >>> >>> >>> On 06/08/2011 08:05 PM, Bogdan-Andrei Iancu wrote: Hi all, The plan is to put on the roll the preparing of a new major release for opensips, to incorporate all the new things that were added : - RTP timeout notification in nathlper (via rtpproxy) with dialog termination - better error handling for RTPproxy failover - dialog enhancement (dialog fixing, in-dialog pinging) - Event interface (datagram support) - registrant module - B2B module - internal API and DB persistence for restarts. - presence enhancement We still have on the roll some work (to be finished in the next week) like: - avp auto aliasing (drop the i: and s: naming) - multi-insert in DB ops (for acc, siptrace, location). The new release will be generated from trunk and a new branch will be created for it. In the next days we will compile a detailed and complete list of new things in opensips 1.7. We also want to change a bit the release policy: after first level of testing, a beta release (release candidate) will be made public ; this code is intended to be used and tested "as final version" - eventual bugs will be fixed, opening the way for the final stable release. This is to improve the quality and stability of the stable release. I will be glad to get feedback on : - what code/functionality is missing and should be in 1.7 - the new release
Re: [OpenSIPS-Users] Preparing new major release 1.7.0 - UPDATE
Hi Richard, On 06/22/2011 04:36 PM, Richard Revels wrote: Bogdan and all, Greetings. I have been using revision 7602 in Production and have found it quite stable w/ most of the functionality I need. Everything else aside though, the support for an Event socket is going to be enough to cause me to start the update process. This is good feedback :) One thing I would really like to see in a release would be a separation of the Dialog Timeout timer and the SIP Session Timer. The Dialog ping will go a long way toward handling this problem in that there is less need to support session timers. However, there are still times when I would like to set the dialog timeout based on some criteria, like credit or whatever, and at the same time allow endpoints to make use of the SIP Session Timer. At the moment that over-rides the value I place on the Dialog Timeout. Is the Dialog Timeout variable able to be modified via the management interface? I don't remember. If not, that would be neat too. Maybe I'm missing something, but why using SST module if you are not interested in terminating the dialog when Session Timer is up ? more or less if you want to control the dialog lifetime by your own values, then you have to ignore SST; if you ignore SST, why using ? AFAIK, SST on opensips is just controlling the dialog lifetime and terminates the call if no re-INVITE. I like the idea of having a beta period for a new release before it is declared a stable release. It may help focus a lot of testing and debug over that 12 day time period that would normally drag out over a couple of months as people try to make time to deal with issues they had found "work-arounds" for. More or less these were the arguments that made me come to this approach: if it is not released, people are not too eager to use/test ; if it is released, they expect to be fully stable release . So we could not take the advantage of the community testing the code (of course, without risks). Regards, Bogdan Richard On Jun 21, 2011, at 5:20 AM, Bogdan-Andrei Iancu wrote: Hi, coming back with the timing for the new 1.7 major release: *30th of June *- SVN freeze - at the time, all new things and known bugs are to be committed into SVN and tested ; at this point the testing phase will start. *12th of July* - release date - the 1.7 beta will be officially release. The list of changes for 1.7 will be fully available starting with 30th of June, when SVN will be freeze. Best regards, Bogdan On 06/08/2011 08:05 PM, Bogdan-Andrei Iancu wrote: Hi all, The plan is to put on the roll the preparing of a new major release for opensips, to incorporate all the new things that were added : - RTP timeout notification in nathlper (via rtpproxy) with dialog termination - better error handling for RTPproxy failover - dialog enhancement (dialog fixing, in-dialog pinging) - Event interface (datagram support) - registrant module - B2B module - internal API and DB persistence for restarts. - presence enhancement We still have on the roll some work (to be finished in the next week) like: - avp auto aliasing (drop the i: and s: naming) - multi-insert in DB ops (for acc, siptrace, location). The new release will be generated from trunk and a new branch will be created for it. In the next days we will compile a detailed and complete list of new things in opensips 1.7. We also want to change a bit the release policy: after first level of testing, a beta release (release candidate) will be made public ; this code is intended to be used and tested "as final version" - eventual bugs will be fixed, opening the way for the final stable release. This is to improve the quality and stability of the stable release. I will be glad to get feedback on : - what code/functionality is missing and should be in 1.7 - the new release policy. Best regards, Bogdan -- Bogdan-Andrei Iancu OpenSIPS solutions and "know-how" ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Preparing new major release 1.7.0 - UPDATE
Speaking of suggestions... (understandable probably won't make it in
1.7, more likely 2.0)
I've been thinking about variables in the script and a couple other things.
1. New variables for direct read/write access to value currently only
available by function (very beneficial for example with cdrs)
a. Dialog variable like $dlg(name)
b. Memcache local like $mcl(name). example usage: if (
$mcl(bad_auth_cnt/$si) == null ) { $mcl(bad_auth_cnt/$si) = 1 } else {
if ( $mcl(bad_auth_cnt/$si) > 10 ) { xlog("WARNING", "Bad password
count exceeded for $si") ; drop; } ; $mcl(bad_auth_cnt/$si) =
$mcl(bad_auth_cnt/$si) + 1 } ; # when var is set it uses default cache
timeout optionally set in core setting section of script ( like listen
option )
c. Memcache regular like $mc(name)
d. Message var that lasts the duration of the mesage like
mvar(name). Fast like var but don't have to worry if it was set by
this message or a previous message.
2. Make all pseudo vars (avp, var, dlg, mc, mcl, mvar) support all
data types like avps:
a. arrays
b. json
c. string
d. int
e. float (new)
f. hash (new)
3. Make all pseudo vars (avp, var, dlg, mc, mcl, mvar) support all the
functions, operators and assignment capabilities of avps like
avp_db_load, avp_check, and avp_subst. The only difference between avp
and var, dlg etc would be what part of memory they are stored in. This
would be useful for many thing like loading memcache from db.
4. Add function that combines functionality of avp_db_load and
avp_db_query. Eg: var_db_load_query("$mvar(qry)", "$avp(qres)/h"); #
result from db of query from $mvar(qry) is in same format (columns) as
returned for avp_db_load. Results are loaded into $avp(qres) as a
hash. Since it is loaded into a single var results can be loaded
several times into different vars without concern for an avp(name)
already being loaded (so if results say to forward call to PSTN for a
call from PSTN you can reload options for diverting user and not worry
about weather the avp was loaded by the first load.
5. Add an option flag to t_on_failure("1", "m"), m for manual failure
route rather than auto as done with DNS SRV so you can choose weather
to try the next dest according to SRV etc dependent on response. In
this case it might be beneficial to store the SRV records in a json
(would be able to represent difference between load balance hosts and
fail over host of SRV) or avp.
6. Enhancements for DRouting
a. Cache drouting user/domain group id and attr in mem like rules
and gateways. (Used memcache to speed things up.)
b. Fix do_routing to convert a number in an avp string. (Annoyance
if for example pulled from memcache as string, must be converted to
int before passed to do_routing.)
c. Add support for ability to look up user/domain and
default/domain with user/domain group id and attr being the first
values and default/domain in the result avps if there is a user/domain
match. If you had 50,000 users but only 50 could do international you
could save 49,949 db entries. (I implemented this with a fairly
complex sql query with avp_db_query)
d. Add support to pass "|" separated list of user/domain vars to
use in user/domain look up, first var set without null is used for
look up. Eg:
do_routing("o/$di|$(ai{uri.user})@$si|$(re{uri.user})@$si|$fU@$si");
could support a short hand like do_routing("SO/darf"); S indicates to
use $si for domain and O indicates the header order to try. ( I
implemented this with checking in order of preference if the various
headers were present setting $avp(s:readSI) and using that in the
avp_db_query used to group id)
e. Add support for aliasing multiple domains to a single alias
domain that so duplication of user/domain settings can be avoided.
Like if you had a 5 proxy servers all setup to send calls from 50,000
users, you would have 250,000. With aliasing you would have only
25,006. ( This I used dalias in the username column of the db and in
the description only put the domain it was aliased to, again adding to
the complexity of the query)
f. Add support for only checking domain. Eg: do_routing("ds"); d
for domain only and s for use $si for domain. ( I implemented this by
using any in the db for the user and added to the complexity of the
query)
g. Add support for re-lookup of source domain according to a
custom header like X-RealSrcIP:192.168.0.1. Might add a column to the
dr_groups table for options and a mod param defining the custom header
name or search the attr column for a key/val pair like XSH=X-RealSrcIP
This is good for your topology hiding servers that would pass the
source IP they got the call from. ( I checked the returned attr avp
for a key/val pair and reran if necessary)
h. Add attr column to dr_gateways. Had to use description column
to store what I would in attr column and assign it to the avp in the
avp_db_query call.
So where are suggestions usually posted? :-)
Thanks again to all who have contributed to
Re: [OpenSIPS-Users] Preparing new major release 1.7.0 - UPDATE
Bogdan and all, Greetings. I have been using revision 7602 in Production and have found it quite stable w/ most of the functionality I need. Everything else aside though, the support for an Event socket is going to be enough to cause me to start the update process. One thing I would really like to see in a release would be a separation of the Dialog Timeout timer and the SIP Session Timer. The Dialog ping will go a long way toward handling this problem in that there is less need to support session timers. However, there are still times when I would like to set the dialog timeout based on some criteria, like credit or whatever, and at the same time allow endpoints to make use of the SIP Session Timer. At the moment that over-rides the value I place on the Dialog Timeout. Is the Dialog Timeout variable able to be modified via the management interface? I don't remember. If not, that would be neat too. I like the idea of having a beta period for a new release before it is declared a stable release. It may help focus a lot of testing and debug over that 12 day time period that would normally drag out over a couple of months as people try to make time to deal with issues they had found "work-arounds" for. Richard On Jun 21, 2011, at 5:20 AM, Bogdan-Andrei Iancu wrote: > Hi, > > coming back with the timing for the new 1.7 major release: > > 30th of June - SVN freeze - at the time, all new things and known bugs are to > be committed into SVN and tested ; at this point the testing phase will start. > > 12th of July - release date - the 1.7 beta will be officially release. > > > The list of changes for 1.7 will be fully available starting with 30th of > June, when SVN will be freeze. > > Best regards, > Bogdan > > > On 06/08/2011 08:05 PM, Bogdan-Andrei Iancu wrote: >> >> Hi all, >> >> The plan is to put on the roll the preparing of a new major release for >> opensips, to incorporate all the new things that were added : >> - RTP timeout notification in nathlper (via rtpproxy) with dialog >> termination >> - better error handling for RTPproxy failover >> - dialog enhancement (dialog fixing, in-dialog pinging) >> - Event interface (datagram support) >> - registrant module >> - B2B module - internal API and DB persistence for restarts. >> - presence enhancement >> >> We still have on the roll some work (to be finished in the next week) like: >> - avp auto aliasing (drop the i: and s: naming) >> - multi-insert in DB ops (for acc, siptrace, location). >> >> >> The new release will be generated from trunk and a new branch will be >> created for it. In the next days we will compile a detailed and complete >> list of new things in opensips 1.7. >> >> We also want to change a bit the release policy: after first level of >> testing, a beta release (release candidate) will be made public ; this code >> is intended to be used and tested "as final version" - eventual bugs will be >> fixed, opening the way for the final stable release. >> This is to improve the quality and stability of the stable release. >> >> I will be glad to get feedback on : >> - what code/functionality is missing and should be in 1.7 >> - the new release policy. >> >> Best regards, >> Bogdan >> > > > -- > Bogdan-Andrei Iancu > OpenSIPS eBootcamp - 2nd of May 2011 > OpenSIPS solutions and "know-how" > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Preparing new major release 1.7.0 - UPDATE
Hi, coming back with the timing for the new 1.7 major release: *30th of June *- SVN freeze - at the time, all new things and known bugs are to be committed into SVN and tested ; at this point the testing phase will start. *12th of July* - release date - the 1.7 beta will be officially release. The list of changes for 1.7 will be fully available starting with 30th of June, when SVN will be freeze. Best regards, Bogdan On 06/08/2011 08:05 PM, Bogdan-Andrei Iancu wrote: Hi all, The plan is to put on the roll the preparing of a new major release for opensips, to incorporate all the new things that were added : - RTP timeout notification in nathlper (via rtpproxy) with dialog termination - better error handling for RTPproxy failover - dialog enhancement (dialog fixing, in-dialog pinging) - Event interface (datagram support) - registrant module - B2B module - internal API and DB persistence for restarts. - presence enhancement We still have on the roll some work (to be finished in the next week) like: - avp auto aliasing (drop the i: and s: naming) - multi-insert in DB ops (for acc, siptrace, location). The new release will be generated from trunk and a new branch will be created for it. In the next days we will compile a detailed and complete list of new things in opensips 1.7. We also want to change a bit the release policy: after first level of testing, a beta release (release candidate) will be made public ; this code is intended to be used and tested "as final version" - eventual bugs will be fixed, opening the way for the final stable release. This is to improve the quality and stability of the stable release. I will be glad to get feedback on : - what code/functionality is missing and should be in 1.7 - the new release policy. Best regards, Bogdan -- Bogdan-Andrei Iancu OpenSIPS eBootcamp - 2nd of May 2011 OpenSIPS solutions and "know-how" ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
