<div> </div>
<div>Hi,
<div> Steven how are you. I have a small problem can u help me to fix it. actually i need to know </div>
<div> when two peoples using two sipsoft phones using different codecs then, which functions of asterisk, and who calls them for codec conversion. suppose sipphone A is using g711Mu and sipphoneB is using g711a.which
function in will call proper functions for codec conversion. </div>
<div> </div>
<div>regards</div><span class="sg">
<div>satya </div></span><span></span></div>
<div><br><br> </div>
<div><span class="gmail_quote">On 6/28/07, <b class="gmail_sendername">Steven Critchfield</b> <<a href="mailto:critch@basesys.com">critch@basesys.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Wed, 2007-06-27 at 11:56 -0400, Mihai Balea wrote:<br>> Hi all,<br>><br>> I've noticed that ast_openstream_full(), in
file.c, changes the<br>> channel write format to conform to the format of the file being opened.<br>> I am wondering why this is so, since the way I see it, file<br>> operations should just provide a data stream to be used by other
<br>> layers and modules.<br>><br>> More to the point, this behavior was causing some issues in<br>> app_conference, when sound files of different types where queued for<br>> playback. When playing a file encoded in gsm, if a second file,
<br>> encoded in ulaw, is queued, then ast_openstream_full will change the<br>> channel write format in midflight with all the obviously nasty results.<br>><br>> Can somebody shed some light into this?<br><br>
Don't take my comments as authoritative. My memory of that section of<br>code is also dated.<br><br>The code you traverse to get a file played to a channel is<br><br>--filesystem read<br>format_* to actually read the bits out of a formatted file.
<br>ast_openstream_full to hand the audio up to the channel<br>codec_* to translate it<br><br>Or something like that.<br><br>The idea is that you let the codecs worry about the translations, but<br>they need to know what type of audio is coming at it to set up the
<br>translations.<br><br>It makes sense this way as we are reusing code that already is being<br>used to convert audio as it traverses from one endpoint to another<br>regardless of what the endpoints are.<br><br>I'm not certain what obvious nasty results you are experiencing. Could
<br>these nasty results be related to the channel type you are using? I know<br>we run through these same codec changes several thousand times a day on<br>our machines, but they are all using ZAP channels and therefore the end
<br>write function will always be the same codec. Maybe this keeps me from<br>seeing the nasty results you are.<br>--<br>Steven Critchfield <<a href="mailto:critch@basesys.com">critch@basesys.com</a>><br><br><br>_______________________________________________
<br>--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">
http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br>