 TransmasterDon't Blame Me I Voted For Bill and Opus
join:2001-06-20
Cheyenne, WY
1 edit | I have a friend who is a Electronic Engineer.....
Like Comcast a Kumquat looks good on the outside but is bitter on the inside. |
--
Send a prayer to Allah, eat Beans. |
|
 espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2
1 edit | 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. |
|
 funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:5
1 edit | 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. |
|
espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2 Reviews:
 ·Clear Wireless
| 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. |
|
|
|
 en102Canadian, 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 |
|
funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:5 | 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! |
|
