| Some information on how to conect Asterisk to the ISDN
| Chapter 5:Usual configuration issues
| Last update:
2020-03-29 |
|---|
Usual issues AKA Pitfalls
Some of the usual suspects of where to put ones foot in it.
Sending faxes out an ISDN line
By default Asterisk will send out all calls with the BC set to speech.
That causes two sorts of problems when sending faxes:
- If the called party has ISDN as well and is able to check the BC, it will probably reject the call, because a fax machine won't support speech.
- It will allow your carrier or some intermediate carrier to use lossy codecs which will make data transmission impossible.
The solution is to always use a Set(CHANNEL(transfercapability)=3K1AUDIO) before you Dial() out.
DTMF not working from SIP to LCR
If you use a SIP phone and dial out using LCR you might be unable to use DTMF controlled IVRs.
This happens if you have your sip peers configured for out-of-band DTMF transmission, which is usually a good idea, preferably using RFC 2833.
In that case you need to pass option s in the dial destination to make LCR generate inband DTMF again when it receives DTMF messages from Asterisk.
e.g. Dial(LCR/bri1/${EXTEN}/s,${dialtime},${dialoptions})
False DTMF on calls coming in via LCR
Intermittent / sporadic DTMF tones generaded on the other channel or features activated even if the user didn't enter any digits.
By default, the m1SDN_DSP module is somewhat oversensitive and is known to produce false positives on DTMF detection.
Add dtmfthreshold=200 (or up to 400) to your modprobe m1SDN_dsp or your modprobe.conf.
Busy instead of dialtone when lifting the handset (DAHDI)
You have a phone connected to Asterisk using cahn_dahdi in NT-Mode and when you lift the receiver to dial,
you get no dialtone, but hear a busy tone instead and no dialling is possible.
This is normal with the default configuration, it always expects en-block dialling.
Depending on the equipment used, you may be able to enter the complete number first and then lift the handset when done and be connected.
To enable overlap dialling, set immediate=yes in chan_dahdi.conf.
Additionally you need a s extension in the corresponding context in extensions.conf,
like e.g. exten => s,1,WaitExten(20).
On newer versions of DAHDI (or probably more like newer versions of Asterisk) the behaviour seems to have changed. You now need
overlapdial=yes and immediate=no in your chan_dahdi.conf.
Beware: Getting overlap dialling fully working in your dialplan including match-as-you-go can be a little tricky.
Unable to set caller ID (DAHDI)
If the caller ID displayed to the people you're calling is always your main number, no matter what you specify with
Set(CALLERID(num)=12345), make sure your chan_dahdi.conf contains prilocaldialplan=unknown.
Outgoing calls are rejected (DAHDI)
or
International calls are rejected while national calls work fine
Either calls are rejected immediately or almost immediately, usually with some rather unspecific cause code.
Unlike what the (older) sample config states, make sure you have both pridialplan=unknown and prilocaldialplan=unknown
in chan_dahdi.conf.
This is the safest choice and should only be changed if you have a special reson to do so
and you know what you're doing. This is also true for pricpndialplan=unknown.
Depending on the way you set caller IDs it can make sense to change prilocaldialplan
and pricpndialplan if you have DDI, however.
Having pridialplan=national will only allow you to call national numbers without long distance access codes.
If you already have national calls working and change the parameters from national to unknown,
make sure to add the long distance prefix for national calls, if required.
Another cause for this issue may be the transmission of CALLERID(name) as a Display IE.
To switch that off, use hidecalleridname=yes.
On incoming calls only the first dialled digit is recognised (DAHDI)
Make sure you have overlapdial=yes in your chan_dahdi.conf.