Klaus Darilion wrote: > Hi! > > I have some problems with digital zap calls (unrestricted digital data) > which gets transcoded by Asterisk. I think the most elegant fix would be > to add a new frame type AST_FRAME_DIGITAL which means that the data is > any digital data and Asterisk MUST NOT touch this data in any kind. > > What do you think about adding this to Asterisk and extend chan_zap to > use AST_FRAME_DIGITAL instead of AST_FRAME_VOICE for digital calls?
Alright, I'm replying at the top of this thread because I have read most of it, and don't see a logical spot to insert my personal comments about this. As the maintainer of libpri, libss7, and most of chan_zap, I hope that my voice will be taken with a balanced outlook on this. What Klaus asks for is not a bad thing, IMHO. Although FRAME_DIGITAL isn't quite the way I would do it, I think that avoiding the demultiplexing/remultiplexing of the ISDN audio/video stream whenever possible is a good idea. It is computationally unnecessary to do so, and I think that it is computationally expensive enough to not do it when you don't have to (between two ISDN channel types). An AST_FRAME_DIGITAL is one way to do it, but I think it is too opaque and a sloppy way to solve this problem. It does not take into account the various other complex audio/video combinations available in ISDN. An existing infrastructure which fits somewhat more closely to this problem is the translator architecture. A channel can advertise the capability of being able to pass H223 encapsulated data, and if both channels natively support that format it can be natively passed over, without any sort of reencapsulation. If the destination channel does not natively support H223 encapsulated data (or bearer capability, if you would like to look at it that way) then it can go through a translator to do demultiplexing for that channel. Any thoughts? -- 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
