[asterisk-dev] AST_FRAME_DIGITAL

[Steven Critchfield]

On Fri, 2007-09-14 at 17:15 +0200, Klaus Darilion wrote:
> 
> critch schrieb:
> > 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.

So let us go about this in an interim manner.

Modify the ISDN channel drivers to hand up
AST_FRAME_VOICE(AST_FORMAT_H223) from them to asterisk. Your application
could request format AST_FORMAT_H223 such that there is no translation
required. From here you continue your current development as you are.

The benefit here is that you get asterisk to the point of being able to
native bridge 3g calls, and you get to worry only about your app for now
while looking at how to get the translation layer to handle things
better in the future. 

Also when you request from your application the format AST_FORMAT_H223,
you can see if asterisk was able to handle the request. If the call
wasn't a H223 call, asterisk couln't get you a H223 format and you will
know you don't have the data you are looking for and can fail in a
predictable manner. 

For instance, you could pass all your incoming calls into your 3g video
application as a brute force detection this way. If your app gets 3g
video stream, then it handles it the way you intend to, else it exits
and allows the call to pass to the rest of your normal extension logic.

See how just a little effort yields lots of cool magic from the core
knowing what it is transfering around?
-- 
Steven Critchfield <critch at basesys.com>