I don´t think that you read the bugs. Several months ago I opened a bug about version 1.6 running out of UDP ports. It has not been fixed. I will jump to it as soon as I do´t have to restart the whole box every hour.<div><a href="https://issues.asterisk.org/view.php?id=16774">https://issues.asterisk.org/view.php?id=16774</a> </div>
<div><br><br><div class="gmail_quote">On Thu, Feb 25, 2010 at 2:28 AM, Pavel Troller <span dir="ltr"><<a href="mailto:patrol@sinus.cz">patrol@sinus.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi!<br>
<div class="im"><br>
> Every packet that arrives goes through a logic, otherwise how woud we know<br>
> that a BYE arrived. We need to intercept that logic and interrupt a timer<br>
> that is running before it closes the call. That is how I see it. I wanted to<br>
> pay Digium to dio this today and they turned me down, even knowing that I<br>
> have the Business Edition. How does Digium expects that we in the Enterprise<br>
> take Asterisk seriously if there is no way to hire a developer to add what<br>
> is so obviously needed that every single use would benefit from it. Cisco<br>
> IOS, for instance, has this timer. We are the industry, and Digium must do<br>
> what we need, and charge us for it. This seriously damages the whole idea of<br>
> open source telecommunications. They did not give me a price, just said "we<br>
> don't do that". This is unacceptable.<br>
> Yours<br>
> Federico<br>
><br>
<br>
</div>Am I right, that you need this timer ?<br>
timerb=32000 ; Call setup timer. If a provisional response is not received<br>
; in this amount of time, the call will autocongest<br>
; Defaults to 64*timert1<br>
<br>
This is a standard feature in 1.6 (I don't know, whether it is in 1.4, but<br>
from your request here I think that it isn't). So, please, feel free to<br>
upgrade your system to the current version and enjoy the feature!<br>
Now, I can imagine your complaints that you simply cannot upgrade for this<br>
reason and that reason etc. However, I'm quoting your "We are the industry, and<br>
Digium must do what we need, and charge us for it". It's not going this way in<br>
the Telco industry, believe me :-). I work as a voice services senior developer<br>
for major telco in Czech Republic. We are using many switches and other types of<br>
telco equipment from established companies (Siemens: EWSD, Nortel: DMS100 and<br>
CS2K, Cisco, TTC Marconi etc.). Almost always, when we need to incorporate a new<br>
feature, our supplier tells us: This feature has been incorporated into the<br>
mainline image in version x.y. You're runnig p.q, where p<x. Please upgrade to<br>
x.y. They are even forcing us to upgrade to the new version even when we are<br>
satisfied with the old one, just by dropping support for it etc. I think that<br>
Digium is doing their things well, much better than those big companies,<br>
because they don't drop their support of older releases, they are at least<br>
fixing bugs etc. I'm afraid that "must" is not a good word to describe what<br>
they have or have not to do, at least I suppose that you didn't sign any<br>
agreement with them which explicitly states their duty to do it...<br>
The last word: The Open Source advantage is, that you have the source code<br>
available and you can either fix these things yourself (it will not be so<br>
hard, because the solution is already there, it's just about backporting it<br>
to the older version), or hire somebody to do it for you. In the case of closed<br>
source, you would have to ask just Digium.<br>
<br>
With regards, Pavel<br>
<div><div></div><div class="h5"><br>
<br>
> On Wed, Feb 24, 2010 at 8:47 PM, Alex Balashov <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>>wrote:<br>
><br>
> > No.<br>
> ><br>
> > On 02/24/2010 08:39 PM, Denis Galvao wrote:<br>
> ><br>
> > > Is this possible to extract the ringing state from a 183 sip header?<br>
> > ><br>
> > > I mean, is this possible to know if the far end is ringing through a<br>
> > > 183 message?<br>
> > ><br>
> > > Denis.<br>
> > ><br>
> > > 2010/2/24, Alex Balashov<<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>>:<br>
> > >> Who told you that you're always going to get a 180 Ringing reply?<br>
> > >><br>
> > >> Most providers that provide PSTN trunking will give you ringback as<br>
> > >> in-band via an early dialog (183 Session in Progress). With some<br>
> > >> calls, you may just get a provisional 100 Trying reply and then<br>
> > >> nothing until a sudden 200 OK. There are many possible flows and<br>
> > >> scenarios.<br>
> > >><br>
> > >> On 02/24/2010 07:59 PM, CDR wrote:<br>
> > >><br>
> > >>> I need a new Timeout parameter added to the Dial application, for SIP<br>
> > >>> dialing. The new timeout would be "first-ring" timeout, as opposed to<br>
> > >>> timeout for connection. If we don't get a 180 Ringing message before a<br>
> > >>> certain amount of seconds, the call fails. This a needed addition to<br>
> > >>> Asterisk. I need this in version 1.4 and cannot wait the normal time<br>
> > for<br>
> > >>> a "new feature" process to complete. The rationale is clear: many<br>
> > >>> carriers will hold the call indefinitely, instead of returning a 503.<br>
> > If<br>
> > >>> the call is ringing, then I don't care if it rings for 60 seconds, but<br>
> > >>> if there is no ringback before 6 seconds, I need yo try another carrier<br>
> > >>> and move on.<br>
> > >>><br>
> > >>> Please contact me at nine five four 444 seven 4 zero 8<br>
> > >>><br>
> > >><br>
> > >><br>
> > >> --<br>
> > >> Alex Balashov - Principal<br>
> > >> Evariste Systems LLC<br>
> > >><br>
> > >> Tel : +1 678-954-0670<br>
> > >> Direct : +1 678-954-0671<br>
> > >> Web : <a href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a><br>
> > >><br>
> > >> --<br>
> > >> _____________________________________________________________________<br>
> > >> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
> > >><br>
> > >> asterisk-dev mailing list<br>
> > >> To UNSUBSCRIBE or update options visit:<br>
> > >> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
> > >><br>
> > ><br>
> ><br>
> ><br>
> > --<br>
> > Alex Balashov - Principal<br>
> > Evariste Systems LLC<br>
> ><br>
> > Tel : +1 678-954-0670<br>
> > Direct : +1 678-954-0671<br>
> > Web : <a href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a><br>
> ><br>
> > --<br>
> > _____________________________________________________________________<br>
> > -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
> ><br>
> > asterisk-dev mailing list<br>
> > To UNSUBSCRIBE or update options visit:<br>
> > <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
> ><br>
<br>
</div></div>> --<br>
<div><div></div><div class="h5">> _____________________________________________________________________<br>
> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
><br>
> asterisk-dev mailing list<br>
> To UNSUBSCRIBE or update options visit:<br>
> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br></div>