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.