Voice transmission over TCP/RTMP
In fact, Adobe Flash Player uses TCP protocol for voice and video transmission. RTMP wraps TCP.
TCP is reliable protocol. It means, TCP packets requires acknowledgement in contrast to the UDP.
Packets may be lost in any networks, but TCP is more sensitive to losses, when we talk about voice transmission.
Consider a network with 2% loss rate and 100ms RTT, where RTT is a round trip time. You can get this value by ping command.
Suppose we have 1 minute voice conversation.
Default voice rate is 50 audio packets per second. So we have 50*60=3000 audio packets in one direction Flash to SIP endpoint.
In this case we have 0.02*3000=60 tcp packets dropped. But tcp is reliable protocol. It means, every dropped packet will be sent again,
and all older packets will be sent after this packet. This introduces additional delay, which equals approximately RTT value.
So, we got 100ms*60=6000ms=6 seconds additional delay for 1 minute conversation, using TCP.
6 seconds delay is unacceptable and we should drop additional packets to adjust delay to acceptable values.
So, if we have requirements 1 second delay maximum, we should drop packets for 6000-1000=5000ms in summ.
Every voice packet has 20ms size, therefore we should drop 5000ms/20ms=250 packets in 1 minute. It will introduce 250/3000 = 8.3% loss rate.
Thus, we have such equation, which reflects dependence of voice quality from the network characteristics:
K = (RTT/ptime)* loss_rate
Here:
K - is a real voice loss rate in percent with minimal latency
RTT - round trip time
ptime - time of playing one voice packet(20ms by default)
loss_rate - loss TCP packet rate in percents
Opposite example:
In our example above K = 2*(100/20) = 10% = 300 dropped packets of 3000.
Thus, if we do not introduce additional latency, we have 10% dropped voice packets. This value is unacceptable for voice communication.
Suppose, acceptable value is about 2% = 60 dropped packets from 3000.
So, we should drop 60 packets and introduce latency for remained 300-60=240 packets. This introduce additional delay: 240*20=4800ms
Resume:
We use unacceptable network for transmission voice over TCP(RTMP). What network is acceptable in this case?
Voice quality is good, if drop rate less than 1% and one way delay less then 500ms.
Thus, we have system of equations and inequalities:
- K = (RTT/ptime)* loss_rate
- K = acceptable_drop_percent + (acceptable_delay/ptime/total_packets)*100
- ptime = 20*
- acceptable_delay < 500ms
- acceptable_drop_percent < 1
Value (acceptable_delay/ptime/total_packets)*100 tends to zero, if total_packets grow.
So, we have new inequality for long communication (greater then 10 minutes):
(RTT/ptime)* loss_rate < acceptable_drop_percent, when total_packets grow.
So, we got a graph of acceptable network. Your network characteristics should be lower than the curve.
For example (loss_rate, RTT) should have values (0.5, 20), (0.25, 40), (0.1,60), (1.5,10), e.t.c. See green area.
Thus, the best decision is to locate Flashphoner server in a collocation, which gives zero loss packets rate for your end user.
This rule is applicable for UDP traffic also, but for TCP(RTMP) traffic this requirement is very important.
How to measure RTT and packet loss properly?
Flashphoner uses audio packet sizes about 96 bytes over TCP(RTMP).
As described above, default packet rate is 50 packets per second. You can simulate this packets by ping command to check your network:
$ping -l 96 -n 1500 127.0.0.0
where ping - is a Windows command, 127.0.0.0 - pinged host.
This measuring should be done during normal load of network.
Example of statistics:
Ping statistics for 168.144.196.170:
Packets: Sent = 170, Received = 170, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 199ms, Maximum = 257ms, Average = 202ms
Ping statistics for 168.144.196.170:
Packets: Sent = 170, Received = 170, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 99ms, Maximum = 157ms, Average = 102ms
RTT = Average = 102ms
loss_rate= (170-170)/170=0%