similar to: 10-rc2: how to debug dropped calls?

On a test fax: -- Executing [s at incoming-fax:1] Set("DAHDI/4-1", "FAXFILE=/var/spool/asterisk/fax/20110415_1825") in new stack -- Executing [s at incoming-fax:2] Answer("DAHDI/4-1", "") in new stack -- Executing [s at incoming-fax:3] ReceiveFAX("DAHDI/4-1", "/var/spool/asterisk/fax/20110415_1825.tif") in new stack

On 12/19/2014 09:42 AM, Rusty Newton wrote: > On Wed, Dec 17, 2014 at 1:09 PM, sean darcy <seandarcy2 at gmail.com> wrote: >> I've got a confbridge set up which works if dialed locally: >> >> -- Executing [266 at internal:1] Answer("DAHDI/1-1", "") in new stack >> -- Executing [266 at internal:2] SendDTMF("DAHDI/1-1",

Have you enabled DTMF logging and seen the DTMF codes being recognised by Asterisk? I had a bunch of soft phones that I had to change to using ?sip info? for the DTMF signalling as the RFC signalling was not always being recognised. This would cause transfers to appear as if the user had not dialled any digits. On 20/12/2014 20:52, "sean darcy" <seandarcy2 at gmail.com> wrote:

On 12/21/2014 11:09 AM, sean darcy wrote: > On 12/21/2014 04:42 AM, Patrick Beaumont wrote: >> Have you enabled DTMF logging and seen the DTMF codes being recognised by >> Asterisk? I had a bunch of soft phones that I had to change to using ?sip >> info? for the DTMF signalling as the RFC signalling was not always being >> recognised. This would cause transfers to appear

On 12/21/2014 04:42 AM, Patrick Beaumont wrote: > Have you enabled DTMF logging and seen the DTMF codes being recognised by > Asterisk? I had a bunch of soft phones that I had to change to using ?sip > info? for the DTMF signalling as the RFC signalling was not always being > recognised. This would cause transfers to appear as if the user had not > dialled any digits. > > >

I've got a confbridge set up which works if dialed locally: -- Executing [266 at internal:1] Answer("DAHDI/1-1", "") in new stack -- Executing [266 at internal:2] SendDTMF("DAHDI/1-1", "1") in new stack -- Executing [266 at internal:3] ConfBridge("DAHDI/1-1", "1") in new stack -- <DAHDI/1-1> Playing

I am unable to dial out over a Wildcard TDM400P. This was working previously, so must have messed up the config somehow. I'm running Asterisk 1.6.0.15, with FreePBX 2.5.2.2. When I dial, I see: -- Executing [s at macro-dialout-trunk:19] Dial("DAHDI/1-1", "DAHDI/g0/9239220,300,") in new stack == Everyone is busy/congested at this time (1:0/1/0) It looks like the

As best i could figure it out, I've installed dahdi and rc4. My TDM400P doesn't answer fxo or fxs. /etc/dahdi/system.conf: loadzone = us defaultzone=us fxoks=1,2 fxsks=4 /etc/asterisk/chan_dahdi.conf: [house-phones] context=internal ; Uses the [internal] context in extensions.conf signalling=fxo_ks ; fxo_ks Use FXO signalling for an FXS chanel dahdichan => 1 ;

On 12/20/2014 03:22 PM, sean darcy wrote: > On 12/19/2014 09:42 AM, Rusty Newton wrote: >> On Wed, Dec 17, 2014 at 1:09 PM, sean darcy <seandarcy2 at gmail.com> wrote: >>> I've got a confbridge set up which works if dialed locally: >>> >>> -- Executing [266 at internal:1] Answer("DAHDI/1-1", "") in new stack >>> --

I have two internal analogue extensions off a TDM400P. If the first is busy, I'd like to ring the second. So: [incoming] exten =>s,1,Answer() exten =>s,n,Dial(${mainline},60) exten =>s,n,ExecIf($["${DIALSTATUS}" = "BUSY"]?Dial(${secondline},30)) But it doesn't work because * first tries Call Waiting on the main line. Here I dial out: -- Starting

pstn incoming on a TDM400P, sometimes i* won't answer, going into a loop like this: -- Starting simple switch on 'DAHDI/4-1' [Jan 16 10:38:55] NOTICE[5808]: chan_dahdi.c:7130 ss_thread: Got event 18 (Ring Begin)... [Jan 16 10:38:57] NOTICE[5808]: chan_dahdi.c:7130 ss_thread: Got event 2 (Ring/Answered)... [Jan 16 10:38:57] NOTICE[5808]: chan_dahdi.c:7299 ss_thread: MWI: Channel 4

From asterisk -cvvvvv == Parsing '/etc/asterisk/chan_dahdi.conf': == Found == Parsing '/etc/asterisk/users.conf': == Found -- Automatically generated pseudo channel [Nov 11 17:43:28] WARNING[5756]: chan_dahdi.c:18155 process_dahdi: Ignoring any changes to 'userbase' (on reload) at line 23. [Nov 11 17:43:28] WARNING[5756]: chan_dahdi.c:18155 process_dahdi:

On Wed, Dec 17, 2014 at 1:09 PM, sean darcy <seandarcy2 at gmail.com> wrote: > I've got a confbridge set up which works if dialed locally: > > -- Executing [266 at internal:1] Answer("DAHDI/1-1", "") in new stack > -- Executing [266 at internal:2] SendDTMF("DAHDI/1-1", "1") in new stack > -- Executing [266 at internal:3]

Here's a call coming in over PSTN to dahdi/4, connected to a local extension dahdi/1: -- Executing [s at incoming-pstn-line:1] Answer("DAHDI/4-1", "") in new stack .......... -- Executing [s at incoming-pstn-line:6] Dial("DAHDI/4-1", "DAHDI/g0,36") in new stack -- Called g0 -- DAHDI/1-1 is ringing -- DAHDI/1-1 is ringing

Specs FC2, Asterisk 1.0.0, Zaptel 1.0.0 TDM400P Port 1 FXS Port 4 FXO Standard analogue handset plugged in with pstn line. Problem: When I go to dialout it drops numbers on the outgoing number. Keys dialed from handset were 9 0418800185 I tried hitting the keys slowly as well as at my normal speed, all tones are heard in the handset for all numbers.

I am having problems getting a Nicherons TDM400P wildcard clone to dial out. Everything appears to be configured correctly, but although I see call progress, it never seems to actually pick up the phone. (The following is a test of 911 emergency, where I substitute 811 [repair service] as the actual number dialed.) *CLI> -- Executing [911 at from-internal:1]

Does anyone know what this error message means? Unable to create channel of type 'DAHDI' (cause 0 - Unknown) I've upgraded to 1.6.0 with dahdi 2.0. For some reason my outbound dahdi calls are not going through. At some point, it starts to work, but I don't know what the trigger is. Out of the blue, outbound calls start to work. I had been using asterisk-1.6-beta9 with zaptel

This is a small 12 line system, internal extensions 150 - 180. I didn't have a phone on 151. Here's the sip.conf stanza: ;;[151] ;;type=friend ;;context=longdistance ;;callerid="Conf Room" <151> ;;secret=0000 ;;host=dynamic ;;qualify=yes ;;dtmfmode=rfc2833 ;;allow=all ;;defaultuser=151 ;;nat=yes ;;canreinvite=no There's no DISA. And then somehow (how???) ip address

I'm attempting to convert from ZAP to DAHDI with 1.6.0. I was using 1.6.0-beta9. I followed the directions I could find. I moved /etc/zapata to /etc/dahdi/system.conf I moved /etc/asterisk/zapata.conf to /etc/asterisk/chan_dahdi.conf I don't undestand how to deal with extensions.conf? I replaced Dial (ZAP/ ...) with Dial (DAHDI/ ... ) All my inbound calls from DAHDI work the same as

Hi: I am useing asterisk 11.12. I use G722 as preferred codec for my ip-phone. and my PSTN DAHDI use alaw. G722 is great when ip-phone talks to each other. but when ip-phone dialout to PSTN DAHDI, G722 is not great, since it is need to transcode to alaw. so I try to change the codec when dial from SIP to DAHDI. I tried to use IP_CODEC/SIP_CODEC_OUTBOUND at dialplan. but the SIP