Interalia MMU-2 as AWU

[jimbobebob]

Well, I thought I knew as much as the others on this forum about Interalia MMU-2 recorders (and have found some good tips as well), but I need help on this one...using it with an Option 61 as an AWU on port 1, and RAN on ports 2 and 3.

I installed this unit to replace an aged Cook Digital Announcer that got fried...so tried to keep the RDB and AWU trunks setup the same, and wired them to the Interalia. The RAN trunks seem to be OK (which is to say they respond to LD 36 Trunk testing, but the AWU is not behaving well. I've had about 3 scenarios of working/not working:
Set as AWU, I was able to dial the ACOD for Rt 10 (8010) and heard MSG 1; but was not able to dial the ACOD from Rt 11 RAN (8011) or Rt 12 RAN (8012). The TARG and TGAR do not conflict, so that's not it. I'm suspecting I may not have a good ground connection, so was tinkering with that today.

In the LD 36 Trunk testing, was getting ERR110 when testing the AWU trunks, but not the RAN. ERR110 says to check the trunk database. Looking into it, I noticed the AWU_Data referenced RANF (defined as the Music On Hold Route!?!) to be Rt 14 (which is setup as an AWU in the PBX but has no trunks wired to it.?.) and the RANR as Rt 10. So I deleted/rebuilt Rt 10 as a RAN route, instead of AWU route, and then I could use LD 36 Trunk testing to access all...Rt 10, 11, and 12, and heard audio from each. All fine and good, right? But now I can no longer dial the ACOD from ANY of the 3 Routes! Not sure if I should be concerned or not...anyone know?

Well, my last symptom is, the AWU functionality 'sort of' works..i.e., when I set a Wake-Up call, it rings the phone at the appropriate time, but never plays the MSG.

So questions-
What is the purpose of the RANF setting in the CDB/AWU_Data, and if it needs to be Rt 14 in my case, shouldn't there be something wired to it? I knew nothing of the wiring/programming of the former Cook Digital Announcers, so don't know if it was supposed to be wired or not. In looking through the LD 15 and LD 16 NTP's, it showed not only the RANF setting, but also indicated there should have been a prompt for 'Conf' loop, but I did not see one when programming...

More background- when I had Rt 10 setup as AWU I noticed that every time I dialed the ACOD of the Rt 10 AWU route, both the sole TN of the Trunk assigned to Rt 14 AWU and 1 TN (of the 4) of the Rt 10 AWU simultaneously went active. Is the RANF route supposed to be 'virtual only' and meant to go active the same time the 'real' RAN route trunk is active? Or should it be wired in common with the trunks of the RAN route, and perhaps without that wiring, that's why I'm not hearing the MSG?

Thanks

 

[StanleySteamer]

I'm not clear what you've got at the moment but it could be that you have a very long message recorded for the wakeup message. The system always plays the message from the beginning. RANF is usually a music source that plays until the Interalia gets around to the beginning of the actual wakeup RAN. If RANF is configured but is not working then you may be getting silence.
So the "intermittent" problem with the wakeup recording may just be that it is occurring just after the recording has started to play and you are getting silence until the playback starts again.
Just a thought.

 

[jimbobebob]

Thanks Stanley,
I did not know that about the RANF, what its true purpose was...as I say, it's currently wired to nothing, so even though my Wakeup message is only 7 seconds long, it may have hit it during the middle of the message, and is routing me to the RANF (which in my case is silence) waiting for the wrap-around. I tried to answer the Wakeup call, and leave it off-hook during the silence, to see if anything played, but never did hear anything play...and I bet I waited 20~30 seconds, so you'd think that would be enough time for the RANF to keep me in suspense, while the MSG started again.
Just checking- should I indeed have the Interalia ports set to C (continuous) play, as the Interalia book suggests (Nortel mode 1), or have them level start/level stop (as in Nortel mode 2)? Most posts here indicate Continuous, but again, most posts are about RAN routes, rather than AWU routes...any thoughts?
Also can you (or anyone) confirm that my AWU MSG route should actually be configured as a RAN route/trunks, vs AWU route/trunks? Seems like it shouldn't take this much effort.?.

 

[jimbobebob]

**RESOLVED** (I think)

Couple of things- I wired the RANF (Rt 14) trunk to the same connections as the associated Interalia RAN trunks, and now when I test a Wakeup call, it plays the 'wakeup' MSG (which, technically, plays the whole time, as it's in Continuous play mode, and wired to the Interalia ports). Either way, when I get a AWU call, it now plays the MSG!

Second thing- I flipped the CP and MB leads of the trunks wired to the Interalia; it's confusing, because the Interalia wiring chart for Nortel (option 1) shows connections for all 4 leads, yet the Notes tell you NOT to connect the MB lead! I did verify that, as long as it has the audio pair on T/R and the GND wired, it behaves the same with/without the MB connection...it just happens to still be connected in mine, and works, so I tiptoed away and left it as is! After a month of tinkering, I'm just glad it works for AWU. When I get a chance, I'll stop by and take a picture of the wiring, to remind myself, and in case anyone asks.

Technically, I still can't dial the Route ACOD's and access the trunks- getting fast busy...but LD 36 Trunk testing works every time now on the Wakeup Route, and the other 2 RAN Routes.

 

[KE407122]

Unable to Dial a Trunk Route ACOD is probably related more to NCOS of the set you're dialing from.

I used to use CP on Interalia MMU. Click click click click everytime each MSG plays and calls held until the CP allows trunk to access the start of the message.

When I upgraded to an XMU+. I decided to use a different integration. PS LR NO (Pulse Start, Level Return, Normally Open) on MSG1-MSG6. MSG 7 was left as CP (Used as Music on Hold)

PS LR NO required a minimum 20 VDC source (We had 48 VDC available too.) to trip the pulse-(msg) when needed. It also required changes to strap options on the Trunk Card for each RAN port.

On an OPT 61 after changing the strap options everything came up fine, however the OPT 11 needed an INI for the strap options to take.

KE407122

"The phone was working fine before it knocked over my coffee.

 

[KE407122]

Sorry, TGAR left as 1 in LD 11 (default) would deny ACOD dial.

TGAR 0-(1)-31 Trunk Group Access Restriction. The default of
(1) automatically blocks direct access.



KE407122

"The phone was working fine before it knocked over my coffee.

 

[jimbobebob]

Thanks for the tips, KE407122

I remember installing an XMU for a large bank customer- that's a sweet product!

My test phone was originally TGAR 0, but along the way in testing, I had changed it...I'll change it back next time I'm onsite.

Good to know there's 'someone' else in the world that's done this before- too often one feels like it's 'me against the world'!

 

[KE407122]

Hey. I'll give Interalia credit for listening. Mind you their RMA process is a pain. You return a defective product with a blank Purchase Order...Sort of like writing a blank cheque. In our budget environment it doesn't cut it in an audit. I won't issue blank PO's.
The original integration documentation was a little unclear. (Which explains why everyone just used CP even on the MMU.) After we got it working, I supplied them with some supplementary documentation and they modified their installation guide.



KE407122

"The phone was working fine before it knocked over my coffee.

 

[jimbobebob]

Hey, can I drum up this thread again? The Interalia has been working fine now for a couple months...now the report is that the AWU's are not working.

I went on site, and found much the same- I can still use the Mtce phone and LD 36, access the trunks of the RAN, and hear the message; however, when I set a WA call, upon delivery time, it shows 'SYSTEM BLOCKED' and AWU RETURN (I think was the verbiage)

They informed me they DID have a power blip overnight, but I checked the AWU route and in CDB, and all is enabled... I DSBL, pulled out and reseated the UNIV TRK card for the AWU, and re-enabled, and did an INIT on the Interalia.

Can't think why else AWU would fail, and show 'SYSTEM BLOCKED'? Getting ready to go in tonight, and 'poke it in the eye' (INI) to see if that resolves it.

Any other ideas?

 

[KCFLHRC]

I have seen this in the past when the link to the Property Management System is down, it wouldn't allow AWU calls to work.

 

[jimbobebob]

The PMS link seems to be up, and they haven't complained about not being able to log guests in or out.

I looked up SYST BLKD in the BKG NTP (EIEIO!) and the description says, in essence, 'failed due to blocking in the system'...which tells me nothing! Especially on a 'non-blocking' Opt61C!

I went through LD 30 and LD 32 and as far as I can see, everything else on the PBX is 'up', so don't know where the 'blocking' is coming from!?!