Option 11 -> Asterisk: Looking for PRI cause codes 2

[EvilJ]

I'm looking for some help with a problem I'm experiencing linking an Option 11 with an Asterisk system. We currently have PRI service over a T1 with DID supplied by AT&T connecting our Nortel to the PSTN. The switch in the CO is a DMS100.

We are trying to insert an Asterisk-based system between the CO and the Nortel to do some IVR/VM/SIP stuff with. The Asterisk box has a dual-T1 interface in it. I setup all the configs on the Asterisk box so that port 0 would take the timing from the CO, emulate a DMS100, and act like the CPE in the link. Port 1 on that card then provides timing to it's link, emulates a DMS100 and acts like the NET side of the link.

Over the weekend, I disconnected the smartjack from the CSU and inserted the Asterisk system between. The T1 to the CO came up like a charm and I could route calls both directions from the Asterisk box and the PSTN.

The link between the Asterisk box and the Nortel also came up with no errors but when I try to route calls over the link, they are failing. When I try to route from the Nortel to the Asterisk box, I get a cause code of 100 on the Asterisk side and a debug message on the Nortel. When I try to call from the Asterisk side to the Nortel, I get a cause code of 54.

Calls coming from the CO arrive as a 4-digit DID. I sent the same 4-digit DID to the Nortel and it didn't work. I also tried 7-digit and 10-digit formats with no luck.

Has anybody seen these types of errors before? My gut tells me it is a Nortel thing because of the success getting calls (with the same basic config) in and out of the PSTN.

Any suggestions would be a big help.

Thanks!
Jason

 

[cscsupport]

are you using the same protocol for the meridian side, off of the asterisk system

 

[EvilJ]

Yes.

In the Nortel, the D-channel is setup as DCH 10. Dumping the ADAN gives me:

ADAN DCH 10
CTYP DCHI
CARD 02
PORT 1
DES DCH10
USR PRI
DCHL 2
OTBF 32
DRAT 64KC
CLOK EXT
IFC D100
SIDE USR
CNEG 1
RLS ID **
RCAP
MBGA NO
OVLR NO
OVLS NO
T23 20
T200 3
T203 10
N200 3
N201 260
K 7

In Asterisk I have the two spans defined as:

# Span 2: R2T1/0/1 "R2T1 (PCI) Card 0 Span 1"
# This is the span from the CO to Asterisk
# It accepts timing from the span, LBO is 0, esf, b8zs
span=2,1,0,esf,b8zs
bchan=1-23
dchan=24

# Span 3: R2T1/0/2 "R2T1 (PCI) Card 0 Span 2"
# This is the span from Asterisk to the Nortel
# It provides timing to the span, LBO is 0, esf, b8zs
span=3,0,0,esf,b8zs
bchan=25-47
dchan=48


The logical definitions in Asterisk are:

; Span 2: R2T1/0/1 "R2T1 (PCI) Card 0 Span 1"
group=0
context=from-trunk
switchtype = dms100
signalling = pri_cpe
channel => 1-23

; Span 3: R2T1/0/2 "R2T1 (PCI) Card 0 Span 2"
group=1
context=from-trunk
switchtype = dms100
signalling = pri_net
channel => 25-47


The odd thing is that the Nortel has been talking to the CO over this link for years with no problems at all. I insert Asterisk into the line and if it is configured correctly, neither end should know that anything has changed. The CO, in fact, continues to work just fine and pass information to the Asterisk system. It is the Nortel that is suddenly upset. I would think that if something was wrong with the Asterisk configuration, that both ends would fail.

 

[drifter56]

On span 3 from the Asterisk to the Nortel it appears the channels are setup as 25 to 47. I am unsure if this is just logical or not but if you only have the one PRI between them I would think the channels in the Nortel would be 1 to 23. This would definately stop the calls from being processed between them as the setup message would contain an interface id and channel number that the other end would not recognize.

 

[EvilJ]

drifter56;

Thanks for the question. I didn't know the answer and it got me thinking. So I did some digging... It turns out that it is indeed just a logical association. Further up the chain there is a link between channel numbers and 'groups' which allow for hunting/roll-over. The lower-level drivers take care of the specifics for each span and map the high-level channel numbers to the low-level implementation.

So, the word from the card manufacturer is that no, the configuration is correct.

On a side note, they informally polled all the engineers around their office and the consensus is that something is wrong in the Nortel config. (I think that is because they reviewed their part of it and nothing was wrong so it must be the other end) I'm not 100% sure I buy this but I still think it might be true. I just don't know where to look in the Nortel to figure it out.

 

[drifter56]

EvilJ;

While I can certainly understand the card manufacturers response, it seems to me that if you have a working circuit, then insert something between the two working pieces of equipment that is suppose to be passive and make to no changes to the original two pieces of equipment, the issue would most likely be with the new device.
Now with that said, not sure if this will help you but here is what I have for your cause codes: 100 - Invalid Information Element contents ( This cause indicates that the equipment sending this cause has received an information element which it has implemented: however, one or more of the fields in the information element are coded in such a way which has not been implemented by the equipment sending this cause)
54 - Incoming calls barred (This cause indicates that the called user will not accept the call delivered in the SETUP message)
Maybe turning on the d channel messages in the PBX will give you a clue, at least is will confim if the PBX thinks the channels are correct or not.

 

[KrisBoutilier]

EvilJ;

Most likely the Asterisk side implementation of DMS100 is incomplete vis-a-vis the expectations of the Option 11. I suspect the Opt11 is both very strict and expects IEs that haven't been implemented yet in libpri.

I have successfully used the following two signalling configs with Asterisk and Nortel hardware:

GTD5 -(NI2)-> Asterisk -(DMS100)-> Norstar

and

GTD5 -(NI2)-> Asterisk -(NI2)-> CS1000

For example, right now the CS1000 is emitting the OSA IE when it outdials operator calls and that's one of those IEs that Asterisk doesn't implement (see

http://bugs.digium.com/view.php?id=9058)

If you want to get to the bottom of this you will likely need to bend Asterisk to fit. 'pri debug span 3' in the Asterisk console will give you a running dump of the D-channel messages with full payload decoding (where the IE has been implemented). Likely you can pair that off against the dumps from the Option 11 side and find out where it's unhappy (though decoding the Option 11 dumps is an art in itself). Also note not _all_ missing or unimplemented IEs are unnecessarily fatal...

You can get additional support from #asterisk on irc.freenode.net or via the mailing lists (see

http://www.asteriskpbx.org/support).

Beware you may have to be patient if you're using the no-cost support options as there don't seem to be too many people with this level of hardware laying around to test/debug interfacing...

Hope that helps.
Kris Boutilier

 

[EvilJ]

KrisBoutilier;

Wow! Thanks for the great post. It gave me some good info.

I actually posted this to Asterisk-users yesterday but haven't received any good hits on it yet. One guy suggested I change the switchtype in Asterisk to National to see if that would fix it. I'm certain that it would (and I think your experience confirms that as well) but I'm not very anxious to change the switchtype in the Nortel just yet. I would like to avoid being forced to out a DCH just so I can change the IFC setting. (If someone knows a way to quickly change the IFC for a DCH without totally out'ing all the routes and b-channels I would forever owe them!)

I ran a call with debug turned on for span 3. Here is the dump minus the Asterisk dialplan stuff (so it's just the PRI debug). You seem to have a lot of experience with type of issue... could you look through this trace and see if you think it is the same kind of thing?

Also, some others have suggested in other posts troubleshooting similar issues that service messages be turned on. Ours are currently disabled (ld 96 - stat serv). Do you think that would make a difference?

Thanks!
Jason

< Protocol Discriminator: Q.931 (8) len=39
< Call Ref: len= 1 (reference 3/0x3) (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 04 e9 80 83 03]
< Channel ID (len= 6) [ Ext: 1 IntID: Explicit PRI Spare: 0 Exclusive Dchan: 0
< ChanSel: Reserved
< Ext: 1 DS1 Identifier: 0
< Ext: 1 Coding: 0 Number Specified Channel Type: 3
< Ext: 0 Channel: 3 ]
< [6c 0c 21 80 36 31 34 38 38 38 32 33 34 34]
< Calling Number (len=14) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
< Presentation: Presentation permitted, user number not screened (0) 'xxxxxx2344' ]
< [70 08 a1 33 33 32 39 31 37 37]
< Called Number (len=10) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) 'xxx9177' ]

-- Making new call for cr 3
-- Processing Q.931 Call Setup
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 108 (cs0, Calling Party Number)
-- Processing IE 112 (cs0, Called Party Number)
q931.c:3298 q931_receive: call 3 on channel 3 enters state 6 (Call Present)
q931.c:2571 q931_call_proceeding: call 3 on channel 3 enters state 9 (Incoming Call Proceeding)

> Protocol Discriminator: Q.931 (8) len=10
> Call Ref: len= 2 (reference 3/0x3) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 03 a9 83 83]
> 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: 3 ]

q931.c:2698 q931_connect: call 3 on channel 3 enters state 10 (Active)

> Protocol Discriminator: Q.931 (8) len=10
> Call Ref: len= 2 (reference 3/0x3) (Terminator)
> Message type: CONNECT (7)
> [18 03 a9 83 83]
> 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: 3 ]

< Protocol Discriminator: Q.931 (8) len=8
< Call Ref: len= 1 (reference 3/0x3) (Originator)
< Message type: RELEASE (77)
< [08 02 81 e4]
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
< Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ]

-- Processing IE 8 (cs0, Cause)
q931.c:3538 q931_receive: call 3 on channel 3 enters state 0 (Null)

NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request

> Protocol Discriminator: Q.931 (8) len=9
> Call Ref: len= 2 (reference 3/0x3) (Terminator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
> Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]

NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null

< Protocol Discriminator: Q.931 (8) len=8
< Call Ref: len= 1 (reference 3/0x3) (Originator)
< Message type: RELEASE (77)
< [08 02 81 e4]
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
< Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ]

-- Making new call for cr 3
-- Processing IE 8 (cs0, Cause)

> Protocol Discriminator: Q.931 (8) len=9
> Call Ref: len= 2 (reference 3/0x3) (Terminator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 d1]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
> Ext: 1 Cause: Invalid call reference value (81), class = Invalid message (e.g. parameter out of range) (5) ]

NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
-- Hungup 'Zap/27-1'

 

[KrisBoutilier]

EvilJ;

Its been a while since I've looked at this stuff, but the following may help:

- The < and > at the beginning of each line indicate if the traffic being decoded is going in or out of the machine.

- Each decode includes the underlying hex payload between [ ], followed by the interpretation provided by libpri. If I recall the 'service messages' will provide you the same hex dump, but without any interpretation.

So, the flow messages go something like:

< Message type: SETUP (5)
{hello? can you set this up for me?}

> Message type: CALL PROCEEDING (2)
{all good, just putting you through now sir}

> Message type: CONNECT (7)
> [18 03 a9 83 83]
> 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: 3 ]
{everything is ready sir, your audio is on channel: 3, please meet your party there...}

< Message type: RELEASE (77)
< [08 02 81 e4]
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
< Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ]
{aaaahhh! I don't understand something about where you want me to meet them or how we're supposed to converse! Go away!}

> Message type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
> Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
{righty-ho sir, the call is over}

< Message type: RELEASE (77)
< [08 02 81 e4]
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
< Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ]
{aaaahhh! now I'm really confused! what did you just say? Go away!}

> Message type: RELEASE COMPLETE (90)
> [08 02 81 d1]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
> Ext: 1 Cause: Invalid call reference value (81), class = Invalid message (e.g. parameter out of range) (5) ]
{sir, you're confusing me. Bugger off.}

... or something like that. A wild stab in the dark? The way the payload is set up in the CONNECT message isn't consistent with the way libpri expects it (Cause: Invalid information element contents). Followed by the libpri state machine expecting a different D channel message to come in after the RELEASE, before the RELEASE COMPLETE, which makes it throw another RELEASE, which makes the Option 11 state machine go all wobbly and throw the RELEASE COMPLETE with 'Cause: Invalid call reference value (81)' set.

When you look up the Option 11 debug message it will probably be related to the duplicate RELEASE message. If you don't have that manual try looking in the latest release of document 553-3001-411 (

http://www142.nortelnetworks.com/techdocs/R4_5/pdf/553-3001-411_19.00_SIOSysMgs.pdf)

Even though it's for the latest release the message most likely has the same definition.

I suggest you try national... if you work out a way to do it quickly and easily without out-ing everything I'd love to know!

Hope that helps.

 

[PJA]

I have exactly the same issue...& have put a lot of hours into trying to fix it...

Any advice would be extremly welcome.

If you paid someone to fix it - can I please ask for the contact details for that person or company...


Regards

Paul Adams

 

[EvilJ]

Paul,

We ended up solving it by getting AT&T to change our PRI from DMS100 to National. Once we did that everything worked fine.

It was a trade-off... I would have rather left the DMS100 switchtype in place but I had a deadline to get the system commissioned so I swallowed the pill and called ATT.

If you want more details, shoot a message to me at tempmail[at]gleim.name and post back to this thread. In the message give me your contact info and I'll get a hold of you from my real e-mail account.

Jason

 

[PJA]

Yes - the pressure's increasing here too...

I sent you the e-mail with my details in...


Thanks

Paul

 

[PJA]

Update.

Got a qualified Nortel tech in today. Changed the Nortel PRI programming from DMS100 to NI2.

Also - changed Asterisk to NI2 (called National in Asterisk - old National is called ni1)

Worked first time.

It took 1 hour of the tech's time...


Regards

Paul Adams