Summary:	ASTERISK-07679: channel.c set_format() exits prematurely under some circumstances.
Reporter:	Tony Mountifield (softins)	Labels:
Date Opened:	2006-09-05 10:19:38	Date Closed:	2006-09-09 15:26:16
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	The optimisations to set_format() in channel.c that were introduced to the 1.2 branch in revision 38310 and revised in revision 38347 appear to exit from set_format() in at least one situation where it should continue. If I use a call file to originate a call to a SIP channel and then send that call into a MeetMe room, no audio is heard, and the log file fills up with the message: chan_sip.c:2561 sip_write: Asked to transmit frame type 64, while native formats is 8 (read/write = 64/64) The situation can be reproduced easily, as follows (I have SIP phones on 2000 and 2002). Extract from extensions.conf: [local-extensions-novm] exten => _20XX,1,Dial(SIP/${EXTEN}) [other-extensions] exten => 4007,1,Answer exten => 4007,2,Wait(1) exten => 4007,3,MeetMe(2222|) exten => 4007,4,Hangup On my 2000 phone I dialled 4007 and entered the conference. On my 2002 phone I also dialled 4007 and entered the conference successfully, with audio being heard. I then hung up 2002 and copied the following call file to /var/spool/asterisk/outgoing: Channel: Local/2002@local-extensions-novm Extension: 4007 Context: other-extensions Priority: 1 As soon as this call enters MeetMe, the sip_write messages start, and continue until the phone is hung up. Reverting the 38347 and 38310 changes corrects the problem. This involved removing these lines:    if ((*rawformat == native) && (*format == fmt)) {        /* the channel is already in these formats, so nothing to do */        ast_mutex_unlock(&chan->lock);        return 0;    }
Comments:	By: Tony Mountifield (softins) 2006-09-05 11:07:46 Apologies, this appears to be a duplicate of bug ASTERISK-7599. Hope the information provided is useful anyway. By: Joshua C. Colp (jcolp) 2006-09-09 15:26:15 Fixed in 1.2 as of revision 42600 and trunk as of revision 42601.