[asterisk-dev] AST_FRAME_DIGITAL

[Klaus Darilion]

Olle E Johansson schrieb:
> 9 sep 2007 kl. 18.15 skrev Russell Bryant:
> 
>> Sergio Garcia Murillo wrote:
>>> Let me try to explain myself again, because it seems that you have  
>>> not
>>> undestood
>>> the issue yet.
>>> The data is NOT video, is h223 data, which is a multiplexed stream  
>>> that
>>> carries
>>> simultaniously audio,video and h245 control data. Once it's  
>>> processed by the
>>> application then you can extract video frames and audio frames  
>>> which can be
>>> correctly handled by asterisk.
>>> So if you don't want to create an opaque data type, then it will  
>>> be great if
>>> you
>>> create it's correct type that would be AST_FRAME_DIGITAL and it's  
>>> correct
>>> format AST_FORMAT_H223.
>>> Also if you want you could also include other digital formats, as for
>>> example
>>> AST_FORMAT_H320 (for isdn conferencing) that would be great.
>> I would prefer that this stream be decoded inside of the channel  
>> driver.  Then,
>> the audio and video should be sent into the core as AST_FRAME_VOICE  
>> and
>> AST_FRAME_VIDEO.  The control data should also be handled inside of  
>> the channel
>> driver, with some of the information passed into Asterisk using
>> AST_FRAME_CONTROL as appropriate.  This is how every channel driver  
>> works.
>>
> Yes, that has been my recommendation to Sergio and Ramtin, who both
> work with this topic in two different ways. Sergio in application space
> and Ramtin in the channel driver.
> 
> Adding channel logic in applications is not following Asterisk  
> architecture.
> We need to solve this either in chan_zap or libpri or both.

I strong disagree an that. Adding H223+H245 demultiplexing into chan_zap 
is the wrong place. The channel driver is used to establish the digitail 
call with channel technology (=ISDN). Then, inside this ISDN digital 
call there may be any application. In our case this is an 3G video call.

A 3G video call my be received with any ISDN technology. Thus, to stay 
with one of Asterisk main features (supports various of different 
hardware and technologies) we have to add this functionality to:
1. chan_zap
2. bristuff
3. chan_msidn
4. chan_visdn
5. chan_capi
(sorry if I have forgotten some ISDN channel drivers)

Further, IMO Asterisk should support data calls as well. E.g. in several 
scenarios a native transfer is not possible (e.g. an call from chan_zap 
to chan_capi) and data calls are used for several scenarios: 3G video, 
proprietary data applications, I think also G4 fax uses digital calls. 
This might be also interesting for chan_sip (e.g. Cisco and Patton 
supports "clear-channel" codecs too)

Thus, IMO the correct design is:
1. add AST_FRAME_DIGITAL to Asterisk core (very very simple)
2. add AST_FRAME_DIGITAL to channel drivers (this can be done step by 
step and expense depends on the channel driver design (chan_zap is PITA))

Now, Asterisk supports DATA calls forwarding.

Further, Asterisk applications can be written which handle this data 
calls. E.g. h324m_gw may handle AST_FRAME_DIGITAL and decodes into 
AST_FRAME_VOICE and AST_FRAME_VIDEO to interact with all standard 
Asterisk applications. You could for example also write a app_g4fax 
application.

As Sergio also said, there can be license issues which prevents adding 
3G video decoding to chan_zap. As application, the 3G application can be 
in asterisk-addons.

regards
klaus