Inbound calls fail on PRI line

Asterisk Asterisk Hardware
1

Hello,

I just changed our local provider for our PRI line, outbound calls work but inbound calls always fail (Cause: Unallocated (unassigned) number (1)).
I asked our new PRI line provider for any specific specs and it didn’t give me anything.
Is there anything I could change in my settings to fix this issue?
Thank you!

Here are the conf files :

system.conf

# Span 1
span=1,1,0,ccs,hdb3,crc4
bchan=1-15,17-31
echocanceller=oslec,1-15,17-31
dchan=16

#Global data
loadzone=fr
defaultzone=fr

chan_dahdi.conf:

[channels]
service_message_support=yes
echocancel=1024
dsp_type=none
echocancelwhenbridged=yes
rxgain=0
txgain=0
qsigchannelmapping=logical
usecallerid=yes
pridialplan=unknown
prilocaldialplan=unknown
internationalprefix=
nationalprefix=
localprefix=
privateprefix=
unknownprefix=
nsf=none
resetinterval=never
overlapdial=no
inbanddisconnect=yes
priindication=outofband
facilityenable=yes
priexclusive=yes
discardremoteholdretrieval=yes
hidecalleridname=
callwaitingcallerid=yes
display_send=name
display_receive=name
vadcng=
mfcr2_variant=itu
mfcr2_category=national_subscriber                              
mfcr2_allow_collect_calls=no                   
mfcr2_accept_on_offer=yes                   
mfcr2_forced_release=no                  
mfcr2_charge_calls=yes  
mfcr2_logging=all
```

Here is the log:

```PRI Span: 1] < Message Type: SETUP (5)
[PRI Span: 1] < [04 03 90 90 a3]
[PRI Span: 1] < Bearer Capability (len= 5) [ Ext: 1  Coding-Std: 0  Info transfer capability: 3.1kHz audio (16)
[PRI Span: 1] <                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
[PRI Span: 1] <                                User information layer 1: A-Law (35)
[PRI Span: 1] < [18 03 a9 83 81]
[PRI Span: 1] < Channel ID (len= 5) [ Ext: 1  IntID: Implicit  Other(PRI)  Spare: 0  Exclusive  Dchan: 0
[PRI Span: 1] <                       ChanSel: As indicated in following octets
[PRI Span: 1] <                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
[PRI Span: 1] <                       Ext: 1  Channel: 1 Type: CPE]
[PRI Span: 1] < [1e 02 81 83]
[PRI Span: 1] < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Private network serving the local user (1)
[PRI Span: 1] <                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
[PRI Span: 1] < [6c 0e 10 80 32 31 32 36 30 30 30 34 39 38 36 32]
[PRI Span: 1] < Calling Party Number (len=16) [ Ext: 0  TON: International Number (1)  NPI: Unknown Number Plan (0)
[PRI Span: 1] <                                 Presentation: Presentation allowed, User-provided, not screened (0)  '212600049862' ]
[PRI Span: 1] -- Making new call for cref 53
[PRI Span: 1] Received message for call 0xb73023f8 on link 0xb70b2054 TEI/SAPI 0/0
[PRI Span: 1] -- Processing Q.931 Call Setup
[PRI Span: 1] -- Processing IE 4 (cs0, Bearer Capability)
[PRI Span: 1] -- Processing IE 24 (cs0, Channel ID)
[PRI Span: 1] -- Processing IE 30 (cs0, Progress Indicator)
[PRI Span: 1] -- Processing IE 108 (cs0, Calling Party Number)
[PRI Span: 1] q931.c:8646 post_handle_q931_message: Call 53 enters state 6 (Call Present).  Hold state: Idle
[PRI Span: 1] q931.c:7135 q931_hangup: Hangup other cref:53
[PRI Span: 1] q931.c:6892 __q931_hangup: ourstate Call Present, peerstate Call Initiated, hold-state Idle
[PRI Span: 1] q931.c:6383 q931_release_complete: Call 53 enters state 0 (Null).  Hold state: Idle
[PRI Span: 1] 
[PRI Span: 1] > DL-DATA request
[PRI Span: 1] > Protocol Discriminator: Q.931 (8)  len=9
[PRI Span: 1] > TEI=0 Call Ref: len= 2 (reference 53/0x35) (Sent to originator)
[PRI Span: 1] > Message Type: RELEASE COMPLETE (90)
[PRI Span: 1] TEI=0 Transmitting N(S)=0, window is open V(A)=0 K=7
[PRI Span: 1] 
[PRI Span: 1] > Protocol Discriminator: Q.931 (8)  len=9
[PRI Span: 1] > TEI=0 Call Ref: len= 2 (reference 53/0x35) (Sent to originator)
[PRI Span: 1] > Message Type: RELEASE COMPLETE (90)
[PRI Span: 1] > [08 02 81 81]
[PRI Span: 1] > Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
[PRI Span: 1] >                  Ext: 1  Cause: Unallocated (unassigned) number (1), class = Normal Event (0) ]
[PRI Span: 1] q931.c:7135 q931_hangup: Hangup other cref:53
[PRI Span: 1] q931.c:6892 __q931_hangup: ourstate Null, peerstate Null, hold-state Idle
[PRI Span: 1] Destroying call 0xb73023f8, ourstate Null, peerstate Null, hold-state Idle
```
2

There doesn’t seem to be any called number.

Your logging doesn’t include how Asterisk handles this, but I suspect it will say no extension s in name of context.

3

In your configuration it seems missing parameters;
context=” for incoming call”
others.
signaling=pri_cpe
switchtype=

4

Thank you for your answer. Here is the context for incoming calls

[port-1]
include=>rtg-in-1
[rtg-in-1]
exten=> _X.,1,Verbose(2,${EXTEN} matches _X.)
exten=> _X.,n,GoSub(sub-failover,s,1(${EXTEN},,SIP/192.168.30.49:0))
exten=> _X.,n,Goto(nocdr,s,1)
[sip-192.168.30.49]

The calls are transferred on a SIP trunk to a 3 CX server.

5

I think they are saying that there should be a reference to port-1 in the DAHDI configuration. However, in any case, you won’t match _X. without a called party number.

6

Sorry I forgot to include the last line of chan_dahdi.conf:
#include /etc/asterisk/dahdi-channels.conf

and dahdi-channels.conf contains the context port-1 :

; Span 1: TE4/0/1 "T4XXP (PCI) Card 0 Span 1" B8ZS/ESF RED 
group=1,11
context=port-1
switchtype=euroisdn
signalling=pri_cpe
channel=1-15,17-31
context = default
group = 63
description=
7

You have context = default you should have context = port-1

8

He has both. I think the second context line is dead, as no channels are defined after it.

9

And after deleting the second one, it still doesn’t work.

10

The second one had no effect, except to confuse people trying to debug your configuration. The problem is that there is no called party number. You should be getting a message saying extension s not found in context port-1, but you are not providing the diagnostics that you are getting.

If you are expecting the called party to be inband DTMF, you need to enable the built in logic for that.

If you need the called party number, you need to fix this at the remote end. If you don’t, replace _X. by the extension from the message, which will be s, in this case…

11

No need to include the path of the dahdi-channels conf file
Just set.
#include dahdi-channels.conf
Remember if made changes on dahdi file should restart dahdi service, be aware to stop first asterisk service before preforming.

12

Thank you very much for your answer, It nows works after replacing _X. to s. To make sure I understand the issue we had, this problem happened after we switched provider for our primary line, does it mean that with our previous provider we were getting the called number? And now since we don’t we need to use s.
Thank you again!

13

Not having seen the logs, from before, I have to guess, but I would say that was the correct interpretation.

14

Could you please explain, what do you mean by enabling the built in logic for that?
Thank you!

15

I can’t find the option. It is possible that it was removed, because you can implement it with explicit dialplan.

There used to be a setting, meant typically for FXS analogue lines, in which Asterisk would present dialtone, read digits and use them to select an extension, without explicit dialplan code to do this.