[FIXED?] Unable to parse call dest in 1.2 using em_w

I have a T1 DSS line that uses e&m wink signaling. I have a single digium T100P card.

Using the asterisk/zaptel/libpri 1.0 branch, everything works perfectly.

With the same configs, the 1.2 branch has some very inconsistent problems. Calls outbound on the T1 work perfectly. Calls coming in sometimes work, but often come in with a destination extension of “9” or even a garbled string. In the 1.2.0, they will often come in with no destination at all, with 1.2.1, it comes in with something, but it’s not parsed correctly.

My line does NOT have caller id of any kind. I have tried the configs with caller id feature on and off. I have played with the “immediate” setting along with changing the default em_w timings.

What part of the whole operation is responsible for this and how should I trouble shoot it from here?



I am still searching for an upgrade solution.

Is anyone able to suggest which part of the chain might be broken? I do not understand if I need to be troubleshooting zaptel, libpri or asterisk.

Thanks much,

I’m having exactly the same problem as you. Running on a HP Proliant ML350 with 2gb mem. Two TE110P Digium cards, one to the PSTN the other to a Merlin Legend PBX. Worked great on the 1.0 branch. I think I will have to revert to my previous config. I will likely call Digium in the meantime to see if I can get some support. Please let me know if you find anything out, I’ll do the same.

Turned off Hyper-Threading in my HP ML350 server bios. No dropped calls or ignored calls since.

Hyper-Threading? I will recompile my kernel without it and see what happens! Thanks for the sugestion.

I might have gotten this worked out, but my solutin was a little diferent. Due to some config issues I am not yet runnin the box with asterisk 1.2 in production yet, but in testing last night I was able to get get it to work consistently.

My current kernel ( did not have smp or hyperthreading options at all, but it was enabled in the bios, so I tried disabling it. This did not help.

Next I compiled a new kernel (2.6.15) with smp and hyperthreading enabled, re-enabled the bios setting, and recompiled zaptel with smp support. Once all of that was in place, the parsing was consistent.

Zaptel was not previously compiled for smp because my kernel was not smp.

This is single cpu P4 box with hypertreading.