SIP to Dual PRI

[birddog]

We have a SIP to Dual PRI as one TG to customer (46Bs and 2Ds on cust end).
When the cust does a busy out the first 23 channels of the trunk, incoming calls are
then rejected and do not roll to the 2 PRI. Debugs show the calls are trying
channel 1 of the first PRI which is not available. Have tried putting both PRIs
under 1 isdn group with no luck. We can do a shout on the 1st PRI or the 1st T1
to the customer drop and the calls will roll to the 2nd PRI as expected however
the D ch on PRI 1 is then down. Does anyone know of an alternate config or is
this a bad test from the customer busying out from their PBX. Is there any way
to busy out B channels from the Adtran to make sure once 23 channels are used,
calls will continue to come in on channels 24-46 of the 2nd PRI?

setup:

SIP--->908e-----PRI 1 on drop T1 0/4------Shoretel PBX(2 PRIs 1 TG-46Bs and 2Ds on cust end)

                   |-----PRI 2 on drop T1 0/3----- 

Thanks

[jayh]

It may not be valid test depending on how the busy-out is accomplished.  If the channels were indeed busy then both sides of the PRI would have them so marked and the calls would roll over normally.

When the customer busies-out the channels, does the "sh int pri 1" change from:

  .......................D

to

MMMMMMMMMMMMMMMMMMMMMMMD

thus flagging the channels as in maintenance mode? 

If not, then it isn't likely a valid test.

Some things you could try:

• Turn on B-channel restarts.  This may propagate the busy-out condition to you but it will take a few minutes, not immediate.
• Separate the two PRIs into two trunks and grouped-trunks with a higher cost to the grouped-trunk for the second PRI.
• Don't do that test then, it's not valid.

When you have one PRI busied-out and place a call to it, what does a "debug isdn l2-f" show as the cause code?

[birddog]

Thanks for your response.

To answer your first question no, we don’t see the ch as in a
M=Maintenance mode. They show as

Channel status 123456789012345678901234

                  
-----------------------D

Legend: - =Unallocated

PBX vendor stats they only have one way to config and test on their end.  So if Im following you correctly, the B-channel restarts may force the adtran into seeing the ch as in M and not as unallocated?

  +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Here are the 3 configs we have tried, a stripped down look at the config, and the debug response.

• TEST 1 (basic config)

isdn-group 1

       connect pri 1

isdn-group 2

       connect pri 2

voice grouped-trunk DROP_PRI

       trunk T02

       trunk T03

       accept $ cost 10

    -----------------------D

SIP.STACK MSG   SIP/2.0 486 Busy Here

TM.T02 01 IsdnTmStateOutboundDeliver - rcvd unexpected CallRelease

2014.03.20 18:30:42 TM.T02 01 IsdnTmStateIdling - clear trunk appearance

2014.03.20 18:30:42 TM.T02 01 IsdnTmStateIdle::ClearCall - unexpected

• TEST 2(two trunks and grouped-trunks)

isdn-group 1

       connect pri 1

isdn-group 2

       connect pri 2

voice grouped-trunk DROP_PRI

       trunk T02

       accept $ cost 10

voice grouped-trunk DROP_PRI_2

       trunk T03

       accept $ cost 15

       -----------------------D

SIP.STACK MSG SIP/2.0 486 Busy Here

(no ISDN debug info or was not seen)

• TEST 3(Both PRIs under 1 isdn-group)

isdn-group 1

    connect pri 1

     connect pri 2

voice grouped-trunk DROP_PRI

       trunk T02

       trunk T03

       accept $ cost 10

     .......................D 
(shows active on adtran side)

ISDN.L2_FMT PRI 1    E4 Cause:100  (INVALID_ELEM_CONTENTS)

SIP.STACK MSG   SIP/2.0 501 Not Implemented

Thanks,

[jayh · Accepted solution]

It's somewhat surprising that this doesn't work.  The "Unallocated" should flag the TA900 to move on to the next PRI.  And, 486 Busy Here doesn't exactly look right unless the PBX is sending cause 17 USER BUSY. It may be that this type of busy-out is being interpreted as a user busy and in this case the Adtran is returning a SIP 486 which will result in a busy signal. 

There is a mapping between ISDN cause codes and SIP responses that can be tweaked but you aren't seeing any ISDN traffic.  I don't think you're getting complete ISDN debugs.

Your snippet

ISDN.L2_FMT PRI 1

E4 Cause:100  (INVALID_ELEM_CONTENTS)

should be part of a dialog showing a TX and RX with a lot more info.

The bottom line is that while it would be nice for this test to work it may not be practical in terms of time and effort.  The likelihood of an actual failure where the D-channel stays up and the B-channels all die won't happen very often.  The place for this to get fixed is in Adtran's development lab where they do interop testing with Shoretel code.  And then it boils down to semantics and interpretation of standards documents.  If Shoretel's implementation of ISDN is anything like their implementation of SIP, the problem isn't likely to be on the Adtran side. 

In other words, simulate a real failure by unplugging the PRI cable or shutting down the interface and verify that everything still works.

[Anonymous]

Hello,

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

Geoff

[birddog]

Found issue to be with the testing done to the PBX. To recap there was never an issue with the PRI failing over. If one PRI was taken down it would roll over. The issue was specific to if the cust busyed out the 1st 23 Bs, new incoming calls would fail and not come in on the open Bs of the 2nd PRI. We were able to shrink the first PRI tdm group down to just a few Bs and make manageable test calls that did roll over with the basic dual PRI config. For what ever reason if the cust put the Bs in maint on thir PBX the calls would still hit the first PRI and fail.

Thanks for the input

[Anonymous]

Has there been anymore work on this by Adtran?  I have this same issue, where in testing the customer Busies the 23 "B" channels on the first PRI and the Adtran will not advance calls to the second configured PRI.

We are seeing that the call is attempting to connect to the busied channel and the 486 Busy Here is sent bak in the SIP Stack.  Is there some config I should be adding to get this to try to route the call to the second PRI which has 23 availble channels?

[jayh]

rthompson wrote:

Has there been anymore work on this by Adtran? I have this same issue, where in testing the customer Busies the 23 "B" channels on the first PRI and the Adtran will not advance calls to the second configured PRI.

This likely isn't an Adtran problem, but relates to the ISDN cause code presented by the PBX when the channels are busied out. If the PBX sends cause 17 USER BUSY, then the Adtran is correct in not attempting to try the next PRI. This code basically tells the originator, "Play a busy signal."

There are a number of ISDN cause codes that can be sent to denote that the call can't be delivered on that channel, but might be deliverable on a different facility. The best next step would be to recreate the scenario and capture an ISDN debug l2-formatted on the Adtran. Depending on what is returned, that cause code should be mappable to something that causes the Adtran to advance to the next PRI.

See also my unanswered post from October 2015 about an inconsistency between the CLI and the GUI and possible issues when bundling two PRI interfaces.  TA900e with two PRIs in one trunk - inconsistency between CLI and GUI

We have been successful in configuring two trunks, one for each PRI, and listing them both in the voice grouped-trunk configuration. If you use a single trunk and ISDN-group you might try two ISDN-groups and trunks, then list them both in the voice grouped-trunk configuration.

[Anonymous]

Jay,

     This is our default configuration - to have two PRIs and Two Trunks in the one Voice Grouped-Trunk.   I have optioned B Channel restarts as a way to detect the maintenance state.  These restarts will occur only once per hour and the duration is not configurable beyond enabling/disabling restarts.  (from my ticket this is a know issue)

*******************  TRUNK CONFIGURATION   *************************************

!

voice trunk T02 type isdn

  description "T1 PRI #1 to PBX, TRUNK T02"

  resource-selection linear ascending

  connect isdn-group 1

  no early-cut-through

  modem-passthrough

  rtp delay-mode adaptive

  codec-list PRI-Trunk

!

voice trunk T03 type isdn

  description "T1 PRI #2 to PBX, TRUNK T03"

  resource-selection linear ascending

  connect isdn-group 2

  no early-cut-through

  modem-passthrough

  rtp delay-mode adaptive

  codec-list PRI-Trunk

!

!

voice grouped-trunk SIP

  description "SIP Voice Grouped Trunk"

  trunk T01

  accept $ cost 0

!

!

voice grouped-trunk PRI

  description "PRI Voice Grouped Trunk"

  trunk T02

  trunk T03

  accept $ cost 0

!

**************    messages below are the status change of the Channel 1 "B Channel" from the PBX and the Adtran acknowledging the change of status   ***********************

09:04:25.941 ISDN.L2_FMT PRI  1  ==============================================

09:04:25.942 ISDN.L2_FMT PRI  1  R Sapi:00 C/R:R Tei:00 INFO Ns:13  Nr:111 P:0

09:04:25.942 ISDN.L2_FMT PRI  1    Prot:43  CRL:1  CRV:0000

09:04:25.942 ISDN.L2_FMT PRI  1    M - 0F SERVICE

09:04:25.942 ISDN.L2_FMT PRI  1     IE - 01 CHANGE STATUS       Len=1

09:04:25.942 ISDN.L2_FMT PRI  1       C2

09:04:25.942 ISDN.L2_FMT PRI  1     IE - 18 CHANNEL ID          Len=3

09:04:25.942 ISDN.L2_FMT PRI  1          A9 Primary Rate

09:04:25.942 ISDN.L2_FMT PRI  1             Intfc ID:IMPLICIT

09:04:25.942 ISDN.L2_FMT PRI  1             Pref/Excl:EXCLUSIVE

09:04:25.942 ISDN.L2_FMT PRI  1             D-Chan Indicated:NO

09:04:25.943 ISDN.L2_FMT PRI  1             Chan. Sel:FOLLOWS

09:04:25.943 ISDN.L2_FMT PRI  1          83 Numb/Map:NUMBER

09:04:25.943 ISDN.L2_FMT PRI  1          81 Channel:1

09:04:25.943 ISDN.CC_MSG PRI  1  CC>>Host: 02 0000 MANAGEMENT_IND

09:04:25.943 ISDN.CC_IE  PRI  1     ie: 01 01 01 90

09:04:25.943 ISDN.CC_IE  PRI  1     ie: 01 02 06 81 82 80 82 00 00

09:04:25.943 ISDN.L2_FMT PRI  1  ==============================================

09:04:25.944 ISDN.L2_FMT PRI  1  T Sapi:00 C/R:C Tei:00 INFO Ns:111 Nr:14  P:0

09:04:25.944 ISDN.L2_FMT PRI  1    Prot:43  CRL:1  CRV:0080

09:04:25.944 ISDN.L2_FMT PRI  1    M - 07 SERVICE_ACK

09:04:25.944 ISDN.L2_FMT PRI  1     IE - 01 CHANGE STATUS       Len=1

09:04:25.944 ISDN.L2_FMT PRI  1       C2

09:04:25.944 ISDN.L2_FMT PRI  1     IE - 18 CHANNEL ID          Len=3

09:04:25.944 ISDN.L2_FMT PRI  1          A9 Primary Rate

09:04:25.944 ISDN.L2_FMT PRI  1             Intfc ID:IMPLICIT

09:04:25.944 ISDN.L2_FMT PRI  1             Pref/Excl:EXCLUSIVE

09:04:25.944 ISDN.L2_FMT PRI  1             D-Chan Indicated:NO

09:04:25.945 ISDN.L2_FMT PRI  1             Chan. Sel:FOLLOWS

09:04:25.945 ISDN.L2_FMT PRI  1          83 Numb/Map:NUMBER

09:04:25.945 ISDN.L2_FMT PRI  1          81 Channel:1

09:04:25.954 ISDN.L2_FMT PRI  1  ==============================================

*********************  debug inbound  call while PBX PRI1 B Channels are in Maintenance   ****************

*********ACCOUNT**********************#debug isdn l2-f

*********ACCOUNT**********************#debug isdn cc-messages

*********ACCOUNT**********************#debug isdn cc-ie

09:05:11.430 ISDN.CC_MSG PRI  1  CC>>Host: 02 8a5b CLEAR_IND

09:05:11.430 ISDN.CC_IE  PRI  1     ie: 00 08 04 00 00 00 A2

09:05:11.431 ISDN.CC_MSG PRI  1  Host>>CC: 02 8a5b CLEAR_RESP

09:05:11.431 ISDN.CC_IE  PRI  1     ie: 00 08 04 00 00 00 A2

09:05:11.431 ISDN.CC_MSG PRI  1  Host>>CC: 00 8a5b SETUP_REQ

09:05:11.431 ISDN.CC_IE  PRI  1     ie: 00 04 0A 80 80 80 90 00 00 00 00 00 82

09:05:11.431 ISDN.CC_IE  PRI  1     ie: 00 6C 0E 80 80 80 80 36 35 30 36 34 32 34 36 33 39

09:05:11.431 ISDN.CC_IE  PRI  1     ie: 00 70 0C 80 80 32 30 36 33 38 38 35 39 30 30

09:05:11.432 ISDN.CC_IE  PRI  1    Qie: 28 0E 57 41 56 45 20 42 52 4F 41 44 42 41 4E 44

2017.06.11 09:05:11 TM.T02 01 IsdnTmStateOutboundDeliver - rcvd unexpected CallRelease

2017.06.11 09:05:11 TM.T02 01 IsdnTmStateIdling - clear trunk appearance

09:05:17.090 ISDN.CC_MSG PRI  1  CC>>Host: 02 8a5c CLEAR_IND

09:05:17.091 ISDN.CC_IE  PRI  1     ie: 00 08 04 00 00 00 A2

09:05:17.091 ISDN.CC_MSG PRI  1  Host>>CC: 02 8a5c CLEAR_RESP

09:05:17.091 ISDN.CC_IE  PRI  1     ie: 00 08 04 00 00 00 A2

09:05:17.091 ISDN.CC_MSG PRI  1  Host>>CC: 00 8a5c SETUP_REQ

09:05:17.091 ISDN.CC_IE  PRI  1     ie: 00 04 0A 80 80 80 90 00 00 00 00 00 82

09:05:17.091 ISDN.CC_IE  PRI  1     ie: 00 6C 0E 80 80 80 80 36 35 30 36 34 32 34 36 33 39

09:05:17.092 ISDN.CC_IE  PRI  1     ie: 00 70 0C 80 80 32 30 36 33 38 38 35 39 30 30

09:05:17.092 ISDN.CC_IE  PRI  1    Qie: 28 0E 57 41 56 45 20 42 52 4F 41 44 42 41 4E 44

2017.06.11 09:05:17 TM.T02 01 IsdnTmStateOutboundDeliver - rcvd unexpected CallRelease

2017.06.11 09:05:17 TM.T02 01 IsdnTmStateIdling - clear trunk appearance

The corresponding SIP Stack is

Invite

100 Trying

486 Busy Here

[jayh]

I'm not super skilled at decoding raw ISDN messages, so this is somewhat of a guess but it looks like the PBX is accepting the call and them sending a clear signal with no cause code. It should instead send a message of no channel available, circuit busy, or similar. I think this is a problem with the ISDN signaling from the PBX when busied out and not from the Adtran.

If there is a cause code sent (and I don't immediately see one in the hex messages), then it could be mapped to something along the lines of "No circuit available" to cause the Adtran to advance to the next PRI.

Best solution is probably not to use the busy-out feature of the PBX to take the PRI out of service. Either busy it out on the Adtran or shut down the underlying T1. If you shut down the T1, check your clocking setup to avoid slips on the remaining T1.