[asterisk-dev] AST_FRAME_DIGITAL

[Klaus Darilion]

Matthew Fredrickson wrote:
> Klaus Darilion wrote:
>> Russell Bryant schrieb:
>>> Matthew Fredrickson wrote:
>>>>> So, if I get it right - there is no need to introduce AST_FRAME_DIGITAL 
>>>>> as it is already there (but named AST_FRAME_MODEM)?
>>>> Yes, basically.  Look in include/frame.h in asterisk 1.4 sources.  There 
>>>> are already subclasses defined for T38 and V150.  I'm thinking that an 
>>>> extension to this frametype would give us what we want.  Then an 
>>>> extension to the translator architecture so that we can make translators 
>>>> for frames other than AST_FRAME_VOICE.
> 
> <snip>
> 
>>> AST_FRAME_MODEM or DIGITAL or whatever is not going to work without a lot of
>>> extra effort.  However, as has been suggested, creating an AST_FORMAT_H223 would
>>> do it.  It's a hack, but you'd have to put the data in an AST_FRAME_VOICE with a
>>> subclass of AST_FORMAT_H223.  In that case, Asterisk would happily pass it
>>> through without transcoding it, since it has no codec module to handle it.
>>>
>>> I don't want to keep this feature from being available to users of Asterisk, I
>>> just want to make sure it is done the most flexible way.
>> This solution is what I am currently working on. Nevertheless I would
>> call it AST_FORMAT_DIGITAL to be more generic and allow bridging of
>> non-h223 calls too (e.g. proprietary data services). The differentiation
>> can be done in the dialplan by analyzing for example user information 
>> layer 1 (e.g. with this patch: http://bugs.digium.com/view.php?id=10217)
> 
> I think that I agree with Russell and Tilghman that having an opaque 
> AST_FORMAT_DIGITAL is ugly for this purpose, especially if it requires 
> analysis in the dialplan for it to even work correctly.  If we were 
> talking about true ISDN data calls, it might be appropriate, but for 
> purposes of passing H223 content through Asterisk, I think that this is 
> the *wrong* approach.

Ok. I will make it AST_FORMAT_H223. My first version will send 
AST_FORMAT_H223 as AST_FRAME_VOICE (this is not very complicated) and 
works fine with current translation core. Further versions should send 
AST_FORMAT_H223 inside AST_FRAME_MODEM/DIGITAL/RAW/OPAQUE/TOBEDEFINED 
when the translation framework is able to handle it.

regards
klaus

> 
> Nothing like that should be considered an opaque type by the core.  True 
> data should be, but when we have audio and video involved like there is 
> in H223, there should be a way that (if necessary) it can be decoded and 
> passed to non ISDN channel types.
>