The Babraham Institute in Cambridge recently set up a SIP Trunk connection with Gamma, using a Mitel IPT solution.

They had a very simple setup with a private addressed VLAN internally for the phones and a Mitel Border Gateway server to handle the incoming and outgoing traffic. The Gateway was in a DMZ network. All the traffic traversed the firewall and was not being blocked.

With everything connected up, they were still having problems in getting the Mitel Border Gateway to interoperate with the Gamma Border controller.

Thanks to Carrick Kennedy at the Babraham Institute who has very kindly provided an outline of the issues and solutions so that others deploying a similar setup might find it useful.

-------------------------------------------------------------------------------------

The principle components of the system consist of Mitel 3300 MX ICP controller, Mitel Border Gateway, Checkpoint firewall & a Cisco external router connecting to JANET.

The ICP controller and the phones are in a dedicated reserved address space VLAN and only use NAT to get internet access for licencing and upgrades. The Mitel Border Gateway has two physical connections and configured in Network edge (server-gateway) mode. One NIC connects to the internal phone reserved addressed VLAN and the other connection to the DMZ VLAN which has valid internet IP addresses. Both VLANs are behind the firewall. This method of configuration, according to Mitel is not supported, but does work. However, there may have been an issue of mis-information as by default most people have reserved addresses behind a firewall and Mitel may not have understood that we were using valid internet IP addresses on the DMZ network and not using NAT.

The Checkpoint firewall was set up initially to permit any traffic to and from Gamma, with no special configuration for SIP packets. The Cisco router carries out the static NAT translations on a one to one basis to the controller and another couple of devices on the phone VLAN. For the Gamma SIP traffic, this NAT feature was not needed as the traffic was leaving the network via the DMZ network with its own valid internet address. The NAT is only there for authorising licenses etc on the controller which need to contact Mitel direct.

From the initial tests, we could see traffic to and from Gamma but a phone call could not be established. Various configurations were tried, but all had the same effect. The one clue that we had was both at Gamma and on our network, the packet captures were showing an ICMP error message packet. The packet source address was our Mitel Gateway and the destination address was at Gamma for what I will call the call setup server (in our case 88.215.63.161). The other IP address at Gamma was for the RTP streams. The ICMP packet was showing as Destination unreachable (port unreachable). Towards the end of the packet, we could see a Session Initiation Protocol section. There was the info about the number being called and the number making the call. All using port 5060. During the session we could still see the Gamma RTP server initiating an RTP stream to our Mitel Gateway address.

What we noticed was that the Mitel Gateway was using a random UDP destination port with a fixed UDP 5060 port as the source port. It was when we compared the packet captures on the Mitel Gateway to those on our JANET link, that we noticed that the random UDP port was different between the two packet captures. This was the reason that the Mitel Gateway was failing to setup the connection as the reply it was getting from Gamma was using a different port to which the Mitel Gateway had issued.

The cause of this was the Checkpoint firewall. It had identified the packets as being UDP SIP type and to resolve any potential problems with NAT, the default configuration for UDP SIP packets is to change this destination UDP port. This is configured under the advanced settings on the properties of the UDP SIP object. We changed this advanced feature so that it treated that packet as a "normal" packet and simply pass it through the firewall. As soon as this change was applied, we were able to make a successful phone call. This, we believe, is the default configuration of the SIP object but maybe different under the latest version called Gaia which we have not tested. I do not have information on other firewalls as to whether they behave in a similar way to the Checkpoint one.

In the end it was a simple fix, but did take a lot of digging around to find out and resolve the problem. So if anyone else sees an ICMP error packet with Destination unreachable (port unreachable) message, then they may be experiencing the same problem.