Re: [Iaxclient-devel] Some data related to the new bug...

[Steve K. <st...@st...>]

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
>>>
>>>      
>>>
>
>  
>