Hi I have an issue with this site regarding remote phones I registered a phone from my office and it was fine I can cycle though all the mgi ports without one fail which proves to me the ports in the firewall are correct,
The problem arises when I take it to any other sites some calls are fine and other have no speech at all, it's also very random as well I can have 10 calls with no speech then every other call works then a bunch of calls that do work, I have tried three different sites and all the same, also from these site I registered it to another system and it works fine.

I talked to Samsung and they said they have come across it before on other sites and it's down to the firewall not passing the voice through correctly even though the ports have been configured.

I am currently asking their IT company to check to see it my office IP is on any allow/white list which would explain why it works and all the rest do not.

Any one else had any issues like this or can shed any light on the subject?

Thanks in advance.

If you are connecting IP phones to a system using the public IP of the system, make sure that ports 6000, 9000, 9001 are all forwarded to the processor IP of the system.

All the ports seem ok going to get some wire shark traces and send them to Samsung.

What kind of system is it and what software version are you running?

It's a 7200 v4.92

If its a MP20s check the rtp ports (MGI & MPS) arent overlapping if you have an OAS in there.

If its an MP20 is your svmi20i overlapping any rtp ports?

Whats the spec of the system?

Attempt to assign MGI ports directly to the phone and see if the problem persists. I have seen this before once and it was the Router causing an issue. For the IP phones to work, you only need ports 6000, 6100, 9000 and 9001 forwarded in the firewall. No need to have MGI's unless you're running SIP on the system. As you say they're all going into the firewall and pointed at the system's internal IP for the processor. I would recommend getting a log of the firewall with the inbound requests from the other IP locations giving you trouble. To see what is going on. If the packets are dropping at the firewall or before.

I'm using a mp 20 with SVMI 20I and have made the ports on the svmi start after the OAS card ports. not been able to get a wire shark trace yet as the on site IT guys in on holiday but their firewall guy is going to run some Logs for me to see if we can get to the bottom of it.

Thanks

I'm using a mp 20 with SVMI 20I and have made the ports on the svmi start after the OAS card ports. not been able to get a wire shark trace yet as the on site IT guys in on holiday but their firewall guy is going to run some Logs for me to see if we can get to the bottom of it.

Thanks

Curious, do you have the white list enabled in settings?

What lines do you have?
Are the handsets on the system DGP or IP?

White list seems fine also using mainly DGP one or two onsite IP phones that work fine and they are using ISDN line but the problem happens with internal calls and to VM as well not just external calls, firewall guys are doing a trace for me early next week.

Hey

This is still going on, the Firewall people can see the problem just cant seem to fix it any one had a problem like this before or know a fix below is there response, also put their Nat settings at the end.

In short the firewall is seeing duplicate flows and dropping them due to the way we have NATted the traffic. Attached is how we have configured the firewall for the NATs, this is so calls can be made both outbound from the school and also inbound so you can take a phone anywhere and still get calls

Is the NAT configuration how you would expect it to be configured?, Is there any other way we can design the VOIP system to avoid duplicate flows?



I reviewed the data you uploaded and I found that the problem is related to the NAT design.Flow baisc logs shows that sessions on port 6000 and also on other ports (ex 30018) failed due to be installed because of duplicate flows being detected.

== 2016-11-14 13:44:18.346 +0000 ==
Packet received at slowpath stage
Packet info: len 60 port 16 interface 16 vsys 2
wqe index 161389 packet 0x0x80000004146e88e6
Packet decoded dump:
L2: 00:1e:49:f4:5c:1a->00:1b:17:00:01:10, type 0x0800
IP: 92.234.10.74->195.246.109.113, protocol 17
version 4, ihl 5, tos 0x00, len 42,
id 395, frag_off 0x4000, ttl 50, checksum 44700
UDP: sport 6000, dport 6000, len 22, checksum 26650
Session setup: vsys 2
Allocated new session 89604.
destination translation 195.246.109.113/6000 => 10.16.149.3/6000
DP0 is selected to process this session.
Created session, enqueue to install
Duplicate flows detected while inserting 179209, flow 2471112 with the same key<<<<<<<<<

A session is a combination of two flows, client to server (c2s) and server to client (s2c). As per the above packet two flow needs to be installed.
c2s: 92.234.10.74/6000->195.246.109.113/6000
s2c:10.16.149.3/6000->92.234.10.74/6000

As per the log, the firewall detected that the flow with id 179209 matches an existing flow.The flow with id 179209 is the s2c flow(session*2+1).So basically there is another session with. c2s as 10.16.149.3/6000->92.234.10.74/6000 and a different s2c.
My understanding of the traffic flow is that packet from 10.16.149.3/600 to 92.234.10.74/600 are expected because VoiP calls can be triggered from outside to inside and the other way around.

Traffic from 10.16.149.3/600 to 92.234.10.74/600 is also NATed as per rule Cathedral School Voice Outbound.Hence when the traffic is initiated from 10.16.149.3 the flowing two flows are created.

c2s 10.16.149.3/6000->92.234.10.74/6000
s2c 92.234.10.74/6000->195.246.109.113/X

I reviewed the flow basic logs and the same thing is happening on port 30018.

To make it working you need to change your NAT design in order to avoid that the flow of sessions initiated from outside matches one of the flows of sessions that are initiated from inside.

NAT #1
Source: Internet (Any Address)
Destination: 195.246.109.113
NAT Address: 10.16.149.3
Port:
UDP – 5090
TCP – 5180
UDP – 6000
UDP – 9000 – 9001

NAT #2
Source: Internet (Any Address)
Destination: XXX.XXX.XXX.XXX
NAT Address: 10.16.149.4
Port:
UDP – 30000 – 30032
UDP – 40000 - 40128

NAT #3
Source: Internet (Any Address)
Destination: XX.XXX.XXX.XXX
NAT Address: 10.16.149.5
Port:
TCP – 6000 - 6002
UDP – 30033 - 30035


NAT #4
Source: 10.16.149.3, 10.16.149.4, 10.16.149.5
Destination: Internet (Any Address)
NAT Address: XXX.XXX.XXX.XXX
Port: Any Port

You say

"Attached is how we have configured the firewall for the NATs, this is so calls can be made both outbound from the school and also inbound so you can take a phone anywhere and still get calls"

What do you mean by take a phone anywhere and still get calls?

Are the local ip phones configured with the public ip address of the system?

If so then you have what's called hairpining (or loopback). Some firewalls don't like that/can't handle it. This looks to be your issue from what the firewall guys are saying.

Why do the phones need to be setup like this? Do they take the phones offsite and then bring them back again?

Hi

The phones are configured with the public IP and only used remotely.

I know what you mean when you try to use a phone with a public IP on a your local LAN I have had that before when customers have brought there phone s back in to the office.

But these are just set up like you would expect a remote phone to be.

It almost sounds like the remote site uses the main site for it's internet connection, is there a vpn or something between the sites?

NO I have tried it on a few sites even taken it home and it's the same there also.

Here is a silly question. Do you have the public IP setup in both cards and have it all set to pri w/ public? Just covering all the bases here.

Hi

Yes that's all correct I have sent my DB to Samsung and they have checked it over and it all looks good, I am doing some Wireshark traces tomorrow to send to them.

I have ran into this issue before. Phone works at my office just fine, but when it got to the customers there was no audio. I know this sounds weird but I had to open ports on the remote side of the customers router. I would assign a static internal ip address on the phone and then have to open ports on the remote router to that IP address. Try walking a user through that in another state. For what its worth my problem was with comcast at the remote end.

I have nothing but problems with comcast and remote IP phones.

The behavior they don't like sounds normal.
have you got wireshark traces yet?

Yeah got the traces sent them to Samsung and they said what I already new that it's the firewall blocking the ports.
I'm not good with wireshark traces but I'm happy to share them.

There usually are ports that need to be opened (forwarded) on the firewall to allow audio & BLFs both ways. Every system is different, but your Samsung manual should have a list---or your Samsung support should be able to give those ports to you. On the system that we install, I have a list of ports that we forward (open). That usually takes care of it on the main end. On the far (remote ) end, you have to open up the ports on the Comcast router/firewall. Without both being done, you will have problems. Comcast does not do this for you.
It can be very frustrating for the first few times that you do these procedures. Hang in there.

It does not look like your port forwards are set up correctly for the remote IP phone.

6000 TCP and UDP should be forwarded to the processor. It looks like you only have UDP.

9000 and 9001 should not be port forwarded. Those are the ports that the phone will source from.

Also, you should not start your audio for the SVMI on an odd number. Odd number is for RTSP. Even number is for RTP.

Assuming the following:

MP20 = 10.16.149.3
OAS = 10.16.149.4
SVMI 20i = 10.16.149.5

TCP/UDP 6000 Port Forward to 10.16.149.3
UDP 30,000 - 30,031 Port Forward to 10.16.149.4
UDP 30,032 - 30,071 Port Forward to 10.16.149.5 (Assuming 20 ports of VM licensed)

Be sure to log into system and set your RTP start port to 30,032 for your SVMI and 30000 for your OAS card.

Remove the UDP 9000 and 9001 rule.

If you want remote access via DM to system:
TCP 5090-5091, 50021 should be pointed to 10.16.149.3

If you want remote acces to SVMI 20i
TCP 6001,6002, 21, 60024 should be forwarded to 10.16.149.5

Port 21 is a bit trickey because both the SVMI and OS use it for file transfer.
In DM, you can change this port for the OS when you create your connection. Change it to 50021
In your firewall, you would port-map it back to 21 before it gets to the OS.

Hope this helps.

Terrell
My Youtube Channel https://www.youtube.com/terrellboyer

I've had a customer with remote ip handsets in the Philippines, who were having intermittent speech issues.

I had a handset on my desk connected which worked flawlessly, even put 1 in another staff members house which worked ok.

Turns out SIP ALG can interfere with no sip calls, it must pickup the RTP stream and assume it's a sip call.

Check that there is no ALG enabled.

Hello

Finally Got to the bottom of this so I thought I would let you know!
We knew it was the firewall causing the issues but didn't know why, the problem was the outbound rules set in the firewall it was sending the wrong ports back instead of the normal RTP 30000 range it was sending back ports 35000 RTPS ports.
I need to confirm what the firewall guy did but I think it was just have one outbound rule for the OAS card and no outbound rule for the mp20 and svmi.

Thanks for your help and comment with this:)