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.