VoIP over internet?
the few last days I've been trying to determine the benefit of using VoIP between to sites over the internet. I thought you might be interested by the little annalysis I conducted and the conclusion.
I know this is more a network discussion than a security discussion but I felt that AO members could be interested in it.
If you get bored reading that tut & think it is useless into AO, tell me I'll remove it
The idea was to compare 2 alternatives solutions:
- end to end IP connection
- VoIP connection via phone network
IPphone(site 1) to ISDN gateway --- circuit switching(phone/ISDN network) ----- ISDN gateway to IPhone(Site 2)
1- Secured communications.
The only way I know to fully protect VoIP communications against a man in the middle (e.g. using VOMIT) is to encrypted data thanks to IPsec. (I didn't heard of H323/SIP encryption application but I am sure it is coming).
The problem of such architecture is that communications to the outer world analog/isdn phones required a VoIP gateway located before the IPsec box otherwise, the gateway will see encrypted data and won't be able to route the circuit connection.
IPsec boxes are quite costly and therefore it will be cost effective to share the box for IP data and VoIP this induces a security risk because that's mean that VoIP traffic and data are not physically or virtually(802.1q) separated. Attacks on VoIP gateway through circuit network are not evaluated ( it is a knowledge blackhole) and could represent a real threat.
But maybe am I paranoid.
VoIP to circuit between site: :
No needs of IPsec, VoIP traffic may have a dedicated VLAN. The threat is mitigated!
Commonly optimized VoIP coms are based on G723 standard: 20 bytes for a sampling rate of 30ms => 5.3kb/s
These samples are encapsulated within the following stacks:
- RTP header => 12 bytes
- UDP header => 8 bytes
- IP header =>20 bytes
- IPsec encapsulation (tunnel mode):
- ESP =>10 bytes
- !!! most connections to ISP are through PPPconnection compressing the IP header
compressed IP header => 0 bytes (addresses are included in ppp header)
- PPP (flag+address+frame control+FCS) =>8 bytes
All of this represent a frame of 78 bytes each 30 ms => 20.8 kb/s for one communication.
The needs required in term of telecom between 21 sites is described as "erlang" unit. e.g. 10 erlang means that anytime the system 10 simultaneous communications. (if there is hundred user in your site they won't all phone in the same time to the remote site!!!)
For a need of 30 Erlang you will require 624 kb/s of throughput.
3- Multiplexing Data & VoIP: gigue
A- The idea here is that VoIP and data shares the same media (the link between the ISP and the private net), even if a VLAN/VRF is dedicated to VoIP. When a frame is sent on the physical layer the next one will have to wait to be transmitted.
Because G723 has a sampling rate of 30 ms a gigue greater that 30 ms will highly perturbed the quality of the communication. To avoid that gigue the MTU for IP data must be well configured:
Link speed MTU gigue
64 Kb/s 240 30 ms
128 Kb/s 480 30 ms
256 Kb/ 960 30 ms
I read somewhere that MTU cannot be less that 512 bytes => therefore VoIP for low bandwidth throughput is not doable if the ISP link is not dedicated to VoIP.
This means that a home user (using mobile IP for instance to connect the enterprise network) may not use VoIP on his PC.
B- QoS: Before the transmission on the physical layer frames needs to be queued in access routers buffers. QoS (also called CAR) prioritize traffic in function of the type of IP traffic it is (VoIP, SMTP, FTP,...). But ISP are still not implementing this techno. Therefore your VoIP "mice" traffic may compete against FTP "elephant" traffic generated by anybidy on the net. This will induce huge delays & gigue.
In my opinion VoIP is a good inside enterprise solution for cabling cost saving but I doubt that it match for internet end users or end2end sites. I'd rather use VoIP T2 gateways to reach the outside world or a remote site
Nice post...Although I don't think I would classify this as a tutorial. It seems to me more like a position paper. (like you are trying to prove a point). All I am saying is that perhaps it would be better suited for a different forum.
The key here and the main problem with the concept of VoIP over the Internet is the QOS factor. There is not currently, nor will there be any time soon (if ever) a way to give certain types of traffic priority over others through the Internet. After all, who's to make the decision that your VoIP traffic should have a higher priority than my FTP traffic (just an example)