On 9/14/07, Matthew Fredrickson <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] ICQ: 142239285 Skype: atis.lezdins Cell Phone: +371 28806004 [Tele2, Latvia] Work phone: +1 800 7502835 [Toll free, USA] ?BEST? -> www.BEST.eu.org _______________________________________________ Sign up now for AstriCon 2007! September 25-28th. http://www.astricon.net/ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
