iaxclient-devel — Development Discussion List

Re: [Iaxclient-devel] static build issue (was: Re: contrib/tcl music on hold patch)

[Mats B. <ma...@gm...>]

On Tue, Apr 22, 2008 at 4:18 PM, Peter Grayson <jpg...@gm...> wrote:
>  <snip>
>
>  You don't give many clues as to what might be going wrong. Do you set
>  the PKG_CONFIG_PATH when you configure iaxclient? Where do iaxclient's
>  dependencies get installed? /usr/local? Do you have different versions
>  of speex, portaudio, etc. installed in /usr/lib?
>

Perhaps I can provide some detailed info of the current state of the
build environment.
Note that I did 'updatedb' to get fresh 'locate' results.

linux:/usr/local/lib/pkgconfig # env | grep PKG
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig:/opt/kde3/lib/pkgconfig:/opt/gnome/lib/pkgconfig:/opt/gnome/lib/pkgconfig:/opt/gnome/share/pkgconfig
linux:/usr/local/lib/pkgconfig # ll  | grep speex
-rw-r--r--   1 root root  321210 Apr 16 16:04 libspeex.a
-rwxr-xr-x   1 root root     763 Apr 16 16:04 libspeex.la
-rw-r--r--   1 root root  217008 Apr 16 16:04 libspeexdsp.a
-rwxr-xr-x   1 root root     772 Apr 16 16:04 libspeexdsp.la
linux:/usr/local/lib/pkgconfig # locate libspeex
/usr/local/lib/libspeex.a
/usr/local/lib/libspeex.la
/usr/local/lib/libspeexdsp.a
/usr/local/lib/libspeexdsp.la
linux:/usr/local/lib/pkgconfig # locate portaudio
/usr/lib/ooo-2.0/program/libportaudio.so
/usr/lib/ooo-2.0/program/libportaudio.so.0
/usr/lib/ooo-2.0/program/libportaudio.so.0.0.18
/usr/local/include/portaudio.h
/usr/local/lib/libportaudio.a
/usr/local/lib/libportaudio.la
/usr/local/lib/pkgconfig/portaudio-2.0.pc
linux:/usr/local/lib/pkgconfig # cat *
prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: iaxclient
Description: Inter-Asterisk eXchange Client Library
Version: 2.x-trunk
Libs: -L${libdir} -liaxclient
Libs.private:
Cflags: -I${includedir}
Requires.private: portaudio-2.0 speex

prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: PortAudio
Description: Portable audio I/O
Requires:
Version: 19

Libs: -L${libdir} -lportaudio  -lm -lpthread
Cflags: -I${includedir} -pthread
# libspeex pkg-config source file

prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: speex
Description: Speex is an audio codec tuned for speech
Version: 1.2beta3
Requires:
Conflicts:
Libs: -L${libdir} -lspeex -lm
Cflags: -I${includedir}
# libspeexdsp pkg-config source file

prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: speexdsp
Description: Speexdsp is a speech processing library that goes along
with the Speex codec
Version: 1.2beta3
Requires:
Conflicts:
Libs: -L${libdir} -lspeexdsp -lm
Cflags: -I${includedir}

It seems that speex is indeed statically linked but still missing (at
least) one speex symbol:

linux:~/C/voip/iaxclient/trunk/contrib/tcl # ldd libtcliaxclient0.2.so
        linux-gate.so.1 =>  (0xffffe000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40052000)
        libasound.so.2 => /usr/lib/libasound.so.2 (0x40065000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40123000)
        /lib/ld-linux.so.2 (0x80000000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40242000)
        libdl.so.2 => /lib/libdl.so.2 (0x40268000)
        libresmgr.so.1 => /lib/libresmgr.so.1 (0x4026c000)

>  You should know that this whole exercise of building a shared object
>  with no shared object dependencies is much like swimming upstream. The
>  build tools are all geared towards either building things statically
>  or building things shared, but not mixing the two in this way. I am
>  curious as to why it is so important to avoid these dynamic link
>  dependencies -- especially on linux?
>

We must be sure of which versions of speex and portaudio we are using
to avoid the "dll hell".
This is not so strange since it is exactly how it worked with the old
iaxclient build system
where speex and portaudio were compiled together with iaxclient code.

Mats

Re: [Iaxclient-devel] possible security hole in iax.c

[Alexander V. <ava...@vo...>]

Actually, in the updated patch I didn't include one change, so here is 
again an update, hopefully the last one

Best regards
Alex

Alexander Vassilev wrote:
> Hmm, seems the patch was broken, here is a newly generated one that works
>
> Regards
> Alex
>
>
> Alexander Vassilev wrote:
>> Hi all,
>>
>> I am attaching a patch that fixes the forementioned problems. The code
>> that was added to handle mini video frames also has a problem -  in case
>> the received frame is a mini video frame, a check is done only against
>> the size of an audio miniheader, which is smaller, so a vulnerability
>> similar to the one from Advisory ID: CORE-2006-0327 (coresecurity.com)
>> is again present in iaxclient. This patch should fix it.
>>
>> Best regards
>> Alex
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
>> Don't miss this year's exciting event. There's still time to save 
>> $100. Use priority code J8TL2D2. 
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone 
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Iaxclient-devel mailing list
>> Iax...@li...
>> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ------------------------------------------------------------------------
>
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel

Re: [Iaxclient-devel] possible security hole in iax.c

[Alexander V. <ava...@vo...>]

Hmm, seems the patch was broken, here is a newly generated one that works

Regards
Alex


Alexander Vassilev wrote:
> Hi all,
>
> I am attaching a patch that fixes the forementioned problems. The code
> that was added to handle mini video frames also has a problem -  in case
> the received frame is a mini video frame, a check is done only against
> the size of an audio miniheader, which is smaller, so a vulnerability
> similar to the one from Advisory ID: CORE-2006-0327 (coresecurity.com)
> is again present in iaxclient. This patch should fix it.
>
> Best regards
> Alex
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ------------------------------------------------------------------------
>
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel

Re: [Iaxclient-devel] possible security hole in iax.c

[Alexander V. <ava...@vo...>]

Hi all,

I am attaching a patch that fixes the forementioned problems. The code
that was added to handle mini video frames also has a problem -  in case
the received frame is a mini video frame, a check is done only against
the size of an audio miniheader, which is smaller, so a vulnerability
similar to the one from Advisory ID: CORE-2006-0327 (coresecurity.com)
is again present in iaxclient. This patch should fix it.

Best regards
Alex

Re: [Iaxclient-devel] possible security hole in iax.c

[Alexander V. <ava...@vo...>]

Hi Pete,

No patches yet, maybe it would be even easier to just edit the code.
Currently I am studying the newly introduced video code, the way packet
size is verified there is also not clean. I will make a patch after I
finish examining the mini video header-related code.

Alex


Peter Grayson wrote:
> Hi Alexander
>
> Do you have patches that addresses these two issues?
>
> Pete
>
> On Tue, Apr 22, 2008 at 3:09 PM, Alexander Vassilev
> <ava...@vo...> wrote:
>   
>> Hi all,
>>
>>  If you remember from the past, there was a security issue with
>>  iax_net_process() tolerating frames that are amaller in size than the
>>  frame header itself. There were checks, but they only logged warnings,
>>  and didnt prevent a possible exploit. There was a security advisory on
>>  this, on securityfocus or somewhere else, not sure. The fix was to add a
>>  return statement if the checks catch a malformed packet. Now, looking at
>>  the code, I see the following:
>>  code from iax.c:
>>
>>  struct iax_event *iax_net_process(unsigned char *buf, int len, struct sockaddr_in *sin)
>>   {
>>         struct ast_iax2_full_hdr *fh = (struct ast_iax2_full_hdr *)buf;
>>         struct ast_iax2_mini_hdr *mh = (struct ast_iax2_mini_hdr *)buf;
>>         struct ast_iax2_video_hdr *vh = (struct ast_iax2_video_hdr *)buf;
>>         struct iax_session *session;
>>
>>         if (ntohs(fh->scallno) & IAX_FLAG_FULL) {
>>         /* Full size header */
>>                 if ((size_t)len < sizeof(struct ast_iax2_full_hdr)) {
>>                 DEBU(G "Short header received from %s\n", inet_ntoa(sin->sin_addr));
>>                 IAXERROR "Short header received from %s\n", inet_ntoa(sin->sin_addr));
>>                 return NULL;
>>         }
>>
>>  ...
>>  Note that there is no check if we actually have the 2 bytes in hte
>>  buffer that represent fh->scallno. What happens if we receive a frame
>>  with size 1 byte?
>>
>>  I also noticed an erroneous comment in this function - this one is not a
>>  security risk :) but would be good if its fixed
>>  code from iax.c:
>>
>>  3236            /* Miniature, voice frame */
>>  3237            if ((vh->zeros == 0) && (ntohs(vh->callno) & 0x8000))
>>
>>
>>
>>  This is actually a miniature video frame
>>
>>  Best regards
>>
>>  Alexander Vassilev
>>  Senior software engineer
>>  VoipGATE S.A.
>>
>>
>>  -------------------------------------------------------------------------
>>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>  Don't miss this year's exciting event. There's still time to save $100.
>>  Use priority code J8TL2D2.
>>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>  _______________________________________________
>>  Iaxclient-devel mailing list
>>  Iax...@li...
>>  https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>>
>>     
>
>   

Re: [Iaxclient-devel] possible security hole in iax.c

[Peter G. <jpg...@gm...>]

Hi Alexander

Do you have patches that addresses these two issues?

Pete

On Tue, Apr 22, 2008 at 3:09 PM, Alexander Vassilev
<ava...@vo...> wrote:
> Hi all,
>
>  If you remember from the past, there was a security issue with
>  iax_net_process() tolerating frames that are amaller in size than the
>  frame header itself. There were checks, but they only logged warnings,
>  and didnt prevent a possible exploit. There was a security advisory on
>  this, on securityfocus or somewhere else, not sure. The fix was to add a
>  return statement if the checks catch a malformed packet. Now, looking at
>  the code, I see the following:
>  code from iax.c:
>
>  struct iax_event *iax_net_process(unsigned char *buf, int len, struct sockaddr_in *sin)
>   {
>         struct ast_iax2_full_hdr *fh = (struct ast_iax2_full_hdr *)buf;
>         struct ast_iax2_mini_hdr *mh = (struct ast_iax2_mini_hdr *)buf;
>         struct ast_iax2_video_hdr *vh = (struct ast_iax2_video_hdr *)buf;
>         struct iax_session *session;
>
>         if (ntohs(fh->scallno) & IAX_FLAG_FULL) {
>         /* Full size header */
>                 if ((size_t)len < sizeof(struct ast_iax2_full_hdr)) {
>                 DEBU(G "Short header received from %s\n", inet_ntoa(sin->sin_addr));
>                 IAXERROR "Short header received from %s\n", inet_ntoa(sin->sin_addr));
>                 return NULL;
>         }
>
>  ...
>  Note that there is no check if we actually have the 2 bytes in hte
>  buffer that represent fh->scallno. What happens if we receive a frame
>  with size 1 byte?
>
>  I also noticed an erroneous comment in this function - this one is not a
>  security risk :) but would be good if its fixed
>  code from iax.c:
>
>  3236            /* Miniature, voice frame */
>  3237            if ((vh->zeros == 0) && (ntohs(vh->callno) & 0x8000))
>
>
>
>  This is actually a miniature video frame
>
>  Best regards
>
>  Alexander Vassilev
>  Senior software engineer
>  VoipGATE S.A.
>
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  Iaxclient-devel mailing list
>  Iax...@li...
>  https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>

[Iaxclient-devel] possible security hole in iax.c

[Alexander V. <ava...@vo...>]

Hi all,

If you remember from the past, there was a security issue with 
iax_net_process() tolerating frames that are amaller in size than the 
frame header itself. There were checks, but they only logged warnings, 
and didnt prevent a possible exploit. There was a security advisory on 
this, on securityfocus or somewhere else, not sure. The fix was to add a 
return statement if the checks catch a malformed packet. Now, looking at 
the code, I see the following:
code from iax.c:

struct iax_event *iax_net_process(unsigned char *buf, int len, struct sockaddr_in *sin)
 {
 	struct ast_iax2_full_hdr *fh = (struct ast_iax2_full_hdr *)buf;
	struct ast_iax2_mini_hdr *mh = (struct ast_iax2_mini_hdr *)buf;
 	struct ast_iax2_video_hdr *vh = (struct ast_iax2_video_hdr *)buf;
 	struct iax_session *session;

 	if (ntohs(fh->scallno) & IAX_FLAG_FULL) {
	/* Full size header */
 		if ((size_t)len < sizeof(struct ast_iax2_full_hdr)) {
 		DEBU(G "Short header received from %s\n", inet_ntoa(sin->sin_addr));
 		IAXERROR "Short header received from %s\n", inet_ntoa(sin->sin_addr));
 		return NULL;
 	}

...
Note that there is no check if we actually have the 2 bytes in hte 
buffer that represent fh->scallno. What happens if we receive a frame 
with size 1 byte?

I also noticed an erroneous comment in this function - this one is not a 
security risk :) but would be good if its fixed
code from iax.c:

3236 		/* Miniature, voice frame */
3237 		if ((vh->zeros == 0) && (ntohs(vh->callno) & 0x8000))



This is actually a miniature video frame

Best regards

Alexander Vassilev
Senior software engineer
VoipGATE S.A.

Re: [Iaxclient-devel] static build issue

[Andrea S. <si...@op...>]

Peter Grayson wrote:

> You don't give many clues as to what might be going wrong. Do you set
> the PKG_CONFIG_PATH when you configure iaxclient? Where do iaxclient's

you're right sorry :) Now I'm in a hurry I'll submit something more detailed
tomorrow, only if mats doesn't beat me

> dependencies get installed? /usr/local? Do you have different versions
> of speex, portaudio, etc. installed in /usr/lib?
> You should know that this whole exercise of building a shared object
> with no shared object dependencies is much like swimming upstream. The
> build tools are all geared towards either building things statically
> or building things shared, but not mixing the two in this way. I am
> curious as to why it is so important to avoid these dynamic link
> dependencies -- especially on linux?




> 
> Pete
> 

Re: [Iaxclient-devel] static build issue (was: Re: contrib/tcl music on hold patch)

[Peter G. <jpg...@gm...>]

On Tue, Apr 22, 2008 at 5:58 AM, Andrea Suisani <si...@op...> wrote:
> Hi all,
>
>  tclers on that list will really appreciate if someone
>  with a better knowledge of iaxclient building system help
>  us to get rid of that annoying problem :)
>
>  let me summarize:
>
>  - goal: build a "self-contained" libtcliaxclient0.2.so with speex and
>          portaudio statically linked in.
>
>  - building iaxclient and tcl extensions (placed in contrib/tcl)
>    the usual way lead me to a working .so file of 34 KB with this
>    dependencies
>
>   sickpig@suino:/usr/lib/tcliaxclient0.2$ldd libtcliaxclient0.2.so
>          linux-gate.so.1 =>  (0xffffe000)
>          libspeexdsp.so.1 => /usr/local/lib/libspeexdsp.so.1 (0xb7f5a000)
>          libspeex.so.1 => /usr/local/lib/libspeex.so.1 (0xb7f43000)
>          libiaxclient.so.1 => /usr/local/lib/libiaxclient.so.1 (0xb7f1c000)
>          libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7f04000)
>          libasound.so.2 => /usr/lib/libasound.so.2 (0xb7e3e000)
>          libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7cf4000)
>          libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7cce000)
>          libportaudio.so.2 => /usr/local/lib/libportaudio.so.2 (0xb7ca7000)
>          libgsm.so.1 => /usr/lib/libgsm.so.1 (0xb7c97000)
>          /lib/ld-linux.so.2 (0x80000000)
>          libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c93000)
>          libjack.so.0 => /usr/lib/libjack.so.0 (0xb7c7a000)
>          librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7c70000)
>
>  - building the bit following instructions contained in contrib/tcl/build-iaxclient.txt,
>    trying to get a tcl extensions with speex and portaudio linked statically,
>    give me a not working library due to:
>
>    sickpig@suino:~$ tclsh
>    % package require iaxclient
>    couldn't load file "/usr/lib/tcliaxclient0.2/libtcliaxclient0.2.so": /usr/lib/tcliaxclient0.2/libtcliaxclient0.2.so: undefined symbol: speex_preprocess_ctl
>
>    size of tcl extensions is bigger but still...
>
>    sickpig@suino:~/src/iaxclient-svn-tree/trunk/contrib/tcl$ ls -lh libtcliaxclient0.2.so
>    -rwxr-xr-x 1 sickpig sickpig 320K 2008-04-18 14:34 libtcliaxclient0.2.so
>
>    with those shared library dependencies
>
>    sickpig@suino:~/src/iaxclient-svn-tree/trunk/contrib/tcl$ ldd libtcliaxclient0.2.so
>           linux-gate.so.1 =>  (0xffffe000)
>           libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7efe000)
>           libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7db4000)
>           /lib/ld-linux.so.2 (0x80000000)
>
>
>  any hints? am I missing something obvious?

You don't give many clues as to what might be going wrong. Do you set
the PKG_CONFIG_PATH when you configure iaxclient? Where do iaxclient's
dependencies get installed? /usr/local? Do you have different versions
of speex, portaudio, etc. installed in /usr/lib?

You should know that this whole exercise of building a shared object
with no shared object dependencies is much like swimming upstream. The
build tools are all geared towards either building things statically
or building things shared, but not mixing the two in this way. I am
curious as to why it is so important to avoid these dynamic link
dependencies -- especially on linux?

Pete

Re: [Iaxclient-devel] Registration process losing REGACK packet

[Peter G. <jpg...@gm...>]

Hi Mark,

On Tue, Apr 22, 2008 at 4:41 AM,  <mar...@op...> wrote:
> Hi,
>
>  Continuing with my investigations, I have identified an issue with
>  registrations that immediately follow a call hangup. There may also be other
>  scenarios which may cause similar problems, when the session pointer address
>  is being reused (read on for my explanation).
>
>  If a hangup is made on a call and the session is destroyed by calling the
>  destroy_session method of iax.c, frames still in the schedq associated with
>  the session being destroyed are marked as being sent by setting the retries
>  value to -1. In my case, not so long after, a registration sequence is
>  begun, which just happens to calloc the same address as the session pointer
>  used in the session for the call above (it is common to see addresses being
>  reused soon after being free'd). When the schedq is being processed in the
>  iax_get_event method of iax.c, a HANGUP frame from the previous call is
>  found, with frame->retries set to -1, frame->final set to 1 and
>  frame->session containing the same pointer address as the one we have been
>  allocated for use as the registration session. The frame processing decides
>  it's a good idea to destroy this session (again), which unfortunately
>  destroys the session being used for the registration, and we have a
>  registration failure as a result.

This sounds familiar. I think this has come up before, but I don't
remember all the details. It sounds like you have investigated it
pretty thoroughly.

>  My fix was to add a curs->frame->session = NULL; in destroy_session, for all
>  scheduled events with the same session in the queue, thus preventing the
>  session from being destroyed later on in iax_get_event of iax.c when the
>  HANGUP frame is scheduled. We know that this session is the one being
>  destroyed and is now invalid. Another possibility is to set
>  curs->frame->final = 0; but I felt that setting the session to NULL was more
>  "correct" (note to self: make sure that the rest of the code can handle
>  this). Those more experienced with the library code make like to offer
>  another solution.

Could you submit a patch with the changes you describe. I will review it.

Thanks so much for looking into this issue.

Pete

[Iaxclient-devel] static build issue (was: Re: contrib/tcl music on hold patch)

[Andrea S. <si...@op...>]

Hi all,

tclers on that list will really appreciate if someone
with a better knowledge of iaxclient building system help
us to get rid of that annoying problem :)

let me summarize:

- goal: build a "self-contained" libtcliaxclient0.2.so with speex and
         portaudio statically linked in.

- building iaxclient and tcl extensions (placed in contrib/tcl)
   the usual way lead me to a working .so file of 34 KB with this
   dependencies

  sickpig@suino:/usr/lib/tcliaxclient0.2$ldd libtcliaxclient0.2.so
         linux-gate.so.1 =>  (0xffffe000)
         libspeexdsp.so.1 => /usr/local/lib/libspeexdsp.so.1 (0xb7f5a000)
         libspeex.so.1 => /usr/local/lib/libspeex.so.1 (0xb7f43000)
         libiaxclient.so.1 => /usr/local/lib/libiaxclient.so.1 (0xb7f1c000)
         libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7f04000)
         libasound.so.2 => /usr/lib/libasound.so.2 (0xb7e3e000)
         libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7cf4000)
         libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7cce000)
         libportaudio.so.2 => /usr/local/lib/libportaudio.so.2 (0xb7ca7000)
         libgsm.so.1 => /usr/lib/libgsm.so.1 (0xb7c97000)
         /lib/ld-linux.so.2 (0x80000000)
         libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c93000)
         libjack.so.0 => /usr/lib/libjack.so.0 (0xb7c7a000)
         librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7c70000)

- building the bit following instructions contained in contrib/tcl/build-iaxclient.txt,
   trying to get a tcl extensions with speex and portaudio linked statically,
   give me a not working library due to:

   sickpig@suino:~$ tclsh
   % package require iaxclient
   couldn't load file "/usr/lib/tcliaxclient0.2/libtcliaxclient0.2.so": /usr/lib/tcliaxclient0.2/libtcliaxclient0.2.so: undefined symbol: speex_preprocess_ctl

   size of tcl extensions is bigger but still...

   sickpig@suino:~/src/iaxclient-svn-tree/trunk/contrib/tcl$ ls -lh libtcliaxclient0.2.so
   -rwxr-xr-x 1 sickpig sickpig 320K 2008-04-18 14:34 libtcliaxclient0.2.so

   with those shared library dependencies

   sickpig@suino:~/src/iaxclient-svn-tree/trunk/contrib/tcl$ ldd libtcliaxclient0.2.so
          linux-gate.so.1 =>  (0xffffe000)
          libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7efe000)
          libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7db4000)
          /lib/ld-linux.so.2 (0x80000000)


any hints? am I missing something obvious?

thanks

andrea

Mats Bengtsson wrote:
> On Mon, Apr 21, 2008 at 3:54 PM, Andrea Suisani <si...@op...> wrote:
>> Hi mats,
>>
>>  any news ?
>>
> 
> No. I have absolutely no idea what is going wrong.
> The very same build system (configure && make, not Xcode) on MacOSX
> works OK. I have:
> 
> Macintosh:build mats$ ll /usr/local/lib/ | grep speex
> -rw-r--r--   1 root  wheel   375056 14 Mar 08:21 libspeex.a
> -rwxr-xr-x   1 root  wheel      763 14 Mar 08:21 libspeex.la
> -rw-r--r--   1 root  wheel   278032 14 Mar 08:21 libspeexdsp.a
> -rwxr-xr-x   1 root  wheel      772 14 Mar 08:21 libspeexdsp.la
> 
> and the actual link stage reads:
> 
> gcc -pipe -dynamiclib -Os -Wall -Wno-implicit-int -fno-common -prebind
> -headerpad_max_install_names -Wl,-search_paths_first
> -Wl,-single_module -o libtcliaxclient0.2.dylib iaxclient.o tones.o
> XThreadUtil.o -lportaudio -lspeexdsp -lspeex -liaxclient -framework
> CoreAudio -framework AudioToolbox -framework AudioUnit -framework
> CoreServices  -L/Library/Frameworks/Tcl.framework -ltclstub8.5
> 
> Excluding the Mac specific stuff, this looks the same as on linux.
> There are a few switches I don't know: -Wl,-search_paths_first
> Also, the dylib is larger (352k) than on linux (280k).
> 
> I also explicitly checked that the missing symbol on linux is there:
> nm libtcliaxclient0.2.dylib |grep speex_preprocess_ctl
> 00012be0 T _speex_preprocess_ctl
> 
> Mats the clueless...
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
> 

Re: [Iaxclient-devel] Registration process losing REGACK packet

[<mar...@op...>]

Hi,

Continuing with my investigations, I have identified an issue with
registrations that immediately follow a call hangup. There may also be other
scenarios which may cause similar problems, when the session pointer address
is being reused (read on for my explanation).

If a hangup is made on a call and the session is destroyed by calling the
destroy_session method of iax.c, frames still in the schedq associated with
the session being destroyed are marked as being sent by setting the retries
value to -1. In my case, not so long after, a registration sequence is
begun, which just happens to calloc the same address as the session pointer
used in the session for the call above (it is common to see addresses being
reused soon after being free'd). When the schedq is being processed in the
iax_get_event method of iax.c, a HANGUP frame from the previous call is
found, with frame->retries set to -1, frame->final set to 1 and
frame->session containing the same pointer address as the one we have been
allocated for use as the registration session. The frame processing decides
it's a good idea to destroy this session (again), which unfortunately
destroys the session being used for the registration, and we have a
registration failure as a result.

My fix was to add a curs->frame->session = NULL; in destroy_session, for all
scheduled events with the same session in the queue, thus preventing the
session from being destroyed later on in iax_get_event of iax.c when the
HANGUP frame is scheduled. We know that this session is the one being
destroyed and is now invalid. Another possibility is to set
curs->frame->final = 0; but I felt that setting the session to NULL was more
"correct" (note to self: make sure that the rest of the code can handle
this). Those more experienced with the library code make like to offer
another solution.

HTH
Mark

-----Original Message-----
From: Andrea Suisani [mailto:si...@op...] 
Sent: Monday, 21 April 2008 11:53 PM
To: mar...@op...
Cc: Iax...@li...
Subject: Re: [Iaxclient-devel] Registration process losing REGACK packet

Hi,


I really don't  know if it is related but the last registration known bugs
that I'm aware of was fixed in 2.0.1 release

if you are interested the thread with subject
[Iaxclient-devel] [announce] iaxclient-2.0.0 (final) released
contains info regarding bug's details

andrea


mar...@op... wrote:
> Hi,
> 
> My build is a DLL on Windows XP, with the IAX v2.1beta2 tag from source
> forge.
> 
> I have been testing the registration process with an Asterisk server
(v1.4,
> v1.6) using unit tests, and found that regularly (not always) the REGACK
> packet is not processed by my client. Using Wireshark, I see the REGREQ
from
> the client, the ACK from the server, and then the REGACK from the server,
> but this packet is not processed by the client. I would expect the
> iaxc_handle_regreply function in iax.c to be called, but this never
happens
> when the error occurs. Additionally, if the server requires authentication
> from the client and there is a REGAUTH packet sent from the server, the
> registration process always completes successfully.
> 
> Does anyone else have this problem, or already addressed the issue in
code?
> Is there a problem with identifying the session?
> 
> regards,
> Mark
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
>
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
> 

Re: [Iaxclient-devel] contrib/tcl music on hold patch

[Mats B. <ma...@gm...>]

On Mon, Apr 21, 2008 at 3:54 PM, Andrea Suisani <si...@op...> wrote:
> Hi mats,
>
>  any news ?
>

No. I have absolutely no idea what is going wrong.
The very same build system (configure && make, not Xcode) on MacOSX
works OK. I have:

Macintosh:build mats$ ll /usr/local/lib/ | grep speex
-rw-r--r--   1 root  wheel   375056 14 Mar 08:21 libspeex.a
-rwxr-xr-x   1 root  wheel      763 14 Mar 08:21 libspeex.la
-rw-r--r--   1 root  wheel   278032 14 Mar 08:21 libspeexdsp.a
-rwxr-xr-x   1 root  wheel      772 14 Mar 08:21 libspeexdsp.la

and the actual link stage reads:

gcc -pipe -dynamiclib -Os -Wall -Wno-implicit-int -fno-common -prebind
-headerpad_max_install_names -Wl,-search_paths_first
-Wl,-single_module -o libtcliaxclient0.2.dylib iaxclient.o tones.o
XThreadUtil.o -lportaudio -lspeexdsp -lspeex -liaxclient -framework
CoreAudio -framework AudioToolbox -framework AudioUnit -framework
CoreServices  -L/Library/Frameworks/Tcl.framework -ltclstub8.5

Excluding the Mac specific stuff, this looks the same as on linux.
There are a few switches I don't know: -Wl,-search_paths_first
Also, the dylib is larger (352k) than on linux (280k).

I also explicitly checked that the missing symbol on linux is there:
nm libtcliaxclient0.2.dylib |grep speex_preprocess_ctl
00012be0 T _speex_preprocess_ctl

Mats the clueless...

Re: [Iaxclient-devel] The cam is not attached during Iaxclient start then it's impossible to attach it later. but Video devices got nothing?

[db p. <pe...@gm...>]

Hi Pete,
...
[[SKIPPED]]
...
>  This does seem like a problem.
>
>  What kind of video capture device is this?
>
My cam is 'logitech quickcam 4000',another cam is 'Camera chip Fusion
100',it got the same problem,
P.S:I start Iaxclient with cam,it is work well.

>  Does your application receive an IAXC_EVENT_VIDCAP_DEVICE event?
>
Yes,I received IAXC_EVENT_VIDCAP_DEVICE event 12 times,as follow,
{{{
...
ready...
VideoCaptureDeviceEvent:
VideoCaptureDeviceEvent:
VideoCaptureDeviceEvent:
VideoCaptureDeviceEvent:
VideoCaptureDeviceEvent:
VideoCaptureDeviceEvent:
VideoCaptureDeviceEvent:
VideoCaptureDeviceEvent:
VideoCaptureDeviceEvent:
VideoCaptureDeviceEvent:
VideoCaptureDeviceEvent:
VideoCaptureDeviceEvent:
regAcknowledged:1 XXX@XXX:4569 18 -1
....
}}}
I have a suggestion the event it's better divid into 2 kind of
it(INSERTION/REMOVE).eg.
IAXC_EVENT_VIDCAP_DEVICE_INSERT & IAXC_EVENT_VIDCAP_DEVICE_REMOVE
just invoke it once?

>  Pete
>

Re: [Iaxclient-devel] The cam is not attached during Iaxclient start then it's impossible to attach it later. but Video devices got nothing?

[Peter G. <jpg...@gm...>]

On Mon, Apr 21, 2008 at 4:01 AM, db peng <pe...@gm...> wrote:
> Hi all,
>   The problem can reproduced by follow steps,
>   1. start Iaxclient without any video capture device.
>   2. plug in video capture device,
>   3. call 'iaxc_video_devices_get(...)',can't get the video device we
>  pluged in just now.
>   The method 'iaxc_video_devices_get(...)' can't get any devices after
>  'IAXC_EVENT_VIDCAP_DEVICE' event ocurrs,my OS is Windows XP.

This does seem like a problem.

What kind of video capture device is this?

Does your application receive an IAXC_EVENT_VIDCAP_DEVICE event?

Pete

Re: [Iaxclient-devel] contrib/tcl music on hold patch

[Andrea S. <si...@op...>]

Hi mats,

any news ?

andrea

Andrea Suisani wrote:
> Mats Bengtsson wrote:
>> Andrea,
>>
>> Perhaps you have any tips for building my tcl package on linux.
>> I have made a memo of my procedures in
>> contrib/tcl/build-iaxclient.txt
>> but when I try to load it into tcl it complains about missing speex symbol
>> speex_preprocess_ctl
> 
> some here :(
> 
> sickpig@suino:~/src/iaxclient-svn-tree/trunk/contrib/tcl$ tclsh
> % package require iaxclient
> couldn't load file "/usr/lib/tcliaxclient0.2/libtcliaxclient0.2.so": /usr/lib/tcliaxclient0.2/libtcliaxclient0.2.so: undefined symbol: speex_preprocess_ctl
> % exit
> 
> I've follow the instructions that I've found in build-iaxclient.txt
> (also setting LDFLAGS env var to "-Wl,-static")
> 
> 
> that's the size
> 
> sickpig@suino:~/src/iaxclient-svn-tree/trunk/contrib/tcl$ ls -lh libtcliaxclient0.2.so
> -rwxr-xr-x 1 sickpig sickpig 320K 2008-04-18 14:34 libtcliaxclient0.2.so
> 
> that's lib dep
> 
> sickpig@suino:~/src/iaxclient-svn-tree/trunk/contrib/tcl$ ldd libtcliaxclient0.2.so
>          linux-gate.so.1 =>  (0xffffe000)
>          libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7efe000)
>          libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7db4000)
>          /lib/ld-linux.so.2 (0x80000000)
> 
> they looks good, no external lib deps beside the usual suspects
> it seems to me that at compile time it fails to bundle external
> libs... but I'm far from being an expert in this stuff....

Re: [Iaxclient-devel] Registration process losing REGACK packet

[Andrea S. <si...@op...>]

Hi,


I really don't  know if it is related but the last registration known bugs
that I'm aware of was fixed in 2.0.1 release

if you are interested the thread with subject
[Iaxclient-devel] [announce] iaxclient-2.0.0 (final) released
contains info regarding bug's details

andrea


mar...@op... wrote:
> Hi,
> 
> My build is a DLL on Windows XP, with the IAX v2.1beta2 tag from source
> forge.
> 
> I have been testing the registration process with an Asterisk server (v1.4,
> v1.6) using unit tests, and found that regularly (not always) the REGACK
> packet is not processed by my client. Using Wireshark, I see the REGREQ from
> the client, the ACK from the server, and then the REGACK from the server,
> but this packet is not processed by the client. I would expect the
> iaxc_handle_regreply function in iax.c to be called, but this never happens
> when the error occurs. Additionally, if the server requires authentication
> from the client and there is a REGAUTH packet sent from the server, the
> registration process always completes successfully.
> 
> Does anyone else have this problem, or already addressed the issue in code?
> Is there a problem with identifying the session?
> 
> regards,
> Mark
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
> 

[Iaxclient-devel] The cam is not attached during Iaxclient start then it's impossible to attach it later. but Video devices got nothing?

[db p. <pe...@gm...>]

Hi all,
  The problem can reproduced by follow steps,
  1. start Iaxclient without any video capture device.
  2. plug in video capture device,
  3. call 'iaxc_video_devices_get(...)',can't get the video device we
pluged in just now.
 The method 'iaxc_video_devices_get(...)' can't get any devices after
'IAXC_EVENT_VIDCAP_DEVICE' event ocurrs,my OS is Windows XP.

Thanks

[Iaxclient-devel] Registration process losing REGACK packet

[<mar...@op...>]

Hi,

My build is a DLL on Windows XP, with the IAX v2.1beta2 tag from source
forge.

I have been testing the registration process with an Asterisk server (v1.4,
v1.6) using unit tests, and found that regularly (not always) the REGACK
packet is not processed by my client. Using Wireshark, I see the REGREQ from
the client, the ACK from the server, and then the REGACK from the server,
but this packet is not processed by the client. I would expect the
iaxc_handle_regreply function in iax.c to be called, but this never happens
when the error occurs. Additionally, if the server requires authentication
from the client and there is a REGAUTH packet sent from the server, the
registration process always completes successfully.

Does anyone else have this problem, or already addressed the issue in code?
Is there a problem with identifying the session?

regards,
Mark

Re: [Iaxclient-devel] contrib/tcl music on hold patch

[Andrea S. <si...@op...>]

Mats Bengtsson wrote:
> Andrea,
> 
> Perhaps you have any tips for building my tcl package on linux.
> I have made a memo of my procedures in
> contrib/tcl/build-iaxclient.txt
> but when I try to load it into tcl it complains about missing speex symbol
> speex_preprocess_ctl

some here :(

sickpig@suino:~/src/iaxclient-svn-tree/trunk/contrib/tcl$ tclsh
% package require iaxclient
couldn't load file "/usr/lib/tcliaxclient0.2/libtcliaxclient0.2.so": /usr/lib/tcliaxclient0.2/libtcliaxclient0.2.so: undefined symbol: speex_preprocess_ctl
% exit

I've follow the instructions that I've found in build-iaxclient.txt
(also setting LDFLAGS env var to "-Wl,-static")


that's the size

sickpig@suino:~/src/iaxclient-svn-tree/trunk/contrib/tcl$ ls -lh libtcliaxclient0.2.so
-rwxr-xr-x 1 sickpig sickpig 320K 2008-04-18 14:34 libtcliaxclient0.2.so

that's lib dep

sickpig@suino:~/src/iaxclient-svn-tree/trunk/contrib/tcl$ ldd libtcliaxclient0.2.so
         linux-gate.so.1 =>  (0xffffe000)
         libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7efe000)
         libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7db4000)
         /lib/ld-linux.so.2 (0x80000000)

they looks good, no external lib deps beside the usual suspects
it seems to me that at compile time it fails to bundle external
libs... but I'm far from being an expert in this stuff....


P.S.
I've to append --without-gsm flag to iaxclient configure
otherwise, tcliaxclient complains also about "undefined symbol: gsm_create"
maybe that's a symptom

Re: [Iaxclient-devel] contrib/tcl music on hold patch

[Andrea S. <si...@op...>]

Mats Bengtsson wrote:
> Andrea,
> 
>>From what I can see it looks that your libtcliaxclient0.2.so links to the shared
> libs only since it is just 34k. It works on your box but the libs need
> to go with it.

yeah you're right, I just don't need to a static compiled libtcliaxclient0.2.so
In fact this morning while reading build-iaxclient.txt I wonder why
you use --disable-shared both in speex and portaudio configure... after reading
your post I figured out...

I will try to build iaxclient without runtime linked library
and I'll let you know


> I need a more selfcontained libtcliaxclient0.2.so with speex and
> portaudio statically linked in.
> I have on my box:
> 
> linux:~/C/voip/iaxclient/trunk/contrib/tcl # ls -lhct  | grep speex
> -rw-r--r--   1 root root 212K Apr 16 16:04 libspeexdsp.a
> -rwxr-xr-x   1 root root  772 Apr 16 16:04 libspeexdsp.la
> -rw-r--r--   1 root root 314K Apr 16 16:04 libspeex.a
> -rwxr-xr-x   1 root root  763 Apr 16 16:04 libspeex.la
> 
> and my libtcliaxclient0.2.so is 289k when it used to be with the old
> build system
> where all was built at the same time 445k. Seems something is missing.
> 
> Mats


Andrea

PS I needed to convert build-iaxclient.txt to being able to read
    it because of CR line terminators.
    I used this command
    tr '\015' '\012' < build-iaxclient.txt > new-build-iaxclient.txt

Re: [Iaxclient-devel] contrib/tcl music on hold patch

[Mats B. <ma...@gm...>]

Andrea,

>From what I can see it looks that your libtcliaxclient0.2.so links to the shared
libs only since it is just 34k. It works on your box but the libs need
to go with it.
I need a more selfcontained libtcliaxclient0.2.so with speex and
portaudio statically linked in.
I have on my box:

linux:~/C/voip/iaxclient/trunk/contrib/tcl # ls -lhct  | grep speex
-rw-r--r--   1 root root 212K Apr 16 16:04 libspeexdsp.a
-rwxr-xr-x   1 root root  772 Apr 16 16:04 libspeexdsp.la
-rw-r--r--   1 root root 314K Apr 16 16:04 libspeex.a
-rwxr-xr-x   1 root root  763 Apr 16 16:04 libspeex.la

and my libtcliaxclient0.2.so is 289k when it used to be with the old
build system
where all was built at the same time 445k. Seems something is missing.

Mats

On Thu, Apr 17, 2008 at 10:32 AM, Andrea Suisani <si...@op...> wrote:
>
> > I have made a memo of my procedures in
> > contrib/tcl/build-iaxclient.txt
> > but when I try to load it into tcl it complains about missing speex symbol
> > speex_preprocess_ctl
> > Also, it is just about 280k which seems way too small, so I suspect some
> > missing code there.
> >
>
>  I've compiled required libs a month ago
>  so take the following with a grain of salt
>
>  regarding lib speex that's what I've done so far:
>
>  download speex 1.2beta3
> (http://downloads.xiph.org/releases/speex/speex-1.2beta3.tar.gz)
>  ./configure && make && sudo make install
>
>  as you can see I ran ./configure with default values
>  and the default --prefix value is /usr/local
>  so you've everything installed in /usr/local/lib
>
>  that's what I've got
>
>  sickpig@suino:~$ls -lhct /usr/local/lib/ | grep speex
>  -rw-r--r-- 1 root root  221K 2008-02-18 10:26 libspeexdsp.a
>  -rwxr-xr-x 1 root root   840 2008-02-18 10:26 libspeexdsp.la
>  lrwxrwxrwx 1 root root    20 2008-02-18 10:26 libspeexdsp.so ->
> libspeexdsp.so.1.4.0
>  lrwxrwxrwx 1 root root    20 2008-02-18 10:26 libspeexdsp.so.1 ->
> libspeexdsp.so.1.4.0
>  -rwxr-xr-x 1 root root  181K 2008-02-18 10:26 libspeexdsp.so.1.4.0
>  -rw-r--r-- 1 root root  336K 2008-02-18 10:26 libspeex.a
>  -rwxr-xr-x 1 root root   819 2008-02-18 10:26 libspeex.la
>  lrwxrwxrwx 1 root root    17 2008-02-18 10:26 libspeex.so ->
> libspeex.so.1.4.0
>  lrwxrwxrwx 1 root root    17 2008-02-18 10:26 libspeex.so.1 ->
> libspeex.so.1.4.0
>  -rwxr-xr-x 1 root root  244K 2008-02-18 10:26 libspeex.so.1.4.0
>
>
>  whereas I've built iaxclient lib using this configure option:
>
>  ./configure --disable-video --enable-clients=testcall --with-local-gsm
>  make
>  sudo make install
>
>  result:
>
>  sickpig@suino:~$ls -lcht  /usr/lib/tcliaxclient0.2/
>  total 48K
>  -rw-r--r-- 1 root root 5.9K 2008-04-17 10:28 iaxclient.tcl
>  -rw-r--r-- 1 root root  185 2008-04-17 10:28 pkgIndex.tcl
>  -rwxr-xr-x 1 root root  34K 2008-04-17 10:28 libtcliaxclient0.2.so
>

[Iaxclient-devel] How is the subclass of video packets calculated?

[Alexander V. <ava...@vo...>]

HI all,

I am examining the video code of iaxclient, and have one question. I 
cannot understand the bitwise operations used to calculate the subclass 
of video packets, in the following code:

for encoding the subclass:
fh->csub = compress_subclass(fr->af.subclass & ~0x1) | ((fr->af.subclass 
& 0x1) << 6);

for decoding the subclass:
subclass = uncompress_subclass(fh->csub & ~0x40) | ((fh->csub >> 6) & 0x1);
 
Could someone explain this, I think it would be useful to all to have 
this documented.

Best regards
Alexander Vassilev

[Iaxclient-devel] Poor sound quality

[Jean-François G. <jf....@sq...>]

Hi,

I'm affraid with the sound quality of iaxclient v2.*
I tested with old branch (v1.*) and i dunno why the sound is far better 
with it.

There is a lot of noise, and applying filter don't change anything.
(i tried each combinaisons of filters possible, DENOISE, CN, ECHO, AGC, 
AAGC)

I dunno what to do to improve this.

I try with testcall application to gu...@mi...
I'm under debian gnu/linux testing,
 - iaxclient 2.1beta3
 - portaudio :  V19 $Id: portaudio.h 1247 2007-08-11 16:29:09Z rossb $
 - speex-1.2beta3

Am i alone with this sound quality problem ?
What should i do ?

Moreover i can't use old branch because there is a bug on authentication 
methods when registering to an asterisk server.

jf

Re: [Iaxclient-devel] v2.1beta3 need patch ?

[Jean-François G. <jf....@sq...>]

Hi Pete,

Peter Grayson a écrit :
> Hi Jean-François,
>
> On Wed, Apr 16, 2008 at 2:18 PM, Jean-François Guchens
> <jf....@sq...> wrote:
>   
>> I think i've found a bug in iaxclient_lib.c :
>>  Line 1168 need to be commented. (calls[callNo].state |=
>>  IAXC_CALL_STATE_COMPLETE;)
>>     
>
> This behavior has been in iaxclient for a very long time. I will need
> more information to be convinced that the semantic here is wrong.
>
>   
ok
>>  Else when receiving an incoming call the call state is always marked as
>>  complete.
>>     
>
> Could you describe the exact scenario? I'm not sure I understand what
> the problem is. It seems like this may be related to what Ruslan
> reported earlier this week -- have you read that thread?
>
> Does this affect calls directly between iaxclient applications?
>
>   
No i didn't read this report, i'm new on iaxclient ML :-)

Here my output :
Incoming call :
 ============== STATE :  active  ringing !free : 10                      
-> ringing
 ============== STATE :  active  complete !free : 18                   
-> answered
 ============== STATE :  active  complete  selected !free : 50   -> selected

Outgoing call:
IAXCLIENT: Originating an audio only call
 ============== STATE :  outgoing  active  selected !free : 
38                    -> sending packet
IAXCLIENT: Failed video codec negotiation.
IAXCLIENT: Call 0 accepted
 ============== STATE :  outgoing  active  selected !free : 
38                    -> receive ack
IAXCLIENT: Call 0 answered
 ============== STATE :  outgoing  active  selected  ringing !free : 
46      -> ringing
IAXCLIENT: Call 0 ringing
 ============== STATE :  outgoing  active  complete  selected !free : 
54   -> complete

I test IAXC_CALL_STATE_* and print the call.state value. Don't pay 
attention to !free.

This calls are made between an iaxclient app i develop and a very basic 
phone plugged on a TDM11b, through asterisk  1.4.17.

As you can see the COMPLETE flag appear, and it's at the right time.
Before my ""patch"", this flag was alway here on outgoing calls. I think 
it's just a flag of iaxclient lib, and this don't change anything on IAX 
protocol communication.

jf
>>  I patched my local version and it works fine now.
>>     
>
> What about for calls going through asterisk?
>
> It seems like if you made an outbound call with iaxclient this change
> would prevent the call from ever getting to the completed state.
>
> Pete
>