Sangoma FXS port issues...
Ok here is a summary of the issues I am having.
1. The audio has some clicks and taps on the FXS port. FXO sound great.
2. Echo when calling out on the FXO from the FXS. The sip phones do not get this when calling out on the FXO. I have tried echocancelwhenbridged both on and off. No change.
3. No CallerID when calling from the FXS phone to internal Extensions. Shows "Unknown"
4. No stutter tone when new voicemails are left on the extension that is on the FXS port.
I just purchased the FXS card and installed it. I was using a Sipura before and it was working great. I opted for the Sangoma because I thought it would be the better solution. I am sure that it will be, I just need to get it working properly.
Here is what I am running.
Trixbox 2.0
Wanpipe 2.3.4-7
Sangoma A200 2FXO 2FXS
1 analog line and 1 FXS extension
1 Sip Extension (Snom 320)
I configured my new FXS module on my sangoma A200, and everyting is working great except callerID on calls to internal extensions...
here is the CLI output...
-- Starting simple switch on 'Zap/1-1'
-- Executing Macro("Zap/1-1", "exten-vm|1000|1000") in new stack
-- Executing Macro("Zap/1-1", "user-callerid") in new stack
-- Executing NoOp("Zap/1-1", "user-callerid: ") in new stack
-- Executing GotoIf("Zap/1-1", "0?report") in new stack
-- Executing GotoIf("Zap/1-1", "0?start") in new stack
-- Executing Set("Zap/1-1", "REALCALLERIDNUM=") in new stack
-- Executing NoOp("Zap/1-1", "REALCALLERIDNUM is ") in new stack
-- Executing Set("Zap/1-1", "AMPUSER=") in new stack
-- Executing Set("Zap/1-1", "AMPUSERCIDNAME=") in new stack
-- Executing GotoIf("Zap/1-1", "1?report") in new stack
-- Goto (macro-user-callerid,s,11)
-- Executing NoOp("Zap/1-1", "TTL: ARG1: 1000") in new stack
-- Executing GotoIf("Zap/1-1", "0?continue") in new stack
-- Executing Set("Zap/1-1", "_TTL=64") in new stack
-- Executing GotoIf("Zap/1-1", "1?continue") in new stack
-- Goto (macro-user-callerid,s,21)
>>>>> -- Executing NoOp("Zap/1-1", "Using CallerID "" <>") in new stack
-- Executing Set("Zap/1-1", "FROMCONTEXT=exten-vm") in new stack
-- Executing Set("Zap/1-1", "VMBOX=1000") in new stack
-- Executing Set("Zap/1-1", "EXTTOCALL=1000") in new stack
-- Executing Set("Zap/1-1", "CFUEXT=") in new stack
-- Executing Set("Zap/1-1", "CFBEXT=") in new stack
-- Executing Set("Zap/1-1", "RT=23") in new stack
-- Executing Macro("Zap/1-1", "record-enable|1000|IN") in new stack
-- Executing GotoIf("Zap/1-1", "0?2:4") in new stack
-- Goto (macro-record-enable,s,4)
-- Executing DeadAGI("Zap/1-1", "recordingcheck|20070519-211252|1179634370.27") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/recordingcheck
recordingcheck|20070519-211252|1179634370.27: Inbound recording not enabled
-- AGI Script recordingcheck completed, returning 0
-- Executing NoOp("Zap/1-1", "No recording needed") in new stack
-- Executing Macro("Zap/1-1", "dial|23|TtrWw|1000") in new stack
-- Executing DeadAGI("Zap/1-1", "dialparties.agi") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/dialparties.agi
dialparties.agi: Starting New Dialparties.agi
dialparties.agi: priority is 1
>>>>>> dialparties.agi: Caller ID name is 'unknown' number is 'unknown'
dialparties.agi: Methodology of ring is 'none'
##
and here is the config for the extension...
;;;;;;[1001]
signalling=fxo_ks
record_out=Adhoc
record_in=Adhoc
mailbox=1001@default
immediate=no
echotraining=800
echocancelwhenbridged=no
echocancel=yes
dial=ZAP/1
context=from-internal
callprogress=no
callerid=device <1001>
busydetect=no
busycount=7
accountcode=
channel=>1
Hello guys,
If you have any noise problems with a Sangoma card please contact our Tech support. Noise can be caused by a couple of issues including a misconfigured card, misconfigured Asterisk, noisy lines, or malfunctioning hardware. As for caller-id, the card it self is not responsible for the caller-id, that along with all other signaling is handled by Asterisk but a noise problem on an analog line can cause problems because the signaling is in band.
In either case send an email to techdesk@sangoma.com, with a brief description of the problem you are having we will get back to within 24 hours normally.


Member Since:
2006-05-31