[asterisk-dev] Changing channel writeformat in ast_openstream_full

[satya panda]

Hi,         Steven how are you. I have a small problem can u help me to fix
it. actually i need to know
        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.whichfunction in will call proper functions for codec
conversion.

regards
satya



On 6/28/07, Steven Critchfield <critch at basesys.com> wrote:
>
> On Wed, 2007-06-27 at 11:56 -0400, Mihai Balea wrote:
> > Hi all,
> >
> > I've noticed that ast_openstream_full(), in file.c, changes the
> > channel write format to conform to the format of the file being opened.
> > I am wondering why this is so, since the way I see it, file
> > operations should just provide a data stream to be used by other
> > layers and modules.
> >
> > More to the point, this behavior was causing some issues in
> > app_conference, when sound files of different types where queued for
> > playback.  When playing a file encoded in gsm, if a second file,
> > encoded in ulaw, is queued, then ast_openstream_full will change the
> > channel write format in midflight with all the obviously nasty results.
> >
> > Can somebody shed some light into this?
>
> Don't take my comments as authoritative. My memory of that section of
> code is also dated.
>
> The code you traverse to get a file played to a channel is
>
> --filesystem read
> format_* to actually read the bits out of a formatted file.
> ast_openstream_full to hand the audio up to the channel
> codec_* to translate it
>
> Or something like that.
>
> The idea is that you let the codecs worry about the translations, but
> they need to know what type of audio is coming at it to set up the
> translations.
>
> It makes sense this way as we are reusing code that already is being
> used to convert audio as it traverses from one endpoint to another
> regardless of what the endpoints are.
>
> I'm not certain what obvious nasty results you are experiencing. Could
> these nasty results be related to the channel type you are using? I know
> we run through these same codec changes several thousand times a day on
> our machines, but they are all using ZAP channels and therefore the end
> write function will always be the same codec. Maybe this keeps me from
> seeing the nasty results you are.
> --
> Steven Critchfield <critch at basesys.com>
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070702/1d4f2e48/attachment.htm