[asterisk-dev] AST_FRAME_DIGITAL

[Matthew Fredrickson]

Klaus Darilion wrote:
> 
> 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.

I think that this can all be solved using the translator architecture. 
See my reply to the original message for more info.

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