Dahdi, Inbound CallerID and Delays (SOLVED)

1

Hi All,

A question about Inbound Callerid and delays.

The Card:
pci:0000:05:00.0 wctdm+ e159:0001 Wildcard TDM400P REV E/F
Freepbx 12.0.76.2
DahdiConfig 2.11.53

The question:
Can I set the “usecallerid” parameter for each channel.?
Or (as it appears) does one setting cover all channels ONLY.

WHY:?

I have been tricking around with the Dahdi setting trying to get this card working and have ended up with two options.
Great results on the whole, no echo and clear voice and Callerid.

But only two of the phone lines have Callerid enabled the other two do not.

When I try to set the usecallerid=no on the two unused channels it turns it off on all channels, guessing it just sees the last usecallerid=no

I need to turn off the callerid stuff on those two lines as with it on it seems to take 10 seconds for the call to be passed thru to be answered.

I have been using the examples to construct a chan_dahdi_channels_custom.conf file to add the extra bits.
Looking like this

; Set Channel 1
usecallerid=yes
channel => 1

; Set Channel 2
usecallerid=yes
channel => 2

; Set Channel 3
usecallerid=no
channel => 3

; Set Channel 4
usecallerid=no
channel => 4

The rest is set correctly in other parts V23, polarity all good

I expected it to work.! but no such luck

There is still the 10 second delay on both of those line.
If I turn off ,“usecallerid=no” then all lines will ring thru instantly but without callerid on the first two.

AN EDIT: (( The above is wrong.! With those strings included in the custom file then it would appear that the final “usecallerid=no” is setting all the channels to off and not just Channel 4 as expected. If I were to have that as “yes” then all channels attempt to decode callerid giving the 10 second dealy on those lines without it.)).
Hey it was a 50/50 chance of making a mistake.!

Can anyone assist with this.?
Hv.

2

On analog lines the CID is detected by rings so the delay that asterisk takes to pass the call to your dialplan is the time that it(or dahdi actually) takes to get the CID. If you want to get the calls faster in your dialplan avoid detecting the CID or set to something that you know is from outside.

1 Like
3

Hi Navaismo,
Yep, Callerid in the UK is normally done at the start of the call.
Just after the first burp. You can see it if you monitor the line.
Plus I used to tinker with CLI back in the days and have built my own FSK decoder many times.

But unless I am mistaken there is no logical reason why any process should take a solid 10 seconds to work out something as basic as callerid.
Perhaps in some places the number is sent upto 10 seconds later but nothing I have ever worked on. If there was a time out setting to change I would be content with that but people hang up after 10 seconds…

But my main question was can you turn callerid off per channel or is it one setting for all channels.

If I can turn it off for the two lines that do not have it then everything is perfect, but I have not found a way.

Still hoping.
Hv.

4

At this point, it might pay to ask if this is real seconds, or customer seconds.

The reason I ask is because many of us have been with customers that claim things like this take “forever”, “15 seconds easy”, “at least 30 seconds”, and many other seemingly quantifiable time periods. When presented with logs (like /var/log/asterisk/full), the number usually comes way down.

If this is 10 “customer” seconds, I can see where it could actually be taking three or four seconds to get everything ready to go, which gets rounded up.

Now, to the original question. If you don’t want caller ID information to slow your call pickup down, you can make them “immediate”. This means that, as soon as the phone goes off hook, an action is taken - usually connecting the line to some other extension. Note that the ‘traditional’ use for immediate calls is for emergency phones or door phones where the caller doesn’t have access to a dial-pad. You can use them for your incoming DAHDI lines to drop them straight into a virtual extension.

5

Hey Dave,

10 Seconds is what I see in the Logs, that is how I knew what to type, I would not have bothered to pull out the stopwatch for such a small period. But I know what you mean, it feels like a lifetime has passed since I played with pots lines, though I am not a customer so I hope that takes me above that sort of speculation.

I was happy with callerid slowing down the call process by 1 or two seconds but 10 seconds is just out of control. Plus I was more interested in an approach to disable the callerid decoding on the two line/modules that do not have it.

From my reading of the docs the process of having variables above the statement “Channel => 1” would store them for channel 1 only but my experience, poor text editing or general lack of understanding is not giving the expected results.

Personally I hate playing with Pots stuff but hey it has to be done I guess.

Hv.

6

Yes you can disabled the callerid per channel. And you are right you can put any setting above the Channel => string to affect that channel. If you dont put anything that measn the next channel will inherit the settings.

7

Hi Navaismo,

I did think that I could disable per channel but all my attempts have come up empty.
I even tried to put stuff in the System settings using
"usecallerid=yes,1-2"
“usecallerid=no,3-4”

This seemed to be a logical format given the current file layout but again no worthwhile results. Though I forget what effect it had.
I am not sure how the files are used and in what order the data is extracted.

Is there any tools that would simulate an incoming call event and give some verbose debug output of the flow and order of processing.?

I did notice that adding and then deleting bits from the System settings in the Dahdi Module seemed to leave the entry in the database with a value of 1, I had to manually remove those or they were inserted in /etc/dahdi/system.conf on each setting rebuild.

I am not trying to be lazy and be spoon fed a solution, I may have to find the dahdi source and step thru it to get a better understanding but I was hoping someone had already done that.!!

Many thanks for the comments and assistance so far.
Hv.

8

Should be something like(I’m a little rusty with dahdi):

usecallerid = yes
callerid=asreceived
dahdichan => 1,2

usecallerid =no
dahdichan => 3,4

1 Like
9

Hi Navaismo,

I see you used the dahdichan => 1,2 format.
So I gave that a go.
Still no joy.

These were the current files.

They all contain the normal #includes but removed here for clarity.

; ########################
IN chan_dahdi.conf:
; ########################
[general]

[channels]
language=en
busydetect=yes
busycount=5
usecallerid=yes
callwaiting=yes
usecallingpres=no
threewaycalling=no
transfer=no
cancallforward=no
callreturn=no
echocancel=yes
echocancelwhenbridged=no
echotraining=800
immediate=yes
faxdetect=no
rxgain=4.5
txgain=3.5

; ########################

; ########################
IN chan_dahdi_groups.conf:
; ########################
signalling=fxs_ks
context=from-analog
group=0
channel=>1

signalling=fxs_ks
context=from-analog
group=0
channel=>2

signalling=fxs_ks
context=from-analog
group=0
channel=>3

signalling=fxs_ks
context=from-analog
group=0
channel=>4
; ########################

; ########################
IN chan_dahdi_channels_custom.conf:
; ########################
usecallerid=yes
cidstart=polarity
cidsignalling=v23
callerid=asreceived
immediate=no
channel => 1
channel => 2

usecallerid=no
cidstart=polarity
cidsignalling=v23
callerid=NoCli<01234567890>
immediate=yes
channel => 3
channel => 4

; Without this next part included ALL CHANNELS will pass “NoCli<01234567890>”
; thru to asterisk. And yet it is only supposed to be setting 3 & 4.
callerid=
; ########################

; ########################
ALTERNATE ATTEMPT
IN chan_dahdi_channels_custom.conf:
; ########################
usecallerid=yes
cidstart=polarity
cidsignalling=v23
callerid=asreceived
immediate=no
dahdichan => 1,2

usecallerid=no
cidstart=polarity
cidsignalling=v23
callerid=NoCli<01234567890>
immediate=yes
dahdichan => 3,4
; ########################

It all look like it should be correct but I must be missing something dam obvious to someone.

Hv.

10

Not sure if in the new version of FreePBX you can edit the chan_dahdi but I suggest to delete all include files and only use one configuration file either dahdi-channels or chan_dahdi I always hated the way that free pbx include many files for dahdi stuff. Try to use only one file and set there all the settings and remove any include.

1 Like
11

+1 @navaismo but make sure the “dahdi helper” is disabled or uninstalled in modules or a reload will BYITA.

12

Hi Navaisom & Dicko,

Many thanks for the continued assistance.
As it is a live system I wont touch it till later but shall attempt the above then.

Am I right in thinking I should remove the Dahdi module from freePbx and then just place all my required config in a single chan_dahdi.conf file in the etc/asterisk folder.

Sounds like a plan, as it does feel like my custom settings are being misplaced somewhere in the process. Just for a test I put in a dummy [section] just after my stuff in the custom file and that thru a right spanner in the works loosing all the context and other default setting I guess. Wish I could find the section in the source that deals with this so I could step thru it and know for sure.

I shall report back when I try that single file stuff later.

Hv.

13

This covers the config in detail

http://doxygen.asterisk.org/trunk/chan_dahdi.conf.html

14

I’ve found that the DAHDI module in FreePBX doesn’t always play nice when you are trying to do things using custom config files. Sometimes, it gets it all right - sometimes not. Since it’s hit or miss for me, I just do whatever it takes to get it working and press on from there.

15

Hey Dicko,

Great tip.! RTFM.
I had read that several times
but have made some subtle errors because I did not read it again.!

Once I get back later I shall see what I can mash together.

Looks promising though.
With the right words anything is possible.

Hv.

16

While it might be frustrating that you’re not getting the answers you are looking for here, as quickly as one would hope, remember two things:

  1. DAHDI is a Digium product, and it therefore outside the scope of both Asterisk and FreePBX. This is a FreePBX forum.

  2. DAHDI is arcane and overly complicated - instead of splitting it into a series of executables that work for different classes of devices, it is all just thrown in together and managed through a series of “completely different from everything else” configuration files that are neither internally consistent or completely backwards compatible. Things that work in subversion 10 don’t always work in sub-version 11.

Setting up DAHDI configs is one of those things that you never revisit once it’s working, and (for me anyway) is something that I don’t do very often. I might set up one or two of these a year, and I always use the same configuration and cards, so the two months I spent figuring out the crap 10 years ago isn’t right on the tips of my fingers.

17

For a similar solution from a respected source:-

18

Hey Dave,
Everything is right on target so far, the help has been perfect.

I know it is not the right forum but I thought it was worth the punt.
Plus if it gets resolved it may help others in the future.

Cheers for the second link Dicko, will have a read later as I really must jump in the shower and start my day ! been putting it off but the time has come.

Hv.

19

Right,
Shutters down so I can play with the phones.

Had a brain wave, or 30 seconds of Clairvoyance.
Turned out to be very simple in the end.

Looking at the files that are included after the “chan_dahdi_channels_custom.conf”.

Like “chan_dahdi_groups.conf” and “chan_dahdi_additional.conf”

That Groups file is also doing some channel setting, curse you.
So custom stuff has to go at the far end of the chain.

I think the problem is that the last file that is included in the chan_dahdi.conf file
is an auto generated file by freepbx, with advice not to edit it.
And the include ordering is also generated by freepbx, with advice not to edit it.

The last one on the list is "chan_dahdi_additional.conf"
I have no idea what part of the module writes to this file, extensions I think I saw, but I found putting my specific line settings in this file to work peachy.
I guess if the custom file was the last to be included then it would give a more logical flow to things giving the user the final say on settings.

I can understand now why it is easy to misconfigure dahdi.

Oh by the way, doing the Right button, “Restart Dahdi/Asterisk”, does not overwrite any files so it was easy to make a couple of edits without removing the module.
Now to click Write disable.

98% of the way there, just have to top up 2% on the understanding.
I am going to read the links you gave and see what I need to adjust or an alternate method to use the custom file to avoid freepbx overwrites.
Or I could uninstall the module, 50/50 at this point.

For reference this is what was in my “chan_dahdi_additional.conf” File
Although I am not sure of the use of immediate=…

;--------------------------------------------------------------------------------;
; Do NOT edit this file as it is auto-generated by FreePBX. ;
;--------------------------------------------------------------------------------;
usecallerid=yes
callerid=asreceived
cidstart=polarity
cidsignalling=v23
immediate=no
channel => 1-2
;
usecallerid=no
callerid=NoCli<01234567890>
immediate=yes
channel => 3-4

callerid=asreceived
;
;callerid=

To be polite and display some housekeeping I should blank the fields I used at the end. Like:
usecallerid=
callerid=
cidstart=
cidsignalling=
immediate=

Seems to be the preferred practice.

Needless to say thanks to Dave and Dicko for their assistance.
Hope to repay the favour sometime.

Hv.

20

careful to read the:

a FreePBX reload will unset your changes as the dahdi helper module will overwrite the /etc/dahdi/system.conf and the /etc/asterisk/dahdi*.conf files except the custom ones. Best to disable the helper and go simple with one dahdi.conf file. JMHO

1 Like