Sometimes customers ask if it's possible to let SwyxServer execute an ECR script for outgoing calls. The short answer is:

No, that's not possible. ECR scripts run for incoming calls to SwyxWare users only.

There's a longer answer to this question with a result you might not expect...

As mentioned above ECR scripts run for calls to SwyxWare users only. What if you could get all your users to dial the number of an special SwyxWare user and append the actual external number, e.g. to call Swyx a user would need to dial

9023147770

023147770 is the operator of Swyx in Dortmund. 9 would not be the configured public line access prefix, but the the internal number of the special user. Let's call him OutboundECR. And because it's a SwyxWare user, it can have an ECR script. Inside the script you can retrieve the additionally dialed digits by calling function PostDialingDigits(). In the example above that would return 023147770.

But at least two problems remain.

• How prevent your users from dialing external numbers directly, e.g. using the standard public access prefix or a canonical number?
• What if users use "overlapped dialing", i.e. hook off first and dial the number digit by digit?

The first problem is easily solved. Assign all users except the special one with number 9 a call rights profile which does allow internal calls only. The special user needs permission to do any type of call, of course.

The second problem is a little more difficult. When you hook off and start dialing 9023147770, the call would be delivered to user OutboundECR as soon as you entered the "9". The script runs and calls function PostDialingDigits(). If you dial fast, the function might return 02314 or some digits more or less. Or you might get no digits at all when you dial more slowly. But the script needs the full address, because the ConnectTo function supports block dialing only. Your script needs to wait until no more digits arrive. That can be done like this:

1. Create a variable to remember dialed digits, e.g. call it sDialedDigits and set it to an empty string
2. Create a variable to remember how often you already had waited, e.g. call it iNumWaits and set it to zero.Â
3. Call PostDialingDigits().
4. If the result is longer than sDialedDigits, store it in sDialedDigits and set iNumWaits to zero. Otherwise, i.e. if PostDialingDigits() returns the same as sDialedDigits already contains, just increment iNumWaits by one.
5. If iNumWaits is less than a predefined maximum, e.g. 5, let the script sleep for one second by calling PBXScript.Sleep(1000). Continue with step 3.
6. Otherwise, i.e. if iNumWaits has reached your maximum, don't sleep and continue with the script. The address to use is in sDialedDigits.

The above simple algorithm waits until there are no new digits for 5 seconds and continues. That way overlapped dialing can be used. If your users dial so slow that there are more than 5 seconds between two digits you can increase the timeout. But note that even when you dial very fast or if you use block dialing, the script will always waits at least 5 seconds. You could improve that by introducing a "#" as termination character so that a user can dial numbers like this: 9023147770#. As soon as your script detects the # it know longer waits and continues.

Now you have a ECR script being executed for each outgoing call. Anything possible for "normal" ECR scripts is possible in this script, too.

But there are several drawbacks:

• The timeout is one of them. Unless you can educate all your users to use block-dialing only, you have to live with it or use the # termination character workaround.
• Different call rights profiles for different users are no longer possible, because all external calls are made via user OutgoingECR and the profile of that user always applies. As administrator you could author OutGoingECR's script to enforce calling rights depending on the calling user, but that's different from the normal configuration.
• If your SwyxWare installation uses different locations you might get some issues, too. All outgoing calls are made in context of special user OutgoungECR, i.e. the location configuration like long distance call prefix is used instead of the prefixes of the originator. If you have configured inter-location call limits these might not work as expected, too.
• There's exactly one ECR script for all outgoing calls of all users. You could author that script to react differently depending on the calling user, but that's no real replacement for normal user-defined call routing rules.
• You users need to always dial the "prefix" 9 for external calls, even for canonical numbers or SIP URIs. Imagine dialing "9+4923147770" or "9sip:office@swyx.com". That's ugly and dialing from other applications like Outlook might no longer work, too.

There may be more problems I'm currently not aware of. I've had  no time to thoroughly test this approach.

 

But there's hope for the last issue. It's possible to keep the normal dialing scheme you're used to. Stay tuned for part 2 which will follow later this week.