Menu
▾
▴
iaxclient-devel
|
From: Adam H. <ad...@te...> - 2004-02-04 22:48:33
|
this may be a stupid question but why is asterisk retransmitting a voice packet. Only the first one is tagged as reliable (I thought anyway). ----- Original Message ----- From: "Steven Sokol" <ss...@so...> To: <iax...@li...> Sent: Thursday, February 05, 2004 9:43 AM Subject: [Iaxclient-devel] Some data related to the new bug... > 1. I cannot make the bug reproduce between my SIP client and my IAX Phone > instance. It simply does not happen. It also does not happen when calls > are placed between IAX Phone and various asterisk service (i.e. Voicemail, > MeetMe, MOH, etc.) > > 2. The audio seems to die at the point when Asterisk transmits a retry > packet: > > Tx-Frame Retry[000] -- OSeqno: 003 ISeqno: 004 Type: VOICE Subclass: 2 > Timestamp: 65855ms SCall: 00006 DCall: 29893 [64.151.42.28:4569] > sip*CLI> > Tx-Frame Retry[001] -- OSeqno: 003 ISeqno: 004 Type: VOICE Subclass: 2 > Timestamp: 65855ms SCall: 00006 DCall: 29893 [64.151.42.28:4569] > > The CLI> above indicates where I hit the enter key just as soon as I heard > the audio die off. > > It seems the issue is specific to IAX2 and possibly to the iaxClient > library. > > Does this ring any bells for anyone? > > Thanks, > > Steve > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
|
From: Steven S. <ss...@so...> - 2004-02-04 23:01:11
|
More notes: 1. It ALWAYS happens. It is not an intermittent issue. This happens for EVERY IAX2-to-IAX2 call made using iaxClient. 2. The timing is uncanny. It ALWAYS happens after 65-67 seconds. 3. The audio dies but the call in not immediately torn down. The call eventually is eventually killed when the PING/PONG cycle times out some seconds later (perhaps over a minute in some of my tests). 4. In EVERY case, the Asterisk kicks out the aforementioned voice frame retransmit message. 5. I don't see registration messages coming through at the same time. I was originally guessing that this happened during the re-reg process. Not so (or at least that doesn't seem to be the case -- could be that the re-reg that takes place prior to the error causes a problem). > -----Original Message----- > From: iax...@li... [mailto:iaxclient-devel- > ad...@li...] On Behalf Of Steven Sokol > Sent: Wednesday, February 04, 2004 4:44 PM > To: iax...@li... > Subject: [Iaxclient-devel] Some data related to the new bug... > > 1. I cannot make the bug reproduce between my SIP client and my IAX Phone > instance. It simply does not happen. It also does not happen when calls > are placed between IAX Phone and various asterisk service (i.e. Voicemail, > MeetMe, MOH, etc.) > > 2. The audio seems to die at the point when Asterisk transmits a retry > packet: > > Tx-Frame Retry[000] -- OSeqno: 003 ISeqno: 004 Type: VOICE Subclass: 2 > Timestamp: 65855ms SCall: 00006 DCall: 29893 [64.151.42.28:4569] > sip*CLI> > Tx-Frame Retry[001] -- OSeqno: 003 ISeqno: 004 Type: VOICE Subclass: 2 > Timestamp: 65855ms SCall: 00006 DCall: 29893 [64.151.42.28:4569] > > The CLI> above indicates where I hit the enter key just as soon as I heard > the audio die off. > > It seems the issue is specific to IAX2 and possibly to the iaxClient > library. > > Does this ring any bells for anyone? > > Thanks, > > Steve > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
|
From: Adam H. <ad...@te...> - 2004-02-04 23:05:12
|
I'm not trying to plug firefly, but does the same issue occur on it? ----- Original Message ----- From: "Steven Sokol" <ss...@so...> To: <iax...@li...> Sent: Thursday, February 05, 2004 10:01 AM Subject: RE: [Iaxclient-devel] Some data related to the new bug... > More notes: > > 1. It ALWAYS happens. It is not an intermittent issue. This happens for > EVERY IAX2-to-IAX2 call made using iaxClient. > > 2. The timing is uncanny. It ALWAYS happens after 65-67 seconds. > > 3. The audio dies but the call in not immediately torn down. The call > eventually is eventually killed when the PING/PONG cycle times out some > seconds later (perhaps over a minute in some of my tests). > > 4. In EVERY case, the Asterisk kicks out the aforementioned voice frame > retransmit message. > > 5. I don't see registration messages coming through at the same time. I > was originally guessing that this happened during the re-reg process. Not > so (or at least that doesn't seem to be the case -- could be that the re-reg > that takes place prior to the error causes a problem). > > > -----Original Message----- > > From: iax...@li... [mailto:iaxclient-devel- > > ad...@li...] On Behalf Of Steven Sokol > > Sent: Wednesday, February 04, 2004 4:44 PM > > To: iax...@li... > > Subject: [Iaxclient-devel] Some data related to the new bug... > > > > 1. I cannot make the bug reproduce between my SIP client and my IAX Phone > > instance. It simply does not happen. It also does not happen when calls > > are placed between IAX Phone and various asterisk service (i.e. Voicemail, > > MeetMe, MOH, etc.) > > > > 2. The audio seems to die at the point when Asterisk transmits a retry > > packet: > > > > Tx-Frame Retry[000] -- OSeqno: 003 ISeqno: 004 Type: VOICE Subclass: 2 > > Timestamp: 65855ms SCall: 00006 DCall: 29893 [64.151.42.28:4569] > > sip*CLI> > > Tx-Frame Retry[001] -- OSeqno: 003 ISeqno: 004 Type: VOICE Subclass: 2 > > Timestamp: 65855ms SCall: 00006 DCall: 29893 [64.151.42.28:4569] > > > > The CLI> above indicates where I hit the enter key just as soon as I heard > > the audio die off. > > > > It seems the issue is specific to IAX2 and possibly to the iaxClient > > library. > > > > Does this ring any bells for anyone? > > > > Thanks, > > > > Steve > > > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Iaxclient-devel mailing list > > Iax...@li... > > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
|
From: Steven S. <ss...@so...> - 2004-02-04 23:35:53
|
I don't know about Firefly (yet). I will have to check that out. Does anybody know what could cause the clients (both ends) to loose their audio streams? There are two streams here - the inbound and the outbound. They both pass through Asterisk. I guess in reality there are three parties to the call: [USER A]<->[ASTERISK]<->[USER B] So there are actually 4 streams. Something is killing off all of them. Would this be happening in Asterisk? How do we trace this on the client side? Steve K, any thoughts? Can we do anything to capture additional information or to tell of the audio streams are dying locally or at Asterisk? Thanks, Steve > -----Original Message----- > From: iax...@li... [mailto:iaxclient-devel- > ad...@li...] On Behalf Of Adam Hart > Sent: Wednesday, February 04, 2004 5:02 PM > To: iax...@li... > Subject: Re: [Iaxclient-devel] Some data related to the new bug... > > I'm not trying to plug firefly, but does the same issue occur on it? > > ----- Original Message ----- > From: "Steven Sokol" <ss...@so...> > To: <iax...@li...> > Sent: Thursday, February 05, 2004 10:01 AM > Subject: RE: [Iaxclient-devel] Some data related to the new bug... > > > > More notes: > > > > 1. It ALWAYS happens. It is not an intermittent issue. This happens > for > > EVERY IAX2-to-IAX2 call made using iaxClient. > > > > 2. The timing is uncanny. It ALWAYS happens after 65-67 seconds. > > > > 3. The audio dies but the call in not immediately torn down. The call > > eventually is eventually killed when the PING/PONG cycle times out some > > seconds later (perhaps over a minute in some of my tests). > > > > 4. In EVERY case, the Asterisk kicks out the aforementioned voice frame > > retransmit message. > > > > 5. I don't see registration messages coming through at the same time. > I > > was originally guessing that this happened during the re-reg process. > Not > > so (or at least that doesn't seem to be the case -- could be that the > re-reg > > that takes place prior to the error causes a problem). > > > > > -----Original Message----- > > > From: iax...@li... > [mailto:iaxclient-devel- > > > ad...@li...] On Behalf Of Steven Sokol > > > Sent: Wednesday, February 04, 2004 4:44 PM > > > To: iax...@li... > > > Subject: [Iaxclient-devel] Some data related to the new bug... > > > > > > 1. I cannot make the bug reproduce between my SIP client and my IAX > Phone > > > instance. It simply does not happen. It also does not happen when > calls > > > are placed between IAX Phone and various asterisk service (i.e. > Voicemail, > > > MeetMe, MOH, etc.) > > > > > > 2. The audio seems to die at the point when Asterisk transmits a > retry > > > packet: > > > > > > Tx-Frame Retry[000] -- OSeqno: 003 ISeqno: 004 Type: VOICE Subclass: > 2 > > > Timestamp: 65855ms SCall: 00006 DCall: 29893 [64.151.42.28:4569] > > > sip*CLI> > > > Tx-Frame Retry[001] -- OSeqno: 003 ISeqno: 004 Type: VOICE Subclass: > 2 > > > Timestamp: 65855ms SCall: 00006 DCall: 29893 [64.151.42.28:4569] > > > > > > The CLI> above indicates where I hit the enter key just as soon as I > heard > > > the audio die off. > > > > > > It seems the issue is specific to IAX2 and possibly to the iaxClient > > > library. > > > > > > Does this ring any bells for anyone? > > > > > > Thanks, > > > > > > Steve > > > > > > > > > > > > > > > ------------------------------------------------------- > > > The SF.Net email is sponsored by EclipseCon 2004 > > > Premiere Conference on Open Tools Development and Integration > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > http://www.eclipsecon.org/osdn > > > _______________________________________________ > > > Iaxclient-devel mailing list > > > Iax...@li... > > > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Iaxclient-devel mailing list > > Iax...@li... > > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
|
From: Steve U. <st...@co...> - 2004-02-04 23:48:09
|
Steven Sokol wrote: >More notes: > >1. It ALWAYS happens. It is not an intermittent issue. This happens for >EVERY IAX2-to-IAX2 call made using iaxClient. > > Not EVERY call. I make hour long calls using iaxclient IAX2-to-IAX2 and have no trouble. I use Linux. Is that the difference? >2. The timing is uncanny. It ALWAYS happens after 65-67 seconds. > >3. The audio dies but the call in not immediately torn down. The call >eventually is eventually killed when the PING/PONG cycle times out some >seconds later (perhaps over a minute in some of my tests). > >4. In EVERY case, the Asterisk kicks out the aforementioned voice frame >retransmit message. > > As Adam said, there is something wrong if a voice frame is being retransmitted at that point in the call. Perhaps checking places where the frame is tagged for retransmission would home in on the problem. >5. I don't see registration messages coming through at the same time. I >was originally guessing that this happened during the re-reg process. Not >so (or at least that doesn't seem to be the case -- could be that the re-reg >that takes place prior to the error causes a problem). > > Regards, Steve |
|
From: Steve K. <st...@st...> - 2004-02-04 23:59:28
|
Steve Underwood wrote: > Steven Sokol wrote: > >> More notes: >> >> 1. It ALWAYS happens. It is not an intermittent issue. This >> happens for >> EVERY IAX2-to-IAX2 call made using iaxClient. >> >> > Not EVERY call. I make hour long calls using iaxclient IAX2-to-IAX2 > and have no trouble. I use Linux. Is that the difference? Glad to hear it is working well for you, though :) >> 2. The timing is uncanny. It ALWAYS happens after 65-67 seconds. >> >> 3. The audio dies but the call in not immediately torn down. The call >> eventually is eventually killed when the PING/PONG cycle times out some >> seconds later (perhaps over a minute in some of my tests). >> >> 4. In EVERY case, the Asterisk kicks out the aforementioned voice frame >> retransmit message. >> >> > As Adam said, there is something wrong if a voice frame is being > retransmitted at that point in the call. Perhaps checking places where > the frame is tagged for retransmission would home in on the problem. If you look at the code I excerpted, it looks like voice frames are occasionally sent as full frames. I'm not sure of the logic behind that (I'd say it would be good if we didn't have all that Ping and Lagrq stuff already being sent, in order to refresh timeouts and establish connectivity with acks). It also correlates exactly with his 65-67 second timing. If this only happens on windows, one place I'd look it to make sure the "gettimeofday" replacement there is correct; it's in winfuncs.c. It's basically adapted from the earlier hack in libiax "winiphone".. |
|
From: Kim H. <ki...@ki...> - 2004-02-05 00:15:55
|
> If this only happens on windows, one place I'd look it to make sure the > "gettimeofday" replacement there is correct; it's in winfuncs.c. It's > basically adapted from the earlier hack in libiax "winiphone".. It fails for me with IAXCLIENT -> asterisk type of calls always as well. - Kim |
|
From: Michael V. D. <mv...@va...> - 2004-02-05 01:06:45
|
On Wed, 04 Feb 2004 18:59:25 -0500, Steve Kann <st...@st...> wrote:
>
>If this only happens on windows, one place I'd look it to make sure the=20
>"gettimeofday" replacement there is correct; it's in winfuncs.c. It's=20
>basically adapted from the earlier hack in libiax "winiphone"..
>
I see that you have:
--8<--------
void gettimeofday(struct timeval *tv, struct timezone *tz)
{
long l =3D startuptime + GetTickCount();
tv->tv_sec =3D l / 1000;
tv->tv_usec =3D (l % 1000) * 1000;
return;
}
--8<--------
shouldn't you have, instead:
tv->tv_usec =3D (l % 1000);
|
|
From: Adam H. <ad...@te...> - 2004-02-05 01:11:24
|
usec is nanoseconds (1 second = a million nanoseconds)
----- Original Message -----
From: "Michael Van Donselaar" <mv...@va...>
To: "Steve Kann" <st...@st...>
Cc: <iax...@li...>
Sent: Thursday, February 05, 2004 12:06 PM
Subject: Re: [Iaxclient-devel] Some data related to the new bug...
On Wed, 04 Feb 2004 18:59:25 -0500, Steve Kann <st...@st...> wrote:
>
>If this only happens on windows, one place I'd look it to make sure the
>"gettimeofday" replacement there is correct; it's in winfuncs.c. It's
>basically adapted from the earlier hack in libiax "winiphone"..
>
I see that you have:
--8<--------
void gettimeofday(struct timeval *tv, struct timezone *tz)
{
long l = startuptime + GetTickCount();
tv->tv_sec = l / 1000;
tv->tv_usec = (l % 1000) * 1000;
return;
}
--8<--------
shouldn't you have, instead:
tv->tv_usec = (l % 1000);
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Iaxclient-devel mailing list
Iax...@li...
https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
|
|
From: Michael V. D. <mv...@va...> - 2004-02-05 01:23:02
|
On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <ad...@te...> =
wrote:
>usec is nanoseconds (1 second =3D a million nanoseconds)
And I can't even blame this on not having my coffee yet. I was seeing =
usec, but
thinking msec.
I don't know if I'm seeing something that's not there, but is anyone =
suspicious
that 65-67 second sounds an awful lot like 65536 msec?
>----- Original Message -----=20
>From: "Michael Van Donselaar" <mv...@va...>
>To: "Steve Kann" <st...@st...>
>Cc: <iax...@li...>
>Sent: Thursday, February 05, 2004 12:06 PM
>Subject: Re: [Iaxclient-devel] Some data related to the new bug...
>
>
>On Wed, 04 Feb 2004 18:59:25 -0500, Steve Kann <st...@st...> =
wrote:
>
>>
>>If this only happens on windows, one place I'd look it to make sure the=
=20
>>"gettimeofday" replacement there is correct; it's in winfuncs.c. It's=20
>>basically adapted from the earlier hack in libiax "winiphone"..
>>
>
>I see that you have:
>
>--8<--------
>void gettimeofday(struct timeval *tv, struct timezone *tz)
>{
> long l =3D startuptime + GetTickCount();
>
> tv->tv_sec =3D l / 1000;
> tv->tv_usec =3D (l % 1000) * 1000;
> return;
>}
>--8<--------
>
>shouldn't you have, instead:
>
> tv->tv_usec =3D (l % 1000);
>
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Iaxclient-devel mailing list
>Iax...@li...
>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Iaxclient-devel mailing list
>Iax...@li...
>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
|
|
From: Kim H. <ki...@ki...> - 2004-02-05 03:06:49
|
The timeing of 65-67 secondsIt may be related to the problem,
but it's not the whole problem. I've spent quite a lot of time using a setup like:
iaxcomm -> asterisk - asterisk -> ata186
I usually get between 5 and 10 minutes per call. The other chap was getting
about 1 hour. My situation is:
733 Mhz Pentium III, windows XP, iaxcomm -> 2.4Ghz Pentium IV
I'm curious to know the setup that is resulting in a regular 65-67 secs then
failure.
- Kim
> On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <ad...@te...> wrote:
>
> >usec is nanoseconds (1 second = a million nanoseconds)
>
> And I can't even blame this on not having my coffee yet. I was seeing usec, but
> thinking msec.
>
> I don't know if I'm seeing something that's not there, but is anyone suspicious
> that 65-67 second sounds an awful lot like 65536 msec?
>
> >----- Original Message -----
> >From: "Michael Van Donselaar" <mv...@va...>
> >To: "Steve Kann" <st...@st...>
> >Cc: <iax...@li...>
> >Sent: Thursday, February 05, 2004 12:06 PM
> >Subject: Re: [Iaxclient-devel] Some data related to the new bug...
> >
> >
> >On Wed, 04 Feb 2004 18:59:25 -0500, Steve Kann <st...@st...> wrote:
> >
> >>
> >>If this only happens on windows, one place I'd look it to make sure the
> >>"gettimeofday" replacement there is correct; it's in winfuncs.c. It's
> >>basically adapted from the earlier hack in libiax "winiphone"..
> >>
> >
> >I see that you have:
> >
> >--8<--------
> >void gettimeofday(struct timeval *tv, struct timezone *tz)
> >{
> > long l = startuptime + GetTickCount();
> >
> > tv->tv_sec = l / 1000;
> > tv->tv_usec = (l % 1000) * 1000;
> > return;
> >}
> >--8<--------
> >
> >shouldn't you have, instead:
> >
> > tv->tv_usec = (l % 1000);
> >
> >
> >
> >-------------------------------------------------------
> >The SF.Net email is sponsored by EclipseCon 2004
> >Premiere Conference on Open Tools Development and Integration
> >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> >http://www.eclipsecon.org/osdn
> >_______________________________________________
> >Iaxclient-devel mailing list
> >Iax...@li...
> >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
> >
> >
> >-------------------------------------------------------
> >The SF.Net email is sponsored by EclipseCon 2004
> >Premiere Conference on Open Tools Development and Integration
> >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> >http://www.eclipsecon.org/osdn
> >_______________________________________________
> >Iaxclient-devel mailing list
> >Iax...@li...
> >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
|
|
From: Steve K. <st...@st...> - 2004-02-05 14:35:34
|
Michael Van Donselaar wrote: >On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <ad...@te...> wrote: > > > >>usec is nanoseconds (1 second = a million nanoseconds) >> >> > >And I can't even blame this on not having my coffee yet. I was seeing usec, but >thinking msec. > >I don't know if I'm seeing something that's not there, but is anyone suspicious >that 65-67 second sounds an awful lot like 65536 msec? > > Yes, it sounds exactly like that. I don't actually think it is the Win32 gettimeofday implementation, but some other set of circumstances which cause this problem. I'm not sure why Steve U isn't seeing this, but others are, but there may be another explanation for that. I think it has to do with the full frame vs mini frame for voice frames, somehow. I haven't seen this happen myself, though. -SteveK |
|
From: Steven S. <ss...@so...> - 2004-02-05 17:04:36
|
Steve,
Can you give me a clue as to where the decision is made to use a full frame
for voice vs. a mini? I also want to understand if I am correct in my
assumption that we are dealing with four distinct legs: [A] <-> [Asterisk]
<-> [B] or if Asterisk somehow redirects/reinvites the connection to the
proper destination ([A] <-> [B]). Since Asterisk throws the Retrans
message, I would guess it is the first option.
Is there any way to know where the audio data is going? The monitors remain
active, and the call is still live. Why would the audio stream simply
_stop_ instead of just pausing.
_____
From: iax...@li...
[mailto:iax...@li...] On Behalf Of Steve Kann
Sent: Thursday, February 05, 2004 8:35 AM
To: Michael Van Donselaar
Cc: iax...@li...
Subject: Re: [Iaxclient-devel] Some data related to the new bug...
Michael Van Donselaar wrote:
On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <mailto:ad...@te...>
<ad...@te...> wrote:
usec is nanoseconds (1 second = a million nanoseconds)
And I can't even blame this on not having my coffee yet. I was seeing usec,
but
thinking msec.
I don't know if I'm seeing something that's not there, but is anyone
suspicious
that 65-67 second sounds an awful lot like 65536 msec?
Yes, it sounds exactly like that.
I don't actually think it is the Win32 gettimeofday implementation, but some
other set of circumstances which cause this problem. I'm not sure why Steve
U isn't seeing this, but others are, but there may be another explanation
for that.
I think it has to do with the full frame vs mini frame for voice frames,
somehow. I haven't seen this happen myself, though.
-SteveK
|
|
From: Steven S. <ss...@so...> - 2004-02-05 00:34:39
|
Yes. Guilty as charged. It always happens UNDER WINDOWS. I believe that the gettimeofday() is being replaced by a function based on GetTickCount(). I wonder if that doesn't have something to do with it. Steve S -----Original Message----- From: iax...@li... [mailto:iax...@li...] On Behalf Of Steve Underwood Sent: Wednesday, February 04, 2004 5:48 PM To: iax...@li... Subject: Re: [Iaxclient-devel] Some data related to the new bug... Steven Sokol wrote: >More notes: > >1. It ALWAYS happens. It is not an intermittent issue. This happens for >EVERY IAX2-to-IAX2 call made using iaxClient. > > Not EVERY call. I make hour long calls using iaxclient IAX2-to-IAX2 and have no trouble. I use Linux. Is that the difference? >2. The timing is uncanny. It ALWAYS happens after 65-67 seconds. > >3. The audio dies but the call in not immediately torn down. The call >eventually is eventually killed when the PING/PONG cycle times out some >seconds later (perhaps over a minute in some of my tests). > >4. In EVERY case, the Asterisk kicks out the aforementioned voice frame >retransmit message. > > As Adam said, there is something wrong if a voice frame is being retransmitted at that point in the call. Perhaps checking places where the frame is tagged for retransmission would home in on the problem. >5. I don't see registration messages coming through at the same time. I >was originally guessing that this happened during the re-reg process. Not >so (or at least that doesn't seem to be the case -- could be that the re-reg >that takes place prior to the error causes a problem). > > Regards, Steve ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Iaxclient-devel mailing list Iax...@li... https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
|
From: Steve K. <st...@st...> - 2004-02-04 23:53:52
|
Steven Sokol wrote: >I don't know about Firefly (yet). I will have to check that out. > >Does anybody know what could cause the clients (both ends) to loose their >audio streams? There are two streams here - the inbound and the outbound. >They both pass through Asterisk. > >I guess in reality there are three parties to the call: > [USER A]<->[ASTERISK]<->[USER B] > >So there are actually 4 streams. Something is killing off all of them. >Would this be happening in Asterisk? How do we trace this on the client >side? > >Steve K, any thoughts? Can we do anything to capture additional information >or to tell of the audio streams are dying locally or at Asterisk? > > You can use tcpdump/ethereal on the asterisk server box to capture and examine the actual packets that are sent in each direction. You can turn on debugging, so that chan_iax2 prints something whenever a packet is sent, doing something similar. Are these calls getting "natively" bridged somehow? [so the frames get sent directly from user a to user b?) I don't know if the library supports that or not; Maybe kram has some idea (he is on this list now..). -SteveK >Thanks, > >Steve > > > > > >>-----Original Message----- >>From: iax...@li... [mailto:iaxclient-devel- >>ad...@li...] On Behalf Of Adam Hart >>Sent: Wednesday, February 04, 2004 5:02 PM >>To: iax...@li... >>Subject: Re: [Iaxclient-devel] Some data related to the new bug... >> >>I'm not trying to plug firefly, but does the same issue occur on it? >> >>----- Original Message ----- >>From: "Steven Sokol" <ss...@so...> >>To: <iax...@li...> >>Sent: Thursday, February 05, 2004 10:01 AM >>Subject: RE: [Iaxclient-devel] Some data related to the new bug... >> >> >> >> >>>More notes: >>> >>>1. It ALWAYS happens. It is not an intermittent issue. This happens >>> >>> >>for >> >> >>>EVERY IAX2-to-IAX2 call made using iaxClient. >>> >>>2. The timing is uncanny. It ALWAYS happens after 65-67 seconds. >>> >>>3. The audio dies but the call in not immediately torn down. The call >>>eventually is eventually killed when the PING/PONG cycle times out some >>>seconds later (perhaps over a minute in some of my tests). >>> >>>4. In EVERY case, the Asterisk kicks out the aforementioned voice frame >>>retransmit message. >>> >>>5. I don't see registration messages coming through at the same time. >>> >>> >>I >> >> >>>was originally guessing that this happened during the re-reg process. >>> >>> >>Not >> >> >>>so (or at least that doesn't seem to be the case -- could be that the >>> >>> >>re-reg >> >> >>>that takes place prior to the error causes a problem). >>> >>> >>> >>>>-----Original Message----- >>>>From: iax...@li... >>>> >>>> >>[mailto:iaxclient-devel- >> >> >>>>ad...@li...] On Behalf Of Steven Sokol >>>>Sent: Wednesday, February 04, 2004 4:44 PM >>>>To: iax...@li... >>>>Subject: [Iaxclient-devel] Some data related to the new bug... >>>> >>>>1. I cannot make the bug reproduce between my SIP client and my IAX >>>> >>>> >>Phone >> >> >>>>instance. It simply does not happen. It also does not happen when >>>> >>>> >>calls >> >> >>>>are placed between IAX Phone and various asterisk service (i.e. >>>> >>>> >>Voicemail, >> >> >>>>MeetMe, MOH, etc.) >>>> >>>>2. The audio seems to die at the point when Asterisk transmits a >>>> >>>> >>retry >> >> >>>>packet: >>>> >>>>Tx-Frame Retry[000] -- OSeqno: 003 ISeqno: 004 Type: VOICE Subclass: >>>> >>>> >>2 >> >> >>>> Timestamp: 65855ms SCall: 00006 DCall: 29893 [64.151.42.28:4569] >>>>sip*CLI> >>>>Tx-Frame Retry[001] -- OSeqno: 003 ISeqno: 004 Type: VOICE Subclass: >>>> >>>> >>2 >> >> >>>> Timestamp: 65855ms SCall: 00006 DCall: 29893 [64.151.42.28:4569] >>>> >>>>The CLI> above indicates where I hit the enter key just as soon as I >>>> >>>> >>heard >> >> >>>>the audio die off. >>>> >>>>It seems the issue is specific to IAX2 and possibly to the iaxClient >>>>library. >>>> >>>>Does this ring any bells for anyone? >>>> >>>>Thanks, >>>> >>>>Steve >>>> >>>> >>>> >>>> >>>>------------------------------------------------------- >>>>The SF.Net email is sponsored by EclipseCon 2004 >>>>Premiere Conference on Open Tools Development and Integration >>>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >>>>http://www.eclipsecon.org/osdn >>>>_______________________________________________ >>>>Iaxclient-devel mailing list >>>>Iax...@li... >>>>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel >>>> >>>> >>> >>> >>>------------------------------------------------------- >>>The SF.Net email is sponsored by EclipseCon 2004 >>>Premiere Conference on Open Tools Development and Integration >>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >>>http://www.eclipsecon.org/osdn >>>_______________________________________________ >>>Iaxclient-devel mailing list >>>Iax...@li... >>>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel >>> >>> >> >>------------------------------------------------------- >>The SF.Net email is sponsored by EclipseCon 2004 >>Premiere Conference on Open Tools Development and Integration >>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >>http://www.eclipsecon.org/osdn >>_______________________________________________ >>Iaxclient-devel mailing list >>Iax...@li... >>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel >> >> > > > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Iaxclient-devel mailing list >Iax...@li... >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > |
|
From: Adam H. <ad...@te...> - 2004-02-05 00:41:38
|
Why don't you guys just use my code from firefly, it's has nanosecond
accuracy. Beats the hell out of 10ms accuaracy
static __int64 freq,start;
static int inited = 0;
//static time_t startuptime;
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
if(!inited)
{
inited = 1;
QueryPerformanceFrequency((LARGE_INTEGER*)&freq);
QueryPerformanceCounter((LARGE_INTEGER*)&start);
}
return TRUE;
}
void gettimeofday(struct timeval *tv, struct timezone *tz)
{
__int64 time;
double elapsed;
QueryPerformanceCounter((LARGE_INTEGER*)&time);
elapsed = (double)(time - start) / (double)freq;
tv->tv_sec = (long)elapsed;
tv->tv_usec = (long)((elapsed-tv->tv_sec) * 1000000);
}
enjoy,
Adam
----- Original Message -----
From: "Steven Sokol" <ss...@so...>
To: <iax...@li...>
Sent: Thursday, February 05, 2004 11:34 AM
Subject: RE: [Iaxclient-devel] Some data related to the new bug...
> Yes. Guilty as charged. It always happens UNDER WINDOWS.
>
> I believe that the gettimeofday() is being replaced by a function based on
> GetTickCount(). I wonder if that doesn't have something to do with it.
>
> Steve S
>
> -----Original Message-----
> From: iax...@li...
> [mailto:iax...@li...] On Behalf Of Steve
> Underwood
> Sent: Wednesday, February 04, 2004 5:48 PM
> To: iax...@li...
> Subject: Re: [Iaxclient-devel] Some data related to the new bug...
>
> Steven Sokol wrote:
>
> >More notes:
> >
> >1. It ALWAYS happens. It is not an intermittent issue. This happens
for
> >EVERY IAX2-to-IAX2 call made using iaxClient.
> >
> >
> Not EVERY call. I make hour long calls using iaxclient IAX2-to-IAX2 and
> have no trouble. I use Linux. Is that the difference?
>
> >2. The timing is uncanny. It ALWAYS happens after 65-67 seconds.
> >
> >3. The audio dies but the call in not immediately torn down. The call
> >eventually is eventually killed when the PING/PONG cycle times out some
> >seconds later (perhaps over a minute in some of my tests).
> >
> >4. In EVERY case, the Asterisk kicks out the aforementioned voice frame
> >retransmit message.
> >
> >
> As Adam said, there is something wrong if a voice frame is being
> retransmitted at that point in the call. Perhaps checking places where
> the frame is tagged for retransmission would home in on the problem.
>
> >5. I don't see registration messages coming through at the same time. I
> >was originally guessing that this happened during the re-reg process.
Not
> >so (or at least that doesn't seem to be the case -- could be that the
> re-reg
> >that takes place prior to the error causes a problem).
> >
> >
> Regards,
> Steve
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
|
|
From: Steven S. <ss...@so...> - 2004-02-05 02:15:29
|
Guys,
I tossed in Adam's code. It makes a very nice replacement for the original
GetTimeOfDay function, but it does not seem to fix the problem.
(Still good to have a far more accurate time function - thanks Adam!)
Anybody have any other ideas? I tend to agree w/ Michael that the number
sure looks close to 65535+1, but others have said the window is different on
their pcs. Who knows....
More thoughts?
Steve
> -----Original Message-----
> From: iax...@li... [mailto:iaxclient-devel-
> ad...@li...] On Behalf Of Adam Hart
> Sent: Wednesday, February 04, 2004 6:39 PM
> To: iax...@li...
> Subject: Re: [Iaxclient-devel] Some data related to the new bug...
>
> Why don't you guys just use my code from firefly, it's has nanosecond
> accuracy. Beats the hell out of 10ms accuaracy
>
> static __int64 freq,start;
> static int inited = 0;
>
> //static time_t startuptime;
>
> BOOL APIENTRY DllMain( HANDLE hModule,
> DWORD ul_reason_for_call,
> LPVOID lpReserved
> )
> {
> if(!inited)
> {
>
> inited = 1;
> QueryPerformanceFrequency((LARGE_INTEGER*)&freq);
> QueryPerformanceCounter((LARGE_INTEGER*)&start);
> }
> return TRUE;
> }
>
> void gettimeofday(struct timeval *tv, struct timezone *tz)
> {
> __int64 time;
> double elapsed;
>
> QueryPerformanceCounter((LARGE_INTEGER*)&time);
>
> elapsed = (double)(time - start) / (double)freq;
>
> tv->tv_sec = (long)elapsed;
> tv->tv_usec = (long)((elapsed-tv->tv_sec) * 1000000);
> }
>
> enjoy,
> Adam
>
> ----- Original Message -----
> From: "Steven Sokol" <ss...@so...>
> To: <iax...@li...>
> Sent: Thursday, February 05, 2004 11:34 AM
> Subject: RE: [Iaxclient-devel] Some data related to the new bug...
>
>
> > Yes. Guilty as charged. It always happens UNDER WINDOWS.
> >
> > I believe that the gettimeofday() is being replaced by a function based
> on
> > GetTickCount(). I wonder if that doesn't have something to do with it.
> >
> > Steve S
> >
> > -----Original Message-----
> > From: iax...@li...
> > [mailto:iax...@li...] On Behalf Of Steve
> > Underwood
> > Sent: Wednesday, February 04, 2004 5:48 PM
> > To: iax...@li...
> > Subject: Re: [Iaxclient-devel] Some data related to the new bug...
> >
> > Steven Sokol wrote:
> >
> > >More notes:
> > >
> > >1. It ALWAYS happens. It is not an intermittent issue. This happens
> for
> > >EVERY IAX2-to-IAX2 call made using iaxClient.
> > >
> > >
> > Not EVERY call. I make hour long calls using iaxclient IAX2-to-IAX2 and
> > have no trouble. I use Linux. Is that the difference?
> >
> > >2. The timing is uncanny. It ALWAYS happens after 65-67 seconds.
> > >
> > >3. The audio dies but the call in not immediately torn down. The call
> > >eventually is eventually killed when the PING/PONG cycle times out some
> > >seconds later (perhaps over a minute in some of my tests).
> > >
> > >4. In EVERY case, the Asterisk kicks out the aforementioned voice
> frame
> > >retransmit message.
> > >
> > >
> > As Adam said, there is something wrong if a voice frame is being
> > retransmitted at that point in the call. Perhaps checking places where
> > the frame is tagged for retransmission would home in on the problem.
> >
> > >5. I don't see registration messages coming through at the same time.
> I
> > >was originally guessing that this happened during the re-reg process.
> Not
> > >so (or at least that doesn't seem to be the case -- could be that the
> > re-reg
> > >that takes place prior to the error causes a problem).
> > >
> > >
> > Regards,
> > Steve
> >
> >
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Iaxclient-devel mailing list
> > Iax...@li...
> > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
> >
> >
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Iaxclient-devel mailing list
> > Iax...@li...
> > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
|
|
From: Steve K. <st...@st...> - 2004-04-16 18:40:26
|
Hey Adam,
We took you advice here [thanks!], and used something based on your
code below, which was nice _most_ of the time.
However, in my office, I have 3 different machines [out of only
about a dozen or so we've been using this code on regularly], where this
fails spectacularly.
The problem is described here, and it is not theoretical. It causes
real problems for timing!
http://support.microsoft.com/?id=274323
So, I've disabled this in iaxclient for now. My suggestion to you
for firefly is to just use GetTickCount, and deal with it's 10ms
accuracy. The 10ms for us isn't a problem, but the 5 second jumps I
saw really are!
-SteveK
Adam Hart wrote:
>Why don't you guys just use my code from firefly, it's has nanosecond
>accuracy. Beats the hell out of 10ms accuaracy
>
>static __int64 freq,start;
>static int inited = 0;
>
>//static time_t startuptime;
>
>BOOL APIENTRY DllMain( HANDLE hModule,
> DWORD ul_reason_for_call,
> LPVOID lpReserved
> )
>{
> if(!inited)
> {
>
> inited = 1;
> QueryPerformanceFrequency((LARGE_INTEGER*)&freq);
> QueryPerformanceCounter((LARGE_INTEGER*)&start);
> }
> return TRUE;
>}
>
>void gettimeofday(struct timeval *tv, struct timezone *tz)
>{
> __int64 time;
> double elapsed;
>
> QueryPerformanceCounter((LARGE_INTEGER*)&time);
>
> elapsed = (double)(time - start) / (double)freq;
>
> tv->tv_sec = (long)elapsed;
> tv->tv_usec = (long)((elapsed-tv->tv_sec) * 1000000);
>}
>
>enjoy,
> Adam
>
>----- Original Message -----
>From: "Steven Sokol" <ss...@so...>
>To: <iax...@li...>
>Sent: Thursday, February 05, 2004 11:34 AM
>Subject: RE: [Iaxclient-devel] Some data related to the new bug...
>
>
>
>
>>Yes. Guilty as charged. It always happens UNDER WINDOWS.
>>
>>I believe that the gettimeofday() is being replaced by a function based on
>>GetTickCount(). I wonder if that doesn't have something to do with it.
>>
>>Steve S
>>
>>-----Original Message-----
>>From: iax...@li...
>>[mailto:iax...@li...] On Behalf Of Steve
>>Underwood
>>Sent: Wednesday, February 04, 2004 5:48 PM
>>To: iax...@li...
>>Subject: Re: [Iaxclient-devel] Some data related to the new bug...
>>
>>Steven Sokol wrote:
>>
>>
>>
>>>More notes:
>>>
>>>1. It ALWAYS happens. It is not an intermittent issue. This happens
>>>
>>>
>for
>
>
>>>EVERY IAX2-to-IAX2 call made using iaxClient.
>>>
>>>
>>>
>>>
>>Not EVERY call. I make hour long calls using iaxclient IAX2-to-IAX2 and
>>have no trouble. I use Linux. Is that the difference?
>>
>>
>>
>>>2. The timing is uncanny. It ALWAYS happens after 65-67 seconds.
>>>
>>>3. The audio dies but the call in not immediately torn down. The call
>>>eventually is eventually killed when the PING/PONG cycle times out some
>>>seconds later (perhaps over a minute in some of my tests).
>>>
>>>4. In EVERY case, the Asterisk kicks out the aforementioned voice frame
>>>retransmit message.
>>>
>>>
>>>
>>>
>>As Adam said, there is something wrong if a voice frame is being
>>retransmitted at that point in the call. Perhaps checking places where
>>the frame is tagged for retransmission would home in on the problem.
>>
>>
>>
>>>5. I don't see registration messages coming through at the same time. I
>>>was originally guessing that this happened during the re-reg process.
>>>
>>>
>Not
>
>
>>>so (or at least that doesn't seem to be the case -- could be that the
>>>
>>>
>>re-reg
>>
>>
>>>that takes place prior to the error causes a problem).
>>>
>>>
>>>
>>>
>>Regards,
>>Steve
>>
>>
>>
>>
>>-------------------------------------------------------
>>The SF.Net email is sponsored by EclipseCon 2004
>>Premiere Conference on Open Tools Development and Integration
>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>>http://www.eclipsecon.org/osdn
>>_______________________________________________
>>Iaxclient-devel mailing list
>>Iax...@li...
>>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>>
>>
>>
>>
>>-------------------------------------------------------
>>The SF.Net email is sponsored by EclipseCon 2004
>>Premiere Conference on Open Tools Development and Integration
>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>>http://www.eclipsecon.org/osdn
>>_______________________________________________
>>Iaxclient-devel mailing list
>>Iax...@li...
>>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>>
>>
>
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Iaxclient-devel mailing list
>Iax...@li...
>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>
>
>
|
|
From: Adam H. <ad...@te...> - 2004-04-17 01:40:28
|
Sorry :| That's pretty bad and I've never heard of it before (I guess it's a hardware issue) 90% of games run on QueryPerformanceCounter() so I guess it can't be too common. I'll fix up firefly, thanks for the information. Anything else I can 'help' you with :) -Adam Steve Kann wrote: > > Hey Adam, > > We took you advice here [thanks!], and used something based on > your code below, which was nice _most_ of the time. > > However, in my office, I have 3 different machines [out of only > about a dozen or so we've been using this code on regularly], where > this fails spectacularly. > > The problem is described here, and it is not theoretical. It > causes real problems for timing! > > http://support.microsoft.com/?id=274323 > > So, I've disabled this in iaxclient for now. My suggestion to you > for firefly is to just use GetTickCount, and deal with it's 10ms > accuracy. The 10ms for us isn't a problem, but the 5 second jumps I > saw really are! > > > -SteveK > > > Adam Hart wrote: > >>Why don't you guys just use my code from firefly, it's has nanosecond >>accuracy. Beats the hell out of 10ms accuaracy >> >>static __int64 freq,start; >>static int inited = 0; >> >>//static time_t startuptime; >> >>BOOL APIENTRY DllMain( HANDLE hModule, >> DWORD ul_reason_for_call, >> LPVOID lpReserved >> ) >>{ >> if(!inited) >> { >> >> inited = 1; >> QueryPerformanceFrequency((LARGE_INTEGER*)&freq); >> QueryPerformanceCounter((LARGE_INTEGER*)&start); >> } >> return TRUE; >>} >> >>void gettimeofday(struct timeval *tv, struct timezone *tz) >>{ >> __int64 time; >> double elapsed; >> >> QueryPerformanceCounter((LARGE_INTEGER*)&time); >> >> elapsed = (double)(time - start) / (double)freq; >> >> tv->tv_sec = (long)elapsed; >> tv->tv_usec = (long)((elapsed-tv->tv_sec) * 1000000); >>} >> >>enjoy, >> Adam >> >>----- Original Message ----- >>From: "Steven Sokol" <ss...@so...> >>To: <iax...@li...> >>Sent: Thursday, February 05, 2004 11:34 AM >>Subject: RE: [Iaxclient-devel] Some data related to the new bug... >> >> >> >> >>>Yes. Guilty as charged. It always happens UNDER WINDOWS. >>> >>>I believe that the gettimeofday() is being replaced by a function based on >>>GetTickCount(). I wonder if that doesn't have something to do with it. >>> >>>Steve S >>> >>>-----Original Message----- >>>From: iax...@li... >>>[mailto:iax...@li...] On Behalf Of Steve >>>Underwood >>>Sent: Wednesday, February 04, 2004 5:48 PM >>>To: iax...@li... >>>Subject: Re: [Iaxclient-devel] Some data related to the new bug... >>> >>>Steven Sokol wrote: >>> >>> >>> >>>>More notes: >>>> >>>>1. It ALWAYS happens. It is not an intermittent issue. This happens >>>> >>>> >>for >> >> >>>>EVERY IAX2-to-IAX2 call made using iaxClient. >>>> >>>> >>>> >>>> >>>Not EVERY call. I make hour long calls using iaxclient IAX2-to-IAX2 and >>>have no trouble. I use Linux. Is that the difference? >>> >>> >>> >>>>2. The timing is uncanny. It ALWAYS happens after 65-67 seconds. >>>> >>>>3. The audio dies but the call in not immediately torn down. The call >>>>eventually is eventually killed when the PING/PONG cycle times out some >>>>seconds later (perhaps over a minute in some of my tests). >>>> >>>>4. In EVERY case, the Asterisk kicks out the aforementioned voice frame >>>>retransmit message. >>>> >>>> >>>> >>>> >>>As Adam said, there is something wrong if a voice frame is being >>>retransmitted at that point in the call. Perhaps checking places where >>>the frame is tagged for retransmission would home in on the problem. >>> >>> >>> >>>>5. I don't see registration messages coming through at the same time. I >>>>was originally guessing that this happened during the re-reg process. >>>> >>>> >>Not >> >> >>>>so (or at least that doesn't seem to be the case -- could be that the >>>> >>>> >>>re-reg >>> >>> >>>>that takes place prior to the error causes a problem). >>>> >>>> >>>> >>>> >>>Regards, >>>Steve >>> >>> >>> >>> >>> > |
|
From: Steve K. <st...@st...> - 2004-04-18 14:15:32
|
On Apr 16, 2004, at 9:37 PM, Adam Hart wrote: > Sorry :| That's pretty bad and I've never heard of it before (I guess > it's a hardware issue) 90% of games run on QueryPerformanceCounter() > so I guess it can't be too common. I'll fix up firefly, thanks for the > information. I guess they must compensate in some way for the jumps; You could use QueryPerformanceCounter along with GetTickCount, and when they don't match, reset your "baseline" to what GetTickCount returns. Then you'd still sometimes be off by up to 10ms. All I know is that I have two or three machines which seem to suffer from this. I only actually saw it happening on one, but three suffer from the same symptoms, and the fix fixed all three. -SteveK > > Anything else I can 'help' you with :) > > -Adam > > Steve Kann wrote: > >> >> Hey Adam, >> >> We took you advice here [thanks!], and used something based on >> your code below, which was nice _most_ of the time. >> >> However, in my office, I have 3 different machines [out of only >> about a dozen or so we've been using this code on regularly], where >> this fails spectacularly. >> >> The problem is described here, and it is not theoretical. It >> causes real problems for timing! >> >> http://support.microsoft.com/?id=274323 >> >> So, I've disabled this in iaxclient for now. My suggestion to >> you for firefly is to just use GetTickCount, and deal with it's 10ms >> accuracy. The 10ms for us isn't a problem, but the 5 second jumps I >> saw really are! >> >> >> -SteveK >> >> >> Adam Hart wrote: >> >>> Why don't you guys just use my code from firefly, it's has nanosecond >>> accuracy. Beats the hell out of 10ms accuaracy >>> >>> static __int64 freq,start; >>> static int inited = 0; >>> >>> //static time_t startuptime; >>> >>> BOOL APIENTRY DllMain( HANDLE hModule, >>> DWORD ul_reason_for_call, >>> LPVOID lpReserved >>> ) >>> { >>> if(!inited) >>> { >>> >>> inited = 1; >>> QueryPerformanceFrequency((LARGE_INTEGER*)&freq); >>> QueryPerformanceCounter((LARGE_INTEGER*)&start); >>> } >>> return TRUE; >>> } >>> >>> void gettimeofday(struct timeval *tv, struct timezone *tz) >>> { >>> __int64 time; >>> double elapsed; >>> >>> QueryPerformanceCounter((LARGE_INTEGER*)&time); >>> >>> elapsed = (double)(time - start) / (double)freq; >>> >>> tv->tv_sec = (long)elapsed; >>> tv->tv_usec = (long)((elapsed-tv->tv_sec) * 1000000); >>> } >>> >>> enjoy, >>> Adam >>> >>> ----- Original Message ----- From: "Steven Sokol" >>> <ss...@so...> >>> To: <iax...@li...> >>> Sent: Thursday, February 05, 2004 11:34 AM >>> Subject: RE: [Iaxclient-devel] Some data related to the new bug... >>> >>> >>> >>>> Yes. Guilty as charged. It always happens UNDER WINDOWS. >>>> >>>> I believe that the gettimeofday() is being replaced by a function >>>> based on >>>> GetTickCount(). I wonder if that doesn't have something to do with >>>> it. >>>> >>>> Steve S >>>> >>>> -----Original Message----- >>>> From: iax...@li... >>>> [mailto:iax...@li...] On Behalf Of >>>> Steve >>>> Underwood >>>> Sent: Wednesday, February 04, 2004 5:48 PM >>>> To: iax...@li... >>>> Subject: Re: [Iaxclient-devel] Some data related to the new bug... >>>> >>>> Steven Sokol wrote: >>>> >>>> >>>>> More notes: >>>>> >>>>> 1. It ALWAYS happens. It is not an intermittent issue. This >>>>> happens >>>>> >>> for >>> >>>>> EVERY IAX2-to-IAX2 call made using iaxClient. >>>>> >>>>> >>>>> >>>> Not EVERY call. I make hour long calls using iaxclient IAX2-to-IAX2 >>>> and >>>> have no trouble. I use Linux. Is that the difference? >>>> >>>> >>>>> 2. The timing is uncanny. It ALWAYS happens after 65-67 seconds. >>>>> >>>>> 3. The audio dies but the call in not immediately torn down. The >>>>> call >>>>> eventually is eventually killed when the PING/PONG cycle times out >>>>> some >>>>> seconds later (perhaps over a minute in some of my tests). >>>>> >>>>> 4. In EVERY case, the Asterisk kicks out the aforementioned voice >>>>> frame >>>>> retransmit message. >>>>> >>>>> >>>>> >>>> As Adam said, there is something wrong if a voice frame is being >>>> retransmitted at that point in the call. Perhaps checking places >>>> where >>>> the frame is tagged for retransmission would home in on the problem. >>>> >>>> >>>>> 5. I don't see registration messages coming through at the same >>>>> time. I >>>>> was originally guessing that this happened during the re-reg >>>>> process. >>>>> >>> Not >>> >>>>> so (or at least that doesn't seem to be the case -- could be that >>>>> the >>>>> >>>> re-reg >>>> >>>>> that takes place prior to the error causes a problem). >>>>> >>>>> >>>>> >>>> Regards, >>>> Steve >>>> >>>> >>>> >>>> >> > |
|
From: Steve K. <st...@st...> - 2004-02-05 19:08:48
|
Steven Sokol wrote:
> Steve,
>
>
>
> Can you give me a clue as to where the decision is made to use a full
> frame for voice vs. a mini? I also want to understand if I am correct
> in my assumption that we are dealing with four distinct legs: [A] <->
> [Asterisk] <-> [B] or if Asterisk somehow redirects/reinvites the
> connection to the proper destination ([A] <-> [B]). Since Asterisk
> throws the Retrans message, I would guess it is the first option.
>
>
>
> Is there any way to know where the audio data is going? The monitors
> remain active, and the call is still live. Why would the audio stream
> simply _/stop/_ instead of just pausing.
>
first question: see chan_iax2.c, and the code I excerpted earlier. i.e.
when the "sendmini" flag is set.
Asterisk and IAX2 has a feature called "native bridging" for IAX2, where
when you have two IAX2 calls going through an asterisk server, the
asterisk server lets them know about it, and they will try to send audio
frames directly to each other, as opposed to going through the asterisk
server.
In this mode, control frames are still supposed to go through the
asterisk server, while audio frames go directly from endpoint to
endpoint. Mark has recently written a better description of this on the
asterisk list. This only happens when certain conditions are satisfied:
1) Both ends of the calls are using the same codec,
2) The two ends are able to reach each other directly (i.e. there's no
NAT, firewall, etc involved).
3) maybe more?
I _think_ that libiax2 and therefore iaxclient should support this. If
this is the case, and you're using this feature, then I have a feeling
that the bug may something along the lines of iaxclient/libiax2 sending
the "full" voice frame to the wrong place. I.e. maybe it should be
going directly to the other iaxclient, and it is instead being sent
through asterisk, or vice versa. OR, the problem could just be that
the ack is being sent to the wrong place, etc.
Using ethereal or even tcpdump or another sniffer on the different
segments should show you what's going on.
The code for this might be the "transfer" stuff in libiax2 (or maybe
not. I'm not sure if that's something different, when the whole call is
transfered, and not just bridged) see EVENT_TX{REPLY,REJECT,ACCEPT}, and
the variable "transfer". In chan_iax2, this would be the stuff
controlled by the preprocessor symbol BRIDGE_OPTIMIZATION, and variables
with the name bridge.
-SteveK
>
>
> ------------------------------------------------------------------------
>
> *From:* iax...@li...
> [mailto:iax...@li...] *On Behalf Of
> *Steve Kann
> *Sent:* Thursday, February 05, 2004 8:35 AM
> *To:* Michael Van Donselaar
> *Cc:* iax...@li...
> *Subject:* Re: [Iaxclient-devel] Some data related to the new bug...
>
>
>
> Michael Van Donselaar wrote:
>
>On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <ad...@te...> <mailto:ad...@te...> wrote:
>
>
>
>
>
>>usec is nanoseconds (1 second = a million nanoseconds)
>>
>>
>>
>
>
>And I can't even blame this on not having my coffee yet. I was seeing usec, but
>
>thinking msec.
>
>
>
>I don't know if I'm seeing something that's not there, but is anyone suspicious
>
>that 65-67 second sounds an awful lot like 65536 msec?
>
>
>
>
> Yes, it sounds exactly like that.
>
> I don't actually think it is the Win32 gettimeofday implementation,
> but some other set of circumstances which cause this problem. I'm not
> sure why Steve U isn't seeing this, but others are, but there may be
> another explanation for that.
>
> I think it has to do with the full frame vs mini frame for voice
> frames, somehow. I haven't seen this happen myself, though.
>
> -SteveK
>
|
|
From: Steve K. <st...@st...> - 2004-02-05 19:48:26
|
In looking at the code a bit more, it looks like libiax2 doesn't support
native bridging. Regardless, it would only work if both ends of the
call were IAX2; I guess a part of your call path is all IAX2 (you could
go around the middle asterisk server), but you couldn't native bridge
between IAX2 and SIP.
Kim Hendrikse wrote:
>FYI,
>
>In reference to "The bug" I have been using the iaxcomm program quite
>a lot to go from
>
>iaxcomm <-> asterisk - NAT <-> asterisk - NAT <-> SIP (ATA 186)
>
>This evening I made a call and apparently one side of the conversation
>dropped out. The SIP/ATA side could hear me fine but I couldn't hear them
>anymore. This happened after about 3 minutes. I was tracing the packets
>on one side, the iaxcomm side, with Alastair Maws iax2 plugin into ethereal.
>I saw no sign of any attempt to bridge, nor should it be able to actually
>as there is nat in the way. Having said that, it may be useful to check
>that the configuration files reflect this fact so the other side knows
>that it is unreachable as I only traced one side.
>
>Yesterday evening I made several calls and they would simply drop out
>after random times, usually around 4 minutes or so, but then I didn't have
>the iax2 plugin in ethereal nor was I tracing it.
>
> - Kim
>
>
>
>>Steven Sokol wrote:
>>
>>
>>
>>>Steve,
>>>
>>>
>>>
>>>Can you give me a clue as to where the decision is made to use a full
>>>frame for voice vs. a mini? I also want to understand if I am correct
>>>in my assumption that we are dealing with four distinct legs: [A] <->
>>>[Asterisk] <-> [B] or if Asterisk somehow redirects/reinvites the
>>>connection to the proper destination ([A] <-> [B]). Since Asterisk
>>>throws the Retrans message, I would guess it is the first option.
>>>
>>>
>>>
>>>Is there any way to know where the audio data is going? The monitors
>>>remain active, and the call is still live. Why would the audio stream
>>>simply _/stop/_ instead of just pausing.
>>>
>>>
>>>
>>first question: see chan_iax2.c, and the code I excerpted earlier. i.e.
>>when the "sendmini" flag is set.
>>
>>Asterisk and IAX2 has a feature called "native bridging" for IAX2, where
>>when you have two IAX2 calls going through an asterisk server, the
>>asterisk server lets them know about it, and they will try to send audio
>>frames directly to each other, as opposed to going through the asterisk
>>server.
>>
>>In this mode, control frames are still supposed to go through the
>>asterisk server, while audio frames go directly from endpoint to
>>endpoint. Mark has recently written a better description of this on the
>>asterisk list. This only happens when certain conditions are satisfied:
>>
>>1) Both ends of the calls are using the same codec,
>>2) The two ends are able to reach each other directly (i.e. there's no
>>NAT, firewall, etc involved).
>>3) maybe more?
>>
>>I _think_ that libiax2 and therefore iaxclient should support this. If
>>this is the case, and you're using this feature, then I have a feeling
>>that the bug may something along the lines of iaxclient/libiax2 sending
>>the "full" voice frame to the wrong place. I.e. maybe it should be
>>going directly to the other iaxclient, and it is instead being sent
>>through asterisk, or vice versa. OR, the problem could just be that
>>the ack is being sent to the wrong place, etc.
>>
>>Using ethereal or even tcpdump or another sniffer on the different
>>segments should show you what's going on.
>>
>>The code for this might be the "transfer" stuff in libiax2 (or maybe
>>not. I'm not sure if that's something different, when the whole call is
>>transfered, and not just bridged) see EVENT_TX{REPLY,REJECT,ACCEPT}, and
>>the variable "transfer". In chan_iax2, this would be the stuff
>>controlled by the preprocessor symbol BRIDGE_OPTIMIZATION, and variables
>>with the name bridge.
>>
>>-SteveK
>>
>>
>>
>>
>>
>>
>>>------------------------------------------------------------------------
>>>
>>>*From:* iax...@li...
>>>[mailto:iax...@li...] *On Behalf Of
>>>*Steve Kann
>>>*Sent:* Thursday, February 05, 2004 8:35 AM
>>>*To:* Michael Van Donselaar
>>>*Cc:* iax...@li...
>>>*Subject:* Re: [Iaxclient-devel] Some data related to the new bug...
>>>
>>>
>>>
>>>Michael Van Donselaar wrote:
>>>
>>>On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <ad...@te...>
>>><mailto:ad...@te...> wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>usec is nanoseconds (1 second = a million nanoseconds)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>And I can't even blame this on not having my coffee yet. I was seeing
>>>usec, but
>>>
>>>thinking msec.
>>>
>>>
>>>
>>>I don't know if I'm seeing something that's not there, but is anyone
>>>suspicious
>>>
>>>that 65-67 second sounds an awful lot like 65536 msec?
>>>
>>>
>>>
>>>
>>>Yes, it sounds exactly like that.
>>>
>>>I don't actually think it is the Win32 gettimeofday implementation,
>>>but some other set of circumstances which cause this problem. I'm not
>>>sure why Steve U isn't seeing this, but others are, but there may be
>>>another explanation for that.
>>>
>>>I think it has to do with the full frame vs mini frame for voice
>>>frames, somehow. I haven't seen this happen myself, though.
>>>
>>>-SteveK
>>>
>>>
>>>
>
>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X