Finite Technologies Incorporated FAQ System - The five questions posted most recently:

IAX Trunking with jitter buffer

Thu, 30 Jul 2009 23:59:54 GMT

The following are notes on configuring the jitter buffer for IAX on IBeX and Asterisk.

1) The new jitterbuffer:
------------------------
You must add "jitterbuffer=yes" to either the [general] part of
iax.conf, or to a peer or a user. (just like the old jitterbuffer).
Also, you can set "maxjitterbuffer=n", which puts a hard-limit on the size of the
jitterbuffer of "n milliseconds". It is not necessary to have the new jitterbuffer
on both sides of a call; it works on the receive side only.

2) PLC:
-------
The new jitterbuffer detects packet loss. PLC is done to try to recreate these
lost packets in the codec decoding stage, as the encoded audio is translated to slinear.
PLC is also used to mask jitterbuffer growth.

This facility is enabled by default in iLBC and speex, as it has no additional cost.
This facility can be enabled in adpcm, alaw, g726, gsm, lpc10, and ulaw by setting
genericplc => true in the [plc] section of codecs.conf.

3) Trunktimestamps:
-------------------
To use this, both sides must be using Asterisk v1.1dev (or coming 1.2 stable).
Setting "trunktimestamps=yes" in iax.conf will cause your box to send 16-bit timestamps
for each trunked frame inside of a trunk frame. This will enable you to use jitterbuffer
for an IAX2 trunk, something that was not possible in the old architecture.

The other side must also support this functionality, or else, well, bad things will happen.
If you don't use trunktimestamps, there's lots of ways the jitterbuffer can get confused because
timestamps aren't necessarily sent through the trunk correctly.

4) Communication with Asterisk v1.0.x systems
---------------------------------------------
You can set up communication with v1.0.x systems with the new jitterbuffer, but
you can't use trunks with trunktimestamps in this communication.

If you are connecting to an Asterisk server with earlier versions of the software (1.0.x),
do not enable both jitterbuffer and trunking for the involved peers/users
in order to be able to communicate. Earlier systems will not support trunktimestamps.

You may also compile chan_iax2.c without the new jitterbuffer, enabling the old
backwards compatible architecture. Look in the source code for instructions.

5) Testing and monitoring:
--------------------------
You can test the effectiveness of PLC and the new jitterbuffer's detection of loss by using
the new CLI command "iax2 test losspct ". This will simulate n percent packet loss
coming _in_ to chan_iax2. You should find that with PLC and the new JB, 10 percent packet
loss should lead to just a tiny amount of distortion, while without PLC, it would lead to
silent gaps in your audio.

"iax2 show netstats" shows you statistics for each iax2 call you have up.
The columns are "RTT" which is the round-trip time for the last PING, and then a bunch of s
tats for both the local side (what you're receiving), and the remote side (what the other
end is telling us they are seeing). The remote stats may not be complete if the remote
end isn't using the new jitterbuffer.

The stats shown are:
* Jit: The jitter we have measured (milliseconds)
* Del: The maximum delay imposed by the jitterbuffer (milliseconds)
* Lost: The number of packets we've detected as lost.
* %: The percentage of packets we've detected as lost recently.
* Drop: The number of packets we've purposely dropped (to lower latency).
* OOO: The number of packets we've received out-of-order
* Kpkts: The number of packets we've received / 1000.

Trouble Shooting
==================

There's a couple of things that can make calls sound bad using the jitterbuffer:

1) The JB and PLC can make your calls sound better, but they can't fix everything.
If you lost 10 frames in a row, it can't possibly fix that. It really can't help much
more than one or two consecutive frames.

2) Bad timestamps: If whatever is generating timestamps to be sent to you generates
nonsensical timestamps, it can confuse the jitterbuffer. In particular, discontinuities
in timestamps will really upset it: Things like timestamps sequences which go 0, 20, 40,
60, 80, 34000, 34020, 34040, 34060... It's going to think you've got about 34 seconds
of jitter in this case, etc..
The right solution to this is to find out what's causing the sender to send us such nonsense,
and fix that. But we should also figure out how to make the receiver more robust in
cases like this.

chan_iax2 will actually help fix this a bit if it's more than 3 seconds or so, but at
some point we should try to think of a better way to detect this kind of thing and resynchronize.

Different clock rates are handled very gracefully though; it will actually deal with a
sender sending 20% faster or slower than you expect just fine.

3) Really strange network delays: If your network "pauses" for like 5 seconds, and then
when it restarts, you are sent some packets that are 5 seconds old, we are going to see
that as a lot of jitter. We already throw away up to the worst 20 frames like this,
though, and the "maxjitterbuffer" parameter should put a limit on what we do in this case.

How do I stop and start IBeX from the command line

Fri, 20 Jun 2008 01:38:21 GMT

The first and most important thing to know is that you should not be stopping and starting IBeX from the command line.

If there is no other choice then you can start and stop the call processing engine and all related processes as follows:

Stop:

At the command line with appropriate permissions type:

/etc/init.d/ibex stop

Start:

At the command line with appropriate permissions type:

/etc/init.d/ibex start

Notes:

Do not stop any of the procsses with the kill command unless you contact our support first.
Do not start Asterisk with the command asterisk -vc or any variation of this command. This will cause no end of problems for you.

What is the default CDR format?

Wed, 18 Apr 2007 07:34:09 GMT

IBeX creates a CDR (Call Detail Record) for every call placed in the system. The record are stored in a comma delimited record of one record per line. Each comma delimited value is enclosed in quotes.

The fields for the record are as follows:

Accountcode: What account number to use: account, (string, 20 characters)
Src: Caller*ID number (string, 80 characters)
Dst: Destination extension (string, 80 characters)
Context: Destination context (string, 80 characters)
Clid: Caller*ID with text (80 characters)
Channel: Channel used (80 characters)
Dstchannel: Destination channel if appropriate (80 characters)
Lastapp: Last application if appropriate (80 characters)
Lastdata: Last application data (arguments) (80 characters)
Start: Start of call (date/time)
Answer: Anwer of call (date/time)
End: End of call (date/time)
Duration: Total time in system, in seconds (integer), from dial to hangup
Billsec: Total time call is up, in seconds (integer), from answer to hangup
Disposition: What happened to the call: ANSWERED, NO ANSWER, BUSY, FAILED
(on some CDR backends, e.g. ODBC, these may be integers; note that more detailed
info can be found in the dialplan variable $HANGUPCAUSE)
Amaflags: What flags to use: see amaflags: DOCUMENTATION, BILLING, IGNORE
etc, specified on a per channel basis like accountcode.
User field: A user-defined field, maximum 255 characters

Important note on transfers:

If you are trying to collect records on IAX to IAX calls you need to be aware that by default, IAX will attempt to transfer calls in this situation (if DTMF is not required). When the transfer is completed the call is dumped from the middle machine and thus the call detail records will report a short call time.

If you want detailed records you must turn off IAX transfer, but unless your servers are very close together, you will definitely get a latency hit from doing so.

Sample CDR:

"","6101","5551111","default","""John Jones"" <6101>","SIP/6101-c698","Zap/3-1","Dial","Zap/R1/5551111","2006-02-26    13:50:58","2006-02-6 13:51:01","2006-02-26 14:15:07",1449,1446,"ANSWERED","DOCUMENTATION"

"","6101","5551112","default","""John Jones"" <6101>","SIP/6101-545c","Zap/2-1","Dial","Zap/R1/5551112","2006-02-26    14:15:38","2006-02-26 14:15:42","2006-02-26 14:16:11",33,29,"ANSWERED","DOCUMENTATION"

IBeX's ICM provides tools for converting IBeX CDR's to just about any format.�� They can be found in the "Billing Options" module and can be managed from the Logfile Management module.

Where can I find weather files for FTIDOE?

Mon, 19 Feb 2007 12:22:10 GMT

Weather File for the United States and a limited set of locations outside the US can be found in our Weather File Library.

For locations not listed in the Weather File Library please refer to the FAQ note regarding locations outside the US.

Where can I find weather files that are not located in the Weather File Library?

Mon, 19 Feb 2007 12:19:41 GMT

Weather files that we can redistribute without any license restrictions can be found in our Weather File Library.

Weather files for locations outside the US can be found on a CD published by ASHRAE. This CD contains IWEC files that will provide weather files to meet the needs of most locations in the world. IWEC files can't be directly compiled by FTIDOE but our Weather File Library provides a Perl script to convert the IWEC files to TMY2.

The CD from ASHRAE (http://www.ashrae.org) is: International Weather for Energy Calculations 1.1 (IWEC Weather Files). The item number is RP-1015. This material is copyrighted by ASHRAE so we can't distribute these files. Please contact ASHRAE to order this CD. If you have any problem converting these files please open a ticket on our Help Desk and we will be happy to assist you.