Pages

Wednesday, August 18, 2010

Auto Attendant Transfer to BCM Extension Problem / Resolution - Active Directory Telephone Attribute Matters

I ran into an interesting issue while integrating Exchange Unified Messaging’s Auto Attendant with OCS and PBX. After setting up everyone who was still living on the BCM’s EUM attribute to include the following string:

xxx;phone-context=LocationProfile.domain.com

… I noticed that when I called into AA, hit option # to transfer to a user’s extension, then entered someone who was on the BCM, I would get transferred to reception. After proceeding to test with another user I’ve been testing with, I noticed that I didn’t have any problems with the user. Just to be safe, I went ahead and opened up both of their mailbox attributes to confirm that their E-Mail Addresses tab was correct and they were:

image

Since I was running out of ideas, I went ahead and turned on logging on both the front-end and mediation server. After carefully reviewing the mediation server logs, I noticed something different about calling into extension 278 and extension 291:

image

As shown in the screenshot above, we can clearly see that after the NOTIFY sip:SomeName-UM01.inside.domain.com line, the successful transfer for extension 291 has an INVITE sip:291;phone-context=Toronto.inside.domain.com while the failed extension 278 shows INVITE sip:4165555555;phone-context=Toronto.inside.domain.com.

As I continued to scratch my head, I thought it was worth reviewing all the attributes stored in the Active Directory Users and Computers MMC snap-in. Opening the 2 users’ AD attributes window side by side shows the following:

image

I didn’t think the Telephone number attribute mattered but figure I’d give it a shot by changing Melvin’s to his internal extension as 278.

I went ahead and called in Exchange UM’s AA, hit # for transfer to user’s extension, and finally 278. The call successfully transfers! As it turns out, Exchange AA actually uses the EUM attribute to ensure that the extension that exist but when the call is actually transferred, it’s transferred via the user’s AD Telephone number attribute. I’ve also taken the time to confirm that this is true by entering my cell phone’s PSTN number in the telephone field, make an attempt to transfer and my cell phone ended up ringing.

I posted the snooper logs internally but can’t do it here as there’s the client’s company domain name in them.

No comments: