Jump to content

Multilanguage queue


Wouter

Recommended Posts

Hi,

What would we the best practice to use a multilanguage system ? (Press 1 for Dutch, 2 for French, 3 for..,  1 for accountcy -> than queue )

Have multiple queues to the same destination / one for each language (but just read in another topic, this is not a good idea because the queue's can interfere with each other)

Change wav sound filename through a variable  and set this parameter for each new call ?

Thank you,

Kind Regards

Link to comment
Share on other sites


1 minute ago, Wouter said:

Hi,

What would we the best practice to use a multilanguage system ? (Press 1 for Dutch, 2 for French, 3 for..,  1 for accountcy -> than queue )

Have multiple queues to the same destination / one for each language (but just read in another topic, this is not a good idea because the queue's can interfere with each other)

Change wav sound filename through a variable  and set this parameter for each new call ?

Thank you,

Kind Regards

We do something similar: Incoming calls are compared to a database. If the caller is found we set a filename variable and play a sound file with exact that name.  Note that the file must be visible in the scope of the callrouting user.

Link to comment
Share on other sites


Hi,  I did some tests and noticed one queue works for every language (using a variable to set the sound file name).

Only culprit now is the system language of the queue waiting position voice.   How can this be changed ?  Found on this forum a : Best practice for multi-language call routing scripts (Part 1),

But not a part 2 where this would be described.

 

Link to comment
Share on other sites


This is a little bit tricky:

 

you would have to create a call routing user for every language you need and use the same call routing script for each user, which takes a call and adds it to the same queue.

 

After that you grab all the number/date/time announcement files from each SwyxWare language version and upload them into the USER scope of the specific language call routing user. You can also place your own announcement files in the single user scopes, and make sure that all call routing scripts of all language call routing users have the same name (as the scripts are the same and use therefore the same filename).

 

What is left now is a simple call routing user with a simple call routing script that gets all calls, figures the language to be used and transfers the call to the specific language user (connect to block, proceed with destination script).

 

That should work.

 

If you are only after the numbers 0 to 9 for the position announcements then you can of course record your own ones or grab only them the different SwyxWare versions. 

 

Important is, that all scripts of all language users use the same queue id!

 

Link to comment
Share on other sites


Hi Tom,

 

Thank your for answer.  OK I understand how to setup this up.  There is only a problem with the part of "connecting to block, proceed with destination script.

 

I wanted to use this same principle in a routing script for a customer. This customer lets the caller make multiple menu choices 1 for the language, another one for planning/offers/customer service/  etc.... (3 levels deep).

Therefore I write the  language and menu choices in a table of a database. (these choices will be displayed in the swxyit client during a call).

But, to keep a clear overview of the routing, I wanted to make one routing user per department and do the processing there. (routing user with proceed with destination script).  In this "department" routing user I then could read the menu choices back from the database to do the processing.  I could do this because the call id between the main routing user (with the public number)  and the "connected to"  (department) routing user is the same. 

But....somebody adviced me NOT to do this, because this might not work in the future.   According to this person the same call id between the main routing user and the connected to routing user, is actually a swyxware bug and a request have been made to Swyx to make it unique after being transferred.  (so the main routing user has a call id and the forwarded call to another routing user has another call id).  If the latter becomes the case the whole setup becomes invalid so he adviced me to do the whole processing in the same main routing user.

I know this becomes a long story....but I am just wondering...if this 'bug' becomes solved... will your principle of forwarding to different language routing users still work ..do your rely on having the same call id in the routing user where the call has been forwarded to.??

 

Link to comment
Share on other sites


Passing information from one call routing into another is also a little bit tricky.

 

The person who advised you is totally correct: every call gets it's own unique call id. The fact that you get the same id in every single script is in fact a bug and you mustn't rely on the id.

 

So you need to pass some sort of identifier into the next script on another way... Unfortunately there is no specific "string" field that could be filled with what ever you like and which would be passed over to following scripts. 

 

But there actually is another string field, that could be used: the calling party name. This property can be manipulated from within the call routing script. So within your first script you could do something like this 

 

     PBXCall.CallingPartyName = PBXCall.CallingPartyName & "###" & sMyOwnGUID

 

The second script takes a look now into this property and reads the unique identifier out from it.

 

Before connecting the call to a device (phone, SwyxIt!) you need to remove the identifier again from the property. Otherwise it would be displayed in the device's display.

 

Link to comment
Share on other sites


Hi Tom,

Sorry to come back here. Since I did the previous setup (split up for the languages), I have a problem with openqueue.

To test I setup a queue which sends call to a group with one available/online  member and one logged off user.

 

First call : works ok -> user picks up : so the only available user is connected

Second call to the same queue -> I get status unreachable in stead of the caller being added to the queue ?

 

If follow 2 times the same path, and so arrive at the same queue entry point.

 

Could you help me out ?

Link to comment
Share on other sites


Correction: it has nothing to do with the split up. It already was like that before.  Still not the expcected behaviour I suppose ?

 

I noticed that the queue works OK if I enter a single user as destination AND disable the secondary calls (otherwise the call is going to line2 or 3 of that user).

If I use a group as destination and one user is calling while the others are logged of,  then the "not reachable result is given" in stead of adding the call to the queue.

I suppose not reachable should only be given when all users in the group are logged of ?

 

Link to comment
Share on other sites


Hi Tom,

 

I installed the update. Now the call is indeed in the status "waiting". So the status is ok. 

But now another problem arises for the person on wait... the cm_dreamtraveller.wav (which I use as alert sound and music on hold sound)  starts over and over again (+/- every second) and the wait position in the queue is never announced.

This all ends after the queue timeout.

Thank your for your help so far.

 

Link to comment
Share on other sites


Okay,

Here the little test I did :

11:18 (19/02/2016)

1) called with user "testuser" nr 949 (line 2) to  hoofdlijn (nr 910).  Hoofdlijn (main line) is a routing script user which lets me choose the language. According to my choice it then connects to mainline_nl (for dutch), nr,916.  In this script I need to make some other choices, but in this test the call arrives in queue "qplanning1" with destination group "planning1" (nr.951).  This group contains one logged on user com2it (nr.902) and one logged off user.

The call arrives on the swyxit groupline (line3) of the user com2it and is picked up. (connected call)

 

11:20 (19/02/2016)

2) I take another line (line1) of the testuser and do exactly the same things (same language and other menu choises).  The call is now queued in Qplanning1.  But now the cm_dreamtraveller loops every second and waiting position is not announced.  After some time the queue timeout passes...

 

[EDIT: server file removed]

 

 

Link to comment
Share on other sites


I have found the reason for that behavior: the user "Sary" is in "Away" mode. Per default SwyxWare still identifies such users as available (if it's a group call), so that the OQ logic fails.

 

You can switch the SwyxWare behavior, so that "Away" and "Do not Disturb" states will not be taken as "available" on group calls anymore. To do this you have to add one of the following registry keys:

 

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Swyx\IpPbxSrv\CurrentVersion\Options]
"SkipGroupCallMembersWithActiveDoNotDisturb"=dword:00000001
"SkipGroupCallMembersWithActiveAway"=dword:00000001
 

Link to comment
Share on other sites


Hi Tom, this worked !!

Great ! Multiple queues, multiple languages with language specific queue position announcement,  sounds very professional !! 

I really thought the user (sary) was logged off and not just "away" (but possibly swyxit automatically logged back in while she was not there). Anyway,   the reg change fixed this.

 

Reselling Swyxware for many years now, still very glad to have chosen/selected swyxware many years ago.

Almost nothing is impossible with this product.  (made myself an answering machine you can set for the whole year with different messages for all kinds of holidays, exception lists, using gui, - also made a simbox callback script, etc...).

Thank you for your quick and good support.

I will do some further testing now.

Have a nice weekend.

 

 

 

Link to comment
Share on other sites


Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and have taken note of our Privacy Policy.
We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.