Multi-Site Login issues - duplicate short mailbox numbers 1

[IPOdan]

Reference: thread1496-1612617

Having issues with multi-site, exact same as Ken Means saw over a year ago. The design has multiple PBXs using E.164 numbering, each with multiple DID ranges, which each range requiring a site. The problem is that when a 4-digit short number is duplicated at another PBX (different long numbers), the system will not allow mailbox login using the short number. The incoming call is linked to the PBX, and the VServer log actually shows the full 11-digit number, but then reports a failure to match.

Avaya is stating that each site must have a unique Hunt Group - which is impossible when using multiple DID ranges at a single physical PBX. To do so would require a seperate DID for checking voicemail for each block of DID's - and making sure the users use the right DID to call and check VM (Externally). Avaya claims that each additional site with the same hunt group will be ignored by design. If so, I would think this would cause invalid logins not just for duplicate short mailbox numbers, but for each mailbox number in the additional sites that share a common hunt group number. (Note that multiple PBXs do NOT share a common hunt group number.)
What Avaya is saying completely conflicts with the multi-site documentation, so I'm wondering if anyone else has had this problem and a different response.

Thanks,

Here's a snippet from the VServer log using 4271 (14014354271)as the example:

1873721112 [FINEST] T0276C <VServer.ocserver.Vups_FedbResolver> (ResolveOneOnly) Find 4271 VMDID A4CECEC4-3E75-496A-9DC1-0A415E242E32
1873721112 [FINEST] T0276C <VServer.ocserver.Vups_FedbResolver> (ResolveMailboxNumber) Get from FEDB
1873721112 [FINEST] T0276C <VServer.ocserver.GLOBAL> (EndLog) FEDB ResolveMailboxNumber T 0 M 0 Q 0

1873721112 [FINE] T0276C <VServer.TUIVLIB.CT_Resolver> (ResolveMailboxNumber) Couldn't resolve mailbox number <4271> <0x80041001> <VUPS_E_NOMATCH>
1873721112 [FINER] T0276C <VServer.TUIVLIB.global> (vuser4) 4-102: Resolve Mailbox Number returned <0x80041801> <CT_E_ENTRY_NOT_FOUND>
1873721112 [FINE] T0276C <VServer.TUIVLIB.global> (vuser4) 4-102: ERROR - Returned HRESULT <0x80041801> <CT_E_ENTRY_NOT_FOUND> - return RETCODE <V_MAILBOX_NOT_AVAILABLE>
1873721112 [FINER] T0276C <VServer.TUIVLIB.global> (VLUExit) UE 4-102 <0ms>
1873721112 [FINER] T0276C <VServer.TUIVLIB.global> (vuser4) >> UE 4-117 [Return number of matches for partial mailbox number]
1873721112 [FINER] T0276C <VServer.TUIVLIB.global> (vuser4) 4-117: VMD search requested <4271>
1873721112 [FINE] T0276C <VServer.TUIVLIB.global> (vuser4) 4-117: Multiple matches: <4271> matched to 2 entries
1873721112 [FINER] T0276C <VServer.TUIVLIB.global> (VLUExit) UE 4-117 <0ms>
1873721112 [FINER] T0276C <VServer.TUIVLIB.global> (vuser4) >> UE 4-117 [Return number of matches for partial mailbox number]
1873721112 [FINER] T0276C <VServer.TUIVLIB.global> (vuser4) 4-117: Local site search requested <4271>, longest MB = 11
1873721112 [FINE] T0276C <VServer.TUIVLIB.CT_Resolver> (ResolvePartialMailboxNumber) Couldn't resolve partial mailbox number <14014354271> <0x80041001> <VUPS_E_NOMATCH>
1873721112 [FINE] T0276C <VServer.TUIVLIB.global> (vuser4) 4-117: No matches
1873721112 [FINE] T0276C <VServer.TUIVLIB.global> (vuser4) 4-117: ERROR - Returned HRESULT <0x80041801> <CT_E_ENTRY_NOT_FOUND> - return RETCODE <V_MAILBOX_NOT_AVAILABLE>

 

[KenMeans]

Yes i have seen this and when you say "What Avaya is saying completely conflicts with the multi-site documentation"

You are correct and this has never been fixed in the MM software.

Ken Means

http://www.tel-is.com

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

 

[IPOdan]

An update on this.
After conversing with Avaya Tier 4, they have said that the feature is working as written. While they will not admit the documentation is then wrong, they will say that the documentation is "vague" and have put in a ticket to update the multi-site documentation.
So this issue will not be fixed.

So let me point out the extreme limitation of multi-site and the ability to use a short mailbox number for login...
For multi-site to work "as expected", each "site" or range of numbers assigned to a PBX must have a unique Hunt Group (Pilot) number assigned and that pilot number must actually pass through on the SIP Integration.
So if you only have a single "site" per physical PBX, you're golden.
If you don't have any duplicated Short Mailbox numbers in the system, you're golden.
If you are unfortunate enough to have both duplicated short mailbox numbers in the system and multiple number ranges per physical PBX, you're Out-of-Luck. You'll either have to assign each number range a unique hunt group number and ensure users use their assigned pilot number (specifically when calling in from outside the system or from a phone other than THEIR deskphone)OR you redesign the dial plan so that only a single range of numbers is used.
The last option is to abandon the ability to use short mailbox numbers for mailbox login. Using the long mailbox number always works.

As we have seen, this limitation comes into play when trying to use E.164 numbering formats, usually in association with Session Manager. Most companies do not have a single continuous DID block.

So our suggestion to customers is now to not use the Avaya recommended E.164 - at least for Modular Messaging. Instead, use a Legacy-style Site Prefix for each site as the leading digits of the long mailbox number. Using this method, we only use a single site per physical PBX. We're no longer concerned about duplicated short mailbox numbers between multiple PBXs. And end-users need not be concerned with their long mailbox numbers when using the TUI, as Short Mailbox numbers will always work.