A common confusion I am seeing from talking with customers and other engineers in the field is getting custom Greetings and Menu Prompts created for the Exchange 2007 Auto Attendants. The program of choice for me when creating these files is Goldwave, you can download the program with a free trial here. This trial version will get you all that you need for a certain time period to record all of your exchange recordings, however I would suggest supporting them and buying the product!
Below are screenshots and a basic walkthrough of creating a recording you can import into exchange 2007 for an auto attendant prompt.
Create a new file in Goldwave by clicking New or going to File->New. Choose the settings for a Mono recording and 8000Hz as the sampling rate and click OK.
To verify the input audio device is correctly set to your headset microphone click the button Highlighted in the above picture.
Choose the “record” device from the drop down menu and hit OK.
Hit the red record button in the middle and start recording the greeting. Hit stop when finished.
Select the unused space, make sure it is highlighted in blue, and hit the Delete key to remove all unused space so you are left with just recorded audio in the file.
Choose File->Save As. Save the file with the Attributes field as shown above: PCM signed 16 bit, mono. Make sure the file type is Wave (*.wav)
You now have a file that Exchange will work with as a Greeting or Main Menu Prompt
I will do a follow up post with importing these wav files for use and some tips and tricks from the WinXnet team on working with the auto attendants and their greetings.
Typically the two workloads of Exchange Unified Messaging and Office Communications Server with Enterprise Voice were deployed separately. Most Companies adopted Exchange UM before OCS, or Companies were deploying OCS in a pilot scenario and integrating with their existing PBX messaging system.
As these products become more mature we are seeing complete deployments of both workloads. At a recent deployment in a Boston based law firm users are being enabled for OCS enterprise voice as well as Exchange Unified Messaging and abandoning their legacy avaya phone. All of the laywers at this company have a telephone number and a fax number, a common difficulty is that the OCS Mediation server does not support the fax protocol. Therefore when deploying OCS as the main endpoint for a user, call flow comes through the mediation server, any faxes sent over this trunk would fail because the mediation server cannot handle the T.38 protocol.
I read a blog post from Mino (The UC Guy) linked here. Mino explained this scenario with a solution that included a secondary dial plan being assigned to users. The key part to this solution was also a second trunk from the pbx that is routed directly to the Unified Messaging Server instead of through the Mediation server.
At the customer in question we had already setup a separate trunk to the UM Server so they could provide all users with Exchange UM Functionality but slowly Migrate users to OCS for voice. We were already routing the faxes directly to the UM server by modifying the coverage path of their fax extension to our UM Pilot Identifier. You can see on the log from the DMG2120 below that the call was routing to the Exchange UM server without any issues, however in the exchange logs it could not find a user.
For the same reason that we had two seperate trunks for UM only users and OCS-UM users we had a secondary dial plan for TelExtn.
I am not sure if this is a commonly known thing however you must click the down arrow to add a EUM address rather than an SMTP address:
This is the same thing as executing this commandshell command provided in Jen’s blog post:
Set-Mailbox -id Randy Wintle -SecondaryAddress 61 -SecondaryDialPlan UmDialPlan
Once the second extension was added to the user (separate screenshots from the deployment and my internal testing), the fax would route correctly to the user and appear in the user’s mailbox.
Luckily for us we already had the ground work built without realizing the faxes would not go through.Now the next step is to get rid of the Avaya PBX completely and have all users utilizing the full Microsoft UC Platform J
A recent deployment integrating with an Avaya S8700 PBX utilizing a DMG2120 gateway to OCS ran into some issues when routing users extensions over to OCS for the piloting phase.
Because of the strain of creating individual routes for each pilot user when their extensions were not in a consecutive block, we have had many scenarios where the customer will forward their legaxy Avaya phone to either a new extension or a pilot identifier on the pbx. In a previous post I outlined the setup where users are assigned new extensions in OCS and they forward their deskphones to that extension. These extensions are a consecutive block so the Avaya routing is simple, all of the numbers matching that pattern route to the pilot identifier for the T1 trunk to the dialogic gateway. From there we would have a CalledNumber on the Dialogic of the new extension, which would route to OCS and do a lookup to ring the Communicator End Point.
The new scenario here was not having a new block of DIDs to forward to, instead attempting to forward to the Pilot Identifier of the T1 trunk on the avaya. Unfortunately I do not have any screenshots from the dialogic logs as this was done in realtime, however I will explain the steps as much as possible below.
The good news is the when forwarding the station to the pilot identifier we would see information hitting the DMG Gateway. This is where a screenshot from the call log would be handy, but basically we were receiving a Called Number of the Pilot Identifier and a Redirect Number of the users Avaya extension. The problem here is OCS cares about the called number, so a user lookup would fail. The DMG Gateways are great with modifying all parts of a call for the invite to go to OCS, we replaced the Called Number with the Redirect Number, giving OCS a number to perform a lookup and reach the user.
Unfortunately we ran into another issue here, this still was failing so running traces through the OCS Logger and Snooper we could see the numbers coming through but failing with Bad Voip Request errors, the same was showing on the dialogic in the call logs. Turns out, OCS does not handle a Redirect number being in the SIP Invite too well in this scenario. The end fix was to remove the Redirect Number all together, so the only information being sent to OCS was a Calling Number and a Called Number. The configuration information can be seen below:
Kudos really goes out to the dialogic team for having such a friendly interface and providing great help in the UI for their routing statements.