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 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
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
