locked
Problem with client side normalization RRS feed

  • Question

  • It appears that the client (Communicator 2007) does not synchronize rules within “Company_Phone_Number_Normalization_Rules.txt”.

    For example

    #######################################################################

    # Five digit Warner Robins Campus Normalization

    # If the first digit is “3”, construct E164 as follow: insert +1478329 and append the last four digit

    # i.e. 30000 becomes +14783290000

    #

    ^3(\d{4})

    +1478329$1

    #######################################################################

     

     

    When the rule is tested with ABServer.exe it returns the correct result:

    args[1]: 30000

    30000 -> tel:+14783290000

        Matching Rule in Company_Phone_Number_Normalization_Rules.txt on line 13

            ^^3(\d{4})$

     

    However, on client side, 30000 is not normalized when typed. I found that the key “PhoneNumberNormalizationRules” in the registry is not changing when “Company_Phone_Number_Normalization_Rules.txt” is changed.

    This is a problem because extensions listed in AD are incorrectly (not normalized) passed to Mediation server for outbound connection.

     

    What is the mechanism of this key update and how this issue can be resolved?

    Thanks,

    Drago

     

    Sunday, May 18, 2008 7:53 PM

All replies

  •  

    Just found I did not have Default Lication Profile for the Poll set up. It is all good now.

     

    Drago

    Sunday, May 18, 2008 10:29 PM
  • Can you explain to me, how a setting like "default pool location profile" (that is strictly an Enterprise Voice setting) can affect the Remote Call Controll phone normalization behavior, as these are 2 totally independent features of the product?
    Friday, July 18, 2008 4:11 PM
  • Right ... Default Location profile has no role to play in RCC. thats Enterprise Voice stuff..

    I think due to some reason the address book phone normalization took place in some time.


    Regards,
    R. Kinker
    MCSE 2003 (Messaging), MCTS - LCS 2005, MCTS - OCS 2007
    http://www.ocspedia.com
    http://www.itcentrics.com/LCS_Home.htm
    Sunday, July 20, 2008 7:58 AM
  • Actually, I am facing an issue because RCC (not EV) users does not seem to apply the rules written into Company_Phone_Number_Normalization_Rules.txt

    The content of the .TXT files appears in the registry under the required key, but still the communicator does not translate the incoming PSTN -> RCC calls to a valid E.164 caller number, so RNL does not happen.

    Is there any way to trace the number normalization process on the client side? (AFAIK the number manipulation does not happen at server side regarding to RCC users)
    Monday, July 21, 2008 9:42 AM
  • I am having a similar experience.  In either RCC or EV mode normalization rules just don't appear to get applied at any level.  In RCC mode they appear in the appropriate registry location, in EV mode the Trace logs show that the location profile contains the expected rules, but in either case numbers are not normalized to E164 and RNL fails.  

    Here is a sanitized EV example of just one of the dozens of different attempts I have made at getting client normalization functioning.  Following are excepts from a MOC trace log; note that the rules in this case are intentionally over simplified and tailored to testing for a particular incoming number, and are deliberately setup to result in irrational results just so that their successful applicaiton would be easy to detect:

    <LocationProfileDescription xmlns="http://schemas.microsoft.com/2007/03/locationProfileDescription"><Name>McPhoneVille</Name><Rule><Pattern>^\+4035551212(\d*)$</Pattern><Translation>3334445555$1</Translation></Rule><Rule><Pattern>^4035551212(\d*)$</Pattern><Translation>2223334444$1</Translation></Rule><Rule><Pattern>^\+?(4035551212)$</Pattern><Translation>+1$1</Translation></Rule><Rule><Pattern>^\+?[\s()\-\./]*1?[\s()\-\./]*\(?\s*(\d\d\d)\s*\)?[\s()\-\./]*(\d\d\d)[\s()\-\./]*(\d\d\d\d)[\s]*$</Pattern><Translation>+1$1$2$3</Translation></Rule></LocationProfileDescription>

    <?xml version="1.0" encoding="UTF-16" standalone="no" ?><DeliveredEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"><monitorCrossRefID>1823</monitorCrossRefID><connection><callID>131881096</callID><deviceID typeOfNumber="dialingNumber">tel:+7123</deviceID></connection><alertingDevice><deviceIdentifier>tel:+7123</deviceIdentifier></alertingDevice><callingDevice><deviceIdentifier>tel:+4035551212</deviceIdentifier></callingDevice><calledDevice><deviceIdentifier>tel:4035557123;phone-context=dialstring</deviceIdentifier>

    INFO  :: CUccRemoteCallControlEndpoint::IsLocalECMADeviceID - Type=1,Failed to match device-ID tel:+4035551212
    INFO  :: CUccRemoteCallControlEndpoint::CreateIncomingSession[03C4E8C8]-call-id=131881096,LocalDynamic=tel:+7123,LocalStatic=tel:+7123,Remote=tel:+4035551212
    INFO  :: CUccRemoteCallControlSession::FindParticipantByECMADeviceId - Type=1,Participant with device-ID tel:+4035551212 not found
    INFO  :: CUccRemoteCallControlSession::IsLocalECMADeviceID - Type=1,Failed to match device-ID tel:+4035551212

    No matter what I do in trying different normalization rules - even completely illogical and far fetched possibilities - the incoming number is never recogonized and normalized by either the Med Srv. or client in either of RCC or EV mode.

    Any ideas about how this is possible would be greatly appreciated.

    Cheers,
    Tuesday, March 24, 2009 9:27 PM