[asterisk-dev] AST_FRAME_DIGITAL

[Sergio Garcia]

---------- Original Message ----------------------------------
From: Tim Panton <thp at westhawk.co.uk>
Date:  Thu, 13 Sep 2007 17:55:54 +0100

>
>On 13 Sep 2007, at 16:46, Sergio Garcia wrote:
>
>>
>>
>>
>> ---------- Original Message ----------------------------------
>> From: Tilghman Lesher <tilghman at mail.jeffandtilghman.com>
>> Reply-To: Asterisk Developers Mailing List <asterisk- 
>> dev at lists.digium.com>
>> Date:  Thu, 13 Sep 2007 07:53:14 -0500
>>
>>> On Thursday 13 September 2007 04:52:20 Klaus Darilion wrote:
>>>> Russell Bryant schrieb:
>>>>> Klaus Darilion wrote:
>>>>>> Thus, why do we have a AST_FRAME_IMAGE? Why is IMAGE not  
>>>>>> treated as
>>>>>> VOICE? Obviously because Asterisk would transcode and the image is
>>>>>> broken - the same reason why I like AST_FRAME_DIGITAL.
>>>>>
>>>>> I don't think that comparing IMAGE to DIGITAL is a valid  
>>>>> comparison.  I
>>>>> can look at the image in an IMAGE frame.  I can listen to the  
>>>>> audio in a
>>>>> VOICE frame. But what about DIGITAL?  How is Asterisk supposed to
>>>>> interpret a DIGITAL frame?
>>>>
>>>> That's the whole point - it should not interpret it at all.
>>>
>>> In that case, you should not queue the frame to Asterisk.   
>>> Period.  If you are
>>> telling me that Asterisk should not know anything about the  
>>> contents, then
>>> it will not handle that frame for any reason whatsoever.
>>
>> Sorry, to be rude.. but how the f*ck are you going to transfer the  
>> frame if you
>> don't queue it??? Does asterisk allows native bridging between  
>> different channels??
>
>Reinvite? - send the RTP stream from endpoint to endpoint ?

Reinvite in isdn, good.. 

>
>>
>>>
>>> I don't think, however, that that is what you want.  You want,  
>>> essentially,
>>> Asterisk to become a carrier of proprietary information that it  
>>> just blindly
>>> passes on to whatever is on the other side.  That does not jibe  
>>> with the
>>> model of ANY of the existing channel drivers in Asterisk today.   
>>> EVERYTHING
>>> must know _what_ it is that it is carrying, in order to properly  
>>> queue it to
>>> the other side.  We don't support unknown codecs, we don't support  
>>> unknown
>>> video types, and we certainly do not support "here's this packet  
>>> of unknown
>>> information, just pass it blindly".
>>>
>>> Asterisk is an intelligent application, and you're trying to treat  
>>> it like a
>>> dumb pipe.
>>
>> That's the problem, core pbx asterisk should be DUMB, the  
>> endopoints should know what to
>> do with the formats. It's something silly to have to patch asterisk  
>> to add a new
>> codec or just a video format!!!
>
>No it isn't. If you want a dumb engine, use something like SER.
>Asterisk's use-case is where you want features - voicemail, IVR,  
>meetme, monitoring
>or joining incompatible technologies eg: chan_skinny->chan_bluetooth  
>without
>batting an eyelid.

I just want an media agnostic core, .i.e. dumb in a way it doens't need
to know the format frame. I think that it was already explained in the
devcon link you sent yesterday.. I'll try to expose what i think in a later
mail so you can see that my intention is not really starting a flame war but
evolving asteirsk to handle better different multimedia escenarios.

Best reagards
Sergio