similar to: Inband SIP DTMF

I've encountered an odd situation with Asterisk 1.4.19 that I can't figure out. If I dial an extension via a Cisco AS5400 with the "g" option to come back, when I then Dial another extension after that, we don't get audio from the caller. There are no firewalls, no routers, no anything but a network switch between. The calls come in as SIP from the Cisco and

Has anyone got a Premisys Slimline channel bank working with a Cisco AS5400 or similar? I'm not sure if my unit is bad, or what. I'm using FXS Loop Start. Calling the port connects immediately without ringing the attached phone. If I pick up the phone, it's connected and I can talk to the caller. Hanging up has no effect. I can see the bit transitions (0101 to 1111 when I go

On Mar 19, 2008, at 1:00 PM, asterisk-users-request at lists.digium.com wrote: > Am I expecting too much? Perhaps. I think the hardware on which we run Asterisk can be much more reliable than the software, which is often the case. We have a bunch of HP servers with RAID and have never lost anything. A HD may fail, but the RAID keeps it going until we pop a new drive in there. A

On Oct 16, 2008, at 2:36 AM, asterisk-users-request at lists.digium.com wrote: > I want to call an extension like 88888 and invoke an external C > program upon > calling, pass an constant integer like 1 to the C program. > > What I have done is: > > /etc/extensions.conf: > exten => 88888,1,system(/usr/local/src/parallel/fire 1) > exten => 88888,n,

All too common and largely undocumented. I had this same problem. Installing ztdummy changes Asterisk to use it for timing of playback, apparently. Removing ztdummy "fixed" the problem. To get it all to work, I had to upgrade to to at least kernel 2.6.23.11 (previous versions are either missing options are just broken.) After doing this, I recompiled ztdummy and it worked. Note

>> All too common and largely undocumented. I had this same problem. >> >> Installing ztdummy changes Asterisk to use it for timing of playback, >> apparently. Removing ztdummy "fixed" the problem. To get it all to >> work, I had to upgrade to to at least kernel 2.6.23.11 (previous >> versions are either missing options are just broken.) > >

On Mar 5, 2008, at 5:46 PM, asterisk-users-request at lists.digium.com wrote: > If you are running a call centre (large or small) using Asterisk, > I'd be > interested to know how you log your agents in & out: > > E.g. > > - Do you use AgentLogin (to force calls onto the agents, perhaps)? > - Do you still use AgentCallbackLogin? > - If you use

Note that the newish SPA962 has 6 appearances and a color screen. I've noticed that the bright color screen does impress people when they first see it. PoE is also very nice and web provisioning was quite easy. I've yet to try a more automated provisioning method on it. I know that getting the polycom's to auto provision wasn't very straight forward. I do provision some

Is there any known reason that the DISA() routine should behave differently than WaitExten() as far as recognizing DTMF tones? If not, I suspect there's a bug here. Try it yourself--two DID's on our PRI, numbers below let you test each routine: It is my observation that some setups/phones DO and some DO NOT express this variance. --I could not show any variance on a sprint mobile phone

Hi can anyone help me on this error msg?? dsp.c:1467 ast_dsp_process: Unable to process inband DTMF on 2 frames thnx St

Using FireFly, all other codecs but G711 Ulaw is selected. But whenever I place a call, I get: Jan 24 16:07:06 WARNING[30654495]: dsp.c:1468 ast_dsp_process: Inband DTMF is not supported on codec G.711 u-law. Use RFC2833 Umm, wtf? I thought Inband was ONLY supported on G.711 u-law. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Is it possible to make Asterisk do inband DTMF over IAX?

Are there any known problems converting dtmf from oob over iax2 to inband over rtp/ulaw? Obviously it works when converting to inband over pri/ulaw et al, but how about rtp? I've got packet traces that confirm that 2833 packets are properly generated when I have 2833 configured for the rtp link, but the other side seems to be ignoring those packets. So I tried inband on that link; nothing

Hi, I'm getting unreliable dtmf recognition (it works fine for 4-5 digits, errors (duplicates) on more), when transferred inband from gsm gateway to NT port of quadbri under bristuffed Asterisk..... Since Asterisk is claimed to have good dtmf recognizer, I suspect there are some settings to workarouned... I've tried dtmf relax, but didn't help, so I suspect gain settings.... Is

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Max Glucksmann (Fax del trabajo).vcf Type: text/x-vcard Size: 617 bytes Desc: not available Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20060118/b1b5e895/MaxGlucksmannFaxdeltrabajo.vcf

Hi all. Why don't Asterisk support inband DTMF with G729? Is there a way to do that!? Are you using RFC2833? Doesn't it a security hole? Thanks. Denis.

I'm trying to use H323 for the first time so please forgive me if I've made a mistake here. I have downloaded and compiled the latest versions of pwlib, openh323 and asterisk. I have dtmfmode=inband in h323.conf, but the remote system is not hearing the DTMF. Running a trace reveals the following... 1:08.398 ThreadID=0x00022012 h323.cxx(4594) H323

Hi All, Since I updated my * (CVS 2004-03-24), daily, I am getting a strange message just before a segmentation fault: "Unable to process inband DTMF on 2 frames". What could it be? Should it cause seg.faults? Daniel

Hi all, I use a GSM device to send dtmf on my asterisk system (via SIP). the codec I use is ulaw (or a-law). dtmf mode is INBAND. relaxmode is on. but most of the case, I 'missed' some DTMF or I 'double' one. as anybody as seen this before? is there any way to prevent this thanks

Hi, we have an Asterisk server basically passing on calls using the Dial application. In the pjsip endpoint settings, the dtmf_mode is set to audio. This works with most calls. However, there is a scenario where DTMF tones don't get forwarded the way I would expect them to get forwarded. A: Caller without RfC4733 support B: our Asterisk, version 17.6.0 C: Another Asterisk, with RfC4733