Hi Duane,

We all agree that this this small systems are having their limitations
(no doubt here).

With respect to voicemail, I would like to add that there are systems
equipped with USB ports and you can plug a flash stick or a HD there.
Voicemail is stored there, so there's no RAM limitation or just
voicemail to e-mail.

On the other hand, just out of curiosity, I tried the speex codec
using the X Lite SIP client.  I was quite impressed.
The delay was barely perceptible.  The fact that asterisk reports
400ms/30ms for 1s of input data doesn't mean that you will have a
400ms delay, because asterisk will not transcode 1s chunks of data at
once.
For a 20ms packetization you should expect a delay of 8ms introduced
by g711 to speex transcoding and less then 1ms for speex to g711
transcoding.


Here's the vmstat output during the call:
$ vmstat 2
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  1      0   5288   1728  13624    0    0     0     0 2115  214 55  0 45  0
 0  1      0   5288   1728  13624    0    0     0     0 2112  272 64  3 33  0
 0  1      0   5288   1728  13624    0    0     0     0 2111  232 57  3 39  0
 0  1      0   5288   1728  13624    0    0     0     0 2120  260 59  2 39  0
 0  1      0   5288   1728  13624    0    0     0     0 2122  296 65  3 33  0
 0  1      0   5288   1728  13624    0    0     0     0 2110  222 56  0 43  0
 0  1      0   5288   1728  13624    0    0     0     0 2115  246 59  4 37  0
 0  1      0   5288   1728  13624    0    0     0     0 2117  268 65  2 33  0
 0  1      0   5288   1728  13624    0    0     0     0 2111  218 49  3 48  0
 0  1      0   5288   1728  13624    0    0     0     0 2127  263 63  2 35  0

CLI> sip show channels
192.168.2.12     phone_spa3  3a0c2b2c0f2  00102/00000  ulaw  No
Tx: ACK
192.168.2.10     2110103     OTdmNWQ0Mzh  00101/00001  spee  No
Rx: ACK


Obviously, at 30-40% idle cpu you can have only one single call doing
speex transcoding.



In the end, it all comes to setting the right expectations from this
little systems and tune/set them properly according to your needs.




Regards,
Ovidiu Sas

On 10/27/07, Duane <[EMAIL PROTECTED]> wrote:
> Chris Chen wrote:
> > I have four friends all running Asterisk 1.4 on Linksys WRTSL54GS, running
> > voicemail, vbuzzer inbound/outbound, voipstunt outbound, voicemail to email,
> > follow me, gtalk integration, with features such as call transfer, call
> > pickup, call parking, three way calling, call waiting, caller id, etc
> > working exceptionally fine for a home of 3-5 extensions, can easily handle
> > concurrent 5 calls in the production network with voice quality. For sure we
> > are not running g729, why should we for our home use?
>
> My comment about voice mail was more to do with the amount of ram
> available, while you might get away with vm to email, what happens when
> the net goes down and you are using an ATA device on a pstn line?
>
> To save an email I'll respond about the 400ms transcoding on speex,
> anything over 300ms RTT will start to incur noticeable delay, so wasting
> 400ms on transcoding as well as any other normal call delays could put
> you well over 500ms per call, that is assuming you don't happen to call
> someone doing something equally stupid.
>
> I can imagine it now...
>
> "Hey bud are you there? Over!"
> "Yea I got ya here good buddy! Over!"
>
> etc
>
> As for why you would want to use g729, perhaps because some codecs
> handle jitter and packet loss better then others?
>
> For everyone defending this practice good luck to you with your toys,
> embedded devices are nice and all, and I have a bunch of WRTs about the
> place, but as I said before they just can't do anything useful beyond
> simple call routing. Everything listed above I would consider simple
> call routing, virtually anything you don't need an AGI script for would
> pretty much be a simple routing function.
>
> Here is an example of what I'd consider a non-simple routing function.
> One of my providers gives me the choice of making timed calls via an
> override prefix or untimed calls. Timed calls for most routes I call are
> 1.6c per minute with per second billing and no connection fee, and the
> untimed calls for the same routes are 8c per call.
>
> With the above information it's easy to see that any calls under 5
> minutes would be better being sent with the override prefix, and any
> calls 5 minutes or longer would be better sending without the override
> prefix.
>
> So what I've done is setup my system to store all CDR information to
> MySQL, and then in the routing logic if no enum route can be found ;) it
> sends the call via an AGI script that does a database lookup and finds
> out the average call length for that route and passes it back to Asterisk.
>
> If the number hasn't been called before I simply guesstimate the average
> call length based on calls to the same area code, while this might seem
> far from perfect all I care about is long term averages because I have a
> few years worth of CDR records to smooth things out.
>
> This same provider now gives me the option of similar call costs to
> about 20 other countries, and I keep meaning to extend the AGI script to
> cover this as it wasn't an option before, although I'm still trying to
> find the time to convert from Asterisk to CallWeaver too.
>
> --
>
> Best regards,
>  Duane
>
> http://www.freeauth.org - Enterprise Two Factor Authentication
> http://www.nodedb.com - Think globally, network locally
> http://www.sydneywireless.com - Telecommunications Freedom
> http://e164.org - Because e164.arpa is a tax on VoIP
>
> "In the long run the pessimist may be proved right,
>     but the optimist has a better time on the trip."
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to