We are attempting to replace an ATT managed MPLS network with a Mikrotik site to site IPSec VPN. It has gone well so far with everything functioning fine with a single exception.
The company uses a Nortel BCM400 phone switch at each site which has 8 IP phone trunks between the locations. When a call comes in and is answered at either, works fine. If the employee transfers the call to another user also at their location, it works fine. However if a call is answered and the user attempts to transfer the call to an extension attached to the remote BCM, the call locks and hangs the system for a bit. The phones themselves are analog and not IP based in anyway, switch to switch communication is all we need.
Switching the gateway on the two phone systems back to the MPLS network restores everything. It seems the VPN and firewall addition to the picture is dropping something doesn’t it? How to tell what traffic is NOT traversing the site to site VPN? I have been pretty liberal on ‘interesting traffic’ for the purposes of the VPN (one side 192.168.10.0/24 to 192.168.20.0/24 with all protocols and the reverse on the other). All data traffic seems to do fine.
There are filter rules on both ends accepting all packets generated from the IP addresses of either BCM400 to any destination. I can watch these filter rules passing traffic while talking on the phone. I also have Mangle rules setup to mark any packet from either BCM with new packet mark ‘VOIP’ and a Queue Tree set to raise the priority of VOIP packets above anything else. I tend to think my method of QoS is not an issue, call quality is grand, just not the transfer part.
I know this is vague and begging a specific question here at the end, but does anyone have any ideas of what I might be missing here?
For clarity, does each of these PBX units have their own external line connections at each end? In other words are the PBX<>PBX links only used when:
a) transferring a call which came in on site A’s phone lines to site B or vice-versa
b) placing calls between site A and site B users
Does b) above work?
Are these SIP trunks?
The primary lines are all at one end. The locations are 60 miles apart. There are a few local lines at the secondary end, and the BCM decides when to use them - so if a local employee calls a local number, they use those, otherwise they all go out one end. Calling a number, without a transfer in the mix, seems to always work.
So, when you dial inbound to the main number, it goes to the primary location. The autoattendant answers and if you put in an extension at the secondary location, the autoattendant successfully transfers the call to the secondary location (secondary BCM) with no issues. It seems to only be user to user transfers.
As it relates to your SIP trunk question… maybe. I would assume that or some proprietary version thereof. Nortel simply called them ‘IP Trunks’ and made you license the number you had in place between BCM units. They sort of made the system a bit of a black box. The BCM is not a new unit and pre-dates modern SIP trunking.
Thanks for your time and thought.
Michael
Could you be accidentally NAT’ing the traffic between sites and that’s causing the BCM trunking to fail? Just a guess
The trunks may actually be H323. If you use Torch on the RouterOS interfaces is there any one-way traffic noticeable involving the PBX address while it is attempting the transfer?
SOLVED - I think 
CelticComms - using Torch was the trick. We were able to see traffic from the BCM phone switch which consisted of packets sent to 0.0.0.0/0 - which were not defined in our IpSec policy as we just connected the two subnets.
I added a policy in IPSec consisting of the source IP of the each phone switch, and a destination of 0.0.0.0/0. As soon as this was done ALL traffic from the BCM went across the tunnel and transfers started working.
THANKS MUCH FOR YOUR SUGGESTION
Michael
Torch is a very handy feature on RouterOS. I sometimes wish it existed on certain other vendors’ gear… 