Matthew Fredrickson 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.
Ok. I will make it AST_FORMAT_H223. My first version will send AST_FORMAT_H223 as AST_FRAME_VOICE (this is not very complicated) and works fine with current translation core. Further versions should send AST_FORMAT_H223 inside AST_FRAME_MODEM/DIGITAL/RAW/OPAQUE/TOBEDEFINED when the translation framework is able to handle it. regards klaus > > 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. > _______________________________________________ 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
