Menu
▾
▴
Re: [Iaxclient-devel] Some data related to the new bug...
|
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 > > > |
