A brief update for those who are interested.
This turned out to be my problem (DOH!). After doing a PRI debug on the
span on
the telco side to a log file, I found that the 'Unable to forward voice'
message corresponded one for one with the following progress message:
< Message type: PROGRESS (3)
< [08 02 84 81]
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location:
Public network serving the remote user (4)
< Ext: 1 Cause: Unallocated (unassigned) number (1), class
Normal Event (0) ]
In other words, it looks like the failed calls are failing because the numbers
are invalid. I verified this with a regular POTS phone on a few, and that was,
in fact, the case.
A suggestion, if anyone is interested, would be that 'Unable to forward
voice'
is maybe not the best message for app_dial to put in the asterisk log
when this
condition occurrs. It would have been nice (and easier to figure out) if what
went into the log was something more along the lines of the actual cause for
what happened.
Thanks,
Christian
Quoting "Christian M. Watts" <cmwatts@ecdatasys.com>:
> Hi,
>
> We've exhausted our internal capabilities as well as Sangoma tech
support and
> were hoping someone with some expertise could help us with a pointer.
> Briefly,
> our issue is as follows.
>
> Periodically (several times an hour), we get either of the following error
> messages in our asterisk messages log. These correspond with dropped
outbound
> calls on a one-to-one basis when the second error happens. The first error
> sometimes causes a dropped call and sometimes does not:
>
> Jun 30 16:40:27 WARNING[5395] app_dial.c: Unable to forward frame
> Jun 30 16:45:07 WARNING[5455] app_dial.c: Unable to forward voice
>
>
> Our hardware is as follows:
>
> Compaq DL380 Dual PIII 1Ghz, 1.2 GB RAM, Onboard SmartArray for SCSI RAID
> Sangoma A102U dual-port T1 card
> Digi Datafire T1 fax/modem board
>
>
> Our software is as follows:
>
> Linux 2.4.30
> Asterisk, Zaptel and Libpri from CVS HEAD as of 6/28/05
> Sangoma wanpipe 2.3.3-beta11 (latest as of this post)
> Patton electronic's latest drivers and firmware for our Digi Datafire
board
> (still no 2.6 Linux support, which is why we're on 2.4)
> Hylafax 4.2.1 driving the Digi Datafire
>
>
> The path (for the problem calls) looks like this:
>
> Digi Datafire -> Sangoma Port B -> Sangoma Port A -> Telco
>
> Basically, sending a fax over a PRI with asterisk doing TDM bridging in the
> middle.
>
>
> We have confirmed the following (based on similar posts to this list
> related to
> the same problem with Digium boards as well as Sangoma tech support
> assistance):
>
> 1. Sangoma Port A takes clocking from the telco
> 2. Sangoma Port B retransmits A's clocking and acts as master
> 3. Sangoma tech support says our configs are correct
> 4. Zaptel.conf is set up with Sangoma Port A as the primary clock source,
and
> Port B to not be used as a clock source
> 5. LBO, switch options, etc. are correct for the environment (since 98% of
> outbound calls are fine, this seems fairly obvious)
> 6. ISDN Transfer Capability gets properly set to 3K1AUDIO for calls
> 7. No IRQ sharing on the system
> 8. IDE DMA mode is irrelevant, since there are no IDE disks in the
> system (other
> than the CDROM)
>
>
> We have tried the following:
>
> 1. Asterisk, libpri and zaptel versions from 6/1/2005, 6/15/2005 and
> 6/28/2005 -
> no change in behavior
> 2. Wanpipe drivers 2.3.3-beta8 and 2.3.3-beta11 - no change in behavior
> 3. Wanpipe configured both with and without the D-Channel hardware HDLC -
no
> change in behavior
> 4. Firmware versions 24 (shipped version) and 25 (latest version) on
> the Sangoma
> card - no change in behavior
> 5. callprogress and busydetect both 'yes' and 'no' in
zapata.conf (currently
> 'no') - no change in behavior
> 6. Added SetTransferCapability(3K1AUDIO) to our dialplan, just to be
> sure - no
> change in behavior
>
>
> General environment:
>
> 1. We run TDM only, no VoIP protocols are in use. SIP, IAX2, MGCP are
> all noload
> in modules.conf.
> 2. This problem occurs with as few as one simultaneous channel active and
as
> many as 15 simultaneous channels active with equal frequency (i.e.: not
load
> related). The load on the box is negligible in any case, plenty of
> RAM is free,
> etc.
> 3. Restarting asterisk does seem to cause the problem not to
> re-present itself
> for 30 minutes to 2 hours. When asterisk is restarted, the Sangoma and
Zaptel
> kernel modules are also unloaded and reloaded.
>
>
> Again, any pointers or help would be greatly appreciated.
>
> Thanks,
> Christian
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
Christian Watts
EC Data Systems, Inc.
303.991.6020 - Voice
303.991.6021 - Fax