During an upgrade to Exchange 2010 SP1 I had a nasty problem. After the upgrade of the Unified Messaging server the server didn’t accept any calls.
In this case the Unified Messaging server was connected to a Nortel CS1000 which used the Subscriber Access and Auto-Attendant of Exchange.
But how can you find out what is going wrong? First a look at the event log may be usefull but in this case nothing strange could be found there. Because the default log level is set to a low level it was necessary to raise the log level to a higher level. This can be done via two methods:
- Exchange Management Console
- Exchange Management Shell
Exchange Management Console
- open the Exchange Management Console
- select the node server management
- select the Unified Messaging server
- select the option Manage Diagnostics Logging in the right menu
- search for MsExchange Unified Messaging in the list
- raise the logging level for the following items: UMCalldata, UMCore and UMService
Exchange Management Shell
- open the Exchange Management Shell
- execute the following Powershell cmdlets:
Set-EventlogLevel 'Servername\MSExchange Unified Messaging\UMCalldata' -level Expert
Set-EventlogLevel 'Servername\MSExchange Unified Messaging\UMCore' -level Expert
Set-EventlogLevel 'Servername\MSExchange Unified Messaging\UMService' -level Expert
Don’t forget to reset the logging level to the original level when you are ready with troubleshooting.
When the logging level is raised it’s time to reproduce the issue. This can be done by, for example, call the Subscriber Access.
In this case this doesn’t help you much either so there was one option left: use a sniffer. Personally my favorite is Wireshark which can be downloaded for free from this site.
Once installed it’s time to reproduce the issue again, don’t forget to enable the capture before doing this.
When you have reproduced the issue you will see a lot of messages which are captured. Among them messages which are from the protocol type SIP. Select one of these rules and select the option Analyze _followed by _Follow TCP Stream. This will give an overview of all SIP messages.
Normally you will see the messages below:
When the problem occurs you will find only two messages Invite and Moved Temporarily:
</em>FROM: “Johan Veldhuis”<sip:110@pabx.local;user=phone>;tag=4ed6938-a161f0a-13c4-40030-6e2965-28e24116-6e2965 </p>
</em>TO: <sip:101@pabx.local;user=phone>;epid=EEBEB645D0;tag=4c63a61135 </p>
</em>CSEQ: 1 INVITE </p>
</em>CALL-ID: 5219808-a161f0a-13c4-40030-6e2965-72d8d4f0-6e2965 VIA: SIP/2.0/TCP 192.168.1.60:5060;branch=z9hG4bKc2922de4f77bdbe59f2613f3.1,SIP/2.0/TCP 192.168.1.10:5060;received=192.168.1.10;branch=z9hG4bK-6e2965-ae51b48a-6f4d0e7 </p>
</em>CONTACT: <sip:101@pabx.local:5065;user=phone;transport=Tcp;maddr=pabx.local> </p>
</em>CONTENT-LENGTH: 0 </p>
</em>SERVER: RTCC/3.5.0.0 </div>
When having a look at the trace above you will see that besides port 5060 also port 5065 is used. Exchange UM will try to redirect the traffic to port 5065. As the Nortel will continue to send messages to port 5060 the call won’t succeed. To solve this issue you will need to make a modification to the trunk so it will send messages via poty 5065 instead of 5060.
Once this has been changed the Nortel will be able to setup a connection to the Exchange UM server. But is this a real solution? Not really but this will require some additional explanation.
So why does Exchange wants to redirect the traffic to port 5065 and doesn’t use port 5060 which is used for SIP by default. Port 5060 is also used by Exchange for SIP but besides this another process is running called the UM Worker process which does the real work. Exchange will use the following ports for this:
The Exchange UM Worker process will be recycled once a week, this may has as a result that the Nortel can’t setup a connection after one week. This because the UM Worker process is recycled and now is using 5067.
But is there a solution for this issue? Well at this moment there isn’t one but I think somebody in the background is working hard on a solution for this. So for now we have the following options:
Because all options are not really a good solution you may need to choose the best of these three, from my point of view the last one.
If you would like to have more info about the Exchange 2010 UM process have a look at the following site.
Comments
