Networking a SX2000 to a Nortel Option 11C via QSIG

[mywayray]

I'm looking for any advice on how to interconnect the Mitel SX2000 to the Nortel Option 11C-
I have confirmed that the correct hardware and software are in both switched and I looking for some direction regarding 'tandem' calls betweem them-
In the Nortel the method uses 'steering codes' to point a dialed number to a Route / Trunk Group-
Any help on setting up the DS-1, building the routing tables, etc... would be of great help

 

[MitelInMyBlood]

We tried this ourselves once and after many frustrating weeks, aborted the idea and used plain generic E & M trunking across an AMI/SF span instead. Even that is a veritible "cluster-#@*!" because if the span goes down the M1 trunks will not recover without human intervention to reset them.

While Mitel supports the full Q.Sig spec and Nortel alledgedly does also, the problem you're going to run into is that the Q.SIG specification is itself comprised of many elective/optional interpretations of the discreet elements.

The Mitel integrates via Q.SIG extremely well with many competitors' systems using either ETSI or ISO standards. Unfortunately, the Nortel Meridian isn't one of them.

 

[mywayray]

MitelInMyBlood-
Thank you for your reply-
I have successfully interconnected various PBX platforms via QSIG-
The customer requirements are such that they want to keep Name & Number intact throughout the 'network'
It's the old story of migrating two offices one with a Mitel and one with a Nortel-
I have connected Avaya and Cisco Call Manager to the Nortel but the Mitel, via QSIG, this will be a first.
If someone can provide the data fill for routing a call that arrives from PSTN on the Mitel then to a 'Tie' span, I will work through the programming of the QSIG-
Thanks

 

[MitelInMyBlood]

The Mitel works magnificently well Q.SIG-integrated to the Cisco Call Manager, to include callerID name & number, CFB/CFNA reason codes, call diversion, step-back on busy, route optomization & voice mail msg waiting.

Granted, it's been 2~3 years since we tried this between a Mitel and an Option 81C running rls 25, but this same question keeps getting asked periodically and so far no one has stepped forward to claim it will work.

 

[mywayray]

MitelInMyBlood-
Look to thread 798-1017219
QSIG Nortel to Cisco, Rolm, Siemens, Mitel
by John Poole
for Nortel config of QSIG-
John has provided screen shots of the Nortel and independently I have tested and use this config

To better describe my plight-
The Customer has a Mitel ‘Microlite SX2000’ R 44.3.9 which I’m told is equivalent to Lightware 30.
The PBX currently has one ISDN PRI to PSTN (DMS 100)
We understand that to support QSIG a second DS-1 board (even though it has 2 ports) is required
The 2nd board has been installed, also QSIG software has been added-
The sites vendor is quite sure that they can program the Mitel, & I'm quite sure I can program the Nortel-
A Call Flow--
With the PSTN connection, a call will come inbound (for this discussion lets say the is to the Main Listed Number and answered by the Console Operator)
The call is presented to the Operator where it is answered. The caller asks for an extension that happens to be on the Nortel PBX.
What I need help understanding is the routing of specific numbers in the dial plan.
If the extension range is 2000 to 3000 and extension 2525 is on the Nortel PBX what do I need to ask for, from the Mitel Engineer, in programming the routing tables to send that call to the QSIG TIE Span. Also is the Original Calling Parties information sent in the D Channel Call Setup.

Long and Short of it is The Mitel needs to become a tandem switch- the Nortel will not have any connection to PSTN other that the Mitel
Thank you for any help-

 

[MitelInMyBlood]

The Mitel will pass the CID info in the D channel setup message.

Tell the Mitel engineer what your number block(s) consist of on the M1. Hopefully it's a block of contiguous numbers on 10, 100 or 1000 number boundaries, i.e., 2500 ~ 2599 inclusive and not fragmented (except for omission). You want the Mitel to send everything in 2500 ~ 2599 to the route that they have set up for the M1. The route consists of the trunk group which is comprised of all the trunks from the QSIG span going to the M1 and may or may not require a special digit mod (likely won't), but could for call-by-call signalling. The Mitel works good as a tandem. As long as you're not going to try to do hop-off at the M1 end you can set it up to use NI2 protocol.

 

[mywayray]

MitelInMyBlood-
Again, thank you
Unfortunately the numbering plan is not consecutive
The existing office has numbers throughout the range, and the new office will pickup the unused numbers (no one wants to tell someone that they have a new number)
So the Engineer will need to route one number at a time-
Some 4 years ago I did this same task, using System Speed Dial, the took the extension 2525 & added it so then all stations could dial it. As a speed dial entry we were able to insert route access code with <E> to send the calling extension number (the span was wink). We got call completion, but this site want to retain Name & Number Display.
I was hoping that there was a cleaner way to point the numbers-
Again, thank you for your help

 

[iptuser]

I have installed Mitel Qsig to Meridian REL 25 what do you need ? We have it set up with names and extension number - works fine

There are a couple of things you need to do on both systems

On the Meridian set up the D-Channel in LD 17 as ISGF if I remember, another issue is the set up on the Route in LD16 by default the Meridian thinks it is connecting to another Meridian so sends extra digits namely the NCOS (COR)and the extension number, The Mitel will reject this and send back a Number unassigned in QSIG messaging. You need to set a prompt in LD16 I think, to STD ,I think again it is a prompt called SIGO. Also both the Meridian and Mitel needs to send OnBlock digits i.e wait until all digits have been received and then send- Meriidan it is FLEN length

How are you doing the numbering?

In the Mitel you need to set up ARS, in the Meridian you have two choices- easy and hard

Easy - You use a feature called Vacant Numbering Routing- VNR, you configure in LD15 , TYPE NET, VNR YES and assign a Route List Index. VNR works in that any number the Meridian does not recognise as on switch , it routes it via the VNR RLI in LD15. The reason for feature is that you do not have to set anything up in the meridian, any new numbers in the Mitel does no require any additional ARS/CDP in the Meridian. The downside is that you can not alternative the call to PSTN as the RLI does not allow Digit translation using VNR

Hard way - You create CDP`s depending on the numbering scheme either 2xx, 3xx etc or individual

Hope that helps

 

[mywayray]

iptuser-
Thank you for your reply-
From the Nortel side I will be using CDP to a route list index to point the calls back to the Mitel (station to station & to PSTN)
What I'm looking for is something I can pass along to the Mitel Engineer to
A) Data Fill to build the DS-1
B) Data Fill to build out the D Channel
C) Data Fill to build out the Bearer Channels
D) Data Fill to build out Routing (Trunk groups)

If screen shots were available they would go a long way in helping me provide direction to the Mitel Engineer
Thank you

 

[jneiberger]

I'm neither a Nortel or Mitel PBX guy but I do remember a couple of things from when we did some Norte/Mitel interoperability testing last year.

First, on the Nortel side, go to LD 17 and you'll find a prompt called PR_TRIGS. These are the QSIG Path Replacement triggers. You'll need to add "CTR2 2 3" in order for call transfers to trigger path replacement messages.

I also seem to recall that the Nortel trunk defaulted to enbloc sending while the Mitel was set to overlapped sending. I don't remember if that was the default, though. Regardless, things might get weird if you don't set them both to enbloc.

Also, there was a bug in the Mitel code that caused some route optimization problems. I don't recall exactly which code we were testing with but I do recall that it was pretty new as of last August/September or so. Make sure you have patches for any QSIG or route optimization issues.

That's about all I can think of at the moment. I'm not very familiar with the Nortel PBXs we have, and we ended up not selecting Mitel as a new vendor, so I don't have much experience with them either.

HTH,
John

 

[mywayray]

jneiberger-
Thank you for your reply-
We were able to tie both PBXs together-
The only outstanding issue is with QSIG Transfer-
The Operator on the Mitel receives a call and extends it to the Nortel, only the Operators extension in displayed-
There doesn't seem to be a info element in the D Channel signaling to refresh the display the original calling line ID

 

[MitelInMyBlood]

Just IMO the fact that you've gotten it to work at all says a lot. When we tried Q.sig networking between Mitel & Nortel several years ago all we ever succeeded in achieving was the callerID info (number only, never the name) and at the time it only worked one-way. The Nortel (Opt 81C) was on Rls 25 and the Nortel cust had really gotten soaked by his dealer, having spent something in excess of $25k just to get everything they said he needed to make Q.sig work. He was not happy.

What does the Nortel user see if an extension on the Mitel is set to call-forward to the Nortel in the following scenarios;
1) Call Forward Always (i.e., immediate) ?
2) Call Forward No Answer (after 2-3 rings on the Mitel)?
3) Call Forward Busy (should behave similar to #1 above)?

I think if you can get your hands on a drop & insert ISDN test set (or know how to interpret the CCS Trace data from the Mitel) that you're going to find that the CID info is being sent in the initial setup message (which the Nortel is seeing and responding to) and the call transfer info is being sent in a supplemental facility message (which the Nortel is ignoring). Therefore in scenarios 1 & 3 above you might logically expect to see the original calling party's CID and in scenario #2 see the CID of the original call destination. In this case I would be surprised if any other features of Q.Sig are working either (diversion, route optimization, MWI set/clear, etc)

Of course this is all just an attempt at diagnosing. I have not a clue how to get it to report transfers. As I said above just getting it to work at all I think you've done well.

 

[jneiberger]

What version of software is running on the Nortel?

 

[mywayray]

MitelInMyBlood & jneiberger
Thank you for your replies
To answer jneiberger's question The Nortel is running 25.40B

MitelInMyBlood-
I connected a protocol analyzer to the span & found there are 3 elements in the call setup all reporting at 0x1C-
The first is the name of the calling party, the second and third seems to be proprietary signaling (which seem to be out of place in a QSIG stack) The Nortel was able to use the correct ie but on QSIG Transfer the ie the Nortel is looking for comes in a supplemental facility message about 250 ms after the setup message again this message contains the original Calling Party Name and Line ID-
So the user experiences is the display shows the Operator Name & number and between the first and second ring the display changes to show the original Name and number
My thought is you and I are on the same page here-
The Mitel should be sending the supplemental facility message but I didn't see one in the ISDN trace I collected-
Is there a setting in the Mitel I will need to set??
If necessary I can post the trace-

 

[MitelInMyBlood]

Gauwd, I'm not even sure that works between our 3300 and the Cisco call manager and I thought we had those two dancing together nicely. If I think of it Monday when I go in I'll try it. Monday's probably going to be hectic tho as we upgraded 4 SX2K machines to LW34 this afternoon and lost most of the user-programmed settings in the data restore. I almost hate to go in Monday.

 

[MitelInMyBlood]

Since you have a protocol analizer in the span and can watch the D-channel data flow, try also enabling CCS trace on the Mitel and see if that tells you anything. The command you'll need on the Mitel is: CCS TR EN CO (ccs trace enable continuous).

Now set the call up again, perform the transfer and watch to see what the CCS trace is sending and whether you're seeing any corresponding data on the analyzer.

CCS Trace is a fairly cryptic dump and will not be in the same data format as the D-channel message. I'm merely wanting to see if anything at all is being sent. I'm sure you'll see it in the CCS trace dump, just not so sure of what you'll see at the same time on the D-channel.

The command to turn off CCS tracing is: CCS TR D (ccs trace disable)

You can find a little CCS Trace documentation in the 3300 Help file. Somewhere around here I also have the CCS Trace Training documentation from a course Larry Arnold (Mitel) gave back in 1999.

By the way, just out of curiosity, what does a Mitel user see if you reverse the scenario by transferring a caller on the M1 back to the Mitel?

 

[MitelInMyBlood]

UPDATE

OK, I was able to test supervised transfer of external calls answered on the Mitel but then manually transferred to a QSIG-integrated Cisco Call Manager this morning.

IT WORKS. The party on the Cisco 1st sees the name & number of the transferring party, then when the transfer occurs (transferring party releases the call) the downstream party on the Cisco sees both name & number of the transferred (original) party.

Based on this I would look at the Meridian as being the non-conforming component (which comes as no surprise).

 

[MitelInMyBlood]

I just thought of something. You might need to be running ISDN rls 7 (enhanced QSIG) - we are...

 

[mywayray]

MitelInMyBlood-
Thank you for all your help-
I'll be back on site next week-
Operator transfer from the Mitel to the Nortel station was my issue- Station to Station both ways seems to be OK-
I'll have the Mitel Eng run the Mitel trace utility also mention the enhanced QSIG question-
I'll post my findings

 

[mywayray]

MitelInMyBlood-
It would seem that over the weekend the enhanced QSIG package was installed-
Now not only does the Nortel folks see the original ANI when the call is extended by the Operator or Auto Attendant but the Mitel stations receive a refresh of the ANI on Alert - prior to this the refresh came on connect-

Thank you for all your help-