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. -- Matthew Fredrickson Software/Firmware Engineer Digium, Inc. _______________________________________________ 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
