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: Richard P. <ric...@co...> - 2004-10-26 15:19:08
|
Hi Did the patch work? I am experiencing the same problem. When I receive a call from another iax softphone to my softphone, using the latest iax library from the cvs, my softphone crashes. If I use a version of the phone compiled with an older version of the library then everything works fine. -----Original Message----- From: iax...@li... [mailto:iax...@li...]On Behalf Of Michael Workman Sent: 26 October 2004 02:51 To: 'Steven M. Sokol'; Iax...@li... Subject: RE: [Iaxclient-devel] Strange fatal issue with attempted native transfer behind same NAT... Yes... You would have to enter the client side manually... But the server side I have a diff... I just been busy on service call just got back... -----Original Message----- From: iax...@li... [mailto:iax...@li...] On Behalf Of Steven M. Sokol Sent: Monday, October 25, 2004 9:47 PM To: Michael Workman; Iax...@li... Subject: Re: [Iaxclient-devel] Strange fatal issue with attempted native transfer behind same NAT... Ok, but you said you had a patch for libiax2, right? That should be cross-platform, right? Thanks, Steve >My library is for vs.net... Not for gcc > > >-----Original Message----- >From: iax...@li... >[mailto:iax...@li...] On Behalf Of Steve >Kann >Sent: Monday, October 25, 2004 9:31 PM >To: Steven Sokol; IMB Recipient 1 >Cc: Michael Workman; Iaxclient-Devel >Subject: Re: [Iaxclient-devel] Strange fatal issue with attempted >native transfer behind same NAT... > > >Sounds like it might be a bug in the code that Bill Doll sent me, and I >integrated last week; Bill? > >P.S. If you're actually working on the library, I suggest that you join >the iaxclient-cvs mailing list, so you'll see all diffs as they are >committed to CVS. > > >-SteveK > > >Steven Sokol wrote: > > > >>Michael, >> >>Please do. I will give it a try and let you know how it works out. >> >>Thanks, >> >>Steve >> >>Michael Workman wrote: >> >> >> >>>Yes I have experienced that on my IAX Library... I have a patch for >>>Asterisk and iax.c If you want let me know Steve I will give you it >>> >>> >>> >>> >>> >>>-----Original Message----- >>>From: iax...@li... >>>[mailto:iax...@li...] On Behalf Of >>>Steven Sokol >>>Sent: Monday, October 25, 2004 5:28 PM >>>To: Iax...@li... >>>Subject: [Iaxclient-devel] Strange fatal issue with attempted native >>>transfer behind same NAT... >>> >>>Ok, this one is really quite strange. I have to do some more >>>testing, but I seem to have real problems in IAX Phone running under >>>the new library whenever I try to make an IAX Phone -to- IAX Phone >>>call with both phones behind the same NAT. Both phones (on different >>>PCs) crash right after Asterisk attempts to get them to talk to each >>>other (sends TXREQ). >>> >>>I can't definitively say that it is related to the NAT however. >>>Could be >>>ANY native transfer. I need to adjust my configuration an try again. >>>Here's the debugging output from the IAX Phone /receiveing/ the >>>call: >>> >>>Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX >>>Subclass: ACK Timestamp: 00102ms SCall: 21019 DCall: 00006 >>>[63.146.169.121:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >>>ACK Timestamp: 00062ms SCall: 00006 DCall: 21019 >>>[63.146.169.121:4569] >>>Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >>>HANGUP >>> Timestamp: 00014ms SCall: 00037 DCall: 00000 [64.151.32.77:4569] >>>Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX >>>Subclass: ACK Timestamp: 00014ms SCall: 21020 DCall: 00037 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >>>NEW Timestamp: 00014ms SCall: 00038 DCall: 00000 >>>[64.151.32.77:4569] >>> VERSION : 2 >>> CALLED NUMBER : s >>> CALLING NUMBER : 8168221807 >>> CALLING NAME : Steven Sokol >>> LANGUAGE : en >>> FORMAT : 1024 >>> CAPABILITY : 1542 >>> ADSICPE : 0 >>> DATE TIME : 156861043 >>> >>>Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX >>>Subclass: ACK Timestamp: 00014ms SCall: 21021 DCall: 00038 >>>[64.151.32.77:4569] >>>Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 001 Type: IAX >>>Subclass: ACCEPT >>> Timestamp: 00015ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >>> FORMAT : 1024 >>> >>>Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 001 Type: CONTROL >>>Subclass: RINGING >>> Timestamp: 00003ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: >>>ACK Timestamp: 00015ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >>>ACK Timestamp: 00003ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>>Tx-Frame Retry[010] -- OSeqno: 002 ISeqno: 001 Type: CONTROL >>>Subclass: ANSWER >>> Timestamp: 02687ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >>>ACK Timestamp: 02687ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >>>TXREQ Timestamp: 02712ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>> APPARENT ADDRES : IPV4 64.151.42.28:4668 >>> CALL NUMBER : 21328 >>> TRANSFER ID : 1501550657 >>> >>>libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c >>>line >>>1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: >>>Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1614: Making new >>>session, peer callno 37, our callno 21020 libiax2/src/iax.c line >>>1614: Making new session, peer callno 38, our callno 21021 >>>libiax2/src/iax.c line 1871: >>>Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 2 >>> >>>--------------------------------------------------------------------- >>>Here'e the output from the originating phone: >>>--------------------------------------------------------------------- >>> >>>Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX >>>Subclass: NEW Timestamp: 00003ms SCall: 21328 DCall: 00000 >>>[64.151.32.77:4569] >>> VERSION : 2 >>> CALLING NUMBER : 8168221807 >>> CALLING NAME : Steven Sokol >>> FORMAT : 1024 >>> CAPABILITY : 1542 >>> USERNAME : ssokol03_sokol >>> CALLED NUMBER : 115 >>> DNID : 115 >>> >>>Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: >>>ACCEPT >>> Timestamp: 00010ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>> FORMAT : 1024 >>> >>>Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX >>>Subclass: ACK Timestamp: 00010ms SCall: 21328 DCall: 00014 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: >>>ANSWER >>> Timestamp: 00013ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>>Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 002 Type: IAX >>>Subclass: ACK Timestamp: 00013ms SCall: 21328 DCall: 00014 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass: >>>RINGING >>> Timestamp: 00016ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>>Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 003 Type: IAX >>>Subclass: ACK Timestamp: 00016ms SCall: 21328 DCall: 00014 >>>[64.151.32.77:4569] >>>Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 003 Type: VOICE >>>Subclass: 138 >>> Timestamp: 00120ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: IAX Subclass: >>>ACK Timestamp: 00120ms SCall: 00014 DCall: 21328 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: CONTROL Subclass: >>>(255?) >>> Timestamp: 02711ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass: >>>TXREQ Timestamp: 02714ms SCall: 00014 DCall: 21328 >>>[64.151.32.77:4569] >>> APPARENT ADDRES : IPV4 64.151.42.28:4667 >>> CALL NUMBER : 21021 >>> TRANSFER ID : 1501550657 >>> >>>libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c >>>line >>>1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 ERROR encoding (no samples output >>>(samples=160) libiax2/src/iax.c line 1871: Cancelling transmission of >>>packet 1 libiax2/src/iax.c line 2153: Don't know what to do with AST >>>control >>>-2147483648 >>> >>>--------------------------------------------------------------------- >>> >>>Following this exchange BOTH clients immediately die and the debugger >>>is WAY off base as to where the error occurs. It always shows the >>>last function in my integration DLL -- a function that is not being >>>called when the crash occurs. >>> >>>Anybody have any thoughts? >>> >>>Thanks, >>> >>>Steve >>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: IT Product Guide on >>>ITManagersJournal Use IT products in your business? Tell us what you >>> >>> >think of them. > > >>>Give us >>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >>>out more http://productguide.itmanagersjournal.com/guidepromo.tmpl >>>_______________________________________________ >>>Iaxclient-devel mailing list >>>Iax...@li... >>>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel >>> >>> >>> >>> > > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on >ITManagersJournal Use IT products in your business? Tell us what you >think of them. Give us Your Opinions, Get Free ThinkGeek Gift >Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >Iaxclient-devel mailing list >Iax...@li... >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Iaxclient-devel mailing list Iax...@li... https://lists.sourceforge.net/lists/listinfo/iaxclient-devel ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Iaxclient-devel mailing list Iax...@li... https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
|
From: Michael V. D. <mi...@va...> - 2004-10-26 13:22:48
|
> -----Original Message----- > From: iax...@li... > [mailto:iax...@li...] On > Behalf Of xavier dutoit > Sent: Tuesday, October 26, 2004 6:43 AM > To: iax...@li... > Subject: [Iaxclient-devel] What is the "incoming ring on PC speaker" ? > > Hello, > > I've been happily using iaxclient (on linux) from Senegal for > quite a while. However, I'd like to have a feature that I > miss: the ability to ring on the PC speaker (as opposed to > only the headphone, as I don't ware it all the day). On the > Options/Audio devices, you have a check box "incoming ring on > the PC speaker". I was playing around with having the speaker beep, but never got it to work well. I just wasn't satisfied with a beep. The other problem is, the only info I could find on how to beep the speaker allowed you to specify the tone and duration, and start the beep. No way to specify a cadence, or cancel an in-progress beep when you answer the phone. The linux Beep(int freq, int dur) is in there, and you could put a call to it in the Ringer::Start to call Beep(), but again, I don't know how you'd stop it when you answer. > Isn't it what I'd like to have ? > Is this something to do on the config to make it work on > linux (obviously, I can't make it work, otherwise I wouldn't > be bothering you)? So, it's in the config, I even think that it's saving your preference. It's just not implemented in the code. > Thanks in advance, > > Xavier > > P.S. Just saw the posts about the new codecs. > Congratulations! I'm going to update my cvs and give it a try > ASAP and let you know... > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on > ITManagersJournal > Use IT products in your business? Tell us what you think of > them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to > find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.782 / Virus Database: 528 - Release Date: 10/22/2004 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.782 / Virus Database: 528 - Release Date: 10/22/2004 |
|
From: xavier d. <xa...@sy...> - 2004-10-26 09:43:31
|
Hello, I've been happily using iaxclient (on linux) from Senegal for quite a while. However, I'd like to have a feature that I miss: the ability to ring on the PC speaker (as opposed to only the headphone, as I don't ware it all the day). On the Options/Audio devices, you have a check box "incoming ring on the PC speaker". Isn't it what I'd like to have ? Is this something to do on the config to make it work on linux (obviously, I can't make it work, otherwise I wouldn't be bothering you)? Thanks in advance, Xavier P.S. Just saw the posts about the new codecs. Congratulations! I'm going to update my cvs and give it a try ASAP and let you know... |
|
From: Michael W. <mwo...@im...> - 2004-10-26 01:50:51
|
Yes... You would have to enter the client side manually... But the server side I have a diff... I just been busy on service call just got back... -----Original Message----- From: iax...@li... [mailto:iax...@li...] On Behalf Of Steven M. Sokol Sent: Monday, October 25, 2004 9:47 PM To: Michael Workman; Iax...@li... Subject: Re: [Iaxclient-devel] Strange fatal issue with attempted native transfer behind same NAT... Ok, but you said you had a patch for libiax2, right? That should be cross-platform, right? Thanks, Steve >My library is for vs.net... Not for gcc > > >-----Original Message----- >From: iax...@li... >[mailto:iax...@li...] On Behalf Of Steve >Kann >Sent: Monday, October 25, 2004 9:31 PM >To: Steven Sokol; IMB Recipient 1 >Cc: Michael Workman; Iaxclient-Devel >Subject: Re: [Iaxclient-devel] Strange fatal issue with attempted >native transfer behind same NAT... > > >Sounds like it might be a bug in the code that Bill Doll sent me, and I >integrated last week; Bill? > >P.S. If you're actually working on the library, I suggest that you join >the iaxclient-cvs mailing list, so you'll see all diffs as they are >committed to CVS. > > >-SteveK > > >Steven Sokol wrote: > > > >>Michael, >> >>Please do. I will give it a try and let you know how it works out. >> >>Thanks, >> >>Steve >> >>Michael Workman wrote: >> >> >> >>>Yes I have experienced that on my IAX Library... I have a patch for >>>Asterisk and iax.c If you want let me know Steve I will give you it >>> >>> >>> >>> >>> >>>-----Original Message----- >>>From: iax...@li... >>>[mailto:iax...@li...] On Behalf Of >>>Steven Sokol >>>Sent: Monday, October 25, 2004 5:28 PM >>>To: Iax...@li... >>>Subject: [Iaxclient-devel] Strange fatal issue with attempted native >>>transfer behind same NAT... >>> >>>Ok, this one is really quite strange. I have to do some more >>>testing, but I seem to have real problems in IAX Phone running under >>>the new library whenever I try to make an IAX Phone -to- IAX Phone >>>call with both phones behind the same NAT. Both phones (on different >>>PCs) crash right after Asterisk attempts to get them to talk to each >>>other (sends TXREQ). >>> >>>I can't definitively say that it is related to the NAT however. >>>Could be >>>ANY native transfer. I need to adjust my configuration an try again. >>>Here's the debugging output from the IAX Phone /receiveing/ the >>>call: >>> >>>Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX >>>Subclass: ACK Timestamp: 00102ms SCall: 21019 DCall: 00006 >>>[63.146.169.121:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >>>ACK Timestamp: 00062ms SCall: 00006 DCall: 21019 >>>[63.146.169.121:4569] >>>Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >>>HANGUP >>> Timestamp: 00014ms SCall: 00037 DCall: 00000 [64.151.32.77:4569] >>>Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX >>>Subclass: ACK Timestamp: 00014ms SCall: 21020 DCall: 00037 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >>>NEW Timestamp: 00014ms SCall: 00038 DCall: 00000 >>>[64.151.32.77:4569] >>> VERSION : 2 >>> CALLED NUMBER : s >>> CALLING NUMBER : 8168221807 >>> CALLING NAME : Steven Sokol >>> LANGUAGE : en >>> FORMAT : 1024 >>> CAPABILITY : 1542 >>> ADSICPE : 0 >>> DATE TIME : 156861043 >>> >>>Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX >>>Subclass: ACK Timestamp: 00014ms SCall: 21021 DCall: 00038 >>>[64.151.32.77:4569] >>>Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 001 Type: IAX >>>Subclass: ACCEPT >>> Timestamp: 00015ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >>> FORMAT : 1024 >>> >>>Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 001 Type: CONTROL >>>Subclass: RINGING >>> Timestamp: 00003ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: >>>ACK Timestamp: 00015ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >>>ACK Timestamp: 00003ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>>Tx-Frame Retry[010] -- OSeqno: 002 ISeqno: 001 Type: CONTROL >>>Subclass: ANSWER >>> Timestamp: 02687ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >>>ACK Timestamp: 02687ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >>>TXREQ Timestamp: 02712ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>> APPARENT ADDRES : IPV4 64.151.42.28:4668 >>> CALL NUMBER : 21328 >>> TRANSFER ID : 1501550657 >>> >>>libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c >>>line >>>1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: >>>Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1614: Making new >>>session, peer callno 37, our callno 21020 libiax2/src/iax.c line >>>1614: Making new session, peer callno 38, our callno 21021 >>>libiax2/src/iax.c line 1871: >>>Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 2 >>> >>>--------------------------------------------------------------------- >>>Here'e the output from the originating phone: >>>--------------------------------------------------------------------- >>> >>>Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX >>>Subclass: NEW Timestamp: 00003ms SCall: 21328 DCall: 00000 >>>[64.151.32.77:4569] >>> VERSION : 2 >>> CALLING NUMBER : 8168221807 >>> CALLING NAME : Steven Sokol >>> FORMAT : 1024 >>> CAPABILITY : 1542 >>> USERNAME : ssokol03_sokol >>> CALLED NUMBER : 115 >>> DNID : 115 >>> >>>Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: >>>ACCEPT >>> Timestamp: 00010ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>> FORMAT : 1024 >>> >>>Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX >>>Subclass: ACK Timestamp: 00010ms SCall: 21328 DCall: 00014 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: >>>ANSWER >>> Timestamp: 00013ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>>Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 002 Type: IAX >>>Subclass: ACK Timestamp: 00013ms SCall: 21328 DCall: 00014 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass: >>>RINGING >>> Timestamp: 00016ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>>Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 003 Type: IAX >>>Subclass: ACK Timestamp: 00016ms SCall: 21328 DCall: 00014 >>>[64.151.32.77:4569] >>>Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 003 Type: VOICE >>>Subclass: 138 >>> Timestamp: 00120ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: IAX Subclass: >>>ACK Timestamp: 00120ms SCall: 00014 DCall: 21328 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: CONTROL Subclass: >>>(255?) >>> Timestamp: 02711ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass: >>>TXREQ Timestamp: 02714ms SCall: 00014 DCall: 21328 >>>[64.151.32.77:4569] >>> APPARENT ADDRES : IPV4 64.151.42.28:4667 >>> CALL NUMBER : 21021 >>> TRANSFER ID : 1501550657 >>> >>>libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c >>>line >>>1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 ERROR encoding (no samples output >>>(samples=160) libiax2/src/iax.c line 1871: Cancelling transmission of >>>packet 1 libiax2/src/iax.c line 2153: Don't know what to do with AST >>>control >>>-2147483648 >>> >>>--------------------------------------------------------------------- >>> >>>Following this exchange BOTH clients immediately die and the debugger >>>is WAY off base as to where the error occurs. It always shows the >>>last function in my integration DLL -- a function that is not being >>>called when the crash occurs. >>> >>>Anybody have any thoughts? >>> >>>Thanks, >>> >>>Steve >>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: IT Product Guide on >>>ITManagersJournal Use IT products in your business? Tell us what you >>> >>> >think of them. > > >>>Give us >>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >>>out more http://productguide.itmanagersjournal.com/guidepromo.tmpl >>>_______________________________________________ >>>Iaxclient-devel mailing list >>>Iax...@li... >>>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel >>> >>> >>> >>> > > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on >ITManagersJournal Use IT products in your business? Tell us what you >think of them. Give us Your Opinions, Get Free ThinkGeek Gift >Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >Iaxclient-devel mailing list >Iax...@li... >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Iaxclient-devel mailing list Iax...@li... https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
|
From: Steven M. S. <ss...@so...> - 2004-10-26 01:47:45
|
Ok, but you said you had a patch for libiax2, right? That should be cross-platform, right? Thanks, Steve >My library is for vs.net... Not for gcc > > >-----Original Message----- >From: iax...@li... >[mailto:iax...@li...] On Behalf Of Steve Kann >Sent: Monday, October 25, 2004 9:31 PM >To: Steven Sokol; IMB Recipient 1 >Cc: Michael Workman; Iaxclient-Devel >Subject: Re: [Iaxclient-devel] Strange fatal issue with attempted native >transfer behind same NAT... > > >Sounds like it might be a bug in the code that Bill Doll sent me, and I >integrated last week; Bill? > >P.S. If you're actually working on the library, I suggest that you join the >iaxclient-cvs mailing list, so you'll see all diffs as they are committed to >CVS. > > >-SteveK > > >Steven Sokol wrote: > > > >>Michael, >> >>Please do. I will give it a try and let you know how it works out. >> >>Thanks, >> >>Steve >> >>Michael Workman wrote: >> >> >> >>>Yes I have experienced that on my IAX Library... I have a patch for >>>Asterisk and iax.c If you want let me know Steve I will give you it >>> >>> >>> >>> >>> >>>-----Original Message----- >>>From: iax...@li... >>>[mailto:iax...@li...] On Behalf Of >>>Steven Sokol >>>Sent: Monday, October 25, 2004 5:28 PM >>>To: Iax...@li... >>>Subject: [Iaxclient-devel] Strange fatal issue with attempted native >>>transfer behind same NAT... >>> >>>Ok, this one is really quite strange. I have to do some more >>>testing, but I seem to have real problems in IAX Phone running under >>>the new library whenever I try to make an IAX Phone -to- IAX Phone >>>call with both phones behind the same NAT. Both phones (on different >>>PCs) crash right after Asterisk attempts to get them to talk to each >>>other (sends TXREQ). >>> >>>I can't definitively say that it is related to the NAT however. >>>Could be >>>ANY native transfer. I need to adjust my configuration an try again. >>>Here's the debugging output from the IAX Phone /receiveing/ the >>>call: >>> >>>Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX >>>Subclass: ACK Timestamp: 00102ms SCall: 21019 DCall: 00006 >>>[63.146.169.121:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >>>ACK Timestamp: 00062ms SCall: 00006 DCall: 21019 >>>[63.146.169.121:4569] >>>Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >>>HANGUP >>> Timestamp: 00014ms SCall: 00037 DCall: 00000 [64.151.32.77:4569] >>>Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX >>>Subclass: ACK Timestamp: 00014ms SCall: 21020 DCall: 00037 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >>>NEW Timestamp: 00014ms SCall: 00038 DCall: 00000 >>>[64.151.32.77:4569] >>> VERSION : 2 >>> CALLED NUMBER : s >>> CALLING NUMBER : 8168221807 >>> CALLING NAME : Steven Sokol >>> LANGUAGE : en >>> FORMAT : 1024 >>> CAPABILITY : 1542 >>> ADSICPE : 0 >>> DATE TIME : 156861043 >>> >>>Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX >>>Subclass: ACK Timestamp: 00014ms SCall: 21021 DCall: 00038 >>>[64.151.32.77:4569] >>>Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 001 Type: IAX >>>Subclass: ACCEPT >>> Timestamp: 00015ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >>> FORMAT : 1024 >>> >>>Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 001 Type: CONTROL >>>Subclass: RINGING >>> Timestamp: 00003ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: >>>ACK Timestamp: 00015ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >>>ACK Timestamp: 00003ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>>Tx-Frame Retry[010] -- OSeqno: 002 ISeqno: 001 Type: CONTROL >>>Subclass: ANSWER >>> Timestamp: 02687ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >>>ACK Timestamp: 02687ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >>>TXREQ Timestamp: 02712ms SCall: 00038 DCall: 21021 >>>[64.151.32.77:4569] >>> APPARENT ADDRES : IPV4 64.151.42.28:4668 >>> CALL NUMBER : 21328 >>> TRANSFER ID : 1501550657 >>> >>>libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c >>>line >>>1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: >>>Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1614: Making new >>>session, peer callno 37, our callno 21020 libiax2/src/iax.c line >>>1614: Making new session, peer callno 38, our callno 21021 >>>libiax2/src/iax.c line 1871: >>>Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 2 >>> >>>--------------------------------------------------------------------- >>>Here'e the output from the originating phone: >>>--------------------------------------------------------------------- >>> >>>Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX >>>Subclass: NEW Timestamp: 00003ms SCall: 21328 DCall: 00000 >>>[64.151.32.77:4569] >>> VERSION : 2 >>> CALLING NUMBER : 8168221807 >>> CALLING NAME : Steven Sokol >>> FORMAT : 1024 >>> CAPABILITY : 1542 >>> USERNAME : ssokol03_sokol >>> CALLED NUMBER : 115 >>> DNID : 115 >>> >>>Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: >>>ACCEPT >>> Timestamp: 00010ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>> FORMAT : 1024 >>> >>>Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX >>>Subclass: ACK Timestamp: 00010ms SCall: 21328 DCall: 00014 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: >>>ANSWER >>> Timestamp: 00013ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>>Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 002 Type: IAX >>>Subclass: ACK Timestamp: 00013ms SCall: 21328 DCall: 00014 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass: >>>RINGING >>> Timestamp: 00016ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>>Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 003 Type: IAX >>>Subclass: ACK Timestamp: 00016ms SCall: 21328 DCall: 00014 >>>[64.151.32.77:4569] >>>Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 003 Type: VOICE >>>Subclass: 138 >>> Timestamp: 00120ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: IAX Subclass: >>>ACK Timestamp: 00120ms SCall: 00014 DCall: 21328 >>>[64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: CONTROL Subclass: >>>(255?) >>> Timestamp: 02711ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >>>Rx-Frame Retry[No] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass: >>>TXREQ Timestamp: 02714ms SCall: 00014 DCall: 21328 >>>[64.151.32.77:4569] >>> APPARENT ADDRES : IPV4 64.151.42.28:4667 >>> CALL NUMBER : 21021 >>> TRANSFER ID : 1501550657 >>> >>>libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c >>>line >>>1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >>>Cancelling >>>transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >>>transmission of packet 0 ERROR encoding (no samples output >>>(samples=160) libiax2/src/iax.c line 1871: Cancelling transmission of >>>packet 1 libiax2/src/iax.c line 2153: Don't know what to do with AST >>>control >>>-2147483648 >>> >>>--------------------------------------------------------------------- >>> >>>Following this exchange BOTH clients immediately die and the debugger >>>is WAY off base as to where the error occurs. It always shows the >>>last function in my integration DLL -- a function that is not being >>>called when the crash occurs. >>> >>>Anybody have any thoughts? >>> >>>Thanks, >>> >>>Steve >>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: IT Product Guide on >>>ITManagersJournal Use IT products in your business? Tell us what you >>> >>> >think of them. > > >>>Give us >>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >>>out more http://productguide.itmanagersjournal.com/guidepromo.tmpl >>>_______________________________________________ >>>Iaxclient-devel mailing list >>>Iax...@li... >>>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel >>> >>> >>> >>> > > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >Use IT products in your business? Tell us what you think of them. Give us >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >Iaxclient-devel mailing list >Iax...@li... >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > |
|
From: Michael W. <mwo...@im...> - 2004-10-26 01:43:19
|
My library is for vs.net... Not for gcc -----Original Message----- From: iax...@li... [mailto:iax...@li...] On Behalf Of Steve Kann Sent: Monday, October 25, 2004 9:31 PM To: Steven Sokol; IMB Recipient 1 Cc: Michael Workman; Iaxclient-Devel Subject: Re: [Iaxclient-devel] Strange fatal issue with attempted native transfer behind same NAT... Sounds like it might be a bug in the code that Bill Doll sent me, and I integrated last week; Bill? P.S. If you're actually working on the library, I suggest that you join the iaxclient-cvs mailing list, so you'll see all diffs as they are committed to CVS. -SteveK Steven Sokol wrote: > Michael, > > Please do. I will give it a try and let you know how it works out. > > Thanks, > > Steve > > Michael Workman wrote: > >> Yes I have experienced that on my IAX Library... I have a patch for >> Asterisk and iax.c If you want let me know Steve I will give you it >> >> >> >> >> >> -----Original Message----- >> From: iax...@li... >> [mailto:iax...@li...] On Behalf Of >> Steven Sokol >> Sent: Monday, October 25, 2004 5:28 PM >> To: Iax...@li... >> Subject: [Iaxclient-devel] Strange fatal issue with attempted native >> transfer behind same NAT... >> >> Ok, this one is really quite strange. I have to do some more >> testing, but I seem to have real problems in IAX Phone running under >> the new library whenever I try to make an IAX Phone -to- IAX Phone >> call with both phones behind the same NAT. Both phones (on different >> PCs) crash right after Asterisk attempts to get them to talk to each >> other (sends TXREQ). >> >> I can't definitively say that it is related to the NAT however. >> Could be >> ANY native transfer. I need to adjust my configuration an try again. >> Here's the debugging output from the IAX Phone /receiveing/ the >> call: >> >> Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX >> Subclass: ACK Timestamp: 00102ms SCall: 21019 DCall: 00006 >> [63.146.169.121:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >> ACK Timestamp: 00062ms SCall: 00006 DCall: 21019 >> [63.146.169.121:4569] >> Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >> HANGUP >> Timestamp: 00014ms SCall: 00037 DCall: 00000 [64.151.32.77:4569] >> Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX >> Subclass: ACK Timestamp: 00014ms SCall: 21020 DCall: 00037 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >> NEW Timestamp: 00014ms SCall: 00038 DCall: 00000 >> [64.151.32.77:4569] >> VERSION : 2 >> CALLED NUMBER : s >> CALLING NUMBER : 8168221807 >> CALLING NAME : Steven Sokol >> LANGUAGE : en >> FORMAT : 1024 >> CAPABILITY : 1542 >> ADSICPE : 0 >> DATE TIME : 156861043 >> >> Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX >> Subclass: ACK Timestamp: 00014ms SCall: 21021 DCall: 00038 >> [64.151.32.77:4569] >> Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 001 Type: IAX >> Subclass: ACCEPT >> Timestamp: 00015ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >> FORMAT : 1024 >> >> Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 001 Type: CONTROL >> Subclass: RINGING >> Timestamp: 00003ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: >> ACK Timestamp: 00015ms SCall: 00038 DCall: 21021 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >> ACK Timestamp: 00003ms SCall: 00038 DCall: 21021 >> [64.151.32.77:4569] >> Tx-Frame Retry[010] -- OSeqno: 002 ISeqno: 001 Type: CONTROL >> Subclass: ANSWER >> Timestamp: 02687ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >> ACK Timestamp: 02687ms SCall: 00038 DCall: 21021 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >> TXREQ Timestamp: 02712ms SCall: 00038 DCall: 21021 >> [64.151.32.77:4569] >> APPARENT ADDRES : IPV4 64.151.42.28:4668 >> CALL NUMBER : 21328 >> TRANSFER ID : 1501550657 >> >> libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c >> line >> 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >> Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: >> Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1614: Making new >> session, peer callno 37, our callno 21020 libiax2/src/iax.c line >> 1614: Making new session, peer callno 38, our callno 21021 >> libiax2/src/iax.c line 1871: >> Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >> Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 2 >> >> --------------------------------------------------------------------- >> Here'e the output from the originating phone: >> --------------------------------------------------------------------- >> >> Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX >> Subclass: NEW Timestamp: 00003ms SCall: 21328 DCall: 00000 >> [64.151.32.77:4569] >> VERSION : 2 >> CALLING NUMBER : 8168221807 >> CALLING NAME : Steven Sokol >> FORMAT : 1024 >> CAPABILITY : 1542 >> USERNAME : ssokol03_sokol >> CALLED NUMBER : 115 >> DNID : 115 >> >> Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: >> ACCEPT >> Timestamp: 00010ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >> FORMAT : 1024 >> >> Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX >> Subclass: ACK Timestamp: 00010ms SCall: 21328 DCall: 00014 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: >> ANSWER >> Timestamp: 00013ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >> Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 002 Type: IAX >> Subclass: ACK Timestamp: 00013ms SCall: 21328 DCall: 00014 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass: >> RINGING >> Timestamp: 00016ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >> Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 003 Type: IAX >> Subclass: ACK Timestamp: 00016ms SCall: 21328 DCall: 00014 >> [64.151.32.77:4569] >> Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 003 Type: VOICE >> Subclass: 138 >> Timestamp: 00120ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: IAX Subclass: >> ACK Timestamp: 00120ms SCall: 00014 DCall: 21328 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: CONTROL Subclass: >> (255?) >> Timestamp: 02711ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass: >> TXREQ Timestamp: 02714ms SCall: 00014 DCall: 21328 >> [64.151.32.77:4569] >> APPARENT ADDRES : IPV4 64.151.42.28:4667 >> CALL NUMBER : 21021 >> TRANSFER ID : 1501550657 >> >> libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c >> line >> 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >> Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >> Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 ERROR encoding (no samples output >> (samples=160) libiax2/src/iax.c line 1871: Cancelling transmission of >> packet 1 libiax2/src/iax.c line 2153: Don't know what to do with AST >> control >> -2147483648 >> >> --------------------------------------------------------------------- >> >> Following this exchange BOTH clients immediately die and the debugger >> is WAY off base as to where the error occurs. It always shows the >> last function in my integration DLL -- a function that is not being >> called when the crash occurs. >> >> Anybody have any thoughts? >> >> Thanks, >> >> Steve >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: IT Product Guide on >> ITManagersJournal Use IT products in your business? Tell us what you think of them. >> Give us >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >> out more http://productguide.itmanagersjournal.com/guidepromo.tmpl >> _______________________________________________ >> Iaxclient-devel mailing list >> Iax...@li... >> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel >> >> ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Iaxclient-devel mailing list Iax...@li... https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
|
From: Steve K. <st...@st...> - 2004-10-25 23:46:45
|
Sounds like it might be a bug in the code that Bill Doll sent me, and I integrated last week; Bill? P.S. If you're actually working on the library, I suggest that you join the iaxclient-cvs mailing list, so you'll see all diffs as they are committed to CVS. -SteveK Steven Sokol wrote: > Michael, > > Please do. I will give it a try and let you know how it works out. > > Thanks, > > Steve > > Michael Workman wrote: > >> Yes I have experienced that on my IAX Library... I have a patch for >> Asterisk >> and iax.c >> If you want let me know Steve I will give you it >> >> >> >> >> >> -----Original Message----- >> From: iax...@li... >> [mailto:iax...@li...] On Behalf Of Steven >> Sokol >> Sent: Monday, October 25, 2004 5:28 PM >> To: Iax...@li... >> Subject: [Iaxclient-devel] Strange fatal issue with attempted native >> transfer behind same NAT... >> >> Ok, this one is really quite strange. I have to do some more >> testing, but I >> seem to have real problems in IAX Phone running under the new library >> whenever I try to make an IAX Phone -to- IAX Phone call with both phones >> behind the same NAT. Both phones (on different PCs) crash right after >> Asterisk attempts to get them to talk to each other (sends TXREQ). >> >> I can't definitively say that it is related to the NAT however. >> Could be >> ANY native transfer. I need to adjust my configuration an try again. >> Here's the debugging output from the IAX Phone /receiveing/ the >> call: >> >> Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX >> Subclass: ACK Timestamp: 00102ms SCall: 21019 DCall: 00006 >> [63.146.169.121:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >> ACK Timestamp: 00062ms SCall: 00006 DCall: 21019 >> [63.146.169.121:4569] >> Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >> HANGUP >> Timestamp: 00014ms SCall: 00037 DCall: 00000 [64.151.32.77:4569] >> Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX >> Subclass: ACK Timestamp: 00014ms SCall: 21020 DCall: 00037 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >> NEW Timestamp: 00014ms SCall: 00038 DCall: 00000 >> [64.151.32.77:4569] >> VERSION : 2 >> CALLED NUMBER : s >> CALLING NUMBER : 8168221807 >> CALLING NAME : Steven Sokol >> LANGUAGE : en >> FORMAT : 1024 >> CAPABILITY : 1542 >> ADSICPE : 0 >> DATE TIME : 156861043 >> >> Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX >> Subclass: ACK Timestamp: 00014ms SCall: 21021 DCall: 00038 >> [64.151.32.77:4569] >> Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 001 Type: IAX >> Subclass: ACCEPT >> Timestamp: 00015ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >> FORMAT : 1024 >> >> Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 001 Type: CONTROL >> Subclass: RINGING >> Timestamp: 00003ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: >> ACK Timestamp: 00015ms SCall: 00038 DCall: 21021 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >> ACK Timestamp: 00003ms SCall: 00038 DCall: 21021 >> [64.151.32.77:4569] >> Tx-Frame Retry[010] -- OSeqno: 002 ISeqno: 001 Type: CONTROL >> Subclass: ANSWER >> Timestamp: 02687ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >> ACK Timestamp: 02687ms SCall: 00038 DCall: 21021 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >> TXREQ Timestamp: 02712ms SCall: 00038 DCall: 21021 >> [64.151.32.77:4569] >> APPARENT ADDRES : IPV4 64.151.42.28:4668 >> CALL NUMBER : 21328 >> TRANSFER ID : 1501550657 >> >> libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c line >> 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >> Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: >> Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1614: Making new >> session, >> peer callno 37, our callno 21020 libiax2/src/iax.c line 1614: Making new >> session, peer callno 38, our callno 21021 libiax2/src/iax.c line 1871: >> Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >> Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 2 >> >> --------------------------------------------------------------------- >> Here'e the output from the originating phone: >> --------------------------------------------------------------------- >> >> Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX >> Subclass: NEW Timestamp: 00003ms SCall: 21328 DCall: 00000 >> [64.151.32.77:4569] >> VERSION : 2 >> CALLING NUMBER : 8168221807 >> CALLING NAME : Steven Sokol >> FORMAT : 1024 >> CAPABILITY : 1542 >> USERNAME : ssokol03_sokol >> CALLED NUMBER : 115 >> DNID : 115 >> >> Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: >> ACCEPT >> Timestamp: 00010ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >> FORMAT : 1024 >> >> Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX >> Subclass: ACK Timestamp: 00010ms SCall: 21328 DCall: 00014 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: >> ANSWER >> Timestamp: 00013ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >> Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 002 Type: IAX >> Subclass: ACK Timestamp: 00013ms SCall: 21328 DCall: 00014 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass: >> RINGING >> Timestamp: 00016ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >> Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 003 Type: IAX >> Subclass: ACK Timestamp: 00016ms SCall: 21328 DCall: 00014 >> [64.151.32.77:4569] >> Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 003 Type: VOICE >> Subclass: 138 >> Timestamp: 00120ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: IAX Subclass: >> ACK Timestamp: 00120ms SCall: 00014 DCall: 21328 >> [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: CONTROL Subclass: >> (255?) >> Timestamp: 02711ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >> Rx-Frame Retry[No] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass: >> TXREQ Timestamp: 02714ms SCall: 00014 DCall: 21328 >> [64.151.32.77:4569] >> APPARENT ADDRES : IPV4 64.151.42.28:4667 >> CALL NUMBER : 21021 >> TRANSFER ID : 1501550657 >> >> libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c line >> 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >> Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >> Cancelling >> transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >> transmission of packet 0 ERROR encoding (no samples output (samples=160) >> libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 >> libiax2/src/iax.c line 2153: Don't know what to do with AST control >> -2147483648 >> >> --------------------------------------------------------------------- >> >> Following this exchange BOTH clients immediately die and the debugger >> is WAY >> off base as to where the error occurs. It always shows the last >> function in >> my integration DLL -- a function that is not being called when the crash >> occurs. >> >> Anybody have any thoughts? >> >> Thanks, >> >> Steve >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >> Use IT products in your business? Tell us what you think of them. >> Give us >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >> out more >> http://productguide.itmanagersjournal.com/guidepromo.tmpl >> _______________________________________________ >> Iaxclient-devel mailing list >> Iax...@li... >> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel >> >> |
|
From: Steve K. <st...@st...> - 2004-10-25 23:43:47
|
Responses inline: Steven M. Sokol wrote: > Steve & Company, > > First, thank you for the codec code. I will be releasing a new > version of the free version of IAX Phone with the codec-enabled > library included. > > I'm working on a few improvements (or at least additions) to the > library, and I want some response. Some of these are already coded, > while others are still on the drawing board. These include: > > - New registration routine > - Client-Side Call Recording > - Multi-Path Audio Output (and possibly input) > - Onboard Mixing for 3-way Calling > - URL Send/URL Event > - DTMF Received Event > > -= New Registration Routines =- > > I've created an iaxc_register2 function that creates a managed list of > registrations and their states. It required a single change to the > existing registration structure -- the addition of a regid integer to > hold the registration identifier. This value (simply an incrmenting > integer) is generated when the registration is created and is used to > identify the registration during callbacks (events). The function > call returns the newly generated registration ID, or negative values > to indicate errors. > > The registration event (appended to the main event structure) returns > the registration ID, the registration result, and the message count > for the mailbox associated with the user account (if any). A new > event type, IAXC_EVENT_REG is used as the event type. The > registration event is generated by the iaxc_regmsg function which is > called from iaxc_handle_regreply. > > The general purpose of this change was to allow the client to display > registration status on an account-by-account basis, and to track > message counts for each account. This is a very minor tweak (and I > suppose we could have returned the registration information in the > user message, but this seems to be a more elegant approach). I think that the consensus seems to be that this functionality can probably replace the existing functionality. I just threw that together, and I don't actually use registration myself :) I'd add a function to cancel a registration as well, once you have an ID and are storing the registrations. > -= Client-Side Call Recording =- > > This set of routines makes use of the libsndfile project code to > integrate call recording into the library. The same function can be > handled by the server using the monitor, but in accordance with Mark's > belief that the greatest amount of processing power is available at > the edge, it can be quite useful. It also fits a need for a client > who /really/ wanted client-side recording and file playback. > > The code to make this happen comes, largely, from the libsndfile > project. The libsndfile functions handle the creation of the file > header (if any) plus the proper formatting of the data for the storage > format. My implementation makes use of it as an external DLL, but it > could readily be compiled into iaxClientLib. It is cross-platform > capable in most respects. The one issue I have not been able to make > fully cross-platform is timing. > > Windows supports "multimedia timers" which are accurate down to 1 ms. > This allows for accurate playback. I don't know much about timers in > Linux (only that the 2.6 kernel is the first to support innate > high-frequency timers) and absolutely nothing about timers in Mac > OSX. Thus it /may/ be best to keep this as a patch outside of the > main code base. My implementation segements it with #ifdef WIN32. > > The recording function captures the output audio stream (as linear > PCM) in the send_encoded_audio function in audio_encode.c. It > captures the input audio stream (also as linear PCM) in the > decode_audio function. At the present time, both streams are written > to separate files which can be optionally mixed using a separate > mixing function. > > Playback of files is handled in a timer callback function in the WIN32 > section of the code. It encodes and sends the audio using the > existing send_encoded_audio function. I may add an option of playing > the audio back over the local audio.output channel as well. > > The recording and playback functions generate a series of events which > are added to the main event structure. These include and event type > of IAXC_EVENT_FILE_IO, an event sub-type (start, stop, etc.), and io > sub-type (recording or playback), and a cause (timeout, end-of-file, > digit, or stop command). > > This function currently exists in the version of the library that > handled only GSM. I am working on porting it into the new multi-codec > version. I think this can be done in a portable way. We already have the playback functionality necessary for sounds. I'm not sure why you need millisecond-accuracy timers for this, though, but gettimeofday will be millisecond-precise on linux-2.6 (10ms on linux-2.4) and on Mac OS X. The present gettimeofday emulation on Windows is currently 10ms-precise on NT-based machines, and 55ms-precise on 9x-based machines. > -= Multi-Path Audio Output (and Input) =- > > This feature is still on the drawing board. It services two > functions. First, it allows for phones with multiple audio devices to > direct the audio from one call to a given device and audio from > another to a separate device. The classic example of this is placing > and "on hold" call on one device (the speakers) while communicating on > another call using a headset. The second function is a bit more > esoteric and relates to a specific customer request. > > My thought here would be to have a pool of audio objects which can be > dynamically assigned to the pool of calls. Instead of having the > "selected" call be the sole consumer/source of audio, the call would > check to see if an audio object was assigned. If so, it would make > use of that object. If not, the audio would be discarded. This still > allows for the use of the "selected" call as the primary (if the > application needs a "primary") but also allows for other calls to > route audio. > > We currently create a single audio object for the client, then assign > various devices (in, out, ring) to that audio object. All calls make > use of that single audio object, but only when the call is the > "selected" call. In order for the multi-destination system to work, > it would seem logical to create separate audio objects and assign them > each an input, output and ring device. Then, each call could be > assigned a different audio object. The function would take as > parameters the call ID and the object ID and would handle properly > passing the references, returning an error if the audio object is > already in use or does not exist. > > I suspect that this will require quite a bit of reworking of the > current audio driver structure. Can the structure be expanded to > support multiple audio i/o devices? Can we simply instantiate and > initialize several driver objects as it stants? Do we run into any > kind of issue in terms of threading if we try to read and/or write on > multiple devices simultaneously? The audio_portaudio driver (which is the only one, aside from audio_file which works at all) presently uses some statics for state; thse would need to be moved into a private structure. I'm not sure how portaudio itself would react to having several instantations in the same process, but I think it handles this. There's a mutex in audio_portaudio that is static, it would need to be moved into the structure to make it thread safe (or, it could be kept static, and shared for by each instantation, as long as it was protected from being re-initialized, etc). You could search the portaudio list, or look at portaudio to see about it's multiple-instantiation-safety. Another way to do this would be to have more than one iaxclient instantiation, and to tranfer calls between them, etc. It is probably not safe to do this in a single process though, so you'd need to use a co-process model (i.e. like tkphone/iaxcli), to do this. > > It will also require at least a small change to the call structure -- > adding the audio object as a memeber. The audio handler routines > would, obviously, need to be altered to make use of the audio object > associated with the call, rather than the single central audio object. > > -= Onboard Mixing For 3-way Calling =- > > I originally started to work out a routine for passing feature > requests back to the server over IAX primarily to enable a server-side > conferencing function. Mark steared me away from that, as again he > feels the client should handle trivial functions like mixing for 3-way > calling. As such I want to implement client native simple conferencing. > > ----------- > CALL1 SEND--------->| |------>CALL1 RCV > | MIX | > CALL2 SEND--------->| & |------>CALL2 RCV > | ECHO | > AUDIO IN (MIC)----->| CANCEL |------>AUDIO OUT (SPK) > ----------- > > I suppose I could spend a bit of time making myself familliar with the > code in app_meetme, but this may be a problem that other more > familliar with the specifics of mixing and echo cancellation would be > better able to address. If nothing else, pointers would be happily > accepted! Look at app_conference -- it does all of this already. You don't need echo cancellation for this, though, meetme and app_conference don't do this. In this case, you have a 3 party conference. Call the 3 parties A, B, C. If you do this the way meetme does it, you do this: Mix A+B, send audio to C. Mix A+C, send audio to B. Mix B+C, send audio to A. app_conference does this in a slightly more efficient way when parties do VAD, because in this case, most of the parties won't be sending audio, and you generally only have audio from one speaker. So, you could do all this in iaxclient if you wanted to, but it would still be better to do it in asterisk with meetme, or app_conference, and have some intellegent dialplan setup combined with transfers and perhaps custom UI in iaxclient, and let it all be done via asterisk.. > > -= URL Send/URL Event =- > > This is simply the addition of a wrapper to the innate IAX2 URL > function and event. It should look much like the text event. This > will make it easy for the application to either "pop" a browser, or > display a web page in a browser window incorporated into the client. Sounds simple. > > -= DTMF Event =- > > This simply converts the DTMF events that are currently handled as > part of the user message stream and provides a separate event that can > be used by the client to recognize DTMF from the far end of the call. > This function is being added to facilitate some basic client-side > automation that a customer has requested. Also sounds simple. Also, w.r.t. Dan's comments about using Message ID's instead of strings for many of the callbacks, I'd support that too. It would probably be best to just add a message-id, and also have the string in english, or to have a method inside of iaxclient which could give you a (possibly internationalized) string given a message-id, that way we have all the strings in the library for everyone to contribute to and use. -SteveK |
|
From: Steven S. <ss...@so...> - 2004-10-25 22:05:07
|
Michael, Please do. I will give it a try and let you know how it works out. Thanks, Steve Michael Workman wrote: >Yes I have experienced that on my IAX Library... I have a patch for Asterisk >and iax.c >If you want let me know Steve I will give you it > > > > > >-----Original Message----- >From: iax...@li... >[mailto:iax...@li...] On Behalf Of Steven >Sokol >Sent: Monday, October 25, 2004 5:28 PM >To: Iax...@li... >Subject: [Iaxclient-devel] Strange fatal issue with attempted native >transfer behind same NAT... > >Ok, this one is really quite strange. I have to do some more testing, but I >seem to have real problems in IAX Phone running under the new library >whenever I try to make an IAX Phone -to- IAX Phone call with both phones >behind the same NAT. Both phones (on different PCs) crash right after >Asterisk attempts to get them to talk to each other (sends TXREQ). > >I can't definitively say that it is related to the NAT however. Could be >ANY native transfer. I need to adjust my configuration an try again. >Here's the debugging output from the IAX Phone /receiveing/ the >call: > >Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX Subclass: >ACK > Timestamp: 00102ms SCall: 21019 DCall: 00006 [63.146.169.121:4569] >Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >ACK > Timestamp: 00062ms SCall: 00006 DCall: 21019 [63.146.169.121:4569] >Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >HANGUP > Timestamp: 00014ms SCall: 00037 DCall: 00000 [64.151.32.77:4569] >Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: >ACK > Timestamp: 00014ms SCall: 21020 DCall: 00037 [64.151.32.77:4569] >Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >NEW > Timestamp: 00014ms SCall: 00038 DCall: 00000 [64.151.32.77:4569] > VERSION : 2 > CALLED NUMBER : s > CALLING NUMBER : 8168221807 > CALLING NAME : Steven Sokol > LANGUAGE : en > FORMAT : 1024 > CAPABILITY : 1542 > ADSICPE : 0 > DATE TIME : 156861043 > >Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: >ACK > Timestamp: 00014ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: >ACCEPT > Timestamp: 00015ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] > FORMAT : 1024 > >Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: >RINGING > Timestamp: 00003ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: >ACK > Timestamp: 00015ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] >Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >ACK > Timestamp: 00003ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] >Tx-Frame Retry[010] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass: >ANSWER > Timestamp: 02687ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] >Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >ACK > Timestamp: 02687ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] >Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >TXREQ > Timestamp: 02712ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] > APPARENT ADDRES : IPV4 64.151.42.28:4668 > CALL NUMBER : 21328 > TRANSFER ID : 1501550657 > >libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c line >1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1614: Making new session, >peer callno 37, our callno 21020 libiax2/src/iax.c line 1614: Making new >session, peer callno 38, our callno 21021 libiax2/src/iax.c line 1871: >Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 2 > >--------------------------------------------------------------------- >Here'e the output from the originating phone: >--------------------------------------------------------------------- > >Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: >NEW > Timestamp: 00003ms SCall: 21328 DCall: 00000 [64.151.32.77:4569] > VERSION : 2 > CALLING NUMBER : 8168221807 > CALLING NAME : Steven Sokol > FORMAT : 1024 > CAPABILITY : 1542 > USERNAME : ssokol03_sokol > CALLED NUMBER : 115 > DNID : 115 > >Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: >ACCEPT > Timestamp: 00010ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] > FORMAT : 1024 > >Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: >ACK > Timestamp: 00010ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] >Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: >ANSWER > Timestamp: 00013ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: >ACK > Timestamp: 00013ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] >Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass: >RINGING > Timestamp: 00016ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: >ACK > Timestamp: 00016ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] >Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 003 Type: VOICE Subclass: 138 > Timestamp: 00120ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] >Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: IAX Subclass: >ACK > Timestamp: 00120ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: CONTROL Subclass: (255?) > Timestamp: 02711ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] >Rx-Frame Retry[No] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass: >TXREQ > Timestamp: 02714ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] > APPARENT ADDRES : IPV4 64.151.42.28:4667 > CALL NUMBER : 21021 > TRANSFER ID : 1501550657 > >libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c line >1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: >Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling >transmission of packet 0 ERROR encoding (no samples output (samples=160) >libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 >libiax2/src/iax.c line 2153: Don't know what to do with AST control >-2147483648 > >--------------------------------------------------------------------- > >Following this exchange BOTH clients immediately die and the debugger is WAY >off base as to where the error occurs. It always shows the last function in >my integration DLL -- a function that is not being called when the crash >occurs. > >Anybody have any thoughts? > >Thanks, > >Steve > > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >Use IT products in your business? Tell us what you think of them. Give us >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >Iaxclient-devel mailing list >Iax...@li... >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > |
|
From: Michael W. <mwo...@im...> - 2004-10-25 21:44:58
|
Yes I have experienced that on my IAX Library... I have a patch for Asterisk and iax.c If you want let me know Steve I will give you it -----Original Message----- From: iax...@li... [mailto:iax...@li...] On Behalf Of Steven Sokol Sent: Monday, October 25, 2004 5:28 PM To: Iax...@li... Subject: [Iaxclient-devel] Strange fatal issue with attempted native transfer behind same NAT... Ok, this one is really quite strange. I have to do some more testing, but I seem to have real problems in IAX Phone running under the new library whenever I try to make an IAX Phone -to- IAX Phone call with both phones behind the same NAT. Both phones (on different PCs) crash right after Asterisk attempts to get them to talk to each other (sends TXREQ). I can't definitively say that it is related to the NAT however. Could be ANY native transfer. I need to adjust my configuration an try again. Here's the debugging output from the IAX Phone /receiveing/ the call: Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX Subclass: ACK Timestamp: 00102ms SCall: 21019 DCall: 00006 [63.146.169.121:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: ACK Timestamp: 00062ms SCall: 00006 DCall: 21019 [63.146.169.121:4569] Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: HANGUP Timestamp: 00014ms SCall: 00037 DCall: 00000 [64.151.32.77:4569] Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: ACK Timestamp: 00014ms SCall: 21020 DCall: 00037 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: NEW Timestamp: 00014ms SCall: 00038 DCall: 00000 [64.151.32.77:4569] VERSION : 2 CALLED NUMBER : s CALLING NUMBER : 8168221807 CALLING NAME : Steven Sokol LANGUAGE : en FORMAT : 1024 CAPABILITY : 1542 ADSICPE : 0 DATE TIME : 156861043 Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: ACK Timestamp: 00014ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: ACCEPT Timestamp: 00015ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] FORMAT : 1024 Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: RINGING Timestamp: 00003ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: ACK Timestamp: 00015ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: ACK Timestamp: 00003ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] Tx-Frame Retry[010] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass: ANSWER Timestamp: 02687ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: ACK Timestamp: 02687ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: TXREQ Timestamp: 02712ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] APPARENT ADDRES : IPV4 64.151.42.28:4668 CALL NUMBER : 21328 TRANSFER ID : 1501550657 libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1614: Making new session, peer callno 37, our callno 21020 libiax2/src/iax.c line 1614: Making new session, peer callno 38, our callno 21021 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 2 --------------------------------------------------------------------- Here'e the output from the originating phone: --------------------------------------------------------------------- Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: NEW Timestamp: 00003ms SCall: 21328 DCall: 00000 [64.151.32.77:4569] VERSION : 2 CALLING NUMBER : 8168221807 CALLING NAME : Steven Sokol FORMAT : 1024 CAPABILITY : 1542 USERNAME : ssokol03_sokol CALLED NUMBER : 115 DNID : 115 Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: ACCEPT Timestamp: 00010ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] FORMAT : 1024 Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: ACK Timestamp: 00010ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: ANSWER Timestamp: 00013ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: ACK Timestamp: 00013ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass: RINGING Timestamp: 00016ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: ACK Timestamp: 00016ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 003 Type: VOICE Subclass: 138 Timestamp: 00120ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: IAX Subclass: ACK Timestamp: 00120ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: CONTROL Subclass: (255?) Timestamp: 02711ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass: TXREQ Timestamp: 02714ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] APPARENT ADDRES : IPV4 64.151.42.28:4667 CALL NUMBER : 21021 TRANSFER ID : 1501550657 libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 ERROR encoding (no samples output (samples=160) libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 2153: Don't know what to do with AST control -2147483648 --------------------------------------------------------------------- Following this exchange BOTH clients immediately die and the debugger is WAY off base as to where the error occurs. It always shows the last function in my integration DLL -- a function that is not being called when the crash occurs. Anybody have any thoughts? Thanks, Steve |
|
From: Steven S. <ss...@so...> - 2004-10-25 21:28:36
|
Ok, this one is really quite strange. I have to do some more testing, but I seem to have real problems in IAX Phone running under the new library whenever I try to make an IAX Phone -to- IAX Phone call with both phones behind the same NAT. Both phones (on different PCs) crash right after Asterisk attempts to get them to talk to each other (sends TXREQ). I can't definitively say that it is related to the NAT however. Could be ANY native transfer. I need to adjust my configuration an try again. Here's the debugging output from the IAX Phone /receiveing/ the call: Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX Subclass: ACK Timestamp: 00102ms SCall: 21019 DCall: 00006 [63.146.169.121:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: ACK Timestamp: 00062ms SCall: 00006 DCall: 21019 [63.146.169.121:4569] Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: HANGUP Timestamp: 00014ms SCall: 00037 DCall: 00000 [64.151.32.77:4569] Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: ACK Timestamp: 00014ms SCall: 21020 DCall: 00037 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: NEW Timestamp: 00014ms SCall: 00038 DCall: 00000 [64.151.32.77:4569] VERSION : 2 CALLED NUMBER : s CALLING NUMBER : 8168221807 CALLING NAME : Steven Sokol LANGUAGE : en FORMAT : 1024 CAPABILITY : 1542 ADSICPE : 0 DATE TIME : 156861043 Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: ACK Timestamp: 00014ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: ACCEPT Timestamp: 00015ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] FORMAT : 1024 Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: RINGING Timestamp: 00003ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: ACK Timestamp: 00015ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: ACK Timestamp: 00003ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] Tx-Frame Retry[010] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass: ANSWER Timestamp: 02687ms SCall: 21021 DCall: 00038 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: ACK Timestamp: 02687ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: TXREQ Timestamp: 02712ms SCall: 00038 DCall: 21021 [64.151.32.77:4569] APPARENT ADDRES : IPV4 64.151.42.28:4668 CALL NUMBER : 21328 TRANSFER ID : 1501550657 libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1614: Making new session, peer callno 37, our callno 21020 libiax2/src/iax.c line 1614: Making new session, peer callno 38, our callno 21021 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 2 --------------------------------------------------------------------- Here'e the output from the originating phone: --------------------------------------------------------------------- Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: NEW Timestamp: 00003ms SCall: 21328 DCall: 00000 [64.151.32.77:4569] VERSION : 2 CALLING NUMBER : 8168221807 CALLING NAME : Steven Sokol FORMAT : 1024 CAPABILITY : 1542 USERNAME : ssokol03_sokol CALLED NUMBER : 115 DNID : 115 Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: ACCEPT Timestamp: 00010ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] FORMAT : 1024 Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: ACK Timestamp: 00010ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: ANSWER Timestamp: 00013ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: ACK Timestamp: 00013ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 001 Type: CONTROL Subclass: RINGING Timestamp: 00016ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 003 Type: IAX Subclass: ACK Timestamp: 00016ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 003 Type: VOICE Subclass: 138 Timestamp: 00120ms SCall: 21328 DCall: 00014 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: IAX Subclass: ACK Timestamp: 00120ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 002 Type: CONTROL Subclass: (255?) Timestamp: 02711ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] Rx-Frame Retry[No] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass: TXREQ Timestamp: 02714ms SCall: 00014 DCall: 21328 [64.151.32.77:4569] APPARENT ADDRES : IPV4 64.151.42.28:4667 CALL NUMBER : 21021 TRANSFER ID : 1501550657 libiax2/src/iax.c line 629: Started on port 4569 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 1871: Cancelling transmission of packet 0 ERROR encoding (no samples output (samples=160) libiax2/src/iax.c line 1871: Cancelling transmission of packet 1 libiax2/src/iax.c line 2153: Don't know what to do with AST control -2147483648 --------------------------------------------------------------------- Following this exchange BOTH clients immediately die and the debugger is WAY off base as to where the error occurs. It always shows the last function in my integration DLL -- a function that is not being called when the crash occurs. Anybody have any thoughts? Thanks, Steve |
|
From: Dan <dt...@fx...> - 2004-10-25 17:30:45
|
Hi, >>Steve & Company, >> >>First, thank you for the codec code. I will be releasing a new version >>of the free version of IAX Phone with the codec-enabled library included. > > Same here. I'm loving iLBC. Same here for DIAX. A pre 0.9.9b is already available for download (without the help file yet) > >>I'm working on a few improvements (or at least additions) to the >>library, and I want some response. Some of these are already coded, >>while others are still on the drawing board. These include: >> >>- New registration routine >>- Client-Side Call Recording >>- Multi-Path Audio Output (and possibly input) >>- Onboard Mixing for 3-way Calling >>- URL Send/URL Event >>- DTMF Received Event >> >>-= New Registration Routines =- >> >>I've created an iaxc_register2 function that creates a managed list of >>registrations and their states. It required a single change to the >>existing registration structure -- the addition of a regid integer to >>hold the registration identifier. This value (simply an incrmenting >>integer) is generated when the registration is created and is used to >>identify the registration during callbacks (events). The function call >>returns the newly generated registration ID, or negative values to >>indicate errors. > > Great idea. I'm all for it. >>The general purpose of this change was to allow the client to display >>registration status on an account-by-account basis, and to track message >>counts for each account. This is a very minor tweak (and I suppose we >>could have returned the registration information in the user message, >>but this seems to be a more elegant approach). > I have modified iaxclient library for DIAX usage in order ti achieve extended registration functionality. It can register with up to 8 servers and get live registration status (good to test the link too) for each server individualy and with the message info (new/old). I'll publish the changes in the source together with the final 0.9.9x. Maybe we cand find a common change to keep the library as standard as possible. >>Please give me thoughts on these features. Let me know if they would be >>useful to you, and also if you see any reason NOT to include them. >>Obviously Steve K will be the final decision maker, but I would like to >>see what others think of these additions. > One otther small change made by me is to send user messages as codes, not as message strings. In this way I can better handle the multilanguage support,. > I see no reason to not include any of these changes. All of them can be usefull for some of us and for some of them a compiler directive can be used to minimize the library dimension if not used. > > I would love to see the new registration scheme implemented. Will be great to have just one, included in the library. The main feature requested by DIAX users is to put a call on hold to place a second call and to have attended transfer capabilities. Best regards, Dan |
|
From: Michael V. D. <mic...@va...> - 2004-10-25 13:39:34
|
Hi Steve (and Steves) On Sun, 24 Oct 2004 14:05:08 -0500, "Steven M. Sokol" <ss...@so...> wrote: >Steve & Company, > >First, thank you for the codec code. I will be releasing a new version=20 >of the free version of IAX Phone with the codec-enabled library = included. Same here. I'm loving iLBC. >I'm working on a few improvements (or at least additions) to the=20 >library, and I want some response. Some of these are already coded,=20 >while others are still on the drawing board. These include: > >- New registration routine >- Client-Side Call Recording >- Multi-Path Audio Output (and possibly input) >- Onboard Mixing for 3-way Calling >- URL Send/URL Event >- DTMF Received Event > >-=3D New Registration Routines =3D- > >I've created an iaxc_register2 function that creates a managed list of=20 >registrations and their states. It required a single change to the=20 >existing registration structure -- the addition of a regid integer to=20 >hold the registration identifier. This value (simply an incrmenting=20 >integer) is generated when the registration is created and is used to=20 >identify the registration during callbacks (events). The function call=20 >returns the newly generated registration ID, or negative values to=20 >indicate errors. Great idea. I'm all for it. > >The registration event (appended to the main event structure) returns=20 >the registration ID, the registration result, and the message count for=20 >the mailbox associated with the user account (if any). A new event=20 >type, IAXC_EVENT_REG is used as the event type. The registration event=20 >is generated by the iaxc_regmsg function which is called from=20 >iaxc_handle_regreply. > >The general purpose of this change was to allow the client to display=20 >registration status on an account-by-account basis, and to track message= =20 >counts for each account. This is a very minor tweak (and I suppose we=20 >could have returned the registration information in the user message,=20 >but this seems to be a more elegant approach). I agree, this sounds more elegant. We'll still need to patch asterisk to= get your message count sent correctly, right? >-=3D Client-Side Call Recording =3D- > >This set of routines makes use of the libsndfile project code to=20 >integrate call recording into the library. The same function can be=20 >handled by the server using the monitor, but in accordance with Mark's=20 >belief that the greatest amount of processing power is available at the=20 >edge, it can be quite useful. It also fits a need for a client who=20 >/really/ wanted client-side recording and file playback. > >The code to make this happen comes, largely, from the libsndfile=20 >project. The libsndfile functions handle the creation of the file=20 >header (if any) plus the proper formatting of the data for the storage=20 >format. My implementation makes use of it as an external DLL, but it=20 >could readily be compiled into iaxClientLib. It is cross-platform=20 >capable in most respects. The one issue I have not been able to make=20 >fully cross-platform is timing. I have no problem with this, but probably wouldn't use it myself if it = isn't portable. >Windows supports "multimedia timers" which are accurate down to 1 ms. =20 >This allows for accurate playback. I don't know much about timers in=20 >Linux (only that the 2.6 kernel is the first to support innate=20 >high-frequency timers) and absolutely nothing about timers in Mac OSX. =20 >Thus it /may/ be best to keep this as a patch outside of the main code=20 >base. My implementation segements it with #ifdef WIN32. > >The recording function captures the output audio stream (as linear PCM)=20 >in the send_encoded_audio function in audio_encode.c. It captures the=20 >input audio stream (also as linear PCM) in the decode_audio function. =20 >At the present time, both streams are written to separate files which=20 >can be optionally mixed using a separate mixing function. > >Playback of files is handled in a timer callback function in the WIN32=20 >section of the code. It encodes and sends the audio using the existing=20 >send_encoded_audio function. I may add an option of playing the audio=20 >back over the local audio.output channel as well. > >The recording and playback functions generate a series of events which=20 >are added to the main event structure. These include and event type of=20 >IAXC_EVENT_FILE_IO, an event sub-type (start, stop, etc.), and io=20 >sub-type (recording or playback), and a cause (timeout, end-of-file,=20 >digit, or stop command). > >This function currently exists in the version of the library that=20 >handled only GSM. I am working on porting it into the new multi-codec=20 >version. > >-=3D Multi-Path Audio Output (and Input) =3D- > >This feature is still on the drawing board. It services two functions. = =20 >First, it allows for phones with multiple audio devices to direct the=20 >audio from one call to a given device and audio from another to a=20 >separate device. The classic example of this is placing and "on hold"=20 >call on one device (the speakers) while communicating on another call=20 >using a headset. The second function is a bit more esoteric and relates= =20 >to a specific customer request. > >My thought here would be to have a pool of audio objects which can be=20 >dynamically assigned to the pool of calls. Instead of having the=20 >"selected" call be the sole consumer/source of audio, the call would=20 >check to see if an audio object was assigned. If so, it would make use=20 >of that object. If not, the audio would be discarded. This still=20 >allows for the use of the "selected" call as the primary (if the=20 >application needs a "primary") but also allows for other calls to route=20 >audio. > >We currently create a single audio object for the client, then assign=20 >various devices (in, out, ring) to that audio object. All calls make=20 >use of that single audio object, but only when the call is the=20 >"selected" call. In order for the multi-destination system to work, it=20 >would seem logical to create separate audio objects and assign them each= =20 >an input, output and ring device. Then, each call could be assigned a=20 >different audio object. The function would take as parameters the call=20 >ID and the object ID and would handle properly passing the references,=20 >returning an error if the audio object is already in use or does not = exist. > >I suspect that this will require quite a bit of reworking of the current= =20 >audio driver structure. Can the structure be expanded to support=20 >multiple audio i/o devices? Can we simply instantiate and initialize=20 >several driver objects as it stants? Do we run into any kind of issue=20 >in terms of threading if we try to read and/or write on multiple devices= =20 >simultaneously? > >It will also require at least a small change to the call structure --=20 >adding the audio object as a memeber. The audio handler routines would,= =20 >obviously, need to be altered to make use of the audio object associated= =20 >with the call, rather than the single central audio object. > >-=3D Onboard Mixing For 3-way Calling =3D- > >I originally started to work out a routine for passing feature requests=20 >back to the server over IAX primarily to enable a server-side=20 >conferencing function. Mark steared me away from that, as again he=20 >feels the client should handle trivial functions like mixing for 3-way=20 >calling. As such I want to implement client native simple conferencing. > > ----------- >CALL1 SEND--------->| |------>CALL1 RCV > | MIX | >CALL2 SEND--------->| & |------>CALL2 RCV > | ECHO | >AUDIO IN (MIC)----->| CANCEL |------>AUDIO OUT (SPK) > ----------- > >I suppose I could spend a bit of time making myself familliar with the=20 >code in app_meetme, but this may be a problem that other more familliar=20 >with the specifics of mixing and echo cancellation would be better able=20 >to address. If nothing else, pointers would be happily accepted! > Would you run into the same timing source problem? That is, asterisk on = i86 linux requires a (1ms??) timing source to clock its stream mixer. They = need a zaptel board or a USB timer hack that is sometimes difficult to = configure. >-=3D URL Send/URL Event =3D- > >This is simply the addition of a wrapper to the innate IAX2 URL function= =20 >and event. It should look much like the text event. This will make it=20 >easy for the application to either "pop" a browser, or display a web=20 >page in a browser window incorporated into the client. Great idea! I already have used an html window to send back billing = info, etc. It is controlled by the iaxclient app. It would be great to have the = asterisk server send the URLs. >-=3D DTMF Event =3D- > >This simply converts the DTMF events that are currently handled as part=20 >of the user message stream and provides a separate event that can be=20 >used by the client to recognize DTMF from the far end of the call. This= =20 >function is being added to facilitate some basic client-side automation=20 >that a customer has requested. I don't think I would use this. >Please give me thoughts on these features. Let me know if they would be= =20 >useful to you, and also if you see any reason NOT to include them. =20 >Obviously Steve K will be the final decision maker, but I would like to=20 >see what others think of these additions. I see no reason to not include any of these changes. I would love to see the new registration scheme implemented. I would like to see the new audio mixer, to allow local music on hold. >Thanks, > >Steve Sokol >Sokol & Associates/AstriCon > > > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >Use IT products in your business? Tell us what you think of them. Give = us >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out = more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >Iaxclient-devel mailing list >Iax...@li... >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
|
From: daniel h. <de...@to...> - 2004-10-25 12:20:01
|
Hi list, I'm trying to call my asterisk box and face audio issue. I always here called party but the other way is not working. So I played with codecs (ulaw,gsm, speex and ilbc), the same. If I call 613 echo test from FWD, record of my voice, is garbage. When iaxComm is in GSM mode, I see in my * logs lots of Dropping voice to exceptionnaly long queue on IAX2/<MyExtension>@<IP of *>:4569/2 and just before asterisk give me "Ooh, voice format changed to 2". Latest CVS under linux. -- Daniel |
|
From: Steven M. S. <ss...@so...> - 2004-10-24 19:05:22
|
Steve & Company,
First, thank you for the codec code. I will be releasing a new version
of the free version of IAX Phone with the codec-enabled library included.
I'm working on a few improvements (or at least additions) to the
library, and I want some response. Some of these are already coded,
while others are still on the drawing board. These include:
- New registration routine
- Client-Side Call Recording
- Multi-Path Audio Output (and possibly input)
- Onboard Mixing for 3-way Calling
- URL Send/URL Event
- DTMF Received Event
-= New Registration Routines =-
I've created an iaxc_register2 function that creates a managed list of
registrations and their states. It required a single change to the
existing registration structure -- the addition of a regid integer to
hold the registration identifier. This value (simply an incrmenting
integer) is generated when the registration is created and is used to
identify the registration during callbacks (events). The function call
returns the newly generated registration ID, or negative values to
indicate errors.
The registration event (appended to the main event structure) returns
the registration ID, the registration result, and the message count for
the mailbox associated with the user account (if any). A new event
type, IAXC_EVENT_REG is used as the event type. The registration event
is generated by the iaxc_regmsg function which is called from
iaxc_handle_regreply.
The general purpose of this change was to allow the client to display
registration status on an account-by-account basis, and to track message
counts for each account. This is a very minor tweak (and I suppose we
could have returned the registration information in the user message,
but this seems to be a more elegant approach).
-= Client-Side Call Recording =-
This set of routines makes use of the libsndfile project code to
integrate call recording into the library. The same function can be
handled by the server using the monitor, but in accordance with Mark's
belief that the greatest amount of processing power is available at the
edge, it can be quite useful. It also fits a need for a client who
/really/ wanted client-side recording and file playback.
The code to make this happen comes, largely, from the libsndfile
project. The libsndfile functions handle the creation of the file
header (if any) plus the proper formatting of the data for the storage
format. My implementation makes use of it as an external DLL, but it
could readily be compiled into iaxClientLib. It is cross-platform
capable in most respects. The one issue I have not been able to make
fully cross-platform is timing.
Windows supports "multimedia timers" which are accurate down to 1 ms.
This allows for accurate playback. I don't know much about timers in
Linux (only that the 2.6 kernel is the first to support innate
high-frequency timers) and absolutely nothing about timers in Mac OSX.
Thus it /may/ be best to keep this as a patch outside of the main code
base. My implementation segements it with #ifdef WIN32.
The recording function captures the output audio stream (as linear PCM)
in the send_encoded_audio function in audio_encode.c. It captures the
input audio stream (also as linear PCM) in the decode_audio function.
At the present time, both streams are written to separate files which
can be optionally mixed using a separate mixing function.
Playback of files is handled in a timer callback function in the WIN32
section of the code. It encodes and sends the audio using the existing
send_encoded_audio function. I may add an option of playing the audio
back over the local audio.output channel as well.
The recording and playback functions generate a series of events which
are added to the main event structure. These include and event type of
IAXC_EVENT_FILE_IO, an event sub-type (start, stop, etc.), and io
sub-type (recording or playback), and a cause (timeout, end-of-file,
digit, or stop command).
This function currently exists in the version of the library that
handled only GSM. I am working on porting it into the new multi-codec
version.
-= Multi-Path Audio Output (and Input) =-
This feature is still on the drawing board. It services two functions.
First, it allows for phones with multiple audio devices to direct the
audio from one call to a given device and audio from another to a
separate device. The classic example of this is placing and "on hold"
call on one device (the speakers) while communicating on another call
using a headset. The second function is a bit more esoteric and relates
to a specific customer request.
My thought here would be to have a pool of audio objects which can be
dynamically assigned to the pool of calls. Instead of having the
"selected" call be the sole consumer/source of audio, the call would
check to see if an audio object was assigned. If so, it would make use
of that object. If not, the audio would be discarded. This still
allows for the use of the "selected" call as the primary (if the
application needs a "primary") but also allows for other calls to route
audio.
We currently create a single audio object for the client, then assign
various devices (in, out, ring) to that audio object. All calls make
use of that single audio object, but only when the call is the
"selected" call. In order for the multi-destination system to work, it
would seem logical to create separate audio objects and assign them each
an input, output and ring device. Then, each call could be assigned a
different audio object. The function would take as parameters the call
ID and the object ID and would handle properly passing the references,
returning an error if the audio object is already in use or does not exist.
I suspect that this will require quite a bit of reworking of the current
audio driver structure. Can the structure be expanded to support
multiple audio i/o devices? Can we simply instantiate and initialize
several driver objects as it stants? Do we run into any kind of issue
in terms of threading if we try to read and/or write on multiple devices
simultaneously?
It will also require at least a small change to the call structure --
adding the audio object as a memeber. The audio handler routines would,
obviously, need to be altered to make use of the audio object associated
with the call, rather than the single central audio object.
-= Onboard Mixing For 3-way Calling =-
I originally started to work out a routine for passing feature requests
back to the server over IAX primarily to enable a server-side
conferencing function. Mark steared me away from that, as again he
feels the client should handle trivial functions like mixing for 3-way
calling. As such I want to implement client native simple conferencing.
-----------
CALL1 SEND--------->| |------>CALL1 RCV
| MIX |
CALL2 SEND--------->| & |------>CALL2 RCV
| ECHO |
AUDIO IN (MIC)----->| CANCEL |------>AUDIO OUT (SPK)
-----------
I suppose I could spend a bit of time making myself familliar with the
code in app_meetme, but this may be a problem that other more familliar
with the specifics of mixing and echo cancellation would be better able
to address. If nothing else, pointers would be happily accepted!
-= URL Send/URL Event =-
This is simply the addition of a wrapper to the innate IAX2 URL function
and event. It should look much like the text event. This will make it
easy for the application to either "pop" a browser, or display a web
page in a browser window incorporated into the client.
-= DTMF Event =-
This simply converts the DTMF events that are currently handled as part
of the user message stream and provides a separate event that can be
used by the client to recognize DTMF from the far end of the call. This
function is being added to facilitate some basic client-side automation
that a customer has requested.
Please give me thoughts on these features. Let me know if they would be
useful to you, and also if you see any reason NOT to include them.
Obviously Steve K will be the final decision maker, but I would like to
see what others think of these additions.
Thanks,
Steve Sokol
Sokol & Associates/AstriCon
|
|
From: Michael V. D. <mi...@va...> - 2004-10-22 23:38:03
|
Linux and Windows compiles of today's CVS are posted on=20 http://iaxclient.sf.net/iaxcomm/index.html |
|
From: Steve K. <st...@st...> - 2004-10-22 15:45:35
|
He's sent me a patch which does the following: 1) Adds Attended Transfer primitives. (anyone interested in seeing this in iaxclient can add this stuff to our layer) 2) Some MSVC portability changes. (zero-length array stuff, I think this fix is clean, and will also work on non-Intel architectures) 3) Some IAX protocol fixes (minor stuff, it seems, but may fix problems, small leaks, etc). Please let the list know how this works for you. -SteveK |
|
From: Babar S. <bab...@ya...> - 2004-10-22 14:58:06
|
> You haven't described exactly what you're doing, so I dunno..
I m testing with two clients (both iaxclientOcx) and I got my answer after adding iaxc_get_codec,
thanks :)
> You could write one. It would be about 3 lines of code -- I'd accept a
> patch for it.
I m affraid more then 3 lines but its working I tested.
int iaxc_get_codec(int callNo)
{
struct iaxc_call *call;
if(callNo < 0)
return audio_format_preferred;
call = &calls[callNo];
if(callNo != selected_call) {
return;
}
return call->format;
}
--- Steve Kann <st...@st...> wrote:
> Babar Shafiq wrote:
>
> >Hi Steve n List,
> >
> >I added the CVS update, now codec negotiation is working nicely.
> >I tried with all combination of codecs (at one side and different on other side) for testing
> with
> >success and no "Bad or incomplete voice packet" :)
> >
> >I tried with SetCodecPriority function to change codec on run time, but I didn't notice any
> >difference in bandwidth usage I didn't tried to put any debug to check whats going on, What
> will
> >be problem ?
> >
> >
>
> You haven't described exactly what you're doing, so I dunno..
>
> Other iax2 endpoints should honor our preferred codec when we make
> calls. When calls come in, we will use the other side's preferred
> codec, if we support it. I've written about that algorighm already, but
> you can see it in the code.
>
> >or there is any iaxc_get_formats to output current codec in coming update ?
> >
> >
> You could write one. It would be about 3 lines of code -- I'd accept a
> patch for it.
>
>
>
> >Also Incomming call's codec is with higher priority ??
> >
> >
>
> Described above, and earlier.
>
> >SetCodecPriority(int codec)
> >{
> > iaxc_set_min_outgoing_framesize(160);
> > if (codec==IAXC_FORMAT_GSM)
>
>iaxc_set_formats(IAXC_FORMAT_GSM,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
> > else if(codec==IAXC_FORMAT_SPEEX)
>
>iaxc_set_formats(IAXC_FORMAT_SPEEX,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
> > else if(codec==IAXC_FORMAT_ILBC)
> > {
> >
>
>iaxc_set_formats(IAXC_FORMAT_ILBC,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
> > iaxc_set_min_outgoing_framesize(240);
> >
> >
> You don't need to set the min framesize here, it will always do the
> right thing anyway.
>
> > }
> > else if(codec==IAXC_FORMAT_ULAW)
> >
>
>iaxc_set_formats(IAXC_FORMAT_ULAW,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
> >
> >}
> >
> >
> >=====
> >God is a great Programmer
> >
> >
> >
> >_______________________________
> >Do you Yahoo!?
> >Declare Yourself - Register online to vote today!
> >http://vote.yahoo.com
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> >Use IT products in your business? Tell us what you think of them. Give us
> >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> >http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >_______________________________________________
> >Iaxclient-devel mailing list
> >Iax...@li...
> >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
> >
> >
> >
>
>
=====
God is a great Programmer
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
|
|
From: Steve K. <st...@st...> - 2004-10-22 14:28:08
|
Dan wrote:
> Hi,
>
>> ----- Original Message ----- From: "Michael Van Donselaar"
>> <mi...@va...>
>>
>>> I've just recompiled iaxComm with the current CVS sources, and MD5
>>
>> authentication seems to be broken.
>>
>> Can anyone verify that they are having problems as well?
>>
>
> It seems to be from the alignment patch.
>
> In iax2-parser.c [447]
>
> changing to:
>
> case IAX_IE_AUTHMETHODS:
> if (len != sizeof(unsigned short)) {
> snprintf(tmp, sizeof(tmp), "Expecting authmethods to be %d bytes
> long but was %d\n", sizeof(unsigned short), len);
> errorf(tmp);
> } else
> ies->authmethods = ntohs(*((unsigned short *)(data+2))); // <
> this replace the modified aligned
> break;
>
Hmm, let's see here:
The line you have shown is:
ies->authmethods = ntohs(*((unsigned short *)(data+2))); // < this
replace the modified
The line in the source now is:
ies->authmethods =
ntohs(GET_ALIGN_16(data+2));
The macro is:
# define GET_ALIGN_16(srcp) *((unsigned short *)srcp)
Which evaluates to:
ies->authmethods = ntohs(*((unsigned short *)data+2));
So, the problem is the macro needs parentheses:
# define GET_ALIGN_16(srcp) *((unsigned short *)(srcp))
Because it's presently dereferencing data, then adding 2, when it should
be adding 2 to the pointer, than dereferencing.
Fixed in CVS.
-SteveK
> Best regards,
> Dan
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>
|
|
From: Steve K. <st...@st...> - 2004-10-22 14:23:01
|
Babar Shafiq wrote:
>Hi Steve n List,
>
>I added the CVS update, now codec negotiation is working nicely.
>I tried with all combination of codecs (at one side and different on other side) for testing with
>success and no "Bad or incomplete voice packet" :)
>
>I tried with SetCodecPriority function to change codec on run time, but I didn't notice any
>difference in bandwidth usage I didn't tried to put any debug to check whats going on, What will
>be problem ?
>
>
You haven't described exactly what you're doing, so I dunno..
Other iax2 endpoints should honor our preferred codec when we make
calls. When calls come in, we will use the other side's preferred
codec, if we support it. I've written about that algorighm already, but
you can see it in the code.
>or there is any iaxc_get_formats to output current codec in coming update ?
>
>
You could write one. It would be about 3 lines of code -- I'd accept a
patch for it.
>Also Incomming call's codec is with higher priority ??
>
>
Described above, and earlier.
>SetCodecPriority(int codec)
>{
> iaxc_set_min_outgoing_framesize(160);
> if (codec==IAXC_FORMAT_GSM)
>iaxc_set_formats(IAXC_FORMAT_GSM,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
> else if(codec==IAXC_FORMAT_SPEEX)
>iaxc_set_formats(IAXC_FORMAT_SPEEX,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
> else if(codec==IAXC_FORMAT_ILBC)
> {
>
>iaxc_set_formats(IAXC_FORMAT_ILBC,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
> iaxc_set_min_outgoing_framesize(240);
>
>
You don't need to set the min framesize here, it will always do the
right thing anyway.
> }
> else if(codec==IAXC_FORMAT_ULAW)
>
>iaxc_set_formats(IAXC_FORMAT_ULAW,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
>
>}
>
>
>=====
>God is a great Programmer
>
>
>
>_______________________________
>Do you Yahoo!?
>Declare Yourself - Register online to vote today!
>http://vote.yahoo.com
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Iaxclient-devel mailing list
>Iax...@li...
>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>
>
>
|
|
From: Babar S. <bab...@ya...> - 2004-10-22 12:19:58
|
Hi Steve n List,
I added the CVS update, now codec negotiation is working nicely.
I tried with all combination of codecs (at one side and different on other side) for testing with
success and no "Bad or incomplete voice packet" :)
I tried with SetCodecPriority function to change codec on run time, but I didn't notice any
difference in bandwidth usage I didn't tried to put any debug to check whats going on, What will
be problem ?
or there is any iaxc_get_formats to output current codec in coming update ?
Also Incomming call's codec is with higher priority ??
SetCodecPriority(int codec)
{
iaxc_set_min_outgoing_framesize(160);
if (codec==IAXC_FORMAT_GSM)
iaxc_set_formats(IAXC_FORMAT_GSM,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
else if(codec==IAXC_FORMAT_SPEEX)
iaxc_set_formats(IAXC_FORMAT_SPEEX,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
else if(codec==IAXC_FORMAT_ILBC)
{
iaxc_set_formats(IAXC_FORMAT_ILBC,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
iaxc_set_min_outgoing_framesize(240);
}
else if(codec==IAXC_FORMAT_ULAW)
iaxc_set_formats(IAXC_FORMAT_ULAW,IAXC_FORMAT_ULAW|IAXC_FORMAT_GSM|IAXC_FORMAT_SPEEX|IAXC_FORMAT_ILBC);
}
=====
God is a great Programmer
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
|
|
From: Dan <dt...@fx...> - 2004-10-22 11:13:25
|
Hi,
>----- Original Message -----
>From: "Michael Van Donselaar" <mi...@va...>
>> I've just recompiled iaxComm with the current CVS sources, and MD5
> authentication seems to be broken.
>
> Can anyone verify that they are having problems as well?
>
It seems to be from the alignment patch.
In iax2-parser.c [447]
changing to:
case IAX_IE_AUTHMETHODS:
if (len != sizeof(unsigned short)) {
snprintf(tmp, sizeof(tmp), "Expecting authmethods to be %d bytes long
but was %d\n", sizeof(unsigned short), len);
errorf(tmp);
} else
ies->authmethods = ntohs(*((unsigned short *)(data+2))); // < this
replace the modified aligned
break;
Best regards,
Dan
|
|
From: Dan <dt...@fx...> - 2004-10-22 10:53:28
|
Hi, >----- Original Message ----- >From: "Michael Van Donselaar" <mi...@va...> > > I've just recompiled iaxComm with the current CVS sources, and MD5 > authentication seems to be broken. > > Can anyone verify that they are having problems as well? > Same problem for me here. It seems that the auth method is changed somewhere from 3 to 2... Best regards, Dan |
|
From: Michael V. D. <mi...@va...> - 2004-10-22 02:32:10
|
I've just recompiled iaxComm with the current CVS sources, and MD5 authentication seems to be broken. Can anyone verify that they are having problems as well? |
|
From: Steve K. <st...@st...> - 2004-10-21 22:13:17
|
Oops! That's my fault. Forgot to cvs add align.c and align.h Committed... NOW. -SteveK Geoff Nordli wrote: >iax...@li... wrote: > > >>I just downloaded the current CVS sources, and the library >>compile fails: >> >>gcc -Igsm/inc -Iportaudio/pa_common -Iportaudio/pablio >>-Iportmixer/px_common >>-Ilibspeex/include -g -Wall -Wpointer-arith >>-DSPEEX_PREPROCESS=1 -Ilibiax2/src >>-DIAXC_IAX2 -DLIBIAX >>-DSPEEX_EC=1 -DWIN32 -c -o libiax2/src/iax2-parser.o >>libiax2/src/iax2-parser.c libiax2/src/iax2-parser.c:31:19: align.h: >>No such file or directory libiax2/src/iax2-parser.c: In function >>`dump_int': libiax2/src/iax2-parser.c:73: warning: implicit >>declaration >>of function >>`GET_ALIGN_32' >>libiax2/src/iax2-parser.c: In function `dump_short': >>libiax2/src/iax2-parser.c:81: warning: implicit declaration >>of function >>`GET_ALIGN_16' >>make: *** [libiax2/src/iax2-parser.o] Error 1 >> >>missing align.h? >> >>BTW, I am seeing a lot more warnings than I used to. Using >>Mingw 2.0.0 and >>cygwin version 2.340.2.5 and wxWindows 2.4.1 >> >> >> >> >> >Can you try to do the compling with all current versions: > >MinGW-3.1.0-1 >wxWindows 2.4.2 > >Cygwin 2.340.2.5???? > >I only have 1005.11.0.0 > >Geoff > > > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >Use IT products in your business? Tell us what you think of them. Give us >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >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.
