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

Thu Jul 12 18:09:29 CDT 2012

On 12-07-12 06: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?
>
>> 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
>
I'd drop FreePBX and try straight asterisk.  At least this will help 
developers try to reproduce the issue.

Also, is this even a valid SDP?

---

INVITE sip:103 at 192.168.183.144:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.183.1:5060;branch=z9hG4bK437855a3
Max-Forwards: 70
From: "WIRELESS CALLER" <sip:6512454836 at 192.168.183.1>;tag=as36dfaa7e
To: <sip:103 at 192.168.183.144:5060>
Contact: <sip:6512454836 at 192.168.183.1:5060>
Call-ID: 7c6fa93a4befd2de4a279c20428c6a10 at 192.168.183.1:5060
CSeq: 102 INVITE
User-Agent: FPBX-2.10.0(10.0)
Date: Thu, 12 Jul 2012 20:22:41 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, 
INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 1674

v=0
o=root 241945485 241945485 IN IP4 192.168.183.1
s=Asterisk PBX SVN-trunk-r369995
c=IN IP4 192.168.183.1
t=0 0
m=audio 10634 RTP/AVP 0 18 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=ice-ufrag:4ad9cb956dd68be267c870d710720d32
a=ice-pwd:06ef6d3c320442d9407e11062b9a7e97
a=candidate:Had08679d 1 UDP 2130706431 173.8.103.157 10634 typ host
a=candidate:Hc0a8b701 1 UDP 2130706431 192.168.183.1 10634 typ host
a=candidate:Hc0a8ac02 1 UDP 2130706431 192.168.172.2 10634 typ host
a=candidate:Ha0a0001 1 UDP 2130706431 10.10.0.1 10634 typ host
a=candidate:Had08679d 2 UDP 2130706430 173.8.103.157 10635 typ host
a=candidate:Hc0a8b701 2 UDP 2130706430 192.168.183.1 10635 typ host
a=candidate:Hc0a8ac02 2 UDP 2130706430 192.168.172.2 10635 typ host
a=candidate:Ha0a0001 2 UDP 2130706430 10.10.0.1 10635 typ host
a=sendrecv
m=video 10660 RTP/AVP 99 104
a=ice-ufrag:4719753d76024bab3a6d5d487fcdbcc9
a=ice-pwd:46c323cb23353b5b6ad6669014a1a89e
a=candidate:Had08679d 1 UDP 2130706431 173.8.103.157 10660 typ host
a=candidate:Hc0a8b701 1 UDP 2130706431 192.168.183.1 10660 typ host
a=candidate:Hc0a8ac02 1 UDP 2130706431 192.168.172.2 10660 typ host
a=candidate:Ha0a0001 1 UDP 2130706431 10.10.0.1 10660 typ host
a=candidate:Had08679d 2 UDP 2130706430 173.8.103.157 10661 typ host
a=candidate:Hc0a8b701 2 UDP 2130706430 192.168.183.1 10661 typ host
a=candidate:Hc0a8ac02 2 UDP 2130706430 192.168.172.2 10661 typ host
a=candidate:Ha0a0001 2 UDP 2130706430 10.10.0.1 10661 typ host
a=rtpmap:99 H264/90000
a=rtpmap:104 MP4V-ES/90000
a=sendrecv

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: 
https://twitter.com/pabelanger