Russell Bryant schrieb: > I can tell you right now that you will not be able to convince me that we > should > add an opaque frame type for this situation. It is completely against the > Asterisk architecture. As you said, the stream you are handling is in fact > voice and video. Asterisk has explicit handling for voice and video, and the > streams should be passed into Asterisk using those frame types.
Hi Russel! A simple scenario: A Asterisk server is used as PBX and is connected to the PSTN with a PRI (zap). Further, it has a BRI card to connect to in-house BRI devices. Asterisk bridges calls between BRI and PRI, and sometimes this is a digital call. As digital calls do not have proper treating yet, it will happen that Asterisk thinks that PRI uses ulaw and BRI uses alaw and starts transcoding - which is a very bad thing for digital connections. Thus, why do we have a AST_FRAME_IMAGE? Why is IMAGE not treated as VOICE? Obviously because Asterisk would transcode and the image is broken - the same reason why I like AST_FRAME_DIGITAL. Maybe I do not need AST_FRAME_DIGITAL at all but could use AST_FRAME_IMAGE too - but I do not know how Asterisk handles images and maybe someday a feature is added to resize images and then it aagin would break digital connections. Thus I think Asterisk should have a AST_FRAME_DIGITAL for bridging any data without interpretation. regards klaus _______________________________________________ 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
