Programmable System Shutdown Possible?

[Guest Buzby]

Hi there,

 

We're using VG 6.0.3377 for an intensive IVR application, running on 46 ports across two servers.

 

Now and then we need to restart VG and/or our database application for maintenance but due to the volume of calls we receive, it is presently very difficult to shut our server down without cutting users off.

 

Is it possible to somehow programmatically (or otherwise) block ports from accepting incoming calls once the line has become available (i.e. once a user has hung-up)?

 

Thanks in advance,

Tyron

[SupportTeam]

Are you using T1/E1 ISDN trunks?

The option of Blocking of individual channels on T1 ISDN trunks would be possible if using VoiceGuide v7, but is not possible when using VoiceGuide v6.

 

If you are using analog lines then to block an analog line you would basically need to take the line 'off-hook'. This can be accomplished by placing an outgoing call on the outbound line.

[Guest Buzby]

The option of Blocking of individual channels on T1 ISDN trunks would be possible if using VoiceGuide v7, but is not possible when using VoiceGuide v6.

 

Can I ask how this is done in VG7 please? An system upgrade is not out-of-the-question if we can justify it with functionality improvements such as this.

 

Thanks!

[SupportTeam]

It would be achieved by issuing a command through the COM/WCF interfaces to place the specified channel in Blocked state either immediately, or at end of current call.

 

ie. You would just run a VBScript which does the COM API calls, and then wait till all calls on system end.

 

The setting would not persist though a service restart. After service restart the channels would no longer be blocked.

 

Channels can be unblocked using similar COM/WCF call.

[ktruk]

Tyron: (bit late for this, but...) If you run a start-up script on each line, you might be able to setup a 'no-answer-flag' that you could use to refuse to connect a call, if its set, effectively closing out each line, until the flag is cleared. You would need some form of clue that all lines were free before shutting down, (line monitor?), but might do the trick. I think this would work on any VG release.

 

To select this option use the "Script Properties" menu entry from the "Edit" menu in the Graphical Design Environment, then check the "Start the script without answering call" box.

 

Either tread-water 'for-ever' or setup a Hangup Call exit path. Arriving at the "Hangup Call" module results in the script finishing and the call never being answered.

 

Calling any module which plays or records a sound file or transfers the call will result in a call being answered.

 

Cheers - Tim.

 

PS: Still using Notes?

[Guest Buzby]

Thanks Tim, I hadn't thought of that even though I knew that feature existed. I'll add that into the main codestream at my next opportunity, will let you know if it works

 

Yep, still using Notes, doing even more calls than ever (around 1.6 million minutes of VG & Lotus-handled calls this year, running 46 lines now). Unfortunately, still having problems with VG crashing the Lotus COM API. Finding it hard to find someone who has enough knowledge of both to trace the problem. Any idea?

 

Cheers,

Tyron

[Guest Buzby]

I used Tim's suggestion and it worked - my script now uses the presence of a file in the C:\ directory to know whether to reject a call or to pick it up.

 

One issue - I'm using ISDN I'd like to be able to issue a hangup-cause code - in particular, 'GC_USER_BUSY' which will tell our telco that one server is full to capacity and to route the calls to a different area altogether.

 

Unfortunately although I'm setting the DropCall_CauseCode $RV, it doesn't seem to be issuing this to the ISDN circuit.

 

Is this feature still supported in VG6?

[SupportTeam]

In v6 try setting:

 

$RV[DropCall_CauseValue]

 

to

 

GC_USER_BUSY

 

(or any other cause).