atcomsystems.ca/forum Forums TDM Business Telephone Systems Samsung Telephones & Systems SPNet with OAS and MGI64

Has anyone run into the issue of no audio across SPNet using an OAS and a MGI64?

I have a customer with several OS7400s SPNet together. A majority of the servers have a combination of 1 OAS and 1 MGI64, with only 2 of the servers having 2 OAS and no MGI64. Here's my problem, site 1 has 2 OAS cards and site 2 has an OAS and a MGI64. When a call is placed between site 1 and 2, and a MGI channel off the MGI64 is selected, I am unable to recieve audio from site 1. If a MGI channel off the OAS card is selected, audio passes both ways no problem. Any ideas?

Did this ever work? Have you tried to swap the IP addresses for the MGI and OAS?
John 807

Hard to say if it ever really worked. I took over this account from another tech. The customer started off small with expectations of only growing within the city. Now they are in 32 states with 7 servers on the east coast and 1 on the west coast. Due to growth we've had to expand the MGI channels. We're utilizing 16 MGIs on the OAS card as well as MPS and 64 MGIs provided by the MGI64. There are 2 servers that provide digital stations only, these are the 2 with just 2 OAS cards. All the other servers are strictly for VoIP phones, these are the servers with 1 OAS and 1 MGI64.

To answer you question about changing of IP addresses for the OAS and MGIs, yes i have done that. I've even gone through and changed all local IPs that the servers are using to something completely different. I've gone through and even opened up the firewalls to allow all traffic from each respective servers public IP, so no traffic should be blocked. So I don't think it's a port forwarding issue either.

Since the OAS and MGI are using the same ports in your router for paths to talk, you need to make sure the ranges are not conflicting with each other. So check that only one card is using range 30000-30128, then allow the next card to take 30129-30161 or whatever the next set is. You may just have a card and port conflict.

I wish that were the case. The original configuration was just as you suggested, OAS used 30000-30031 and MGI used 30032-30160. I've even gone through and re-programmed so OAS starts at 30000 and MGI starts at 31000 to make sure of no conflicts. Still have the issue though.

If the MGI channels were added after the original install check MMC 615. you could possible be missing some of the channels 38xx. check mmc 724 to confirm the 38xx on your MGI & OAS cards add them if they are not there & that could possible fix your issue. otherwise you will have to bust out wire shark & get a capture to see what is going on.

Was finally able to resolve this issue. Actually stumbled across the problem while troubleshooting another issue.

So we use Sonicwall TZ series router/firewall at these locations. One of these locations (site 1 from the scenario above) has 3 servers behind the Sonicwall and the Sonicwall is handling 3 Public IP addresses, 1 for each server. When setting up these public servers and port forwarding for the services, the Sonicwall creates NAT Policies for the outbound traffic. By default, the outbound NAT policy is created based on the services you set in the Access Rules for inbound.

So if you have a system with 2 OAS cards, it will use UDP ports 30000-30063 for its MGIs, and if you have another system with 1 OAS and 1 MGI64 it will use UDP ports 30000-30158 (sorry if my math is off). The Sonicwall creates an outbound policy stating the Source IP address of the OAS (192.168.1.12) will get Translated to the Public IP address (68.225.86.235) for Services of UDP 30000-30063.

However, when that server tries to connect (or respond) to a port on the MGI64 in the other server higher than 30063, the Sonicwall was sending it out based on a different policy that translated the Public IP to a different address. Therefore causing 1 way audio.

Resolved by changing the outbound policies for that server so that traffic from any of the private IP addresses on that server, using Any service (rather than based on its' inbound services), get translated to the correct Public IP for that server.

So essentially you didn't have the nat policies setup for the MGI card in your router. That makes sense.

They were setup. However, Sonicwall automatically sets them up based on the Firewall Access Rules, Services and Address Objects that you create. Essentially when it created the NAT Policies for outbound, it restricted the services for that particular server to only the services designated by the inbound rule. Therefore, if that internal server used a service outside of that group, the Sonicwall used the default public IP address rather than the Public IP address designated for that server.