Summary:	ASTERISK-09013: [patch] Half Duplex Audio on SIP Calls Using MixMonitor/AMD
Reporter:	Matt Riddell (zx81)	Labels:
Date Opened:	2007-03-14 18:21:10	Date Closed:	2011-06-07 14:02:56
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_amd
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 9281-amd-silgen.diff ( 1) debug_failed1.TXT ( 2) debug_worked1.TXT ( 3) debug_worked2.TXT ( 4) debug_worked3.TXT ( 5) debug_worked4.TXT ( 6) debug_worked5.TXT ( 7) debug_worked6.TXT ( 8) failed1.TXT ( 9) failed2.TXT (10) rtp_failed1.TXT (11) rtp_failed2.TXT (12) rtp_failed3.TXT (13) rtp_worked1.TXT (14) rtp_worked2.TXT (15) rtp_worked3.TXT (16) rtp_worked4.TXT (17) rtp_worked5.TXT (18) worked1.TXT (19) worked2.TXT (20) worked3.TXT (21) worked4.TXT (22) worked5.TXT (23) worked6.TXT (24) worked7.TXT (25) worked8.TXT (26) worked9.TXT
Description:	Second call from Asterisk Box causes no audio to be transferred when using mixmonitor ****** STEPS TO REPRODUCE ****** Hi, We have the following situation: * Asterisk Calls a number * User Listens to message * Caller Presses 1 * MixMonitor Starts * Call is sent via voip to a call center If Packet2Packet Bridging occurs, (i.e. MixMonitor is not involved) the calls work fine.   The calls do not always fail.  With MixMonitor, about 20% of the calls are half duplex. Also I noticed from the rtcp stats that in the failed calls say that we have sent no packets. There is no NAT involved.
Comments:	By: Serge Vecher (serge-v) 2007-03-15 08:14:40 everything looks aok in the failed logs. Make sure debug is set for console in logger.conf, do core set debug 4 and redo the tests. By: Matt Riddell (zx81) 2007-03-15 14:42:10 You'll notice in the rtcp stats that asterisk is not sending any audio in the failed tests. By: Matt Riddell (zx81) 2007-03-15 14:51:53 Debugs attached - looks like maybe a problem with: [Mar 15 18:15:24] DEBUG[15780]: channel.c:1586 queue_frame_to_spies: Triggering queue flush for spy 'MixMonitor' on 'SIP/voipjet-006bf0a0' By: Matt Riddell (zx81) 2007-03-15 23:59:24 anything else i can add to make this easier to debug? By: Olle Johansson (oej) 2007-03-18 05:31:35 enable rtp debugging to see what we're getting and sending to each side. Thanks. By: Matt Riddell (zx81) 2007-03-19 17:58:18 :) Damn that's a lot of logs Pretty much everything I can add I guess! :) By: Matt Riddell (zx81) 2007-03-20 18:31:22 Anything I can do to get this bumped?  Customer is looking to dump Asterisk.  This is an enterprise set up with up to concurrent 3000 lines, and I'd really prefer it to be running Asterisk! By: Serge Vecher (serge-v) 2007-03-20 19:13:42 do you have to use AMD? perhaps test without it... Also, if you catch the right guy at the right moment on #asterisk-bugs irc channel on freenet you may get lucky. There is always an option of hiring somebody too. Just trying to give you options. By: Matt Riddell (zx81) 2007-03-20 19:56:13 It doesn't happen when using no Mixmonitor, but using AMD, whereas it does happen when using Mixmonitor. In the time period where AMD is happening, the call is full duplex, it only fails once it gets to the next call (i.e. the user has pressed one). By: Matt Riddell (zx81) 2007-03-20 19:56:42 Who would you recommend to hire? By: Joshua C. Colp (jcolp) 2007-03-20 22:05:00 Please try the attached patch. MixMonitor wants a constant stream of frames and when AMD is executed it doesn't get that... so it can freak out. By: Matt Riddell (zx81) 2007-03-21 03:59:38 Waiting for customer to become available for next test.  Should have results within 48 hours. By: Serge Vecher (serge-v) 2007-03-22 15:11:31 how goes the testing, Matt? By: Matt Riddell (zx81) 2007-03-25 01:43:47 Still waiting on customer, hope to get it done tonight. By: Matt Riddell (zx81) 2007-03-26 17:03:31 So far we are 6 calls into the test without any half duplex, will do another 9 calls. Call 9/15 was half duplex. /me cries Any other ideas? By: Matt Riddell (zx81) 2007-03-26 17:44:42 Initially we saw that on calls that don't do Packet2Packet bridging there was a *possibility* of a HD call. When Packet2Packet bridging is enabled there is never a problem. Thing is, Local Channel usage or Mixmonitor cause the channel to not do P2P bridging. If someone wants I can give root access to the boxes, organise testing of patches, anything as long as I can get this fixed. By: Matt Riddell (zx81) 2007-03-26 18:26:55 Ok, here's the results of testing without having AMD running (as per File's request on IRC): Call 1: Ok Call 2: Ok Call 3: Ok Call 4: Ok Call 5: Ok Call 6: Half Duplex By: Joshua C. Colp (jcolp) 2007-03-27 14:56:19 Okay then can I get access to the machine where this is happening and have it loaded with emacs so I can make some source modifications? By: Matt Riddell (zx81) 2007-03-27 19:40:12 Sure, I'll catch you on IRC. Haven't seen you on IRC, I've emailed you the access details. By: Matt Riddell (zx81) 2007-03-28 15:29:57 Hi, Any word? By: Joshua C. Colp (jcolp) 2007-03-29 18:45:09 This was a configuration issue involving rfc2833compensate, a silly RFC2833 implementation, and out of order packets. If this arises again... please reopen.