Random ACD's

[dkluth]

Hey Guys,

So I am cleaning up our Option 11 that was upgraded to a CS1000 running Succession 4.5. I found about 20 ACD's that look like this:
TYPE ACD
CUST 0
ACDN 2124
MWC NO
DSAC NO
MAXP 1
SDNB NO
BSCW NO
ISAP NO
AACQ NO
RGAI NO
ACAA NO
FRRT
SRRT
NRRT
FROA NO
CALP POS
ICDD NO
NCFW 7000
FNCF NO
FORC NO
RTQT 0
SPCP NO
OBTN NO
RAO NO
CWTH 1
NCWL NO
BYTH 0
OVTH 2047
TOFT NONE
HPQ NO
OCN NO
OVDN
IFDN
OVBU LNK LNK LNK LNK
EMRT
MURT
RTPC NO
STIO
TSFT 20
HOML YES
RDNA NO
LABEL_KEY0 NO
NRAC NO
DAL NO
RPRT YES
RAGT 4
DURT 30
RSND 4
FCTH 20
CRQS 100
IVR NO
OBSC NO
OBPT 0
CWNT NONE

Any idea if what these could be used for before I go delete them all?

Thanks,

Doug

 

[bigindian65]

They are being used to forward, hence the MAXP1, and NCFW XXXX, instead of using LD 49 DNIS, or phantoms.

 

[bigindian65]

When someone calls 2124, they are getting 7000.

 

[jamie2]

Is 7000 your voice mail DN? They are probably old Guest Mailboxes? Just an idea.

If they are, you can keep them or make them into phantoms.

 

[EddieDuece]

Figure out what 7000 is and you'll have your answer.

 

[dkluth]

Thanks Guys. I should have let you know 7000 is VM. I figured that's what they were but I wanted to make sure the system wouldn't be using them for anything.

Doug

 

[BikeTours]

I work for an application services developer whose product runs on a server supporting a telephony board. Typically we are requested to connect our server to a customer PBX across a T1 circuit; we can use either PRI or T1 robbed-bit. Needless to say I research a variety of different PBXs to figure out how best to do so.

With one of our customers I ran into this use of an ACD queue to forward traffic to the T1 trunk connecting to our server. Our server was connected to the Option 11C using a T1 robbed bit circuit. All the calls into our server were from internal extensions.

For whatever reason the customer's PBX technician used this method of setting up an ACD queue and then forwarding it permanently to night-service with the forwarding endpoint being our trunk.

From this series of questions it seems like other deployments use this same option.

I never fully understood why one would want to use this ACD queue/forward strategy as opposed to setting up something like a steering code solution.

Perhaps it is because of my assumption as to what an ACD queue is used for. My perception is you use it so that external calls coming into the PBX can be forwarded to a group of agents. In this context it seemed like the ACD queue was acting as an automatic route selection; the user dials a number and it routes to a trunk interface.

Question: Can anyone comment on Nortel's use of the ACD queue? Do they use it for basic dial plan support - the user dials a number - the ACD queue tables provides the required match and the call is forwarded - so it is acting like a basic automatic route selection table.

question: If they could it seems that it would be far simpler to have the extensions simply dial the trunk access code to seize our trunk. Is this ACD queue configuration provide additional features like forwarding of called and calling number that simply dialing a trunk access code might not have?

 

[bigindian65]

Typically no one replys to "piggy-back" threads that pose new questions.

ACD NCFW is simple, easy to manage, takes up ONE dnb of DID or non-DID. Is usefully for digit conversion without 86,87,49. SAVEs numbering plan. Why smoke say, 23xx for a DSC, LSC, losing 100 block of numbers when you can 23xx ONE number and accomplish forwarding to another number, Toll-free, helpdesk etc.

 

[BikeTours]

In the implementation that our customer provided the ACD queue pointed to a robbed bit trunk. I assume that we could equally as well have used a PRI trunk interface by optioning the route data block for a PRI interface, instead of DTI and then doing the balance of the configuration required of a PRI trunk.

Question: Would that assumption be correct?

 

[johnpoole]

yes that assunption is correct.. i perfer qsig for that setup.. nortel from the 1st day of mermail used maxp 1 acd for redirect.. and usually i use it for internal redirects where a dsc/acod will not work

john poole
bellsouth business
columbia,sc

 

[BikeTours]

I walked into this Nortel implementation two or three days after I started with my company so I didn't have much opportunity to look into this to any great degree. Our customer actually contracts their PBX support off to another company, and unfortunately I had no opportunity to interact with them. They simply came in and implemented the night forwarded ACD solution on a robbed bit trunk. I seems from the responses that I have gotten from this Tek-Tips board that this ACD solution is a fairly common implementation.

Post installation I also looked into issue around using a PRI trunk to connect our server to the Option 11C

The telephony boards we use run in ISDN User-side mode. We have to get Network side from the PBX. I got contradictory information from various sources in regards to optioning the Option 11C for ISDN network side and I am wondering what is the reality in this regard.

Our board manufacturer suggests that when optioned Network side the Nortel PBXs can only support a SL1 ISDN protocol type, a proprietary Nortel standard that their telephony board does not support. Apparently if optioned ISDN-User side you have more ISDN protocol definitions available including ISDN DMS-100 which the telephony board supports. You therefore have two options: go with robbed bit or only run ISDN user from the PBX.

I don't know if that is true across the whole Option 11C firmware releases, or in the most recent firmware releases this restriction was removed. For example, the board manufacturer suggested, although they could not confirm this point, that Nortel has a QSIG firmware load, that in addition to implementing QSIG on the system this firmware load allows you to option the PRI interfaces on the PBX to ISDN-Network and still use a standard protocol definition.

What is the Nortel Option 11 story on this?