SIP Clients



There is a trend to go Java (to support platform independence) that IMO is disappointing. Not that java is inherently a bad language, but the culture around it tends to grab binary bits with out the source and just run with it - a source of bugs and security issues. This cultural issue is also what keeps a lot of java applications out of Debian (they can't find the original source).

SIP Clients - Soft-Phones

Ekiga

SIP over wifi

Wifi and sip don't exactly like each other. The problem people get is stuttering. It is the old bit where it is easy to confuse the difference between speed and latency. If you look at the through-put - wifi appears like it should work, but there are cases where packets can be delayed - and if part of an audio stream, either you get excessive latency from buffering or it misses a time slot and stutters.

Now if you were watching a video - no problem ( it is if you need to mix video inputs) - just delay the playback via a big buffer - but phone conversations are sort-of realtime.

So this is why there is a market for a substitute and what I've heard is that Siemens- Gigaset ( DECT ) phones are a good substitute for wifi.

This is looking like it would block using a softphone via wifi. I've wondered if some of the low data rate codex would make it sort of work? Once I get the rest of freeswitch working I will be building a updated linphone ( the stable version in Debian has problems) to test with. My hunch is that the low data rate won't fix the problem with maximum delay of packets. (Could be a function of the wifi ccess-point - and how many are sharing it).

See myth 16 here http://www.cisco.com/en/US/prod/collateral/wireless/ps9391/ps9393/ps9394/prod_white_paper0900aecd807395a9.html

A bit more about latency. Landlines use data paths like in T1 bits where every call channel has a place waiting for the next bit of data - ( 8 bit words where they steal a bit for signaling - thus 56kbits instead of 64kbit.) Every frame of the T1 data has a place reserved for your phone conversation - no sharing (at least at this level).

Land-line latency was so short no one noticed or even talked about it. Enter cell phones. Bad nasty latency - I measured up to 500ms (anything over 50ms bugs me)( plug a mike into a storage oscilloscope and have the cell phone call your land-line on speaker phone - clap - measure the time between the clap and the clap coming out of the speakerphone.).

This is bad. In WWII the Nazi's used wire recorders to insert latency and found that if the latency was bad enough - people would get mad at each other for interrupting. ( I suppose the latency introduced with cell phones is why everyone started hating each other.)..

Now introduce wifi. The lovely folks in government did not want it to work. It potentially competed with services that people paid for and those providers provided bribes^h^h^h^h^h^h investment opportunities (The type the little guy never sees) to the ruling elite to be sure it would die. So after stalling they came up with a plan - put wifi on top of the frequency u-wave ovens use - lots of interference and they are tuned for water absorption so the range should be limited - and specify a very low amount of power - limit the spectrum.

BUT! - EEs are a stubborn bunch - they took what the FCC gave them and made it work anyway.

But, it sort of sucks. The kluges that resend missed packets and the like induce latency all over the place.

Part of the problem is the SIP protocol overhead - could be IAX would make it work a bit better?, but right now we live in a SIP world. I've not been able to find any numbers on IAX vs SIP over wifi - I bet it still has problems.


Top Page wiki Index

Disclaimer

This information may have errors; It is not permissible to be read by anyone who has ever met a lawyer.
Use is confined to Engineers with more than 370 course hours of electronic engineering for theoretical studies.
ph +1(785) 841-3089

Email inform@xtronics.com

(C) Copyright 1994-2017, Transtronics, Inc. All rights reserved
TranstronicsĀ® is a registered trademark of Transtronics, Inc.
All trademarks are the property of their respective owners.