I am doing some testing with our SIP provider. I have OXE PBX on public IP connected to the internet.
The case that I am trying is the following:
I want to put a few (for example 5) IPTouch sets to one private network with ADSL access to the internet (in this network is a router with FW). I want these IP phones to route over the internet (without the VPN) to the PBX.
The results of our analysis are the following:
In case of one IP Touch set in private network, the set connects to PBX correctly. With the correct UDP port forwarding the set is working OK. The port 32512 is used for the registration and UDP port 32514 is used for the voice to private IP of the IP Touch set. (port forwarding is done on the firewall)
In case of two IP Touch sets in private network, we run into problems. The problem is, that the UDP communication is not started by the IP Touch set (which is behind the NAT router), but the Call Server (IP: 18.104.22.168), which is in fact in front of the FireWall. In this case it is clear, that the FireWall blocks all that traffic.
In the attached file private_net_2xIPtouch.pcap, you can see, that the communication is always started by the CPU Call Server (TFTP1). In this case, we always have the same destination port 32512 – even if we have two or more IP Touch sets in the private network. With the port forwarding in this case, we can only manage to route the trafic to only one IP Touch set.
In the second attachment graf_private_2sets.doc, you can see the traffic flow, where the UDP packet comes from the Call Server (CPU) and is correctly accepted by one IP Touch set with IP 192.168.10.55 (because of the port forwarding). The other IP Touch set in the same private network (IP 192.168.10.53) does not get the UDP packet.
In theory, the solution could be the following:
The request for the UDP or the registration or whatever communication in the private network should always come from the same private network, which means that the IP Touch set should send that kind of request. In that case, the correct ports could be opened and the session could stop correctly. In case that the request comes from the external network, the traffic is allways blocked.
If we could not reach that logic, then the only solution is, that the Call Server (CPU), which starts the communication, is sending the UDP packets to port 32512+1 and UDP 32514+1 for the voice, so that the destination ports are not always the same. In this case, the correct administration of the routers is needed.
Does anyone have any experiance about that? Did anyone try that kind of case?
I would really appreciate if anyone could give me any advice or the suggestion about that.
I am looking forward to hearing from you,
You do not have the required permissions to view the files attached to this post.