[asterisk-dev] channel formats and ast_set_read/write_format
Klaus Darilion
klaus.mailinglists at pernau.at
Wed Apr 1 05:00:33 CDT 2009
Hi!
I tried to understand the channel formats myself and have some
speculations - it would be nice if somebody can comment ("correct" or
"wrong"):
nativeformats: This is what the channel is able to handle. This is a
bitmask where mutliple formats can be specified. The channel must be
prepared to receive frames in any of this formats.
readformat: this is the format (a single format) in which the core wants
to read the frames from a channel
writeformat: this is the format (a single format) in which the core
writes frames to a channel
rawreadformat: this is the format in which the channel delivers frames
via the channel's read function. This should be one of the nativeformats.
rawwriteformat: this is the format in which the channel receives frames
via the channel's write function. This should be one of the nativeformats.
If a call is bridged, the readformat must be equal to the writeformat of
the bridged channel, and vice versa.
When the core writes frames to a channel, the channel's writetrans
translatorpath will be used to translate from the writeformat in any of
the channel's native formats.
The channel's read function has to provide the frames in the channel's
rawreadformat. This will be transcoded to readformat by channel's
readtrans translatorpath.
If the channel's read function would return a format which is different
to the channel's rawreadformat (e.g. the SIP peer sends with a new
codec) the channel has to set nativeformats to the new format and call
ast_set_read_format(*chan,current readformat) to initiate a new
translation path.
If the channel does not support transcoding itself, it must be ensured
that nativeformats include only a single format (the one that the
channel returns on it's read function) as the readtranslator will expect
the format in this. (As set_format chooses one of the nativeformats as
rawreadformat - thus the channel must return frames in the rawreadformat).
nativeformats: is set by the channel
readformat/writeformat: is set by the core (e.g. when making
channels compatible for bridging) or by an application which
is connected to a channel implicit by using the
ast_set_read/write_format() functions.
rawreadformat/rawwriteformat is set implicit when
ast_set_read/write_format() sets up a new translator path.
Hope that someone comments on this. If it is correct we could add it to
developer documentation.
thanks
klaus
Klaus Darilion wrote:
> Hi!
>
> I failed to find out the differences in struct ast_channel between:
>
> int nativeformats; /*!< Kinds of data this channel can
> natively handle */
> int readformat; /*!< Requested read format */
> int writeformat; /*!< Requested write format */
> struct ast_trans_pvt *writetrans; /*!< Write translation path */
> struct ast_trans_pvt *readtrans; /*!< Read translation path */
> int rawreadformat; /*!< Raw read format */
> int rawwriteformat; /*!< Raw write format */
>
> and the proper usage of ast_set_read/write_format.
>
> Can somebody please describe the meaning of these channel members for a
> channel driver?
>
> Who should write to these channel members - the core or the channel
> driver? What does "read" mean - the channel reads from the core or the
> core reads from the channel?
>
> What's the difference between readformat and rawreadformat?
>
> E.g. a channel driver receives RTP packets with G.729 and forwards them
> to the core. Further, the channel driver wants to receive the voice
> frames in format alaw. Which channel members have to be set by the
> channel driver? Does the channel driver have to set the channel members
> directly or is this done with the ast_set_read/write_format() functions?
> What is the role of nativeformats in this case?
>
> thanks
> klaus
>
>
> _______________________________________________
> --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
More information about the asterisk-dev
mailing list