* You are viewing Posts Tagged ‘chan’

HELP!! Caller ID “unknown” for all inbound call (Satria Anamarta)

Hi Anam

It seem should be work, but I just have a question about chan_dahdi.conf regardless to parameter
rxwink=300 ; Atlas seems to use long (250ms) winks
By the way gain parameters shouldn´t have any effect to CID signal processing, how about to comment, and test again, if still without working try to connect parallel phone with Asterisk it will check if could be a hardware problem or configuration parameter setting

Good luck
Mc GRATH Ricardo
E-Mail mcgrathr@mail2web.com

HELP!! Caller ID “unknown” for all inbound call

This is a very strange problem (at least for me). I just realized that
started from April 20th 2012 every inbound call is from “unknown”.
Prior that, asterisk succesfully displayed the caller caller’s ID for SOME
of the calls (30-50% success rate). I am using PBX | monitoring menu to see
this report.

As far as I remember, I dont modify any settings that related to caller ID,
but few days ago (I dont remember the exact date), I modify the rxgain and
txgain value in chan_dahdi.conf.
The inbound caller ID doesn’t display on the log and on the phone.

I’m running asterisk 1.8.7.0
FreePBX 2.8.1
FXO card using Digium AEX800B

The caller ID is display well on the phone If I connect the phone directly
without connecting to asterisk (just for testing purpose)

This is my chan_dahdi.conf

[trunkgroups]

[channels]
context=from-pstn
signalling=fxs_ks
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
faxdetect=incoming
echotraining=800
rxgain=8.0
txgain=8.0
callgroup=1
pickupgroup=1

;Uncomment these lines if you have problems with the disconection of your
analog lines
;busydetect=yes
;busycount=3

immediate=no

#include dahdi-channels.conf
#include chan_dahdi_additional.conf
chan_dahdi.conf (END)

This is my dahdi-channels.conf
; Autogenerated by /usr/sbin/dahdi_genconf on Fri Mar 30 22:32:16 2012
; If you edit this file and execute /usr/sbin/dahdi_genconf again,
; your manual changes will be LOST.
; Dahdi Channels Configurations (chan_dahdi.conf)
;
; This is not intended to be a complete chan_dahdi.conf. Rather, it is
intended
; to be #include-d by /etc/chan_dahdi.conf that will include the global
settings
;

; Span 1: WCTDM/0 “Wildcard AEX800 Board 1″ (MASTER)
;;; line=”1 WCTDM/0/0 FXSKS”
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 1
callerid=
group=
context=default

;;; line=”2 WCTDM/0/1 FXSKS”
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 2
callerid=
group=
context=default

;;; line=”3 WCTDM/0/2 FXSKS”
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 3
callerid=
group=
context=default

;;; line=”4 WCTDM/0/3 FXSKS”
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 4
callerid=
group=
context=default

;;; line=”5 WCTDM/0/4 FXSKS”
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 5
callerid=
group=
context=default

;;; line=”6 WCTDM/0/5 FXSKS”
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 6
callerid=
group=
context=default

Any help would be very appeciated.

Thanks and best regards,
Anam.

FXO -> GSM Gateway Problem


>>
>> I have a problem where calling “out” of asterisk when the call is
answered dahdi hangs up immediately.

I’d make sure both answeronpolarityswitch and hanguponpolarityswitch are
either commented out or set to no.

from chan_dahdi.conf;
; Use a polarity reversal to mark when a outgoing call is answered by the
; remote party.
;
;answeronpolarityswitch=yes
;
; In some countries, a polarity reversal is used to signal the disconnect of
a
; phone line. If the hanguponpolarityswitch option is selected, the call
will
; be considered “hung up” on a polarity reversal.
;
;hanguponpolarityswitch=yes
;

Alec Davis

DAHDI FXO Call Issues / Indication Types

Greetings-

I’ve had reports of a customer PBX acting strangely to some inbound calls. Specifically, a call comes into an FXO port, hits a Dial() to ring a few extensions, but by the time someone answers the phone, the call has been dropped, and the caller is listening to on-hold music. There is nothing in the dialplan that would cause this behavior.

The logs have a couple of odd (to me, maybe normal) items that may give some information.

After the call comes in, and the SIP endpoints are dialed, I see:

[2012-04-12 08:51:04] DEBUG[7313] chan_dahdi.c: Requested indication 3 on channel DAHDI/1-1

I have to assume indication 3 means playing ringing tones to DAHDI/1?

The phones are ringing at this point. In the logs I see this:

[2012-04-12 08:51:06] DEBUG[7313] sig_analog.c: analog_exception 1
[2012-04-12 08:51:06] DEBUG[7313] sig_analog.c: Exception on 13, channel 1
[2012-04-12 08:51:06] DEBUG[7313] sig_analog.c: __analog_handle_event 1
[2012-04-12 08:51:06] DEBUG[7313] sig_analog.c: Got event ANALOG_EVENT_RINGBEGIN(12) on channel 1 (index 0)

I’m assuming the indication 3 specified earlier was to send ring tones on DAHDI/1, this simply confirms it?

Next, one of the phones answered the call, and a new indication is sent:

[2012-04-12 08:51:07] VERBOSE[7313] app_dial.c: — SIP/102-000021ae answered DAHDI/1-1
[2012-04-12 08:51:07] DEBUG[7313] chan_dahdi.c: Requested indication 22 on channel DAHDI/1-1

What does indication 22… indicate?

There is more to the log, but it is intermingled with a callback and I’m not easily able to parse it out at the moment. Does any of the above seem out of place, or does it look ‘normal’?

As an aside, where could a person find a list of indications used on DAHDI channels, analog and/or PRI/T1?

chan_sip.so module not loading

Hi,

I have installed asterisk 1.8.11.0. but there’s a problem with the sip
channel module.

The module chan_sip.so exists in /usr/lib/asterisk/modules, but it
won’t load at startup.
CLI command module load chan_sip.so also did not work.