[asterisk-dev] AST_FRAME_DIGITAL

[Matthew Fredrickson]

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.

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.

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