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

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

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
>