Dialing out PRI channel and sending the right number/digits

Asterisk Asterisk Support
#1

Hi,

I have several PRI and BRI cards all working fine except for one PRI line/port which is “misbehaving”.

Just for the record, this failing PRI line works fine with an old Asterisk 1.4 with libpri. It “misbehaves” when moving it to a new Asterisk 18.10.0 with libpri 1.6.0.

Whenever I dial “DAHDI/g4/${DIALED_NUMBER}” I can hear my provider’s automated voice saying that the dialed number does not exist.
So I’m guessing that the PRI port (Digium) works fine, and that I am accessing my provider’s services. However, it seems (just a thought here) that Asterisk is not sending the digits out properly through the PRI line (or the provider is not receiving all of them properly).
It’s as if ${DIALED_NUMBER} were sent truncated somehow. I have no proof of this because I have no way of knowing what the PRI line provider is actually “seeing”.

This is what I see in the console:

    -- Called DAHDI/g4/${DIALED_NUMBER}
    -- DAHDI/i6/${DIALED_NUMBER}-c is proceeding passing it to PJSIP/web4053-000000ed
    -- DAHDI/i6/${DIALED_NUMBER}-c is making progress passing it to PJSIP/web4053-000000ed
       > 0x7fa67812d4e0 -- Strict RTP learning after remote address set to: ${ASTERISK_SERVER_PUB_IP_ADDR1}:26898
       > 0x7fa67812d4e0 -- Strict RTP learning after ICE completion
       > 0x7fa67812d4e0 -- Strict RTP learning after remote address set to: ${CLIENT_IP_ADDR}:41237
    -- PJSIP/web4053-000000ed requested media update control 26, passing it to DAHDI/i6/${DIALED_NUMBER}-c
       > 0x7fa67812d4e0 -- Strict RTP switching to RTP target address ${CLIENT_IP_ADDR}:41237 as source

My chan_dahdi.conf includes a files which contains:

; Span 6: WCTE2/0/2 "WCTE23X (PCI) Card 0 Span 2" CCS/HDB3/CRC4 RED
group=4,16
context=from-pstn
switchtype = euroisdn
signalling = pri_cpe
channel => 44-58,60-74
context = default
group = 63

My /etc/dahdi/system.conf contains:

# Span 6: WCTE2/0/2 "WCTE23X (PCI) Card 0 Span 2" CCS/HDB3/CRC4 RED
span=6,6,0,ccs,hdb3,crc4
# termtype: te
bchan=44-58,60-74
dchan=59
echocanceller=mg2,44-58,60-74

If I run
# asterisk -rx "pri show spans"
I can see that the span is up:
PRI span 6/0: Up, Active

Here are the details:

# asterisk -rx "pri show span 6"
Primary D-channel: 59
Status: Up, Active
Switchtype: EuroISDN
Type: CPE
Remote type: Network
Overlap Dial: 0
Logical Channel Mapping: 0
Timer and counter settings:
  N200: 3
  N202: 3
  K: 7
  T200: 1000
  T201: 1000
  T202: 2000
  T203: 10000
  T303: 4000
  T305: 30000
  T308: 4000
  T309: 6000
  T312: 6000
  T313: 4000
  T316: -1
  N316: 2
  T-HOLD: 4000
  T-RETRIEVE: 4000
  T-RESPONSE: 4000
  T-STATUS: 4000
  T-ACTIVATE: 10000
  T-DEACTIVATE: 4000
  T-INTERROGATE: 4000
  T-RETENTION: 30000
  T-CCBS1: 4000
  T-CCBS2: 2700000
  T-CCBS3: 20000
  T-CCBS4: 5000
  T-CCBS5: 3600000
  T-CCBS6: 3600000
  T-CCNR2: 10800000
  T-CCNR5: 11700000
  T-CCNR6: 11700000
Q931 RX: 55
Q931 TX: 47
Q921 RX: 165
Q921 TX: 75385
Q921 Outstanding: 0 (TEI=0)
Total active-calls:0 global:0
CC records:
Overlap Recv: No

I also ran
pri set debug on span 6
and I’m getting lots of messages in the console.

Example:

    -- Executing [s@custom-dialout:2] Dial("PJSIP/web4053-0000017d", "DAHDI/g4/${DIALED_NUMBER},300,tTwWxX") in new stack
PRI Span: 6 -- Making new call for cref 32778
    -- Requested transfer capability: 0x00 - SPEECH
PRI Span: 6
PRI Span: 6 > DL-DATA request
PRI Span: 6 > Protocol Discriminator: Q.931 (8)  len=36
PRI Span: 6 > TEI=0 Call Ref: len= 2 (reference 10/0xA) (Sent from originator)
PRI Span: 6 > Message Type: SETUP (5)
PRI Span: 6 TEI=0 Transmitting N(S)=12, window is open V(A)=12 K=7
PRI Span: 6
PRI Span: 6 > Protocol Discriminator: Q.931 (8)  len=36
PRI Span: 6 > TEI=0 Call Ref: len= 2 (reference 10/0xA) (Sent from originator)
PRI Span: 6 > Message Type: SETUP (5)
PRI Span: 6 > [04 03 80 90 a3]
PRI Span: 6 > Bearer Capability (len= 5) [ Ext: 1  Coding-Std: 0  Info transfer capability: Speech (0)
PRI Span: 6 >                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
PRI Span: 6 >                                User information layer 1: A-Law (35)
PRI Span: 6 > [18 03 a1 83 81]
PRI Span: 6 > Channel ID (len= 5) [ Ext: 1  IntID: Implicit  Other(PRI)  Spare: 0  Preferred  Dchan: 0
PRI Span: 6 >                       ChanSel: As indicated in following octets
PRI Span: 6 >                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
PRI Span: 6 >                       Ext: 1  Channel: 1 Type: CPE]
PRI Span: 6 > [6c 06 21 80 34 30 35 33]
PRI Span: 6 > Calling Party Number (len= 8) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
PRI Span: 6 >                                 Presentation: Presentation allowed, User-provided, not screened (0)  '4053' ]
PRI Span: 6 > [70 0a 80 36 35 36 36 36 30 34 39 39]
PRI Span: 6 > Called Party Number (len=12) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)  '${DIALED_NUMBER}' ]
PRI Span: 6 > [a1]
PRI Span: 6 > Sending Complete (len= 1)
PRI Span: 6 q931.c:6531 q931_setup: Call 32778 enters state 1 (Call Initiated).  Hold state: Idle
    -- Called DAHDI/g4/${DIALED_NUMBER}
PRI Span: 6
PRI Span: 6 < Protocol Discriminator: Q.931 (8)  len=10
PRI Span: 6 < TEI=0 Call Ref: len= 2 (reference 10/0xA) (Sent to originator)
PRI Span: 6 < Message Type: CALL PROCEEDING (2)
PRI Span: 6 < [18 03 a9 83 81]
PRI Span: 6 < Channel ID (len= 5) [ Ext: 1  IntID: Implicit  Other(PRI)  Spare: 0  Exclusive  Dchan: 0
PRI Span: 6 <                       ChanSel: As indicated in following octets
PRI Span: 6 <                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
PRI Span: 6 <                       Ext: 1  Channel: 1 Type: CPE]
PRI Span: 6 Received message for call 0x7fa61812f420 on link 0x55ff206ddfe0 TEI/SAPI 0/0
PRI Span: 6 -- Processing IE 24 (cs0, Channel ID)
PRI Span: 6 q931.c:9095 post_handle_q931_message: Call 32778 enters state 3 (Outgoing Call Proceeding).  Hold state: Idle
Span 6: Processing event PRI_EVENT_PROCEEDING(13)
    -- DAHDI/i6/${DIALED_NUMBER}-11 is proceeding passing it to PJSIP/web4053-0000017d
PRI Span: 6
PRI Span: 6 < Protocol Discriminator: Q.931 (8)  len=13
PRI Span: 6 < TEI=0 Call Ref: len= 2 (reference 10/0xA) (Sent to originator)
PRI Span: 6 < Message Type: PROGRESS (3)
PRI Span: 6 < [1e 02 8a 81]
PRI Span: 6 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Network beyond the interworking point (10)
PRI Span: 6 <                               Ext: 1  Progress Description: Call is not end-to-end ISDN; further call progress information may be available inband. (1) ]
PRI Span: 6 < [1e 02 8a 88]
PRI Span: 6 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Network beyond the interworking point (10)
PRI Span: 6 <                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
PRI Span: 6 Received message for call 0x7fa61812f420 on link 0x55ff206ddfe0 TEI/SAPI 0/0
PRI Span: 6 -- Processing IE 30 (cs0, Progress Indicator)
PRI Span: 6 -- Processing IE 30 (cs0, Progress Indicator)
Span 6: Processing event PRI_EVENT_PROGRESS(17)
    -- DAHDI/i6/${DIALED_NUMBER}-11 is making progress passing it to PJSIP/web4053-0000017d
       > 0x7fa5e410e550 -- Strict RTP learning after remote address set to: ${ASTERISK_SERVER_PUBLIC_IP_ADDR1}:21728
       > 0x7fa5e410e550 -- Strict RTP learning after ICE completion
       > 0x7fa5e410e550 -- Strict RTP learning after remote address set to: ${CLIENT_IP_ADDR}:40221
    -- PJSIP/web4053-0000017d requested media update control 26, passing it to DAHDI/i6/${DIALED_NUMBER}-11
       > 0x7fa5e410e550 -- Strict RTP switching to RTP target address ${CLIENT_IP_ADDR}:40221 as source
       > 0x7fa5e410e550 -- Strict RTP learning complete - Locking on source address ${CLIENT_IP_ADDR}:40221
PRI Span: 6
PRI Span: 6 < Protocol Discriminator: Q.931 (8)  len=9
PRI Span: 6 < TEI=0 Call Ref: len= 2 (reference 10/0xA) (Sent to originator)
PRI Span: 6 < Message Type: DISCONNECT (69)
PRI Span: 6 < [08 02 83 9f]
PRI Span: 6 < Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Transit network (3)
PRI Span: 6 <                  Ext: 1  Cause: Normal, unspecified (31), class = Normal Event (1) ]
PRI Span: 6 Received message for call 0x7fa61812f420 on link 0x55ff206ddfe0 TEI/SAPI 0/0
PRI Span: 6 -- Processing IE 8 (cs0, Cause)
PRI Span: 6 -- Found active call: 0x7fa61812f420 cref:32778
PRI Span: 6 q931.c:9345 post_handle_q931_message: Call 32778 enters state 12 (Disconnect Indication).  Hold state: Idle
Span 6: Processing event PRI_EVENT_HANGUP_REQ(15)
    -- Span 6: Channel 0/1 got hangup request, cause 31
PRI Span: 6 q931.c:7332 q931_hangup: Hangup other cref:32778
PRI Span: 6 q931.c:7089 __q931_hangup: ourstate Disconnect Indication, peerstate Disconnect Request, hold-state Idle
PRI Span: 6 q931.c:6124 q931_release: Call 32778 enters state 19 (Release Request).  Hold state: Idle
PRI Span: 6
PRI Span: 6 > DL-DATA request
PRI Span: 6 > Protocol Discriminator: Q.931 (8)  len=9
PRI Span: 6 > TEI=0 Call Ref: len= 2 (reference 10/0xA) (Sent from originator)
PRI Span: 6 > Message Type: RELEASE (77)
PRI Span: 6 TEI=0 Transmitting N(S)=13, window is open V(A)=13 K=7
PRI Span: 6
PRI Span: 6 > Protocol Discriminator: Q.931 (8)  len=9
PRI Span: 6 > TEI=0 Call Ref: len= 2 (reference 10/0xA) (Sent from originator)
PRI Span: 6 > Message Type: RELEASE (77)
PRI Span: 6 > [08 02 81 9f]
PRI Span: 6 > Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
PRI Span: 6 >                  Ext: 1  Cause: Normal, unspecified (31), class = Normal Event (1) ]
    -- Hungup 'DAHDI/i6/${DIALED_NUMBER}-11'
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [s@custom-dialout:3] Return("PJSIP/web4053-0000017d", "") in new stack
    -- Executing [${DIALED_NUMBER}@default:3] Hangup("PJSIP/web4053-0000017d", "") in new stack
  == Spawn extension (default, ${DIALED_NUMBER}, 3) exited non-zero on 'PJSIP/web4053-0000017d'
PRI Span: 6
PRI Span: 6 < Protocol Discriminator: Q.931 (8)  len=5
PRI Span: 6 < TEI=0 Call Ref: len= 2 (reference 10/0xA) (Sent to originator)
PRI Span: 6 < Message Type: RELEASE COMPLETE (90)
PRI Span: 6 Received message for call 0x7fa61812f420 on link 0x55ff206ddfe0 TEI/SAPI 0/0
PRI Span: 6 q931.c:9204 post_handle_q931_message: Call 32778 enters state 0 (Null).  Hold state: Idle
PRI Span: 6 q931.c:7332 q931_hangup: Hangup other cref:32778
PRI Span: 6 q931.c:7089 __q931_hangup: ourstate Null, peerstate Null, hold-state Idle
PRI Span: 6 Destroying call 0x7fa61812f420, ourstate Null, peerstate Null, hold-state Idle
Span 6: Processing event PRI_EVENT_HANGUP_ACK(9)

As I said before, during the above console log I can hear the provider’s autoamted voice telling me that the number I dialed is invalid or the subscriber doesn’t exist.

Also, the provider does not require a special prefix to dial out.
In fact, if I check my old Asterisk 1.4 system I can confirm that I’m dialing out the same way but with “ZAP/g1/${DIALED_NUMBER}|300|TWf” where ${DIALED_NUMBER} is exactly the same.

My old /etc/asterisk/zapata.conf (Asterisk 1.4) is:

[trunkgroups]
trunkgroup => 1,16
spanmap => 1,1,1
[channels]
language=es
context=from-zaptel
signalling=fxs_ks
rxwink=300 
usecallerid=yes
cidsignalling=dtmf
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
rxgain=14.0
txgain=1.0
group=0
immediate=no
busydetect=no
callprogress=no
faxdetect=no
switchtype = euroisdn
signalling = pri_cpe
overlapdial=yes
context=from-alcatel-custom
group = 1
callgroup = 1
pickupgroup = 1
immediate=no
echocancel=yes
echotraining=yes
echocancelwhenbridged=yes
rxgain=2.0
txgain=1.0
busydetect=no
facilityenable = yes
transfer = yes
channel => 1-15
channel => 17-31

My old /etc/zaptel.conf is:

span=1,1,0,ccs,hdb3,crc4
bchan=1-15
dchan=16
bchan=17-31

Still in my old Asterisk 1.4 system:

# asterisk -rx "pri show span 1"
Primary D-channel: 16
Status: Provisioned, Up, Active
Switchtype: EuroISDN
Type: CPE
Overlap Dial: 1
Logical Channel Mapping: 0
Timer and counter settings:
  N200: 3
  N202: 3
  K: 7
  T200: 1000
  T202: 10000
  T203: 10000
  T303: 4000
  T305: 30000
  T308: 4000
  T309: 6000
  T313: 4000
  T-HOLD: 4000
  T-RETRIEVE: 4000
  T-RESPONSE: 4000
Overlap Recv: Yes

So, I’m wondering why the calls are working fine in the old 1.4 system but not in the new one.

Any ideas?

#2

I haven’t used ISDN cards for years myself, but you can generate pcap traces from these connections as well and then analyze them with Wireshark. I once had a small problem that was quickly solved by Sangoma with such a trace. In my case it was a wrong idle message that occurred under some operating conditions (was BRI not PRI).

#3

Thanks, but I was hoping someone from Digium could take a look at this here. My company bought these cards several years ago. Not sure I can open a support ticket.

Also, no idea how to dump a pcap trace of a PRI hardware interface. I think Sangoma has specific programs for that. I’m not sure Digium/DAHDI does. I thought a “pri debug” log would be enough.

#4

There was nothing special. I think it was the wanpipemon tool to capture the traces, but my cards came from Sangoma. There’s probably something similar for the Digium cards.

#5

Hello,

Can you check for numbering format set , it looks like your system is stripping off numbers which could be issue of call failing, you can try to trouble shoot it with your tel co.

Regards
CJ

#6

Hi,

What do you mean by “numbering format set”? Are there libpri options for that?
In Asterisk I’m just dialing DAHDI/group/number. Is there any special option to the Dial command?

I just noticed one thing though. In my old Asterisk 1.4 system I see this for my PRI line:

Overlap Dial: 1

while I see this in my newer PBX:

Overlap Dial: 0

I’m not sure what that does and how to change that option…

#7

Hello,

In your chan_dahdi.conf file

[channels]
context=incoming
switchtype=euroisdn
signaling=pri_cpe
overlapdial=yes**

** you can enable or disable overlap dial

Regards
CJ

#8

Overlap dialling is the ability to send initial digits before the complete number is available.

#9

I added the overlapdial parameter and could check that the setting was applied:

Overlap Dial: 1

However, I’m still getting the same behavior, ie. the telco seems to be unable to “read” every single digit Asterisk is sending.

Do you have any other suggestions apart from trying to debug this with the telco?
I also didn’t find any dahdi_* binaries to dump PRI traffic. I guess I can only make do with “pri set debug”.

#10

What does the “immediate” parameter do if set to no.
What is the default value for “immediate” if never specified by user?

EDIT: I read the comments in the sample config file, but I don’t know what to make of it when dialing OUT a PRI line.

#11

You are sending an invalid caller ID number. It looks like you are sending an internal number, but you are sending it with type of number of National, which means the network is expecting to a long distance number for your country without the initial long distance access code, e.g. 5551234567 for North America, or 20 xxxx xxxx for an older inner London number if in the UK. It’s just possible that they are actually complaining about the caller ID. Unfortunately they are dong a voice announcement, as early media, probably because the rejection is happening beyond the boundary of the ISDN network, rather than a specific clearing cause.

The fact that the rejection is remote complicates things, as it might not be your service provider that is actually rejecting the call.

I also note that you are sending with type of number = unknown. That would typically cause the number to be interpreted as if dialled from a simple phone, but is also possible that they expect a national or international number, and don’t bother to check the type of number, and the call has been routed as though it started with an area or country code.

Because this is ISDN, the number is being sent in a checksummed data packet, so what is being logged is what the provider will be receiving.

#12

You almost certainly don’t want it set to no on an exchange line. It’s purpose is really for analogue stations (phones). If not immediate, Asterisk will present dial tone and obtain the dialled number, before any dialplan is run.

#13

Thanks a lot for that. So, the caller ID part could have something to do with it, but the tests I ran didn’t change anything.

I tried setting CALLERID(all) to an empty string:

    -- Executing [${DIALED_NUMBER}@default:2] Gosub("PJSIP/web4053-00000008", "custom-dialout-PROVIDER1,s,1(${DIALED_NUMBER})") in new stack
    -- Executing [s@custom-dialout-PROVIDER1:1] NoOp("PJSIP/web4053-00000008", "custom-dialout-PROVIDER1 ${DIALED_NUMBER}") in new stack
    -- Executing [s@custom-dialout-PROVIDER1:2] Set("PJSIP/web4053-00000008", "CALLERID(all)=") in new stack
    -- Executing [s@custom-dialout-PROVIDER1:3] NoOp("PJSIP/web4053-00000008", "caller ID set to "" <>") in new stack
    -- Executing [s@custom-dialout-PROVIDER1:4] Dial("PJSIP/web4053-00000008", "DAHDI/g4/${DIALED_NUMBER},300,tTwWxX") in new stack
PRI Span: 6 -- Making new call for cref 32770
    -- Requested transfer capability: 0x00 - SPEECH
PRI Span: 6
PRI Span: 6 > DL-DATA request
PRI Span: 6 > Protocol Discriminator: Q.931 (8)  len=31
PRI Span: 6 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 6 > Message Type: SETUP (5)
PRI Span: 6 TEI=0 Transmitting N(S)=2, window is open V(A)=2 K=7
PRI Span: 6
PRI Span: 6 > Protocol Discriminator: Q.931 (8)  len=31
PRI Span: 6 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 6 > Message Type: SETUP (5)
PRI Span: 6 > [04 03 80 90 a3]
PRI Span: 6 > Bearer Capability (len= 5) [ Ext: 1  Coding-Std: 0  Info transfer capability: Speech (0)
PRI Span: 6 >                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
PRI Span: 6 >                                User information layer 1: A-Law (35)
PRI Span: 6 > [18 03 a1 83 81]
PRI Span: 6 > Channel ID (len= 5) [ Ext: 1  IntID: Implicit  Other(PRI)  Spare: 0  Preferred  Dchan: 0
PRI Span: 6 >                       ChanSel: As indicated in following octets
PRI Span: 6 >                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
PRI Span: 6 >                       Ext: 1  Channel: 1 Type: CPE]
PRI Span: 6 > [6c 02 21 80]
PRI Span: 6 > Calling Party Number (len= 4) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
PRI Span: 6 >                                 Presentation: Presentation allowed, User-provided, not screened (0)  '' ]
PRI Span: 6 > [70 0a 80 36 35 36 36 36 30 34 39 39]
PRI Span: 6 > Called Party Number (len=12) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)  '${DIALED_NUMBER}' ]
PRI Span: 6 q931.c:6531 q931_setup: Call 32770 enters state 1 (Call Initiated).  Hold state: Idle
    -- Called DAHDI/g4/${DIALED_NUMBER}
PRI Span: 6
PRI Span: 6 < Protocol Discriminator: Q.931 (8)  len=10
PRI Span: 6 < TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent to originator)
PRI Span: 6 < Message Type: CALL PROCEEDING (2)
PRI Span: 6 < [18 03 a9 83 81]
PRI Span: 6 < Channel ID (len= 5) [ Ext: 1  IntID: Implicit  Other(PRI)  Spare: 0  Exclusive  Dchan: 0
PRI Span: 6 <                       ChanSel: As indicated in following octets
PRI Span: 6 <                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
PRI Span: 6 <                       Ext: 1  Channel: 1 Type: CPE]
PRI Span: 6 Received message for call 0x7faef00187a0 on link 0x55846bb55890 TEI/SAPI 0/0
PRI Span: 6 -- Processing IE 24 (cs0, Channel ID)
PRI Span: 6 q931.c:9095 post_handle_q931_message: Call 32770 enters state 3 (Outgoing Call Proceeding).  Hold state: Idle
Span 6: Processing event PRI_EVENT_PROCEEDING(13)
    -- DAHDI/i6/${DIALED_NUMBER}-2 is proceeding passing it to PJSIP/web4053-00000008
PRI Span: 6
PRI Span: 6 < Protocol Discriminator: Q.931 (8)  len=13
PRI Span: 6 < TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent to originator)
PRI Span: 6 < Message Type: PROGRESS (3)
PRI Span: 6 < [1e 02 8a 81]
PRI Span: 6 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Network beyond the interworking point (10)
PRI Span: 6 <                               Ext: 1  Progress Description: Call is not end-to-end ISDN; further call progress information may be available inband. (1) ]
PRI Span: 6 < [1e 02 8a 88]
PRI Span: 6 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Network beyond the interworking point (10)
PRI Span: 6 <                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
PRI Span: 6 Received message for call 0x7faef00187a0 on link 0x55846bb55890 TEI/SAPI 0/0
PRI Span: 6 -- Processing IE 30 (cs0, Progress Indicator)
PRI Span: 6 -- Processing IE 30 (cs0, Progress Indicator)
Span 6: Processing event PRI_EVENT_PROGRESS(17)
    -- DAHDI/i6/${DIALED_NUMBER}-2 is making progress passing it to PJSIP/web4053-00000008
       > 0x7faf9c08efb0 -- Strict RTP learning after remote address set to: ${ASTERISK_SERVER_PUBLIC_IP_ADDR1}:37882
       > 0x7faf9c08efb0 -- Strict RTP learning after ICE completion
       > 0x7faf9c08efb0 -- Strict RTP learning after remote address set to: ${CLIENT_IP_ADDR}:44309
    -- PJSIP/web4053-00000008 requested media update control 26, passing it to DAHDI/i6/${DIALED_NUMBER}-2
       > 0x7faf9c08efb0 -- Strict RTP switching to RTP target address ${CLIENT_IP_ADDR}:44309 as source
       > 0x7faf9c08efb0 -- Strict RTP learning complete - Locking on source address ${CLIENT_IP_ADDR}:44309
PRI Span: 6
PRI Span: 6 < Protocol Discriminator: Q.931 (8)  len=9
PRI Span: 6 < TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent to originator)
PRI Span: 6 < Message Type: DISCONNECT (69)
PRI Span: 6 < [08 02 83 9f]
PRI Span: 6 < Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Transit network (3)
PRI Span: 6 <                  Ext: 1  Cause: Normal, unspecified (31), class = Normal Event (1) ]
PRI Span: 6 Received message for call 0x7faef00187a0 on link 0x55846bb55890 TEI/SAPI 0/0
PRI Span: 6 -- Processing IE 8 (cs0, Cause)
PRI Span: 6 -- Found active call: 0x7faef00187a0 cref:32770
PRI Span: 6 q931.c:9345 post_handle_q931_message: Call 32770 enters state 12 (Disconnect Indication).  Hold state: Idle
Span 6: Processing event PRI_EVENT_HANGUP_REQ(15)
    -- Span 6: Channel 0/1 got hangup request, cause 31
PRI Span: 6 q931.c:7332 q931_hangup: Hangup other cref:32770
PRI Span: 6 q931.c:7089 __q931_hangup: ourstate Disconnect Indication, peerstate Disconnect Request, hold-state Idle
PRI Span: 6 q931.c:6124 q931_release: Call 32770 enters state 19 (Release Request).  Hold state: Idle
PRI Span: 6
PRI Span: 6 > DL-DATA request
PRI Span: 6 > Protocol Discriminator: Q.931 (8)  len=9
PRI Span: 6 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 6 > Message Type: RELEASE (77)
PRI Span: 6 TEI=0 Transmitting N(S)=3, window is open V(A)=3 K=7
PRI Span: 6
PRI Span: 6 > Protocol Discriminator: Q.931 (8)  len=9
PRI Span: 6 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 6 > Message Type: RELEASE (77)
PRI Span: 6 > [08 02 81 9f]
PRI Span: 6 > Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
PRI Span: 6 >                  Ext: 1  Cause: Normal, unspecified (31), class = Normal Event (1) ]
    -- Hungup 'DAHDI/i6/${DIALED_NUMBER}-2'
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [s@custom-dialout-PROVIDER1:5] Return("PJSIP/web4053-00000008", "") in new stack
    -- Executing [${DIALED_NUMBER}@default:3] Hangup("PJSIP/web4053-00000008", "") in new stack
  == Spawn extension (default, ${DIALED_NUMBER}, 3) exited non-zero on 'PJSIP/web4053-00000008'
PRI Span: 6
PRI Span: 6 < Protocol Discriminator: Q.931 (8)  len=5
PRI Span: 6 < TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent to originator)
PRI Span: 6 < Message Type: RELEASE COMPLETE (90)
PRI Span: 6 Received message for call 0x7faef00187a0 on link 0x55846bb55890 TEI/SAPI 0/0
PRI Span: 6 q931.c:9204 post_handle_q931_message: Call 32770 enters state 0 (Null).  Hold state: Idle
PRI Span: 6 q931.c:7332 q931_hangup: Hangup other cref:32770
PRI Span: 6 q931.c:7089 __q931_hangup: ourstate Null, peerstate Null, hold-state Idle
PRI Span: 6 Destroying call 0x7faef00187a0, ourstate Null, peerstate Null, hold-state Idle
Span 6: Processing event PRI_EVENT_HANGUP_ACK(9)

This is a cellphone PRI so I also tried setting a valid caller ID such as:

PRI Span: 6 > Calling Party Number (len=13) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
PRI Span: 6 >                                 Presentation: Presentation allowed, User-provided, not screened (0)  '313534053' ]
PRI Span: 6 > [70 0a 80 36 35 36 36 36 30 34 39 39]
PRI Span: 6 > Called Party Number (len=12) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)  '${DIALED_NUMBER}' ]

I still get the same result though.
The Digium card I’m using (TE235) has serial number DM05144300001 if that can be of any help.

Just for the sake of comparing I took a pri debug of the exact same call when placed through my older Asterisk 1.4 system. I can see this bit:

> Calling Number (len= 8) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation permitted, user number not screened (0)  '7021' ]
> [70 0a a1 36 35 36 36 36 30 34 39 39]
> Called Number (len=12) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '${DIALED_NUMBER}' ]
q931.c:5039 q931_setup: Call 35565 enters state 1 (Call Initiated).  Hold state: Idle

Note that the caller ID is 7021 instead of 4053 in this case, but that’s irrelevant because both 7021 and 4053 are not settable through this provider.

Here I can see that both TON and NPI are clearly defined.
Maybe that’s it, but how do I fix the TON and NPI issue in the new Asterisk 18 system?

#14

From the chan_dahdi sample config file I can read:

; pridialplan may be also set at dialtime, by prefixing the dialed number with
; one of the following letters:
; U - Unknown
; I - International
; N - National
; L - Local (Net Specific)
; S - Subscriber
; V - Abbreviated
; R - Reserved (should probably never be used but is included for completeness)
;
; Additionally, you may also set the following NPI bits (also by prefixing the
; dialed string with one of the following letters):
; u - Unknown
; e - E.163/E.164 (ISDN/telephony)
; x - X.121 (Data)
; f - F.69 (Telex)
; n - National
; p - Private
; r - Reserved (should probably never be used but is included for completeness)
;
; You may also set the prilocaldialplan in the same way, but by prefixing the
; Caller*ID Number rather than the dialed number.

; Please note that telcos which require this kind of additional manipulation
; of the TON/NPI are *rare*.  Most telco PRIs will work fine simply by
; setting pridialplan to unknown or dynamic.

My older Asterisk 1.4 system does not custom-set any pri*dialplan options so my new Asterisk 18 system doesn’t either.
However, given the situation I might try to set TON and NPI via dialplan.

Since I get “TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)” for the “Called Party Number” then I guess I need to change the way I dial the number with:

Dial(DAHDI/g4/Ne${DIALED_NUMBER})

Here’s the result:

PRI Span: 6 > Calling Party Number (len= 4) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
PRI Span: 6 >                                 Presentation: Presentation allowed, User-provided, not screened (0)  '' ]
PRI Span: 6 > [70 0a a1 36 35 36 36 36 30 34 39 39]
PRI Span: 6 > Called Party Number (len=12) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '${DIALED_NUMBER}' ]
PRI Span: 6 q931.c:6531 q931_setup: Call 32771 enters state 1 (Call Initiated).  Hold state: Idle
    -- Called DAHDI/g4/Ne${DIALED_NUMBER}

…and the call goes through just fine!

So I’m glad it finally works despite the fact that current Asterisk/Dahdi/libpri are not able to automatically detect the proper values as my old Asterisk 1.4 system did.

In any case, thank you very much for all the hints and info.

#15