Jump to content

Tom Wellige

Root Moderator
 View Profile  See their activity

  • Posts

    4,309

  • Joined

  • Last visited

  • Days Won

    117

 Content Type 

Profiles

SwyxPEDIA Wiki

Zendesk Integration

Persistent Variables

Longest Waiting

VBScript build in functions

GSE build in functions (VBScript)

Server Script API (VBScript)

GSE build in functions (Lua)

Server Script API (Lua)

Function Collection (VBScript)

Function Collection (Lua)

IPS Integration

Jira Service Integration

Forums

Blogs

Downloads

Blog Entries posted by Tom Wellige

  1. Tom Wellige

    #6: Make it easy!

    By Tom Wellige,


    General
    VBScript Lua
     
    Last week I have shown how to setup a simple call routing script for the conference user to have a different pin validation for every available conference room.
     
    The latest version in that article had an hard coded pin validation for each room in an Evaluate block.
     
    This was ok when still developing the script but I don't consider that version properly usable or a customer as it is quite complicated for an untrained person to change a pin for a conference room.
     
    The GSE comes with a quite handy feature which could help us out here: GSE Rule Parameters.
     
    A GSE rule can have any number of parameters which can be configured from outside the GSE rule, i.e. the call routing manager, and will then be passed into the GSE rule. We will make use of this to have all pins for all conference rooms as parameters, so they can be easily modified from the call routing manager, even from a totally untrained user. WE had seen this actually already in a previous blog, #3: Be more flexible on dates!
     

     

     
     
    So, how do these parameter work? Quite simple actually. With just 3 steps you get them fully functional into your call routing script.
     
    Step 1 - Define the Parameter
    Open the properties of your GSE rule and switch to the parameters page. On there you will see an empty list in which you can add any number of parameters.
     

     
    Press the "+" button to add a parameter. You are now getting asked for three values.
     
     

     
    The first value is the name of the parameter. This name will show up in the description field in the call routing manager.
    The second value is a variable name. The parameter which is configured on the call routing manager (outside the GSE rule) is available within the GSE rule in this variable.
    The third value is the default value for this parameter which is used until the user modifies it. The user will also be able to revert back to this default at any time.
     
    Step 2 - Use the Parameter
    Once the parameter is defined it can be used. As said, within the GSE rule it is available in the variable we have defined in step 1. Of course now it depends on what your call routing script should do. In this tiny example I will pass the name of an announcement (file name) into the script and use the "Play Announcement" block to play that file.
     

     

     
    As file name we simply use the content of the defined variable.
     
    Step 3 - Set the Description
    The final step is to take a closer look onto the description of the GSE rule. As seen in the first image in this article a parameter is a clickable link in the description field of the GSE rule. So somehow we need to write something clever into the description field of the GSE rule, so that the call routing manager will display that clickable link.
     

     
    You can now read all manuals the SwyxWare comes with and do some extensive Google searches to find a definition of the required syntax for these links... Or....
     
    Press the following button:
     

     
    This is exactly the reason this button is there for in the first place. By clicking it, the GSE will generate for every configured parameter the required syntax in the description field.
     

     
    That's it! Save the GSE rule, exit the GSE and the parameter in all its glory in the call routing manager:
     

     
    By clicking on the link in the description field you are now able to set another announcement file name, which will further on used by the rule and announced for every incoming call.
     
    In case you want to check this little yourself, here it is:
     
    For VBScript based Call Routing
    Parameter Test.rse
     
    For Lua based Call Routing
    ParameterTest_Lua.rse
     
    Conclusion
    Now it is time to take the PIN validation for the conference rooms of last weeks blog article and bring it to the promised next comfort level.
     
    Define parameters for every room:
     

     
    Use the parameters when validating the PIN:
     

     
    Set the description field of the GSE rule:
     

     
    Done! We now have a call routing script for the conference user that provide a PIN validation for each conference room, where it is possible to give every room its own welcome announcement and PIN number, and to modify the different PINs from outside of the GSE rule in the call routing manager.
     

     
    In case you want to use it/play with it, here it is:
     
    For VBScript based Call Routing:
    Conferene_PIN_3.rse
     
    For Lua based Call Routing:
    Conferene_PIN_3_Lua.rse
     
     
    Enjoy!
     
    PS: don't miss to take a look into the ECR Useful Link Collection
     
  2. Tom Wellige

    #5: Let me in!

    By Tom Wellige,


    General
    VBScript Lua
     
    The SwyxWare comes with build-in conference rooms. In order to use them you just have to assign the wanted number (or numbers) to the "Conference" user via the SwyxWare Administration within the Microsoft Management Console (MMC) or Swyx Control Center (SCC). 
     
    When using the SCC you can assign a PIN for each configured conference room (from SwyxWare 11.50 or SwyxON 1.50 on). When using the MMC you just get the conference rooms without any PIN. But it is actually quite easy to setup a call routing for the PIN validation in front of such a conference room. This article will show how to do that, also for several different rooms, each with its own PIN.
     

     
     
    With a Get DTMF String block we ask the caller for a 5 digit pin and store it into a variable sPIN.
    Hint: please never ever use a name PIN as variable name. Why is explained here: GSE build-in function PIN.
     
     

     
    Afterwards we use the Evaluate block to check if the entered pin equals 12345.
     

     
    The SwyxWare handles numbers and DTMF digits internally as strings. So within the variable sPIN is a string and not a number. Therefore we have to compare it with a string "12345" and not a number 12345. In the latter case we would compare apples with oranges.
     
    If the entered pin equals 12345 the call will be connected into the conference room. This is done by using the Connect To block and use the "original destination" as target:
     

     
     
    From here you can download the call routing script. Please refer to the "Take me to your leader!" blog article to learn how to import this file.
     
    For VBScript based Call Routing:
    Conferene_PIN_1.rse
     
    For Lua based Call Routing:
    Conferene_PIN_1_Lua.rse
     
     
    With the above script it is possible to have a pin check in front of one room or the same pin check in front of every room. If you have several rooms and want to have each room with its own pin the script needs to get modified a little bit.
     
    Lets assume the rooms 300, 301 and 302 should get their own pin as also their own announcement asking for the pin. To do so Call blocks are used to evaluate which rooms has been called.
     

     
    As you can see, every conference room has now its own Get DTMF String and Evaluate block. This gives us the chance to configure different announcements per conference room as also different pins.
     
    Within the Call block at the beginning of each line we check, if a certain conference room (i.e. internal extension of the Conference user) has been called:
     

     
     
    From here you can download the call routing script:
     
    For VBScript based Call Routing:
    Conferene_PIN_2.rse
     
    For Lua based Call Routing:
    Conferene_PIN_2_Lua.rse
     
     
    The latest version of the script is already functional but not yet very user friendly. Imagine you have to change the pin for one of the rooms. You have to get into the GSE, open the "Properties" of the correct "Evaluate" block, change to the "Parameters" page and enter the new PIN between the quotation marks. If you are not used to handle the GSE there is a certain chance that you damage something. Fortunately there is a really nice and easy solution to get the script more easy maintainable. That will be the topic of next weeks blog article.
     
     
    Enjoy!
     
    PS: don't miss to take a look into the ECR Useful Link Collection
     
  3. Tom Wellige

    #4: Take me to your leader!

    By Tom Wellige,


    General
    VBScript Lua
     
    How to bring call routing functionality from user A to user B? 
     
    Two things upfront:
     
    a single rule of a user being made with the "GSE" can be transferred all rules of a user, regardless if being made with the "rule wizard" or the "GSE" can be transferred  
    Nothing else is possible!
     
    Lets start with item 2 of this list...
     
    Transfer all rules of a user
    The most comfortable way to do this is to use the SwyxWare Administration "Clone Properties..." feature:
     

     

     
    With this all call routing rules along with the used announcements (.wav files) will be copied to all users to the selected group. Afterwards all users of this group have an identical call routing (a copy of the original user's one). Any previous call routing of the users of the group is overwritten/gone.
     
     
    Another possibility is to download all files from the user's "USER SCOPE" and upload them into the "USER SCOPE" of the destination user. This can be done with the SwyxWare Administration:
     

     
    Select the original user:
     

     
    Select all displayed files and save them to your local drive:
     

     
     
    Afterwards select the destination user and press "Add..." to upload all previously downloaded files into his "USER SCOPE".
     

     
     
    Transfer a single rule being made with the GSE
    To transfer a GSE rule you need the so called .RSE file belonging to this rule. There are two ways to get this file:
     
    1. via the GSE
     
    Open the rule with the GSE, then open the "File | Export..." menu item. 
     

     
    You are now able to define the name and location to where the .RSE file should be stored on your local machine.
     
     
    2. via the SwyxWare Administration
     
    Just like above when downloading all files of a given user open his "Files" list in the properties of the server:
     

     
    Select the .RSE file belonging to your GSE rule. The filename here always starts with "rule" and being followed by the name you have stored your rule under. Press "Save As..." to store is on your local machine.
     

     
     
    With having the .RSE file in your hand you open the Call Routing Manager of the user you want to give this rule to and create a new rule with the GSE:
     

     

     
     
    Within the GSE open the "File | Import..." menu item and select the .RSE file from your disk.
     
    Save the rule, exit the GSE and Call Routing Manager and you are done.
     
     
    As already written above, these two described ways are the only possible ways to transfer call routing functionality from A to B. 
     
     
    I don't want to miss to mention the "GSE Actions". These are sort of subroutines which are created with the GSE and can be called any number of times. They are in fact the only thing within the call routing which can be provided globally to all users. So one single "GSE Action" can be used by all users on a system. This is how to provide call routing functionality globally and I will discuss it in detail some time later.
     
    Enjoy!
     
    PS: don't miss to take a look into the ECR Useful Link Collection
     
     
  4. Tom Wellige

    #2: Hello, it's me!

    By Tom Wellige,


    General
    VBScript Lua
     
    Imagine you are on the road, somewhere on a business trip and you have just learned that you will be one more day out of office. So you will not be back tomorrow but only the day after.
    Problem is, that the announcement you left in your "I am out of office" call routing rule tells all callers that you will be back tomorrow.
     
    How can you prevent callers getting wrong information? Do you have a chance to change you announcement from on the road?
     
    Yes, you can! All you need to do is to get into your remote inquiry. From there you are able to change the announcement of your standard voicemail or the unconditional redirection (enable/disable as also the destination).
    But you don't want to enable it in your standard voicemail, so that every caller could press the # key to end up in your remote inquiry PIN prompt. 
     
    The solution is a simple script on top of the rules list in your call routing manager, checking if you are calling, and if so getting you straight into your remote inquiry. All others should get into your default call routing.
     

     
    The following call routing script simply checks if it is you. If so the remote inquiry will be started. If not, the rule will be skipped, meaning that all following call routing rules in the list will be started.
     

     
    Place your mobile number into the "Call" block, so that the script will identify you from your mobile number.
     

     
     
    Within you remote inquiry it is up to you if you want to enter your PIN or not.
     

     
    One could argue, that you identified yourself already by your caller id, so the script already knows that it is you and the PIN prompt could be skipped. On the other hand with features like "CLIP, no screening" caller ids can be faked, you so might better not want to omit the PIN prompt. It's up to you.
     
    You can download this simple call routing script from here (of course you need to modify the currently configured mobile number).
     
    For VBScript based Call Routing:
    hello.rse
     
    For Lua based Call Routing:
    hello_Lua.rse
     
     
    Enjoy!
     
    PS: don't miss to take a look into the ECR Useful Link Collection
     
     
  5. Tom Wellige
    In this new blog series I am going to write on a more or less regular basis articles about the SwyxWare call routing.
     
    I will take together with you a look behind the scenes of the call routing, give useful examples for the daily usage, give examples and templates for the development of more complex rules and maybe from time to time just share a joke with you.
     
    From more than 15 years experience of giving the professional and developer call routing trainings I have a huge fundus of examples and tips to share.
     
    Some things might be already shared on the Swyx Forum page (forum articles, wiki articles or downloads), but I will try to shed some more light behind the "why" certain things work, and not just "how".
     
    I am open to any kind of suggestions for topics of this blog series. Feel free to voice them in the comments below.
     
  6. Tom Wellige
    From 2009 to 2011 mirjam baumberger wrote a great blog, the "Fridays' Swyx Tip". Every Friday she posted a tip regarding the usage of SwyxWare and connected tools and devices. As the old forum is offline, this article series will be restored here again over the time. Please note that some information in this article series might not be valid anymore with current SwyxWare versions or downloads might not be available anymore.
     
    This blog article was originally posted on 08.01.2009 09:17
     
    Dear Swyx Users
     
    I'm sure everyone is familiar with the Swyx caller list. The caller list contains information about the calls that have come in for you. You see the numbers of the callers, their names (if known), the time of the call and what happened to it, whether it was picked up or forwarded and so on.
     
    If a call was not picked up by you, you will see this by the animation of the "Caller List" button.
     

     
    But did you know that you can also send an alert msg when you have missed a called?
    Yes, Swyx makes sure that you stay in control of your communication! No call will stay unanswered, as you will be notified straight away if you have missed an incoming call to your extension.
     
    SwyxWare sends you an e-mail with the caller details, date and time when you did not answer your phone.
     
    You have missed a call from +6493092323 McNeil Ltd on Thursday 23/10/2008 4:42:59 p.m. The called number was 301. Click here to call back: callto:+6493092323 Brought to you by: www.swyx.com  


    Or you can even be notified via a txt message!
     

     
    To enable this notification e-mail, you have to add a simply call routing script to your rule book.
     
    You can download the sample ECR script fom below. Save the rule and import the script in your Call Routing Manager and change the e-mail address accordingly.
     
    AlertOnMissedCall.zip
     
     

     
    From now on, you will be notified if you missed a call and you can make sure that your customers are getting treated as they deserve it 😉
     
    Any questions?
     
    Have a good weekend and happy Swyxing . . . .
     
    Kind regards
    Mirjam
     
    @ IT Net World Ltd, NZ AUS SWYX Distributor
    http://www.itnetworld.co.nz/
     
×
×
  • 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.