PSTN - Outbound Local Call Problem

daveofca
Posts: 2
Member Since:
2009-02-05

Hi - I am new to Trixbox but have read several articles in the forum in trying to solve this issue and can't seem to locate a solution.

A200 with 4 FXO connected to 4 lines inbound from local carrier. Can receive calls from all 4 lines but cannot seem to dial out from any of them.

I correctly installed the sangoma card, but cannot for the life of me figure out how to ensure the DMTF signals are kicked over to the PSTN without resulting in a "we're sorry, your call did not go through..."

I added the relaxeddtmf entry, but still no resolution. It seems as though the PSTN lines may not be getting the entire DMTF signal as it is kicked out pretty quick at the beginning of the call, but I am not sure if I am even on the right track.

I am excited to get this system into production in a small business office with only a few sip softphones.

Any assistance would be greatly appreciated.



SkykingOH
Posts: 9541
Member Since:
2007-12-17
Can you please post some

Can you please post some call logs. Look at the sticky thread "We are not dentist's" for information on how to ask for help and what information we need.

I doubt it is a DTMF speed issue. The relaxdtmf parameter is only related to DTMF detection.

--

Scott

aka "Skyking"



jingxi02
Posts: 136
Member Since:
2007-05-19
General field problem

This is a general problem when deploying PBX with analog trunk. The problem caused by the the following conditions.

1. The PTSN line from your carrier needs to have a short moment to handshake the signal with the CPE.
2. The FXO interface sends the dialing digits down to the PSTN line too early.

Basically the PSTN circuit is analog. When an analog interface needs to communicate over coper wire, it needs to handshake. It just exeactly like when our Modem dialing the ISP for internet access in the old day, the Modem mades the handshake noise for a few seconds before it can connect. The FXO interface and the PSTN line does the samething but just much shorter. It may take a few millisecond to half second before the line is cleared to accept the dialing digits. This handshake timing is very depanding on the line condition.

When you making a call in Trixbox, the Asterisk processes the digits and have the Zaptel picks up a port to send the digit down. The Zaptel module opens the first available port on the FXO interface (Off hook). If no other instruction is given, the Asterisk will start sending the digits down to the line. It doesn't know and doesn't care if the line is cleared to accpet digits or not. It just send it anyway. If the line is still in handshaking, it will end up missing one or two digits. For example, you want to dial 715-871-5571, but the carrier may just receive 158715571 or 5875571. You will get "we're sorry, your call did not go through..." signal because incomplete digits.

To solve this issue, you can simply makel the FXO interface to delay a little bit before sending digits to the line. It can be done by go into the Trunk setting in the TB GUI. In the option "Outbound Dial Prefix", put couple "w"s. I think one "w" makes half second delay when dialing. Just make sure you put "w"s without the quotes.



romy_punzalan
Posts: 8
Member Since:
2009-04-06
PSTN CANNOT ACCESS TRIXBOX

Hello,

I am testing Trixbox to PSTN connection via mfcR2 (cas) signaling using Sangoma A104DE E1 interface card. Trixbox can access PSTN (local & ndd calls) but one of my problems is that PSTN cannot access Trixbox. Pls. advise me on what informations on our trixbox will be needed to analyze this prob. any help will be appreciated. below is the log file when pstn call trixbox;

== Parsing '/etc/asterisk/asterisk.conf': Found
Connected to Asterisk 1.4.22.1 currently running on trixbox1 (pid = 9448)
Verbosity is at least 10
-- Executing [s@from-pstn:1] NoOp("DAHDI/34-1", "No DID or CID Match") in new stack
-- Executing [s@from-pstn:2] Answer("DAHDI/34-1", "") in new stack
-- Executing [s@from-pstn:3] Wait("DAHDI/34-1", "2") in new stack
-- Executing [s@from-pstn:4] Playback("DAHDI/34-1", "ss-noservice") in new stack
-- Playing 'ss-noservice' (language 'en')
-- Executing [s@from-pstn:5] SayAlpha("DAHDI/34-1", "") in new stack
-- Executing [s@from-pstn:6] Hangup("DAHDI/34-1", "") in new stack
== Spawn extension (from-pstn, s, 6) exited non-zero on 'DAHDI/34-1'
-- Executing [h@from-pstn:1] Hangup("DAHDI/34-1", "") in new stack
== Spawn extension (from-pstn, h, 1) exited non-zero on 'DAHDI/34-1'
-- Hungup 'DAHDI/34-1'
-- Executing [s@from-pstn:1] NoOp("DAHDI/3-1", "No DID or CID Match") in new stack
-- Executing [s@from-pstn:2] Answer("DAHDI/3-1", "") in new stack
-- Executing [s@from-pstn:3] Wait("DAHDI/3-1", "2") in new stack
-- Executing [s@from-pstn:4] Playback("DAHDI/3-1", "ss-noservice") in new stack
-- Playing 'ss-noservice' (language 'en')
-- Executing [s@from-pstn:5] SayAlpha("DAHDI/3-1", "") in new stack
-- Executing [s@from-pstn:6] Hangup("DAHDI/3-1", "") in new stack
== Spawn extension (from-pstn, s, 6) exited non-zero on 'DAHDI/3-1'
-- Executing [h@from-pstn:1] Hangup("DAHDI/3-1", "") in new stack
== Spawn extension (from-pstn, h, 1) exited non-zero on 'DAHDI/3-1'
-- Hungup 'DAHDI/3-1'

Thank you and regards



daveofca
Posts: 2
Member Since:
2009-02-05
RESOLVED

@ jingxi02: Thank you for your detailed response. In tinkering with the system's settings I was able to resolve the issue.

I removed the g0 trunk set up with the sangoma wanpipe install and instead roll 4 new trunks for each pstn line coming into the a200. This seemed to mitigate the issue and allow me to set up my outbound routes to choose the order of outbound lines the system uses.

After that, I added dial rules, and this seemed to totally fix the issue I was encountering. I am not sure if the dial rules help slow down the handshake with the analog pstn, but the dial tones definitely seem to be different from before when there were no dial rules in place. I did not add any w's to the outbound dial prefix as this change fixed the problem before I could, but I definitely think you were right in your analysis of the issue I was encountering.

At any rate, my small office now has a complete trixbox pbx system with follow me calling, 4 analog fxo lines, voicemail, ivr, and voicemail to email. One surprising feature was when a fax came across our analog line and ended up in an inbox held on the server. We were going to move to a third party fax to email solution, but if I can get this configured to be reliable, no need. Hooray for open source solutions!!!

Total time from install to production - 5 hours, including ivr and recordings.



solstars
Posts: 57
Member Since:
2009-07-23
I had the same issues with a

I had the same issues with a Sangoma USB. The "ww" tip worked fine for me. Thanks for solving my issue!



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.