sorry for reposting -- I think this question belongs to both mailing list. I am really stuck with this.
rr
----- Forwarded Message ---- From: Rao Ramaratnamma raramarat@yahoo.com To: Christian Schlatter cs@unc.edu; users@openser.org Sent: Tuesday, November 7, 2006 11:15:27 PM Subject: Re: [Users] TM : retransmission timers
the ser ottendorf announcement does mention improved timers. Cannot openser include this feature too and cannot I merge ser with openser for good timers? I am still trying to understand the difference between ser and openser but standart compliance seems to be very important matter!
Cannot people provide me with some hints? I am sure that I am not the only who is asking the difference between ser and openser. ser documentation does not appear uptodate, but the software as sannounced appears impressive. I have already asked this question but did not receive any answer.
thank you in advance!
rr
----- Original Message ---- From: Christian Schlatter cs@unc.edu To: users@openser.org Sent: Tuesday, November 7, 2006 10:52:56 PM Subject: Re: [Users] TM : retransmission timers
Greg Fausak wrote:
Hello,
I believe this is a well known bug. Granularity of timers is 1 second. So, if you sign up for a timer to be fired in 1 second it will happen anywhere between 0 seconds and 1 second. 2 seconds will happen between 1 and 2 seconds. I usually set up my timers to be 2, 2, 4, 8. There are VOIP providers that are pretty sticky about the first 500ms. If you are using one of them you're out of luck.
Yes, there is a timer process that wakes up every second to perform retransmissions. I was actually quite surprised that OpenSER, which is known to be very standards compliant, does not follow the RFC 3261 retransmission timeouts. On the other hand, the RFC 3261 timeout values are just suggestions and standards compliant SIP UA must accept shorter timeouts. Still it would be nice if OpenSER would support sub second timers, this would allow for shorter fail-over times.
Christian
I believe SER has made timer changes to support more exact timer intervals. They are a completely different camp, with a different feature set (although they share the same roots).
-g
On 11/7/06, Jean-François SMIGIELSKI jf-smig@ibelgique.com wrote:
Hello,
I made strange observations about the intervals between retransmissions with the TM module. In my experiments, I used the default parameters for the TM module timers, and I sent an INVITE that cannot receive answers (it has a well known R-URI
pattern that is forwarded to a place and port that
nobody listen).
When reading RFC3261, I expected to see intervals between retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s.
But with OpenSER, (I have tested with the debian package 1.1.0-5 on a debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s are spent (9 sendings). The first interval is sometomes very short (40ms).
Altough I like the sequence of 4s separated transmissions, I do not know why the first interval is so short, and why there is no sending after 1s.
Did anybody observed such behaviours? Are they normal?
Thanks in advance!
JF
Smigielski.
iBELGIQUE, exprimez-vous ! http://web.ibelgique.com/
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
thanks Rao for bringing this up. Actually our company has moved to openser around 6 months ago after reading the rumor spread around on the openser lists that SER is no longer being maintained. Looking now at the new SER I must confess that we are more than impressed about the new features and substantial changes to SER. It seems that, unlike openser, the guys behind SER spent the time not on cosmetic and superficial changes but on real improvements. I assume this difference in working style comes from the fact that openser is lead by a company that is capitalizing the open-source spirit to satisfy the day-to-day needs of it customers whereas SER is being maintained by guys who have a long term vision of things. While it will surely cost us some time and effort for us the decision is already clear that unless openser integrates the SER improvements we will go back to SER.
Bye
Kil Il
Rao Ramaratnamma raramarat@yahoo.com wrote: sorry for reposting -- I think this question belongs to both mailing list. I am really stuck with this.
rr
----- Forwarded Message ---- From: Rao Ramaratnamma raramarat@yahoo.com To: Christian Schlatter cs@unc.edu; users@openser.org Sent: Tuesday, November 7, 2006 11:15:27 PM Subject: Re: [Users] TM : retransmission timers
the ser ottendorf announcement does mention improved timers. Cannot openser include this feature too and cannot I merge ser with openser for good timers? I am still trying to understand the difference between ser and openser but standart compliance seems to be very important matter!
Cannot people provide me with some hints? I am sure that I am not the only who is asking the difference between ser and openser. ser documentation does not appear uptodate, but the software as sannounced appears impressive. I have already asked this question but did not receive any answer.
thank you in advance!
rr
----- Original Message ---- From: Christian Schlatter cs@unc.edu To: users@openser.org Sent: Tuesday, November 7, 2006 10:52:56 PM Subject: Re: [Users] TM : retransmission timers
Greg Fausak wrote:
Hello,
I believe this is a well known bug. Granularity of timers is 1 second. So, if you sign up for a timer to be fired in 1 second it will happen anywhere between 0 seconds and 1 second. 2 seconds will happen between 1 and 2 seconds. I usually set up my timers to be 2, 2, 4, 8. There are VOIP providers that are pretty sticky about the first 500ms. If you are using one of them you're out of luck.
Yes, there is a timer process that wakes up every second to perform retransmissions. I was actually quite surprised that OpenSER, which is known to be very standards compliant, does not follow the RFC 3261 retransmission timeouts. On the other hand, the RFC 3261 timeout values are just suggestions and standards compliant SIP UA must accept shorter timeouts. Still it would be nice if OpenSER would support sub second timers, this would allow for shorter fail-over times.
Christian
I believe SER has made timer changes to support more exact timer intervals. They are a completely different camp, with a different feature set (although they share the same roots).
-g
On 11/7/06, Jean-François SMIGIELSKI jf-smig@ibelgique.com wrote:
Hello,
I made strange observations about the intervals between retransmissions with the TM module. In my experiments, I used the default parameters for the TM module timers, and I sent an INVITE that cannot receive answers (it has a well known R-URI pattern that is forwarded to a place and port that nobody listen).
When reading RFC3261, I expected to see intervals between retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s.
But with OpenSER, (I have tested with the debian package 1.1.0-5 on a debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s are spent (9 sendings). The first interval is sometomes very short (40ms).
Altough I like the sequence of 4s separated transmissions, I do not know why the first interval is so short, and why there is no sending after 1s.
Did anybody observed such behaviours? Are they normal?
Thanks in advance!
JF Smigielski.
iBELGIQUE, exprimez-vous ! http://web.ibelgique.com/
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
--------------------------------- Everyone is raving about the all-new Yahoo! Mail.
Kim,
I don't think that's really a fair assessment of the situation. It seems to me, and others much more knowledgeable please comment on this, that OpenSER was forked because SER was left to stagnate, and because of a large number of feature patches that were just left to sit. The development cycles became too long, and it was unclear what the plan was.
Looking back on the progress of OpenSER, one can see that the team didn't just take those patches and merge them, and pretend that they have a new product, but have instead continually developed the code base. The always have a roadmap of the next release, and an estimated timeline for completing it. A lot of important features have been added.
Likewise, OpenSER seems to be using a different development philosophy. The OpenSER team releases .1 increment releases with new, useful, and stable features fairly often instead of waiting years. Since I've been using OpenSER, I've seen 3 releases. SER has put out 1 in that same time period, and honestly, I don't see the same amount of features really being added by SER. If anyone can compare the two in their present STABLE forms, I would really like to hear about it.
In addition, it seems many of the changes to SER have been in response to OpenSER. Iptel/SER had the same website for years, with little information about what was actually happening. If you check the OpenSER website, they are always giving useful information and news to the users and community about going forward. Just in the last few months has Iptel/SER actually changed, no doubt partly due to how good OpenSER looked in comparison.
Mike Williams
On Wednesday 08 November 2006 04:06, Kim Il wrote:
thanks Rao for bringing this up. Actually our company has moved to openser around 6 months ago after reading the rumor spread around on the openser lists that SER is no longer being maintained. Looking now at the new SER I must confess that we are more than impressed about the new features and substantial changes to SER. It seems that, unlike openser, the guys behind SER spent the time not on cosmetic and superficial changes but on real improvements. I assume this difference in working style comes from the fact that openser is lead by a company that is capitalizing the open-source spirit to satisfy the day-to-day needs of it customers whereas SER is being maintained by guys who have a long term vision of things. While it will surely cost us some time and effort for us the decision is already clear that unless openser integrates the SER improvements we will go back to SER.
Bye
Kil Il
Rao Ramaratnamma raramarat@yahoo.com wrote: sorry for reposting -- I think this question belongs to both mailing list. I am really stuck with this.
rr
----- Forwarded Message ---- From: Rao Ramaratnamma raramarat@yahoo.com To: Christian Schlatter cs@unc.edu; users@openser.org Sent: Tuesday, November 7, 2006 11:15:27 PM Subject: Re: [Users] TM : retransmission timers
the ser ottendorf announcement does mention improved timers. Cannot openser include this feature too and cannot I merge ser with openser for good timers? I am still trying to understand the difference between ser and openser but standart compliance seems to be very important matter!
Cannot people provide me with some hints? I am sure that I am not the only who is asking the difference between ser and openser. ser documentation does not appear uptodate, but the software as sannounced appears impressive. I have already asked this question but did not receive any answer.
thank you in advance!
rr
----- Original Message ---- From: Christian Schlatter cs@unc.edu To: users@openser.org Sent: Tuesday, November 7, 2006 10:52:56 PM Subject: Re: [Users] TM : retransmission timers
Greg Fausak wrote:
Hello,
I believe this is a well known bug. Granularity of timers is 1 second. So, if you sign up for a timer to be fired in 1 second it will happen anywhere between 0 seconds and 1 second. 2 seconds will happen between 1 and 2 seconds. I usually set up my timers to be 2, 2, 4, 8. There are VOIP providers that are pretty sticky about the first 500ms. If you are using one of them you're out of luck.
Yes, there is a timer process that wakes up every second to perform retransmissions. I was actually quite surprised that OpenSER, which is known to be very standards compliant, does not follow the RFC 3261 retransmission timeouts. On the other hand, the RFC 3261 timeout values are just suggestions and standards compliant SIP UA must accept shorter timeouts. Still it would be nice if OpenSER would support sub second timers, this would allow for shorter fail-over times.
Christian
I believe SER has made timer changes to support more exact timer intervals. They are a completely different camp, with a different feature set (although they share the same roots).
-g
On 11/7/06, Jean-François SMIGIELSKI jf-smig@ibelgique.com wrote:
Hello,
I made strange observations about the intervals between retransmissions with the TM module. In my experiments, I used the default parameters for the TM module timers, and I sent an INVITE that cannot receive answers (it has a well known R-URI pattern that is forwarded to a place and port that nobody listen).
When reading RFC3261, I expected to see intervals between retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s.
But with OpenSER, (I have tested with the debian package 1.1.0-5 on a debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s are spent (9 sendings). The first interval is sometomes very short (40ms).
Altough I like the sequence of 4s separated transmissions, I do not know why the first interval is so short, and why there is no sending after 1s.
Did anybody observed such behaviours? Are they normal?
Thanks in advance!
JF Smigielski.
iBELGIQUE, exprimez-vous ! http://web.ibelgique.com/
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Everyone is raving about the all-new Yahoo! Mail.
Mike,
thanks a lot for your insight and the time you have taken to answer my question. I surely did not want to be unafir to anyone. I can not comment on the why the SER people are having only few releases compared to openser but I guess they have a good reason for that (I would guess it has something to do with thoroughness, testing ..., but I am here just guessing). For me and I guess many other people who depend on SER/openser for their business the more interesting question is what to use in the long term, which camp is the more innovative, is actually driving the change and is commiting itself to the really difficult tasks. Your statement that changes in SER have been in response to openser is surely a very good starting point -and if this is true then there is no reason to shift back to SER. Do you, or maybe other people, have more examples -besides the web page- for this. This will really help me to better judge the situation. Looking at the release notes of both openser and SER I am still of the opinion that compared to the new features of SER, most of the features that were added to openser in the last year are of cosmetic nature (hardly any touches the tough issues of security, performance and reliability).
Yours sincerely
Kim
Mike Williams mike@mikebwilliams.com wrote: Kim,
I don't think that's really a fair assessment of the situation. It seems to me, and others much more knowledgeable please comment on this, that OpenSER was forked because SER was left to stagnate, and because of a large number of feature patches that were just left to sit. The development cycles became too long, and it was unclear what the plan was.
Looking back on the progress of OpenSER, one can see that the team didn't just take those patches and merge them, and pretend that they have a new product, but have instead continually developed the code base. The always have a roadmap of the next release, and an estimated timeline for completing it. A lot of important features have been added.
Likewise, OpenSER seems to be using a different development philosophy. The OpenSER team releases .1 increment releases with new, useful, and stable features fairly often instead of waiting years. Since I've been using OpenSER, I've seen 3 releases. SER has put out 1 in that same time period, and honestly, I don't see the same amount of features really being added by SER. If anyone can compare the two in their present STABLE forms, I would really like to hear about it.
In addition, it seems many of the changes to SER have been in response to OpenSER. Iptel/SER had the same website for years, with little information about what was actually happening. If you check the OpenSER website, they are always giving useful information and news to the users and community about going forward. Just in the last few months has Iptel/SER actually changed, no doubt partly due to how good OpenSER looked in comparison.
Mike Williams
On Wednesday 08 November 2006 04:06, Kim Il wrote:
thanks Rao for bringing this up. Actually our company has moved to openser around 6 months ago after reading the rumor spread around on the openser lists that SER is no longer being maintained. Looking now at the new SER I must confess that we are more than impressed about the new features and substantial changes to SER. It seems that, unlike openser, the guys behind SER spent the time not on cosmetic and superficial changes but on real improvements. I assume this difference in working style comes from the fact that openser is lead by a company that is capitalizing the open-source spirit to satisfy the day-to-day needs of it customers whereas SER is being maintained by guys who have a long term vision of things. While it will surely cost us some time and effort for us the decision is already clear that unless openser integrates the SER improvements we will go back to SER.
Bye
Kil Il
Rao Ramaratnamma wrote: sorry for reposting -- I think this question belongs to both mailing list. I am really stuck with this.
rr
----- Forwarded Message ---- From: Rao Ramaratnamma To: Christian Schlatter ; users@openser.org Sent: Tuesday, November 7, 2006 11:15:27 PM Subject: Re: [Users] TM : retransmission timers
the ser ottendorf announcement does mention improved timers. Cannot openser include this feature too and cannot I merge ser with openser for good timers? I am still trying to understand the difference between ser and openser but standart compliance seems to be very important matter!
Cannot people provide me with some hints? I am sure that I am not the only who is asking the difference between ser and openser. ser documentation does not appear uptodate, but the software as sannounced appears impressive. I have already asked this question but did not receive any answer.
thank you in advance!
rr
----- Original Message ---- From: Christian Schlatter To: users@openser.org Sent: Tuesday, November 7, 2006 10:52:56 PM Subject: Re: [Users] TM : retransmission timers
Greg Fausak wrote:
Hello,
I believe this is a well known bug. Granularity of timers is 1 second. So, if you sign up for a timer to be fired in 1 second it will happen anywhere between 0 seconds and 1 second. 2 seconds will happen between 1 and 2 seconds. I usually set up my timers to be 2, 2, 4, 8. There are VOIP providers that are pretty sticky about the first 500ms. If you are using one of them you're out of luck.
Yes, there is a timer process that wakes up every second to perform retransmissions. I was actually quite surprised that OpenSER, which is known to be very standards compliant, does not follow the RFC 3261 retransmission timeouts. On the other hand, the RFC 3261 timeout values are just suggestions and standards compliant SIP UA must accept shorter timeouts. Still it would be nice if OpenSER would support sub second timers, this would allow for shorter fail-over times.
Christian
I believe SER has made timer changes to support more exact timer intervals. They are a completely different camp, with a different feature set (although they share the same roots).
-g
On 11/7/06, Jean-François SMIGIELSKI wrote:
Hello,
I made strange observations about the intervals between retransmissions with the TM module. In my experiments, I used the default parameters for the TM module timers, and I sent an INVITE that cannot receive answers (it has a well known R-URI pattern that is forwarded to a place and port that nobody listen).
When reading RFC3261, I expected to see intervals between retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s.
But with OpenSER, (I have tested with the debian package 1.1.0-5 on a debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s are spent (9 sendings). The first interval is sometomes very short (40ms).
Altough I like the sequence of 4s separated transmissions, I do not know why the first interval is so short, and why there is no sending after 1s.
Did anybody observed such behaviours? Are they normal?
Thanks in advance!
JF Smigielski.
iBELGIQUE, exprimez-vous ! http://web.ibelgique.com/
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Everyone is raving about the all-new Yahoo! Mail.
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
--------------------------------- Sponsored Link
Get an Online or Campus degree - Associate's, Bachelor's, or Master's - in less than one year.
Kim,
Here are a few features of the top of my head that I can think of, both fetch support and new a DB mode for usrloc.
The new db mode allows me to have two OpenSER servers load balanced using just DNS SRV records and a mysql backend because any SIP transmission can go to either server, and any server can fail without effecting anything else.
From the openser home page:
Accounting optimization:
"2006-09-25 - Accounting module (acc) has been redesigned to be more flexible and faster.
The module suffered major changes in the internals, but kept easy interface to the configuration script. Lot of useless fields were removed from the default list, they can be recorded on demand via extra accounting facility.
Many other optimization were introduced to enable modularity and faster storage. Also, multi-leg accounting was enhanced to allow definition of as many fields to be recorded as needed."
This describes some major memory tunings as well better support for huge numbers of users:
Database fetch support 2006-07-14: New introduced fetch support for database drivers enables management of huge number of location entries (>120 000) with no need of OpenSER compilation tunings.
Just few days after the last major release , new appealing feature was introduced in the development version.
Until now, when dealing with large number of subscribers, OpenSER/SER required tunings and recompilation to resize the private memory large enough so that all location records from database could be loaded. It was quite annoying because this private memory was used only once, at startup, afterwards most of it was not used at all by the SIP server, but it was allocated and no other application could use it.
The new features loads chunks of records, the size of the chunk being configurable and specific for the available private memory. The issue is now solved in OpenSER, allowing straightforward deployments for carrier grade platforms. This adds more value to the features introduced with the latest release that enabled geographic distribution/failover and load balancing.
If I think of some other good stuff, I'll let you know.
Perhaps someone should put all these comparisons into a wiki page so that we can build an accurate picture of the advantages of each product.
Mike Williams
On Wednesday 08 November 2006 11:46, Kim Il wrote:
Mike,
thanks a lot for your insight and the time you have taken to answer my question. I surely did not want to be unafir to anyone. I can not comment on the why the SER people are having only few releases compared to openser but I guess they have a good reason for that (I would guess it has something to do with thoroughness, testing ..., but I am here just guessing). For me and I guess many other people who depend on SER/openser for their business the more interesting question is what to use in the long term, which camp is the more innovative, is actually driving the change and is commiting itself to the really difficult tasks. Your statement that changes in SER have been in response to openser is surely a very good starting point -and if this is true then there is no reason to shift back to SER. Do you, or maybe other people, have more examples -besides the web page- for this. This will really help me to better judge the situation. Looking at the release notes of both openser and SER I am still of the opinion that compared to the new features of SER, most of the features that were added to openser in the last year are of cosmetic nature (hardly any touches the tough issues of security, performance and reliability).
Yours sincerely
Kim
Mike Williams mike@mikebwilliams.com wrote: Kim,
I don't think that's really a fair assessment of the situation. It seems to me, and others much more knowledgeable please comment on this, that OpenSER was forked because SER was left to stagnate, and because of a large number of feature patches that were just left to sit. The development cycles became too long, and it was unclear what the plan was.
Looking back on the progress of OpenSER, one can see that the team didn't just take those patches and merge them, and pretend that they have a new product, but have instead continually developed the code base. The always have a roadmap of the next release, and an estimated timeline for completing it. A lot of important features have been added.
Likewise, OpenSER seems to be using a different development philosophy. The OpenSER team releases .1 increment releases with new, useful, and stable features fairly often instead of waiting years. Since I've been using OpenSER, I've seen 3 releases. SER has put out 1 in that same time period, and honestly, I don't see the same amount of features really being added by SER. If anyone can compare the two in their present STABLE forms, I would really like to hear about it.
In addition, it seems many of the changes to SER have been in response to OpenSER. Iptel/SER had the same website for years, with little information about what was actually happening. If you check the OpenSER website, they are always giving useful information and news to the users and community about going forward. Just in the last few months has Iptel/SER actually changed, no doubt partly due to how good OpenSER looked in comparison.
Mike Williams
On Wednesday 08 November 2006 04:06, Kim Il wrote:
thanks Rao for bringing this up. Actually our company has moved to openser around 6 months ago after reading the rumor spread around on the openser lists that SER is no longer being maintained. Looking now at the new SER I must confess that we are more than impressed about the new features and substantial changes to SER. It seems that, unlike openser, the guys behind SER spent the time not on cosmetic and superficial changes but on real improvements. I assume this difference in working style comes from the fact that openser is lead by a company that is capitalizing the open-source spirit to satisfy the day-to-day needs of it customers whereas SER is being maintained by guys who have a long term vision of things. While it will surely cost us some time and effort for us the decision is already clear that unless openser integrates the SER improvements we will go back to SER.
Bye
Kil Il
Rao Ramaratnamma wrote: sorry for reposting -- I think this question belongs to both mailing list. I am really stuck with this.
rr
----- Forwarded Message ---- From: Rao Ramaratnamma To: Christian Schlatter ; users@openser.org Sent: Tuesday, November 7, 2006 11:15:27 PM Subject: Re: [Users] TM : retransmission timers
the ser ottendorf announcement does mention improved timers. Cannot openser include this feature too and cannot I merge ser with openser for good timers? I am still trying to understand the difference between ser and openser but standart compliance seems to be very important matter!
Cannot people provide me with some hints? I am sure that I am not the only who is asking the difference between ser and openser. ser documentation does not appear uptodate, but the software as sannounced appears impressive. I have already asked this question but did not receive any answer.
thank you in advance!
rr
----- Original Message ---- From: Christian Schlatter To: users@openser.org Sent: Tuesday, November 7, 2006 10:52:56 PM Subject: Re: [Users] TM : retransmission timers
Greg Fausak wrote:
Hello,
I believe this is a well known bug. Granularity of timers is 1 second. So, if you sign up for a timer to be fired in 1 second it will happen anywhere between 0 seconds and 1 second. 2 seconds will happen between 1 and 2 seconds. I usually set up my timers to be 2, 2, 4, 8. There are VOIP providers that are pretty sticky about the first 500ms. If you are using one of them you're out of luck.
Yes, there is a timer process that wakes up every second to perform retransmissions. I was actually quite surprised that OpenSER, which is known to be very standards compliant, does not follow the RFC 3261 retransmission timeouts. On the other hand, the RFC 3261 timeout values are just suggestions and standards compliant SIP UA must accept shorter timeouts. Still it would be nice if OpenSER would support sub second timers, this would allow for shorter fail-over times.
Christian
I believe SER has made timer changes to support more exact timer intervals. They are a completely different camp, with a different feature set (although they share the same roots).
-g
On 11/7/06, Jean-François SMIGIELSKI wrote:
Hello,
I made strange observations about the intervals between retransmissions with the TM module. In my experiments, I used the default parameters for the TM module timers, and I sent an INVITE that cannot receive answers (it has a well known R-URI pattern that is forwarded to a place and port that nobody listen).
When reading RFC3261, I expected to see intervals between retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s.
But with OpenSER, (I have tested with the debian package 1.1.0-5 on a debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s are spent (9 sendings). The first interval is sometomes very short (40ms).
Altough I like the sequence of 4s separated transmissions, I do not know why the first interval is so short, and why there is no sending after 1s.
Did anybody observed such behaviours? Are they normal?
Thanks in advance!
JF Smigielski.
__ iBELGIQUE, exprimez-vous ! http://web.ibelgique.com/
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Everyone is raving about the all-new Yahoo! Mail.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Sponsored Link
Get an Online or Campus degree - Associate's, Bachelor's, or Master's - in less than one year.
Mike,
this is a really good start and we should collect these things so as to help the community to take the right choice. I would also suggest that what ever ground breaking issues we list we stay at the functional level (I do not think anyone is helped by using a description containing "allowing carrier grade platforms" and similar marketing phrases).
cheers
Mike Williams mike@mikebwilliams.com wrote: Kim,
Here are a few features of the top of my head that I can think of, both fetch support and new a DB mode for usrloc.
The new db mode allows me to have two OpenSER servers load balanced using just DNS SRV records and a mysql backend because any SIP transmission can go to either server, and any server can fail without effecting anything else.
From the openser home page:
Accounting optimization:
"2006-09-25 - Accounting module (acc) has been redesigned to be more flexible and faster.
The module suffered major changes in the internals, but kept easy interface to the configuration script. Lot of useless fields were removed from the default list, they can be recorded on demand via extra accounting facility.
Many other optimization were introduced to enable modularity and faster storage. Also, multi-leg accounting was enhanced to allow definition of as many fields to be recorded as needed."
This describes some major memory tunings as well better support for huge numbers of users:
Database fetch support 2006-07-14: New introduced fetch support for database drivers enables management of huge number of location entries (>120 000) with no need of OpenSER compilation tunings.
Just few days after the last major release , new appealing feature was introduced in the development version.
Until now, when dealing with large number of subscribers, OpenSER/SER required tunings and recompilation to resize the private memory large enough so that all location records from database could be loaded. It was quite annoying because this private memory was used only once, at startup, afterwards most of it was not used at all by the SIP server, but it was allocated and no other application could use it.
The new features loads chunks of records, the size of the chunk being configurable and specific for the available private memory. The issue is now solved in OpenSER, allowing straightforward deployments for carrier grade platforms. This adds more value to the features introduced with the latest release that enabled geographic distribution/failover and load balancing.
If I think of some other good stuff, I'll let you know.
Perhaps someone should put all these comparisons into a wiki page so that we can build an accurate picture of the advantages of each product.
Mike Williams
On Wednesday 08 November 2006 11:46, Kim Il wrote:
Mike,
thanks a lot for your insight and the time you have taken to answer my question. I surely did not want to be unafir to anyone. I can not comment on the why the SER people are having only few releases compared to openser but I guess they have a good reason for that (I would guess it has something to do with thoroughness, testing ..., but I am here just guessing). For me and I guess many other people who depend on SER/openser for their business the more interesting question is what to use in the long term, which camp is the more innovative, is actually driving the change and is commiting itself to the really difficult tasks. Your statement that changes in SER have been in response to openser is surely a very good starting point -and if this is true then there is no reason to shift back to SER. Do you, or maybe other people, have more examples -besides the web page- for this. This will really help me to better judge the situation. Looking at the release notes of both openser and SER I am still of the opinion that compared to the new features of SER, most of the features that were added to openser in the last year are of cosmetic nature (hardly any touches the tough issues of security, performance and reliability).
Yours sincerely
Kim
Mike Williams wrote: Kim,
I don't think that's really a fair assessment of the situation. It seems to me, and others much more knowledgeable please comment on this, that OpenSER was forked because SER was left to stagnate, and because of a large number of feature patches that were just left to sit. The development cycles became too long, and it was unclear what the plan was.
Looking back on the progress of OpenSER, one can see that the team didn't just take those patches and merge them, and pretend that they have a new product, but have instead continually developed the code base. The always have a roadmap of the next release, and an estimated timeline for completing it. A lot of important features have been added.
Likewise, OpenSER seems to be using a different development philosophy. The OpenSER team releases .1 increment releases with new, useful, and stable features fairly often instead of waiting years. Since I've been using OpenSER, I've seen 3 releases. SER has put out 1 in that same time period, and honestly, I don't see the same amount of features really being added by SER. If anyone can compare the two in their present STABLE forms, I would really like to hear about it.
In addition, it seems many of the changes to SER have been in response to OpenSER. Iptel/SER had the same website for years, with little information about what was actually happening. If you check the OpenSER website, they are always giving useful information and news to the users and community about going forward. Just in the last few months has Iptel/SER actually changed, no doubt partly due to how good OpenSER looked in comparison.
Mike Williams
On Wednesday 08 November 2006 04:06, Kim Il wrote:
thanks Rao for bringing this up. Actually our company has moved to openser around 6 months ago after reading the rumor spread around on the openser lists that SER is no longer being maintained. Looking now at the new SER I must confess that we are more than impressed about the new features and substantial changes to SER. It seems that, unlike openser, the guys behind SER spent the time not on cosmetic and superficial changes but on real improvements. I assume this difference in working style comes from the fact that openser is lead by a company that is capitalizing the open-source spirit to satisfy the day-to-day needs of it customers whereas SER is being maintained by guys who have a long term vision of things. While it will surely cost us some time and effort for us the decision is already clear that unless openser integrates the SER improvements we will go back to SER.
Bye
Kil Il
Rao Ramaratnamma wrote: sorry for reposting -- I think this question belongs to both mailing list. I am really stuck with this.
rr
----- Forwarded Message ---- From: Rao Ramaratnamma To: Christian Schlatter ; users@openser.org Sent: Tuesday, November 7, 2006 11:15:27 PM Subject: Re: [Users] TM : retransmission timers
the ser ottendorf announcement does mention improved timers. Cannot openser include this feature too and cannot I merge ser with openser for good timers? I am still trying to understand the difference between ser and openser but standart compliance seems to be very important matter!
Cannot people provide me with some hints? I am sure that I am not the only who is asking the difference between ser and openser. ser documentation does not appear uptodate, but the software as sannounced appears impressive. I have already asked this question but did not receive any answer.
thank you in advance!
rr
----- Original Message ---- From: Christian Schlatter To: users@openser.org Sent: Tuesday, November 7, 2006 10:52:56 PM Subject: Re: [Users] TM : retransmission timers
Greg Fausak wrote:
Hello,
I believe this is a well known bug. Granularity of timers is 1 second. So, if you sign up for a timer to be fired in 1 second it will happen anywhere between 0 seconds and 1 second. 2 seconds will happen between 1 and 2 seconds. I usually set up my timers to be 2, 2, 4, 8. There are VOIP providers that are pretty sticky about the first 500ms. If you are using one of them you're out of luck.
Yes, there is a timer process that wakes up every second to perform retransmissions. I was actually quite surprised that OpenSER, which is known to be very standards compliant, does not follow the RFC 3261 retransmission timeouts. On the other hand, the RFC 3261 timeout values are just suggestions and standards compliant SIP UA must accept shorter timeouts. Still it would be nice if OpenSER would support sub second timers, this would allow for shorter fail-over times.
Christian
I believe SER has made timer changes to support more exact timer intervals. They are a completely different camp, with a different feature set (although they share the same roots).
-g
On 11/7/06, Jean-François SMIGIELSKI wrote:
Hello,
I made strange observations about the intervals between retransmissions with the TM module. In my experiments, I used the default parameters for the TM module timers, and I sent an INVITE that cannot receive answers (it has a well known R-URI pattern that is forwarded to a place and port that nobody listen).
When reading RFC3261, I expected to see intervals between retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s.
But with OpenSER, (I have tested with the debian package 1.1.0-5 on a debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s are spent (9 sendings). The first interval is sometomes very short (40ms).
Altough I like the sequence of 4s separated transmissions, I do not know why the first interval is so short, and why there is no sending after 1s.
Did anybody observed such behaviours? Are they normal?
Thanks in advance!
JF Smigielski.
__ iBELGIQUE, exprimez-vous ! http://web.ibelgique.com/
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Everyone is raving about the all-new Yahoo! Mail.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Sponsored Link
Get an Online or Campus degree - Associate's, Bachelor's, or Master's - in less than one year.
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
--------------------------------- Everyone is raving about the all-new Yahoo! Mail.
This features comparisons are not to last for too long, some performance comparisons would also be nice. After all, there are plenty of UA-level stacks out there. At least now that both projects get to have stable releases after forking and some core functionality remained shared.
I wonder what "unbiased" organization will take up the challenge. :-)
On 11/8/06, Kim Il kim_il_s@yahoo.com wrote:
Mike,
this is a really good start and we should collect these things so as to help the community to take the right choice. I would also suggest that what ever ground breaking issues we list we stay at the functional level (I do not think anyone is helped by using a description containing "allowing carrier grade platforms" and similar marketing phrases).
cheers
{truncated because too large}
I can see what you are hinting at, but I guess that the users are the unbiased party that should do the judgment and not the parties who have something to gain.
cheers
Weiter Leiter bp4mls@googlemail.com wrote: This features comparisons are not to last for too long, some performance comparisons would also be nice. After all, there are plenty of UA-level stacks out there. At least now that both projects get to have stable releases after forking and some core functionality remained shared.
I wonder what "unbiased" organization will take up the challenge. :-)
On 11/8/06, Kim Il <kim_il_s@yahoo.com > wrote:Mike,
this is a really good start and we should collect these things so as to help the community to take the right choice. I would also suggest that what ever ground breaking issues we list we stay at the functional level (I do not think anyone is helped by using a description containing "allowing carrier grade platforms" and similar marketing phrases).
cheers {truncated because too large}
--------------------------------- Sponsored Link
Talk more and pay less. Vonage can save you up to $300 a year on your phone bill. Sign up now.
Common user barely has time to meet his boss requirements, rather than playing around with different scenarios, platforms, environments.
I only read one email where Daniel stated that OpenSER now performs a whole much better while loading users from database. SER guys put no figure out yet, neither bare numbers nor comparisons. I'm just really curious to see how both servers perform, that's all.
Even though I must maintain my SER, I kinda like OpenSER's faster releases and developers' responsiveness (that I shamelessly exploit for the common code left there :-), which is pretty much nonexistent with iptel (at least this is the general belief here at OpenSER). But about this I'll probably have to fight on SER's mailing list. I still wish that one day I won't have to compare features; heck, NetSER and FreeSER are still available ;-).
WL.
PS. Maybe regretfully, I haven't seen any iptel booth at von this year, while OpenSER guys put up a nice show. My congrats.
On 11/9/06, Kim Il kim_il_s@yahoo.com wrote:
I can see what you are hinting at, but I guess that the users are the unbiased party that should do the judgment and not the parties who have something to gain.
cheers
*Weiter Leiter bp4mls@googlemail.com* wrote:
This features comparisons are not to last for too long, some performance comparisons would also be nice. After all, there are plenty of UA-level stacks out there. At least now that both projects get to have stable releases after forking and some core functionality remained shared.
I wonder what "unbiased" organization will take up the challenge. :-)
On 11/8/06, Kim Il < kim_il_s@yahoo.com > wrote:
Mike,
this is a really good start and we should collect these things so as to help the community to take the right choice. I would also suggest that what ever ground breaking issues we list we stay at the functional level (I do not think anyone is helped by using a description containing "allowing carrier grade platforms" and similar marketing phrases).
cheers
{truncated because too large}
Sponsored Link
Talk more and pay less. Vonage can save you up to $300 a year on your phone bill. Sign up now.http://clk.atdmt.com/VON/go/yhxxxvon1080000017von/direct/01/
Mike Williams writes:
The new db mode allows me to have two OpenSER servers load balanced using just DNS SRV records and a mysql backend because any SIP transmission can go to either server, and any server can fail without effecting anything else.
mike,
how do yo handle NAT traversal if the server dies to which a UA behind a NAT has initiated the dialog?
-- juha
I made the switch to OpenSER for hard technical reasons (i simply could not implement the system i had designed using SER, i needed branch routes, pseudo variables, proper support for canceling transactions and a few other things), and i suggest that if you consider switching (in either direction) it should be for similarly "hard" reasons.
You mentioned that you switched to OpenSER because "rumor spread around on the openser lists that SER is no longer being maintained", i havn't heard this rumor but a simple glance at the CVS commit logs for the SER repositories would have shown this to be true or not (in this case, not). This is a very dangerous reason to switch!
I feel that both the SER and OpenSER teams are working hard on both "cosmetic and superficial changes" as well as "real improvements" and that is inaccurate to say that either is focusing on primarily on one of those things. SER is about to release a huge update to their software, containing a large number of additions, some inspired by work done on OpenSER, some completely new, its a certainty that you will see a similar occurrence in OpenSER once the new version of SER is released. Its only natural to build off of others work, it is what i regard to be humanities single biggest strength
Now OpenSER was created for a reason, and i'm certain that this reasoning still stands (if you havn't, i would urge you to read about it here: http://openser.org/index.php?option=com_content&task=view&id=40&...). If your requirements were met by the SER code base and their direction, time lines and philosophy aligned with your own, then rumors should not be enough to unsettle you. SER and OpenSER are both very solid projects (in my opinion) however they have different characteristics as such as better suited for different environments and situations. Regardless, the full merits of both applications should be evaluated when determining which to use for a project, not just surface level characteristics
I anticipate staying with OpenSER because of their short release cycle, eagerness to add features to their software and their direction, i'm certain that the upcoming release of SER will be very compelling (and of very high quality) but i already have plans in place following the OpenSER timelines (i'm very eager to begin writing modules to make use of the dialog module, i think this is really the killer app for OpenSER) however my requirements are fairly large and unique so they in no way apply to everyone
my few thoughts =D
tavis
Kim Il wrote:
Mike,
thanks a lot for your insight and the time you have taken to answer my question. I surely did not want to be unafir to anyone. I can not comment on the why the SER people are having only few releases compared to openser but I guess they have a good reason for that (I would guess it has something to do with thoroughness, testing ..., but I am here just guessing). For me and I guess many other people who depend on SER/openser for their business the more interesting question is what to use in the long term, which camp is the more innovative, is actually driving the change and is commiting itself to the really difficult tasks. Your statement that changes in SER have been in response to openser is surely a very good starting point -and if this is true then there is no reason to shift back to SER. Do you, or maybe other people, have more examples -besides the web page- for this. This will really help me to better judge the situation. Looking at the release notes of both openser and SER I am still of the opinion that compared to the new features of SER, most of the features that were added to openser in the last year are of cosmetic nature (hardly any touches the tough issues of security, performance and reliability).
Yours sincerely
Kim
*/Mike Williams mike@mikebwilliams.com/* wrote:
Kim, I don't think that's really a fair assessment of the situation. It seems to me, and others much more knowledgeable please comment on this, that OpenSER was forked because SER was left to stagnate, and because of a large number of feature patches that were just left to sit. The development cycles became too long, and it was unclear what the plan was. Looking back on the progress of OpenSER, one can see that the team didn't just take those patches and merge them, and pretend that they have a new product, but have instead continually developed the code base. The always have a roadmap of the next release, and an estimated timeline for completing it. A lot of important features have been added. Likewise, OpenSER seems to be using a different development philosophy. The OpenSER team releases .1 increment releases with new, useful, and stable features fairly often instead of waiting years. Since I've been using OpenSER, I've seen 3 releases. SER has put out 1 in that same time period, and honestly, I don't see the same amount of features really being added by SER. If anyone can compare the two in their present STABLE forms, I would really like to hear about it. In addition, it seems many of the changes to SER have been in response to OpenSER. Iptel/SER had the same website for years, with little information about what was actually happening. If you check the OpenSER website, they are always giving useful information and news to the users and community about going forward. Just in the last few months has Iptel/SER actually changed, no doubt partly due to how good OpenSER looked in comparison. Mike Williams On Wednesday 08 November 2006 04:06, Kim Il wrote: > thanks Rao for bringing this up. Actually our company has moved to openser > around 6 months ago after reading the rumor spread around on the openser > lists that SER is no longer being maintained. Looking now at the new SER I > must confess that we are more than impressed about the new features and > substantial changes to SER. It seems that, unlike openser, > the guys > behind SER spent the time not on cosmetic and superficial changes but on > real improvements. I assume this difference in working style comes from the > fact that openser is lead by a company that is capitalizing the open-source > spirit to satisfy the day-to-day needs of it customers whereas SER is being > maintained by guys who have a long term vision of things. While it will > surely cost us some time and effort for us the decision is already clear > that unless openser integrates the SER improvements we will go back to SER. > > Bye > > Kil Il > > Rao Ramaratnamma wrote: sorry for reposting -- I > think this question belongs to both mailing list. I am really stuck with > this. > > rr > > ----- Forwarded Message ---- > From: Rao Ramaratnamma > To: Christian Schlatter ; users@openser.org > Sent: Tuesday, November 7, 2006 11:15:27 PM > Subject: Re: [Users] TM : retransmission timers > > the ser ottendorf announcement does mention improved timers. Cannot openser > include this feature too and cannot I merge ser with openser for good > timers? I am still trying to understand the difference between ser and > openser but standart compliance seems to be very important matter! > > Cannot people provide me with some hints? I am sure that I am not the only > who is asking the difference between ser and openser. ser documentation > does not appear uptodate, but the software as sannounced appears > impressive. I have already asked this question but did not receive any > answer. > > thank you in advance! > > rr > > ----- Original Message ---- > From: Christian Schlatter > To: users@openser.org > Sent: Tuesday, November 7, 2006 10:52:56 PM > Subject: Re: [Users] TM : retransmission timers > > Greg Fausak wrote: > > Hello, > > > > I believe this is a well known bug. > > Granularity of timers is 1 second. So, if you sign up for a timer to > > be fired in 1 second it will happen anywhere between 0 seconds and 1 > > second. > > 2 seconds will happen between 1 and 2 seconds. I usually set up my > > timers to be 2, 2, 4, 8. There are VOIP providers that are pretty > > sticky about > > the first 500ms. If you are using one of them you're out of luck. > > Yes, there is a timer process that wakes up every second to perform > retransmissions. I was actually quite surprised that OpenSER, which is > known to be very standards compliant, does not follow the RFC 3261 > retransmission timeouts. On the other hand, the RFC 3261 timeout values > are just suggestions and standards compliant SIP UA must accept shorter > timeouts. Still it would be nice if OpenSER would support sub second > timers, this would allow for shorter fail-over times. > > Christian > > > I believe SER has made timer changes to support more exact timer > > intervals. They are a completely different camp, with a different > > feature set (although they share the same roots). > > > > -g > > > > On 11/7/06, Jean-François SMIGIELSKI wrote: > >> Hello, > >> > >> I made strange observations about the intervals between > >> retransmissions with the TM module. > >> In my experiments, I used the default parameters for the TM module > >> timers, and I sent an INVITE that cannot receive answers (it has a > >> well known R-URI pattern that is forwarded to a place and port that > >> nobody listen). > >> > >> When reading RFC3261, I expected to see intervals between > >> retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s. > >> > >> But with OpenSER, (I have tested with the debian package 1.1.0-5 on a > >> debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by > >> myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s > >> are spent (9 sendings). The first interval is sometomes very short > >> (40ms). > >> > >> Altough I like the sequence of 4s separated transmissions, I do not > >> know why the first interval is so short, and why there is no sending > >> after 1s. > >> > >> Did anybody observed such behaviours? Are they normal? > >> > >> Thanks in advance! > >> > >> JF Smigielski.
Tavis,
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. I am really glad that people are coming out and discussing the real merits and I hope this will lead to a better understanding of the two camps
bye Tavis P tavis.lists@galaxytelecom.net wrote:
You mentioned that you switched to OpenSER because "rumor spread around on the openser lists that SER is no longer being maintained", i havn't heard this rumor but a simple glance at the CVS commit logs for the SER repositories would have shown this to be true or not (in this case, not). This is a very dangerous reason to switch!
I feel that both the SER and OpenSER teams are working hard on both "cosmetic and superficial changes" as well as "real improvements" and that is inaccurate to say that either is focusing on primarily on one of those things. SER is about to release a huge update to their software, containing a large number of additions, some inspired by work done on OpenSER, some completely new, its a certainty that you will see a similar occurrence in OpenSER once the new version of SER is released. Its only natural to build off of others work, it is what i regard to be humanities single biggest strength
Now OpenSER was created for a reason, and i'm certain that this reasoning still stands (if you havn't, i would urge you to read about it here: http://openser.org/index.php?option=com_content&task=view&id=40&...). If your requirements were met by the SER code base and their direction, time lines and philosophy aligned with your own, then rumors should not be enough to unsettle you. SER and OpenSER are both very solid projects (in my opinion) however they have different characteristics as such as better suited for different environments and situations. Regardless, the full merits of both applications should be evaluated when determining which to use for a project, not just surface level characteristics
I anticipate staying with OpenSER because of their short release cycle, eagerness to add features to their software and their direction, i'm certain that the upcoming release of SER will be very compelling (and of very high quality) but i already have plans in place following the OpenSER timelines (i'm very eager to begin writing modules to make use of the dialog module, i think this is really the killer app for OpenSER) however my requirements are fairly large and unique so they in no way apply to everyone
my few thoughts =D
tavis
Kim Il wrote:
Mike,
thanks a lot for your insight and the time you have taken to answer my question. I surely did not want to be unafir to anyone. I can not comment on the why the SER people are having only few releases compared to openser but I guess they have a good reason for that (I would guess it has something to do with thoroughness, testing ..., but I am here just guessing). For me and I guess many other people who depend on SER/openser for their business the more interesting question is what to use in the long term, which camp is the more innovative, is actually driving the change and is commiting itself to the really difficult tasks. Your statement that changes in SER have been in response to openser is surely a very good starting point -and if this is true then there is no reason to shift back to SER. Do you, or maybe other people, have more examples -besides the web page- for this. This will really help me to better judge the situation. Looking at the release notes of both openser and SER I am still of the opinion that compared to the new features of SER, most of the features that were added to openser in the last year are of cosmetic nature (hardly any touches the tough issues of security, performance and reliability).
Yours sincerely
Kim
*/Mike Williams /* wrote:
Kim, I don't think that's really a fair assessment of the situation. It seems to me, and others much more knowledgeable please comment on this, that OpenSER was forked because SER was left to stagnate, and because of a large number of feature patches that were just left to sit. The development cycles became too long, and it was unclear what the plan was. Looking back on the progress of OpenSER, one can see that the team didn't just take those patches and merge them, and pretend that they have a new product, but have instead continually developed the code base. The always have a roadmap of the next release, and an estimated timeline for completing it. A lot of important features have been added. Likewise, OpenSER seems to be using a different development philosophy. The OpenSER team releases .1 increment releases with new, useful, and stable features fairly often instead of waiting years. Since I've been using OpenSER, I've seen 3 releases. SER has put out 1 in that same time period, and honestly, I don't see the same amount of features really being added by SER. If anyone can compare the two in their present STABLE forms, I would really like to hear about it. In addition, it seems many of the changes to SER have been in response to OpenSER. Iptel/SER had the same website for years, with little information about what was actually happening. If you check the OpenSER website, they are always giving useful information and news to the users and community about going forward. Just in the last few months has Iptel/SER actually changed, no doubt partly due to how good OpenSER looked in comparison. Mike Williams On Wednesday 08 November 2006 04:06, Kim Il wrote: > thanks Rao for bringing this up. Actually our company has moved to openser > around 6 months ago after reading the rumor spread around on the openser > lists that SER is no longer being maintained. Looking now at the new SER I > must confess that we are more than impressed about the new features and > substantial changes to SER. It seems that, unlike openser, > the guys > behind SER spent the time not on cosmetic and superficial changes but on > real improvements. I assume this difference in working style comes from the > fact that openser is lead by a company that is capitalizing the open-source > spirit to satisfy the day-to-day needs of it customers whereas SER is being > maintained by guys who have a long term vision of things. While it will > surely cost us some time and effort for us the decision is already clear > that unless openser integrates the SER improvements we will go back to SER. > > Bye > > Kil Il > > Rao Ramaratnamma wrote: sorry for reposting -- I > think this question belongs to both mailing list. I am really stuck with > this. > > rr > > ----- Forwarded Message ---- > From: Rao Ramaratnamma > To: Christian Schlatter ; users@openser.org > Sent: Tuesday, November 7, 2006 11:15:27 PM > Subject: Re: [Users] TM : retransmission timers > > the ser ottendorf announcement does mention improved timers. Cannot openser > include this feature too and cannot I merge ser with openser for good > timers? I am still trying to understand the difference between ser and > openser but standart compliance seems to be very important matter! > > Cannot people provide me with some hints? I am sure that I am not the only > who is asking the difference between ser and openser. ser documentation > does not appear uptodate, but the software as sannounced appears > impressive. I have already asked this question but did not receive any > answer. > > thank you in advance! > > rr > > ----- Original Message ---- > From: Christian Schlatter > To: users@openser.org > Sent: Tuesday, November 7, 2006 10:52:56 PM > Subject: Re: [Users] TM : retransmission timers > > Greg Fausak wrote: > > Hello, > > > > I believe this is a well known bug. > > Granularity of timers is 1 second. So, if you sign up for a timer to > > be fired in 1 second it will happen anywhere between 0 seconds and 1 > > second. > > 2 seconds will happen between 1 and 2 seconds. I usually set up my > > timers to be 2, 2, 4, 8. There are VOIP providers that are pretty > > sticky about > > the first 500ms. If you are using one of them you're out of luck. > > Yes, there is a timer process that wakes up every second to perform > retransmissions. I was actually quite surprised that OpenSER, which is > known to be very standards compliant, does not follow the RFC 3261 > retransmission timeouts. On the other hand, the RFC 3261 timeout values > are just suggestions and standards compliant SIP UA must accept shorter > timeouts. Still it would be nice if OpenSER would support sub second > timers, this would allow for shorter fail-over times. > > Christian > > > I believe SER has made timer changes to support more exact timer > > intervals. They are a completely different camp, with a different > > feature set (although they share the same roots). > > > > -g > > > > On 11/7/06, Jean-François SMIGIELSKI wrote: > >> Hello, > >> > >> I made strange observations about the intervals between > >> retransmissions with the TM module. > >> In my experiments, I used the default parameters for the TM module > >> timers, and I sent an INVITE that cannot receive answers (it has a > >> well known R-URI pattern that is forwarded to a place and port that > >> nobody listen). > >> > >> When reading RFC3261, I expected to see intervals between > >> retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s. > >> > >> But with OpenSER, (I have tested with the debian package 1.1.0-5 on a > >> debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by > >> myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s > >> are spent (9 sendings). The first interval is sometomes very short > >> (40ms). > >> > >> Altough I like the sequence of 4s separated transmissions, I do not > >> know why the first interval is so short, and why there is no sending > >> after 1s. > >> > >> Did anybody observed such behaviours? Are they normal? > >> > >> Thanks in advance! > >> > >> JF Smigielski.
--------------------------------- Everyone is raving about the all-new Yahoo! Mail beta.
Disclaimer: I am affiliated with SER, iptel.org and allthough attempting to give an objective account from a user perspective, I will probably be accused of being biased in many of the things I state. ------------- You may want to read the SER - Getting Started document http://www.iptel.org/ser/doc/gettingstarted and especially: http://siprouter.onsip.org/doc/gettingstarted/ch03.html
Since that was written, OpenSER has released 1.0 and 1.1, while SER is now about to release its first major release since the fork.
I haven't followed OpenSER closely, so I cannot speak for it, but SER's upcoming release addresses many of the major shortcomings found in SER/OpenSER's shared roots, i.e. SER 0.9.x. These changes include a major rewrite of timers, as well as big improvement in the database model.
AFAIK, the module interfaces are still fairly similar, but a major difference in how variables and message data is manipulated (thus causing modules to be different): openser has further developed the pseudo-variables introduced with avpops module, while SER has introduced selects. Which one you prefer is a matter of taste, but IMHO ser.cfg for upcoming SER is greatly easier to read, as well as maintain compared to the pseudo-variable approach, and it is my firm opinion that new users will find SER more intuitive to use when they start getting their teeth into SIP server configuration and maintenance.
As for documentation, the SER pre-release does not have complete documentation, and yes, the documentation effort is lagging behind a bit. I'm in charge of that effort, and the goal is to have a satisfactory set of documentation for the upcoming release. The last few months of improvements at iptel.org are evidence of that process. OpenSER has focused on documentation and seems to have a fairly good documentation.
Finally, to your wish of combining ser and openser: ser and openser have some shared modules, but only where the developers have commited to maintaining in both environments. The cores are by now also quite far apart. So, as each project has its own priorities, expect some features to developed in both (by different developers and different code), while other features to be only found in one.
In the end, it boils down to which piece of software you feel satisfies your needs, whether you have confidence in the project moving in the direction you need, and whether the project will deliver the software in a satisfactory, bug-free condition at the intervals you need. g-)
Rao Ramaratnamma wrote:
sorry for reposting -- I think this question belongs to both mailing list. I am really stuck with this.
rr
----- Forwarded Message ---- From: Rao Ramaratnamma raramarat@yahoo.com To: Christian Schlatter cs@unc.edu; users@openser.org Sent: Tuesday, November 7, 2006 11:15:27 PM Subject: Re: [Users] TM : retransmission timers
the ser ottendorf announcement does mention improved timers. Cannot openser include this feature too and cannot I merge ser with openser for good timers? I am still trying to understand the difference between ser and openser but standart compliance seems to be very important matter!
Cannot people provide me with some hints? I am sure that I am not the only who is asking the difference between ser and openser. ser documentation does not appear uptodate, but the software as sannounced appears impressive. I have already asked this question but did not receive any answer.
thank you in advance!
rr
----- Original Message ---- From: Christian Schlatter cs@unc.edu To: users@openser.org Sent: Tuesday, November 7, 2006 10:52:56 PM Subject: Re: [Users] TM : retransmission timers
Greg Fausak wrote:
Hello,
I believe this is a well known bug. Granularity of timers is 1 second. So, if you sign up for a timer to be fired in 1 second it will happen anywhere between 0 seconds and 1 second. 2 seconds will happen between 1 and 2 seconds. I usually set up my timers to be 2, 2, 4, 8. There are VOIP providers that are pretty sticky about the first 500ms. If you are using one of them you're out of luck.
Yes, there is a timer process that wakes up every second to perform retransmissions. I was actually quite surprised that OpenSER, which is known to be very standards compliant, does not follow the RFC 3261 retransmission timeouts. On the other hand, the RFC 3261 timeout values are just suggestions and standards compliant SIP UA must accept shorter timeouts. Still it would be nice if OpenSER would support sub second timers, this would allow for shorter fail-over times.
Christian
I believe SER has made timer changes to support more exact timer intervals. They are a completely different camp, with a different
feature
set (although they share the same roots).
-g
On 11/7/06, Jean-François SMIGIELSKI jf-smig@ibelgique.com wrote:
Hello,
I made strange observations about the intervals between retransmissions with the TM module. In my experiments, I used the default parameters for the TM module timers, and I sent an INVITE that cannot receive answers (it has a well known R-URI pattern that is forwarded to a place and port that nobody listen).
When reading RFC3261, I expected to see intervals between retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during
32s.
But with OpenSER, (I have tested with the debian package 1.1.0-5 on a debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s are spent (9 sendings). The first interval is sometomes very short (40ms).
Altough I like the sequence of 4s separated transmissions, I do not know why the first interval is so short, and why there is no sending after 1s.
Did anybody observed such behaviours? Are they normal?
Thanks in advance!
JF Smigielski.
iBELGIQUE, exprimez-vous ! http://web.ibelgique.com/
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Greger V. Teigre -
Juha Heinanen -
Kim Il -
Mike Williams -
Rao Ramaratnamma -
Tavis P -
Weiter Leiter