[asterisk-dev] AST_FRAME_DIGITAL

[Matthew Fredrickson]

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.