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: Steven S. <ss...@so...> - 2004-02-13 01:06:12
|
Please forgive the cross-post. I wanted this to get in front of all of those who might have ideas. I have been working for the past two weeks on a bug in either chan_iax2 or libiax2. The issue manifests itself as such: 1. A call is established between two clients using libiax2 (using the IAX2 protocol). 2. Both clients are located behind a NAT screen (the same NAT screen). Asterisk is located on a public (routable) address outside of the NAT. 3. Initial setup succeeds. All signaling messages (reliably sent packets requiring ACK). Voice frames (mini frames) also flow properly and the call connects as expected. 4. After approximately 60-65 seconds of conversation, the voice drops out on both legs of the call. Both clients continue to send outbound voice packets to the Asterisk, but no valid voice packets (mini frames) arrive. 5. Immediately prior to the drop of the voice connectivity, se see a retransmission notice on Asterisk's IAX2 debugging output. Why Asterisk (or either client) would attempt to re-send a voice frame is unknown. 6. The audio does not return. The call eventually is dropped (after 60-120 seconds). This only occurs when the call traverses a NAT. It seems to happen on both Linux and Win32 clients. Michael Van Donselaar and I have been tracking this for several weeks. We have run up against the wall with this. Could we ask for a bit of assistance from one of the project leaders. We will be happy to provide you with any information and copies of our client code. Any assistance would be greatly appreciated. Thanks in advance, Steve Sokol Sokol & Associates, LLC www.sokol-associates.com IaxTel: (700) 613-9004 Phone: (816) 822-1807 |
From: Michael V. D. <mv...@va...> - 2004-02-12 01:30:08
|
The more I look at it the more sure I am that the 65 sec disconnect = problem is due to a failed attempt to bridge the connection between the two clients. I can call between two Win32 iaxcomms just fine. It doesn't drop off at = 65 seconds, but then there are TXREQ, TXCNT and TXREJ frames being sent = either. ----8<---- CUT HERE ----8<---- Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX Subclass: = ACK Timestamp: 00031ms SCall: 07463 DCall: 00011 [192.168.0.254:4569] Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: NEW Timestamp: 00001ms SCall: 06320 DCall: 00000 [192.168.0.253:4569] VERSION : 2 CALLING NUMBER : 310 CALLING NAME : Vanserv FORMAT : 2 CAPABILITY : 2 CALLED NUMBER : s DNID : s Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: = ACK Timestamp: 00001ms SCall: 07464 DCall: 06320 [192.168.0.253:4569] Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: = ACCEPT Timestamp: 00010ms SCall: 07464 DCall: 06320 [192.168.0.253:4569] Tx-Frame Retry[010] -- OSeqno: 001 ISeqno: 001 Type: CONTROL Subclass: = RINGING Timestamp: 00011ms SCall: 07464 DCall: 06320 [192.168.0.253:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: ACK Timestamp: 00010ms SCall: 06320 DCall: 07464 [192.168.0.253:4569] Rx-Frame Retry[No] -- OSeqno: 001 ISeqno: 002 Type: VOICE Subclass: 2 Timestamp: 00060ms SCall: 06320 DCall: 07464 [192.168.0.253:4569] Rx-Frame Retry[Yes] -- OSeqno: 001 ISeqno: 002 Type: VOICE Subclass: 2 Timestamp: 00060ms SCall: 06320 DCall: 07464 [192.168.0.253:4569] Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX Subclass: = ACK Timestamp: 00060ms SCall: 07464 DCall: 06320 [192.168.0.253:4569] Tx-Frame Retry[010] -- OSeqno: 002 ISeqno: 002 Type: CONTROL Subclass: = ANSWER Timestamp: 04827ms SCall: 07464 DCall: 06320 [192.168.0.253:4569] Tx-Frame Retry[010] -- OSeqno: 003 ISeqno: 002 Type: VOICE Subclass: 2 Timestamp: 04837ms SCall: 07464 DCall: 06320 [192.168.0.253:4569] Tx-Frame Retry[009] -- OSeqno: 002 ISeqno: 002 Type: CONTROL Subclass: = ANSWER Timestamp: 04827ms SCall: 07464 DCall: 06320 [192.168.0.253:4569] Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 004 Type: IAX Subclass: ACK Timestamp: 04827ms SCall: 06320 DCall: 07464 [192.168.0.253:4569] Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = REGREQ Timestamp: 00001ms SCall: 07465 DCall: 00000 [192.168.0.254:4569] USERNAME : 309 REFRESH : 60 Rx-Frame Retry[No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: = REGAUTH Timestamp: 00001ms SCall: 00003 DCall: 07465 [192.168.0.254:4569] AUTHMETHODS : 3 CHALLENGE : 204174473 USERNAME : 309 ----8<---- Snip several successful REGAUTH/REGREQ/ACK series----8<---- ----8<---- Resume at point of manual hangup ----8<---- Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 002 Type: IAX Subclass: = ACK Timestamp: 00006ms SCall: 07466 DCall: 00008 [192.168.0.254:4569] Tx-Frame Retry[010] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass: = HANGUP Timestamp: 84292ms SCall: 07464 DCall: 06320 [192.168.0.253:4569] CAUSE : Dumped Call Tx-Frame Retry[009] -- OSeqno: 004 ISeqno: 002 Type: IAX Subclass: = HANGUP Timestamp: 84292ms SCall: 07464 DCall: 06320 [192.168.0.253:4569] CAUSE : Dumped Call ----8<---- CUT HERE ----8<---- Any ideas, gang? |
From: Michael V. D. <mv...@va...> - 2004-02-12 01:08:20
|
On Wed, 11 Feb 2004 14:55:02 -0600, Steven Sokol = <ss...@so...> wrote: >I would really like to know. I have been digging further and further = into >this trying to find out where the error takes place. So far I have = almost >nothing to go on. I can't get my linux client to work with CVS code compiled for IAX2. I think any success anyone had either had a non-IAX leg in the = connection, or the user was using a version compiled for IAX1. It looks like there is a problem with the transfer after the call is = answered. It looks like there's a problem with the TXCNT not making it through. = (Does that IP address mean that it is trying to transfer to 0.0.0.0, or that it= is trying to send the TXCNT messages *to* 0.0.0.0??) stderr from iaxcomm running on 192.168.0.254 calling 192.168.1.253, = registered with * on 192.168.0.254: ----8<---- CUT HERE ----8<---- Tx-Frame Retry[010] -- OSeqno: 002 ISeqno: 002 Type: CONTROL Subclass: = ANSWER=20 Timestamp: 03279ms SCall: 29386 DCall: 00012 [192.168.0.254:4569] Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 003 Type: IAX Subclass: ACK= =20 Timestamp: 03279ms SCall: 00012 DCall: 29386 [192.168.0.254:4569] Rx-Frame Retry[No] -- OSeqno: 002 ISeqno: 003 Type: IAX Subclass: = TXREQ =20 Timestamp: 03299ms SCall: 00012 DCall: 29386 [192.168.0.254:4569] APPARENT ADDRES : IPV4 192.168.1.253:4569 CALL NUMBER : 25751 TRANSFER ID : 1711973375 Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXCNT =20 Timestamp: 03287ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Tx-Frame Retry[010] -- OSeqno: 003 ISeqno: 003 Type: VOICE Subclass: 2 Timestamp: 03288ms SCall: 29386 DCall: 00012 [192.168.0.254:4569] Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 004 Type: IAX Subclass: ACK= =20 Timestamp: 03288ms SCall: 00012 DCall: 29386 [192.168.0.254:4569] Tx-Frame Retry[009] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXCNT =20 Timestamp: 03287ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Scheduling retransmission 9 Tx-Frame Retry[010] -- OSeqno: 004 ISeqno: 003 Type: IAX Subclass: = HANGUP=20 Timestamp: 03449ms SCall: 29386 DCall: 00012 [192.168.0.254:4569] CAUSE : Dumped Call Rx-Frame Retry[No] -- OSeqno: 003 ISeqno: 005 Type: IAX Subclass: ACK= =20 Timestamp: 03449ms SCall: 00012 DCall: 29386 [192.168.0.254:4569] Tx-Frame Retry[008] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXCNT =20 Timestamp: 03287ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Scheduling retransmission 8 Tx-Frame Retry[007] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXCNT =20 Timestamp: 03287ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Scheduling retransmission 7 Tx-Frame Retry[006] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXCNT =20 Timestamp: 03287ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Scheduling retransmission 6 Tx-Frame Retry[005] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXCNT =20 Timestamp: 03287ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Scheduling retransmission 5 Tx-Frame Retry[004] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXCNT =20 Timestamp: 03287ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Scheduling retransmission 4 Tx-Frame Retry[003] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXCNT =20 Timestamp: 03287ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Scheduling retransmission 3 Tx-Frame Retry[002] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXCNT =20 Timestamp: 03287ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Scheduling retransmission 2 Tx-Frame Retry[001] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXCNT =20 Timestamp: 03287ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Scheduling retransmission 1 Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXCNT =20 Timestamp: 03287ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Scheduling retransmission 0 Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXREJ =20 Timestamp: 12800ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 Tx-Frame Retry[009] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: = TXREJ =20 Timestamp: 12800ms SCall: 29386 DCall: 25751 [0.0.0.0:0] TRANSFER ID : 1711973375 ----8<---- CUT HERE ----8<---- |
From: Steven S. <ss...@so...> - 2004-02-11 20:55:59
|
I would really like to know. I have been digging further and further into this trying to find out where the error takes place. So far I have almost nothing to go on. I _think_ that the clients are not actually failing to send/receive the audio streams to/from Asterisk. My rather poor testing seems to indicate that both systems continue to receive packets. They seem to be either bad packets, or the scheduler never schedules them for delivery. I really am working a bit beyond my abilities here. Any help from any of those who have a better grasp for the delivery mechanisms in libiax2 would be greatly appreciated. Steven |
From: Michael V. D. <mv...@va...> - 2004-02-10 03:58:46
|
On Sat, 07 Feb 2004 11:03:12 -0600, Steven Sokol = <ss...@so...> wrote: >> You're getting TXREJ because whatever you're calling is trying to = transfer >> you and I'm guessing you're sending the TXCNT to the wrong place just >> judging by the output. Unfortunately your debug omits IP addresses. >>=20 > >I will try to add the IPs into the debug. Strange - I am not trying to >transfer the call (I control the clients at each end). Thus far the = client >library only supports blind transfer. OK, I've added Steve S' logging code into my local sources, and if I'm = reading it right, iaxclient is misunderstanding the initial transfer request. When an IAX_COMMAND_TXREQ message is sent, the transfer sockaddr_in = struct in the session struct should contain the peer's ip address, right? My setup: asterisk server at 192.168.0.254 iaxcomm at 192.168.0.253 iaxcomm at 192.168.0.128 logfile by 192.168.0.128 when called by 192.168.0.253: --8<-- CUT HERE --8<-- 21:40:09 (12709385) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Peer: 192.168.0.254 Session Call Number: 28010 Peer Call Number: 0 Session In Seq Num: 0 Session Out Seq Num: 0 Sending Seq Num: -1 Transfer: 192.168.0.254 21:40:09 (12709395) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Peer: 192.168.0.254 Session Call Number: 28011 Peer Call Number: 0 Session In Seq Num: 0 Session Out Seq Num: 0 Sending Seq Num: -1 Transfer: 192.168.0.254 21:40:09 (12709425) -> Rx Type: 6, Subtype: IAX_COMMAND_REGAUTH Peer: 192.168.0.254 Session Call Number: 28010 Peer Call Number: 3 Frame Source Call No: 896 Frame Dest Call No: 27245 Session In Seq No: 0 Session Out Seq No: 1 Frame In Seq No: 1 Frame Out Seq No: 0 Transfer: 192.168.0.254 21:40:09 (12709425) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Peer: 192.168.0.254 Session Call Number: 28010 Peer Call Number: 3 Session In Seq Num: 1 Session Out Seq Num: 1 Sending Seq Num: -1 Transfer: 192.168.0.254 21:40:09 (12709425) -> Rx Type: 6, Subtype: IAX_COMMAND_REGAUTH Peer: 192.168.0.254 Session Call Number: 28011 Peer Call Number: 5 Frame Source Call No: 1408 Frame Dest Call No: 27501 Session In Seq No: 0 Session Out Seq No: 1 Frame In Seq No: 1 Frame Out Seq No: 0 Transfer: 192.168.0.254 21:40:09 (12709425) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Peer: 192.168.0.254 Session Call Number: 28011 Peer Call Number: 5 Session In Seq Num: 1 Session Out Seq Num: 1 Sending Seq Num: -1 Transfer: 192.168.0.254 21:40:09 (12709445) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK Peer: 192.168.0.254 Session Call Number: 28010 Peer Call Number: 3 Frame Source Call No: 896 Frame Dest Call No: 27245 Session In Seq No: 1 Session Out Seq No: 2 Frame In Seq No: 2 Frame Out Seq No: 1 Transfer: 192.168.0.254 21:40:09 (12709445) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK Peer: 192.168.0.254 Session Call Number: 28010 Peer Call Number: 3 Session In Seq Num: 2 Session Out Seq Num: 2 Sending Seq Num: 2 Transfer: 192.168.0.254 21:40:09 (12709445) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK Peer: 192.168.0.254 Session Call Number: 28011 Peer Call Number: 5 Frame Source Call No: 1408 Frame Dest Call No: 27501 Session In Seq No: 1 Session Out Seq No: 2 Frame In Seq No: 2 Frame Out Seq No: 1 Transfer: 192.168.0.254 21:40:09 (12709445) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK Peer: 192.168.0.254 Session Call Number: 28011 Peer Call Number: 5 Session In Seq Num: 2 Session Out Seq Num: 2 Sending Seq Num: 2 Transfer: 192.168.0.254 21:40:20 (12719619) -> Rx Type: 6, Subtype: IAX_COMMAND_NEW Peer: 192.168.0.254 Session Call Number: 28012 Peer Call Number: 11 Frame Source Call No: 2944 Frame Dest Call No: 0 Session In Seq No: 0 Session Out Seq No: 0 Frame In Seq No: 0 Frame Out Seq No: 0 Transfer: 192.168.0.254 21:40:20 (12719619) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK Peer: 192.168.0.254 Session Call Number: 28012 Peer Call Number: 11 Session In Seq Num: 1 Session Out Seq Num: 0 Sending Seq Num: 0 Transfer: 192.168.0.254 21:40:20 (12719629) -> Tx Type: 6, Subtype: IAX_COMMAND_ACCEPT Peer: 192.168.0.254 Session Call Number: 28012 Peer Call Number: 11 Session In Seq Num: 1 Session Out Seq Num: 0 Sending Seq Num: -1 Transfer: 192.168.0.254 21:40:20 (12719629) -> Tx Type: 4, Subtype: IAX_COMMAND_PONG Peer: 192.168.0.254 Session Call Number: 28012 Peer Call Number: 11 Session In Seq Num: 1 Session Out Seq Num: 1 Sending Seq Num: -1 Transfer: 192.168.0.254 21:40:20 (12719649) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK Peer: 192.168.0.254 Session Call Number: 28012 Peer Call Number: 11 Frame Source Call No: 2944 Frame Dest Call No: 27757 Session In Seq No: 1 Session Out Seq No: 2 Frame In Seq No: 1 Frame Out Seq No: 1 Transfer: 192.168.0.254 21:40:20 (12719649) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK Peer: 192.168.0.254 Session Call Number: 28012 Peer Call Number: 11 Frame Source Call No: 2944 Frame Dest Call No: 27757 Session In Seq No: 1 Session Out Seq No: 2 Frame In Seq No: 2 Frame Out Seq No: 1 Transfer: 192.168.0.254 21:40:24 (12723715) -> Tx Type: 4, Subtype: IAX_COMMAND_ACK Peer: 192.168.0.254 Session Call Number: 28012 Peer Call Number: 11 Session In Seq Num: 1 Session Out Seq Num: 2 Sending Seq Num: -1 Transfer: 192.168.0.254 21:40:24 (12723715) -> Tx Type: 6, Subtype: IAX_COMMAND_UNQUELCH Peer: 192.168.0.254 Session Call Number: 28012 Peer Call Number: 11 Session In Seq Num: 1 Session Out Seq Num: 3 Sending Seq Num: -1 Transfer: 192.168.0.254 21:40:24 (12723725) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK Peer: 192.168.0.254 Session Call Number: 28012 Peer Call Number: 11 Frame Source Call No: 2944 Frame Dest Call No: 27757 Session In Seq No: 1 Session Out Seq No: 4 Frame In Seq No: 3 Frame Out Seq No: 1 Transfer: 192.168.0.254 21:40:24 (12723725) -> Rx Type: 6, Subtype: IAX_COMMAND_TXREQ Peer: 192.168.0.254 Session Call Number: 28012 Peer Call Number: 11 Frame Source Call No: 2944 Frame Dest Call No: 27757 Session In Seq No: 1 Session Out Seq No: 4 Frame In Seq No: 3 Frame Out Seq No: 1 Transfer: 192.168.0.254 21:40:24 (12723725) -> Tx Type: 6, Subtype: IAX_COMMAND_TXCNT Peer: 192.168.0.254 Session Call Number: 28012 Peer Call Number: 11 Session In Seq Num: 2 Session Out Seq Num: 4 Sending Seq Num: 0 Transfer: 192.168.0.254 --8<-- CUT HERE --8<-- If I'm reading this right, then isn't the TXREQ trying to transfer to 192.168.0.254 rather than 192.168.0.253? |
From: Adam H. <ad...@te...> - 2004-02-08 22:30:55
|
> More Data: > > Watching the trace, the error seems to take place after the timeout for the > transfer attempt. As Adam pointed out, IAX2 always tries to establish a > native bridge. Somehow our clients, being both NATed behind the same NAT > device (i.e. both using the same real outside IP address) are unable to > connect natively (the NAT router is not smart enough to "pinwheel" IAX > packets?) so the connection does not work. I've been meaning to talk to Mark about this. I want to add something to IAX to allow two people behind the same nat to talk to each other (many NAT routers can't do "pinwheel") > > Oddly, the IAX protocol seems to default to switching over to a > native-bridged operation UNLESS it receives tacit failure messages from both > sides. > Neg, it's actually when it receives a confirmation from both sides. So in your situation where both parties can't talk to each other, it should remain communicating through the server. > Can we set a noreinvite flag for IAX (I know, I should look at the > source...) to prevent the system from event trying to reinvite the audio > point-to-point? > > I want to blame the "both clients behind the same NAT screen" factor, but I > have had client-to-client calls loose audio after 1 minute even when users > are calling in from outside. I think you're answered why before, from one of your emails >Question: If the client ultimately sends a transfer reject message back to >Asterisk, why would Asterisk stop relaying the mini-frames (i.e. why would >it assume the native transfer took place)? From the trace I attached >before, it looks like the client sends a TXCNT message, followed by a number >of TXREJ messages. It appears to never receive an ACK from the Asterisk for >the TXREJ message (or is it the other client it is rejecting?) so it sends >it multiple times. Ding Ding Ding, for whatever reason the TXREJ aren't getting ACK'd. IAX will kill any session when a packet times out. > > Thoughts? > > Adam, did you have anything like this spring up in Firefly? Nope, sorry |
From: Steven S. <ss...@so...> - 2004-02-08 21:55:18
|
FYI - I tried setting notransfer=yes and it had no effect. Asterisk still tried to establish a native bridge. Still lost audio after 65 seconds. > -----Original Message----- > From: iax...@li... [mailto:iaxclient-devel- > ad...@li...] On Behalf Of Steven Sokol > Sent: Sunday, February 08, 2004 2:43 PM > To: iax...@li... > Subject: [Iaxclient-devel] Re: Bug info... (really weird bug info) > > More Data: > > Watching the trace, the error seems to take place after the timeout for > the > transfer attempt. As Adam pointed out, IAX2 always tries to establish a > native bridge. Somehow our clients, being both NATed behind the same NAT > device (i.e. both using the same real outside IP address) are unable to > connect natively (the NAT router is not smart enough to "pinwheel" IAX > packets?) so the connection does not work. > > Oddly, the IAX protocol seems to default to switching over to a > native-bridged operation UNLESS it receives tacit failure messages from > both > sides. > > Here's what you see with a IAX2-to-IAX2 call through Iaxtel that does > _not_ > have any problems with the audio: > > -- IAX2[1111]/8 answered IAX2[iaxtel@69.73.19.178:4569]/7 > -- Stopped music on hold on IAX2[iaxtel@69.73.19.178:4569]/7 > -- Attempting native bridge of IAX2[iaxtel@69.73.19.178:4569]/7 and > -- Channel 'IAX2[iaxtel@69.73.19.178:4569]/7' unable to transfer > > Note the last line - the chan_iax2 code at Iaxtel detected that a native > session could not be established, so it rejected the attempt and my > Asterisk > continued to relay the voice data. > > Here's what you see with the IAX client-to-IAX client call: > > -- Accepting unauthenticated call from 64.151.42.28, requested format > = > 2, actual format = 2 > -- Executing Dial("IAX2[guest@1105]/3", "IAX2/1111|20|m") in new stack > -- Called 1111 > -- Started music on hold, class 'default', on IAX2[guest@1105]/3 > -- Call accepted by 64.151.42.28 (format GSM) > -- Format for call is GSM > -- IAX2[1111]/5 is ringing > -- IAX2[1111]/5 answered IAX2[guest@1105]/3 > -- Stopped music on hold on IAX2[guest@1105]/3 > -- Attempting native bridge of IAX2[guest@1105]/3 and IAX2[1111]/5 > -- Registered '1111' (AUTHENTICATED) at 64.151.42.28:4569 > -- Registered '1111' (AUTHENTICATED) at 64.151.42.28:4569 > > You never see either side (properly?) reject the attempted native > transfer, > so Asterisk bows out of the call and the audio stops. > > Can we set a noreinvite flag for IAX (I know, I should look at the > source...) to prevent the system from event trying to reinvite the audio > point-to-point? > > I want to blame the "both clients behind the same NAT screen" factor, but > I > have had client-to-client calls loose audio after 1 minute even when users > are calling in from outside. > > Thoughts? > > Adam, did you have anything like this spring up in Firefly? > > Thanks, > > Steve > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
From: Steven S. <ss...@so...> - 2004-02-08 20:43:31
|
More Data: Watching the trace, the error seems to take place after the timeout for the transfer attempt. As Adam pointed out, IAX2 always tries to establish a native bridge. Somehow our clients, being both NATed behind the same NAT device (i.e. both using the same real outside IP address) are unable to connect natively (the NAT router is not smart enough to "pinwheel" IAX packets?) so the connection does not work. Oddly, the IAX protocol seems to default to switching over to a native-bridged operation UNLESS it receives tacit failure messages from both sides. Here's what you see with a IAX2-to-IAX2 call through Iaxtel that does _not_ have any problems with the audio: -- IAX2[1111]/8 answered IAX2[iaxtel@69.73.19.178:4569]/7 -- Stopped music on hold on IAX2[iaxtel@69.73.19.178:4569]/7 -- Attempting native bridge of IAX2[iaxtel@69.73.19.178:4569]/7 and -- Channel 'IAX2[iaxtel@69.73.19.178:4569]/7' unable to transfer Note the last line - the chan_iax2 code at Iaxtel detected that a native session could not be established, so it rejected the attempt and my Asterisk continued to relay the voice data. Here's what you see with the IAX client-to-IAX client call: -- Accepting unauthenticated call from 64.151.42.28, requested format = 2, actual format = 2 -- Executing Dial("IAX2[guest@1105]/3", "IAX2/1111|20|m") in new stack -- Called 1111 -- Started music on hold, class 'default', on IAX2[guest@1105]/3 -- Call accepted by 64.151.42.28 (format GSM) -- Format for call is GSM -- IAX2[1111]/5 is ringing -- IAX2[1111]/5 answered IAX2[guest@1105]/3 -- Stopped music on hold on IAX2[guest@1105]/3 -- Attempting native bridge of IAX2[guest@1105]/3 and IAX2[1111]/5 -- Registered '1111' (AUTHENTICATED) at 64.151.42.28:4569 -- Registered '1111' (AUTHENTICATED) at 64.151.42.28:4569 You never see either side (properly?) reject the attempted native transfer, so Asterisk bows out of the call and the audio stops. Can we set a noreinvite flag for IAX (I know, I should look at the source...) to prevent the system from event trying to reinvite the audio point-to-point? I want to blame the "both clients behind the same NAT screen" factor, but I have had client-to-client calls loose audio after 1 minute even when users are calling in from outside. Thoughts? Adam, did you have anything like this spring up in Firefly? Thanks, Steve |
From: Steven S. <ss...@so...> - 2004-02-08 16:19:58
|
> Is the GS101 SIP (which would be another data point), or is it MGCP as > well? Yup. It's a SIP hard-phone. It has a set of issues all its own, but it seems to do the basics right, and I have never lost the audio stream on it. > > I got sidetracked today, but should be able to work on it tomorrow > evening. > Great! Looking forward to hearing your results. Steve |
From: Steven S. <ss...@so...> - 2004-02-08 02:22:24
|
> > Is there anything in libiax2 that automagically attempts to natively > > couple/transfer (i.e. send audio directly point-to-point) when both > clients > > are IAX2 and both are using the same codec? > > > yep, it's always automatically attempted a native bridge. Just wondering > why > you'd have problems now given it's worked for ages. > Stranger still, why does it seem to be a problem for the windows version but not (at least according to some users) for the Linux version? From what Adam says, I guess we are experiencing some kind of failure when the native bridge fails to establish. My configuration has the Asterisk box on an un-NATted IP, while both clients are behind the NAT screen. However, I have seen the problem occur when receiving calls from other who are outside of the NAT. (And IAX is pretty NAT friendly anyway). Question: Is this only happening on Windows and if so, what is it about the Windows version that causes the problem. Question: If the client ultimately sends a transfer reject message back to Asterisk, why would Asterisk stop relaying the mini-frames (i.e. why would it assume the native transfer took place)? From the trace I attached before, it looks like the client sends a TXCNT message, followed by a number of TXREJ messages. It appears to never receive an ACK from the Asterisk for the TXREJ message (or is it the other client it is rejecting?) so it sends it multiple times. Question: if the native bridge cannot be established, why _do_ we see the client sending a TXCNT message? Is this simply acknowledging the client's ability to communicate with the server? Is this an acknowledgement of the client's ability to communicate with the remote client? I realize that adding the IPs into the debug trace will help answer this... Anybody have any thoughts? Thanks, Sokol |
From: Adam H. <ad...@te...> - 2004-02-08 00:53:10
|
> > You're getting TXREJ because whatever you're calling is trying to transfer > > you and I'm guessing you're sending the TXCNT to the wrong place just > > judging by the output. Unfortunately your debug omits IP addresses. > > > > I will try to add the IPs into the debug. Strange - I am not trying to > transfer the call (I control the clients at each end). Thus far the client > library only supports blind transfer. > > Is there anything in libiax2 that automagically attempts to natively > couple/transfer (i.e. send audio directly point-to-point) when both clients > are IAX2 and both are using the same codec? > yep, it's always automatically attempted a native bridge. Just wondering why you'd have problems now given it's worked for ages. |
From: Steven S. <ss...@so...> - 2004-02-07 17:03:23
|
> You're getting TXREJ because whatever you're calling is trying to transfer > you and I'm guessing you're sending the TXCNT to the wrong place just > judging by the output. Unfortunately your debug omits IP addresses. > I will try to add the IPs into the debug. Strange - I am not trying to transfer the call (I control the clients at each end). Thus far the client library only supports blind transfer. Is there anything in libiax2 that automagically attempts to natively couple/transfer (i.e. send audio directly point-to-point) when both clients are IAX2 and both are using the same codec? Thanks, Steven |
From: Mark S. <mar...@di...> - 2004-02-07 16:54:02
|
You're getting TXREJ because whatever you're calling is trying to transfer you and I'm guessing you're sending the TXCNT to the wrong place just judging by the output. Unfortunately your debug omits IP addresses. Mark On Sat, 7 Feb 2004, Steven Sokol wrote: > Not to be impatient, but did anybody get this message? > > > -----Original Message----- > > From: iax...@li... [mailto:iaxclient-devel- > > ad...@li...] On Behalf Of Steven Sokol > > Sent: Friday, February 06, 2004 2:07 PM > > To: iax...@li... > > Subject: [Iaxclient-devel] Bug info... (really weird bug info) > > Importance: High > > > > Greetings, > > > > I put my trace code back into the library to see what is being sent and > > received. The result is bizarre. In IAX to (SIP, ZAP) everything looks > > normal. Pings, registrations, all the normal stuff are sent and received. > > > > In IAX-IAX conversations, however, the client seems to become confused and > > send several spurious IAX_COMMAND_TXREJ messages. I am guessing that this > > confuses Asterisk which at some point stops relaying the voice frames. > > > > The timing follows the 1000 ms timeout you see in the iax.c for > > retransmission of reliably transmitted frames. > > > > Another oddity. During the negotiation and answer phase of calls from an > > IAX source, the client seems to receive an IAX_COMMAND_TXREQ, to which we > > reply with IAX_COMMAND_TXCNT. > > > > Does ANYBODY know why we are seeing the transfer stuff being activated? > > Is > > this part of the native (IAX-IAX) protocol? What gives? I had a 40 > > minute > > call today with somebody in the Ukraine using my softphone while I was > > using > > my SIP phone. This _HAS_ to be an IAX specific issue. > > > > Below is an entire log of a client for a single call that lost audio. > > Audio > > dropped at approximately 14:02:35. > > > > 14:01:23 (2109140) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > > Session Call Number: 9184 > > Peer Call Number: 0 > > Session In Seq Num: 0 > > Session Out Seq Num: 0 > > Sending Seq Num: -1 > > > > 14:01:23 (2109156) -> Rx Type: 6, Subtype: > > IAX_COMMAND_REGAUTH > > Session Call Number: 9184 > > Peer Call Number: 4 > > Frame Source Call: 1152 > > Frame Dest Call: 57379 > > Session In Seq Num: 0 > > Session Out Seq Num: 1 > > Frame In Seq Num: 1 > > Frame Out Seq Num: 0 > > > > 14:01:23 (2109156) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > > Session Call Number: 9185 > > Peer Call Number: 0 > > Session In Seq Num: 0 > > Session Out Seq Num: 0 > > Sending Seq Num: -1 > > > > 14:01:23 (2109156) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > > Session Call Number: 9184 > > Peer Call Number: 4 > > Session In Seq Num: 1 > > Session Out Seq Num: 1 > > Sending Seq Num: -1 > > > > 14:01:24 (2109171) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK > > Session Call Number: 9184 > > Peer Call Number: 4 > > Frame Source Call: 1152 > > Frame Dest Call: 57379 > > Session In Seq Num: 1 > > Session Out Seq Num: 2 > > Frame In Seq Num: 2 > > Frame Out Seq Num: 1 > > > > 14:01:24 (2109187) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9184 > > Peer Call Number: 4 > > Session In Seq Num: 2 > > Session Out Seq Num: 2 > > Sending Seq Num: 2 > > > > 14:01:24 (2109218) -> Rx Type: 6, Subtype: > > IAX_COMMAND_REGAUTH > > Session Call Number: 9185 > > Peer Call Number: 337 > > Frame Source Call: 20865 > > Frame Dest Call: 57635 > > Session In Seq Num: 0 > > Session Out Seq Num: 1 > > Frame In Seq Num: 1 > > Frame Out Seq Num: 0 > > > > 14:01:24 (2109234) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > > Session Call Number: 9185 > > Peer Call Number: 337 > > Session In Seq Num: 1 > > Session Out Seq Num: 1 > > Sending Seq Num: -1 > > > > 14:01:24 (2109328) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK > > Session Call Number: 9185 > > Peer Call Number: 337 > > Frame Source Call: 20865 > > Frame Dest Call: 57635 > > Session In Seq Num: 1 > > Session Out Seq Num: 2 > > Frame In Seq Num: 2 > > Frame Out Seq Num: 1 > > > > 14:01:24 (2109328) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9185 > > Peer Call Number: 337 > > Session In Seq Num: 2 > > Session Out Seq Num: 2 > > Sending Seq Num: 2 > > > > 14:01:24 (2109359) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9185 > > Peer Call Number: 337 > > Frame Source Call: 20865 > > Frame Dest Call: 57635 > > Session In Seq Num: 2 > > Session Out Seq Num: 2 > > Frame In Seq Num: 2 > > Frame Out Seq Num: 1 > > > > 14:01:30 (2115453) -> Rx Type: 6, Subtype: IAX_COMMAND_NEW > > Session Call Number: 9186 > > Peer Call Number: 5 > > Frame Source Call: 1408 > > Frame Dest Call: 0 > > Session In Seq Num: 0 > > Session Out Seq Num: 0 > > Frame In Seq Num: 0 > > Frame Out Seq Num: 0 > > > > 14:01:30 (2115453) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 1 > > Session Out Seq Num: 0 > > Sending Seq Num: 0 > > > > 14:01:30 (2115468) -> Tx Type: 6, Subtype: IAX_COMMAND_ACCEPT > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 1 > > Session Out Seq Num: 0 > > Sending Seq Num: -1 > > > > 14:01:30 (2115484) -> Tx Type: 4, Subtype: IAX_COMMAND_PONG > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 1 > > Session Out Seq Num: 1 > > Sending Seq Num: -1 > > > > 14:01:30 (2115484) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9186 > > Peer Call Number: 5 > > Frame Source Call: 1408 > > Frame Dest Call: 57891 > > Session In Seq Num: 1 > > Session Out Seq Num: 2 > > Frame In Seq Num: 1 > > Frame Out Seq Num: 1 > > > > 14:01:30 (2115500) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9186 > > Peer Call Number: 5 > > Frame Source Call: 1408 > > Frame Dest Call: 57891 > > Session In Seq Num: 1 > > Session Out Seq Num: 2 > > Frame In Seq Num: 2 > > Frame Out Seq Num: 1 > > > > 14:01:32 (2117609) -> Tx Type: 4, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 2 > > Session Out Seq Num: 2 > > Sending Seq Num: -1 > > > > 14:01:32 (2117625) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 2 > > Session Out Seq Num: 2 > > Sending Seq Num: 2 > > > > 14:01:32 (2117640) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9186 > > Peer Call Number: 5 > > Frame Source Call: 1408 > > Frame Dest Call: 57891 > > Session In Seq Num: 2 > > Session Out Seq Num: 3 > > Frame In Seq Num: 3 > > Frame Out Seq Num: 2 > > > > 14:01:32 (2117640) -> Rx Type: 6, Subtype: IAX_COMMAND_TXREQ > > Session Call Number: 9186 > > Peer Call Number: 5 > > Frame Source Call: 1408 > > Frame Dest Call: 57891 > > Session In Seq Num: 2 > > Session Out Seq Num: 3 > > Frame In Seq Num: 3 > > Frame Out Seq Num: 2 > > > > 14:01:32 (2117656) -> Tx Type: 6, Subtype: IAX_COMMAND_TXCNT > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 3 > > Session Out Seq Num: 3 > > Sending Seq Num: 0 > > > > 14:01:32 (2117718) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9186 > > Peer Call Number: 5 > > Frame Source Call: 1408 > > Frame Dest Call: 57891 > > Session In Seq Num: 3 > > Session Out Seq Num: 4 > > Frame In Seq Num: 4 > > Frame Out Seq Num: 3 > > > > 14:01:41 (2126953) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 3 > > Session Out Seq Num: 4 > > Sending Seq Num: 0 > > > > 14:01:51 (2136375) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 3 > > Session Out Seq Num: 4 > > Sending Seq Num: 0 > > > > 14:02:00 (2145656) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 3 > > Session Out Seq Num: 4 > > Sending Seq Num: 0 > > > > 14:02:09 (2154953) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 3 > > Session Out Seq Num: 4 > > Sending Seq Num: 0 > > > > 14:02:19 (2164265) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 3 > > Session Out Seq Num: 4 > > Sending Seq Num: 0 > > > > 14:02:24 (2169140) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > > Session Call Number: 9187 > > Peer Call Number: 0 > > Session In Seq Num: 0 > > Session Out Seq Num: 0 > > Sending Seq Num: -1 > > > > 14:02:24 (2169156) -> Rx Type: 6, Subtype: > > IAX_COMMAND_REGAUTH > > Session Call Number: 9187 > > Peer Call Number: 2 > > Frame Source Call: 640 > > Frame Dest Call: 58147 > > Session In Seq Num: 0 > > Session Out Seq Num: 1 > > Frame In Seq Num: 1 > > Frame Out Seq Num: 0 > > > > 14:02:24 (2169171) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > > Session Call Number: 9187 > > Peer Call Number: 2 > > Session In Seq Num: 1 > > Session Out Seq Num: 1 > > Sending Seq Num: -1 > > > > 14:02:24 (2169171) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > > Session Call Number: 9188 > > Peer Call Number: 0 > > Session In Seq Num: 0 > > Session Out Seq Num: 0 > > Sending Seq Num: -1 > > > > 14:02:24 (2169187) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK > > Session Call Number: 9187 > > Peer Call Number: 2 > > Frame Source Call: 640 > > Frame Dest Call: 58147 > > Session In Seq Num: 1 > > Session Out Seq Num: 2 > > Frame In Seq Num: 2 > > Frame Out Seq Num: 1 > > > > 14:02:24 (2169203) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9187 > > Peer Call Number: 2 > > Session In Seq Num: 2 > > Session Out Seq Num: 2 > > Sending Seq Num: 2 > > > > 14:02:24 (2169250) -> Rx Type: 6, Subtype: > > IAX_COMMAND_REGAUTH > > Session Call Number: 9188 > > Peer Call Number: 192 > > Frame Source Call: 49280 > > Frame Dest Call: 58403 > > Session In Seq Num: 0 > > Session Out Seq Num: 1 > > Frame In Seq Num: 1 > > Frame Out Seq Num: 0 > > > > 14:02:24 (2169265) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > > Session Call Number: 9188 > > Peer Call Number: 192 > > Session In Seq Num: 1 > > Session Out Seq Num: 1 > > Sending Seq Num: -1 > > > > 14:02:24 (2169296) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9188 > > Peer Call Number: 192 > > Frame Source Call: 49280 > > Frame Dest Call: 58403 > > Session In Seq Num: 1 > > Session Out Seq Num: 2 > > Frame In Seq Num: 1 > > Frame Out Seq Num: 0 > > > > 14:02:24 (2169328) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK > > Session Call Number: 9188 > > Peer Call Number: 192 > > Frame Source Call: 49280 > > Frame Dest Call: 58403 > > Session In Seq Num: 1 > > Session Out Seq Num: 2 > > Frame In Seq Num: 2 > > Frame Out Seq Num: 1 > > > > 14:02:24 (2169343) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9188 > > Peer Call Number: 192 > > Session In Seq Num: 2 > > Session Out Seq Num: 2 > > Sending Seq Num: 2 > > > > 14:02:28 (2173562) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 3 > > Session Out Seq Num: 4 > > Sending Seq Num: 0 > > > > 14:02:37 (2182859) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 4 > > Session Out Seq Num: 4 > > Sending Seq Num: 0 > > > > 14:02:38 (2183062) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 4 > > Session Out Seq Num: 4 > > Sending Seq Num: 4 > > > > 14:02:46 (2191031) -> Rx Type: 6, Subtype: IAX_COMMAND_PING > > Session Call Number: 9186 > > Peer Call Number: 5 > > Frame Source Call: 1408 > > Frame Dest Call: 57891 > > Session In Seq Num: 4 > > Session Out Seq Num: 4 > > Frame In Seq Num: 4 > > Frame Out Seq Num: 4 > > > > 14:02:46 (2191046) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 5 > > Session Out Seq Num: 4 > > Sending Seq Num: 4 > > > > 14:02:47 (2192156) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 5 > > Session Out Seq Num: 4 > > Sending Seq Num: 0 > > > > 14:02:47 (2192875) -> Tx Type: 6, Subtype: IAX_COMMAND_HANGUP > > Session Call Number: 9186 > > Peer Call Number: 5 > > Session In Seq Num: 5 > > Session Out Seq Num: 4 > > Sending Seq Num: -1 > > > > 14:02:48 (2193031) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > > Session Call Number: 9186 > > Peer Call Number: 5 > > Frame Source Call: 1408 > > Frame Dest Call: 57891 > > Session In Seq Num: 5 > > Session Out Seq Num: 5 > > Frame In Seq Num: 5 > > Frame Out Seq Num: 5 > > > > 14:02:48 (2193046) -> Rx Type: 6, Subtype: IAX_COMMAND_INVAL > > Session Call Number: 9186 > > Peer Call Number: 5 > > Frame Source Call: 1408 > > Frame Dest Call: 57891 > > Session In Seq Num: 5 > > Session Out Seq Num: 5 > > Frame In Seq Num: 0 > > Frame Out Seq Num: 0 > > > > > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Iaxclient-devel mailing list > > Iax...@li... > > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > |
From: Steven S. <ss...@so...> - 2004-02-07 16:09:17
|
Not to be impatient, but did anybody get this message? > -----Original Message----- > From: iax...@li... [mailto:iaxclient-devel- > ad...@li...] On Behalf Of Steven Sokol > Sent: Friday, February 06, 2004 2:07 PM > To: iax...@li... > Subject: [Iaxclient-devel] Bug info... (really weird bug info) > Importance: High > > Greetings, > > I put my trace code back into the library to see what is being sent and > received. The result is bizarre. In IAX to (SIP, ZAP) everything looks > normal. Pings, registrations, all the normal stuff are sent and received. > > In IAX-IAX conversations, however, the client seems to become confused and > send several spurious IAX_COMMAND_TXREJ messages. I am guessing that this > confuses Asterisk which at some point stops relaying the voice frames. > > The timing follows the 1000 ms timeout you see in the iax.c for > retransmission of reliably transmitted frames. > > Another oddity. During the negotiation and answer phase of calls from an > IAX source, the client seems to receive an IAX_COMMAND_TXREQ, to which we > reply with IAX_COMMAND_TXCNT. > > Does ANYBODY know why we are seeing the transfer stuff being activated? > Is > this part of the native (IAX-IAX) protocol? What gives? I had a 40 > minute > call today with somebody in the Ukraine using my softphone while I was > using > my SIP phone. This _HAS_ to be an IAX specific issue. > > Below is an entire log of a client for a single call that lost audio. > Audio > dropped at approximately 14:02:35. > > 14:01:23 (2109140) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > Session Call Number: 9184 > Peer Call Number: 0 > Session In Seq Num: 0 > Session Out Seq Num: 0 > Sending Seq Num: -1 > > 14:01:23 (2109156) -> Rx Type: 6, Subtype: > IAX_COMMAND_REGAUTH > Session Call Number: 9184 > Peer Call Number: 4 > Frame Source Call: 1152 > Frame Dest Call: 57379 > Session In Seq Num: 0 > Session Out Seq Num: 1 > Frame In Seq Num: 1 > Frame Out Seq Num: 0 > > 14:01:23 (2109156) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > Session Call Number: 9185 > Peer Call Number: 0 > Session In Seq Num: 0 > Session Out Seq Num: 0 > Sending Seq Num: -1 > > 14:01:23 (2109156) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > Session Call Number: 9184 > Peer Call Number: 4 > Session In Seq Num: 1 > Session Out Seq Num: 1 > Sending Seq Num: -1 > > 14:01:24 (2109171) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK > Session Call Number: 9184 > Peer Call Number: 4 > Frame Source Call: 1152 > Frame Dest Call: 57379 > Session In Seq Num: 1 > Session Out Seq Num: 2 > Frame In Seq Num: 2 > Frame Out Seq Num: 1 > > 14:01:24 (2109187) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9184 > Peer Call Number: 4 > Session In Seq Num: 2 > Session Out Seq Num: 2 > Sending Seq Num: 2 > > 14:01:24 (2109218) -> Rx Type: 6, Subtype: > IAX_COMMAND_REGAUTH > Session Call Number: 9185 > Peer Call Number: 337 > Frame Source Call: 20865 > Frame Dest Call: 57635 > Session In Seq Num: 0 > Session Out Seq Num: 1 > Frame In Seq Num: 1 > Frame Out Seq Num: 0 > > 14:01:24 (2109234) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > Session Call Number: 9185 > Peer Call Number: 337 > Session In Seq Num: 1 > Session Out Seq Num: 1 > Sending Seq Num: -1 > > 14:01:24 (2109328) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK > Session Call Number: 9185 > Peer Call Number: 337 > Frame Source Call: 20865 > Frame Dest Call: 57635 > Session In Seq Num: 1 > Session Out Seq Num: 2 > Frame In Seq Num: 2 > Frame Out Seq Num: 1 > > 14:01:24 (2109328) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9185 > Peer Call Number: 337 > Session In Seq Num: 2 > Session Out Seq Num: 2 > Sending Seq Num: 2 > > 14:01:24 (2109359) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9185 > Peer Call Number: 337 > Frame Source Call: 20865 > Frame Dest Call: 57635 > Session In Seq Num: 2 > Session Out Seq Num: 2 > Frame In Seq Num: 2 > Frame Out Seq Num: 1 > > 14:01:30 (2115453) -> Rx Type: 6, Subtype: IAX_COMMAND_NEW > Session Call Number: 9186 > Peer Call Number: 5 > Frame Source Call: 1408 > Frame Dest Call: 0 > Session In Seq Num: 0 > Session Out Seq Num: 0 > Frame In Seq Num: 0 > Frame Out Seq Num: 0 > > 14:01:30 (2115453) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 1 > Session Out Seq Num: 0 > Sending Seq Num: 0 > > 14:01:30 (2115468) -> Tx Type: 6, Subtype: IAX_COMMAND_ACCEPT > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 1 > Session Out Seq Num: 0 > Sending Seq Num: -1 > > 14:01:30 (2115484) -> Tx Type: 4, Subtype: IAX_COMMAND_PONG > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 1 > Session Out Seq Num: 1 > Sending Seq Num: -1 > > 14:01:30 (2115484) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9186 > Peer Call Number: 5 > Frame Source Call: 1408 > Frame Dest Call: 57891 > Session In Seq Num: 1 > Session Out Seq Num: 2 > Frame In Seq Num: 1 > Frame Out Seq Num: 1 > > 14:01:30 (2115500) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9186 > Peer Call Number: 5 > Frame Source Call: 1408 > Frame Dest Call: 57891 > Session In Seq Num: 1 > Session Out Seq Num: 2 > Frame In Seq Num: 2 > Frame Out Seq Num: 1 > > 14:01:32 (2117609) -> Tx Type: 4, Subtype: IAX_COMMAND_ACK > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 2 > Session Out Seq Num: 2 > Sending Seq Num: -1 > > 14:01:32 (2117625) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 2 > Session Out Seq Num: 2 > Sending Seq Num: 2 > > 14:01:32 (2117640) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9186 > Peer Call Number: 5 > Frame Source Call: 1408 > Frame Dest Call: 57891 > Session In Seq Num: 2 > Session Out Seq Num: 3 > Frame In Seq Num: 3 > Frame Out Seq Num: 2 > > 14:01:32 (2117640) -> Rx Type: 6, Subtype: IAX_COMMAND_TXREQ > Session Call Number: 9186 > Peer Call Number: 5 > Frame Source Call: 1408 > Frame Dest Call: 57891 > Session In Seq Num: 2 > Session Out Seq Num: 3 > Frame In Seq Num: 3 > Frame Out Seq Num: 2 > > 14:01:32 (2117656) -> Tx Type: 6, Subtype: IAX_COMMAND_TXCNT > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 3 > Session Out Seq Num: 3 > Sending Seq Num: 0 > > 14:01:32 (2117718) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9186 > Peer Call Number: 5 > Frame Source Call: 1408 > Frame Dest Call: 57891 > Session In Seq Num: 3 > Session Out Seq Num: 4 > Frame In Seq Num: 4 > Frame Out Seq Num: 3 > > 14:01:41 (2126953) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 3 > Session Out Seq Num: 4 > Sending Seq Num: 0 > > 14:01:51 (2136375) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 3 > Session Out Seq Num: 4 > Sending Seq Num: 0 > > 14:02:00 (2145656) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 3 > Session Out Seq Num: 4 > Sending Seq Num: 0 > > 14:02:09 (2154953) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 3 > Session Out Seq Num: 4 > Sending Seq Num: 0 > > 14:02:19 (2164265) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 3 > Session Out Seq Num: 4 > Sending Seq Num: 0 > > 14:02:24 (2169140) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > Session Call Number: 9187 > Peer Call Number: 0 > Session In Seq Num: 0 > Session Out Seq Num: 0 > Sending Seq Num: -1 > > 14:02:24 (2169156) -> Rx Type: 6, Subtype: > IAX_COMMAND_REGAUTH > Session Call Number: 9187 > Peer Call Number: 2 > Frame Source Call: 640 > Frame Dest Call: 58147 > Session In Seq Num: 0 > Session Out Seq Num: 1 > Frame In Seq Num: 1 > Frame Out Seq Num: 0 > > 14:02:24 (2169171) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > Session Call Number: 9187 > Peer Call Number: 2 > Session In Seq Num: 1 > Session Out Seq Num: 1 > Sending Seq Num: -1 > > 14:02:24 (2169171) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > Session Call Number: 9188 > Peer Call Number: 0 > Session In Seq Num: 0 > Session Out Seq Num: 0 > Sending Seq Num: -1 > > 14:02:24 (2169187) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK > Session Call Number: 9187 > Peer Call Number: 2 > Frame Source Call: 640 > Frame Dest Call: 58147 > Session In Seq Num: 1 > Session Out Seq Num: 2 > Frame In Seq Num: 2 > Frame Out Seq Num: 1 > > 14:02:24 (2169203) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9187 > Peer Call Number: 2 > Session In Seq Num: 2 > Session Out Seq Num: 2 > Sending Seq Num: 2 > > 14:02:24 (2169250) -> Rx Type: 6, Subtype: > IAX_COMMAND_REGAUTH > Session Call Number: 9188 > Peer Call Number: 192 > Frame Source Call: 49280 > Frame Dest Call: 58403 > Session In Seq Num: 0 > Session Out Seq Num: 1 > Frame In Seq Num: 1 > Frame Out Seq Num: 0 > > 14:02:24 (2169265) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ > Session Call Number: 9188 > Peer Call Number: 192 > Session In Seq Num: 1 > Session Out Seq Num: 1 > Sending Seq Num: -1 > > 14:02:24 (2169296) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9188 > Peer Call Number: 192 > Frame Source Call: 49280 > Frame Dest Call: 58403 > Session In Seq Num: 1 > Session Out Seq Num: 2 > Frame In Seq Num: 1 > Frame Out Seq Num: 0 > > 14:02:24 (2169328) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK > Session Call Number: 9188 > Peer Call Number: 192 > Frame Source Call: 49280 > Frame Dest Call: 58403 > Session In Seq Num: 1 > Session Out Seq Num: 2 > Frame In Seq Num: 2 > Frame Out Seq Num: 1 > > 14:02:24 (2169343) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9188 > Peer Call Number: 192 > Session In Seq Num: 2 > Session Out Seq Num: 2 > Sending Seq Num: 2 > > 14:02:28 (2173562) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 3 > Session Out Seq Num: 4 > Sending Seq Num: 0 > > 14:02:37 (2182859) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 4 > Session Out Seq Num: 4 > Sending Seq Num: 0 > > 14:02:38 (2183062) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 4 > Session Out Seq Num: 4 > Sending Seq Num: 4 > > 14:02:46 (2191031) -> Rx Type: 6, Subtype: IAX_COMMAND_PING > Session Call Number: 9186 > Peer Call Number: 5 > Frame Source Call: 1408 > Frame Dest Call: 57891 > Session In Seq Num: 4 > Session Out Seq Num: 4 > Frame In Seq Num: 4 > Frame Out Seq Num: 4 > > 14:02:46 (2191046) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 5 > Session Out Seq Num: 4 > Sending Seq Num: 4 > > 14:02:47 (2192156) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 5 > Session Out Seq Num: 4 > Sending Seq Num: 0 > > 14:02:47 (2192875) -> Tx Type: 6, Subtype: IAX_COMMAND_HANGUP > Session Call Number: 9186 > Peer Call Number: 5 > Session In Seq Num: 5 > Session Out Seq Num: 4 > Sending Seq Num: -1 > > 14:02:48 (2193031) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK > Session Call Number: 9186 > Peer Call Number: 5 > Frame Source Call: 1408 > Frame Dest Call: 57891 > Session In Seq Num: 5 > Session Out Seq Num: 5 > Frame In Seq Num: 5 > Frame Out Seq Num: 5 > > 14:02:48 (2193046) -> Rx Type: 6, Subtype: IAX_COMMAND_INVAL > Session Call Number: 9186 > Peer Call Number: 5 > Frame Source Call: 1408 > Frame Dest Call: 57891 > Session In Seq Num: 5 > Session Out Seq Num: 5 > Frame In Seq Num: 0 > Frame Out Seq Num: 0 > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
From: Steven S. <ss...@so...> - 2004-02-06 20:08:17
|
Greetings, I put my trace code back into the library to see what is being sent and received. The result is bizarre. In IAX to (SIP, ZAP) everything looks normal. Pings, registrations, all the normal stuff are sent and received. In IAX-IAX conversations, however, the client seems to become confused and send several spurious IAX_COMMAND_TXREJ messages. I am guessing that this confuses Asterisk which at some point stops relaying the voice frames. The timing follows the 1000 ms timeout you see in the iax.c for retransmission of reliably transmitted frames. Another oddity. During the negotiation and answer phase of calls from an IAX source, the client seems to receive an IAX_COMMAND_TXREQ, to which we reply with IAX_COMMAND_TXCNT. Does ANYBODY know why we are seeing the transfer stuff being activated? Is this part of the native (IAX-IAX) protocol? What gives? I had a 40 minute call today with somebody in the Ukraine using my softphone while I was using my SIP phone. This _HAS_ to be an IAX specific issue. Below is an entire log of a client for a single call that lost audio. Audio dropped at approximately 14:02:35. 14:01:23 (2109140) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Session Call Number: 9184 Peer Call Number: 0 Session In Seq Num: 0 Session Out Seq Num: 0 Sending Seq Num: -1 14:01:23 (2109156) -> Rx Type: 6, Subtype: IAX_COMMAND_REGAUTH Session Call Number: 9184 Peer Call Number: 4 Frame Source Call: 1152 Frame Dest Call: 57379 Session In Seq Num: 0 Session Out Seq Num: 1 Frame In Seq Num: 1 Frame Out Seq Num: 0 14:01:23 (2109156) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Session Call Number: 9185 Peer Call Number: 0 Session In Seq Num: 0 Session Out Seq Num: 0 Sending Seq Num: -1 14:01:23 (2109156) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Session Call Number: 9184 Peer Call Number: 4 Session In Seq Num: 1 Session Out Seq Num: 1 Sending Seq Num: -1 14:01:24 (2109171) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK Session Call Number: 9184 Peer Call Number: 4 Frame Source Call: 1152 Frame Dest Call: 57379 Session In Seq Num: 1 Session Out Seq Num: 2 Frame In Seq Num: 2 Frame Out Seq Num: 1 14:01:24 (2109187) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9184 Peer Call Number: 4 Session In Seq Num: 2 Session Out Seq Num: 2 Sending Seq Num: 2 14:01:24 (2109218) -> Rx Type: 6, Subtype: IAX_COMMAND_REGAUTH Session Call Number: 9185 Peer Call Number: 337 Frame Source Call: 20865 Frame Dest Call: 57635 Session In Seq Num: 0 Session Out Seq Num: 1 Frame In Seq Num: 1 Frame Out Seq Num: 0 14:01:24 (2109234) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Session Call Number: 9185 Peer Call Number: 337 Session In Seq Num: 1 Session Out Seq Num: 1 Sending Seq Num: -1 14:01:24 (2109328) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK Session Call Number: 9185 Peer Call Number: 337 Frame Source Call: 20865 Frame Dest Call: 57635 Session In Seq Num: 1 Session Out Seq Num: 2 Frame In Seq Num: 2 Frame Out Seq Num: 1 14:01:24 (2109328) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9185 Peer Call Number: 337 Session In Seq Num: 2 Session Out Seq Num: 2 Sending Seq Num: 2 14:01:24 (2109359) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9185 Peer Call Number: 337 Frame Source Call: 20865 Frame Dest Call: 57635 Session In Seq Num: 2 Session Out Seq Num: 2 Frame In Seq Num: 2 Frame Out Seq Num: 1 14:01:30 (2115453) -> Rx Type: 6, Subtype: IAX_COMMAND_NEW Session Call Number: 9186 Peer Call Number: 5 Frame Source Call: 1408 Frame Dest Call: 0 Session In Seq Num: 0 Session Out Seq Num: 0 Frame In Seq Num: 0 Frame Out Seq Num: 0 14:01:30 (2115453) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 1 Session Out Seq Num: 0 Sending Seq Num: 0 14:01:30 (2115468) -> Tx Type: 6, Subtype: IAX_COMMAND_ACCEPT Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 1 Session Out Seq Num: 0 Sending Seq Num: -1 14:01:30 (2115484) -> Tx Type: 4, Subtype: IAX_COMMAND_PONG Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 1 Session Out Seq Num: 1 Sending Seq Num: -1 14:01:30 (2115484) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9186 Peer Call Number: 5 Frame Source Call: 1408 Frame Dest Call: 57891 Session In Seq Num: 1 Session Out Seq Num: 2 Frame In Seq Num: 1 Frame Out Seq Num: 1 14:01:30 (2115500) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9186 Peer Call Number: 5 Frame Source Call: 1408 Frame Dest Call: 57891 Session In Seq Num: 1 Session Out Seq Num: 2 Frame In Seq Num: 2 Frame Out Seq Num: 1 14:01:32 (2117609) -> Tx Type: 4, Subtype: IAX_COMMAND_ACK Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 2 Session Out Seq Num: 2 Sending Seq Num: -1 14:01:32 (2117625) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 2 Session Out Seq Num: 2 Sending Seq Num: 2 14:01:32 (2117640) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9186 Peer Call Number: 5 Frame Source Call: 1408 Frame Dest Call: 57891 Session In Seq Num: 2 Session Out Seq Num: 3 Frame In Seq Num: 3 Frame Out Seq Num: 2 14:01:32 (2117640) -> Rx Type: 6, Subtype: IAX_COMMAND_TXREQ Session Call Number: 9186 Peer Call Number: 5 Frame Source Call: 1408 Frame Dest Call: 57891 Session In Seq Num: 2 Session Out Seq Num: 3 Frame In Seq Num: 3 Frame Out Seq Num: 2 14:01:32 (2117656) -> Tx Type: 6, Subtype: IAX_COMMAND_TXCNT Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 3 Session Out Seq Num: 3 Sending Seq Num: 0 14:01:32 (2117718) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9186 Peer Call Number: 5 Frame Source Call: 1408 Frame Dest Call: 57891 Session In Seq Num: 3 Session Out Seq Num: 4 Frame In Seq Num: 4 Frame Out Seq Num: 3 14:01:41 (2126953) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 3 Session Out Seq Num: 4 Sending Seq Num: 0 14:01:51 (2136375) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 3 Session Out Seq Num: 4 Sending Seq Num: 0 14:02:00 (2145656) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 3 Session Out Seq Num: 4 Sending Seq Num: 0 14:02:09 (2154953) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 3 Session Out Seq Num: 4 Sending Seq Num: 0 14:02:19 (2164265) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 3 Session Out Seq Num: 4 Sending Seq Num: 0 14:02:24 (2169140) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Session Call Number: 9187 Peer Call Number: 0 Session In Seq Num: 0 Session Out Seq Num: 0 Sending Seq Num: -1 14:02:24 (2169156) -> Rx Type: 6, Subtype: IAX_COMMAND_REGAUTH Session Call Number: 9187 Peer Call Number: 2 Frame Source Call: 640 Frame Dest Call: 58147 Session In Seq Num: 0 Session Out Seq Num: 1 Frame In Seq Num: 1 Frame Out Seq Num: 0 14:02:24 (2169171) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Session Call Number: 9187 Peer Call Number: 2 Session In Seq Num: 1 Session Out Seq Num: 1 Sending Seq Num: -1 14:02:24 (2169171) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Session Call Number: 9188 Peer Call Number: 0 Session In Seq Num: 0 Session Out Seq Num: 0 Sending Seq Num: -1 14:02:24 (2169187) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK Session Call Number: 9187 Peer Call Number: 2 Frame Source Call: 640 Frame Dest Call: 58147 Session In Seq Num: 1 Session Out Seq Num: 2 Frame In Seq Num: 2 Frame Out Seq Num: 1 14:02:24 (2169203) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9187 Peer Call Number: 2 Session In Seq Num: 2 Session Out Seq Num: 2 Sending Seq Num: 2 14:02:24 (2169250) -> Rx Type: 6, Subtype: IAX_COMMAND_REGAUTH Session Call Number: 9188 Peer Call Number: 192 Frame Source Call: 49280 Frame Dest Call: 58403 Session In Seq Num: 0 Session Out Seq Num: 1 Frame In Seq Num: 1 Frame Out Seq Num: 0 14:02:24 (2169265) -> Tx Type: 6, Subtype: IAX_COMMAND_REGREQ Session Call Number: 9188 Peer Call Number: 192 Session In Seq Num: 1 Session Out Seq Num: 1 Sending Seq Num: -1 14:02:24 (2169296) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9188 Peer Call Number: 192 Frame Source Call: 49280 Frame Dest Call: 58403 Session In Seq Num: 1 Session Out Seq Num: 2 Frame In Seq Num: 1 Frame Out Seq Num: 0 14:02:24 (2169328) -> Rx Type: 6, Subtype: IAX_COMMAND_REGACK Session Call Number: 9188 Peer Call Number: 192 Frame Source Call: 49280 Frame Dest Call: 58403 Session In Seq Num: 1 Session Out Seq Num: 2 Frame In Seq Num: 2 Frame Out Seq Num: 1 14:02:24 (2169343) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9188 Peer Call Number: 192 Session In Seq Num: 2 Session Out Seq Num: 2 Sending Seq Num: 2 14:02:28 (2173562) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 3 Session Out Seq Num: 4 Sending Seq Num: 0 14:02:37 (2182859) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 4 Session Out Seq Num: 4 Sending Seq Num: 0 14:02:38 (2183062) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 4 Session Out Seq Num: 4 Sending Seq Num: 4 14:02:46 (2191031) -> Rx Type: 6, Subtype: IAX_COMMAND_PING Session Call Number: 9186 Peer Call Number: 5 Frame Source Call: 1408 Frame Dest Call: 57891 Session In Seq Num: 4 Session Out Seq Num: 4 Frame In Seq Num: 4 Frame Out Seq Num: 4 14:02:46 (2191046) -> Tx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 5 Session Out Seq Num: 4 Sending Seq Num: 4 14:02:47 (2192156) -> Tx Type: 6, Subtype: IAX_COMMAND_TXREJ Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 5 Session Out Seq Num: 4 Sending Seq Num: 0 14:02:47 (2192875) -> Tx Type: 6, Subtype: IAX_COMMAND_HANGUP Session Call Number: 9186 Peer Call Number: 5 Session In Seq Num: 5 Session Out Seq Num: 4 Sending Seq Num: -1 14:02:48 (2193031) -> Rx Type: 6, Subtype: IAX_COMMAND_ACK Session Call Number: 9186 Peer Call Number: 5 Frame Source Call: 1408 Frame Dest Call: 57891 Session In Seq Num: 5 Session Out Seq Num: 5 Frame In Seq Num: 5 Frame Out Seq Num: 5 14:02:48 (2193046) -> Rx Type: 6, Subtype: IAX_COMMAND_INVAL Session Call Number: 9186 Peer Call Number: 5 Frame Source Call: 1408 Frame Dest Call: 57891 Session In Seq Num: 5 Session Out Seq Num: 5 Frame In Seq Num: 0 Frame Out Seq Num: 0 |
From: Steve K. <st...@st...> - 2004-02-05 19:48:26
|
In looking at the code a bit more, it looks like libiax2 doesn't support native bridging. Regardless, it would only work if both ends of the call were IAX2; I guess a part of your call path is all IAX2 (you could go around the middle asterisk server), but you couldn't native bridge between IAX2 and SIP. Kim Hendrikse wrote: >FYI, > >In reference to "The bug" I have been using the iaxcomm program quite >a lot to go from > >iaxcomm <-> asterisk - NAT <-> asterisk - NAT <-> SIP (ATA 186) > >This evening I made a call and apparently one side of the conversation >dropped out. The SIP/ATA side could hear me fine but I couldn't hear them >anymore. This happened after about 3 minutes. I was tracing the packets >on one side, the iaxcomm side, with Alastair Maws iax2 plugin into ethereal. >I saw no sign of any attempt to bridge, nor should it be able to actually >as there is nat in the way. Having said that, it may be useful to check >that the configuration files reflect this fact so the other side knows >that it is unreachable as I only traced one side. > >Yesterday evening I made several calls and they would simply drop out >after random times, usually around 4 minutes or so, but then I didn't have >the iax2 plugin in ethereal nor was I tracing it. > > - Kim > > > >>Steven Sokol wrote: >> >> >> >>>Steve, >>> >>> >>> >>>Can you give me a clue as to where the decision is made to use a full >>>frame for voice vs. a mini? I also want to understand if I am correct >>>in my assumption that we are dealing with four distinct legs: [A] <-> >>>[Asterisk] <-> [B] or if Asterisk somehow redirects/reinvites the >>>connection to the proper destination ([A] <-> [B]). Since Asterisk >>>throws the Retrans message, I would guess it is the first option. >>> >>> >>> >>>Is there any way to know where the audio data is going? The monitors >>>remain active, and the call is still live. Why would the audio stream >>>simply _/stop/_ instead of just pausing. >>> >>> >>> >>first question: see chan_iax2.c, and the code I excerpted earlier. i.e. >>when the "sendmini" flag is set. >> >>Asterisk and IAX2 has a feature called "native bridging" for IAX2, where >>when you have two IAX2 calls going through an asterisk server, the >>asterisk server lets them know about it, and they will try to send audio >>frames directly to each other, as opposed to going through the asterisk >>server. >> >>In this mode, control frames are still supposed to go through the >>asterisk server, while audio frames go directly from endpoint to >>endpoint. Mark has recently written a better description of this on the >>asterisk list. This only happens when certain conditions are satisfied: >> >>1) Both ends of the calls are using the same codec, >>2) The two ends are able to reach each other directly (i.e. there's no >>NAT, firewall, etc involved). >>3) maybe more? >> >>I _think_ that libiax2 and therefore iaxclient should support this. If >>this is the case, and you're using this feature, then I have a feeling >>that the bug may something along the lines of iaxclient/libiax2 sending >>the "full" voice frame to the wrong place. I.e. maybe it should be >>going directly to the other iaxclient, and it is instead being sent >>through asterisk, or vice versa. OR, the problem could just be that >>the ack is being sent to the wrong place, etc. >> >>Using ethereal or even tcpdump or another sniffer on the different >>segments should show you what's going on. >> >>The code for this might be the "transfer" stuff in libiax2 (or maybe >>not. I'm not sure if that's something different, when the whole call is >>transfered, and not just bridged) see EVENT_TX{REPLY,REJECT,ACCEPT}, and >>the variable "transfer". In chan_iax2, this would be the stuff >>controlled by the preprocessor symbol BRIDGE_OPTIMIZATION, and variables >>with the name bridge. >> >>-SteveK >> >> >> >> >> >> >>>------------------------------------------------------------------------ >>> >>>*From:* iax...@li... >>>[mailto:iax...@li...] *On Behalf Of >>>*Steve Kann >>>*Sent:* Thursday, February 05, 2004 8:35 AM >>>*To:* Michael Van Donselaar >>>*Cc:* iax...@li... >>>*Subject:* Re: [Iaxclient-devel] Some data related to the new bug... >>> >>> >>> >>>Michael Van Donselaar wrote: >>> >>>On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <ad...@te...> >>><mailto:ad...@te...> wrote: >>> >>> >>> >>> >>> >>> >>> >>>>usec is nanoseconds (1 second = a million nanoseconds) >>>> >>>> >>>> >>>> >>>> >>>And I can't even blame this on not having my coffee yet. I was seeing >>>usec, but >>> >>>thinking msec. >>> >>> >>> >>>I don't know if I'm seeing something that's not there, but is anyone >>>suspicious >>> >>>that 65-67 second sounds an awful lot like 65536 msec? >>> >>> >>> >>> >>>Yes, it sounds exactly like that. >>> >>>I don't actually think it is the Win32 gettimeofday implementation, >>>but some other set of circumstances which cause this problem. I'm not >>>sure why Steve U isn't seeing this, but others are, but there may be >>>another explanation for that. >>> >>>I think it has to do with the full frame vs mini frame for voice >>>frames, somehow. I haven't seen this happen myself, though. >>> >>>-SteveK >>> >>> >>> > > > |
From: Steve K. <st...@st...> - 2004-02-05 19:08:48
|
Steven Sokol wrote: > Steve, > > > > Can you give me a clue as to where the decision is made to use a full > frame for voice vs. a mini? I also want to understand if I am correct > in my assumption that we are dealing with four distinct legs: [A] <-> > [Asterisk] <-> [B] or if Asterisk somehow redirects/reinvites the > connection to the proper destination ([A] <-> [B]). Since Asterisk > throws the Retrans message, I would guess it is the first option. > > > > Is there any way to know where the audio data is going? The monitors > remain active, and the call is still live. Why would the audio stream > simply _/stop/_ instead of just pausing. > first question: see chan_iax2.c, and the code I excerpted earlier. i.e. when the "sendmini" flag is set. Asterisk and IAX2 has a feature called "native bridging" for IAX2, where when you have two IAX2 calls going through an asterisk server, the asterisk server lets them know about it, and they will try to send audio frames directly to each other, as opposed to going through the asterisk server. In this mode, control frames are still supposed to go through the asterisk server, while audio frames go directly from endpoint to endpoint. Mark has recently written a better description of this on the asterisk list. This only happens when certain conditions are satisfied: 1) Both ends of the calls are using the same codec, 2) The two ends are able to reach each other directly (i.e. there's no NAT, firewall, etc involved). 3) maybe more? I _think_ that libiax2 and therefore iaxclient should support this. If this is the case, and you're using this feature, then I have a feeling that the bug may something along the lines of iaxclient/libiax2 sending the "full" voice frame to the wrong place. I.e. maybe it should be going directly to the other iaxclient, and it is instead being sent through asterisk, or vice versa. OR, the problem could just be that the ack is being sent to the wrong place, etc. Using ethereal or even tcpdump or another sniffer on the different segments should show you what's going on. The code for this might be the "transfer" stuff in libiax2 (or maybe not. I'm not sure if that's something different, when the whole call is transfered, and not just bridged) see EVENT_TX{REPLY,REJECT,ACCEPT}, and the variable "transfer". In chan_iax2, this would be the stuff controlled by the preprocessor symbol BRIDGE_OPTIMIZATION, and variables with the name bridge. -SteveK > > > ------------------------------------------------------------------------ > > *From:* iax...@li... > [mailto:iax...@li...] *On Behalf Of > *Steve Kann > *Sent:* Thursday, February 05, 2004 8:35 AM > *To:* Michael Van Donselaar > *Cc:* iax...@li... > *Subject:* Re: [Iaxclient-devel] Some data related to the new bug... > > > > Michael Van Donselaar wrote: > >On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <ad...@te...> <mailto:ad...@te...> wrote: > > > > > >>usec is nanoseconds (1 second = a million nanoseconds) >> >> >> > > >And I can't even blame this on not having my coffee yet. I was seeing usec, but > >thinking msec. > > > >I don't know if I'm seeing something that's not there, but is anyone suspicious > >that 65-67 second sounds an awful lot like 65536 msec? > > > > > Yes, it sounds exactly like that. > > I don't actually think it is the Win32 gettimeofday implementation, > but some other set of circumstances which cause this problem. I'm not > sure why Steve U isn't seeing this, but others are, but there may be > another explanation for that. > > I think it has to do with the full frame vs mini frame for voice > frames, somehow. I haven't seen this happen myself, though. > > -SteveK > |
From: Steven S. <ss...@so...> - 2004-02-05 17:04:36
|
Steve, Can you give me a clue as to where the decision is made to use a full frame for voice vs. a mini? I also want to understand if I am correct in my assumption that we are dealing with four distinct legs: [A] <-> [Asterisk] <-> [B] or if Asterisk somehow redirects/reinvites the connection to the proper destination ([A] <-> [B]). Since Asterisk throws the Retrans message, I would guess it is the first option. Is there any way to know where the audio data is going? The monitors remain active, and the call is still live. Why would the audio stream simply _stop_ instead of just pausing. _____ From: iax...@li... [mailto:iax...@li...] On Behalf Of Steve Kann Sent: Thursday, February 05, 2004 8:35 AM To: Michael Van Donselaar Cc: iax...@li... Subject: Re: [Iaxclient-devel] Some data related to the new bug... Michael Van Donselaar wrote: On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <mailto:ad...@te...> <ad...@te...> wrote: usec is nanoseconds (1 second = a million nanoseconds) And I can't even blame this on not having my coffee yet. I was seeing usec, but thinking msec. I don't know if I'm seeing something that's not there, but is anyone suspicious that 65-67 second sounds an awful lot like 65536 msec? Yes, it sounds exactly like that. I don't actually think it is the Win32 gettimeofday implementation, but some other set of circumstances which cause this problem. I'm not sure why Steve U isn't seeing this, but others are, but there may be another explanation for that. I think it has to do with the full frame vs mini frame for voice frames, somehow. I haven't seen this happen myself, though. -SteveK |
From: Steve K. <st...@st...> - 2004-02-05 14:35:34
|
Michael Van Donselaar wrote: >On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <ad...@te...> wrote: > > > >>usec is nanoseconds (1 second = a million nanoseconds) >> >> > >And I can't even blame this on not having my coffee yet. I was seeing usec, but >thinking msec. > >I don't know if I'm seeing something that's not there, but is anyone suspicious >that 65-67 second sounds an awful lot like 65536 msec? > > Yes, it sounds exactly like that. I don't actually think it is the Win32 gettimeofday implementation, but some other set of circumstances which cause this problem. I'm not sure why Steve U isn't seeing this, but others are, but there may be another explanation for that. I think it has to do with the full frame vs mini frame for voice frames, somehow. I haven't seen this happen myself, though. -SteveK |
From: Scott L. <la...@la...> - 2004-02-05 06:35:11
|
On Wed, Feb 04, 2004 at 09:12:04AM -0600, Steven Sokol wrote: > Just wondering if the silence since my last message is due to my mail server > or if everyone has left the building. > Sourceforge lists are frelled. Dog slow. spa...@li... moved to spa...@in... due to these problems over the past couple of weeks. -- Scott Lambert KC5MLE Unix SysAdmin la...@la... |
From: Kim H. <ki...@ki...> - 2004-02-05 03:06:49
|
The timeing of 65-67 secondsIt may be related to the problem, but it's not the whole problem. I've spent quite a lot of time using a setup like: iaxcomm -> asterisk - asterisk -> ata186 I usually get between 5 and 10 minutes per call. The other chap was getting about 1 hour. My situation is: 733 Mhz Pentium III, windows XP, iaxcomm -> 2.4Ghz Pentium IV I'm curious to know the setup that is resulting in a regular 65-67 secs then failure. - Kim > On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <ad...@te...> wrote: > > >usec is nanoseconds (1 second = a million nanoseconds) > > And I can't even blame this on not having my coffee yet. I was seeing usec, but > thinking msec. > > I don't know if I'm seeing something that's not there, but is anyone suspicious > that 65-67 second sounds an awful lot like 65536 msec? > > >----- Original Message ----- > >From: "Michael Van Donselaar" <mv...@va...> > >To: "Steve Kann" <st...@st...> > >Cc: <iax...@li...> > >Sent: Thursday, February 05, 2004 12:06 PM > >Subject: Re: [Iaxclient-devel] Some data related to the new bug... > > > > > >On Wed, 04 Feb 2004 18:59:25 -0500, Steve Kann <st...@st...> wrote: > > > >> > >>If this only happens on windows, one place I'd look it to make sure the > >>"gettimeofday" replacement there is correct; it's in winfuncs.c. It's > >>basically adapted from the earlier hack in libiax "winiphone".. > >> > > > >I see that you have: > > > >--8<-------- > >void gettimeofday(struct timeval *tv, struct timezone *tz) > >{ > > long l = startuptime + GetTickCount(); > > > > tv->tv_sec = l / 1000; > > tv->tv_usec = (l % 1000) * 1000; > > return; > >} > >--8<-------- > > > >shouldn't you have, instead: > > > > tv->tv_usec = (l % 1000); > > > > > > > >------------------------------------------------------- > >The SF.Net email is sponsored by EclipseCon 2004 > >Premiere Conference on Open Tools Development and Integration > >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > >http://www.eclipsecon.org/osdn > >_______________________________________________ > >Iaxclient-devel mailing list > >Iax...@li... > >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > > > >------------------------------------------------------- > >The SF.Net email is sponsored by EclipseCon 2004 > >Premiere Conference on Open Tools Development and Integration > >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > >http://www.eclipsecon.org/osdn > >_______________________________________________ > >Iaxclient-devel mailing list > >Iax...@li... > >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
From: Steven S. <ss...@so...> - 2004-02-05 02:15:29
|
Guys, I tossed in Adam's code. It makes a very nice replacement for the original GetTimeOfDay function, but it does not seem to fix the problem. (Still good to have a far more accurate time function - thanks Adam!) Anybody have any other ideas? I tend to agree w/ Michael that the number sure looks close to 65535+1, but others have said the window is different on their pcs. Who knows.... More thoughts? Steve > -----Original Message----- > From: iax...@li... [mailto:iaxclient-devel- > ad...@li...] On Behalf Of Adam Hart > Sent: Wednesday, February 04, 2004 6:39 PM > To: iax...@li... > Subject: Re: [Iaxclient-devel] Some data related to the new bug... > > Why don't you guys just use my code from firefly, it's has nanosecond > accuracy. Beats the hell out of 10ms accuaracy > > static __int64 freq,start; > static int inited = 0; > > //static time_t startuptime; > > BOOL APIENTRY DllMain( HANDLE hModule, > DWORD ul_reason_for_call, > LPVOID lpReserved > ) > { > if(!inited) > { > > inited = 1; > QueryPerformanceFrequency((LARGE_INTEGER*)&freq); > QueryPerformanceCounter((LARGE_INTEGER*)&start); > } > return TRUE; > } > > void gettimeofday(struct timeval *tv, struct timezone *tz) > { > __int64 time; > double elapsed; > > QueryPerformanceCounter((LARGE_INTEGER*)&time); > > elapsed = (double)(time - start) / (double)freq; > > tv->tv_sec = (long)elapsed; > tv->tv_usec = (long)((elapsed-tv->tv_sec) * 1000000); > } > > enjoy, > Adam > > ----- Original Message ----- > From: "Steven Sokol" <ss...@so...> > To: <iax...@li...> > Sent: Thursday, February 05, 2004 11:34 AM > Subject: RE: [Iaxclient-devel] Some data related to the new bug... > > > > Yes. Guilty as charged. It always happens UNDER WINDOWS. > > > > I believe that the gettimeofday() is being replaced by a function based > on > > GetTickCount(). I wonder if that doesn't have something to do with it. > > > > Steve S > > > > -----Original Message----- > > From: iax...@li... > > [mailto:iax...@li...] On Behalf Of Steve > > Underwood > > Sent: Wednesday, February 04, 2004 5:48 PM > > To: iax...@li... > > Subject: Re: [Iaxclient-devel] Some data related to the new bug... > > > > Steven Sokol wrote: > > > > >More notes: > > > > > >1. It ALWAYS happens. It is not an intermittent issue. This happens > for > > >EVERY IAX2-to-IAX2 call made using iaxClient. > > > > > > > > Not EVERY call. I make hour long calls using iaxclient IAX2-to-IAX2 and > > have no trouble. I use Linux. Is that the difference? > > > > >2. The timing is uncanny. It ALWAYS happens after 65-67 seconds. > > > > > >3. The audio dies but the call in not immediately torn down. The call > > >eventually is eventually killed when the PING/PONG cycle times out some > > >seconds later (perhaps over a minute in some of my tests). > > > > > >4. In EVERY case, the Asterisk kicks out the aforementioned voice > frame > > >retransmit message. > > > > > > > > As Adam said, there is something wrong if a voice frame is being > > retransmitted at that point in the call. Perhaps checking places where > > the frame is tagged for retransmission would home in on the problem. > > > > >5. I don't see registration messages coming through at the same time. > I > > >was originally guessing that this happened during the re-reg process. > Not > > >so (or at least that doesn't seem to be the case -- could be that the > > re-reg > > >that takes place prior to the error causes a problem). > > > > > > > > Regards, > > Steve > > > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Iaxclient-devel mailing list > > Iax...@li... > > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Iaxclient-devel mailing list > > Iax...@li... > > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Iaxclient-devel mailing list > Iax...@li... > https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
From: Michael V. D. <mv...@va...> - 2004-02-05 01:23:02
|
On Thu, 05 Feb 2004 12:08:32 +1100, Adam Hart <ad...@te...> = wrote: >usec is nanoseconds (1 second =3D a million nanoseconds) And I can't even blame this on not having my coffee yet. I was seeing = usec, but thinking msec. I don't know if I'm seeing something that's not there, but is anyone = suspicious that 65-67 second sounds an awful lot like 65536 msec? >----- Original Message -----=20 >From: "Michael Van Donselaar" <mv...@va...> >To: "Steve Kann" <st...@st...> >Cc: <iax...@li...> >Sent: Thursday, February 05, 2004 12:06 PM >Subject: Re: [Iaxclient-devel] Some data related to the new bug... > > >On Wed, 04 Feb 2004 18:59:25 -0500, Steve Kann <st...@st...> = wrote: > >> >>If this only happens on windows, one place I'd look it to make sure the= =20 >>"gettimeofday" replacement there is correct; it's in winfuncs.c. It's=20 >>basically adapted from the earlier hack in libiax "winiphone".. >> > >I see that you have: > >--8<-------- >void gettimeofday(struct timeval *tv, struct timezone *tz) >{ > long l =3D startuptime + GetTickCount(); > > tv->tv_sec =3D l / 1000; > tv->tv_usec =3D (l % 1000) * 1000; > return; >} >--8<-------- > >shouldn't you have, instead: > > tv->tv_usec =3D (l % 1000); > > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Iaxclient-devel mailing list >Iax...@li... >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Iaxclient-devel mailing list >Iax...@li... >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
From: Adam H. <ad...@te...> - 2004-02-05 01:11:24
|
usec is nanoseconds (1 second = a million nanoseconds) ----- Original Message ----- From: "Michael Van Donselaar" <mv...@va...> To: "Steve Kann" <st...@st...> Cc: <iax...@li...> Sent: Thursday, February 05, 2004 12:06 PM Subject: Re: [Iaxclient-devel] Some data related to the new bug... On Wed, 04 Feb 2004 18:59:25 -0500, Steve Kann <st...@st...> wrote: > >If this only happens on windows, one place I'd look it to make sure the >"gettimeofday" replacement there is correct; it's in winfuncs.c. It's >basically adapted from the earlier hack in libiax "winiphone".. > I see that you have: --8<-------- void gettimeofday(struct timeval *tv, struct timezone *tz) { long l = startuptime + GetTickCount(); tv->tv_sec = l / 1000; tv->tv_usec = (l % 1000) * 1000; return; } --8<-------- shouldn't you have, instead: tv->tv_usec = (l % 1000); ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Iaxclient-devel mailing list Iax...@li... https://lists.sourceforge.net/lists/listinfo/iaxclient-devel |
From: Michael V. D. <mv...@va...> - 2004-02-05 01:06:45
|
On Wed, 04 Feb 2004 18:59:25 -0500, Steve Kann <st...@st...> wrote: > >If this only happens on windows, one place I'd look it to make sure the=20 >"gettimeofday" replacement there is correct; it's in winfuncs.c. It's=20 >basically adapted from the earlier hack in libiax "winiphone".. > I see that you have: --8<-------- void gettimeofday(struct timeval *tv, struct timezone *tz) { long l =3D startuptime + GetTickCount(); tv->tv_sec =3D l / 1000; tv->tv_usec =3D (l % 1000) * 1000; return; } --8<-------- shouldn't you have, instead: tv->tv_usec =3D (l % 1000); |