ACN2005 Term Project Improve VoIP quality

Transcription

1 ACN2005 Term Project Improve VoIP quality By introducing TCP-Friendly protocol Burt C.F. Lien ( 連 矩 鋒 ) CSIE Department, National Taiwan University p93007@csie.ntu.edu.tw Abstract The most notorious of VoIP lies on its voice quality when unmanaged internet traffic bursts. Lost packets may result in uncomfortable or twisted voice in receiver side. Nonetheless, since most of VoIP traffic use RTP (Real-time Transport Protocol), which layered on top of UDP, it is the nature of a connectionless protocol that the sender sends as much as it can do without the knowledge of network congestion. In this work, I will present an aggressive, but simple, method to augment RTP protocol with knowledge of TCP-friendly by using its extension bit in the header. This can effectively improve the quality of VoIP traffic under network congestion and, in the meanwhile, maintain its compatibility with other non-tcp-friendly-aware VoIP traffic. Introduction It may sound good to make real time traffic adaptive to network congestion status. Nonetheless, speaking to VoIP, unlike video s variable bit rate codec standard, not all of communication peers have the ability to change to various bit rates (some might supports only G.729/20ms for example), thus lead to an interoperability concern. Within unmanaged networks, burst traffic would cause packet loss and subsequently impair the received voice quality because of not enough sampling data fro voice decoder. This would lead to a poor voice communication quality. A TCP-friendly mentioned here is a generic term which means a congestion-aware protocol other than unreliable UDP protocol. In this work, I will combine the advantage of voice decoder's linear interpolation and the TCP-friendly protocol, residing between RTP and UDP layer, to comfort this issue. The idea is not to slow down the transmission from RTP itself because VoIP is a real time traffic. Instead, it will slow down the transmission rate by dropping selected packets from its internal network sending queue (RTP queue).

2 Speaking to voice decoder, linear interpolation is the simplest and basic way to recover lost frames. It is the nature of interpolation method to achieve better prediction results if sampling data of the lost frame's close neighbors can be correctly received. So, if we intentionally to drop a single packet within a continuous voice stream, the accuracy of decoder s prediction may be improved significantly. <Figure 1: A distribution of controlled packet drops> <Figure 2: A distribution of uncontrolled packet drops> Based on above assumption, I will design an aggressive method to internally drop a packet (for ex: 1 out of 5 packets if the packet lost rate in the network is 20%) from the RTP sending queue autonomously upon receiving congestion signal from TCP-friendly protocol (the modified RTP extension). This implementation is to provide a relatively simple and useful method to improve VoIP quality while considering the interoperability with incumbent protocol stacks. VoIP Protocol Stacks Most of current VoIP protocol (voice parts) stacks look like the following diagram. Considering the interoperability with other ordinary VoIP protocol layers, we are not going add a new protocol layer here to complicate the problem. I propose to add a TCP-friendly mechanism inside the RTP header which will be detailed in next section.

3 Voice Data RTP UDP TCP-friendly protocol resides here IP <Data link> <Physical> RTP Extension The format of RTP Header is as following: Ver P X CC M PT Sequence Number Timestamp SSRC CSRC [0..15] ::: <X, Extension. 1 bit. If set, the fixed header is followed by exactly one header extension.> We can have an extra 32-bit word space if the X-bit is set. From the definition of RTP header, the X bit can be set to extend RTP for user-specific application or proprietary information. An extra 32-bits word is available when the X bit of the header is set. It is useful if we need to extend some field for congestion control, while considering the interoperability with other VoIP protocol stacks. TCP-friendly Implementation 1. Congestion Detection From RTP protocol definition, the real time data will be transmitted, tagged with a sequence number, which we can detect a lost packet once the sequence numbers discontinue. The proportion of lost packets in a specific period of time provides us the severity of network congestion. We can then launch or stop our underlying TCP-friendly protocol upon the information. 2. The packet lost rate Initial threshold of packet lost rate is defined as 2%, and increase by 2% scale, in this work. Once the lost rate exceeds the threshold, we begin our regulation by sending a congestion information to opposite peer while communication. Lost rate

4 larger than 30% is not consider here because the voice quality may be out of control. VoIP application itself should disconnect the call via RTCP (Real Time Control Protocol) BYE command. 3. Additive increase and decrease When packet lost rate achieve 2% in the network, the mechanism will be launched and drop specific packets from its outgoing queue. Assume PLR is the packet lost rate in the network, the following algorithm is implemented to deal with packets in the RTP outgoing queue: IF PLR>=2 IF ( SequenceNumber % 100 == PLR ) DropThePacket; ELSE SendThePacketAsUsual ENDIF 4. Recovery Once PLR (packet lost rate) is less than 2, the RTP traffic regulation will be disabled. 5. Protocol Implementation: I define the RTP extension 32-bit data as following: <protocol initials> <hd> <severity of congestion> Protocol Initials (16 bits): Pad with 16 continuous 0 as RTP extension initial recognition. Protocol Header (3 bits): Fixed with 101 (binary) as the protocol header that each TCP-friendly protocol designed here can recognize each other. Severity of Congestion (13bits): A 13-bit long unsigned integer, which represents the detected lost rate in receiver side. Receiver side algorithm: Receiver side maintains a sliding window which records the packet lost rate (PLR) during a specific period as time goes by (for ex: 30 seconds). IF PLR>=2 Set RTP header X-bit to be 1 Extension word = <PLR value>

5 (13 bit long) ELSE DoNothing Sender side algorithm: When sender side receives RTP packets with X-bit set to 1, it parses the extension word. Upon detecting the TCP-friendly header 101, it reads the value of PLR and starts outgoing queue regulation process. IF PLR>=2 IF ( SequenceNumber % 100 == PLR ) DropThePacket; ELSE DoNothing (SendThePacketAsUsual) ENDIF Software tools: The TCP-friendly protocol introduced here will be implemented on open RTP (ortp ) protocol stack and Windows UDP/IP stacks. We choose G.711/20ms (64Kbps for the voice payload) as the only voice codec in this test ( Speex : a free codec ). Experimentation Test configuration is as following: ( the rectangular represent VoIP a communication peer; the circular represent a network in the experiment) A caller Bandwidth Simulator < test set A> B callee C caller Bandwidth Simulator D callee < test set B > Bandwidth simulator is in charge of simulating various network bandwidths during the experiments. Considering the overhead of other protocol headers beside voice payload itself, the minimum bandwidth to accommodate a clear G.711/20ms VoIP call should be:

6 160bytes(voice payload) + 16bytes(RTP) + 4 bytes (RTP extension) + 8bytes(UDP) + 20bytes(IP) + 21bytes(MAC) = 229bytes/20ms = 91.6kbps Having the bandwidth information, we then configure 4 types of bandwidth in bandwidth simulator, 100kbps/ 80kbps/ 60kbps/ 40kbps respectively for both test set A and B. We hope to know the impact of VoIP voice quality when bandwidth falls underneath the minimum bandwidth threshold and the effectiveness of our proposed TCP-friendly protocol. I plan to conduct a human perceptive experiment to verify the effectiveness of this work. Two sets of VoIP equipments (A and B) will be set up for tests, set A with normal VoIP feature, and set B is equipped with TCP-friendly protocol that we design in the work. 20 persons (10men+10women), without the knowledge of the difference, will be choosed to judge the voice and vote for the best quality among these 2 sets. Results: U1~U10: men; U11~U20: women. Set A (normal), and set B (TCP-friendly aware) are provided: User U1 U2 U3 U4 U5 U6 U7 U8 U9 U User U11 U12 U13 U14 U15 U16 U17 U18 U19 U < Test results 1). 100kbps, 2). 80kbps, 3). 60kbps, 4). 40kbps > Future Work For not having enough time, the implementation in work has not yet been down. If I have a similar project or course in next semester, I will try to finish the mechanism mentioned in this work, and have the above mentioned human perception experiments. Summary The mechanism used in this work can effectively mitigate network congestion by dropping certain packets before sending (narrowing down the consuming bandwidth). Nonetheless, just like the back-off mechanism, misbehaved users may eat more bandwidth than those well-behaved guys, and we currently have no solution for punishing those misbehaving.

7 Therefore, the TCP-friendly protocol proposed here should be promoted widely to gain the largest benefits. Reference [1] TCP-friendly transmission of voice over IP Beritelli, F.; Ruggeri, G.; Schembra, G.; Communications, ICC IEEE International Conference on Volume 2, 28 April-2 May 2002 Page(s): vol.2 [2] Real-time Internet video using error resilient scalable compression and TCP-friendly transport protocol Wai-Tian Tan; Zakhor, A.; Multimedia, IEEE Transactions on Volume 1, Issue 2, June 1999 Page(s): [3] Time-lined TCP for the TCP-friendly delivery of streaming media Mukherjee, B.; Brecht, T.; Network Protocols, Proceedings International Conference on Nov Page(s): [4] MPEG-TFRCP: video transfer with TCP-friendly rate control protocol Miyabayashi, M.; Wakamiya, N.; Murata, M.; Miyahara, H.; Communications, ICC IEEE International Conference on Volume 1, June 2001 Page(s): vol.1 [5] A quality-adaptive TCP-friendly architecture for real-time streams in the Internet Sahu, D.; Ghosh, D.; Chakrabarti, I.; Communications, APCC The 9th Asia-Pacific Conference on Volume 1, Sept Page(s):71-75 Vol.1 [6] An empirical study of real audio traffic Mena, A.; Heidemann, J.; INFOCOM Nineteenth Annual Joint Conference of the IEEE Computer and communications Societies. Proceedings. IEEE Volume 1, March 2000 Page(s): vol.1 [7] Resource allocation for audio and video streaming over the Internet Qian Zhang; Ya-Qin Zhang; Wenwu Zhu; Circuits and Systems, Proceedings. ISCAS 2000 Geneva. The 2000 IEEE International Symposium on Volume 4, May 2000 Page(s):21-24 vol.4