ASTERISK-02818: [patch] libiax2 updates: CNG, MSVC, XFER, ALIGN, codecs, misc

[Home]

Summary: ASTERISK-02818: [patch] libiax2 updates: CNG, MSVC, XFER, ALIGN, codecs, misc

Reporter: stevekstevek (stevekstevek) Labels:

Date Opened: 2004-11-15 15:28:35.000-0600 Date Closed: 2004-12-06 18:00:14.000-0600

Priority: Major Regression? No

Status: Closed/Complete Components: Core/General

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) libiax2.diff
( 1) libiax2-2.diff

Description: This is a combined patch for several libiax2 updates.

These come from:
Stephen Uhler (Alignment)
Bill Doll, Jr: (MSVC, XFER)
Myself (CNG, codecs, and misc fixups)

All three contributors claim to have disclaimers on file.

This patch does the following:

1) Adds support necessary for codec negotiation
2) Adds support for alignment-needing architectures
3) Adds support for Solaris in particular
4) Adds support for attended transfer
5) Adds support for Microsoft Visual C++
6) Adds CNG frame generation support

There is also some code in here, unused, for voice timestamp prediction. I am planning on reworking this, and the jitterbuffer in general, in the coming months. I definately wanted to submit these changes now before beginning that work, which will require extensive changes.

Complete history can be found via iaxclient-cvs on sourceforge. This code has been in production for several weeks by the various users of iaxclient (iaxcomm, iaxphone, DIAX), as well as by Bill Doll's application..

Here is a changelog from our CVS repository. Sorry about the awkward wrapping as I paste this in, and also note that we're presently _not_ using any of Stephan Kauss' code for alignment, so a disclaimer from him is not necessary.

2004-11-08 12:56 stevek

* iax-client.h: Declare things, and other odds and ends to
eliminate a half-dozen warnings.

2004-10-29 21:51 stevek

* iax.c, iax2-parser.c: Fix for crash on transfer from Bill Doll --
the alignment patch here was incorrect. (we were just assigning
a pointer here, but the pointer may be to unaligned data, so we
need to check on that..).

2004-10-27 11:53 stevek

* frame.h, iax-client.h, iax.c: Add CNG frame sending support:

iaxclient will now send a single CNG (with a hard-coded and
rather arbitrary level), whenever it detects the end of a speech
fragment.

This can aid recipients in determining the difference between
lost voice frames, and actual silence.

2004-10-22 11:40 stevek

* iax-client.h, iax.c, iax2-parser.c: Changes from
bdolljr@bigskytech.com

MVVC portability changes (finally, a simple clean solution for
MSVC zero-length array annoyances),

Attended Transfer additions.

Additional codec rejection for unlikely case that remote chose a
codec we didn't advertise.

2004-10-22 10:27 stevek

* align.h: need parentheses around args to macros.

2004-10-21 18:13 stevek

* align.c, align.h: Forgot to commit these: cleaner alignment for
libiax2 (from Stephen Uhler).
2004-10-21 10:49 stevek

* iax2-parser.c: Reworked alignment patch (much cleaner) by Stephen
Uhler at Sun.

2004-10-20 15:09 stevek

* iax-client.h, iax.c: Codec negotiation.

change iaxc_set_encoder_format api to iaxc_set_formats(int
preferred, int allowed);

added iaxc_set_min_outgoing_framesize(int samples);

Both of these APIs are not necessary to be called; they have
sensible defaults.

Advertise our preferences and capabilities when making outgoing
calls, and choose a format based on remote preferences and
capabilities when accepting incoming calls.

2004-09-09 11:30 stevek

* iax.c, iax2-parser.c: Changes from Stephen Uhler

- Reminded me that I never actually committed Stephan Kauss'
alignment patch for libiax2. - Some small build changes for
Solaris - New portmixer implementation for solaris. - New sample
client: tkphone. Cross-platform "agent-based" tk
implementation.

2004-06-10 16:16 stevek

* iax.c: 1) Back out voice timestamp prediction. While this
would theoretically make things work better, in practice, it
fixed a theoretical problem for us, and caused actual
problems. It turns out that on Windows, it's pretty near
impossible to get the correct time. We only need a
long-term accurate time mechanism (don't need high-resolution),
and both GetTickCount and GetSystemTime return different, but
drifting times. [they drift relative both to the sound card
on the machine, as well as to servers with correct time]. At
least on some machines. The Hi-res time functions also are
not long-term accurate.

So, what went wrong with voice prediction is that during
a call, on some machines, we'd drift between the
system clock and the sound card by 240ms (our "threshold"
for voice prediction) every 5 minutes or less. This
caused us to send overlapping timestamps as we changed
timebases (if we went backwards, which we saw the most),
or to send a gap of 240ms (if we went forward, which may
happen, but we wouldn't notice because it sounds
pretty much like a network hiccough).

Instead, without voice prediction, our timestamps are
generally +- 55ms from accurate [based on windows
scheduling accuracy], and they do drift, but they drift
slowly, and asterisk on the other end generally handles
this gracefully: The jitter buffer properly adapts, etc.

The advantages we're losing, though are: (1) reading
ethereal output is much harder to follow with the "jumpy"
timestamps, and (2) now that asterisk sends timestamps
through IAX -> SIP calls, etc, these calls will now
depend on the remote endpoint's ability to deal with
these timestamp jitters, etc.

2) Only update our local "lastsent" timestamp notion when sending
a non AST_FRAME_IAX frame. This is what asterisk itself
does, and expects. The problem we saw which this solves is that
we were updating our lastsent ts when we sent a VNAK to
asterisk, and then we weren't sending a full voice frame because
of that, however asterisk doesn't update it's last timestamp
from us in this case, and this subsequent voice miniframes were
way off. This probably would also only happen when silence
detection of some sort was being used, otherwise it's a race
that you'd probably win.

Comments: By: Brian West (bkw918) 2004-11-15 17:18:12.000-0600

do all three of you have disclaimers on file?
By: stevekstevek (stevekstevek) 2004-11-15 17:25:20.000-0600

From my original post: "All three contributors claim to have disclaimers on file."

I know I do, and the other contributors have told me they do as well. I wasn't sitting next to them when they faxed them in, so I all I can do is pass along that they've claimed to have done so.
By: bdolljr (bdolljr) 2004-11-19 17:02:39.000-0600

disclaimer on file for me...
By: Mark Spencer (markster) 2004-11-20 01:57:22.000-0600

Surely we can get a version of get_align32 and friends without a nagging BSD style license right?
By: stevekstevek (stevekstevek) 2004-11-20 09:42:01.000-0600

I think the license that Stephen put on this is a Modified BSD license without the advertising clause..

Of course, someone is welcome to re-write it..
By: Mark Spencer (markster) 2004-11-20 10:18:33.000-0600

+ * Redistribution in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.

That's the part that worries me. There are two modified BSD licenses which are okay, one which does not require changes to "documentation and/or other materials" and one which only requires it when the features provided by the software are a listed feature.

I believe the Asterisk/Solaris patch may have an implementation which would not have such a disclaimer on it.
By: stevekstevek (stevekstevek) 2004-11-20 10:43:39.000-0600

The solaris patch bug 0002740
seems to contain similar notices in queue.h:

+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.

And the GPL-incompatible advertising clause:
+ * 3. All advertising materials mentioning features or use of this software
+ * must display the following acknowledgement:
+ * This product includes software developed by the University of
+ * California, Berkeley and its contributors.

Anyway, I see these __get_uint32 and __get_uint16 functions, but as you noted there, they don't deal with endianness. Also, I don't see the reciprocal __set functions (apparently we need __setuint32 also.

Has Stephen Uhler sent in a disclaimer? If so, then you can just relicense however you want. If not, I can wait until you get the other patch worked out, and then If you allow me to also relicense the code there LGPL for libiax2, then I can replace the functions here.

Although the functions are simple, and writing all this seems to take almost as long as writing the functions themselves :) I can't easily test this, because the only alignment-needing box I have is a really old sparc box that hasn't booted in years, and getting a test together will take quite some time.
By: stevekstevek (stevekstevek) 2004-12-03 13:45:25.000-0600

The new attachment is an updated patch. Different than the previous, this patch:

1) Uses get_uint32 and get_uint16 from bug 0002740. Assuming that we have Digium's permission to copy these 8 lines of code frpm chan_iax2 to libiax2.

2) Adds back VOICE_TS_PREDICTION into libiax2, adjusting the "txcore" as well to compensate for drift between soundcard and local time.

So, now, all the code here was written by either Bill Doll, Myself, or is the 8 lines of code from bug 0002740, which is already disclaimed.
By: Mark Spencer (markster) 2004-12-03 21:00:48.000-0600

Permission granted, of course. Added to CVS. Thanks!