Some PBX integrations can be particularly tricky, especially when they are legacy PBX is multiple versions behind the current releases or the hardware is failing. It reminds me a little bit of some of the old Exchange 5.5 and Novell migrations I have done in the past, except in a different kind of environment. On a good note, you eventually become pretty knowledgeable about different PBX systems and their quirks, and how to work through them the best you can.
With that said, I stumbled upon a particularly interesting blog post by a MS employee about using the
MSPL scripting language to manipulate SIP packets and fake a 180 ring back. Ultimately, the ideal fix is to get the existing PBX to do the right thing, but sometimes that is not always a viable option.
Read about the ring back workaround
here.
In the upcoming months, I'm going to dig more into MSPL and see exactly how creative you can get with this language. It could prove to be very handy for problematic/buggy SIP implementations or as a stop-gap measure to work around something that OCS normally cannot handle. I'm thinking of situations where you need to do something special/different between the mediation server and the PBX gateway to make things work correctly.
Of course, keep in mind any custom made scripts you deploy will be the first things that Microsoft PSS will want to disable in a troubleshooting scenario. It definitely would put you into an 'unsupported' scenario.