[asterisk-dev] Bounty

Thu Feb 25 01:28:24 CST 2010

Hi!

> Every packet that arrives goes through a logic, otherwise how woud we know
> that a BYE arrived. We need to intercept that logic and interrupt a timer
> that is running before it closes the call. That is how I see it. I wanted to
> pay Digium to dio this today and they turned me down, even knowing that I
> have the Business Edition. How does Digium expects that we in the Enterprise
> take Asterisk seriously if there is no way to hire a developer to add what
> is so obviously needed that every single use would benefit from it. Cisco
> IOS, for instance, has this timer.  We are the industry, and Digium must do
> what we need, and charge us for it. This seriously damages the whole idea of
> open source telecommunications. They did not give me a price, just said "we
> don't do that". This is unacceptable.
> Yours
> Federico
> 

Am I right, that you need this timer ?
timerb=32000                   ; Call setup timer. If a provisional response is not received
                               ; in this amount of time, the call will autocongest
                               ; Defaults to 64*timert1

This is a standard feature in 1.6 (I don't know, whether it is in 1.4, but
from your request here I think that it isn't). So, please, feel free to
upgrade your system to the current version and enjoy the feature!
  Now, I can imagine your complaints that you simply cannot upgrade for this
reason and that reason etc. However, I'm quoting your "We are the industry, and
Digium must do what we need, and charge us for it". It's not going this way in
the Telco industry, believe me :-). I work as a voice services senior developer
for major telco in Czech Republic. We are using many switches and other types of
telco equipment from established companies (Siemens: EWSD, Nortel: DMS100 and
CS2K, Cisco, TTC Marconi etc.). Almost always, when we need to incorporate a new
feature, our supplier tells us: This feature has been incorporated into the 
mainline image in version x.y. You're runnig p.q, where p<x. Please upgrade to
x.y. They are even forcing us to upgrade to the new version even when we are
satisfied with the old one, just by dropping support for it etc. I think that
Digium is doing their things well, much better than those big companies, 
because they don't drop their support of older releases, they are at least
fixing bugs etc. I'm afraid that "must" is not a good word to describe what
they have or have not to do, at least I suppose that you didn't sign any
agreement with them which explicitly states their duty to do it...
  The last word: The Open Source advantage is, that you have the source code
available and you can either fix these things yourself (it will not be so
hard, because the solution is already there, it's just about backporting it
to the older version), or hire somebody to do it for you. In the case of closed
source, you would have to ask just Digium. 

With regards, Pavel

> On Wed, Feb 24, 2010 at 8:47 PM, Alex Balashov <abalashov at evaristesys.com>wrote:
> 
> > No.
> >
> > On 02/24/2010 08:39 PM, Denis Galvao wrote:
> >
> > > Is this possible to extract the ringing state from a 183 sip header?
> > >
> > > I mean, is this possible to know if the far end is ringing through a
> > > 183 message?
> > >
> > > Denis.
> > >
> > > 2010/2/24, Alex Balashov<abalashov at evaristesys.com>:
> > >> Who told you that you're always going to get a 180 Ringing reply?
> > >>
> > >> Most providers that provide PSTN trunking will give you ringback as
> > >> in-band via an early dialog (183 Session in Progress).  With some
> > >> calls, you may just get a provisional 100 Trying reply and then
> > >> nothing until a sudden 200 OK.  There are many possible flows and
> > >> scenarios.
> > >>
> > >> On 02/24/2010 07:59 PM, CDR wrote:
> > >>
> > >>> I need a new Timeout parameter added to the Dial application, for SIP
> > >>> dialing. The new timeout would be "first-ring" timeout, as opposed to
> > >>> timeout for connection. If we don't get a 180 Ringing message before a
> > >>> certain amount of seconds, the call fails. This a needed addition to
> > >>> Asterisk. I need this in version 1.4 and cannot wait the normal time
> > for
> > >>> a "new feature" process to complete. The rationale is clear: many
> > >>> carriers will hold the call indefinitely, instead of returning a 503.
> > If
> > >>> the call is ringing, then I don't care if it rings for 60 seconds, but
> > >>> if there is no ringback before 6 seconds, I need yo try another carrier
> > >>> and move on.
> > >>>
> > >>> Please contact me at nine five four 444 seven 4 zero 8
> > >>>
> > >>
> > >>
> > >> --
> > >> Alex Balashov - Principal
> > >> Evariste Systems LLC
> > >>
> > >> Tel    : +1 678-954-0670
> > >> Direct : +1 678-954-0671
> > >> Web    : http://www.evaristesys.com/
> > >>
> > >> --
> > >> _____________________________________________________________________
> > >> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> > >>
> > >> asterisk-dev mailing list
> > >> To UNSUBSCRIBE or update options visit:
> > >>     http://lists.digium.com/mailman/listinfo/asterisk-dev
> > >>
> > >
> >
> >
> > --
> > Alex Balashov - Principal
> > Evariste Systems LLC
> >
> > Tel    : +1 678-954-0670
> > Direct : +1 678-954-0671
> > Web    : http://www.evaristesys.com/
> >
> > --
> > _____________________________________________________________________
> > -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-dev
> >

> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev