Wouter Posted February 10, 2016 #1 Share Posted February 10, 2016 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 More sharing options...
RiseAndShine Posted February 10, 2016 #2 Share Posted February 10, 2016 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 More sharing options...
Wouter Posted February 15, 2016 Author #3 Share Posted February 15, 2016 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 More sharing options...
Tom Wellige Posted February 17, 2016 #4 Share Posted February 17, 2016 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 More sharing options...
Wouter Posted February 18, 2016 Author #5 Share Posted February 18, 2016 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 More sharing options...
Wouter Posted February 18, 2016 Author #6 Share Posted February 18, 2016 And If I understand OK : If I have 2 languages , 5 departments, 2 languages, and 2 queues for each department (according to the menu choice within the department), I have to make 20 routing users ?? That's a lot.... Link to comment Share on other sites More sharing options...
Wouter Posted February 18, 2016 Author #7 Share Posted February 18, 2016 Ignore my last questions, just made a routing user split after the language choice (and not on a further menu level) , so only 1 routing user with destination script processing per language needed. Nice trick by the way ! Link to comment Share on other sites More sharing options...
Tom Wellige Posted February 18, 2016 #8 Share Posted February 18, 2016 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 More sharing options...
Tom Wellige Posted February 18, 2016 #9 Share Posted February 18, 2016 About your second comment: yes, that exactly was the idea Link to comment Share on other sites More sharing options...
Wouter Posted February 18, 2016 Author #10 Share Posted February 18, 2016 Hi Tom, Thank you, for the tricks ! Link to comment Share on other sites More sharing options...
Tom Wellige Posted February 18, 2016 #11 Share Posted February 18, 2016 You're mostly welcome! Link to comment Share on other sites More sharing options...
Wouter Posted February 18, 2016 Author #12 Share Posted February 18, 2016 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 More sharing options...
Wouter Posted February 18, 2016 Author #13 Share Posted February 18, 2016 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 More sharing options...
Tom Wellige Posted February 19, 2016 #14 Share Posted February 19, 2016 I remember this to be a problem in OQ v2.0 (2.0.5) which is fixed in the latest available version v2.1 (beta 2). Link to comment Share on other sites More sharing options...
Wouter Posted February 19, 2016 Author #15 Share Posted February 19, 2016 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 More sharing options...
Tom Wellige Posted February 19, 2016 #16 Share Posted February 19, 2016 To analyse that I would need a server trace including a complete call into the queue and some information like who calls whom to be able to identify the call in the trace. Link to comment Share on other sites More sharing options...
Wouter Posted February 19, 2016 Author #17 Share Posted February 19, 2016 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 More sharing options...
Tom Wellige Posted February 19, 2016 #18 Share Posted February 19, 2016 Thanks for the trace. I have downloaded and removed it from your post again (as might contain privacy relevant data). I will have a look on it as soon as possible... Link to comment Share on other sites More sharing options...
Wouter Posted February 19, 2016 Author #19 Share Posted February 19, 2016 OK Thank you for all you efforts !! Will be great if everythng is working fine ! If I can grant you some credits as support, just let me know. Link to comment Share on other sites More sharing options...
Tom Wellige Posted February 19, 2016 #20 Share Posted February 19, 2016 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 More sharing options...
Wouter Posted February 19, 2016 Author #21 Share Posted February 19, 2016 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 More sharing options...
Tom Wellige Posted February 19, 2016 #22 Share Posted February 19, 2016 Glad that fixed the problem! Have a nice weekend, too! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.