[asterisk-dev] AST_FRAME_DIGITAL

[Steven Critchfield]

On Mon, 2007-09-17 at 18:45 +0200, Klaus Darilion wrote:
> Thus, to summarize:
> 
> I see two options for adding digital/3G video types to Asterisk:
> 
> 1. AST_FORMAT_H223. This will only be used if the incoming call is 
> digital AND signals H.223&H.245.
> 
> + with this option it is for sure that the digital call is a 3G video call
> - there is no standardized way to forward this to other Asterisk server

With a format, you should be able to transfer it via IAX to the far side
asterisk server even if asterisk doesn't know how to deal with the
format itself.

> - does not help us handling other non-3G-video calls

That is a short sighted comment. It actually gets us closer to handling
it as it gets the data up to asterisk in a manner that asterisk knows
what it is holding. Later code practice would be to decode the H223 and
reintroduce the information into asterisk as the component pieces.

> 2. AST_FORMAT_CLEARMODE. This will be used for any incoming digital 
> call. Thus, from the frametype it is not deriveable which application is 
> inside the CLEARMODE.
> 
> + by adding CLEARMODE to rtp.c we have a standard conform way to forward 
> digital calls to other Asterisk servers

This could be done in rtp without a that specific format. Essentially
you are trying to argue a channel driver specific implementation into
the asterisk core way of doing things instead of being agnostic to the
channel drivers.

> + more generic and flexible

More generic yes. Flexible? I don't think so. The only flexibility is
that you get asterisk to ignore the data and pass it along. This doesn't
let you take advantage of the large amount of functionality in asterisk
to handle the call without jumping through some major hurdles. 

> - requires a little bit more dialplan logic to detect 3G video calls
> 
> Thus, is there a chance to get AST_FORMAT_CLEARMODE into Asterisk (which 
> I would prefer instead of AST_FORMAT_H223)?

I think with those modifications, you are about evened up on your
pro/cons for now, and the format_223 would be the long term winner.
-- 
Steven Critchfield <critch at basesys.com>