asterisk users - Nov 2004 - PRI Dialing failure?

So I reached the point where my PRI is accepting incoming calls, but I
cannot dialout.  I must be doing something stupid, but I can't figure it
out.  The Asterisk box is sitting between the Mitel and the phone company,
and has PRI lines to each.  Asterisk was built from CVS r1-0

Log for a call from mitel heading outbound:
-------------------------

    -- Accepting call from '' to '15123455476' on channel 0/14,
span 2
Nov 28 15:27:05 DEBUG[1779]: chan_zap.c:1221 zt_enable_ec: No
echocancellation requested
    -- Executing Dial("Zap/38-1", "Zap/g3/5123455476") in
new stack
Nov 28 15:27:05 NOTICE[1787]: app_dial.c:743 dial_exec: Unable to create
channel of type 'Zap'
  == Everyone is busy/congested at this time
Nov 28 15:27:05 DEBUG[1787]: app_dial.c:1029 dial_exec: Exiting with
DIALSTATUS=CHANUNAVAIL.
    -- Executing Congestion("Zap/38-1", "") in new stack


The Configs:

-------------------------
zaptel.conf:
-------------------------
#Span 1  T1 to Remote Site
span=1,2,0,esf,b8zs
clear=1-24

#Span 2  Mitel
span=2,0,0,esf,b8zs
bchan=25-47
dchan=48

#Span 3  Verizon
span=3,1,0,esf,b8zs
bchan=49-71
dchan=72

-------------------------
zapata.conf:
-------------------------
[channels]

#Mitel
switchtype=dms100
context=frommitel
signalling=pri_net
group=>1
channel => 25-47

#Verizon
switchtype=dms100
context=external
signalling=pri_cpe
group=>2
channel => 49-71

-------------------------
extensions.conf
-------------------------
[globals]
OUTGOING-TRUNK=Zap/g3

[frommitel]
exten=>1234,1,Playback(vm-goodbye)
exten=>1234,2,Hangup
exten => _1NXXNXXXXXX, 1,Dial(${OUTGOING-TRUNK}/${EXTEN:1})
exten => _1NXXNXXXXXX, 2,Congestion

On Sunday 28 November 2004 19:01, mfarver@ticom.com
wrote:
> So I reached the point where my PRI is accepting incoming calls, but I
> cannot dialout.  I must be doing something stupid, but I can't figure
it
> out.  The Asterisk box is sitting between the Mitel and the phone company,
> and has PRI lines to each.  Asterisk was built from CVS r1-0
[...]
> -------------------------
> zapata.conf:
> -------------------------
> [channels]
>
> #Mitel
> switchtype=dms100
> context=frommitel
> signalling=pri_net
> group=>1
> channel => 25-47
>
> #Verizon
> switchtype=dms100
> context=external
> signalling=pri_cpe
> group=>2
> channel => 49-71
>
> -------------------------
> extensions.conf
> -------------------------
> [globals]
> OUTGOING-TRUNK=Zap/g3
Neither of your 2 PRIs are in group 3. Your span 1 seems non-existent.


B

This looks like a config issue, "class of service barred" but getting
config information out of verizon is nearly impossible.  I compared what
the Mitel is sending to asterisk (since the mitel does work with the PRI)
with what asterisk is sending and do not see any large differences.

debugging spam 3 asterisk to verizon:
--snip--
Enabled debugging on span 3
    -- Executing Dial("Zap/38-1", "Zap/g2/15123455476") in
new stack
-- Making new call for cr 32770
> Protocol Discriminator: Q.931 (8)  len=33
> Call Ref: len= 2 (reference 2/0x2) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a2]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer
capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps,
circuit-mode (16)
>                              Ext: 1  User information layer 1: u-Law (34)
> [18 03 a9 83 81]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive
Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel
Type: 3
>                       Ext: 1  Channel: 1 ]
> [6c 02 00 c3]
> Calling Number (len= 4) [ Ext: 0  TON: Unknown Number Type (0)  NPI:
Unknown Number Plan (0)
>                           Presentation: Number not available (67)
'' ]
> [70 0c a1 31 35 31 32 33 34 35 35 34 37 36]
> Called Number (len=14) [ Ext: 1  TON: National Number (2)  NPI:
ISDN/Telephony Numbering Plan (E.164/E.163) (1) '15123455476' ]
    -- Accepting call from '' to '15123455476' on channel 0/14,
span 2
Nov 28 17:04:29 DEBUG[2287]: chan_zap.c:1221 zt_enable_ec: No
echocancellation requested
    -- Called g2/15123455476
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 32770/0x8002) (Terminator)
< Message type: RELEASE COMPLETE (90)
< [08 02 82 b6]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0  
Location: Public network serving the local user (2)
<                  Ext: 1  Cause: Incoming call barred (54), class Service or
Option not Available (3) ]
-- Processing IE 8 (cs0, Cause)
    -- Channel 0/1, span 3 got hangup
Nov 28 17:04:29 DEBUG[2293]: chan_zap.c:2465 zt_setoption: Set option
AUDIO MODE, value: ON(1) on Zap/49-1
Nov 28 17:04:29 DEBUG[2293]: chan_zap.c:1975 zt_hangup: Hangup: channel:
49 index = 0, normal = 43, callwait = -1, thirdcall = -1
Nov 28 17:04:29 DEBUG[2293]: chan_zap.c:2103 zt_hangup: Already hungup... 
Calling hangup once, and clearing call
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null Nov
28 17:04:29 DEBUG[2293]: chan_zap.c:2377 zt_setoption: Set option TDD
MODE, value: OFF(0) on Zap/49-1
Nov 28 17:04:29 DEBUG[2293]: chan_zap.c:1193 update_conf: Updated
conferencing on 49, with 0 conference users
Nov 28 17:04:29 DEBUG[2293]: chan_zap.c:2459 zt_setoption: Set option
AUDIO MODE, value: OFF(0) on Zap/49-1
    -- Hungup 'Zap/49-1'
  == No one is available to answer at this time
Nov 28 17:04:29 DEBUG[2293]: app_dial.c:1029 dial_exec: Exiting with
DIALSTATUS=NOANSWER.
    -- Executing Congestion("Zap/38-1", "") in new stack

---------


debugging span 2, mitel to asterisk
---------------


Enabled debugging on span 2
< Protocol Discriminator: Q.931 (8)  len=29
< Call Ref: len= 2 (reference 7795/0x1E73) (Originator)
< Message type: SETUP (5)
< [04 03 80 90 a2]
< Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer
capability: Speech (0)
<                              Ext: 1  Trans mode/rate: 64kbps,
circuit-mode (16)
<                              Ext: 1  User information layer 1: u-Law
(34) < [18 03 a9 83 8e]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive
Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0   Number Specified   Channel
Type: 3
<                       Ext: 1  Channel: 14 ]
< [70 0c a1 31 35 31 32 33 34 35 35 34 37 36]
< Called Number (len=14) [ Ext: 1  TON: National Number (2)  NPI:
ISDN/Telephony Numbering Plan (E.164/E.163) (1) '15123455476' ]
-- Making new call for cr 7795
-- Processing Q.931 Call Setup
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 112 (cs0, Called Party Number)
> Protocol Discriminator: Q.931 (8)  len=10
> Call Ref: len= 2 (reference 40563/0x9E73) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 03 a9 83 8e]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive
Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel
Type: 3
>                       Ext: 1  Channel: 14 ]
    -- Executing Dial("Zap/38-1", "Zap/g2/15123455476") in
new stack --
Accepting call from '' to '15123455476' on channel 0/14, span 2
Nov 28 17:07:42 DEBUG[2309]: chan_zap.c:1221 zt_enable_ec: No
echocancellation requested
    -- Called g2/15123455476
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 40563/0x9E73) (Terminator)
> Message type: PROGRESS (3)
> [1e 02 81 88]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)
0: 0   Location: Private network serving the local user
(1)
>                               Ext: 1  Progress Description: Inband
information or appropriate pattern now
available. (8) ]
    -- Channel 0/1, span 3 got hangup
Nov 28 17:07:42 WARNING[2315]: app_dial.c:399 wait_for_answer: Unable to
forward voice
Nov 28 17:07:42 DEBUG[2315]: chan_zap.c:2465 zt_setoption: Set option
AUDIO MODE, value: ON(1) on Zap/49-1
Nov 28 17:07:42 DEBUG[2315]: chan_zap.c:1975 zt_hangup: Hangup: channel:
49 index = 0, normal = 43, callwait = -1, thirdcall = -1
Nov 28 17:07:42 DEBUG[2315]: chan_zap.c:2103 zt_hangup: Already hungup... 
Calling hangup once, and clearing call
Nov 28 17:07:42 DEBUG[2315]: chan_zap.c:2377 zt_setoption: Set option TDD
MODE, value: OFF(0) on Zap/49-1
Nov 28 17:07:42 DEBUG[2315]: chan_zap.c:1193 update_conf: Updated
conferencing on 49, with 0 conference users
Nov 28 17:07:42 DEBUG[2315]: chan_zap.c:2459 zt_setoption: Set option
AUDIO MODE, value: OFF(0) on Zap/49-1
    -- Hungup 'Zap/49-1'
  == No one is available to answer at this time
Nov 28 17:07:42 DEBUG[2315]: app_dial.c:1029 dial_exec: Exiting with
DIALSTATUS=NOANSWER.
    -- Executing Congestion("Zap/38-1", "") in new stack

On Sun, 28 Nov 2004 mfarver@ticom.com wrote:
> This looks like a config issue, "class of service barred" but
getting
> config information out of verizon is nearly impossible.  I compared what
> the Mitel is sending to asterisk (since the mitel does work with the PRI)
> with what asterisk is sending and do not see any large differences.
Perhaps they dislike the numbering plan for the calling number you sent? 
The Mitel sends no calling number in the debug log while Asterisk sent an 
empty number with TON/NPI unknown/unknown. Just an idea.

Peter

I figured it out.

The key was that the mitel was always dialing channel 14, Asterisk was
always dialing channel 1.

When I reconfigure asterisk to round robin dial the PRI group it started
at 1 and worked upwards.  If the channel in the debug output is >9 dialing
works.  It appears that the bottom 8 of the PRI channels are DID only.

So by changing my zapata.conf to this:

#Verizon
switchtype=national
context=external
signalling=pri_cpe
#Channels 49-56 are DID only
group=>2
channel => 49-56
group=>3
channel => 57-71

and setting the extensions.conf to dial group 3 yt works...

Thanks for the tip to the PRI debug output.

Mark Farver
> On Sun, 28 Nov 2004 mfarver@ticom.com wrote:
>
>> This looks like a config issue, "class of service barred" but
getting
>> config information out of verizon is nearly impossible.  I compared
what
>> the Mitel is sending to asterisk (since the mitel does work with the
>> PRI)
>> with what asterisk is sending and do not see any large differences.
>
> Perhaps they dislike the numbering plan for the calling number you sent?
> The Mitel sends no calling number in the debug log while Asterisk sent an
> empty number with TON/NPI unknown/unknown. Just an idea.
>
> Peter
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>