[asterisk-dev] AST_FRAME_DIGITAL

[Sergio Garcia]

---------- Original Message ----------------------------------
From: Klaus Darilion <klaus.mailinglists at pernau.at>
Reply-To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Date:  Mon, 10 Sep 2007 10:53:02 +0200

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

Also, if we get into SIP, this would allow us to handle application media 
in SDPs used for msrp, file sharing, whiteboarding, etc.. 

BR
Sergio