OCS 2007 R2 with Avaya Definity G3R Integration Notes

We recently did a lighthouse deployment with a very old PBX, the Avaya Definity G3r. There were a couple minor complications to this configuration however we were able to get through it with no issues and have full call flow between the two systems. I wanted to share the configurations we implemented in case anyone else runs into this unique PBX scenario.

Again we were utilizing a dialogic DMG2120 gateway for this implementation, if you notice on the Dialogic interoperability site you will not see any guides for the Definity G3 and OCS. http://www.dialogic.com/microsoftuc/pbx_integration.htm

We noticed in the exchange UM portion they had information for CAS signaling, however we could not get the CAS signaling to work properly so we decided to go with a T1 ISDN connection. The PBX would not support the QSIG standard so I reached out to our local support channel for some guides with the NI2 ISDN protocol. Dialogic does not currently have any official documentation around this setup, however they were able to provide some basic screens for me to hand off to the Avaya admin, and you can see these configurations below: (Note: These configuration screenshots were provided by Dialogic, I did not produce these)

Those screens above will get your Avaya side ready to handle the NI2 signaling from the dialogic gateway. The Dialogic side of this configuration is very basic and can be found below:

This customer also was one of the customers requiring #9 to get out to the PSTN which you can find a fix to in my previous post here.

(87)

Posted on by admin in Enterprise Voice, Microsoft, OCS, OCS 2007 R2, Unified Communications 3 Comments

Recording Custom Exchange UM Auto Attendant Prompts

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.

(252)

Posted on by admin in Exchange 2007, Exchange UM, Microsoft, Unified Communications Leave a comment

Dialogic DMG2120 T1 ISDN Firmware Bug: Sending # and * Characters on Call Invites

Typically organizations require a 9 or some other combination of digits to get out to the PSTN for outbound calling. At two recent deployments I ran into a scenario where the feature access code for PSTN dialing was #9. These customers had internal extensions in the 9000 range so it was not possible to use just a 9 for a feature access code. There are a couple tricky parts to this, as well as a dialogic bug which has since been fixed.

The first tricky part is that OCS does not work with a # or a * in normalized phone numbers. The simple workaround for this was to have users enter a #9 before outbound calls, but normalize it to +9 like OCS is used to dealing with. From there this matches outbound routes and goes to the Dialogic gateway to pass on to the PBX for outbound calling. At the gateway we make a routing statement in outbound calls to replace the + sign with a # so the number now looks correct for the PBX. This configuration can be seen below:

After running many tests all of our outbound calls were reaching the internal switch boards, or failing due to an unknown user. On the outbound call logs from the dialogic we would see the full number being sent (#912075551234). While talking to the PBX Administrators they claimed not to see a # sign and were only getting 4 digits, this was not matching any users so it was routing to the switchboard or failing. After some minor arguing back and forth about who had their settings set correctly to send the information I realized there must be an issue with the dialogic. I reached out to my local support channel that was able to confirm the bug, and the development team has come up with a fix.

Below is a link to experimental modified firmware for the DMG2120 series gateway when using a T1 ISDN connection. You should only apply this if you are having the need to send a # or * character in your call invites. This will be built in to the next public release, but I wanted to make sure people had some awareness of this if currently having this issue with deployments.

DMG2120 Experimental Firmware

(64)

Posted on by admin in Dialogic, Enterprise Voice, Microsoft, OCS, OCS 2007 R2, Unified Communications Leave a comment

Exchange UM With OCS and Receiving Faxes- Success Story!

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

(21)

Posted on by admin in Dialogic, Exchange 2007, Exchange UM, Microsoft, OCS, OCS 2007 R2, Unified Communications Leave a comment

Forwarding Extensions from Avaya To OCS with Dialogic DMG2120

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.

(43)

Posted on by admin in Dialogic, Enterprise Voice, Microsoft, OCS, OCS 2007 R2, Unified Communications Leave a comment
« Previous   1 2 3 4 5 6 7 8 9