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

[Taylor, Jonn]

On 07/12/2012 05:15 PM, Matthew Jordan wrote:
> ----- 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?
https://issues.asterisk.org/jira/browse/ASTERISK-20050
>
>> 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.
I have had one-way audio on SIP to SIP, SIP to IAX and SIP to USTM.
>
> 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.
NO, I rolled back to 362497 and there are no problems.
>
>> 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.
Is this enabled by default?
>
> 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.
I can reproduce this on my test system at home, HP DL380 G3 with ClearOS 
5, and my production system in our office that is on a older Dell that 
is running CentOS 5.8 i386. Both have almost the identical setup.

Internet <-> server with asterisks <-> internal network
>
>> 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.
I have been running trunk as I have been helping with chan_unistim
>
> 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
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>     http://lists.digium.com/mailman/listinfo/asterisk-dev