Menu
▾
▴
iaxclient-devel — Development Discussion List
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(3) |
Mar
(16) |
Apr
(11) |
May
(3) |
Jun
(109) |
Jul
(70) |
Aug
(22) |
Sep
(19) |
Oct
(4) |
Nov
(25) |
Dec
(46) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(68) |
Feb
(52) |
Mar
(54) |
Apr
(57) |
May
(13) |
Jun
(15) |
Jul
(16) |
Aug
(3) |
Sep
(43) |
Oct
(95) |
Nov
(106) |
Dec
(142) |
| 2005 |
Jan
(62) |
Feb
(190) |
Mar
(75) |
Apr
(117) |
May
(123) |
Jun
(64) |
Jul
(122) |
Aug
(95) |
Sep
(63) |
Oct
(102) |
Nov
(99) |
Dec
(85) |
| 2006 |
Jan
(59) |
Feb
(64) |
Mar
(138) |
Apr
(82) |
May
(62) |
Jun
(62) |
Jul
(72) |
Aug
(50) |
Sep
(21) |
Oct
(95) |
Nov
(95) |
Dec
(29) |
| 2007 |
Jan
(26) |
Feb
(36) |
Mar
(45) |
Apr
(12) |
May
(53) |
Jun
(38) |
Jul
(19) |
Aug
(87) |
Sep
(63) |
Oct
(272) |
Nov
(102) |
Dec
(63) |
| 2008 |
Jan
(54) |
Feb
(19) |
Mar
(84) |
Apr
(111) |
May
(17) |
Jun
(26) |
Jul
(18) |
Aug
(10) |
Sep
(14) |
Oct
(9) |
Nov
(4) |
Dec
(12) |
| 2009 |
Jan
(5) |
Feb
(7) |
Mar
(4) |
Apr
(8) |
May
(4) |
Jun
(7) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(6) |
Mar
(6) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mark S. <mar...@di...> - 2004-01-19 04:24:04
|
is it confirmed then that this is not, in fact, a bug in libiax2 but in the application using it? Are there any more patches for libiax2 that need to be merged? It would be nice to make a release. Mark On Sun, 18 Jan 2004, Michael Van Donselaar wrote: > On Sun, 18 Jan 2004 19:06:39 -0600, Steven Sokol <ss...@so...> > wrote: > > >Ok, I can't do the dance of joy yet. Somebody else here has to try this > >and agree that the solution works across the board. BUT, so far I can't > >get it to fail (which is a first for me). So.... a minor hooray is in > >order. > > I think you can start dancing. > > I've patched my local sources, and compiled Win32 and Linux-Gtk versions of > iaxComm. > > I can't get them to fail after an hour of testing. > > Plain binaries are at > http://iaxclient.sourceforge.net/iaxcomm/iaxcomm-win-test.exe and > http://iaxclient.sourceforge.net/iaxcomm/iaxcomm-lin-test > > _______________________________________________ > Asterisk-Dev mailing list > Ast...@li... > http://lists.digium.com/mailman/listinfo/asterisk-dev > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev > |
|
From: Michael V. D. <mv...@va...> - 2004-01-19 03:25:11
|
On Sun, 18 Jan 2004 19:06:39 -0600, Steven Sokol = <ss...@so...> wrote: >Ok, I can't do the dance of joy yet. Somebody else here has to try this >and agree that the solution works across the board. BUT, so far I can't >get it to fail (which is a first for me). So.... a minor hooray is in >order. I think you can start dancing. I've patched my local sources, and compiled Win32 and Linux-Gtk versions = of iaxComm. I can't get them to fail after an hour of testing. Plain binaries are at http://iaxclient.sourceforge.net/iaxcomm/iaxcomm-win-test.exe and http://iaxclient.sourceforge.net/iaxcomm/iaxcomm-lin-test |
|
From: Steven S. <ss...@so...> - 2004-01-19 01:07:56
|
Ok, I can't do the dance of joy yet. Somebody else here has to try this
and agree that the solution works across the board. BUT, so far I can't
get it to fail (which is a first for me). So.... a minor hooray is in
order.
The fix:
In iaxclient_lib.c find the function "iaxc_handle_regreply()"
Towards the bottom (line 847 on mine, but it's pretty hacked up) you
will see the following:
// XXX I think the session is no longer valid.. at least, that's
// what miniphone does, and re-using the session doesn't seem to
// work!
cur->session = NULL;
To make the fix:
// XXX I think the session is no longer valid.. at least, that's
// what miniphone does, and re-using the session doesn't seem to
// work!
iax_destroy(cur->session);
cur->session = NULL;
That's it. Just explicitly destroy the session with the
iax_destroy(cur->session); call. That seems to do it. The root of the
error seemed to be this:
When the system went to re-register, it created a session that was then
included in the pool of available sessions on the heap. Steve's
original version simply cut the session loose from the registration - it
never explicitly killed it. So the session hung around with all of its
state information intact. Somehow, and I am still trying to fathom the
specific reason, the session was then re-used for a subsequent incoming
call. Because its state information, including the InSeq and OutSeq
values were still intact from the registration interchange, the
iax_header_to_event function saw the InSeq number as not matching the
arriving event message and chucked the whole thing. Sneaky.
Please test this hypothesis and see if it holds. So far I haven't
missed a call, and I don't see any leakage of memory, handles, threads,
etc. Those of you working on the Linux version of this especially give
it a shot -- I don't have any working Linux client code.
Sorry I don't have a formal diff to present. Hopefully Steve K can make
the change on the master copy in CVS.
Good luck.
Steve
|
|
From: Steven S. <ss...@so...> - 2004-01-17 15:48:22
|
Here's the section of the trace that seems to best illustrate the issue:
17:49:52 (76041281) LOG_MESSAGE-> Tx Type: 6, Subtype:
IAX_COMMAND_ACK
Session Call Number: 26737
Peer Call Number: 3
Session In Seq Num: 2
Session Out Seq Num: 2
Sending Seq Num: 2
17:50:07 (76056281) LOG_MESSAGE-> Rx Type: 6, Subtype:
IAX_COMMAND_NEW
Session Call Number: 26733
Peer Call Number: 1
Frame Source Call: 384
Frame Dest Call: 0
Session In Seq Num: 2
Session Out Seq Num: 2
Frame In Seq Num: 0
Frame Out Seq Num: 0
17:50:07 (76056312) LOG_MESSAGE-> Packet arrived out of order (expecting
2, got 0) (frametype = 6, subclass = IAX_COMMAND_NEW)
17:50:07 (76056328) LOG_MESSAGE-> Sending Ack Anyway!
17:50:07 (76056343) LOG_MESSAGE-> Tx Type: 6, Subtype:
IAX_COMMAND_ACK
Session Call Number: 26733
Peer Call Number: 1
Session In Seq Num: 2
Session Out Seq Num: 2
Sending Seq Num: 0
Do I understand that you think the session is being recycled? That that
is the reason the InSeq and OutSeq are both set to 2 for the session? I
guess I have to dig further into iax.c to figure out how/where the
session is destroyed/created.
Do you have a copy of the whitepaper from Mark that is supposed to exist
and explain the inner workings of IAX2? I feel like I am flying a bit
blind here in that I don't have any definitive documentation as to how
it should work (except for the source which is rather silent in terms of
"here's how you do it" information).
Thanks,
Steve Sokol
-----Original Message-----
From: Steve Kann [mailto:st...@st...]
Sent: Friday, January 16, 2004 9:31 PM
To: Steven Sokol
Cc: iax...@li...; 'Dan'
Subject: Re: [Iaxclient-devel] IAX2 Client Library Bug Update - Sequence
Number Confusion?
Steve,
Sorry I haven't replied in a while. You've been doing so well, I didn't
want to get in the way :) [ and I was really busy with other things ].
So, from this, it sounds like there's some issue with the "session"
handling. Much of the session handling code the library wasn't written
by me, and even the stuff I did write I wasn't really sure about.
In this case, it seems like the iaxclient library is keeping a session
around when it should be destroying it. This problem could be libiax2
library code, and not in the iaxclient_lib handling because while in the
iaxclient_lib.c handling, we try to "shadow" the libiax2's session
handling, when the new call comes in, libiax2 is looking up the session
with iax_find_session.
If this was happening, then iax_find_session would be finding a session
that matched the new call. This should never happen.
It seems likely that somewhere, the libiax2 should be calling
destroy_session, but it isn't. There's lots of places this could happen.
You can probably find out if you look at the previous uses of session,
and how it was used last before it was re-used for this call.
It might be the registration stuff. I wasn't real sure how that all was
supposed to work in the library, so I might be doing it incorrectly. Or,
it might be that one end is hanging up or rejecting a call, and then not
destroying the associated session. Currently, I'm making a new session
for every "refresh" of the registrations, and I'm assuming it's no
longer valid when the reg reply comes in (see the big XXX in
iaxc_handle_regreply()). Maybe you need to do iax_destroy(session) at
the end of iaxc_handle_regreply()??? (This is likely to be the case;
chan_iax2.c does send_command_final when it sends the regack or regrej
back). Or, maybe libiax2 should be doing that for us. If it needs to be
done, it doesn't really matter where it's done, but maybe Mark has some
idea on whether he'd like it in his library or not. (In all other cases,
libiax2 handles destruction of sessions, even thought it does expose an
API for a caller to destroy them. We don't call that anywhere).
It looks like in your debug code that you should have enough debugging
output to see how the matching callno/dcallno was used for that
particular host right before the new call comes in. If you see that, it
should point us right to where the problem happens.
In my client, none of this is being triggered, because it is very
simple, and only makes a single, outgoing call during it's lifetime, so
I have never actually seen this problem. On the other hand, we're just
starting our alpha testing with my client, and already I've uncovered
some things I need to handle better, which will be in the library:
handling audio initialization errors in particular, handling a (reported
on the list) problem with changing devices, etc.
-SteveK
On Jan 16, 2004, at 6:20 PM, Steven Sokol wrote:
Dan,
Sorry for the HTML mail, but I wanted to be able to highlight some
things. No HTML-hater flames please.
I changed my iax.clogging again to provide additional information. I
can now see that the SESSION (i.e. the IAX line on the client) appears
to be the culprit. I originally thought that this was an Asterisk bug
(and it still could be) but I have more information now:
Good Call
Here's what we see from the Client's perspective when a "good" or
connecting call arrives:
We receive an incoming "new" message from Asterisk:
16:28:17(71109312) LOG_MESSAGE-> Rx Type: 6, Subtype:
IAX_COMMAND_NEW
Session Call Number: 11079
Peer Call Number: 1
Frame Source Call: 384
Frame DestCall: 0
Session In Seq Num: 0
SessionOut SeqNum: 0
Frame InSeqNum: 0
Frame OutSeqNum: 0
We respond with an acknowledgement, telling * that we received the
command.
16:28:17(71109328) LOG_MESSAGE->Tx Type: 6, Subtype:
IAX_COMMAND_ACK
Session Call Number: 11079
Peer Call Number: 1
Session In Seq Num: 1
SessionOut SeqNum: 0
SendingSeqNum: 0
We also send an accept message letting * know to initialize a valid
session on the server.
16:28:17(71109343) LOG_MESSAGE->Tx Type: 6, Subtype:
IAX_COMMAND_ACCEPT
Session Call Number: 11079
Peer Call Number: 1
Session In Seq Num: 1
SessionOut SeqNum: 0
SendingSeqNum: -1
Bad Call
Now here is what we see when a "bad" or non-connecting call arrives:
The same new message arrives on our system, but the sessionInSeq
andOutSeq are set to 2.
16:29:07(71159453) LOG_MESSAGE-> Rx Type: 6, Subtype:
IAX_COMMAND_NEW
Session Call Number: 11078
Peer Call Number: 3
Frame Source Call: 896
Frame DestCall: 0
Session In Seq Num: 2
SessionOut SeqNum: 2
Frame InSeqNum: 0
Frame OutSeqNum: 0
The code iniax_header_to_eventthat handles validating the ordination of
received messages chokes because the session was expecting Sequence
Number 2 and received a zero from Asterisk. This seems to point to the
session not being properly cleaned up when the previous call (or other
activity) terminated.
16:29:07(71159453) LOG_MESSAGE-> Packet arrived out of order (expecting
2, got 0) (frametype= 6, subclass = IAX_COMMAND_NEW)
The logic iniax_header_to_eventdefaults to sending the ACK message to
the server. Asterisk then expects to receive an ACCEPT message within a
few milliseconds. This never shows up because we bail out of the code as
you see below.
16:29:07(71159468) LOG_MESSAGE-> SendingAckAnyway!
16:29:07(71159484) LOG_MESSAGE->Tx Type: 6, Subtype:
IAX_COMMAND_ACK
Session Call Number: 11078
Peer Call Number: 3
Session In Seq Num: 2
SessionOut SeqNum: 2
SendingSeqNum: 0
The logic is to then bail out without returning an event. The library
assumes that the event is invalid (because of the invalid sequence
number) and simply disregards it.
16:29:07(71159484) LOG_MESSAGE-> Returning Null! Exiting In
ReSendSection!
After waiting for the ACCPET message for whatever tolerance is set in
thechan_iaxcode, the Asterisk server again tries to start a new call by
sending another NEW command. Since nothing has cleared up the InSeqand
OutSeqvalues in the session, this fails as well.
16:29:09(71161453) LOG_MESSAGE-> Rx Type: 6, Subtype:
IAX_COMMAND_NEW
Session Call Number: 11078
Peer Call Number: 3
Frame Source Call: 896
Frame DestCall: 128
Session In Seq Num: 2
SessionOut SeqNum: 2
Frame InSeqNum: 0
Frame OutSeqNum: 0
16:29:09(71161468) LOG_MESSAGE-> Packet arrived out of order (expecting
2, got 0) (frametype= 6, subclass = IAX_COMMAND_NEW)
16:29:09(71161468) LOG_MESSAGE-> SendingAckAnyway!
16:29:09(71161484) LOG_MESSAGE->Tx Type: 6, Subtype:
IAX_COMMAND_ACK
Session Call Number: 11078
Peer Call Number: 3
Session In Seq Num: 2
SessionOut SeqNum: 2
SendingSeqNum: 0
16:29:09(71161500) LOG_MESSAGE-> Returning Null! Exiting In
ReSendSection!
Summary
From what I can tell, the Sessions are held within the 'calls' variables
iniaxclient_lib.c. The 'calls' represents the virtual "lines" or
"channels" that your client allocates when you call
theiaxc_initialize(int audType,int inCalls). The session values for
each "call" must not be properly cleared when that session released by
either the remote end hanging up, or by the client dumping the call by
callingiaxc_clear_call(int toDump). I suspect that the
session'sInSeqandOutSeqshould be cleared but they are not.
I hope Steve Kann or Steve Underwood (who have much more experience
under the hood of iax2 than I) will be able to see where the issue is
taking place.
Regards,
Steven
|
|
From: Kim H. <ki...@ki...> - 2004-01-17 12:30:13
|
Hi, How can I access my IVR voice mail on Asterisk? Pressing the buttons doesn't seem to send the tones. - Kim Hendrikse |
|
From: Dan <dt...@fx...> - 2004-01-17 06:46:55
|
Hi Steven, > Sorry for the HTML mail, but I wanted to be able to highlight some > things. No HTML-hater flames please. Is more visible that way( if the client supports HTML mail)...if not, it is very difficult to read it. > Summary > >From what I can tell, the Sessions are held within the 'calls' variables > in iaxclient_lib.c. The 'calls' represents the virtual "lines" or > "channels" that your client allocates when you call the > iaxc_initialize(int audType, int inCalls). The session values for each > "call" must not be properly cleared when that session released by either > the remote end hanging up, or by the client dumping the call by calling > iaxc_clear_call(int toDump). I suspect that the session's InSeq and > OutSeq should be cleared but they are not. > As I told you in my previous mail, if you try to call (when the destination does not ring) and hangup before server resend the NEW packet, the destination rings a little bit. This mean that if the server will send the NEW packet a little bit later, is possible that this bug to be solved (or in libiax2 to send ACCEPT packet faster). Best regards, Dan P.S. I have no deep knowledge on IAX protocol, so it is just an idea. |
|
From: Steve K. <st...@st...> - 2004-01-17 03:31:09
|
Steve, Sorry I haven't replied in a while. You've been doing so well, = I=20 didn't want to get in the way :) [ and I was really busy with other=20 things ]. So, from this, it sounds like there's some issue with the = "session"=20 handling. Much of the session handling code the library wasn't=20 written by me, and even the stuff I did write I wasn't really sure=20 about. In this case, it seems like the iaxclient library is keeping a = session=20 around when it should be destroying it. This problem could be libiax2=20= library code, and not in the iaxclient_lib handling because while in=20 the iaxclient_lib.c handling, we try to "shadow" the libiax2's session=20= handling, when the new call comes in, libiax2 is looking up the session=20= with iax_find_session. If this was happening, then iax_find_session would be finding a=20= session that matched the new call. This should never happen. It seems likely that somewhere, the libiax2 should be calling=20 destroy_session, but it isn't. There's lots of places this could=20 happen. You can probably find out if you look at the previous uses of=20= session, and how it was used last before it was re-used for this call. It might be the registration stuff. I wasn't real sure how that = all=20 was supposed to work in the library, so I might be doing it=20 incorrectly. Or, it might be that one end is hanging up or rejecting=20= a call, and then not destroying the associated session. Currently, I'm=20= making a new session for every "refresh" of the registrations, and I'm=20= assuming it's no longer valid when the reg reply comes in (see the big=20= XXX in iaxc_handle_regreply()). Maybe you need to do=20 iax_destroy(session) at the end of iaxc_handle_regreply()??? (This is=20= likely to be the case; chan_iax2.c does send_command_final when it=20 sends the regack or regrej back). Or, maybe libiax2 should be doing=20 that for us. If it needs to be done, it doesn't really matter where=20 it's done, but maybe Mark has some idea on whether he'd like it in his=20= library or not. (In all other cases, libiax2 handles destruction of=20 sessions, even thought it does expose an API for a caller to destroy=20 them. We don't call that anywhere). It looks like in your debug code that you should have enough = debugging=20 output to see how the matching callno/dcallno was used for that=20 particular host right before the new call comes in. If you see that, it=20= should point us right to where the problem happens. In my client, none of this is being triggered, because it is = very=20 simple, and only makes a single, outgoing call during it's lifetime, so=20= I have never actually seen this problem. On the other hand, we're just=20= starting our alpha testing with my client, and already I've uncovered=20 some things I need to handle better, which will be in the library: =20 handling audio initialization errors in particular, handling a=20 (reported on the list) problem with changing devices, etc. -SteveK On Jan 16, 2004, at 6:20 PM, Steven Sokol wrote: > Dan, > > > Sorry for the HTML mail, but I wanted to be able to highlight some=20 > things.=A0No HTML-hater flames please. > > =A0 > > I changed my iax.clogging again to provide additional information.=A0 = I=20 > can now see that the SESSION (i.e. the IAX line on the client) appears=20= > to be the culprit.=A0 I originally thought that this was an Asterisk = bug=20 > (and it still could be) but I have more information now: > > =A0 > > Good Call > > Here's what we see from the Client's perspective when a "good" or=20 > connecting call arrives: > > =A0 > > We receive an incoming =93new=94 message from Asterisk: > > 16:28:17(71109312) LOG_MESSAGE-> Rx=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Type= : 6, Subtype:=20 > IAX_COMMAND_NEW > > =A0=A0=A0=A0=A0=A0Session Call Number: 11079 > > =A0=A0=A0=A0=A0=A0Peer Call Number:=A0=A0 1 > > =A0=A0=A0=A0=A0=A0Frame Source Call:=A0=A0=A0=A0=A0=A0=A0 384 > > =A0=A0=A0=A0=A0=A0Frame DestCall:=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 > > =A0=A0=A0=A0=A0=A0Session In Seq Num:=A0=A0=A0=A0=A0=A0 0 > > SessionOut SeqNum:=A0=A0=A0=A0=A0 0 > > =A0=A0=A0=A0=A0=A0Frame InSeqNum:=A0=A0=A0=A0=A0=A0=A0=A0 0 > > =A0=A0=A0=A0=A0=A0Frame OutSeqNum:=A0=A0=A0=A0=A0=A0=A0 0 > > =A0 > > We respond with an acknowledgement, telling * that we received the=20 > command. > > 16:28:17(71109328) LOG_MESSAGE->Tx=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Type:= 6, Subtype:=20 > IAX_COMMAND_ACK > > =A0=A0=A0=A0=A0=A0Session Call Number: 11079 > > =A0=A0=A0=A0=A0=A0Peer Call Number:=A0=A0 1 > > =A0=A0=A0=A0=A0=A0Session In Seq Num:=A0=A0=A0=A0=A0=A0 1 > > =A0=A0=A0=A0=A0=A0SessionOut SeqNum:=A0=A0=A0=A0=A0 0 > > =A0=A0=A0=A0=A0=A0SendingSeqNum:=A0=A0=A0 0 > > =A0 > > We also send an accept message letting * know to initialize a valid=20 > session on the server. > > 16:28:17(71109343) LOG_MESSAGE->Tx=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Type:= 6, Subtype:=20 > IAX_COMMAND_ACCEPT > > =A0=A0=A0=A0=A0=A0Session Call Number: 11079 > > =A0=A0=A0=A0=A0=A0Peer Call Number:=A0=A0 1 > > =A0=A0=A0=A0=A0=A0Session In Seq Num:=A0=A0=A0=A0=A0=A0 1 > > =A0=A0=A0=A0=A0=A0SessionOut SeqNum:=A0=A0=A0=A0=A0 0 > > =A0=A0=A0=A0=A0=A0SendingSeqNum:=A0=A0=A0 -1 > > =A0 > > Bad Call > > Now here is what we see when a "bad" or non-connecting call arrives: > > =A0 > > The same new message arrives on our system, but the sessionInSeq=20 > andOutSeq are set to 2. > > 16:29:07(71159453) LOG_MESSAGE-> Rx=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Type= : 6, Subtype:=20 > IAX_COMMAND_NEW > > =A0=A0=A0=A0=A0=A0Session Call Number: 11078 > > =A0=A0=A0=A0=A0=A0Peer Call Number:=A0=A0 3 > > =A0=A0=A0=A0=A0=A0Frame Source Call:=A0=A0=A0=A0=A0=A0=A0 896 > > =A0=A0=A0=A0=A0=A0Frame DestCall:=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 > > =A0=A0=A0=A0=A0=A0Session In Seq Num:=A0=A0=A0=A0=A0=A0 2 > > SessionOut SeqNum:=A0=A0=A0=A0=A0 2 > > =A0=A0=A0=A0=A0=A0Frame InSeqNum:=A0=A0=A0=A0=A0=A0=A0=A0 0 > > =A0=A0=A0=A0=A0=A0Frame OutSeqNum:=A0=A0=A0=A0=A0=A0=A0 0 > > =A0 > > The code iniax_header_to_eventthat handles validating the ordination=20= > of received messages chokes because the session was expecting Sequence=20= > Number 2 and received a zero from Asterisk.=A0This seems to point to = the=20 > session not being properly cleaned up when the previous call (or other=20= > activity) terminated. > > 16:29:07(71159453) LOG_MESSAGE-> Packet arrived out of order=20 > (expecting 2, got 0) (frametype=3D 6, subclass =3D IAX_COMMAND_NEW) > > =A0 > > The logic iniax_header_to_eventdefaults to sending the ACK message to=20= > the server.=A0Asterisk then expects to receive an ACCEPT message = within=20 > a few milliseconds.=A0This never shows up because we bail out of the=20= > code as you see below. > > 16:29:07(71159468) LOG_MESSAGE-> SendingAckAnyway! > > 16:29:07(71159484) LOG_MESSAGE->Tx=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Type:= 6, Subtype:=20 > IAX_COMMAND_ACK > > =A0=A0=A0=A0=A0=A0Session Call Number:=A0=A0=A0=A0=A0=A011078 > > =A0=A0=A0=A0=A0=A0Peer Call Number:=A0=A0=A0=A0=A0=A0=A0=A0 3 > > =A0=A0=A0=A0=A0=A0Session In Seq Num:=A0=A0=A0=A0=A0=A0 2 > > =A0=A0=A0=A0=A0=A0SessionOut SeqNum:=A0=A0=A0=A0=A0 2 > > =A0=A0=A0=A0=A0=A0SendingSeqNum:=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 > > =A0 > > The logic is to then bail out without returning an event.=A0 The = library=20 > assumes that the event is invalid (because of the invalid sequence=20 > number) and simply disregards it. > > 16:29:07(71159484) LOG_MESSAGE-> Returning Null! Exiting In=20 > ReSendSection! > > =A0 > > After waiting for the ACCPET message for whatever tolerance is set in=20= > thechan_iaxcode, the Asterisk server again tries to start a new call=20= > by sending another NEW command.=A0Since nothing has cleared up the=20 > InSeqand OutSeqvalues in the session, this fails as well. > > 16:29:09(71161453) LOG_MESSAGE-> Rx=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Type= : 6, Subtype:=20 > IAX_COMMAND_NEW > > =A0=A0=A0=A0=A0=A0Session Call Number:=A0=A0=A0=A0=A0=A011078 > > =A0=A0=A0=A0=A0=A0Peer Call Number:=A0=A0=A0=A0=A0=A0=A0=A0 3 > > =A0=A0=A0=A0=A0=A0Frame Source Call:=A0=A0=A0=A0=A0=A0=A0 896 > > =A0=A0=A0=A0=A0=A0Frame DestCall:=A0=A0=A0=A0=A0=A0=A0=A0=A0 128 > > =A0=A0=A0=A0=A0=A0Session In Seq Num:=A0=A0=A0=A0=A0=A0 2 > > =A0=A0=A0=A0=A0=A0SessionOut SeqNum:=A0=A0=A0=A0=A0 2 > > =A0=A0=A0=A0=A0=A0Frame InSeqNum:=A0=A0=A0=A0=A0=A0=A0=A0 0 > > =A0=A0=A0=A0=A0=A0Frame OutSeqNum:=A0=A0=A0=A0=A0=A0=A0 0 > > =A0 > > 16:29:09(71161468) LOG_MESSAGE-> Packet arrived out of order=20 > (expecting 2, got 0) (frametype=3D 6, subclass =3D IAX_COMMAND_NEW) > > 16:29:09(71161468) LOG_MESSAGE-> SendingAckAnyway! > > 16:29:09(71161484) LOG_MESSAGE->Tx=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Type:= 6, Subtype:=20 > IAX_COMMAND_ACK > > =A0=A0=A0=A0=A0=A0Session Call Number:=A0=A0=A0=A0=A0=A011078 > > =A0=A0=A0=A0=A0=A0Peer Call Number:=A0=A0=A0=A0=A0=A0=A0=A0 3 > > =A0=A0=A0=A0=A0=A0Session In Seq Num:=A0=A0=A0=A0=A0=A0 2 > > =A0=A0=A0=A0=A0=A0SessionOut SeqNum:=A0=A0=A0=A0=A0 2 > > =A0=A0=A0=A0=A0=A0SendingSeqNum:=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 > > =A0 > > 16:29:09(71161500) LOG_MESSAGE-> Returning Null! Exiting In=20 > ReSendSection! > > =A0 > > Summary > > =46rom what I can tell, the Sessions are held within the =91calls=92=20= > variables iniaxclient_lib.c.=A0 The =91calls=92 represents the virtual=20= > =93lines=94 or =93channels=94 that your client allocates when you call=20= > theiaxc_initialize(int audType,int inCalls).=A0 The session values for=20= > each =93call=94 must not be properly cleared when that session = released by=20 > either the remote end hanging up, or by the client dumping the call by=20= > callingiaxc_clear_call(int toDump).=A0 I suspect that the=20 > session=92sInSeqandOutSeqshould be cleared but they are not. > > =A0 > > I hope Steve Kann or Steve Underwood (who have much more experience=20 > under the hood of iax2 than I) will be able to see where the issue is=20= > taking place. > > =A0 > > Regards, > > =A0 > > Steven |
|
From: Steven S. <ss...@so...> - 2004-01-16 23:21:32
|
Dan,
Sorry for the HTML mail, but I wanted to be able to highlight some
things. No HTML-hater flames please.
I changed my iax.c logging again to provide additional information. I
can now see that the SESSION (i.e. the IAX line on the client) appears
to be the culprit. I originally thought that this was an Asterisk bug
(and it still could be) but I have more information now:
Good Call
Here's what we see from the Client's perspective when a "good" or
connecting call arrives:
We receive an incoming "new" message from Asterisk:
16:28:17 (71109312) LOG_MESSAGE-> Rx Type: 6, Subtype:
IAX_COMMAND_NEW
Session Call Number: 11079
Peer Call Number: 1
Frame Source Call: 384
Frame Dest Call: 0
Session In Seq Num: 0
Session Out Seq Num: 0
Frame In Seq Num: 0
Frame Out Seq Num: 0
We respond with an acknowledgement, telling * that we received the
command.
16:28:17 (71109328) LOG_MESSAGE-> Tx Type: 6, Subtype:
IAX_COMMAND_ACK
Session Call Number: 11079
Peer Call Number: 1
Session In Seq Num: 1
Session Out Seq Num: 0
Sending Seq Num: 0
We also send an accept message letting * know to initialize a valid
session on the server.
16:28:17 (71109343) LOG_MESSAGE-> Tx Type: 6, Subtype:
IAX_COMMAND_ACCEPT
Session Call Number: 11079
Peer Call Number: 1
Session In Seq Num: 1
Session Out Seq Num: 0
Sending Seq Num: -1
Bad Call
Now here is what we see when a "bad" or non-connecting call arrives:
The same new message arrives on our system, but the session InSeq and
OutSeq are set to 2.
16:29:07 (71159453) LOG_MESSAGE-> Rx Type: 6, Subtype:
IAX_COMMAND_NEW
Session Call Number: 11078
Peer Call Number: 3
Frame Source Call: 896
Frame Dest Call: 0
Session In Seq Num: 2
Session Out Seq Num: 2
Frame In Seq Num: 0
Frame Out Seq Num: 0
The code in iax_header_to_event that handles validating the ordination
of received messages chokes because the session was expecting Sequence
Number 2 and received a zero from Asterisk. This seems to point to the
session not being properly cleaned up when the previous call (or other
activity) terminated.
16:29:07 (71159453) LOG_MESSAGE-> Packet arrived out of order (expecting
2, got 0) (frametype = 6, subclass = IAX_COMMAND_NEW)
The logic in iax_header_to_event defaults to sending the ACK message to
the server. Asterisk then expects to receive an ACCEPT message within a
few milliseconds. This never shows up because we bail out of the code
as you see below.
16:29:07 (71159468) LOG_MESSAGE-> Sending Ack Anyway!
16:29:07 (71159484) LOG_MESSAGE-> Tx Type: 6, Subtype:
IAX_COMMAND_ACK
Session Call Number: 11078
Peer Call Number: 3
Session In Seq Num: 2
Session Out Seq Num: 2
Sending Seq Num: 0
The logic is to then bail out without returning an event. The library
assumes that the event is invalid (because of the invalid sequence
number) and simply disregards it.
16:29:07 (71159484) LOG_MESSAGE-> Returning Null! Exiting In ReSend
Section!
After waiting for the ACCPET message for whatever tolerance is set in
the chan_iax code, the Asterisk server again tries to start a new call
by sending another NEW command. Since nothing has cleared up the InSeq
and OutSeq values in the session, this fails as well.
16:29:09 (71161453) LOG_MESSAGE-> Rx Type: 6, Subtype:
IAX_COMMAND_NEW
Session Call Number: 11078
Peer Call Number: 3
Frame Source Call: 896
Frame Dest Call: 128
Session In Seq Num: 2
Session Out Seq Num: 2
Frame In Seq Num: 0
Frame Out Seq Num: 0
16:29:09 (71161468) LOG_MESSAGE-> Packet arrived out of order (expecting
2, got 0) (frametype = 6, subclass = IAX_COMMAND_NEW)
16:29:09 (71161468) LOG_MESSAGE-> Sending Ack Anyway!
16:29:09 (71161484) LOG_MESSAGE-> Tx Type: 6, Subtype:
IAX_COMMAND_ACK
Session Call Number: 11078
Peer Call Number: 3
Session In Seq Num: 2
Session Out Seq Num: 2
Sending Seq Num: 0
16:29:09 (71161500) LOG_MESSAGE-> Returning Null! Exiting In ReSend
Section!
Summary
From what I can tell, the Sessions are held within the 'calls' variables
in iaxclient_lib.c. The 'calls' represents the virtual "lines" or
"channels" that your client allocates when you call the
iaxc_initialize(int audType, int inCalls). The session values for each
"call" must not be properly cleared when that session released by either
the remote end hanging up, or by the client dumping the call by calling
iaxc_clear_call(int toDump). I suspect that the session's InSeq and
OutSeq should be cleared but they are not.
I hope Steve Kann or Steve Underwood (who have much more experience
under the hood of iax2 than I) will be able to see where the issue is
taking place.
Regards,
Steven
|
|
From: Steven S. <ss...@so...> - 2004-01-16 18:55:35
|
Greetings. Here's a puzzler for you. I have been working with a number
of people, including Mark Spencer to try to track down this bug. The
bizarre thing that seems to be happening is this: when a NEW call
message arrives from the Asterisk server, it should have an inbound
sequence number (iseqno) of 0. However, it appears that, for the calls
that fail, the sequence number is incorrectly set to 2. Is this done by
Asterisk when it sends? By libiax2 when it receives? Therein lies the
mystery.
This is seen in both the trace from Asterisk and from my tracing. (Both
of which are included below for your reading pleasure.) From what I can
fathom from the chan_iax2 code, each time a call is started using the
IAX_COMMAND_NEW subtype, the sequence number SHOULD be zero. From the
perspective of the chan_iax2.c code in Asterisk, the IAX_COMMAND_NEW
message is always sent by calling the send_command function and passing
a sequence number of -1. Follow:
1. send_command(...) function calls the __send_command function.
2. __send_command(...) in turn calls iax2_send(...) function passing
along the seqno = -1
3. iax2_send(...) sets the oseqno based on the seqno passed. If seqno >
-1 (which it ain't) the frame's outgoing sequence number is set to the
seqno passed in.
4. In our case, the seqno IS -1, so the outgoing (oseqno) sequence
number is set to the value of the channel's oseqno + 1 (oseqno++).
5. In either case, the iseqno is set to the channel's iseqno value.
6. An IAX header frame (fh) is created.
7. The frame header's call number (callno) is set to the frame's call
number.
8. The frame header's oseqno is set to the frame's oseqno.
9. As long as the call is not a transfer, the frame header's iseqno is
set to the frame's seqno.
10. The frame is packetized and sent.
This can all be seen in chan_iax2.c lines 2408 - 2421.
Here's what the iax2 debugging shows:
{{{{{{{{{{{{{{{{{{{{{ GOOD CALL HERE }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
-- Executing Dial("SIP/1101-bf98", "IAX2/1105|30") in new stack
-- Called 1105
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
NEW
Timestamp: 00001ms SCall: 00007 DCall: 00000 [64.151.42.28:4569]
VERSION : 2
CALLED NUMBER : s
CALLING NUMBER : 1101
CALLING NAME : Steven Sokol
LANGUAGE : en
FORMAT : 2
CAPABILITY : 2
ADSICPE : 2
DATE TIME : 137389161
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass:
ACK
Timestamp: 00001ms SCall: 30543 DCall: 00007 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass:
ACCEPT
Timestamp: 00016ms SCall: 30543 DCall: 00007 [64.151.42.28:4569]
-- Call accepted by 64.151.42.28 (format GSM)
-- Format for call is GSM
Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass:
ACK
Timestamp: 00016ms SCall: 00007 DCall: 30543 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass:
RINGING
Timestamp: 00031ms SCall: 30543 DCall: 00007 [64.151.42.28:4569]
Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 00031ms SCall: 00007 DCall: 30543 [64.151.42.28:4569]
-- IAX2[1105]/7 is ringing
Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass:
ANSWER
Timestamp: 02766ms SCall: 30543 DCall: 00007 [64.151.42.28:4569]
Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass:
ACK
Timestamp: 02766ms SCall: 00007 DCall: 30543 [64.151.42.28:4569]
-- IAX2[1105]/7 answered SIP/1101-bf98
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 003 Type: VOICE Subclass: 2
Timestamp: 02815ms SCall: 00007 DCall: 30543 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 001 Type: VOICE Subclass: 2
Timestamp: 02797ms SCall: 30543 DCall: 00007 [64.151.42.28:4569]
Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 004 Type: IAX Subclass:
ACK
Timestamp: 02797ms SCall: 00007 DCall: 30543 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 02797ms SCall: 30543 DCall: 00007 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass:
HANGUP
Timestamp: 06031ms SCall: 30543 DCall: 00007 [64.151.42.28:4569]
CAUSE : Dumped Call
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 005 Type: IAX Subclass:
ACK
Timestamp: 06031ms SCall: 00007 DCall: 30543 [64.151.42.28:4569]
-- Hungup 'IAX2[1105]/7'
== Spawn extension (default, 1109, 1) exited non-zero on
'SIP/1101-bf98'
Rx-Frame Retry[Yes] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass:
HANGUP
Timestamp: 06031ms SCall: 30543 DCall: 00007 [64.151.42.28:4569]
CAUSE : Dumped Call
{{{{{{{{{{{{{{{{{{{{{{ REGISTRATION HERE
}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
REGREQ
Timestamp: 00001ms SCall: 30544 DCall: 00000 [64.151.42.28:4569]
USERNAME : 1105
REFRESH : 60
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass:
REGAUTH
Timestamp: 00001ms SCall: 00004 DCall: 30544 [64.151.42.28:4569]
AUTHMETHODS : 7
CHALLENGE : 179726065
USERNAME : 1105
Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass:
REGREQ
Timestamp: 00047ms SCall: 30544 DCall: 00004 [64.151.42.28:4569]
USERNAME : 1105
REFRESH : 60
MD5 RESULT : 5f74d808d3b1216dd6fec0daf0dafd74
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass:
REGACK
Timestamp: 00036ms SCall: 00004 DCall: 30544 [64.151.42.28:4569]
USERNAME : 1105
REFRESH : 60
DATE TIME : 137389167
APPARENT ADDRES : IPV4 64.151.42.28:4569
CALLING NAME : "Steve 1105" <(816) 822-1807>
Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 00036ms SCall: 30544 DCall: 00004 [64.151.42.28:4569]
{{{{{{{{{{{{{ GOOD CALL HERE - ABORTED BEFORE ANSWER
}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
-- Executing Dial("SIP/1101-c1ed", "IAX2/1105|30") in new stack
-- Called 1105
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
NEW
Timestamp: 00001ms SCall: 00005 DCall: 00000 [64.151.42.28:4569]
VERSION : 2
CALLED NUMBER : s
CALLING NUMBER : 1101
CALLING NAME : Steven Sokol
LANGUAGE : en
FORMAT : 2
CAPABILITY : 2
ADSICPE : 2
DATE TIME : 137389171
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass:
ACK
Timestamp: 00001ms SCall: 30545 DCall: 00005 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass:
ACCEPT
Timestamp: 00015ms SCall: 30545 DCall: 00005 [64.151.42.28:4569]
-- Call accepted by 64.151.42.28 (format GSM)
-- Format for call is GSM
Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass:
ACK
Timestamp: 00015ms SCall: 00005 DCall: 30545 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass:
RINGING
Timestamp: 00031ms SCall: 30545 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 00031ms SCall: 00005 DCall: 30545 [64.151.42.28:4569]
-- IAX2[1105]/5 is ringing
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass:
HANGUP
Timestamp: 02018ms SCall: 00005 DCall: 30545 [64.151.42.28:4569]
-- Hungup 'IAX2[1105]/5'
== Spawn extension (default, 1109, 1) exited non-zero on
'SIP/1101-c1ed'
Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 02018ms SCall: 30545 DCall: 00005 [64.151.42.28:4569]
{{{{{{{{{{{{BAD CALL
HERE}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
-- Executing Dial("SIP/1101-6144", "IAX2/1105|30") in new stack
-- Called 1105
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
NEW
Timestamp: 00001ms SCall: 00006 DCall: 00000 [64.151.42.28:4569]
VERSION : 2
CALLED NUMBER : s
CALLING NUMBER : 1101
CALLING NAME : Steven Sokol
LANGUAGE : en
FORMAT : 2
CAPABILITY : 2
ADSICPE : 2
DATE TIME : 137389176
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 00001ms SCall: 30540 DCall: 00006 [64.151.42.28:4569]
Tx-Frame Retry[001] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
NEW
Timestamp: 00001ms SCall: 00006 DCall: 00000 [64.151.42.28:4569]
VERSION : 2
CALLED NUMBER : s
CALLING NUMBER : 1101
CALLING NAME : Steven Sokol
LANGUAGE : en
FORMAT : 2
CAPABILITY : 2
ADSICPE : 2
DATE TIME : 137389176
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 00001ms SCall: 30540 DCall: 00006 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 000 Type: IAX Subclass:
LAGRQ
Timestamp: 10002ms SCall: 00006 DCall: 30540 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
REGREQ
Timestamp: 00001ms SCall: 00001 DCall: 00000 [69.73.19.178:4569]
USERNAME : ssokol01
REFRESH : 60
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass:
REGAUTH
Timestamp: 00001ms SCall: 00190 DCall: 00001 [69.73.19.178:4569]
AUTHMETHODS : 3
CHALLENGE : 187891203
USERNAME : ssokol01
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass:
REGREQ
Timestamp: 00053ms SCall: 00001 DCall: 00190 [69.73.19.178:4569]
USERNAME : ssokol01
REFRESH : 60
MD5 RESULT : 0b907bfdb681b46d9696baba55388b34
Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass:
REGACK
Timestamp: 00049ms SCall: 00190 DCall: 00001 [69.73.19.178:4569]
USERNAME : ssokol01
REFRESH : 60
DATE TIME : 137388674
APPARENT ADDRES : IPV4 64.151.32.77:4569
CALLING NAME : "Steven Sokol" <(700) 613-9004>
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 00049ms SCall: 00001 DCall: 00190 [69.73.19.178:4569]
Tx-Frame Retry[001] -- OSeqno: 001 ISeqno: 000 Type: IAX Subclass:
LAGRQ
Timestamp: 10002ms SCall: 00006 DCall: 30540 [64.151.42.28:4569]
Tx-Frame Retry[002] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
NEW
Timestamp: 00001ms SCall: 00006 DCall: 00000 [64.151.42.28:4569]
VERSION : 2
CALLED NUMBER : s
CALLING NUMBER : 1101
CALLING NAME : Steven Sokol
LANGUAGE : en
FORMAT : 2
CAPABILITY : 2
ADSICPE : 2
DATE TIME : 137389176
-- Hungup 'IAX2[1105]/6'
== Spawn extension (default, 1109, 1) exited non-zero on
'SIP/1101-6144'
Tx-Frame Retry[000] -- OSeqno: 002 ISeqno: 000 Type: IAX Subclass:
HANGUP
Timestamp: 13617ms SCall: 00006 DCall: 30540 [64.151.42.28:4569]
Tx-Frame Retry[001] -- OSeqno: 002 ISeqno: 000 Type: IAX Subclass:
HANGUP
Timestamp: 13617ms SCall: 00006 DCall: 30540 [64.151.42.28:4569]
Here's what my client log shows:
{{{{{{{{{{{{{{{{{{{{ GOOD CALL }}}}}}}}}}}}}}}}}}}}}}}}}}}}}
12:34:36 (57093781) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1920
DestCall: 0 InSequ: 0 OutSequ: 0 Type: 6
Subclass: IAX_COMMAND_NEW
12:34:36 (57093796) LOG_MESSAGE-> COMMAND SENT: Sequence: 0 Type: 6
Subclass: IAX_COMMAND_ACK
12:34:36 (57093812) LOG_MESSAGE-> COMMAND SENT: Sequence: -1 Type: 6
Subclass: IAX_COMMAND_ACCEPT
12:34:36 (57093828) LOG_MESSAGE-> COMMAND SENT: Sequence: -1 Type: 4
Subclass: IAX_COMMAND_PONG
12:34:36 (57093843) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1920
DestCall: 20343 InSequ: 1 OutSequ: 1 Type: 6
Subclass: IAX_COMMAND_ACK
12:34:36 (57093859) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1920
DestCall: 20343 InSequ: 1 OutSequ: 1 Type: 6
Subclass: IAX_COMMAND_ACK
12:34:39 (57096562) LOG_MESSAGE-> COMMAND SENT: Sequence: -1 Type: 4
Subclass: IAX_COMMAND_ACK
12:34:39 (57096609) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1920
DestCall: 20343 InSequ: 1 OutSequ: 1 Type: 6
Subclass: IAX_COMMAND_ACK
12:34:39 (57096625) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1920
DestCall: 20343 InSequ: 2 OutSequ: 1 Type: 6
Subclass: IAX_COMMAND_ACK
12:34:39 (57096640) LOG_MESSAGE-> COMMAND SENT: Sequence: 4 Type: 6
Subclass: IAX_COMMAND_ACK
12:34:42 (57099828) LOG_MESSAGE-> COMMAND SENT: Sequence: -1 Type: 6
Subclass: IAX_COMMAND_HANGUP
12:34:42 (57100062) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1920
DestCall: 20343 InSequ: 2 OutSequ: 2 Type: 6
Subclass: IAX_COMMAND_ACK
12:34:42 (57100078) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1920
DestCall: 20343 InSequ: 2 OutSequ: 0 Type: 6
Subclass: IAX_COMMAND_INVAL
{{{{{{{{{{{{{{{{{{{{{ REGISTRATION }}}}}}}}}}}}}}}}}}}}}}}}
12:34:48 (57105796) LOG_MESSAGE-> COMMAND SENT: Sequence: -1 Type: 6
Subclass: IAX_COMMAND_REGREQ
12:34:48 (57105812) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1152
DestCall: 20599 InSequ: 0 OutSequ: 0 Type: 6
Subclass: IAX_COMMAND_REGAUTH
12:34:48 (57105828) LOG_MESSAGE-> COMMAND SENT: Sequence: -1 Type: 6
Subclass: IAX_COMMAND_REGREQ
12:34:48 (57105843) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1152
DestCall: 20599 InSequ: 1 OutSequ: 1 Type: 6
Subclass: IAX_COMMAND_REGACK
12:34:48 (57105859) LOG_MESSAGE-> COMMAND SENT: Sequence: 2 Type: 6
Subclass: IAX_COMMAND_ACK
{{{{{{{{{{{{{{{{{{{{ GOOD CALL - ABORTED BEFORE ANSWER
}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
12:34:55 (57112250) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1408
DestCall: 0 InSequ: 0 OutSequ: 0 Type: 6
Subclass: IAX_COMMAND_NEW
12:34:55 (57112265) LOG_MESSAGE-> COMMAND SENT: Sequence: 0 Type: 6
Subclass: IAX_COMMAND_ACK
12:34:55 (57112281) LOG_MESSAGE-> COMMAND SENT: Sequence: -1 Type: 6
Subclass: IAX_COMMAND_ACCEPT
12:34:55 (57112296) LOG_MESSAGE-> COMMAND SENT: Sequence: -1 Type: 4
Subclass: IAX_COMMAND_PONG
12:34:55 (57112312) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1408
DestCall: 20855 InSequ: 1 OutSequ: 1 Type: 6
Subclass: IAX_COMMAND_ACK
12:34:55 (57112312) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1408
DestCall: 20855 InSequ: 1 OutSequ: 1 Type: 6
Subclass: IAX_COMMAND_ACK
12:34:57 (57114265) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1408
DestCall: 20855 InSequ: 1 OutSequ: 1 Type: 6
Subclass: IAX_COMMAND_HANGUP
12:34:57 (57114281) LOG_MESSAGE-> COMMAND SENT: Sequence: 2 Type: 6
Subclass: IAX_COMMAND_ACK
{{{{{{{{{{{{ BAD CALL }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
12:35:06 (57123500) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1664
DestCall: 0 InSequ: 2 OutSequ: 0 Type: 6
Subclass: IAX_COMMAND_NEW
12:35:06 (57123515) LOG_MESSAGE-> Packet arrived out of order (expecting
2, got 0) (frametype = 6, subclass = IAX_COMMAND_NEW)
12:35:06 (57123531) LOG_MESSAGE-> Sending Ack Anyway!
12:35:06 (57123546) LOG_MESSAGE-> COMMAND SENT: Sequence: 0 Type: 6
Subclass: IAX_COMMAND_ACK
12:35:06 (57123562) LOG_MESSAGE-> Returning Null! Exiting In ReSend
Section!
12:35:08 (57125515) LOG_MESSAGE-> COMMAND RECEIVED: SourceCall: 1664
DestCall: 128 InSequ: 2 OutSequ: 0 Type: 6
Subclass: IAX_COMMAND_NEW
12:35:08 (57125531) LOG_MESSAGE-> Packet arrived out of order (expecting
2, got 0) (frametype = 6, subclass = IAX_COMMAND_NEW)
12:35:08 (57125531) LOG_MESSAGE-> Sending Ack Anyway!
12:35:08 (57125546) LOG_MESSAGE-> COMMAND SENT: Sequence: 0 Type: 6
Subclass: IAX_COMMAND_ACK
12:35:08 (57125562) LOG_MESSAGE-> Returning Null! Exiting In ReSend
Section!
Look at the last section (bad call) of both the asterisk trace and my
trace. Does anybody have any idea what is going on here with the
sequence numbers? Is sure looks like asterisk thinks it is sending us
sequence number zero for the new call, but we are seeing it as sequence
number 2. I don't know where the tracing that asterisk generates is
done, but somewhere, on one side of the network or the other, the
sequence number is getting miss-set to 2.
When we get sequence number 2, we see it as out of order. We simply
send and an ACK. We never send the ACCEPT that needs to follow in order
to start the conversation. As you can see, get a repeated NEW message
again with the buggered iseqno, and again we simply ACK it. After a
while asterisk gives up and destroys the call.
Can SOMEBODY knowledgeable PLEASE take a look at both the client library
and chan_iax2 and fathom where this number is being miss set. I am
working at the very upper range of my capabilities here. (Remember, I
am primarily a windows weenie).
Thanks!
Steve Sokol
|
|
From: Steven S. <ss...@so...> - 2004-01-14 18:43:59
|
Iaxclient-dev members, please pardon the recap. Everybody please pardon the cross-post. I just wanted as many knowledgeable eyes on this as I could get. For the past several months I have been working with the iaxclient library in an attempt to make a powerful, multi-function IAX/IAX2 client that works on the Windows platform. The one major stumbling block that I run into is this: the client seems to stop responding to inbound call requests (i.e. it don't ring when it should ring) after some period of time or event. After tracking the issue as best I can (I am no c-language genius and have little experience with gcc/gdb) I have found out where the error is occurring. It seems that the sequence tracker in the iax_header_to_event function in the iax.c file of libiax2 is somehow getting messages out-of-sequence. Below is a make-shift trace that shows a registration sequence and several calls that are handled by the client. The trace logs both sent and received command messages. I don't understand the messaging sequence enough to figure out why this is occurring. Steve Underwood apparently fixed this issue (or the issue was never as bad) when running under Linux. It appears to be specific to the IAX2 protocol (IAX1 does not seem to loose messages) running on Win32. Oddly, it seems to be much more prevalent with connections from my local Asterisk server than from IAXtel (which I have used for testing). Below is the trace with all of the commands sent/received. Attached is the version of the iax.c file that I hacked. Please forgive my ugly C coding. It was a quick/dirty operation. I would greatly appreciate any insight as to how the messaging sequence works, and what could be causing it to get out of wack. Additional info can be had from the iaxclient-dev list archive (previous posts on this topic). Please feel free to contact me directly. My phone number is [IAXTel] 1-700-613-9004, [PSTN} 1-826-822-1807. Thanks! Steve [Client Starts And Registers] 12:13:10 (59914093) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:13:10 (59914109) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_REGAUTH 12:13:10 (59914109) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:13:10 (59914125) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_REGACK 12:13:10 (59914125) LOG_MESSAGE-> COMMAND SENT: Sequence: 2, Type: 6, Subclass: IAX_COMMAND_ACK [Successful Inbound Call (SIP UA to IAX Client)] 12:13:18 (59922625) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_NEW 12:13:18 (59922640) LOG_MESSAGE-> COMMAND SENT: Sequence: 0, Type: 6, Subclass: IAX_COMMAND_ACK 12:13:18 (59922656) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_ACCEPT 12:13:18 (59922656) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 4, Subclass: IAX_COMMAND_PONG 12:13:18 (59922671) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_ACK 12:13:18 (59922671) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_ACK 12:13:20 (59924453) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 4, Subclass: IAX_COMMAND_ACK 12:13:20 (59924500) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_ACK 12:13:20 (59924578) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 2, O. Sequence: 2, Type: 6, Subclass: IAX_COMMAND_ACK 12:13:24 (59928062) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 2, O. Sequence: 2, Type: 6, Subclass: IAX_COMMAND_HANGUP 12:13:24 (59928078) LOG_MESSAGE-> COMMAND SENT: Sequence: 4, Type: 6, Subclass: IAX_COMMAND_ACK [Successful Inbound Call (SIP UA to IAX Client)] 12:13:55 (59959437) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_NEW 12:13:55 (59959437) LOG_MESSAGE-> COMMAND SENT: Sequence: 0, Type: 6, Subclass: IAX_COMMAND_ACK 12:13:55 (59959453) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_ACCEPT 12:13:55 (59959453) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 4, Subclass: IAX_COMMAND_PONG 12:13:55 (59959468) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_ACK 12:13:55 (59959468) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_ACK 12:13:57 (59961578) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 4, Subclass: IAX_COMMAND_ACK 12:13:57 (59961625) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_ACK 12:13:57 (59961625) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 2, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_ACK 12:13:57 (59961640) LOG_MESSAGE-> COMMAND SENT: Sequence: 4, Type: 6, Subclass: IAX_COMMAND_ACK 12:14:00 (59964109) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_HANGUP 12:14:00 (59964343) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 2, O. Sequence: 2, Type: 6, Subclass: IAX_COMMAND_ACK 12:14:00 (59964343) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_INVAL [Successful Outbound Call (IAX Client to SIP UA)] 12:14:26 (59990750) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_NEW 12:14:26 (59990796) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_AUTHREQ 12:14:26 (59990812) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_AUTHREP 12:14:26 (59990812) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_ACK 12:14:27 (59990828) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_ACCEPT 12:14:27 (59990843) LOG_MESSAGE-> COMMAND SENT: Sequence: 3, Type: 6, Subclass: IAX_COMMAND_ACK 12:14:27 (59990843) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 2, O. Sequence: 2, Type: 4, Subclass: IAX_COMMAND_ACK 12:14:29 (59992828) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 2, Type: 4, Subclass: IAX_COMMAND_ACK 12:14:29 (59992843) LOG_MESSAGE-> Packet arrived out of order (expecting 4, got 2) (frametype = 4, subclass = 4) 12:14:29 (59992843) LOG_MESSAGE-> Sending Ack Anyway! 12:14:29 (59992859) LOG_MESSAGE-> COMMAND SENT: Sequence: 3, Type: 6, Subclass: IAX_COMMAND_ACK 12:14:29 (59992875) LOG_MESSAGE-> Returning Null! Exiting In ReSend Section! 12:14:35 (59999265) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 4, Type: 6, Subclass: IAX_COMMAND_HANGUP 12:14:35 (59999281) LOG_MESSAGE-> COMMAND SENT: Sequence: 3, Type: 6, Subclass: IAX_COMMAND_ACK [Re-Registration] 12:17:10 (60154156) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:17:10 (60154171) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_REGAUTH 12:17:10 (60154187) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:17:10 (60154203) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_REGACK 12:17:10 (60154218) LOG_MESSAGE-> COMMAND SENT: Sequence: 2, Type: 6, Subclass: IAX_COMMAND_ACK [FAILED CALL! Inbound Call (SIP UA to IAX Client)] 12:18:07 (60211578) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_NEW 12:18:07 (60211593) LOG_MESSAGE-> Packet arrived out of order (expecting 2, got 0) (frametype = 6, subclass = 1) 12:18:07 (60211609) LOG_MESSAGE-> Sending Ack Anyway! 12:18:07 (60211625) LOG_MESSAGE-> COMMAND SENT: Sequence: 0, Type: 6, Subclass: IAX_COMMAND_ACK 12:18:07 (60211640) LOG_MESSAGE-> Returning Null! Exiting In ReSend Section! 12:18:09 (60213593) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_NEW 12:18:09 (60213609) LOG_MESSAGE-> Packet arrived out of order (expecting 2, got 0) (frametype = 6, subclass = 1) 12:18:09 (60213625) LOG_MESSAGE-> Sending Ack Anyway! 12:18:09 (60213625) LOG_MESSAGE-> COMMAND SENT: Sequence: 0, Type: 6, Subclass: IAX_COMMAND_ACK 12:18:09 (60213640) LOG_MESSAGE-> Returning Null! Exiting In ReSend Section! 12:18:10 (60214171) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:18:10 (60214187) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_REGAUTH 12:18:10 (60214203) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:18:10 (60214218) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_REGACK 12:18:10 (60214218) LOG_MESSAGE-> COMMAND SENT: Sequence: 2, Type: 6, Subclass: IAX_COMMAND_ACK 12:18:17 (60221593) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 2, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_LAGRQ 12:18:17 (60221609) LOG_MESSAGE-> Packet arrived out of order (expecting 2, got 1) (frametype = 6, subclass = 11) 12:18:17 (60221609) LOG_MESSAGE-> Sending Ack Anyway! 12:18:17 (60221625) LOG_MESSAGE-> COMMAND SENT: Sequence: 0, Type: 6, Subclass: IAX_COMMAND_ACK 12:18:17 (60221640) LOG_MESSAGE-> Returning Null! Exiting In ReSend Section! 12:18:27 (60231593) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 2, O. Sequence: 2, Type: 6, Subclass: IAX_COMMAND_PING 12:18:27 (60231609) LOG_MESSAGE-> COMMAND SENT: Sequence: 0, Type: 6, Subclass: IAX_COMMAND_ACK 12:18:27 (60231625) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_PONG 12:18:27 (60231625) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 3, O. Sequence: 3, Type: 6, Subclass: IAX_COMMAND_LAGRQ 12:18:27 (60231640) LOG_MESSAGE-> COMMAND SENT: Sequence: 0, Type: 6, Subclass: IAX_COMMAND_ACK 12:18:27 (60231656) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_LAGRP 12:18:27 (60231671) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_VNAK 12:18:27 (60231671) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_VNAK 12:18:27 (60231703) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_VNAK 12:18:27 (60231734) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_VNAK 12:18:28 (60231937) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_VNAK 12:18:28 (60231984) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_VNAK 12:18:29 (60232906) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_VNAK 12:18:29 (60232953) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_VNAK 12:18:32 (60236750) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_VNAK 12:18:32 (60236796) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_VNAK 12:18:37 (60241578) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 4, O. Sequence: 4, Type: 6, Subclass: IAX_COMMAND_HANGUP 12:18:37 (60241593) LOG_MESSAGE-> COMMAND SENT: Sequence: 0, Type: 6, Subclass: IAX_COMMAND_ACK [Re-Registration] 12:19:10 (60274187) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:19:10 (60274203) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_REGAUTH 12:19:10 (60274218) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:19:10 (60274234) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_REGACK 12:19:10 (60274234) LOG_MESSAGE-> COMMAND SENT: Sequence: 2, Type: 6, Subclass: IAX_COMMAND_ACK [Re-Registration] 12:20:10 (60334203) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:20:10 (60334218) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_REGAUTH 12:20:10 (60334218) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:20:10 (60334250) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_REGACK 12:20:10 (60334250) LOG_MESSAGE-> COMMAND SENT: Sequence: 2, Type: 6, Subclass: IAX_COMMAND_ACK [Re-Registration] 12:21:10 (60394218) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:21:10 (60394234) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: IAX_COMMAND_REGAUTH 12:21:10 (60394234) LOG_MESSAGE-> COMMAND SENT: Sequence: -1, Type: 6, Subclass: IAX_COMMAND_REGREQ 12:21:10 (60394265) LOG_MESSAGE-> COMMAND RECEIVED: I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: IAX_COMMAND_REGACK 12:21:10 (60394265) LOG_MESSAGE-> COMMAND SENT: Sequence: 2, Type: 6, Subclass: IAX_COMMAND_ACK [END OF SESSION - CLIENT CLOSED] |
|
From: Steven S. <ss...@so...> - 2004-01-14 16:45:16
|
I really don't mean to be a bother, but this glitch is holding up my development. I was wondering if Steve K or anybody else who is more than an order of magnitude smarter than I would have a few minutes to chat on IRC about this error. I will try to do all of the leg work, but I need some direction. I really have a rather poor understanding of the message sequencing mechanism used by libiax, and could use some pointers. I will be lurking in the asterisk IRC channel. My handle is (surprisingly) ssokol. You can also give me a ring on IAXTel at 1-700-613-9004, or use the MSIM thing. I am ss...@so... there as well. Thanks! Steven |
|
From: Steven S. <ss...@so...> - 2004-01-13 20:06:07
|
I made a small change to the code in iax_header_to_event, essentially telling the function to accept NEW and HANGUP commands out of sequence. It worked -- sort of. It ALWAYS detects and raises the RING event. Unfortunately, it seems to bollix up the audio stream after a while. The first few calls go through just fine. By the 3rd or 4th call, however, audio never connects and we get a stream of VNAK messages. Here's my trace: 16480234 Log Message-> I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: 1 16480265 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: 4 16480281 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: 4 16482515 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: 4 16482562 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 2, Subclass: 2 16482640 Log Message-> I. Sequence: 2, O. Sequence: 2, Type: 6, Subclass: 4 16485656 Log Message-> I. Sequence: 2, O. Sequence: 2, Type: 6, Subclass: 4 16501390 Log Message-> I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: 1 16501406 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: 4 16501421 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: 4 16503609 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: 4 16503656 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 2, Subclass: 2 16503687 Log Message-> I. Sequence: 2, O. Sequence: 2, Type: 6, Subclass: 4 16508328 Log Message-> I. Sequence: 2, O. Sequence: 2, Type: 6, Subclass: 4 16520843 Log Message-> I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: 1 16520875 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: 4 16520890 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: 4 16522640 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: 4 16522703 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 2, Subclass: 2 16522734 Log Message-> I. Sequence: 2, O. Sequence: 2, Type: 6, Subclass: 4 16527359 Log Message-> I. Sequence: 2, O. Sequence: 2, Type: 6, Subclass: 5 16532921 Log Message-> I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: 14 16532937 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: 15 16532953 Log Message-> I. Sequence: 0, O. Sequence: 0, Type: 6, Subclass: 14 16533078 Log Message-> I. Sequence: 1, O. Sequence: 1, Type: 6, Subclass: 15 16533078 Log Message-> I. Sequence: 2, O. Sequence: 1, Type: 6, Subclass: 4 16556625 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 1 16556640 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 16556640 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 16556687 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 16556703 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 16556953 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 16556953 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 16557906 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 16557921 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 16558625 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 1 16559906 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 16559968 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 16560000 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 16560015 Log Message-> I. Sequence: 2, O. Sequence: 0, Type: 6, Subclass: 18 ... (4 pages of this)... FYI: Subclass Key 1 = IAX_COMMAND_NEW 2 = IAX_COMMAND_PING 4 = IAX_COMMAND_ACK 5 = IAX_COMMAND_HANGUP 14 = IAX_COMMAND_REGAUTH 15 = IAX_COMMAND_REGACK 18 = IAX_COMMAND_VNAK /* If we receive voice before valid first voice frame, send this */ |
|
From: Steven S. <ss...@so...> - 2004-01-13 17:54:06
|
I have narrowed the section of the code where the inbound call messages
are being lost to a particular sub-section of the
Ok. I have narrowed the iax_header_to_event function. My simple
logging seems to have trapped where the error is occurring. Now, I need
somebody with more experience to help me figure out WHY we are getting
these errors.
[FYI - I DO have the latest version of the code with all of Steve
Underwood's changes]
Here is my trace:
7897468 Log Message-> Processing Message...
7897484 Log Message-> Packet arrived out of order (expecting 2, got 0)
(frametype = 6, subclass = 1)
7897500 Log Message-> Sending Ack Anyway!
7897500 Log Message-> Returning Null! Exiting In ReSend Section!
7899468 Log Message-> Processing Message...
7899484 Log Message-> Packet arrived out of order (expecting 2, got 0)
(frametype = 6, subclass = 1)
7899484 Log Message-> Sending Ack Anyway!
7899500 Log Message-> Returning Null! Exiting In ReSend Section!
7904203 Log Message-> Processing Message...
7904218 Log Message-> Packet arrived out of order (expecting 2, got 1)
(frametype = 6, subclass = 5)
7904234 Log Message-> Sending Ack Anyway!
7904234 Log Message-> Returning Null! Exiting In ReSend Section!
[FYI - The numbers to the left of the trace are approximate ms since
bootup from the GetTickCount() Win32 function.]
This is coming in the iax_header_to_event function in a section with a
comment that says "Check where we are". It appears to be validating the
packet arrival sequence. The above trace shows an out-of-order arrival
of two IAX_COMMAND_NEW messages, and an IAX_COMMAND_HANGUP message when
the non-working call is abandoned at the far end. [See below for a copy
of the code as I am using it...]
Can anybody tell me what would cause the parser to view the incoming
COMMAND_NEW messages as out-of-order. The "expecting 2, got 0" makes it
look like it was expecting some kind of confirmation for a previous
action or message? Can we safely bypass this? Steve, Steve, Michael,
Dan - do you guys know what the preceding message and why we failed to
receive it?
Thanks!
Steve Sokol
Sokol & Associates, LLC
[My Code Including The Debugging. Attached is the iax.c file from my
system.]
/* Check where we are */
if (ntohs(fh->dcallno) & IAX_FLAG_RETRANS)
updatehistory = 0;
if ((session->iseqno != fh->oseqno) &&
(session->iseqno || ((subclass !=
IAX_COMMAND_TXCNT) && (subclass != IAX_COMMAND_TXACC)) || (subclass !=
AST_FRAME_IAX))) {
if (
((subclass != IAX_COMMAND_ACK) &&
(subclass != IAX_COMMAND_INVAL) &&
(subclass != IAX_COMMAND_TXCNT) &&
(subclass != IAX_COMMAND_TXACC) &&
(subclass != IAX_COMMAND_VNAK)) ||
(fh->type != AST_FRAME_IAX)) {
/* If it's not an ACK packet, it's out
of order. */
DEBU(G "Packet arrived out of order
(expecting %d, got %d) (frametype = %d, subclass = %d)\n",
session->iseqno, fh->oseqno,
fh->type, subclass);
char Error[200];
sprintf(Error, "Packet arrived out of
order (expecting %d, got %d) (frametype = %d, subclass = %d)\n",
session->iseqno, fh->oseqno,
fh->type, subclass);
iax_debug_log((LPCSTR) Error);
if (session->iseqno > fh->oseqno) {
/* If we've already seen it, ack
it XXX There's a border condition here XXX */
if ((fh->type != AST_FRAME_IAX)
|| ((subclass != IAX_COMMAND_ACK) && (subclass != IAX_COMMAND_INVAL))) {
DEBU(G "Acking
anyway\n");
iax_debug_log("Sending
Ack Anyway!");
/* XXX Maybe we should
handle its ack to us, but then again, it's probably outdated anyway, and
if
we have anything to
send, we'll retransmit and get an ACK back anyway XXX */
send_command_immediate(session, AST_FRAME_IAX, IAX_COMMAND_ACK, ts,
NULL, 0,fh->iseqno);
} else {
iax_debug_log("Sending
Absolutely Nothing...");
}
} else {
/* Send a VNAK requesting
retransmission */
iax_debug_log("Sending Vnak!");
iax2_vnak(session);
}
iax_debug_log("Returning Null! Exiting
In ReSend Section!");
return NULL; //****** THIS IS WHERE WE
EXIT WITH NO EVENT BEING GENERATED!!!
}
} else {
/* Increment unless it's an ACK or VNAK */
if (((subclass != IAX_COMMAND_ACK) &&
(subclass != IAX_COMMAND_INVAL) &&
(subclass != IAX_COMMAND_TXCNT) &&
(subclass != IAX_COMMAND_TXACC) &&
(subclass != IAX_COMMAND_VNAK)) ||
(fh->type != AST_FRAME_IAX))
session->iseqno++;
}
|
|
From: Steve K. <st...@st...> - 2004-01-12 20:28:53
|
Steven Sokol wrote: >My client seems to be experiencing errors when I force it to switch the >Audio Output/Input devices while a call is active. I do this for >intercom calls if the client is configured with different ring and audio >out devices (to force the intercom over the main PC speaker). However, >the audio becomes terribly choppy and remains that way for all >subsequent calls until the client is closed and re-opened. > >The client also dies a terrible death on closing, popping several memory >exception error messages before finally falling into the bit bucket. > >Has anybody run into this before? My client is using the internal PA >audio interface. Is anybody out there using a different (i.e. the >external or the Windows native) audio interface? Do they work better? > > I'll answer your questions in reverse order :) 1) Nobody as far as I know is using any other audio driver than portaudio; The audio driver interface is modular, but the only "working" drivers are the portaudio and the file drivers. The file driver was just a hack I wrote for testing. The "windows" driver was written before things were really modularized, and it has not been maintained. 2) As far as the trouble you're reporting, the two issues may not be related. What happens when you change audio devices is that you end up calling pa_select_devices in audio_portaudio.c. This stops and then starts the devices, which should do the right thing, but there's a possibility that there's some subtle problems in the underlying libraries which make this not work properly. I'm not sure what that would be, though. -SteveK |
|
From: Steven S. <ss...@so...> - 2004-01-12 17:22:28
|
My client seems to be experiencing errors when I force it to switch the Audio Output/Input devices while a call is active. I do this for intercom calls if the client is configured with different ring and audio out devices (to force the intercom over the main PC speaker). However, the audio becomes terribly choppy and remains that way for all subsequent calls until the client is closed and re-opened. The client also dies a terrible death on closing, popping several memory exception error messages before finally falling into the bit bucket. Has anybody run into this before? My client is using the internal PA audio interface. Is anybody out there using a different (i.e. the external or the Windows native) audio interface? Do they work better? Thanks! Steve |
|
From: Steven M. S. <ss...@so...> - 2004-01-10 02:49:54
|
Ok. I got the code and cleaned it up (ast_pthread_mutex_lock to ast_mutex_lock) so that it compiles and loads. Silly question I know, but how do I use it? How do I drop myself and conceivably several other parties into the application? Much thanks! Steven -----Original Message----- From: Steve Kann [mailto:st...@st...] Sent: Friday, January 09, 2004 6:32 PM To: Steven Sokol Cc: iax...@li... Subject: Re: [Iaxclient-devel] Conferencing In IAX Clients Steven Sokol wrote: >Greetings, > >Do any of the existing IAX user agents support conferencing? What seems >to be the most logical way to accomplish conferencing in iaxClient? >Does the Asterisk server act as the point of conference (ala MeetMe) or >is there a strait-forward way to make the client bridge multiple voice >streams? Other than tossing everyone into a MeetMe, I can't think of a >good way to establish a conference -- especially when you take into >consideration the possibility of multiple codecs in the mix. > >Any thoughts? Am I missing anything? > > We currently are using iaxclients for a conference, and we do it on the server (although we do not use meetme, we use app_conference, which is in CVS with iaxclient on sf.net; it does need updating). If you wanted to mix incoming calls like this in iaxclient, you could use a similar approach to that taken by app_conference, but it could be CPU intensive to do this for a large conference in uncontrolled client environments. |
|
From: John T. <jt...@lo...> - 2004-01-10 01:53:06
|
At 7:32 PM -0500 1/9/04, Steve Kann wrote: >Steven Sokol wrote: > >>Greetings, >> >>Do any of the existing IAX user agents support conferencing? What seems >>to be the most logical way to accomplish conferencing in iaxClient? >>Does the Asterisk server act as the point of conference (ala MeetMe) or >>is there a strait-forward way to make the client bridge multiple voice >>streams? Other than tossing everyone into a MeetMe, I can't think of a >>good way to establish a conference -- especially when you take into >>consideration the possibility of multiple codecs in the mix. >> >>Any thoughts? Am I missing anything? >> > >We currently are using iaxclients for a conference, and we do it on >the server (although we do not use meetme, we use app_conference, >which is in CVS with iaxclient on sf.net; it does need updating). > >If you wanted to mix incoming calls like this in iaxclient, you >could use a similar approach to that taken by app_conference, but it >could be CPU intensive to do this for a large conference in >uncontrolled client environments. Apologies if this starts to go off-topic, but I don't understand why you'd use app_conference in the first place, as app_meetme seems to cover much of the same functionality. As to SteveK's original question: why not just fork multiple copies of the iax agent and send the audio stream back to the original agent instance in a muxed manner? Multiple codecs shouldn't matter; if you can accept the codec of the caller, then everything is fine. The only limitation would start to be horsepower on your box and (probably sooner) bandwidth at whatever bottleneck was upstream from you. Here's what I would see as one of two options: First part of call scenario: A -> B If our Asterisk server is doing the right thing, then A will call B and the audio stream will flow between A and B, and only the setup will go through our (unshown) Asterisk server. Now, let's say C calls B: A -> B ^ | C Ideally, we'd like to have our Asterisk server again just set up the call, and the audio data would create a second call on B's machine. B would answer the call, hit the mythical "conference" button, and C and B and A would now all be chatting at the same time. Bandwidth to B's computer would more-or-less double, since he's now sending traffic to two different destinations: B and A. In the conference situation, wouldn't there simply be two instances of a call happening with the audio shared back to the "primary" instance of the call? Is this supported in the library? Sorry, I'm not enough of a coder to peek in there and see. Additonal channels would come into this conference in the same fashion, where for every call to B there would be an incremental increase in bandwidth for B. I'm uncertain how one would force this to be a single stream between * and B without using MeetMe. I suppose this would be a "native bridge transfer" or something. JT |
|
From: Steve K. <st...@st...> - 2004-01-10 00:32:12
|
Steven Sokol wrote: >Greetings, > >Do any of the existing IAX user agents support conferencing? What seems >to be the most logical way to accomplish conferencing in iaxClient? >Does the Asterisk server act as the point of conference (ala MeetMe) or >is there a strait-forward way to make the client bridge multiple voice >streams? Other than tossing everyone into a MeetMe, I can't think of a >good way to establish a conference -- especially when you take into >consideration the possibility of multiple codecs in the mix. > >Any thoughts? Am I missing anything? > > We currently are using iaxclients for a conference, and we do it on the server (although we do not use meetme, we use app_conference, which is in CVS with iaxclient on sf.net; it does need updating). If you wanted to mix incoming calls like this in iaxclient, you could use a similar approach to that taken by app_conference, but it could be CPU intensive to do this for a large conference in uncontrolled client environments. |
|
From: Steven S. <ss...@so...> - 2004-01-09 23:36:30
|
Greetings, Do any of the existing IAX user agents support conferencing? What seems to be the most logical way to accomplish conferencing in iaxClient? Does the Asterisk server act as the point of conference (ala MeetMe) or is there a strait-forward way to make the client bridge multiple voice streams? Other than tossing everyone into a MeetMe, I can't think of a good way to establish a conference -- especially when you take into consideration the possibility of multiple codecs in the mix. Any thoughts? Am I missing anything? Thanks, Steve P.S. Has anybody taken a crack at native IAX transfers? |
|
From: Steve K. <st...@st...> - 2004-01-08 00:42:54
|
Steve,
Looks like you're working your way down there to the problem.
I think the other Steve (Steve Underwood -- so there's three Steves
here at least), found a bug related to this already, so you should look
at that diff as well. There might be a similar error. This may be
obvious, but make sure that you have these included in your sources.
(they are in CVS..). Here's the most important parts [this is just part
of the diff, so it won't apply; see steveu's original messages:
/home/steveu/iaxclient/iaxclient/lib/libiax2/src/iax2-parser.c
--- lib/libiax2/src/iax2-parser.c 2003-06-07 04:17:59.000000000 +0800
+++ /home/steveu/iaxclient/iaxclient/lib/libiax2/src/iax2-parser.c 2003-12-27 18:56:20.000000000 +0800
[...]
@@ -498,10 +502,17 @@
snprintf(tmp, sizeof(tmp), "Expecting transferid to be %d bytes long but was %d\n", sizeof(unsigned int), len);
errorf(tmp);
} else
ies->transferid = ntohl(*((unsigned int *)(data + 2)));
break;
+ case IAX_IE_DATETIME:
+ if (len != sizeof(unsigned int)) {
+ snprintf(tmp, sizeof(tmp), "Expecting date/time to be %d bytes long but was %d\n", sizeof(unsigned int), len);
+ errorf(tmp);
+ } else
+ ies->datetime = ntohl(*((unsigned int *)(data + 2)));
+ break;
default:
snprintf(tmp, sizeof(tmp), "Ignoring unknown information element '%s' (%d) of length %d\n", iax_ie2str(ie), ie, len);
errorf(tmp);
}
diff -rU5 lib/libiax2/src/iax.c /home/steveu/iaxclient/iaxclient/lib/libiax2/src/iax.c
--- lib/libiax2/src/iax.c 2003-11-13 07:26:38.000000000 +0800
[...]
@@ -1993,11 +1995,15 @@
e->datalen = datalen;
}
return schedule_delivery(e, ts);
case AST_FRAME_IAX:
/* Parse IE's */
- if (iax_parse_ies(&e->ies, fh->iedata, datalen)) {
+ if (datalen) {
+ memcpy(e->data, fh->iedata, datalen);
+ e->datalen = datalen;
+ }
+ if (iax_parse_ies(&e->ies, e->data, e->datalen)) {
IAXERROR "Unable to parse IE's");
free(e);
e = NULL;
break;
}
And then this one:
--- iax.c.ref 2003-12-27 22:19:51.000000000 +0800
+++ iax.c 2003-12-27 22:20:22.000000000 +0800
@@ -1830,11 +1830,14 @@
if ((ms > -4) || (e->etype != IAX_EVENT_VOICE)) {
/* Return the event immediately if it's it's less than 3 milliseconds
too late, or if it's not voice (believe me, you don't want to
just drop a hangup frame because it's late, or a ping, or some such.
That kinda ruins retransmissions too */
- return e;
+ /* Queue for immediate delivery */
+ iax_sched_event(e, NULL, 0);
+ return NULL;
+ //return e;
}
DEBU(G "(not so) Silently dropping a packet (ms = %d)\n", ms);
/* Silently discard this as if it were to be delivered */
free(e);
return NULL;
=======================
Then, if you trace through (Mark's) code, you will see that the behavior
you're seeing isn't all that unexpected -- iax_get_event(0) will return
null in cases where
a) There are no pending "scheduled" events that need handling.
- AND -
either
b) there are no events to read from the network (shouldn't happen if
we're calling it as a result of netfd being set in select.)
OR
c) iax_net_read returns null (probably because iax_net_process returns
null, which
might be because iax_net_process returns null, which might be because
schedule_delivery returns null, etc).
d) there was an event read from iax_net_read but the event was "handled" by
handle_event.
Now, the case (c) is the common case, and this will happen whenever a
packet is a bit early, for example --
Actually, looking at steveu's changes to schedule_delivery a bit more,
it seems like he made it _never_ return the event at all, but to always
queue it up for later processing. And now, I'm not sure that was
necessary..
It shouldn't hurt too much, but it means the event won't get processed
until the next time we call iax_get_event.
The code in iaxc_service_network could probably be cleaned up a bit, but
it looks like it should work. The question is where are these events
getting lost..
I don't see the problem, but I haven't really done any work with
incoming calls (my client doesn't get incoming calls :)).
Unfortunately, my guess from looking through this for 30 minutes is that
somewhere in iax_header_to_event is your problem.
Eventually, you need to end up at line 2019: e = schedule_delivery(e,
ts); for this.. And schedule_delivery should do the right thing..
(iax_session_new does clear all of it's memory, so that should rxcore
should be clear, for example). schedule_delivery should almost always
end up where steveu made that change.. (because ms should almost always
be zero, unless the clock ticked in the middle of calc_rxstamp).
[ note: the gettimeofday implementation on MSWin is a bit coarse, so the
difference may be large there, but it should also be positive if it is ].
So, I'm a bit stumped. I'd put a breakpoint (or a print) around line
2019, and make sure you're getting there when a the NEW command comes in..
-SteveK
Steven Sokol wrote:
>Here's a real surprise I found: the failure in the iaxClient library
>seems to be failing when it calls iax_get_event in the iax2 library.
>Here's my understanding of how this is happening:
>
>1. My Client Starts.
>2. It initializes IAX2 passing in all the necessary goodies.
>3. It calls iaxc_start_processing_thread() to begin processing.
>4. iaxc_processor calls the function iaxc_process_calls
>5. iaxc_process_calls call iaxc_service_network
>6. iaxc_service_network checks for a waiting event using
>select/FD_ISSET
>7. If an event is waiting (bit is set on net FD), do_iax_event gets
>called.
>8. do_iax_event continues to get called until FD bit is not set (no
>more events?)
>9. do_iax_event gets called one more time to handle anything that may
>have been missed?
>10. iaxc_service_network returns.
>11. iaxc_process_calls handles other functions (pings, audio,
>registrations).
>12. iaxc_process_calls returns.
>13. iaxc_processor sleeps for 5ms.
>14. iaxc_processor starts over -> Goto Step 5.
>
>In steps 7, 8 and 9, the code calls do_iax_event() which in turn gets an
>event structure by calling the iax_get_event(0) function in iax.c. The
>iax_get_event function appears to process pending messages then gets
>events from the network by calling iax_net_read. Iax_net_read in turn
>grabs a buffer from the network file descriptor and processes it into an
>event structure by calling iax_net_process. Iax_net_process converts
>the buffer into either a full sized or mini header. Based on the type
>of header it uses one of two methods to transform the data into an event
>(either an "event" or a voice frame).
>
>In theory every time the netfd is set (meaning there is an event
>waiting) there should be an event structure to read from the network
>(from Asterisk). This is where things (under Win32, at least) seem to
>break down. I added some code to alert me when the netfd is signaled
>but there is no event returned by the iax_get_event(0) call in
>iax_do_event (i.e. the event pointer [e] is null). This seems to happen
>from time to time. And for whatever reason, it seems to happen fairly
>consistently after a few minutes, causing it to miss call notifications.
>
>Oddly it does not seem to have any problem with re-registration
>acknowledgments. And apparently it does not happen on the connection
>to/from IAXtel. Would this mean that my local Asterisk is munging the
>messages? I see some debugging code in the libiax code, but I don't
>know how to activate a debugger that will respond (nor what if anything
>needs to be changed in my build to activate the debugging code).
>
>Any suggestions would be greatly helpful. I know Michael is looking
>forward to a fix for this. I don't know if Dante is still plagued by
>this one or not, but it would be great to have the Win32 side of the
>library clean and running smooth!
>
>Thanks,
>
>Steve Sokol
>Sokol & Associates, LLC
>
>[Where I Think Thins Are Going South]
>
>static void do_iax_event() {
> struct iax_event *e = 0;
> int callNo;
>
> while ( (e = iax_get_event(0))) {
> // first, see if this is an event for one of our calls.
> callNo = iaxc_find_call_by_session(e->session);
> if(callNo >= 0) {
> iaxc_handle_network_event(e, callNo);
> } else if
>#ifndef IAXC_IAX2
> ( e->etype == IAX_EVENT_REGREP )
>#else
> ((e->etype == IAX_EVENT_REGACK ) || (e->etype ==
>IAX_EVENT_REGREJ ))
>#endif
> {
> iaxc_handle_regreply(e);
> } else if(e->etype == IAX_EVENT_REGREQ ) {
> iaxc_usermsg(IAXC_ERROR, "Registration requested
>by someone, but we don't understand!");
> } else if(e->etype == IAX_EVENT_CONNECT) {
>
> callNo = iaxc_first_free_call();
>....
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Perforce Software.
>Perforce is the Fast Software Configuration Management System offering
>advanced branching capabilities and atomic changes on 50+ platforms.
>Free Eval! http://www.perforce.com/perforce/loadprog.html
>_______________________________________________
>Iaxclient-devel mailing list
>Iax...@li...
>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>
>
>
|
|
From: Steven S. <ss...@so...> - 2004-01-07 23:34:00
|
Here's a real surprise I found: the failure in the iaxClient library
seems to be failing when it calls iax_get_event in the iax2 library.
Here's my understanding of how this is happening:
1. My Client Starts.
2. It initializes IAX2 passing in all the necessary goodies.
3. It calls iaxc_start_processing_thread() to begin processing.
4. iaxc_processor calls the function iaxc_process_calls
5. iaxc_process_calls call iaxc_service_network
6. iaxc_service_network checks for a waiting event using
select/FD_ISSET
7. If an event is waiting (bit is set on net FD), do_iax_event gets
called.
8. do_iax_event continues to get called until FD bit is not set (no
more events?)
9. do_iax_event gets called one more time to handle anything that may
have been missed?
10. iaxc_service_network returns.
11. iaxc_process_calls handles other functions (pings, audio,
registrations).
12. iaxc_process_calls returns.
13. iaxc_processor sleeps for 5ms.
14. iaxc_processor starts over -> Goto Step 5.
In steps 7, 8 and 9, the code calls do_iax_event() which in turn gets an
event structure by calling the iax_get_event(0) function in iax.c. The
iax_get_event function appears to process pending messages then gets
events from the network by calling iax_net_read. Iax_net_read in turn
grabs a buffer from the network file descriptor and processes it into an
event structure by calling iax_net_process. Iax_net_process converts
the buffer into either a full sized or mini header. Based on the type
of header it uses one of two methods to transform the data into an event
(either an "event" or a voice frame).
In theory every time the netfd is set (meaning there is an event
waiting) there should be an event structure to read from the network
(from Asterisk). This is where things (under Win32, at least) seem to
break down. I added some code to alert me when the netfd is signaled
but there is no event returned by the iax_get_event(0) call in
iax_do_event (i.e. the event pointer [e] is null). This seems to happen
from time to time. And for whatever reason, it seems to happen fairly
consistently after a few minutes, causing it to miss call notifications.
Oddly it does not seem to have any problem with re-registration
acknowledgments. And apparently it does not happen on the connection
to/from IAXtel. Would this mean that my local Asterisk is munging the
messages? I see some debugging code in the libiax code, but I don't
know how to activate a debugger that will respond (nor what if anything
needs to be changed in my build to activate the debugging code).
Any suggestions would be greatly helpful. I know Michael is looking
forward to a fix for this. I don't know if Dante is still plagued by
this one or not, but it would be great to have the Win32 side of the
library clean and running smooth!
Thanks,
Steve Sokol
Sokol & Associates, LLC
[Where I Think Thins Are Going South]
static void do_iax_event() {
struct iax_event *e = 0;
int callNo;
while ( (e = iax_get_event(0))) {
// first, see if this is an event for one of our calls.
callNo = iaxc_find_call_by_session(e->session);
if(callNo >= 0) {
iaxc_handle_network_event(e, callNo);
} else if
#ifndef IAXC_IAX2
( e->etype == IAX_EVENT_REGREP )
#else
((e->etype == IAX_EVENT_REGACK ) || (e->etype ==
IAX_EVENT_REGREJ ))
#endif
{
iaxc_handle_regreply(e);
} else if(e->etype == IAX_EVENT_REGREQ ) {
iaxc_usermsg(IAXC_ERROR, "Registration requested
by someone, but we don't understand!");
} else if(e->etype == IAX_EVENT_CONNECT) {
callNo = iaxc_first_free_call();
....
|
|
From: Steven S. <ss...@so...> - 2004-01-07 23:12:29
|
I am working on an email that covers what I have discovered in debugging the iaxClient library. It seems that the issue lies somewhere in the libiax2/iax.c low-level code. We get the event notification, but the event data is getting munged when the iaxClient library calls iax_get_event(0). Hopefully SteveK can take a look and give me a 1 minute fix. Thanks, Steve Sokol > -----Original Message----- > From: Michael Van Donselaar [mailto:mv...@va...] > Sent: Wednesday, January 07, 2004 4:46 PM > To: Steven Sokol > Subject: Re: [Iaxclient-devel] Missing Inbound Calls / Multiple Protocols > > On Wed, 7 Jan 2004 16:36:50 -0600, "Steven Sokol" <ssokol@sokol- > associates.com> > wrote: > > >Michael, > > > >I actually have two separate Windows DLLs compiled from the code > >(slightly cleaned up to keep IAX1 working). Since Win32 loads DLLs into > >their own memory space for each process, I would think that the issues > >with the conditionals would be eliminated. I just don't know how PA > >handles being loaded twice for the same process. > > That's very convenient. While I'd like to just run IAX2, I think that > I've got > to figure a workaround to get over the igoring incoming calls. > > I'm in over my head trying to debug the iax2 library code. > > I do find it interesting that you don't miss calls from iaxtel. Maybe you > chould bring it up on asterisk-devel. > > > >> -----Original Message----- > >> From: Michael Van Donselaar [mailto:mv...@va...] > >> Sent: Wednesday, January 07, 2004 3:59 PM > >> To: Steven Sokol > >> Subject: Re: [Iaxclient-devel] Missing Inbound Calls / Multiple > >Protocols > >> > >> On Wed, 07 Jan 2004 14:52:59 -0600, Steven Sokol <ssokol@sokol- > >> associates.com> > >> wrote: > >> > >> >Question: I have the iaxClient library compiled into two DLLs (IAX1 > >& > >> >IAX2). My client currently uses either one or the other. Is there > >any > >> >foreseeable problem using BOTH? I want to allow calls to/from a > >> >particular server to be made using IAX1, while calls to/from another > >> >server will use IAX2. Does that make sense? Do you see any terrible > >> >issues with this? > >> > >> iaxclient_lib.c has a lot of ifdefs that reference the protocol > >version. > >> I > >> think it would require a major rewrite to allow it to use both. > >> > >> I do think that it would be useful, however to get that functionality. > >I > >> just > >> don't know the code well enough at this point to jump in and do it. |
|
From: Steven S. <ss...@so...> - 2004-01-07 20:53:59
|
I just discovered something interesting. I have my client now working
with multiple registrations and I have found that while the system will
reliably start missing calls (not seeing inbound calls) from my Asterisk
server (CVS updated yesterday) it does not ever seem to miss calls
coming from Iaxtel.
I hope that somebody out there can read the trace from the IAX2
debugging better than I. Below are two traces. The first is a call
that failed made from the Grandstream BT101 SIP phone to the IAX client
softphone. When the call was made, the Grandstream never played back
ringback tones (it was completely silent for about 30 seconds) then give
me a "403" and played about 3 seconds of busy before returning to idle.
The second trace is of a call made from the same phone to the same IAX
Client softphone but by calling its IAXtel number. As expected, the
call went through with all of the normal functions (ringback on the
BT101, ringing on the softphone) and the call was successfully
completed.
Should I post this to the asterisk-dev list as well? It seems very
strange that calls coming from the local server would fail, but from the
remote server would succeed. Is there a patch to IAX2 that has not yet
been applied to the CVS?
Question: I have the iaxClient library compiled into two DLLs (IAX1 &
IAX2). My client currently uses either one or the other. Is there any
foreseeable problem using BOTH? I want to allow calls to/from a
particular server to be made using IAX1, while calls to/from another
server will use IAX2. Does that make sense? Do you see any terrible
issues with this?
Thanks!
Steven
[FALIED CALL: SIP Phone to IAX Client Softphone]
sip*CLI>
-- Executing Dial("SIP/1101-ac5c", "IAX2/1105|30") in new stack
-- Called 1105
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
NEW
Timestamp: 00001ms SCall: 00005 DCall: 00000 [64.151.42.28:4569]
VERSION : 2
CALLED NUMBER : s
CALLING NUMBER : 1101
CALLING NAME : Steven Sokol
LANGUAGE : en
FORMAT : 2
CAPABILITY : 2
ADSICPE : 2
DATE TIME : 136803348
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 00001ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[001] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
NEW
Timestamp: 00001ms SCall: 00005 DCall: 00000 [64.151.42.28:4569]
VERSION : 2
CALLED NUMBER : s
CALLING NUMBER : 1101
CALLING NAME : Steven Sokol
LANGUAGE : en
FORMAT : 2
CAPABILITY : 2
ADSICPE : 2
DATE TIME : 136803348
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 00001ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 000 Type: IAX Subclass:
LAGRQ
Timestamp: 10012ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 10012ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 002 ISeqno: 000 Type: IAX Subclass:
PING
Timestamp: 20012ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 003 ISeqno: 000 Type: IAX Subclass:
LAGRQ
Timestamp: 20013ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 003 Type: IAX Subclass:
ACK
Timestamp: 20012ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 003 Type: IAX Subclass:
PONG
Timestamp: 20012ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
VNAK
Timestamp: 20018ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 004 Type: IAX Subclass:
ACK
Timestamp: 20013ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 004 Type: IAX Subclass:
LAGRP
Timestamp: 20013ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
VNAK
Timestamp: 20019ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[Yes] -- OSeqno: 002 ISeqno: 003 Type: IAX Subclass:
PONG
Timestamp: 20012ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
VNAK
Timestamp: 20076ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[Yes] -- OSeqno: 003 ISeqno: 004 Type: IAX Subclass:
LAGRP
Timestamp: 20013ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
VNAK
Timestamp: 20077ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[Yes] -- OSeqno: 002 ISeqno: 003 Type: IAX Subclass:
PONG
Timestamp: 20012ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
VNAK
Timestamp: 20328ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[Yes] -- OSeqno: 003 ISeqno: 004 Type: IAX Subclass:
LAGRP
Timestamp: 20013ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
VNAK
Timestamp: 20329ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[Yes] -- OSeqno: 002 ISeqno: 003 Type: IAX Subclass:
PONG
Timestamp: 20012ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
VNAK
Timestamp: 21295ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[Yes] -- OSeqno: 003 ISeqno: 004 Type: IAX Subclass:
LAGRP
Timestamp: 20013ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
VNAK
Timestamp: 21296ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[Yes] -- OSeqno: 002 ISeqno: 003 Type: IAX Subclass:
PONG
Timestamp: 20012ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
VNAK
Timestamp: 25139ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[Yes] -- OSeqno: 003 ISeqno: 004 Type: IAX Subclass:
LAGRP
Timestamp: 20013ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
VNAK
Timestamp: 25140ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
-- Nobody picked up in 30000 ms
-- Hungup 'IAX2[1105]/5'
Tx-Frame Retry[000] -- OSeqno: 004 ISeqno: 000 Type: IAX Subclass:
HANGUP
Timestamp: 29993ms SCall: 00005 DCall: 03540 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 005 Type: IAX Subclass:
ACK
Timestamp: 29993ms SCall: 03540 DCall: 00005 [64.151.42.28:4569]
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
REGREQ
Timestamp: 00001ms SCall: 03557 DCall: 00000 [64.151.42.28:4569]
USERNAME : 1105
REFRESH : 300
[SUCCESSFUL CALL FROM IAXCOM (Using The Same SIP Phone)]
-- Executing Dial("SIP/1101-29f4",
"IAX2/ssokol01:ham...@ia.../17008221807@iaxtel") in new stack
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
NEW
Timestamp: 00001ms SCall: 00001 DCall: 00000 [69.73.19.178:4569]
VERSION : 2
CALLED NUMBER : 17008221807
CALLING NUMBER : 1101
CALLING NAME : Steven Sokol
LANGUAGE : en
CALLED CONTEXT : iaxtel
USERNAME : ssokol01
FORMAT : 2
CAPABILITY : 2
ADSICPE : 2
DATE TIME : 136803677
-- Called ssokol01:ham...@ia.../17008221807@iaxtel
Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass:
AUTHREQ
Timestamp: 00001ms SCall: 00139 DCall: 00001 [69.73.19.178:4569]
AUTHMETHODS : 3
CHALLENGE : 224537503
USERNAME : ssokol01
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass:
AUTHREP
Timestamp: 00053ms SCall: 00001 DCall: 00139 [69.73.19.178:4569]
MD5 RESULT : 30c53c657e2aa944ef8f3654e55ff574
Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass:
ACCEPT
Timestamp: 00051ms SCall: 00139 DCall: 00001 [69.73.19.178:4569]
FORMAT : 2
-- Call accepted by 69.73.19.178 (format GSM)
-- Format for call is GSM
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX Subclass:
ACK
Timestamp: 00051ms SCall: 00001 DCall: 00139 [69.73.19.178:4569]
Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 002 Type: CONTROL Subclass:
(255?)
Timestamp: 00054ms SCall: 00139 DCall: 00001 [69.73.19.178:4569]
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 003 Type: IAX Subclass:
ACK
Timestamp: 00054ms SCall: 00001 DCall: 00139 [69.73.19.178:4569]
-- IAX2[69.73.19.178:4569]/1 stopped sounds
Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: CONTROL Subclass:
RINGING
Timestamp: 00139ms SCall: 00139 DCall: 00001 [69.73.19.178:4569]
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 004 Type: IAX Subclass:
ACK
Timestamp: 00139ms SCall: 00001 DCall: 00139 [69.73.19.178:4569]
-- IAX2[69.73.19.178:4569]/1 is ringing
Rx-Frame Retry[No] -- OSeqno: 004 ISeqno: 002 Type: CONTROL Subclass:
(255?)
Timestamp: 03651ms SCall: 00139 DCall: 00001 [69.73.19.178:4569]
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 005 Type: IAX Subclass:
ACK
Timestamp: 03651ms SCall: 00001 DCall: 00139 [69.73.19.178:4569]
Rx-Frame Retry[No] -- OSeqno: 005 ISeqno: 002 Type: CONTROL Subclass:
ANSWER
Timestamp: 03652ms SCall: 00139 DCall: 00001 [69.73.19.178:4569]
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 006 Type: IAX Subclass:
ACK
Timestamp: 03652ms SCall: 00001 DCall: 00139 [69.73.19.178:4569]
Rx-Frame Retry[No] -- OSeqno: 006 ISeqno: 002 Type: IAX Subclass:
TXREQ
Timestamp: 03653ms SCall: 00139 DCall: 00001 [69.73.19.178:4569]
APPARENT ADDRES : IPV4 64.151.42.28:4569
CALL NUMBER : 3585
TRANSFER ID : 439399019
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 007 Type: IAX Subclass:
ACK
Timestamp: 03653ms SCall: 00001 DCall: 00139 [69.73.19.178:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass:
TXCNT
Timestamp: 03705ms SCall: 00001 DCall: 03585 [64.151.42.28:4569]
TRANSFER ID : 439399019
-- IAX2[69.73.19.178:4569]/1 stopped sounds
-- IAX2[69.73.19.178:4569]/1 answered SIP/1101-29f4
Tx-Frame Retry[000] -- OSeqno: 002 ISeqno: 007 Type: VOICE Subclass: 2
Timestamp: 03723ms SCall: 00001 DCall: 00139 [69.73.19.178:4569]
Rx-Frame Retry[No] -- OSeqno: 007 ISeqno: 002 Type: VOICE Subclass: 2
Timestamp: 03679ms SCall: 00139 DCall: 00001 [69.73.19.178:4569]
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 008 Type: IAX Subclass:
ACK
Timestamp: 03679ms SCall: 00001 DCall: 00139 [69.73.19.178:4569]
Rx-Frame Retry[No] -- OSeqno: 007 ISeqno: 003 Type: IAX Subclass:
ACK
Timestamp: 03723ms SCall: 00139 DCall: 00001 [69.73.19.178:4569]
Rx-Frame Retry[No] -- OSeqno: 008 ISeqno: 003 Type: IAX Subclass:
HANGUP
Timestamp: 04915ms SCall: 00139 DCall: 00001 [69.73.19.178:4569]
Tx-Frame Retry[-01] -- OSeqno: 003 ISeqno: 009 Type: IAX Subclass:
ACK
Timestamp: 04915ms SCall: 00001 DCall: 00139 [69.73.19.178:4569]
-- Hungup 'IAX2[69.73.19.178:4569]/1'
== Spawn extension (default, 917008221807, 1) exited non-zero on
'SIP/1101-29f4'
sip*CLI>
|
|
From: Faizan N. <fai...@vo...> - 2004-01-03 01:36:20
|
Cool work.
What did you do about ec (SPEEX_ECHO or USE_MEC3) pre-defines.
I used SPEEX_ECHO.
----- Original Message -----
From: "Darren Smith" <da...@st...>
To: "'Faizan Naqvi'" <fai...@Ho...>;
<iax...@li...>
Sent: Saturday, January 03, 2004 3:50 AM
Subject: RE: [Iaxclient-devel] solved struct hell.
> WOOHOO :-)
>
> Untar the tarball ;-)
>
> 1. Change include dir from libiax to libiax2 and include
portmixer/px_common
> 2. Add IAXC_IAX2 & LIBIAX to PRE_DEFINITIONS
> 3. Remove libiax/*.h & *.c from project
> 4. add libspeex/mdf.c to project
> 5. add portmixer/px_win_wmme/px_win_wmme.c to project
> 6. remove inline crap
> 7. change sendto_t to: typedef int (pascal *sendto_t)(SOCKET, const char
*,
> int, int, const struct sockaddr *, int);
> 8. add libiax2/src/iax.c
> 9. add libiax2/src/md5.c
> 10. apply patch to iax.c
> 11. add libiax2/src/iax2-parser.c
> 12. move #include <unistd.h> declaration in iax2-parser to inside the
!WIN32
> DEF clause
>
> Then Compile and enjoy native IAX2 (in Debug mode anyway) :-)
>
> Regards
>
> Darren ']data[' Smith
>
> > -----Original Message-----
> > From: iax...@li...
> > [mailto:iax...@li...] On
> > Behalf Of Darren Smith
> > Sent: 02 January 2004 21:21
> > To: 'Faizan Naqvi'; iax...@li...
> > Subject: RE: [Iaxclient-devel] solved struct hell.
> >
> > Hi Faizan et al
> >
> > There are still errors it seems :-(
> >
> > In libiax2/iax-client.h:
> >
> > typedef int PASCAL (*sendto_t)(SOCKET, const char *, int,
> > int, const struct sockaddr *, int);
> >
> > Doesn't seem to work at all, if I remove the PASCAL (google
> > says PASCAL ==
> > __stdcall?) it compiles however WinIAX crashes badly, yet no
> > matter what combination I try, will it accept it :-)
> >
> > In iax.c 'struct iax_session *iax_session_new(void)':
> >
> > S->sendto = sendto causes:
> > error C2152: '=' : pointers to functions with different
> > attributes
> >
> > If I typecast it with (sendto_t) it compiles?
> >
> > Lastly, but I don't think it matters too much (except from a
> > performance point of view?):
> >
> > Libiax2/winpoop.h:
> >
> > inline doesn't seem to want to work, either as __inline
> > or inline.
> >
> > Any thoughts you have would be appreciated.
> >
> > Regards
> >
> > Darren ']data[' Smith.
> >
> > > -----Original Message-----
> > > From: iax...@li...
> > > [mailto:iax...@li...] On Behalf Of
> > > Faizan Naqvi
> > > Sent: 23 November 2003 07:52
> > > To: iax...@li...
> > > Subject: [Iaxclient-devel] solved struct hell.
> > >
> > > Hi.
> > > Well it looks like Release version wont work for a while.
> > So here is
> > > the solution with some C theory.
> > > If I am repeating someone's else thoughts than sorry for that.
> > > /////////////////MY CODE////////////////// #ifdef _MSC_VER unsigned
> > > buffer[4096];
> > > struct {
> > > struct iax_frame fr2;
> > > } buf;
> > > #else
> > > struct {
> > > struct iax_frame fr2;
> > > unsigned char buffer[4096]; /* Buffer -- must
> > > preceed fr2 */
> > > } buf;
> > > #endif
> > > struct iax_frame *fr;
> > > int res;
> > > int sendmini=0;
> > > unsigned int lastsent;
> > > unsigned int fts;
> > >
> > > #ifdef _MSC_VER
> > > buffer[0]=0;
> > > #else
> > > /* Shut up GCC */
> > > buf.buffer[0] = 0;
> > > #endif
> > > /////////////////////////////////////////END OF MY
> > > CODE.//////////////////////////////
> > >
> > > The member afdata of iax_frame is zero sized. The struct hell
> > > origianly was declaerd like this ////////////////code in
> > > iax_send///////// struct hell {
> > > struct iax_frame*fr2;
> > > unsigned char buffer[4096];
> > > } buf;
> > > ////////////////end code///////
> > > This allocated 4K after afdata so when afdata is filled it
> > goes into
> > > buffer but is able to accessed by afdata.
> > > MSVC doesnt allow this. Putting it buffer before fr2
> > compiles fine but
> > > gives no space for data to be copied in afdata.
> > > So, remebering that stack is in reverse declaring buffer
> > just before
> > > struct hell gives afdata 4K like this.
> > > //////////////modified iax_send code./////////// unsigned char
> > > buffer[4096]; struct hell {
> > > struct iax_frame*fr2;
> > > } buf;
> > > //////////////end code///////////////////////
> > >
> > > I hope this solevs the proble,
> > > Somebody get the Release version working.
> > > thank you.
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: IBM Linux Tutorials.
> > > Become an expert in LINUX or just sharpen your skills. Sign up for
> > > IBM's Free Linux Tutorials. Learn everything from the bash
> > shell to
> > > sys admin.
> > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > > _______________________________________________
> > > Iaxclient-devel mailing list
> > > Iax...@li...
> > > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills. Sign
> > up for IBM's Free Linux Tutorials. Learn everything from the
> > bash shell to sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Iaxclient-devel mailing list
> > Iax...@li...
> > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
|
|
From: Darren S. <da...@st...> - 2004-01-02 22:50:47
|
WOOHOO :-)
Untar the tarball ;-)
1. Change include dir from libiax to libiax2 and include portmixer/px_common
2. Add IAXC_IAX2 & LIBIAX to PRE_DEFINITIONS
3. Remove libiax/*.h & *.c from project
4. add libspeex/mdf.c to project
5. add portmixer/px_win_wmme/px_win_wmme.c to project
6. remove inline crap
7. change sendto_t to: typedef int (pascal *sendto_t)(SOCKET, const char *,
int, int, const struct sockaddr *, int);
8. add libiax2/src/iax.c
9. add libiax2/src/md5.c
10. apply patch to iax.c
11. add libiax2/src/iax2-parser.c
12. move #include <unistd.h> declaration in iax2-parser to inside the !WIN32
DEF clause
Then Compile and enjoy native IAX2 (in Debug mode anyway) :-)
Regards
Darren ']data[' Smith
> -----Original Message-----
> From: iax...@li...
> [mailto:iax...@li...] On
> Behalf Of Darren Smith
> Sent: 02 January 2004 21:21
> To: 'Faizan Naqvi'; iax...@li...
> Subject: RE: [Iaxclient-devel] solved struct hell.
>
> Hi Faizan et al
>
> There are still errors it seems :-(
>
> In libiax2/iax-client.h:
>
> typedef int PASCAL (*sendto_t)(SOCKET, const char *, int,
> int, const struct sockaddr *, int);
>
> Doesn't seem to work at all, if I remove the PASCAL (google
> says PASCAL ==
> __stdcall?) it compiles however WinIAX crashes badly, yet no
> matter what combination I try, will it accept it :-)
>
> In iax.c 'struct iax_session *iax_session_new(void)':
>
> S->sendto = sendto causes:
> error C2152: '=' : pointers to functions with different
> attributes
>
> If I typecast it with (sendto_t) it compiles?
>
> Lastly, but I don't think it matters too much (except from a
> performance point of view?):
>
> Libiax2/winpoop.h:
>
> inline doesn't seem to want to work, either as __inline
> or inline.
>
> Any thoughts you have would be appreciated.
>
> Regards
>
> Darren ']data[' Smith.
>
> > -----Original Message-----
> > From: iax...@li...
> > [mailto:iax...@li...] On Behalf Of
> > Faizan Naqvi
> > Sent: 23 November 2003 07:52
> > To: iax...@li...
> > Subject: [Iaxclient-devel] solved struct hell.
> >
> > Hi.
> > Well it looks like Release version wont work for a while.
> So here is
> > the solution with some C theory.
> > If I am repeating someone's else thoughts than sorry for that.
> > /////////////////MY CODE////////////////// #ifdef _MSC_VER unsigned
> > buffer[4096];
> > struct {
> > struct iax_frame fr2;
> > } buf;
> > #else
> > struct {
> > struct iax_frame fr2;
> > unsigned char buffer[4096]; /* Buffer -- must
> > preceed fr2 */
> > } buf;
> > #endif
> > struct iax_frame *fr;
> > int res;
> > int sendmini=0;
> > unsigned int lastsent;
> > unsigned int fts;
> >
> > #ifdef _MSC_VER
> > buffer[0]=0;
> > #else
> > /* Shut up GCC */
> > buf.buffer[0] = 0;
> > #endif
> > /////////////////////////////////////////END OF MY
> > CODE.//////////////////////////////
> >
> > The member afdata of iax_frame is zero sized. The struct hell
> > origianly was declaerd like this ////////////////code in
> > iax_send///////// struct hell {
> > struct iax_frame*fr2;
> > unsigned char buffer[4096];
> > } buf;
> > ////////////////end code///////
> > This allocated 4K after afdata so when afdata is filled it
> goes into
> > buffer but is able to accessed by afdata.
> > MSVC doesnt allow this. Putting it buffer before fr2
> compiles fine but
> > gives no space for data to be copied in afdata.
> > So, remebering that stack is in reverse declaring buffer
> just before
> > struct hell gives afdata 4K like this.
> > //////////////modified iax_send code./////////// unsigned char
> > buffer[4096]; struct hell {
> > struct iax_frame*fr2;
> > } buf;
> > //////////////end code///////////////////////
> >
> > I hope this solevs the proble,
> > Somebody get the Release version working.
> > thank you.
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills. Sign up for
> > IBM's Free Linux Tutorials. Learn everything from the bash
> shell to
> > sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Iaxclient-devel mailing list
> > Iax...@li...
> > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign
> up for IBM's Free Linux Tutorials. Learn everything from the
> bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>
|
72 messages has been excluded from this view by a project administrator.
