[asterisk-dev] AST_FRAME_DIGITAL

[Klaus Darilion]

Tilghman Lesher schrieb:
> 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? 

There is nothing wrong with it. The question is: Where to demux a 
digital stream in the service (e.g. audio and video).

If you do it in the channel driver, you have to add it to all channel 
drivers. If you do it in an application you only have to do it once - 
and channel driver and the application can be developed independently - 
no dependencies.

regards
klaus

> 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.
>