[asterisk-dev] AST_FRAME_DIGITAL

[Klaus Darilion]

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.
> 
> I realize that this exists, but the question is for whether it makes sense to do
> so, when the steam itself is actually voice and video.  There is _a lot_ of code
> in Asterisk that expects audio and video to be handled in a certain way, and
> this is an extremely different way to approach it.  That is why I was trying to
> push it that direction.
> 
> Later on the tread, I see that there actually is a way to get the stream broken
> down into raw voice and video streams by running it through an application which
> creates a local channel back into asterisk.  I didn't know this before.  It's
> certainly very much different than how things are done anywhere else, but it's
> a clever solution.  Knowing that this piece of the puzzle is in place makes me
> much more comfortable with the method being proposed, but I don't think I'm
> convinced yet.  I wish I had understood all of the details of what existed at
> the beginning of all of this.  :)

I guess this was our fault too as we expected others to know the ongoing
work regarding h324m, but this was obviously a false expection.

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

> Humor me for a bit longer and help me understand why one way requires a lot more
> code in the channel drivers than the other.  In the proposed method, you are
> reading the data and stuffing them in H223 frames and passing them into
> Asterisk.  Now, if the code that the application is using to decode and encode
> the H223 data is put into a library, why is it really any more invasive to the
> channel drivers to do the decoding there?
> 
> ISDN H223 data -> chan_zap, put it into H223 frames -> Asterisk core
> 
> versus
> 
> 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.

regards
klaus