[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