[asterisk-dev] AST_FRAME_DIGITAL

Tim Panton thp at westhawk.co.uk
Thu Sep 13 11:55:54 CDT 2007


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 ?

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

Tim.







More information about the asterisk-dev mailing list