We are currently working on integration to a 3rd party PBX. The connection is via an ISDN PRI 'TIE' line utilizing NI2. We are the Network side and they are the User. The issue is our option 11 is utilizing Call-by-call routing. We have configured a TIE service route and the D-Channel is stable, we can 4- digit dial an extension on the other switch, we can assign a DID and pass this call directly though. However a problem arises when the other switch attempts to initiate a call to one of the Nortel extensions or through us to the CO. We disconnect the call every time with an ISDN Cause Code 16. We believe it is because we do not receive an NSF code from the other switch but can not be sure. This switch is unable to provide us with an NSF code either. Has anyone ever experienced this? If yes, what is the recommended work around?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Option 11C - CBC routing
- Thread starter Keithmd
- Start date
NI2 is not anything I know about..
maybe we call it something elsa here.
But have you traced the d-channel and seen that you are getting extensionnumbers or number that you have treatments for?
If you should reach an outside line you also has to have a treatment for that.
If the destination of the call isnt known by the receiving end, I can imagine it could be problems like this.
maybe we call it something elsa here.
But have you traced the d-channel and seen that you are getting extensionnumbers or number that you have treatments for?
If you should reach an outside line you also has to have a treatment for that.
If the destination of the call isnt known by the receiving end, I can imagine it could be problems like this.
- Thread starter
- #4
Thanks for the responses, NI2 is a ISDN protocol, it can also be used for switch to switch communications. Our switch is acting as the CO, in this case. We have eliminated the NSF coding as an issue, however we still cannot dial through the Option 11 to the CO, we can dial any extension on either switch, but the Option 11 will not recognize more that 4 digits although it does receive all 10. This one has us stumped. Any additional thoughts would be greatly appreciated.
Could be a barring issue on the meridian.
Is trunk to trunk calling allowed? I think the prompt is in the RDB's TRMB? (tromboning i think)
Is there any idc on the inbound route (inbound to m1)
not sure what else but perhaps a ncos issue?
Hope this helps.. I had a eic i3 server hanging off of a m1 and had similar issues..
"It's not getting any smarter out there. You have to come to terms with stupidity, and make it work for you."
Is trunk to trunk calling allowed? I think the prompt is in the RDB's TRMB? (tromboning i think)
Is there any idc on the inbound route (inbound to m1)
not sure what else but perhaps a ncos issue?
Hope this helps.. I had a eic i3 server hanging off of a m1 and had similar issues..
"It's not getting any smarter out there. You have to come to terms with stupidity, and make it work for you."
- Thread starter
- #6
Are you in the UK/europe?
I used the following protocols
On the I3 end ets300 "b" end and on the m1 I think it was a qsig.
I also remember that there was a issue with the I3 dial plan
We had to treat the dialstring differently if we were dialling the CO directly or via our M1.
Put a trace on the tieline and look at what you're getting into the m1. is the aculab/dialogic board adding a prefix?
Let us know how you get on
Mike
"It's not getting any smarter out there. You have to come to terms with stupidity, and make it work for you."
I used the following protocols
On the I3 end ets300 "b" end and on the m1 I think it was a qsig.
I also remember that there was a issue with the I3 dial plan
We had to treat the dialstring differently if we were dialling the CO directly or via our M1.
Put a trace on the tieline and look at what you're getting into the m1. is the aculab/dialogic board adding a prefix?
Let us know how you get on
Mike
"It's not getting any smarter out there. You have to come to terms with stupidity, and make it work for you."
- Thread starter
- #8
- Thread starter
- #12
We worked wit the local Nortel Reseller, they escalated and Nortel stepped up to the plate. As for Joy......tons. The issue was with the CBCR module, Nortel had to dial in and disable it, and then we loaded our Route, tested everything. Nortel dialed back in and re-activated the CBCR module our route persisted. We even did a complete power cycle on the Option 11 and we are still up.
As for you previous question on CIC, It has been great. Not too many issues at all.
As for you previous question on CIC, It has been great. Not too many issues at all.
- Status
Similar threads
- Locked
- Question
- Locked
- Question