Summary:	ASTERISK-06218: MeetMe transcoding problem
Reporter:	op (op)	Labels:
Date Opened:	2006-01-30 07:45:08.000-0600	Date Closed:	2008-01-15 16:41:39.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_meetme
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) meetme-indications.diff
Description:	MeetMe causes problems as soon as clients using different codecs are on the same conference channel. Example: A MeetMe conference is established by a caller on an ISDN CAPI interface:   NativeFormat: 8    WriteFormat: 64     ReadFormat: 64 Another user joins the conference with his SIP device using a different codec:   NativeFormat: 4    WriteFormat: 4     ReadFormat: 64 In this case the second caller gets no audio, and the following error message appears on the console over and over again: Jan 30 15:31:23 WARNING[7351]: chan_sip.c:2524 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 64/4) The same problem occurs if multiple SIP users with different codecs join the same conference. This looks like no transcoding is done even though the channels involved would require transcoding. This installation contains kapejod's BRIstuff patches.
Comments:	By: twisted (twisted) 2006-01-30 11:03:27.000-0600 as the BRIStuff patches modify the core channel code, please use the lastet SVN trunk WITHOUT the BRIStuff patch set. By: Mike Noskov (ionic) 2006-02-13 02:41:01.000-0600 I'm observing the same issue on latest SVN trunk (as of Feb 12, 2006). Additional info: it works fine if no sound was tranferred on the channel before joining the conference. By: op (op) 2006-02-13 03:05:51.000-0600 Thanks for your feedback, that keeps me from having to set up an additional unpatched testbed system. I could get rid of this problem by removing a Ringing before joining the conference, so this actually depends on whether or not audio has been sent before starting MeetMe. Furthermore, I could reproduce the problem with two callers both using aLaw, so this does NOT seem to be a real codec issue. WriteFormat is confusing me a bit: When everything works fine, both WriteFormat and ReadFormat are set to 64 (no matter what's the native format on that channel). Whenever the problem occurs, WriteFormat is set to the native format of the channel instead. Is it possible that the indications stuff screws up the channel codec configuration? By: op (op) 2006-02-13 06:59:43.000-0600 My patch attached above fixed this issue. It causes MeetMe to end active indications (which restores the write format to its original value) _before_ switching to AST_FORMAT_SLINEAR. Please note that it's based on a BRIstuffed Asterisk, so line numbers may differ. By: Mike Noskov (ionic) 2006-02-13 08:11:03.000-0600 it solved the problem for me too, thank you By: twisted (twisted) 2006-02-13 10:41:45.000-0600 fixed in svn 1.2 & trunk.  Thanks! (please note that you must have a disclaimer on file for future code contributions that are any larger than this). By: Digium Subversion (svnbot) 2008-01-15 16:41:37.000-0600 Repository: asterisk Revision: 9756 U   branches/1.2/apps/app_meetme.c ------------------------------------------------------------------------ r9756 | twisted | 2008-01-15 16:41:37 -0600 (Tue, 15 Jan 2008) | 2 lines Don't set the formats before we stop indications.  (issue ASTERISK-6218) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=9756 By: Digium Subversion (svnbot) 2008-01-15 16:41:39.000-0600 Repository: asterisk Revision: 9759 U   trunk/apps/app_meetme.c ------------------------------------------------------------------------ r9759 | twisted | 2008-01-15 16:41:39 -0600 (Tue, 15 Jan 2008) | 2 lines Don't set the formats before we stop indications.  (issue ASTERISK-6218) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=9759