Voice Session Script stops at 0 (zero)

[Andras888]

I have a new CCMS 6.0 with the following problem:

The script below is supposed to play back the calling DN, but every time it encounters a 0 (zero), it stops and hangs up. If I call it from DN 5091, it will play "five" and hang up. If I call it from DN 5760, it will play "five seven six" and hang up. It works fine with DNs without a digit 0.


ASSIGN CLID TO clid_holder_cv

OPEN VOICE SESSION
PLAY PROMPT NUMBERBYDIGIT clid_holder_cv
END VOICE SESSION

disconnect


Please help!

 

[djwht]

has the prompt for zero been recorded and tested (played back after the recording)?

 

[Andras888]

It has been recorded. What is the best way of testing it?

 

[dowlingp]

Use App builder and click on record! send to local phone and click Play this should give you your recording Back.

Also what file name have you given zero: as voice item 0 will not work.

 

[BellWest]

Is zero item 1 in the list with in the application?

Should be as follows

1=0
2=1
3=2 and so on

 

[Andras888]

I will have access to the system in 5 days and will check...

 

[Andras888]

In Application Builder there is an application called "prompts". In that application there is only Begin and End with nothing else in between. I don't see any of the numbers in announcements. They must be stored elsewhere... maybe on the CCMS server?

 

[djwht]

in the application, at the top menu, where File, View...etc- don't remember I think its Define and beneath that is voice items and in the voice items are all the prompts associated with the application

 

[Andras888]

Thanks for all your replies...

Yes, I found it. Zero tests fine. The voice ID for 0 is 104. The numbers = voice IDs are as follows:

1=1
2=2
3=3...
20=20
30=21
40=22...
100=28
1000=29
million=30
billion=31
21=32...
29=40
31=41...
39=49
49=50...
99=103...
0=104
Negative=105
Quadrillion=106
Trillion=107

It was set up by a vendor and I am not sure what logic the technician followed. I wonder if this setup is arbitrary or how it should be?

 

[Milesprower]

As Bellwest said, the configuration should be as follows.

c_zero_gv = file1:1
c_one_gv = file1:2
c_two_gv = file1:3

Sometimes a vendor may alter the configuration if you are playing the position in queue back to the caller (for example, there are 2 callers in queue). But, to play back numbers you should follow the configuration where the zero variable calls file1:1 and so on.

 

[Andras888]

Yes, we are playing queue position and estimated waiting time back to the caller. But we would also like to have another script (above) to play back the calling DN. How could we have both?

 

[Milesprower]

It looks like it will be a lot of work. You will have to rename the variables so they start with c_zero_gv = file1:1.

The position in queue intrinsic returns a value that is the number of calls ahead of the current caller. Your announcements may be worded so that the caller hears they are "caller number X in queue". Sometimes the vendor will take out the "0" value so that the caller never hears they are caller 0 in queue. So if you redo the variables you will probably have to reword the position in queue announcements.

 

[Andras888]

Milesprower, thank you! I am registered to take the admin course soon and it hopefully will reveal to me some more of what is happening... I wonder: The script announces the DN correctly except for the zero, the numbers are not off by one. So the system must know where the numbers are recorded. Why is the zero an exception then? Or could I record the numbers 0 through 9 separately in another application and somehow tell the script to use the new application instead?

 

[Andras888]

djwht, dowlingp, BellWest, and Milesprower, thank you for your replies! I just verified under script variables > voice segments, that c_one_gv = SCCS_Prompts:1 and c_zero_gv = SCCS_Prompts:104. In my mind, if the system calls the c_zero_gv, and it is pointing to the correct, existing, and working voice announcement of zero, it should just work. What am I missing?

 

[sandyml]

(1) Doublecheck the spelling and upper/lower case of the voice file in your variables (e.g., SCCSPrompts or SCCS_prompts is not the same as SCCS_Prompts

(2) Re-record the voice segment

As you say, it should work.

 

[djwht]

the application in CP you should be looking at is SCCS_Prompts and not prompts like you mentioned above

"In Application Builder there is an application called "prompts". In that application there is only Begin and End with nothing else in between. I don't see any of the numbers in announcements. They must be stored elsewhere... maybe on the CCMS server?"

if these are the same, then I would say, its time to call nortel after you have re-record the zero prompt jus to make sure its not corrupted.

it should be working, doesn't matter what order they're in, as long as the file and segment are correct.

 

[Milesprower]

numbers that are converted to spoken word are always stored in file1. I suspect that Nortel has some hard coded logic that requires this naming convention.

 

[Andras888]

Thank you sandyml, djwht, and Milesprower for your replies. I verified everything, re-recorded, and still have the same symptom. It is "SCCS_Prompts" in script variables > voice segment, I removed and re-added the <filename>:<seg#> of c_zero_gv as SCCS_Prompts:104, in Application Builder I opened the SCCS_Prompts App, re-recorded voice item 104 as "zero".

I will ask our vendor to open a Nortel ticket. There should be no charge from Nortel since it seems to be a bug with the system.

 

[Milesprower]

Don't be so sure, Nortel classifies almost everything as a customer issue.
As far as I know the name of the application in application builder is not important as long as you match it exactly in SCCS. However, to speak numical values, the voice needs to be recorded in application "file1".

 

[Andras888]

Milesprower, I will try creating a new application "file1" and record the numbers 0 through 9, then re-point them in script variables > voice segment, then test it. But what does not and would not make sense to me (even if this started to work) is why numbers 1 through 9 work as it is (if "file1" is a requirement), and work correctly, not off-by-one, with the exception of zero. Nonetheless, I will try it. I will have access to the system after CCMA training next week, which I am looking forward to. Thanks again!