Kalahary-Harry

You don't say if you want to report on every thing in Symposium. If you do, then you need to write the scripts for it and handle the call from A - Z in Symposium.

If you just want to report on the calls that used your internal CDN, but NOT on the calls handled by Meridian Mail, you can set this up quickly like so:


First create a DNIS on your PBX. Choose an unused number (refer to LD 20: PRT LUDN).

In LD 49, convert the DNIS in your IDC table to route the call to your Mail ACD (ie IDC 1234 7000)

Then, in Meridian Mail, you need to first create a Menu Service: (MS)
(from the main screen:
Option 3 (Voice Administration),
option 4 (Voice Services Administration)
option 6 (Voice Menu Definitions)
press [F2] to add a new MS
Specify the Voice Menu ID nnnn, Title (give it a logical name)
Specify the Revert DN (I would make that the internal CDN)
LEAVE THE ACCESS PASSWORD BLANK (else callers will be prompted to enter a password)
Specify the UPDATE password
Set Silent Disconnect to YES
Then specify your action keys:
1 CL (call) nnnn (your internal CDN)
2 CL (call) nnnnnnnnnn (your external number including your AC1 or AC2)
3 - 9 (I would set to RP - repeat)
Initial no response (RP)
Delayed response CL nnnn (your internal CDN)
Press [F1] to save

Then [F1] (exit) again to go back to the previous screen:
Chose 1 (Voice Services DN table)
Press [F2] to add
Specify the Access DN = your DNIS you created in LD 49
Specify Service = MS , then you are prompted to enter the Menu ID, this is the one you created above
Specify comment = logical name
[F1] to save.

Now the PBX knows to send calls for DNIS nnnn to MMail, MMail knows that if DNIS nnnn calls, it must play the voice menu with ID mmmm.

When the caller makes the selection of key 1, MMail will send the call back to the PBX. Assuming you have set up the CDN and acquired it on Symposium, and you have an appropriate script, Symposium then handles the call to the CDN.

NB: You should still be able to report on the DNIS, by adding it into Symposium's DNIS table. You will see ALL calls to that DNIS. Your CDN of your option 1 will report on the calls presented to it after the call arrives from Meridian Mail.

All that is left to do is for some one to record the actual message to play (Welcome.. press 1 for this, press 2 for that). Theperson who records the message will need to know the Menu ID as well as the UPDATE password. They will dial your prompt maintenance number (you should see that in the Voice Services DN table.

If you want to handle the call in Symposium from moment of entry, then you have to start your entry number (the DNIS above) off as a CDN instead, acquire it, and write a script that includes the "GIVE IVR WITH MENU ID...." command.

Hope this is useful...

ell

Thanks for your response, it has been really helpful. However I still have 2 issues...

1) Firstly I want the number to go straight through to message instead of ringing. To do this I have entered the following command: FTR CFW 7000
However I keep getting the following error message - sch0355

2) I tested the number but when I choose option 2 (which should transfer to external number) I got the following message "your call cannot be completed at this time, please try again later"

Any help on this would be appreciated!!


This is a print of the configuration...

TN 37 13
DATE
PAGE
DES

DES 500
TN 037 0 00 13
TYPE 500
CDEN 4D
CUST 0
WRLS NO
DN 7006 0 MARP
CPND
CPND_LANG ROMAN
NAME Claims IVR
XPLN 24
DISPLAY_FMT FIRST,LAST
AST NO
IAPG 0
HUNT 7000
TGAR 1
LDN NO
NCOS 7
SGRP 0
RNPG 0
LNRS 16
XLST
SCI 0
SCPW 1111
SFLT NO
CAC_MFC 0
CLS TLD DTN FBD XFA WTA THFD FNA HTD ONS
LPR XRA AGRD CWD SWD MWA RMMD SMWD LPD XHD SLKD CCSD LNA TVD
CFTA SFA MRD C6A CNID CLBD AUTU
ICDD CDMD EHTD MCTD
GPUA DPUA CFXD ARHA OVDD AGTD CLTD LDTD ASCD
MBXD CPFA CPTA UDI RCC HBTA IRGD IAMD DDGA NAMA MIND
NRWD NRCD NROD SPKD CRD PRSD MCRD
EXR0 SHL SMSD ABDD CFHA DNDY DNO3
CWND USRA BNRD OCBD RTDD RBDD RBHD FAXD CNUD CNAD PGND FTTC
FDSD NOVD CDMR
RCO 0
PLEV 02
CSDN
AACS NO
MLWU_LANG 0
FTR CFW 4
FTR PHD
FTR FDN 7000
FTR EFD 7000
FTR EHT 7000
DATE 4 OCT 2007

Kalahary-Harry

Hi ell

I would NOT use a 500 phone set to manage the incoming calls. For the precise reason that the callers get ring back, and may even get busy tone, even if you use a phantom set.

Instead, here is what I would suggest:

1: (I don't know what your number range is from your telco, so I may assume one or two Ooops's)

Chose an unused number in LD20 by
Req PRT
Type LUDN
(type in the first digit of your telco number range, for example 1, the system will list ALL unused numbers starting with 1).
Let's assume you chose the available number 1006. (if your telco number range is 7000 and so forth, you can use 7006 as you listed above).

2. Go to LD 49
REQ PRT
Type IDC
Cust 0 (default?)
DCNO <cr>

You will get a list of all IDC tables that exist. If at all possible, use DCNO 0, or if the first DCNO is 1, then use 1. If you don't have any existing tables, instead of CHG just type NEW.

Req CHG
type IDC
Cust 0
DCNO 0
IDGT 1006
1006 7000 (that is your voice mail DN, correct?)
IDGT <cr>

If your telco number range is 7000 ++, then make the IDC entry

IDGT 7006
7006 7000
IDGT <cr>

(you have now created a DNIS entry that routes the incoming calls for 1006 or 7006 directly to Merdian Mail, no ring back - unless all your mail ports are busy.)

2:
Go to LD 23, and create the ACD-DN (ie 4006) for your agents to log in (if you already have that, excellent)

Then create your internal CDN (ie 5006), with DFDN nnnn (nnnn = the ACD-DN number)

Then create another ACD-DN (ie 5026) (for the call routing to your external company). In this case, set the NCFW n nnnnnnnnnn (the number including your AC1 or AC2 that dials out to the external number. Here is why:
- Your Merdian Mail may be set up to NOT dial out. And that is a GOOD thing, don't change it. A mail system that is secured in that way is a good mail system. So instead of dialing out directly via MMail, you are dialing out from an ACD-DN. This is a secure way, since no one can go and change the number unless they have a maintenance password. Ok... next:

Now log on to MMail, and set up the Menue Service (as described previously), and make your KEY1 CL 5006 (internal CDN), KEY2 CL 5026 (the ACD-DN that calls out to your external party), then the rest as described.

Remember also to ADD your DNIS (1006 or 7006, depending you what you used) to your Voice Services DN table! If you don't do that, Meridian Mail will play an error message to the caller and attempt to transfer to an attendant.

So now you have created a call flow like so:

Call comes in on 1006 (or 7006) -> transfers to Meridian Mail (7000)

Meridian Mail checks it's Voice Services DN table, and sees that the call must receive the greeting of your MS nnnn (what ever menu ID you specified)

Meridian Mail plays the recorded greeting (hello.. press 1 for internal CDN., press 2 for external number - obviously you will record a reall message!!)

The caller presses "1", Meridian Mail "dials" 5006 - your internal CDN:
- Your Meridian PBX notices that CDN 5006 has a DFDN of 4006 (your ACD),and the call is presented to the queue where the agents are logged in.

The caller presses "2", Meridian Mail dials 5026 - the ACD that will dial out and your call is routed to the external number you specified, because the ACD 5016 does NOT have agents logged in, and assumes it is in NIGHT MODE (=NCFW).
Remember though that for the duration of the call, you are using 2 ports on your PRI:
- One for the incoming call
- One for the outgoing call

Now... if you do NOT have your ACD licenses activated yet (again, I just assumed - silly me):

instead of using an ACD-DN for agents to log in, set up a hunt group, and in your MMail Menue Service, KEY1 CL nnnn call the Pilot DN of the hunt group (I never used it, but it should work?)

will

Kalahary-Harry,
Just out of curiosity, why wouldn't you use mermail's restriction/permission lists to outdial directly from vm? You can restrict everything and only permission a particular outdial #. Seems secure enough.

thanks,
Will

Kalahary-Harry

A number of sites got hacked here in South Africa about 3 years ago.. cost them millions in phone calls made via their MMail over just a few week ends. The "hackers" picked out a site one week end, flooded it with calls, then moved on to the next one the following week end and so on. I haven't really worked with MMail restriction lists, it was kind of agreed between the different support companies to lock MMail systems down as a general rule and route calls out via ACD-DN's. I guess old habits die hard. We took the approach of better safe than sorry. And belive me, affected customers wanted heads to roll amongst the support companies.. I like my head where it is right now.. he he