SIP-trunking a Nortel (now Avaya) CS1k to Exchange UM.

Posted by Greig Sheridan on 21 January 2011, 11:10 pm

I left a lot of my heritage and many familiar faces behind when I decided to jump ship from the PABX world in early 2010 and focus on this UC caper full-time, so I was delighted to recently have the opportunity to work with some old colleagues integrating a Nortel CS1000 (aka CS1k) with Exchange 2007 UM.

The published information on the whole integration process is rather limited, but we know that with a bunch of PEPs and some good fortune it’s possible to get a CS1k of at least Rls 5.5 software talking to Exchange. (I tried this on my in-house Rls 4.5 without success in advance, although I do know of a site “successfully” running UM on Rls 5.0 – even though it’s very much not supported).

The PABX configuration is covered in a lot of (unnecessary?) detail in this document, which I found in a number of places on the Interweb, so I’ll only show a couple of screen-captures here. (Paradoxically, this document references a minimum of Rls 5.0 software, but the feature wasn’t officially offered – or supported – until Rls 5.5).

The first trap though is that Exchange has moved on from Port 5060. Fortunately you’ll get a very concise error in Exchange if you’ve gone with 5060 in the PABX, and Exchange will point you to use port 5065. So far so good.

Just for clarity, here are our routing entries. “12345” is essentially our Message Centre DN, and “56789” is the Auto-Attendant / Voice Menu:

From this point you’re ready to attack the Exchange config. Fear not, the Exchange side is really quite simple. Just create a default Dial Plan, a Policy and an IP Gateway, and you’re 3/4 there.

In this particular example, Exchange was to replace CallPilot, so we created a 5-digit dial plan to match the PABX’s extension range. The relevant bits of the Dial Plan are:

NumberOfDigitsInExtension         : 5
AccessTelephoneNumbers            : {12345}
VoIPSecurity                      : Unsecured
URIType                           : TelExtn

(Don’t forget to apply the Dial Plan to this UM server at the Server Config level in the Exchange Management Console. Double-click the UM server’s name and go for the “UM Settings” tab. If you’re using Exchange 2010, this is also where you’ll set the Startup Mode to be either TCP or Dual).

Create an IP Gateway. The IP address of the gateway is the Node address of the CS1k:

Address           : 111.222.333.44

… and the Hunt Group Pilot Number is the Distant Steering Code you’ve created in the PABX, Element Manager & the NRS for Exchange to use as its VSDN-equivalent:

PilotIdentifier   : 12345

We also opted to add an Auto-Attendant. Again, the DN we used here had previously been created as a DSC in the PABX:

PilotIdentifierList                       : {56789}

From this point we found things were working well – to the point that one of our test extensions ended up with a real voicemail message before we were even aware of it.

Calling the main Exchange number (12345) from a user’s phone you were answered by the Exchange Voice Access greeting, the user’s number was recognised, their name was spoken (or their personal verification played), then you were prompted for their password. Cool!

Unfortunately, our test calls to the Auto-Attendant on x56789 were greeted by “Release and Try Again”, and Event ID 32768 stamped in the Event Log of Exchange:

The Telephony Manager declined a call with Call Id '5bc57fb8-1dcc394-13c4-40030-cb-39c99b1e-cb' for the following reason in component telephony session: 'The media description received from the remote SIP peer has an invalid content type 'multipart/mixed'.'.  Further trace information for support personnel follows: 
Microsoft.SpeechServer.Core.InvalidMediaException: The media description received from the remote SIP peer has an invalid content type 'multipart/mixed'.

Googling didn’t help, and we were struggling for an answer until one of our troupe suggested we swap the two DNs, and this led us to the solution. (Thanks Geeza).

In the PABX’s Element Manager, we’d neglected to realise there’s another gate opener that provided a place to enter the AA number. Once that was in, we were sweet, and on our way home: