[asterisk-dev] AST_FRAME_DIGITAL

[Atis]

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?

Regards,
Atis

-- 
Atis Lezdins,
IT Responsible of BEST Riga,
atis at BEST.eu.org
ICQ: 142239285
Skype: atis.lezdins
Cell Phone: +371 28806004 [Tele2, Latvia]
Work phone: +1 800 7502835 [Toll free, USA]
?BEST? -> www.BEST.eu.org