Symposium scripting - CLID 1

[Gigaic]

I am routing calls from an option 11C to an asterisk over a radio link (15KM). Any time this portion of the SCCS script has to execute, instead of the CLID showing the caller's #, a number 1125787** is shown instead. When the if condition is not satisfied, then we have the caller's # as CLID.

IF (LOGGED AGENT COUNT GO_IVR = 0) THEN
ROUTE CALL 1113001
ELSE …


where GO_IVR is the skillset.

This portion of script also does the same if uncommented:

/* IF (QUEUED CALL COUNT GO_IVR) > 2 THEN
ROUTE CALL 1113001
ELSE */

There seem to be some similarities. Could someone please advice me on what other commands I can use to route calls when no agent is logged in and also overflow when agents are logged in.

Thanks
George

 

[captaingadget]

If there are no agents logged in then the skillset is deemed to be out of service.

IF OUT OF SERVICE go_ivr THEN
ROUTE CALL .....

If there are agents logged in then you can overflow on age of call i.e. the length of time it has been queuing, or estimated wait time, or number of calls in the queue, or practically any mathmatical calculation you can think of.

If you attempt to queue a call to an out of service skillset then the call will not be queued.

IF NOT QUEUED THEN
ROUTE CALL .....

 

[Gigaic]

I am using IF OUT OF SERVICE ...

However, I had caller ID displayed on the PRI link while agents were logged in, eg (all numbers start with 27)

DCH 13 UIPE_OMSG CC_SETUP_REQ REF 00005835 CH 3 26 TOD 8:26:16 CK FE71CAD9
CALLING #:276542273 NUM PLAN: E164 TON: NATL
CALLED #:3001 NUM PLAN: E164 TON: UNKNOWN

However when agents are logged out, this is what I get:

DCH 13 UIPE_OMSG CC_SETUP_REQ REF 00000B87 CH 3 9 TOD 19:21:52 CK 0D6EF1F3
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:112578717 NUM PLAN: E164 TON: NATL
CALLED #:3001 NUM PLAN: E164 TON: UNKNOWN

The caller's # starts with 27, however I get 112578717.
What could be wrong?

Thanks
George

 

[captaingadget]

I'll be honest and say I don't really know what is going on but I will speculate that with agents logged on, then the call will have been queued at some stage and the CLID preserved.

When all logged out, the call will not have been queued it will instead hit the route call command and route to # 1113001. In this case I would suggest that the original CLID has been lost and replaced by the ID of perhaps the CDN or one of your trunks.

Does this sound feasable??

 

[djwht]

You're going to have to check in the 11C to see how 1113001 is going out...BARS/NARS, CDP...etc

 

[Gigaic]

Captain, what you are saying makes sense. What djwht said is more likely the problem and I need some help with that.

I programmed a route (11) with acod 111 and configured 2 ISDN PRIs (60 channels) into that route. The asterisk where I am routing calls to is expecting 3001 and hence when I route call 1113001 only 3001 is sent to the asterisk.

Please advice on what else to do since I believe the odd numbers being sent as CLID when agents are not logged in has something to do with the nars/bars/cdp. If u need me to post more information, I will.

Thanks
George

 

[djwht]

go to ld 21 and print out your clid table and post it if you can and also the route db

 

[Gigaic]

Hi djwht,

Here is the CLID (11257 definetly comes from here, but not sure where 87xx comes from):

REQ: prt
TYPE: clid
CUST 0
SIZE 10
RNGE

INTL 233

ENTRY 0
HNTN 11
ESA_HLCL 257
ESA_INHN NO
ESA_APDN YES
HLCL 257
DIDN YES
HLOC
LSC
CLASS_FMT DN

******************************************

Route Data Block (RDB)

TYPE RDB
CUST 00
DMOD
ROUT 11
DES NYANIBA
TKTP DID
NPID_TBL_NUM 0
SAT NO
RCLS EXT
VTRK NO
NODE
DTRK YES
BRIP NO
DGTP PRI2
ISDN YES
MODE PRA
IFC EURO
CNTY ETSI
SBN NO
PNI 00000
NCNA NO
NCRD NO
ISAR NO
CPFXS YES
SDID NO
DAPC NO
INTC NO
DSEL VOD
PTYP DCO
AUTO NO
DNIS YES
NDGT 4
DDLY NO
DCDR NO
ICOG IAO
RANX NO
SRCH RRB
TRMB YES
STEP
ACOD 111
TCPP NO
TARG
CLEN 1
BILN NO
OABS
INST
IDC YES
DCNO 1
NDNO 1 *
DNAM NO
MFC NO
ICIS YES
OGIS YES
TIMR ICF 512
OGF 512
EOD 13952
NRD 10112
DDL 70
ODT 4096
RGV 640
FLH 510
GTO 896
GTI 896


PAGE 002

SFB 3
NBS 2048
NBL 4096
DTD NO
SCDT NO
2 DT NO
DDO NO
DRNG NO
CDR NO
CCO NO
NATL YES
SSL
CFWR NO
IDOP NO
MUS NO
MR NO
PANS YES
EQAR NO
FRL 0 0
FRL 1 0
FRL 2 0
FRL 3 0
FRL 4 0
FRL 5 0
FRL 6 0
FRL 7 0
TTBL 0
ATAN NO
OPR NO
PRDL NO
EOS NO
DNSZ 0
RCAL NO
MCTS NO
ALRM NO
BTT 30
ACKW NO
ART 0
PECL NO
DCTI 0
TIDY 111 11
SGRP 0
ARDN NO
AACR NO

What do I do please?

Thanks
George

 

[djwht]

could you print a DNB of 8717

since you're direct selecting the route via ACOD, you're bypassing NARS/BARS, CDP and all other outgoing access restriction on the PBX...

That being said, all outgoing calls has a CLID attached to it based on the clid table assigned to device making the call. SCCS has no clid table assigned it like normal devices so all calls from SCCS will use the default clid table 0, plus anytime you direct select a route via acod, clid table 0 is used.

With DIDN set to YES in the clid table, this means to attach the extension number to the HNTN(NPA)and HLCL(NXX)or 11 257 xxxx. Since SCCS has no extension of its own, it relies on info its receiving in the calldata - more than likely, its the incoming CDN or DFDN.

A quick and dirty way to find this is do a DNB on the 87xx number or to get real precise, run a AML trace from the SCCS, or from the PBX (I wouldn't recommend, doing it from the PBX though, unless you like looking at hundreds of lines of HEX)

Armed with the above information and a layout of your callflow, you should be able to see the problem more clearly.

 

[Gigaic]

Thanks djwht.

I checked 87xx and found they are the DNs of LSE1 channels. Calls go to an IVR first before rerouting into a queue if they wish to speak to an agent.

If I want to just allow the CLID that came with the call (customer's number) to go all the way through to the off-site (Asterisk box) what do I have to do.

The strange part is the fact that when agents are logged in, it is fine, however when they all logout and routing is done by say IF NOT QUEUED THEN ROUTE CALL 1113001.

Please assist finally , you have been excellent.

Thanks
George

 

[djwht]

could possibly be a patch issue where the xfer clid is replacing the original clid after a xfer from a frontended menu...but before we head down the road...

the calls are leaving sccs via the route call command when agents are logged out, but how is the call leaving when agents are logged in?

 

[Gigaic]

In both cases, calls leave sccs via route call command.

This is the script which routes excess calls during the day and all calls when agents are gone home to another location (note labels A & B just put in for clarity):

IF NOT QUEUED THEN /* A */
ROUTE CALL 1113001
END IF


/* IF (QUEUED CALL COUNT GO_IVR) > 2 THEN /* B */
ROUTE CALL 1113001
ELSE */

QUEUE TO SKILLSET GO_IVR
WAIT 2
GIVE MUSIC 21

SECTION WaitLoop
WAIT 20
IF NOT QUEUED THEN
ROUTE CALL 1113001

ELSE
QUEUE TO SKILLSET GO_IVR
WAIT 2 /* Allow time in case an agent is available */
END IF

ROUTE CALL 1113001
GIVE RAN 36

EXECUTE WaitLoop

With both sections A & B put in comments, this is a live capture a few minutes ago (CLID is correct):

DCH 15 UIPE_OMSG CC_SETUP_REQ REF 00005B9C CH 22 26 TOD 17:55:52 CK 171E2EF0
CALLING #:275130214 NUM PLAN: E164 TON: NATL
CALLED #:3001 NUM PLAN: E164 TON: UNKNOWN

DCH 15 UIPE_OMSG CC_RELEASE_REQ REF 00005B4E CH 22 19 TOD 17:55:54 CK 171E3B4B

DCH 15 UIPE_OMSG CC_SETUP_REQ REF 00005B9D CH 22 19 TOD 17:55:56 CK 171E4DCF
CALLING #:276883787 NUM PLAN: E164 TON: NATL
CALLED #:3001 NUM PLAN: E164 TON: UNKNOWN

DCH 15 UIPE_OMSG CC_DISC_REQ REF 00005B9B CH 22 12 TOD 17:56:00 CK 171E691F
CAUSE: #16 - NORMAL CALL CLEARING

DCH 15 UIPE_OMSG CC_RELEASE_RESP REF 00005B9B CH 22 12 TOD 17:56:00 CK 171E6A1E

DCH 15 UIPE_OMSG CC_SETUP_REQ REF 00005B9E CH 22 12 TOD 17:56:02 CK 171E7CAD

When comments on section A was removed, this is what I got (CLID is wrong):

DCH 13 UIPE_OMSG CC_SETUP_REQ REF 00002784 CH 3 8 TOD 17:59:30 CK 1724D8F3
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:112578717 NUM PLAN: E164 TON: NATL
CALLED #:3001 NUM PLAN: E164 TON: UNKNOWN

DCH 15 UIPE_OMSG CC_SETUP_REQ REF 00005BAE CH 22 27 TOD 17:59:32 CK 1724E180
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:112578702 NUM PLAN: E164 TON: NATL
CALLED #:3001 NUM PLAN: E164 TON: UNKNOWN

DCH 15 UIPE_OMSG CC_SETUP_REQ REF 00005BAF CH 22 25 TOD 17:59:32 CK 1724E2CE
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:112578709 NUM PLAN: E164 TON: NATL
CALLED #:3001 NUM PLAN: E164 TON: UNKNOWN

DCH 15 UIPE_OMSG CC_DISC_REQ REF 00005BA4 CH 22 6 TOD 17:59:32 CK 1724E5F5
CAUSE: #16 - NORMAL CALL CLEARING

DCH 15 UIPE_OMSG CC_RELEASE_RESP REF 00005BA4 CH 22 6 TOD 17:59:32 CK 1724E73

Currently no agent is logged in. However, during the day when agents are logged in and comments on section B is removed, the same efect is experienced.

My email is g_ofori@hotmail.com if that will help.

Thanks
George

 

[yyrkroon]

I see a few things wrong with the script, unfortunately, I'm about to leave for the airport. I'll take a look at this, and hopefully have a fix for you on Monday

my apologies,

 

[Gigaic]

Thanks yyrkroon.

I am pleased to hear that you will take a look at the script for me today. I eargerly await your response.


Thanks again.
George

 

[yyrkroon]

ok, try this

IF NOT OUT OF SERVICE GO_IVR THEN
QUEUE TO SKILLSET GO_IVR
WAIT 2
ELSE
ROUTE CALL 1113001
END IF

IF QUEUED CALL COUNT GO_IVR > 2 THEN
ROUTE CALL 1113001
END IF

GIVE RAN #
GIVE MUSIC #

SECTION WAITLOOP
WAIT 20
IF PRIORITY IN QUEUE GO_IVR = 0 THEN
IF NOT OUT OF SERVICE GO_IVR THEN
QUEUE TO SKILLSET GO_IVR
WAIT 2
ELSE
ROUTE CALL 1113001
END IF
ELSE
IF QUEUED CALL COUNT GO_IVR > 2 THEN
ROUTE CALL 1113001
END IF
END IF

GIVE RAN 36
EXECUTE WATLOOP

 

[djwht]

is there a reason why you're not using cdp and instead using direct route access... I would think the CDP would work a whole lot better in this situation

I'm stump as to why you get different clid when agents are logged in vs logged out.

are you familiar with aml and eb traces on sccs? if you are, those would help in determining what's is going on

 

[Gigaic]

yykroon, I have changed the script with yours, however I am still getting the CLID problem.

djwht, I will try the CDP tomorrow to see if it helps. Any idea how I can stop the CLID table information from replacing the customer's number?

Thanks for the help.
George