[asterisk-dev] AST_FRAME_DIGITAL

[Klaus Darilion]

critch schrieb:
> On Fri, 2007-09-14 at 13:41 +0200, Klaus Darilion wrote:
>> Russell Bryant schrieb:
> 
>>> ISDN H223 data -> chan_zap -> H223decoder to VOICE/VIDEO frames -> Asterisk core
>> Probably the difference isn't that much if the 324m_gw is stable. But 
>> for development it is much better to have it in a separate application. 
>> Further libh324m is GPL thus it can not be included in Asterisk channeö 
>> driver sources. But having a dedicated application it can be easily 
>> added to asterisk-addons for example.
> 
> Ahh, but it could still be an add-on with it being a transcoder module.
> 
> The patch to the channel drivers would only be tto the ones who could
> receive h223 itself. They would possibly mark the frames ast
> AST_FRAME_VOICE with a sub frame type as AST_FORMAT_H223. 

yes.

> At that point the data is into asterisk with minimal changes. And for

yes

> differing channels that could handle H223, they would be able to handle
> passing the data raw to each other. So asterisk should at that point be
> able to bridge a call from PRI to BRI without problems.

exactly.
> 
> The addon would then be a transcoder of H223 data to the demuxed
> audio/video/control frames using the library that is GPL licensed.
>
> This way is a lot more likely to get merged with the official releases
> as it is the asterisk way, and requires little changes to the core of
> the application.   

I agree. But extending the translation framework to translate 
AST_FRAME_VOICE(AST_FORMAT_H223) into AST_FRAME_VOICE(AST_FORMAT_AMR) 
and AST_FRAME_VIDEO(AST_FORMAT_H63_PLUS) is not easily done. Thus, to 
make 3G calls possible now I prefer the application, but if for example 
1.6 allows translation between frame types then the application should 
be migrated in to translation framework.

klaus