Showing posts with label Normalisation. Show all posts
Showing posts with label Normalisation. Show all posts

Wednesday, 27 June 2012

Lync Dial Plan and Phone Words

So this is something new that I came across the other day, it has been around for a while but it actually affected a client, so had to figure out a way around it.
Phone Words, according to ACMA are:

Phonewords are made up from the letters of the alphabet that appear on a telephone keypad. These letters can be used to form a word, or a part word/part number combination, which can then be dialled as a telephone number to access a particular service. One example is '1300 FLIGHT'. Every phoneword has a primary underlying phone number, or in some cases more than one number, used by the telecommunications network as an 'address' for delivering the call.
The types of numbers that are most commonly used for phonewords include those beginning with the prefixes '1300', and '1800', which are 10 digits in length, and numbers beginning with '13', which are generally six digits in length.
When you think about it its actually pretty easy to solve, but first i had to get my head around what it all meant.


My original dialplan normalisation rule for 1300 or 1800 numbers was a simple
^(1[38]00\d{6})$ --> +$1
But as soon as a phone word was over the 10 total digits in length the call would fail. As a side note the number that was found to be the issue was the RSPCA number 1300 CRUELTY (1300 278 358).

So 1st plan was to remove the $ in the normalisation rule, and change it to 
^(1[38]00\d{5}\d+) --> +$1
This worked, until the call hit the gateway and was sent out with too many digits was rejected by the carrier.


So next plan was to only send the 10 digits to the gateway, this resulted in
^(1[38]00\d{6})\d* --> +$1

This only send the first 10 digits of the normalised number to the gateway and allows for the call to proceed to the carrier.


As with all pattern matching there is always more than one way to do this, so if you have a better way, please leave a comment.


Link to ACMA phone works fact sheet:
http://www.acma.gov.au/WEB/STANDARD/pc=PC_1682

Lync Normalisation Rules - Pattern Matching

The table below outlines some of the available regular expressions for Lync number normalisation.  


Element
Meaning
Example
Explanation of example
^
Match at beginning of string
^123
Match the digits 123 at the beginning of the string
()
Captures the matched sub expression
(456)
Capture what is between the parentheses into a numbered variable, starting at 1 which can be accessed as $n, eg $1
*
Specifies zero or more matches
\d(*)
+
Specifies one or more matches
\d(+)
?
Specifies zero or one matches
\d(?)
{n}
Specifies exactly n matches
\d{4}
Match 4 digits
{n,}
Specifies at least n matches
\d{3,}
Match at least 3 digits (with no limit to number of digits matched
{n,m}
Specifies at least n, but no more than m, matches.
\d{3,6}
Match at least 3 digits but no more than 6 digits
\d
Matches any decimal digit
^\d
Match any decimal digit (at the beginning of a string)
|
Matches any one of the terms separated by the | (vertical bar) character
134 | 135
Match either the string 134 or the string 135
$
The match must occur at the end of the string
^(123)$
Match exactly digits 123 (and not 1234)

The Lync number normalisation is based on .NET regular expression, more details can be found on the MSDN site: http://msdn.microsoft.com/en-us/library/hs600312

Zoom Virtual Agent (ZVA) and SNOW Integration

Adding Integration between SNOW and Zoom Virtual Agent (ZVA), is a fairly straight forward configuration, first step is to ensure that an OA...