Real T1 trunk group…

Home » Asterisk Users » Real T1 trunk group…
Asterisk Users 5 Comments

Hey all!

I’m not sure if this went out the first time I sent it so I apologize now
if it’s a duplicate.

I’ve been banging my head against the wall for a while (almost 18 hours
today alone) with this one… I migrated our incomming T1’s from the Option
11 to our Asterisk box this morning. We have 1 local T1 and 2 long distance
T1’s. The local T1 went over with out a hitch. The problem is with my 2
long distance T1’s. The switch on the other end is a DMS250 I’m told so I
set Asterisk to DMS100 and got the timing, framing, etc all set. Well, the
D channels came up so thats good. I started getting dropped calls every
once in a while. I did a debug on the spans and saw the following:

PRI Span: 3
PRI Span: 3 < Protocol Discriminator: Q.931 (8) len=40
PRI Span: 3 < TEI=0 Call Ref: len= 2 (reference 857/0x359) (Sent from
originator)
PRI Span: 3 < Message Type: SETUP (5)
PRI Span: 3 < [04 03 80 90 a2]
PRI Span: 3 < Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info
transfer capability: Speech (0)
PRI Span: 3 < Ext: 1 Trans mode/rate: 64kbps,
circuit-mode (16)
PRI Span: 3 < User information layer 1:
u-Law (34)
PRI Span: 3 < [18 04 e9 80 83 08]
PRI Span: 3 < Channel ID (len= 6) [ Ext: 1 IntID: Explicit Other(PRI)
Spare: 0 Exclusive Dchan: 0
PRI Span: 3 < ChanSel: As indicated in following
octets
*PRI Span: 3 < Ext: 1 DS1 Identifier: 0
*PRI Span: 3 < Ext: 1 Coding: 0 Number Specified
Channel Type: 3
PRI Span: 3 < Ext: 0 Channel: 8 Type: CPE]
PRI Span: 3 < [20 02 00 e2]
PRI Span: 3 < Network-Specific Facilities (len= 2) [ Toll Free MEGACOM ]
PRI Span: 3 < [6c 0c 21 83 37 32 37 34 3033 34 30 37 34]
PRI Span: 3 < Calling Number (len=14) [ Ext: 0 TON: National Number (2)
NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)

The key part is the “*Ext: 1 DS1 Identifier: 0*” part. That’s when calls
fail. Right now, all calls are coming in on span 3 and want to talk to
Identifier 0 (span 2). If a call comes in on span 2 and requests “*Ext: 1
DS1 Identifier: 1*”, it fails. I called Verizon and asked them what was
going on. Turns out, its configured as a trunk group. The tech mentioned
that I need to figure out how to set my identifiers on the group and I
should be good to go. I’ve done a ton of research about chan_dahdi.conf and
dahdi-channels.conf and I think the answer is trunk groups.

I tried configuring a trunkgroup and set the primary dch to 24 and the bdch
to 72 and then then spanmap’ed span 2 and 3 into group 1 (e.g. 2,1,0 and
3,1,1) but I don’t see anything when I do a “dahdi show channels” or a “pri
show spans” or a “pri show channels”, not even the channels not in the
group. If I delete the trunkgroup, all three commands return all the
channels.

I’m just curious if I’m going down the right path with trunkgroups for this
or if there is something else to take care of the DS1 Identifier issue.

So another quick look… when a sucessful call comes in it goes to DS1
Identifier 0… the Asterisk CLI shows the following:

5 thoughts on - Real T1 trunk group…

  • Sounds similar to what I am doing. Migrating from a Nortel Option 61 to
    Asterisk. I have everything set, and am just waiting for an appropriate
    window to move the 4 T-1s (2 trunk groups). All PRIs are national
    though, not DMS100.
    Here are the relevant portions of my configs, I based them on a working
    model for PRIs connecting the Asterisk to the Option 61 as TIE trunks.
    This config has two dual port cards, with span 1 and 3 being a group and
    2 and 4 being a different group. I hope this helps. (Or perhaps
    identifies something I have wrong that may not have been found yet 😉

    Dale

    ###################################
    /etc/dahdi/system.conf
    ###################################

    # Span 1: TE2/0/1 “T2XXP (PCI) Card 0 Span 1” B8ZS/ESF RED
    span=1,1,0,esf,b8zs
    # termtype: unknown
    bchan=1-23
    dchan=24
    echocanceller=hwec,1-23

    # Span 2: TE2/0/2 “T2XXP (PCI) Card 0 Span 2” B8ZS/ESF RED
    span=2,2,0,esf,b8zs
    # termtype: unknown
    bchan=25-47
    dchan=48
    echocanceller=hwec,25-47

    # Span 3: TE2/1/1 “T2XXP (PCI) Card 1 Span 1” B8ZS/ESF RED
    span=3,3,0,esf,b8zs
    # termtype: unknown
    bchan=49-71
    dchan=72
    echocanceller=hwec,49-71

    # Span 4: TE2/1/2 “T2XXP (PCI) Card 1 Span 2” (MASTER) B8ZS/ESF RED
    span=4,4,0,esf,b8zs
    # termtype: unknown
    bchan=73-95
    dchan=96
    echocanceller=hwec,73-95

    ##############################
    /etc/asterisk/chan_dahdi.conf
    ##############################

    [trunkgroups]
    trunkgroup => 1,24,72
    trunkgroup => 2,48,96
    spanmap => 1,1,0
    spanmap => 3,1,1
    spanmap => 2,2,0
    spanmap => 4,2,1

    [channels]

    ….
    ; Span 1: TE2/0/1 “T2XXP (PCI) Card 0 Span 1” B8ZS/ESF RED
    ; General Trunking
    group=1
    context=from-pstn
    switchtype = national
    signalling = pri_cpe
    channel => 1-23

    ; Span 2: TE2/0/2 “T2XXP (PCI) Card 0 Span 2” B8ZS/ESF
    ; IVR Trunking
    group=2
    context=from-pstn
    switchtype = national
    signalling = pri_cpe
    channel => 25-47

    ; Span 3: TE2/1/1 “T2XXP (PCI) Card 1 Span 1” B8ZS/ESF
    ; General Trunking
    group=1
    context=from-pstn
    switchtype = national
    signalling = pri_cpe
    channel => 49-71

    ; Span 4: TE2/1/2 “T2XXP (PCI) Card 1 Span 2” (MASTER) B8ZS/ESF RED
    ; IVR Trunking
    group=2
    context=from-pstn
    switchtype = national
    signalling = pri_cpe
    channel => 73-95

  • Dale,

    That’s funny! That is almost exactly what I’m trying to do. Thanks for
    the quick response! I’m on the way into the office now and I’ll give
    the configuration a shot. I hope the config really helps. Maybe with
    our two migrations happening at the same time we maybe able to help
    each other out.

    I’ll reply back within the hour!

    Louis

    Sent from my iPhone

  • I have found that in most cases the easiest way to fix these issues is
    to simply call the provider and ask them to switch it to NI2. Most of
    them can do that while on the phone.

  • Well… It worked! I would have wrote back sooner but I got swamped
    with trying to move a business department to the new facility.

    I think my problem was that I fat fingered (actually, overlooked) the
    trunk group. The d channels should have been 48 and 72 because I was
    using span 2 and 3. I kept putting in 24 for the primary d channel.

    I’m going to have to find a window now so I can break it and put it
    back together again to verify. I made a change in chan_dahdi.conf on
    the group value for the spans too. I’m pretty sure that group value is
    for outbound calling though, right? Shouldn’t have impacted the trunk
    group.

    One last thing, the Verizon tech also mentioned that they are using
    “Most/Least idle” for call distribution, is there a way for * to do
    this too or should it not matter? I’m thinking italy not since both
    sides are keeping track of the in use channels so they shouldn’t send
    a call down a channel that’s busy and have a call “collide”.

    Thanks again Dale!

    V/r,
    Louis

  • Great! Glad to hear it is working for you 🙂
    Been there, done that. One of my greatest talents if fat fingering.
    I believe that you a correct. The group is used by Dial(). I do not
    believe it has impact on inbound, that is the context setting.
    As far as I know (I have not looked at the source), the options for
    outbound channel selection are:
    g – Hunt from low to high
    G – Hunt from high to low
    r – Round Robin Ascending
    R – Round Robin Descending

    In theory, it should not be a significant problem, but I suspect it may
    cause some issues if your system is heavily loaded as both you and
    Verison my attempt to initiate a call on the same channel, that is why
    typically the one end hunts low to high and the other hunts high to
    low. It will not eliminate collision, but it tends to reduce it. I am
    not sure what happens when a collision occurs.
    No problem. Glad to help. And it makes me feel better about my config.

    Dale