Inbound calls get truncated to 2 digits

[Viet]

My Asterisk box is being set up to connect to a legacy PBX model NEC NEAX2000 IPS via T1 PRI. Dial in and dial out run fine except that the incoming calls get truncated to 4 digits. For example from an extension on the NEC side the dial out prefix code toward the Asterisk is 44, then the Asterisk extension 5120. So the string 44-5120 is dialed, the 44 gets stripped and 5120 gets sent toward the Asterisk, which only receives 51 with the ending 20 missing.

CLI> core set verbose 10
Verbosity is at least 10
– Accepting call from ‘’ to ‘51’ on channel 0/21, span 1
– Executing [51@from-internal:1] ResetCDR(“DAHDI/21-1”, “”) in new stack
– Executing [51@from-internal:2] NoCDR(“DAHDI/21-1”, “”) in new stack

If on the Asterisk side a 2-digit extension is defined, for example 19, then dialing 44-19 from the NEC side reaches that extension fine.

The NEC side was known to have a correct dial plan because it could dial to the previous version of this Asterisk box, which was just being rebuilt from scratch.

“Pri intense debug span 1” also showed that only 2 incoming digits were received. So my question is: how can I trace which dial plan and commands are being used by Asterisk when receiving the inbound string?

So far testing had been done only on internal extensions, no attempt made yet to receive incoming calls from outside. Initially no inbound route was defined on the Asterisk side, this was left to default settings.

It’s Asterisk 1.4.24, FreePBX 2.5.1.2 running on CentOS 5.3 linux kernel 2.6.18.

Thanks in advance for reviewing my setup!

Below is the chan_dahdi.conf

;autogenerated by /usr/sbin/wancfg_dahdi do not hand edit
;autogenrated on 2009-04-29
;Dahdi Channels Configurations
;For detailed Dahdi options, view /etc/asterisk/chan_dahdi.conf.bak

[trunkgroups]

[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no

;Sangoma A101 port 1 [slot:4 bus:12 span:1]
switchtype=4ess
context=from-internal
group=1
echocancel=no
signalling=pri_net
channel =>1-23

and the relevant contexts from extensions.conf

[from-trunk] ; just an alias since VoIP shouldn’t be called PSTN
include => from-pstn

[from-pstn]
include => from-pstn-custom ; create this context in extensions_custom.conf to include customizations
include => ext-did
include => ext-did-post-custom
include => from-did-direct ; MODIFICATOIN (PL) for findmefollow if enabled, should be bofore ext-local
include => ext-did-catchall ; THIS MUST COME AFTER ext-did
exten => fax,1,Goto(ext-fax,in_fax,1)

; MODIFICATION (PL)
;
; Required to assure that direct dids go to personal ring group before local extension.
; This could be auto-generated however I it is prefered to be put here and hard coded
; so that it can be modified if ext-local should take precedence in certain situations.
; will have to decide what to do later.
;
[from-did-direct]
include => ext-findmefollow
include => ext-local

…

;this is where parked calls go if they time-out. Should probably re-ring
[default]
include => ext-local
exten => s,1,Playback(vm-goodbye)
exten => s,2,Macro(hangupcall)

[shmaize]

Try with overlapdial=yes in chan_dahdi.conf

[Viet]

Dear shmaize,

Thank you for your reply. This was tried too with no change.

But in the meantime further testing was done and it is very likely that the problem comes from the setup on the NEC side. So we are checking into that too because the data gathered so far have been contradictory. I am getting help from a colleague who knows how to navigate in the NEC maze.

[iceburn2003]

The problem does sound like its on the other PBX’s side. On our Avaya PBX there are some settings for adding and removing digits through the routing process.

Basically, you call ext 6666 it adds the Routing Pattern number defined in the Uniform Dialplan on the Avaya. Now the number is 1236666 which tells the Avaya to use Routing Pattern 123. Routing Pattern 123 is setup to remove 3 digits before sending it out the trunk to Asterisk. Asterisk sees the number as 6666.