RE: [Iaxclient-devel] Bug info... (really weird bug info)

[Steven S. <ss...@so...>]

> > Is there anything in libiax2 that automagically attempts to natively
> > couple/transfer (i.e. send audio directly point-to-point) when both
> clients
> > are IAX2 and both are using the same codec?
> >
> yep, it's always automatically attempted a native bridge. Just wondering
> why
> you'd have problems now given it's worked for ages.
> 

Stranger still, why does it seem to be a problem for the windows version but
not (at least according to some users) for the Linux version?

From what Adam says, I guess we are experiencing some kind of failure when
the native bridge fails to establish.  My configuration has the Asterisk box
on an un-NATted IP, while both clients are behind the NAT screen.  However,
I have seen the problem occur when receiving calls from other who are
outside of the NAT.  (And IAX is pretty NAT friendly anyway).

Question:  Is this only happening on Windows and if so, what is it about the
Windows version that causes the problem.

Question: If the client ultimately sends a transfer reject message back to
Asterisk, why would Asterisk stop relaying the mini-frames (i.e. why would
it assume the native transfer took place)?  From the trace I attached
before, it looks like the client sends a TXCNT message, followed by a number
of TXREJ messages.  It appears to never receive an ACK from the Asterisk for
the TXREJ message (or is it the other client it is rejecting?) so it sends
it multiple times.

Question:  if the native bridge cannot be established, why _do_ we see the
client sending a TXCNT message?  Is this simply acknowledging the client's
ability to communicate with the server?  Is this an acknowledgement of the
client's ability to communicate with the remote client?  I realize that
adding the IPs into the debug trace will help answer this...

Anybody have any thoughts?

Thanks,

Sokol