[asterisk-dev] Intermittent one-way audio and call failure on trunk

[Matthew Jordan]

----- Original Message -----
> From: "Jonn Taylor" <jonnt at taylortelephone.com>
> To: "Asterisk Developers" <asterisk-dev at lists.digium.com>
> Sent: Thursday, July 12, 2012 4:05:28 PM
> Subject: [asterisk-dev] Intermittent one-way audio and call failure on trunk
> 
> First off i open a bug on this a few weeks ago and was told that it
> was
> a network config problem but rolling back to a previous revision
> trunk
> makes the problem go away.

Do you have a revision number for trunk which eliminated the problems
you're having?

> Have running test system at home on my gateway server that is running
> CentOS 5 i386, dual nic's, using freepbx 2.10. Using SIP, Unistim and
> IAX devices. SIP trunk provider is bandwidth.com(level3).

That's a lot of ground to cover.  In particular, chan_unistim received
major updates for Asterisk 11 (more information here:
https://wiki.asterisk.org/wiki/display/AST/Unistim+channel+improvements).
You may want to try and narrow down the scope of your problems by
limiting things to one particular technology at a time.

Do you have the same problems running something other than trunk?  That
might at least eliminate whether or not its an issue with trunk, or an
issue with a release branch of Asterisk.

> Current version of trunk I am getting 2 problem. Sometimes the phones
> do
> a partial ring and hangup and the second is the call will ring you
> can
> answer the call but get one-way audio, caller can not hear you. If
> you
> put the call on-hold sometimes you can get the audio to work.

In your 'failed-call.txt', the remote end point sent a BYE immediately
after it sent the ACK for the 200 OK.  There are two interesting things
to note:
1) The first 200 OK we sent to the remote endpoint timed out.  The fact
that the endpoint failed to respond in a timely fashion, then immediately
sent a BYE after ACK'ing the two 200 OKs (the original and the re-transmit)
points towards some error in the remote end point - or at least, we sent
it something it didn't like.  This leads to...
2) You're transmitting ICE candidates to the remote endpoint, which may
be freaking it out.  ICE is a new feature in Asterisk 11, and can be
disabled in rtp.conf.

In the 'one-way-audio' file, there isn't anything that jumps out from
the signalling... but with no knowledge of your network, firewalls,
the entities involved, which side had one-way audio (you or them),
I'd just be guessing as to what the issue was.  Again, since ICE is
involved, it may have confused the remote end point such that it started
sending media to the wrong candidate... but without evidence pointing
to that, I'm just guessing.

> Here are the two files with the SIP debug turned on.
> 
> http://www.taylortelephone.com/Files/failed-call.txt
> 
> http://www.taylortelephone.com/Files/one-way-audio.txt
> 
> Jonn
> 

In conclusion, please do keep in mind that trunk is sometimes unstable,
due to the nature of new features being added to it almost constantly.
Sometimes things break.  Sometimes things change, and since the features
are under development, all of the notifications that things have changed
may not be apparent yet.  While reporting bugs against it is appreciated,
it may be some time before things reach a quiescent state - if they ever
do.  That isn't to say we don't appreciate people running trunk - in fact,
people who choose to run trunk in a real world environment provide invaluable
feedback.  Just remember that when you do run trunk, you're trying new
things out, and generally staying on the 'bleeding edge' of new feature
development.

Thanks

Matt

--
Matthew Jordan
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org