Summary:	ASTERISK-05388: Answering a SIP channel, then Dialing and going into a quiet meetme causes a transmit frame type error
Reporter:	Ted Cabeen (secabeen)	Labels:
Date Opened:	2005-10-28 15:12:33	Date Closed:	2005-11-10 22:36:08.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asteriskscript_20051102.txt ( 1) extensions_20051102.conf ( 2) extensions.conf ( 3) meetme_20051102.conf ( 4) meetme.conf ( 5) sip.conf ( 6) sip20051102.conf
Description:	If you Answer a SIP channel, try to Dial out to an extension and then put the call into a quiet meetme after the Dial times out, you get the following error and no audio from the meetme: WARNING[16468]: chan_sip.c:1836 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 64/4) ****** STEPS TO REPRODUCE ****** Define the following extension in your dialplan: exten => 515,1,Answer() exten => 515,2,Dial(SIP/otherphone,5) exten => 515,3,Meetme(419|q) When you dial 515 from a SIP phone, otherphone will ring for 5 seconds, and then you'll be put in the meetme, but you won't get any audio from the meetme.   This was confirmed with a Cisco 7960 and a newly compiled 1.0.9.
Comments:	By: Serge Vecher (serge-v) 2005-10-28 15:21:49 I wonder if this is related http://bugs.digium.com/view.php?id=4101 ? Although we have no chan_local involved this time. By: Kevin P. Fleming (kpfleming) 2005-10-31 17:23:16.000-0600 We cannot begin to debug this without all the information requested in the bug posting guidelines. At a minimum, we need enough configuration information to attempt to reproduce the problem, and a complete console/debug trace showing exactly what is occurring to the call. By: Ted Cabeen (secabeen) 2005-10-31 17:28:05.000-0600 Sorry.  Here's the brief trace from the console.  I'll attach the sip.conf, meetme.conf and extensions.conf as well.  Let me know if there are any other files you need: Asterisk Ready. *CLI>    -- Executing Answer("SIP/255-74d9", "") in new stack    -- Executing Dial("SIP/255-74d9", "SIP/255|5") in new stack    -- Called 255    -- SIP/255-57a5 is ringing    -- Nobody picked up in 5000 ms    -- Executing MeetMe("SIP/255-74d9", "419|q") in new stack  == Parsing '/home/asterisk/1.0.9/etc/asterisk/meetme.conf': Found    -- Created MeetMe conference 1023 for conference '419' Oct 31 15:26:52 WARNING[19981]: chan_sip.c:1836 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 64/4) Oct 31 15:26:52 WARNING[19981]: chan_sip.c:1836 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 64/4) By: Kevin P. Fleming (kpfleming) 2005-11-01 17:30:01.000-0600 This is not an error, as the message clearly states that it is a warning. You say the meetme is 'quiet', but that you don't receive any audio from it... I'm a bit confused, can you clarify the situation for us? Finally, we are very close to releasing Asterisk 1.2, and are unlikely to make any major changes in Asterisk 1.0.x for this sort of problem. Can you test your scenario using CVS HEAD or Asterisk 1.2.0-beta2 to confirm that the problem still exists? I will try to replicate it here as well, but it would be best if you can also demonstrate that it is or is not still an issue. Thanks! By: Ted Cabeen (secabeen) 2005-11-01 17:32:28.000-0600 By quiet, I meant that the MeetMe application was passed the 'q' option.  The problem is that when you have declared the 'q' option, there's no audio at all. I'll doublecheck it with HEAD.  I think it doesn't happen there, but I'm not positive. By: Ted Cabeen (secabeen) 2005-11-01 17:56:59.000-0600 Just tested it with a HEAD from yesterday and it does happen in HEAD.  The station that gets put into the meetme after an Answer can be heard, but they can't hear anything from the other end.   If the Answer()ed called is played the conf-onlyperson file as they enter the conference, it works fine.  However, if the first audio they get after the Answer and Dial is the meetme itself, then the conversion warning shows up and they receive no audio. By: Kevin P. Fleming (kpfleming) 2005-11-01 18:58:17.000-0600 OK, I'll test it here, thanks for the clarification. By: Kevin P. Fleming (kpfleming) 2005-11-01 19:08:31.000-0600 Well, it appears that we are going to need much more information; I just tested this scenario and it worked as expected (no extraneous messages, two-way audio between the phones). At a minimum, we will need to see the SIP peer/user definitions involved, and a _complete_ console trace ('set verbose 10', 'set debug 10' and ensure that the debug channel is enabled in logger.conf) so we can set up the same scenario. By: Kevin P. Fleming (kpfleming) 2005-11-01 19:09:16.000-0600 Ahh, I see you have posted the config information already, sorry :-) If you can get the console trace, that would be most helpful. By: Ted Cabeen (secabeen) 2005-11-02 12:47:31.000-0600 I just uploaded the console trace and updated versions of the three config files.   (I added a 299 sip user so that I could be sure to have someone in the meetme when I called in and got the error.  When 299 is in the meetme, they can hear the person calling from 255, but 255 can not hear them.  255 is the sip user who is being Answered and Dialed before going into the meetme.) By: Kevin P. Fleming (kpfleming) 2005-11-07 21:36:36.000-0600 Your console log is not from CVS HEAD, so the line numbers don't match up. I will try to isolate the problem anyway :-( By: Ted Cabeen (secabeen) 2005-11-07 22:01:33.000-0600 I'm pretty sure it's from HEAD as of October 31st.  I updated on the 2nd, but it looks like I didn't re-compile.  Sorry about that. By: Kevin P. Fleming (kpfleming) 2005-11-07 22:01:41.000-0600 I just don't see it... there is nothing in CVS HEAD app_meetme.c that could cause the channel's write mode to its original value. Please upload a console log from CVS HEAD showing this behavior. By: Ted Cabeen (secabeen) 2005-11-09 00:28:09.000-0600 Hmmm.  I can't seem to replicate this one in a current HEAD.  Strange. Let's close this one for now, and if it pops back up again, I'll make sure to track it down solidly and then resubmit. By: Kevin P. Fleming (kpfleming) 2005-11-10 22:35:59.000-0600 Closing at poster's request.