Creating Queues

[Virikas]

Hey there,

as I am normaly more the server and SIP specialist guy I'm currently struggling about creating a simple callrouting with a queue script.

The script shall simply

1) Connect to the user behind the central number.

2) Put the call into a queue for that central number if that user is busy

3) Connect calls from the queue when the user behind the central number is ready again.

The challenge here is, that I need that callrouting for a larger amount of central numbers and I want to control it only via script parameters.

So I need a unique QueueID. Is it possible to use "=CalledNumber()" within the CreateQueue Block here?

CallDestination can be delivered via script parameter that's not a problem.

Secondly I got confused by the two different timeout exits from the call in queue block.

One is called queuetimeout, which should be the timeout value set in the Set Queue propertys block.

But what is the other one and what timeout value do I set in the set queue propertys block and what timeout do i set in the call inq ueue block?

Is there a possibility to create a queue without any kind of timeout?

And at least: Does anyone have an import ready script fro me?

regards

Virikas

[Tom Wellige]

Unfortunately all attempts to get a single call routing being used for different operators (with different paramters (like queue id, queue destination, ...) are doomed because the Queue ID field in the Create Queue misses an important feature:

 

 

 

 

The "x/y" button shows that it is possible to place own VBScript code into a field. Without that button it is not possible. And as you know, the Create Queue block misses that feature.

 

 

This is how the generated code looks like in case you try it anyway:

 

 

 

In order to work it would need to look like this:

 

 

 

So, having one script which servers for all your operators will not be possible.

 

 

About the two different Timeouts:

 

That was originally intended to be used for some sort of VIP handling. Like giving a VIP call a shorter timeout to get it faster diverted to another group.

 

First of all, that would also be possible by having just one timeout field, and secondly you can't do a real VIP handling with the SwyxWare queue.

 

For that you would put a VIP at the beginning of the queue (and not at the end, as you do with usual calls) and give it a shorter timeout. Now imagine first VIP comes in and gets at the beginning of the queue. Shortly after a second VIP comes in and pushes the first VIP to the second position of the queue...

 

In order to do something like that you would need a priority field per call and then sort the queue by priority and then by longest waiting time.

 

 

So, long story short: set both timeout fields to the same value and handle both timeout exits equally.

 

 

 

[Virikas]

Create Queue misses an important feature

This was exactly what I feared when looking at the GUI, but was hoping that there was just the GUI guy sleeping

Thanks for the explanation towards the different timeouts. This even gets not clear after reading the ECR documentation.

Such a simple script:

Start --> ConnectToWantedDestination --> Connect --> done

or

Satrt --> ConnectToWantedDestination --> Busy --> CreateQueue --> SetQueueAtribs --> CallInQueue --> (WaitFor)Done

[Tom Wellige]

In my opinion you don't need the first "Connect To" block.

 

Just put the call straight into the queue. If the destination is free the call will be delivered immediately.

 

You also don't have to wait for "done", as you will only exit the "Process Call By Queue" block once the call is disconnected again. Unlike the "Connect To" block, which you exit once the call is connected.

[Virikas]

The idea with the additional ConnectTo was, that calls can go directly to the desired destination if it is free, without the need of RAM consuming Queue Creation AND without a short waiting musikc snippet.

[Tom Wellige]

Oh yes, sorry, I forgot that one second of MOH. But that could be solved with placing one or two seconds of silence at the beginning of the MOH.

 

The memory usage is not a problem at all.

[Virikas]

The memory usage is not a problem at all.

You don't drive that many 1000 user 3000 devices systems

Memory IS an issue as long as that IpPbxSrv.exe is a 32bit process

[Tom Wellige]

Point taken