[asterisk-dev] AST_FRAME_DIGITAL

[Sergio Garcia]

---------- Original Message ----------------------------------
From: Russell Bryant <russell at digium.com>
Reply-To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Date:  Thu, 13 Sep 2007 10:04:11 -0500

>Klaus Darilion wrote:
>> Thus, if I have 3G video call bridged by Asterisk from chan_zap to 
>> chan_misdn Asterisk should decode the 3G video and then reencode it - 
>> does not sound well engineered.
>> 
>> If Asterisk bridges a G4 fax call from chan_zap to chan_misdn Asterisk 
>> should decode the G4 fax into in an IMAGE and the reencode it to G4?
>
>If you don't, then you are really defeating the purpose of using Asterisk in the
>first place.  Let me list a few small examples that would work if you do break
>the stream down into voice and video frames, but will not work if you pass the
>stream through as raw.  There are countless more ...
>
>1) What if you want to monitor the call via ChanSpy?  Specifically, what if you
>want to monitor the call from a channel type that is not an ISDN channel?

Half point for ast_format_digital, what if you want to monitor the h223 data and
store it in a file so you can debug it after a crash?
Another half point for app_h324m, you can monitor the h223 data channel or the
local channel with the demuxed audio and video.


>
>2) What happens if one caller wants to transfer the other to a non-ISDN channel?

Full point to ast_frame_digital, I could use tdmoe or even SIP (i have already done)
to send the data to another asterisk box. Or you can choose to send the demuxed data
just as usual.

>
>3) What if you want to transfer the channels into a conference with other ISDN
>channels?  (Manager action redirect, for example)
>
>I understand your desire to make this work.  I can also appreciate you seeing
>the "easy way" to do it, and pushing that direction.  However, what I and
>Tilghman have been trying to do is push this more toward the "Asterisk way" of
>doing this.  Asterisk is designed to be a channel technology independent
>application.  That means, it does not matter if it is ISDN or SIP or whatever
>else, it all looks the same inside of Asterisk.  This lets us build features
>that will work across any type of call.  What you are proposing completely
>breaks this architecture.  So, for a little bit of extra work and minor effect
>on performance, you can make this fit into the Asterisk architecture, bridging
>3G ISDN voice and video calls to everything else that Asterisk has to offer.
>

What if it's already working our way?
What if our alternative just offer the same functionalities as your way and also
allows you to have more functionality?
What if the asterisk way is just incorrect (or not perfect) and we just want to 
help in fixing it?

Best regards
Sergio