[asterisk-dev] AST_FRAME_DIGITAL

[Matthew Fredrickson]

Tilghman Lesher wrote:
> On Wednesday 12 September 2007 10:45:26 Klaus Darilion wrote:
>> Russell Bryant schrieb:
>>> Christian wrote:
>>>> I vote for AST_FRAME_DIGITAL too! I think i suggested that about over
>>>> one year already..  It would be very useful to transport Digital Data
>>>> like HDLC Frames which might occur in the media channel of chan_zap and
>>>> chan_misdn. At the moment such data would be sent with AST_FRAME_VOICE
>>>> which is not appropriate.
>>> I will not argue that such a thing would not be useful.  However, I want
>>> to be _very_ strict about what it could be used for.  In the context of
>>> this thread, where the stream is actually voice and video, it is
>>> absolutely not appropriate.
>> What about another way to implement DIGITAL calls inside Asterisk. I
>> could add a voice codec called AST_FORMAT_DIGITAL. As there will be no
>> codec_digital Asterisk does only support pass through of
>> AST_FORMAT_DIGITAL. This would be a compromise - no new frame type -
>> just a certain codec to prevent that digital calls will be treated as
>> u/alaw with potential transcoding problems.
> 
> What is so wrong with demuxing the frames into their component frames?  I
> would think that this process should take very little CPU, as you are doing
> zero transcoding, just separating packets of data.  Once you starting dealing
> with component frames, then we can start discussing ways to ensure that you
> get the raw component frames, never any attempts to transcode them.
> 

I can see their point though.  Why do it when you don't have to.  I 
think my propsed AST_FORMAT_DIGITAL with different subclasses that can 
be transcoded using an extension to the translation core would solve all 
of these issues.

-- 
Matthew Fredrickson
Software/Firmware Engineer
Digium, Inc.