Tuesday, 20 October 2009

Number Normalization – Server Side

In OCS Number Normalization is performed in two places either on the Server if it is a Server activity or on the client if it is a client activity .

During my testing for my previous post around PSTN Conferencing I came across some difference in the way client side and server side normalization works.

These differences mean that translations which would succeed on the client will fail when performed server side.

My intial investigation have focused around a single Normalziation rule, in order to keep things simple.

So first the background, in the UK it is common for PBXs to require a 9 to be prefixed to numbers for outbound dialling so to cater for this I often use the following normalization rule, this allows users to continue to enter numbers as they would have done using a PBX phone:

Existing Normalization Rule

This rule should allow for either:

  • 01134960121
  • 901134960121

To be entered and be translated into:

  • +441134960121

This works as expected in the communicator client as shown in the following two screenshots:

Communicator Showing Translation 0Communicator Showing Translation 90

Route Helper and Test Translation within the Admin Tool both perform the translation as expected as well.

In this test there is only 1 Normalization Profile, which is assigned to the Pool and Mediation Server; there is no User Specific Profile assigned.

With regards to the logging shown during this post we will be focusing on the TranslationApplication log; as this contains the required information; in order to make the logs readable I have removed all but the explanation text; and each line is shown as a bullet point.

Before moving to the Server Side aspect, shown below is the output for when the Communicator Client logs in and downloads the Normalization Profile.

  • OnLocationProfileRequest: SERVICE, reqUri=sip:adam.gent@contoso.com;gruu;opaque=app:locationprofile:get;default
  • Phone context is user-default, using Location Profile assigned to caller URI
  • Using user-default profile: name=UK.contoso.com
  • Found default parameter, need default profile
  • Using default profile: UK.contoso.com
  • Sending 200 response to SERVICE request profile details. xml=<LocationProfileDescription xmlns="http://schemas.microsoft.com/2007/03/locationProfileDescription"><Name>UK.contoso.com</Name><Rule><Pattern>^9?0(\d{9,10})$</Pattern><Translation>+44$1</Translation><InternalEnterpriseExtension>false</InternalEnterpriseExtension><ApplicableForDeviceDialing>true</ApplicableForDeviceDialing></Rule><OptimizeDeviceDialing>false</OptimizeDeviceDialing></LocationProfileDescription>

I have removed all normalization rules from the last log line above apart for the one we are interested in.

Moving onto the Server Side, OCS uses the Translation Application to perform all Server Side Normalization requirements on the Server. For testing I have tested against the PSTN Conferencing (Conferencing Attendant Service (CAS)) and incoming calls into the Mediation Server.

Starting with Conferencing, I have called into the CAS twice from a Mobile (Cell) Phone, the first test is using 01134960121 as the phone number to identify with and the second is using 901134960121 both of these should be translated to +441134960121 as shown earlier with the Communicator Screenshots

The first test failed and the second test worked correctly as can be seen in the log outputs below:

Input: 01134960121 Expected Output: +441134960121 Actual Output: No Match

  • OnRequest: INVITE, reqUri=sip:+441134960100@contoso.com;user=phone newHostPart=
  • Processing From URI: sip:+447700900621@contoso.com;user=phone
  • Global number, no further From URI processing. FromUri=tel:+447700900621
  • Global number, no further processing. RequestUri=sip:+441134960100@contoso.com;user=phone
    calledNumber='01134960121'
  • No matching rule found

Input: 901134960121 Expected Output: +441134960121 Actual Output: +441134960121

  • OnRequest: INVITE, reqUri=sip:+441134960100@contoso.com;user=phone newHostPart=
  • Processing From URI: sip:+447700900621@contoso.com;user=phone
  • Global number, no further From URI processing. FromUri=tel:+447700900621
  • Global number, no further processing. RequestUri=sip:+441134960100@contoso.com;user=phone
    calledNumber='901134960121'
  • ruleName='PSTN Access UK - 0, 90' matched Num='901134960121', txNum='+441134960121'
  • MATCH: New request Uri='sip:+441134960121@contoso.com'

This shows that the Translation Application does not understand the optional part of the Regular Expression.

In order to see if this just occurs with the CAS, I did the same tests by providing 01134960121 and 901134960121 as the Called Number in an incoming call to the Mediation Server. Again the first test failed and the second test worked correctly as can be seen in the log outputs below:

Input: 01134960121 Expected Output: +441134960121 Actual Output: No Match

  • OnRequest: INVITE, reqUri=sip:01134960100;phone-context=UK.contoso.com@contoso.com;user=phone newHostPart=
  • Processing From URI: sip:+447700900621@contoso.com;user=phone
  • Global number, no further From URI processing. FromUri=tel:+447700900621
  • calledNumber='01134960100'
  • No matching rule found

Input: 901134960121 Expected Output: +441134960121 Actual Output: +441134960121

  • OnRequest: INVITE, reqUri=sip:901134960100;phone-context=UK.contoso.com@contoso.com;user=phone newHostPart=
  • Processing From URI: sip:+447700900621@contoso.com;user=phone
  • Global number, no further From URI processing. FromUri=tel:+447700900621
  • calledNumber='901134960100'
  • ruleName='PSTN Access UK - 0, 90' matched Num='901134960100', txNum='+441134960100'
  • MATCH: New request Uri='sip:+441134960100@contoso.com;user=phone'

Having established the same issue occurs for both the CAS and Mediation Server, I wanted to see what happened if I entered simple Normalization Rule to match 01134960100

In order to do this the following Normalization Rule was added and it was placed in the order after the existing rule.

The screenshot below shows the new rule:

New Normalization Rule

And the screenshot below shows the rule order:

Translation Ordering Location Profile

Running the two tests that failed again, 01134960100 for both the CAS and the Mediation Server both worked as expected although against the new Normalization Rule.

These are shown below:

Conferencing, Input: 01134960121 Expected Output: +441134960121 Actual Output: +441134960121

  • OnRequest: INVITE, reqUri=sip:+441134960100@contoso.com;user=phone newHostPart=
  • Processing From URI: sip:+447700900621@contoso.com;user=phone
  • Global number, no further From URI processing. FromUri=tel:+447700900621
  • Global number, no further processing. RequestUri=sip:+441134960100@contoso.com;user=phone
  • calledNumber='01134960121'
  • ruleName='PSTN Access UK - 0' matched Num='01134960121', txNum='+441134960121'
  • MATCH: New request Uri='sip:+441134960121@contoso.com'

Mediation Server, Input: 01134960121 Expected Output: +441134960121 Actual Output: +441134960121

  • OnRequest: INVITE, reqUri=sip:01134960100;phone-context=UK.contoso.com@contoso.com;user=phone newHostPart=
  • Processing From URI: sip:+447700900621@contoso.com;user=phone
  • Global number, no further From URI processing. FromUri=tel:+447700900621
  • calledNumber='01134960100'
  • ruleName='PSTN Access UK - 0' matched Num='01134960100', txNum='+441134960100'
  • MATCH: New request Uri='sip:+441134960100@contoso.com;user=phone'

While breaking down the Normalization rules into simple rules is one option, it is far from ideal as it create more rules and potentially more confusion; considering the rules work as expected client side.

Since I have only looked at a single Regular Expression which focuses around an optional character either there is an issue with the optional character within the Translation Application or there are issues with other regular expressions.

In summary just because every OCS test tool says that the normalization rule works and it works in Communicator do not assume that it works server side. Hopefully this will be fixed so that the same rule produces the same output no matter if it is run client or server side.

It would also be useful for another test tool that allows for testing against the Translation Application.

The test platform was OCS 2007 R2 Enterprise Edition running QFE2.

No comments:

Post a Comment