dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
11
share rss forum feed


espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2

1 edit
reply to Transmaster

Re: I have a friend who is a Electronic Engineer.....

How do you use TCP resets to close a UDP-based RTP stream?

Edit: I noticed you said Skype conference mode, which isn't really VoIP, in the same way that TeamSpeak isn't technically VoIP.


funchords
Hello
Premium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6

1 edit

1 recommendation

said by espaeth:
Edit: I noticed you said Skype conference mode, which isn't really VoIP, in the same way that TeamSpeak isn't technically VoIP.
Can you say more about that? They both sound like fine VOIP examples.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
FCC Public Hearing on the Future of the Internet - Thursday, April 17th - Stanford Univ., Calif.


espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2
said by funchords:

Can you say more about that? They both sound like fine VOIP examples.
To be a truly interactive VoIP stream it needs to be UDP-based because timing is more critical than complete delivery. I believe everyone is familiar with the delay that cell phones introduce into a conversation -- if you don't mentally account for that delay it is very easy to step over each other when the listener/speaker roles change on the phone. In standard VoIP services today that are based on UDP RTP streams you have moments where audio cuts out from packet loss, but that audio is flat out gone. (just like an interruption in cell phone coverage) Some audio codecs (ie, G729) will attempt to "guess" what the missing data contained and fill in the gap resulting in that mechanical/robotic sound that people have described with VoIP. In either case, there is no attempt to recover the packet; the goal is keeping the stream timing in tact.

Each VoIP call is actually comprised two independent audio streams. If you were to build this connection using TCP sessions and packets were lost the audio would sound like a stuttering CD -- you'd hear everything transmitted but you would gain duration in the form of silence while the packets are retransmitted in the background. Not only does TCP have more overhead, but over time the two audio streams tend to become so desynchronized from each other that two-way communication is impossible. If only one of the two streams gets drops it's especially bad, but even if both sessions take drops the random retry function is enough to introduce noticeable offsets.

My dealing with VoIP is in the enterprise setting with SCCP/SIP/H323 call control and G711 or G729 RTP streams so that's where my knowledge mainly lies, but I haven't come across a serious implementation for voice that uses TCP sessions. The only instances I've seen were closer to the Nextel walkie-like service (where the time delay is already assumed), which I don't consider to be a true VoIP service.


en102
Canadian, eh?

join:2001-01-26
Valencia, CA
I've had VERY good luck using Skypeout with a bluetooth headset for teleconference calls. I have a 3Mbps/512kbps DSL line and it works VERY well 99% of the time.
The few times that I have issues are typically from heavy bandwidth use spikes (download/upload) or CPU spikes.
I've even had a session work decently when tunneled over SSH to a and connection sent through web squid proxy server.
Lastly, I had a VPN tunnel then port forwarded through an SSH session to a squid proxy server, and it STILL worked (many hickups though... due to VPN performance).
--
Canada = Hollywood North


funchords
Hello
Premium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6
reply to espaeth
Lol, I've actually heard that on some earlier codec stuff I worked on .... Ma-ma-ma-ma-ma-max Head-d-d--d-droom!