Normalization of phone number at the client end or server end?

Normalization of the dialed number into E.164 format has been an interesting thing always! I am not going to explain the normalization rules here..  What we are going to discuss is the end point where Normalization rule does take place to translate the dialed number into E.164 format..

Each user is assigned a location Profile, and upon dialing a phone number, the ordered list of normalization rules associated with the user's location profile are applied. If a first match to a normalization rule is found, the client translates the phone number into E.164 format before the SIP request is sent to the user's home pool. If a match is not found, the phone number is still sent to the user's home pool, but it is tagged as a dial string because it couldn't be normalized.
The dial string that the client sends to Office communications Server includes a phone-context attribute that specifies the name of the user's location profile. the server attempts to resolve the phone number by using the specified location profile normalization rules.

Note: During in-bound provisioning the clients cache normalization rule from ocs server based on their location profile. same rule they apply while doing normalization of any number.

So the translation of number with the help of normalization rules happens at the communicator and communications server both end. It depends on the situation. If communicator could normalize the number then the normalized number will be sent to the Office Communications server. If the communicator cant normalize due to any reason the number will be again tried to normalize at the Office Communications Server end.

See how does Reverse Name Lookup work!

when an External User makes call to the internal user(Inbound Logic)