[asterisk-dev] AST_FRAME_DIGITAL

[Matthew Fredrickson]

Atis wrote:
> On 9/14/07, Matthew Fredrickson <creslin at digium.com> wrote:
>> Klaus Darilion wrote:
>>> Russell Bryant schrieb:
>>>> Matthew Fredrickson wrote:
>>>>>> So, if I get it right - there is no need to introduce AST_FRAME_DIGITAL
>>>>>> as it is already there (but named AST_FRAME_MODEM)?
>>>>> Yes, basically.  Look in include/frame.h in asterisk 1.4 sources.  There
>>>>> are already subclasses defined for T38 and V150.  I'm thinking that an
>>>>> extension to this frametype would give us what we want.  Then an
>>>>> extension to the translator architecture so that we can make translators
>>>>> for frames other than AST_FRAME_VOICE.
>> <snip>
>>
>>>> AST_FRAME_MODEM or DIGITAL or whatever is not going to work without a lot of
>>>> extra effort.  However, as has been suggested, creating an AST_FORMAT_H223 would
>>>> do it.  It's a hack, but you'd have to put the data in an AST_FRAME_VOICE with a
>>>> subclass of AST_FORMAT_H223.  In that case, Asterisk would happily pass it
>>>> through without transcoding it, since it has no codec module to handle it.
>>>>
>>>> I don't want to keep this feature from being available to users of Asterisk, I
>>>> just want to make sure it is done the most flexible way.
>>> This solution is what I am currently working on. Nevertheless I would
>>> call it AST_FORMAT_DIGITAL to be more generic and allow bridging of
>>> non-h223 calls too (e.g. proprietary data services). The differentiation
>>> can be done in the dialplan by analyzing for example user information
>>> layer 1 (e.g. with this patch: http://bugs.digium.com/view.php?id=10217)
>> I think that I agree with Russell and Tilghman that having an opaque
>> AST_FORMAT_DIGITAL is ugly for this purpose, especially if it requires
>> analysis in the dialplan for it to even work correctly.  If we were
>> talking about true ISDN data calls, it might be appropriate, but for
>> purposes of passing H223 content through Asterisk, I think that this is
>> the *wrong* approach.
>>
>> Nothing like that should be considered an opaque type by the core.  True
>> data should be, but when we have audio and video involved like there is
>> in H223, there should be a way that (if necessary) it can be decoded and
>> passed to non ISDN channel types.
> 
> Hi,
> 
> Another probably foolish question - i don't know anything about how
> the 3G video calls are made, but i suppose there aren't may different
> codecs right now. I'm just learning by this thread and my cell-phone -
> so i suppose there is currently only one combination - 3GP + AMR for
> videocalll - why just don't present it as separate codec for asterisk
> (even if it's presented as audio stream to asterisk - it doesn't have
> to know what's inside)? The same way as ulaw or gsm works - add it in
> format_3g and/or codec_3g. This way you could have regular 3GP files
> (with AMR audio i suppose), that could be played back with Playback().
> It would still be a separate module, and without dialplan mess. And
> linking to SIP calls would be done trough regular translator, that
> would separate audio/video streams.. Is it possible?

If you'll notice some of the other threads, that is what we are 
basically proposing.

-- 
Matthew Fredrickson
Software/Firmware Engineer
Digium, Inc.