Unable to Acquire Voice Ports

[phlegmer]

Systems: SCCS 5, Callpilot 3, PBX 61C

We have only been using GIVE IVR in the past and would like to setup Access Ports so we can use the featureful OPEN VOICE SESSION in our scripts. I've been using the "Symposium, M1/Succession 1000, and Voice Processing Guide (297-2183-909)" to assist in getting this to work. Here is what I've done:

- Callpilot
- Converted 5 standard voice channels into ACCESS Channels using the configuration wizard
- Assigned Class ID's for each (1-5)
- Created SDN on CP (4001)
- Rebooted CP
- PBX
- Created a new ACD (4001) per the instructions for the ACCESS Channels
- Modified the already created TN's that were standard voice ports for ACCESS Channels (per the instructions [p86])
- SCCS
- Created and acquired new IVR ACCESS Channel ACD (4001)
- Created new Phonesets as Voice Ports
- Modified properties of Voice Ports in the Voice Ports section in SCCS to add the Voice Port Channel info (1-5)

It's these ports that will not acquire. (Acquire Failed)

I've since rebooted both CP and SCCS in the proper order with no change.

Is there any sort of system log to maybe shed some light as to why the acquire is failing?

Here is the PRT of one of the TN's:

DES CPILOT
TN 020 0 08 00
TYPE 2008
CDEN 8D
CTYP XDLC
CUST 0
FDN
TGAR 1
LDN NO
NCOS 0
SGRP 0
RNPG 0
SCI 0
SSU
XLST
SCPW
CLS TLD FBD WTA LPR MTD FND HTD ADD HFD
MWD LMPN RMMD SMWD AAD IMD XHD IRD NID OLD VCE DRG1
POD DSX VMD MMA CMSD SLKD CCSD SWD LND CNDD
CFTD SFD MRD DDV CNID CDCA MSID DAPA BFED RCBD
ICDD CDMD LLCN MCTD CLBD AUTU
GPUD DPUD DNDD CFXD ARHD FITD CNTD CLTD ASCD
CPFA CPTA ABDD CFHD FICD NAID BUZZ AGRD MOAD AHD
DDGA NAMA
DRDD EXR0
USMD USRD ULAD RTDD RBDD RBHD PGND OCBD FLXA FTTC DNDY DNO3 MCBN

CPND_LANG ENG
HUNT
PLEV 02
SPID NONE
AST 00 01
IAPG 0
AACS YES
ACQ AS: TN,AST-DN,AST-POSID
ASID 17
SFNB 1 2 3 4 5 6 11 12 13 18 22 24
SFRB
USFB 1 2 3 4 5 6 7 9 10 11 12 13 14 15
CALB 0 1 3 4 5 6 8 9 10 11 12
FCTB
ITNA NO
DGRP
PRI 01
MLWU_LANG 0
DNDR 0
DTMK
KEY 00 ACD 4001 0 6251
AGN
01 SCN 6275 1 MARP
CPND
NAME CALLPILOT PORT 1
XPLN 16
DISPLAY_FMT FIRST,LAST
02 MSB
03 NRD
04 TRN
05 AO3
06
07
DATE 2 OCT 2009


Many thanks in advance if any assistance!!

 

[Milesprower]

excellent detail.

Did you assign the SCCS C-Lan on the Call Pilot and the Call Pilot E-LAN on the SCCS (System Configuration Utility)? Did you check TCP and hardcode the Call Pilot Server Port to 10008?

 

[phlegmer]

Thanks for the quick reply.

I didn't do anything with the C/E LAN settings since this is an already working system for many years now. Is port 10008 something specific for Voice Ports to function?

Give IVR feature has and still is working today so I assumed all the IP settings would stay the same.

Is this a wrong assumption?

Thank!

 

[Milesprower]

You're probably ok, but I would check the SCCS Config Utility and make sure everything is exactly as specified in documentation. GIVE IVR is not nearly as picky as Access capability.

You can always back out of the config utility, but if you do need to make a change, it will shut down services, so you need to schedule a change during off hours.

 

[phlegmer]

Checked the SCCS Config Utility and the Voice Connection tab is configured to point to the correct CP ELAN address along with port 10008.

Forgot to also share the PRT of the ACDN in case something obvious I missed there:

TYPE ACD
CUST 0
ACDN 4001
MWC NO
DSAC NO
MAXP 12
SDNB NO
BSCW NO
ISAP NO
AACQ YES
ASID 17
SFNB
USFB 1 3 4 5 6
CALB 1 3 4 5 6 8 11
RGAI NO
ACAA NO
FRRT
SRRT
NRRT
FROA NO
NCFW
FNCF NO
FORC NO
RTQT 0
SPCP YES
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
NRAC NO
DAL NO
RPRT YES
RAGT 4
DURT 30
RSND 4
FCTH 20
CRQS 100
IVR YES
TRDN NONE
ALOG YES
OBSC NO
OBPT 5
CWNT NONE

According to the doc, the only thing that one needs to be concerned about is that IVR and ALOG are set to YES. Looks set to me.

What about any sort of system log to try and track what the heck is going on with the acquire failure?

Thanks!

 

[Milesprower]

The debugging capabilities are not very good. Basically you have three devices (Call Pilot, Switch, SCCS) that are not integrated, but hand-off tasks to each other. If anything is not exactly how it is supposed to be, it does not work.

I did not see that you rebooted SCCS as well as Call Pilot. You need to take both systems down and then bring up SCCS. When SCCS is up, then restart Call Pilot. Call Pilot must see Meridian Link Services from SCCS when it is coming up or it will fail. As a short cut or a little extra push, you may find stopping and starting VSM service on SCCS is required.

Do some searches in this forum, there are several posts on things to look for with Access capability.

 

[phlegmer]

[Milesprower] "I did not see that you rebooted SCCS as well as Call Pilot."

Yup, did that as mentioned in the original post:
[phlegmer] "I've since rebooted both CP and SCCS in the proper order with no change."

[Milesprower] "Do some searches in this forum, there are several posts on things to look for with Access capability."

Ok, I'll do some additional searching. However, my initial searching did not yield much help.

Thanks

 

[Milesprower]

There are some really detailed threads, including one which recently recommended a switch INI if you haven't done one in a while. (The E-LAN connections sometimes get hosed up.)

Are you sure you have all the software packaged on the switch to enable ACCESS? Also, there was a time when you needed to provision AST licenses for access ports.

 

[yyrkroon]

AACS YES
ACQ AS: TN,AST-DN,AST-POSID
ASID 17
SFNB 1 2 3 4 5 6 11 12 13 18 22 24
SFRB
USFB 1 2 3 4 5 6 7 9 10 11 12 13 14 15
CALB 0 1 3 4 5 6 8 9 10 11 12
FCTB


PBX shows the TN is acquired and so is the PID, by ELAN 17. Is ELAN 17 your Symposium?

I would advised to manually deacquire the ports on the PBX, out the VP programming on the Symposium and recreate them again, but before you acquire them, verify the port configuration on the CP...items such as PID, SCN and class ID. Then attempt to acquire just 1 of the VP.

The MLSM trace may help in identifying your problem.

 

[phlegmer]

Interesting! I looked at a regular agent's phone ASID and it was set to 17 as well. Not familiar on where to find out what system ASID 17 is. Also not familiar with how to manually deacquire a TN. Always done it from within Symposium.

Please advise.

Thanks!

 

[yyrkroon]

If your agents show ASID 17 then 17 is the Symposium. To check what ELAN 17 is, go to LD 48 and STAT ELAN, look at ELAN 17 IP address and verify it against your Symposium IP addresses, it should match up with the ELAN NIC interface.

To manually deacquire agents - LD 48 and type DACR AGT TN (TN of the agent)

 

[phlegmer]

Double checked and ELAN 17 is Symposium. Had me worried at first because it appears that the DES for 16 (CP) and 17 are switched around. Had to go into the Symposium server network config to double check.

Tried the manual deacquire and that seemed to work fine. I did a PRT of the TN and it appeared to no longer be acquired. I then deleted the voice port out of Symposium and re-added it. Tried to acquire and Symposium says the same thing....Acquire Failed

However, when I tried the acquire, the PBX terminal came up with:

VTN001 17 20 0 8 0 16 47 4

When I look up VTN001, it basically means it was successful in acquiring?

PRT the TN and sure enough, the PBX thinks it's acquired, even though Symposium still says it failed. Very odd.

 

[Wane47]

iapg is usually set to 1. access ports are much easier to bring up if you have the latest peps on callpilot and sccs. If you get the failure to acquire in sccs, it usually means the port is already acquired.

 

[Milesprower]

Although I have been told many times it should make no difference, we always set up SCCS as ELAN 16. It makes sense as SCCS is brought up first before Call Pilot and should grab ELAN 16. The fact that they are switched indicates either the switch is "stuck" (did you reboot switch?) or the Call Pilot came up before the SCCS in which case SCCS will not be able to acquire the ports.

Also, did you verify that you have the correct feature packages on the switch?

 

[sandyml]

Is SECU set to YES on botht the CallPilot and SCCS elans?

 

[phlegmer]

[Wane47]
"iapg is usually set to 1"

I checked ours and another site and they are all set to 0. According to a doc I found, the default is 0 -->

http://callpath.genesyslab.com/cics/zzntm1in.htm

[Milesprower]
"Although I have been told many times it should make no difference, we always set up SCCS as ELAN 16"

You may have stumbled on something. Granted that I did make sure SCCS was up before I powered up CP and it really shouldn't matter. Just got off my weekly telephony meeting and one of the folks mentioned that something similar happened to them when they had the ELAN 16 and 17 reversed.

I guess before going forward, we should try and get that straightened out. Is it just a matter of changing it on the switch and be done with it or do I need to power down CP and SCCS while making the swap?

Thanks!

 

[phlegmer]

[sandyml]
"Is SECU set to YES on botht the CallPilot and SCCS elans?"

It appears so

VAS
VSID 16
DLOP
ELAN 16
SECU YES
INTL 0001
MCNT 9999

VSID 17
DLOP
ELAN 17
SECU YES
INTL 0001
MCNT 9999

 

[Milesprower]

Well, when you power both SCCS and Call Pilot down, the first one up should grab ELAN 16. However, sometimes the switch ELAN assignment persists. This is why I asked if you can reboot the switch. Take everything down, reboot switch, bring up SCCS, bring up Call Pilot.

 

[phlegmer]

[Milesprower]
"Take everything down, reboot switch, bring up SCCS, bring up Call Pilot."

Yup, that's what we'll plan to try. We'll also attempt to get our ELAN assignment straighten out as well
[blue]
.STAT ELAN

SERVER TASK: ENABLED
ELAN #: 16 DES: SYMPOSIUM
APPL_IP_ID: 10 .0 .0 .4 LYR7: ACTIVE EMPTY APPL ACTIVE
ELAN #: 17 DES: CALLPILOT
APPL_IP_ID: 10 .0 .0 .3 LYR7: ACTIVE EMPTY APPL ACTIVE [/blue]

.3 is actually Symposium and CP is is .4

Can anyone suggest the syntax to make the swap? I see in the book that LD 48 can enable, disable, and stat ELAN's but not sure how to reconfigure 16 and 17. Would there be anything else that needs to be done before and after the ip swap (besides rebooting everything)? For instance, re-acquire all the phonesets?

Thanks

 

[phlegmer]

I think it has finally sunk in what you are talking about Milesprower. In my mind I was thinking that somewhere in the PBX, ELAN 16 and 17 were statically set to the specific IP. It wasn't until I did some digging with a LD22 and printed the configs for CFN. The configs show the ELAN's but there is nothing set as far as IP's for 16 and 17. I re-read your last comment and it now makes sense. Whichever is up first should grab 16. If that doesn't happen, ini time.