NEC 2000 IPS - B channel issues

[clecman]

Different angle here - I am tech for carrier with softswitch running two ISDN PRIs to a customer site - both running NI-2 with variant of Telcordia National ISDN 2 (if anyone cares).

Running into issues where B channels stop communicating.
No T1 issues...not seeing D channel issues...not all calls drop at same time.

Basically, the channel stops responding, possibly after a Rel with cause code of 127.
I saw a similar post on dialogic web-page - is the nec 2000 IPS the same? Or share with dialogic?

http://www.dialogic.com/forums/forums/thread-view.asp?posts=40&tid=343

Customer has remote buildings connected by IP (all I know and not obtaining more unfortunately).

We see B channel flow as this:
>> Q.931: Setup 3527 (from orig) --- from carrier
<< Q.931: Call Proceeding 3527 (to orig) --- from nec
<< Q.931: Alerting 3527 (to orig) --- from NEC - ringing
<< Q.931: Connect 3527 (to orig) --- answer
>> Q.931: Connect Acknowledge 3527 (from orig) - answer ack
Putting the disconnect in due to cause being network unspecified 127 - think that this may be the issue.
ISDN >> Q.931: Disconnect 3527 (from orig)
ISDN Cause: Standard 00, Location 0A, Cause 127
ISDN 08023527 4508028A FF ..5'E....
>> Q.931: Release 3527 (from orig)
>> Q.931: Release 3527 (from orig)
>> Q.931: Restart 0000

At this point, the PBX stops acking any disconnected call and has issues calling out as well even though NEC tech sees channels as idle.

Any help would be appreciated.

 

[rotters]

The posting you show indicates on a mismatch of protocols from the dialogic to NI2. If you have NI2 programmed on the NEC as well as the telco, there is no mismatch here.

You say that you have a Telecordia variant of NI2. I don't know what that means but if it is not standard NI2 then maybe that is causing the protocol mismatch.

 

[clecman]

Thanks for the response.

I would agree with some type of mismatch. As for the variant, I included that as some vendors ask for that - could be DMS-100, 5E....

We have run NI-2, 5E, DMS-100 - and this happens with each and every ISDN setting used. We just stop fully communicating.

We do continue to recive and transmit call setups, but channels are never released properly.

The PBX does connect to several other buildings - I think they may be using QSig here, but not sure.

Just hoping that somebody has seen something similar as I run through the traces.

Another hurdle is the NEC only has Q.921 debug while we have Q.931...trying to figure out exactly what all of their debug means and how it may correlate.

27'00 o>04:30-08-15-04-50-51-58-59-FF/
27'00 o>04:30-85-15-01-10-FF/
27'00 o>04:30-08-15-04-50-51-58-59-FF/
27'05 I<04:7D-89-00-42-14-01-02-66-00-FF/
27'05 o>04:30-08-14-04-50-51-58-59-FF/
27'05 o>04:30-85-14-01-10-FF/
27'05 o>04:30-08-14-04-50-51-58-59-FF/

Thanks again.

 

[clecman]

One other thing to note that I just discovered.

When this problem arose last week, the catalyst to one of the PRI's lack of response was a hairpin call.
Number from one site called number on another site, but both numbers exist on the same pbx.

Called number (terminated on pri2) disconnected first and released normally. The calling number on pri1 receives the disconnect, but does not ack it. We then send restart message.

Does NEC have any issues with a hairpin call?
Is it acceptable to call a DID on a carrier PRI when that DID actually terminates on the PBX - that orignated the call?

again, thanks for any input

 

[kid2400]

YOu stated the NEC is connected to other buildings...are their other 2000's at these locations?, are the calls causing these issus from extensions from those other sites? If it is a NEC networked configuration (CCIS)then the calls should terminate and give you the correct messages. If not and it's Qsig then good luck, NEC supports Qsig but in limited forms...
You could as the last poster stated try normal flavor of NI2