Jaa

Additional logic for resolving internal calling numbers in Exchange 2007 SP1 Unified Messaging

  • Artikkeli

Exchange 2007 SP1 Unified Messaging includes additional logic for resolving internal calling numbers (Reverse Number Lookup - RNL) when it needs to generate Missed Call notifications and Voice Mail notifications. In Exchange 2007 RTM it performs RNL against UM-enabled users in the same UM dial plan and the called user's Outlook Contacts. In Exchange 2007 SP1 Unified Messaging will also do RNL against all users in AD.

Exchange 2007 SP1 UM will start doing the same RNL searches as in Exchange 2007 RTM. However if a match is not found it will convert the Calling Party Number (if necessary), pre-pend "tel:+" and search in AD for a user with the string +\<converted number> defined in the msRTCSIP-Line attribute.

Let us discuss in more details how it works. First some definitions

  • Called Party Number - the number of the called UM enabled user
  • Calling Party Number - the number of the person calling the UM enabled user

These numbers can be presented to Exchange 2007 SP1 Unified Messaging in a number of different formats depending on the way Exchange 2007 SP1 Unified Messaging is connected to the PBX/PSTN.

Conversion of Calling Party Number

The conversion of of the Calling Party Number depends on the length of the Calling Party Number.

If the length of Calling Party Number is different from the parameter NumberOfDigitsInExtension of the UM dial plan of the called user Exchange 2007 SP1 Unified Messaging will take the Calling Party Number and convert it to an external number by pre-pending "tel:+" to it.

If the length of Calling Party Number is equal to the parameter NumberOfDigitsInExtension of the UM dial plan of the called user UM will convert the Calling Party Number to an external number and pre-pend "tel:+" to it, i.e. +\<external number>. The InternationalNumberFormat parameter describes how to convert an extension as defined in this UM dial plan to an external number format. The external number format could be E.164 formatted, but it is not required.

The format of the parameter is nnnnnnnnxxxxx, where x is a digit in the extension and the number of x's is equal to the UM dial plan parameter NumberOfDigitsInExtension. Let's see an example: if we have 5 digits extensions and the DID range is +131255xxxxx we would set InternationalNumberFormat="131255xxxxx" and NumberOfDigitsInExtension=5 on the UM dial plan.

The table below shows some examples on how UM will construct the search string.

Calling Party Number NumberOfDigitsInExtension in called user's UM dial plan InternationalNumberFormat in called user's UM dial plan Search string Note
22334 5 131255xxxxx tel:+13125522334 E.164 format
3125522334 5 131255xxxxx tel:+3125522334  
5522334 5 131255xxxxx tel:+5522334  
+13125522334 5 131255xxxxx tel:+13125522334 E.164 format
90113125522334 5 131255xxxxx tel:+90113125522334  

Why searching against the msRTCSIP-Line attribute?

So UM will search against all AD for a user with the converted Calling Party Number as the value of the msRTCSIP-Line attribute. Why is it searching against the msRTCSIP-Line attribute and not one of the many telephony related attributes in AD?

The reason is that the msRTCSIP-Line attribute is a key attribute if OCS 2007 is implemented in the environment. In such cases the msRTCSIP-Line attribute contains the Direct Inward Dialing (DID) number of Enterprise Voice enabled users homed on OCS 2007 in the format "tel:+<E.164 number>", exactly the format UM is looking for. Nice! Another advantage of using msRTCSIP-Line is that this attribute is indexed in Active Directory making searches faster. The msRTCSIP-Line attribute is also used when implementing Remote Call Control (RCC).

Since Exchange 2007 SP1 Unified Messaging is the voice mail solution for OCS 2007 it makes great sense to use the same attribute. The only caveat is that the search against msRTCSIP-Line will ONLY work, if the schema has been extended for LCS 2005 SP1 or OCS 2007. Exchange 2007 SP1 does not extend the schema with this attribute.

Which types of users will the new UM search be able to match?

The new UM search will be able to match all OCS 2007 Enterprise Voice enabled users in AD. This is all fine, but in a typical OCS 2007 Voice implementation process you will have some users still on the PBX and some users on Enterprise Voice. So how is it possible to have the RNL happen correctly when a user on the PBX calls a UM enabled user?

The answer is straightforward :-) You define the PBX users in AD. Typically they are already AD Users, but if not you can create them as AD Contacts. No matter if they are AD Users or AD Contacts then populate the msRTCSIP-Line attribute with correctly formatted numbers. You can either use ADSIedit to enter it manually or you can use LDIFDE or CSVDE to enter it using a script.