Tavis, <br><br>sure, I knew that SER was not stopped but it seems a lot of others believed this and I was over voted, Nevertheless, thisis not the topic of the discussion.<br>I am really glad that people are coming out and discussing the real merits<br>and I hope this will lead to a better understanding of the two camps<br><br>bye<br><b><i>Tavis P <tavis.lists@galaxytelecom.net></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br><br>You mentioned that you switched to OpenSER because "rumor spread around<br>on the openser lists that SER is no longer being maintained", i havn't<br>heard this rumor but a simple glance at the CVS commit logs for the SER<br>repositories would have shown this to be true or not (in this case,<br>not). This is a very dangerous reason to switch!<br><br>I feel that both the SER and OpenSER teams are working hard on both<br>"cosmetic and superficial changes" as well
as "real improvements" and<br>that is inaccurate to say that either is focusing on primarily on one of<br>those things. <br>SER is about to release a huge update to their software, containing a<br>large number of additions, some inspired by work done on OpenSER, some<br>completely new, its a certainty that you will see a similar occurrence<br>in OpenSER once the new version of SER is released. Its only natural to<br>build off of others work, it is what i regard to be humanities single<br>biggest strength<br><br>Now OpenSER was created for a reason, and i'm certain that this<br>reasoning still stands (if you havn't, i would urge you to read about it<br>here:<br>http://openser.org/index.php?option=com_content&task=view&id=40&Itemid=61).<br>If your requirements were met by the SER code base and their direction,<br>time lines and philosophy aligned with your own, then rumors should not<br>be enough to unsettle you. SER and OpenSER are both very solid
projects<br>(in my opinion) however they have different characteristics as such as<br>better suited for different environments and situations. Regardless,<br>the full merits of both applications should be evaluated when<br>determining which to use for a project, not just surface level<br>characteristics<br><br>I anticipate staying with OpenSER because of their short release cycle,<br>eagerness to add features to their software and their direction, i'm<br>certain that the upcoming release of SER will be very compelling (and of<br>very high quality) but i already have plans in place following the<br>OpenSER timelines (i'm very eager to begin writing modules to make use<br>of the dialog module, i think this is really the killer app for OpenSER)<br>however my requirements are fairly large and unique so they in no way<br>apply to everyone<br><br><br>my few thoughts =D<br><br>tavis<br><br><br><br>Kim Il wrote:<br>> Mike,<br>><br>> thanks a lot for your insight and the
time you have taken to answer my<br>> question. I surely did not want to be unafir to anyone.<br>> I can not comment on the why the SER people are having only few<br>> releases compared to openser but I guess they have a good reason for<br>> that (I would guess it has something to do with thoroughness, testing<br>> ..., but I am here just guessing).<br>> For me and I guess many other people who depend on SER/openser for<br>> their business the more interesting question is what to use in the<br>> long term, which camp is the more innovative, is actually driving the<br>> change and is commiting itself to the really difficult tasks. Your<br>> statement that changes in SER have been in response to openser is<br>> surely a very good starting point -and if this is true then there is<br>> no reason to shift back to SER. Do you, or maybe other people, have<br>> more examples -besides the web page- for this. This will really help<br>> me
to better judge the situation. Looking at the release notes of both<br>> openser and SER I am still of the opinion that compared to the new<br>> features of SER, most of the features that were added to openser in<br>> the last year are of cosmetic nature (hardly any touches the tough<br>> issues of security, performance and reliability).<br>><br>> Yours sincerely<br>><br>> Kim<br>><br>> */Mike Williams <mike@mikebwilliams.com>/* wrote:<br>><br>> Kim,<br>><br>> I don't think that's really a fair assessment of the situation. It<br>> seems to<br>> me, and others much more knowledgeable please comment on this,<br>> that OpenSER<br>> was forked because SER was left to stagnate, and because of a<br>> large number of<br>> feature patches that were just left to sit. The development cycles<br>> became too<br>> long, and it was unclear what the plan was.<br>><br>>
Looking back on the progress of OpenSER, one can see that the team<br>> didn't just<br>> take those patches and merge them, and pretend that they have a<br>> new product,<br>> but have instead continually developed the code base. The always<br>> have a<br>> roadmap of the next release, and an estimated timeline for<br>> completing it. A<br>> lot of important features have been added.<br>><br>> Likewise, OpenSER seems to be using a different development<br>> philosophy. The<br>> OpenSER team releases .1 increment releases with new, useful, and<br>> stable<br>> features fairly often instead of waiting years. Since I've been using<br>> OpenSER, I've seen 3 releases. SER has put out 1 in that same time<br>> period,<br>> and honestly, I don't see the same amount of features really being<br>> added by<br>> SER. If anyone can compare the two in their
present STABLE forms,<br>> I would<br>> really like to hear about it.<br>><br>> In addition, it seems many of the changes to SER have been in<br>> response to<br>> OpenSER. Iptel/SER had the same website for years, with little<br>> information<br>> about what was actually happening. If you check the OpenSER<br>> website, they are<br>> always giving useful information and news to the users and<br>> community about<br>> going forward. Just in the last few months has Iptel/SER actually<br>> changed, no<br>> doubt partly due to how good OpenSER looked in comparison.<br>><br>> Mike Williams<br>><br>> On Wednesday 08 November 2006 04:06, Kim Il wrote:<br>> > thanks Rao for bringing this up. Actually our company has moved<br>> to openser<br>> > around 6 months ago after reading the rumor spread around on the<br>> openser<br>>
> lists that SER is no longer being maintained. Looking now at the<br>> new SER I<br>> > must confess that we are more than impressed about the new<br>> features and<br>> > substantial changes to SER. It seems that, unlike openser,<br>> > the guys<br>> > behind SER spent the time not on cosmetic and superficial<br>> changes but on<br>> > real improvements. I assume this difference in working style<br>> comes from the<br>> > fact that openser is lead by a company that is capitalizing the<br>> open-source<br>> > spirit to satisfy the day-to-day needs of it customers whereas<br>> SER is being<br>> > maintained by guys who have a long term vision of things. While<br>> it will<br>> > surely cost us some time and effort for us the decision is<br>> already clear<br>> > that unless openser integrates the SER improvements we
will go<br>> back to SER.<br>> ><br>> > Bye<br>> ><br>> > Kil Il<br>> ><br>> > Rao Ramaratnamma wrote: sorry for reposting -- I<br>> > think this question belongs to both mailing list. I am really<br>> stuck with<br>> > this.<br>> ><br>> > rr<br>> ><br>> > ----- Forwarded Message ----<br>> > From: Rao Ramaratnamma<br>> > To: Christian Schlatter ; users@openser.org<br>> > Sent: Tuesday, November 7, 2006 11:15:27 PM<br>> > Subject: Re: [Users] TM : retransmission timers<br>> ><br>> > the ser ottendorf announcement does mention improved timers.<br>> Cannot openser<br>> > include this feature too and cannot I merge ser with openser for<br>> good<br>> > timers? I am still trying to understand the difference between<br>> ser and<br>> >
openser but standart compliance seems to be very important matter!<br>> ><br>> > Cannot people provide me with some hints? I am sure that I am<br>> not the only<br>> > who is asking the difference between ser and openser. ser<br>> documentation<br>> > does not appear uptodate, but the software as sannounced appears<br>> > impressive. I have already asked this question but did not<br>> receive any<br>> > answer.<br>> ><br>> > thank you in advance!<br>> ><br>> > rr<br>> ><br>> > ----- Original Message ----<br>> > From: Christian Schlatter<br>> > To: users@openser.org<br>> > Sent: Tuesday, November 7, 2006 10:52:56 PM<br>> > Subject: Re: [Users] TM : retransmission timers<br>> ><br>> > Greg Fausak wrote:<br>> > > Hello,<br>> > ><br>> > > I
believe this is a well known bug.<br>> > > Granularity of timers is 1 second. So, if you sign up for a<br>> timer to<br>> > > be fired in 1 second it will happen anywhere between 0 seconds<br>> and 1<br>> > > second.<br>> > > 2 seconds will happen between 1 and 2 seconds. I usually set up my<br>> > > timers to be 2, 2, 4, 8. There are VOIP providers that are pretty<br>> > > sticky about<br>> > > the first 500ms. If you are using one of them you're out of luck.<br>> ><br>> > Yes, there is a timer process that wakes up every second to perform<br>> > retransmissions. I was actually quite surprised that OpenSER,<br>> which is<br>> > known to be very standards compliant, does not follow the RFC 3261<br>> > retransmission timeouts. On the other hand, the RFC 3261 timeout<br>> values<br>> > are just
suggestions and standards compliant SIP UA must accept<br>> shorter<br>> > timeouts. Still it would be nice if OpenSER would support sub second<br>> > timers, this would allow for shorter fail-over times.<br>> ><br>> > Christian<br>> ><br>> > > I believe SER has made timer changes to support more exact timer<br>> > > intervals. They are a completely different camp, with a different<br>> > > feature set (although they share the same roots).<br>> > ><br>> > > -g<br>> > ><br>> > > On 11/7/06, Jean-François SMIGIELSKI wrote:<br>> > >> Hello,<br>> > >><br>> > >> I made strange observations about the intervals between<br>> > >> retransmissions with the TM module.<br>> > >> In my experiments, I used the default parameters for the TM<br>>
module<br>> > >> timers, and I sent an INVITE that cannot receive answers (it<br>> has a<br>> > >> well known R-URI pattern that is forwarded to a place and<br>> port that<br>> > >> nobody listen).<br>> > >><br>> > >> When reading RFC3261, I expected to see intervals between<br>> > >> retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions,<br>> during 32s.<br>> > >><br>> > >> But with OpenSER, (I have tested with the debian package<br>> 1.1.0-5 on a<br>> > >> debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by<br>> > >> myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ...<br>> until 26s<br>> > >> are spent (9 sendings). The first interval is sometomes very<br>> short<br>> > >> (40ms).<br>> >
>><br>> > >> Altough I like the sequence of 4s separated transmissions, I<br>> do not<br>> > >> know why the first interval is so short, and why there is no<br>> sending<br>> > >> after 1s.<br>> > >><br>> > >> Did anybody observed such behaviours? Are they normal?<br>> > >><br>> > >> Thanks in advance!<br>> > >><br>> > >> JF Smigielski.<br>><br><br></mike@mikebwilliams.com></blockquote><br><p> 
<hr size=1>Everyone is raving about <a href="http://us.rd.yahoo.com/evt=45083/*http://advision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail beta.</a>