Udostępnij za pośrednictwem

Exchange 2010 SP1 Unified Messaging cannot transfer call to an extension

  • Artykuł

 

There are a number of reasons that may lead to calls not being transferred correctly to extensions homed on gateways - Cisco Call Manager, Audio Codes, OCS\LYNC amongst others, one of them blogged by me here. In this blog I am going to talk about another issue we have seen with our customers.

 

ISSUE

Unable to transfer calls to an extension using Auto Attendant with key mappings set.

 

CAUSE

Microsoft Exchange Unified Messaging (UM) 2010 SP1 currently relies on the From header from the initial INVITE (call request) into UM to form the URI to transfer the call to. It takes the extension from the Auto Attendant key mapping and takes the server part from the server part of the From header (which should indicate the server address of the gateway).

 

Example -

If the From header is From: "Test" <sip:4832883828@174.281.138.34>;tag=4839-293-2991-392943

 

A transfer to a key mapped extension 5748 may lead to a Refer-To header like Refer-To= <sip:5748@174.281.138.34>

 

Now, sometimes the gateways would include the right server address in the From header.

From: "Test" <sip:4832883828@anonymous.invalid>;tag=4839-293-2991-392943

 

This may result in Refer-to header -

Refer-To: <sip:5748@anonymous.invalid>

 

Which as you would imagine the gateway may not be able to handle. This will result in a prompt like "Sorry unable to transfer the call".

 

RESOLUTION

  1. The gateway should be configured to send the INVITE with the From header having the server address of the gateway.
  2. Microsoft will, in a future release try to use the server address from the Contact header in the INVITE instead of the From header, this should resolve most of the issues we have seen so far. Stay tuned to this blog to find out when this change is made.

Comments

  • Anonymous
    May 07, 2012
    has there been any news on this problem