[asterisk-dev] AST_FRAME_DIGITAL

[Tilghman Lesher]

On Saturday 08 September 2007 06:57:11 Sergio Garcia Murillo wrote:
> ----- Original Message -----
> From: "Tilghman Lesher" <tilghman at mail.jeffandtilghman.com>
> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> Sent: Friday, September 07, 2007 3:53 PM
> Subject: Re: [asterisk-dev] AST_FRAME_DIGITAL
>
> > On Friday 07 September 2007 05:50:37 Klaus Darilion wrote:
> > > 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?
> >
> > If you don't want Asterisk to handle that data at all, why are
> > you queuing it up in the first place?  Seems like refusing to
> > queue the frame at all solves the issue brilliantly.
>
> I think you have not undertood the problem. We want asterisk to handle
> the frames but without processing them, so no transcoding, echo
> cancelling, etc, is done on it.  Just transport the data from one end to
> the other end without even knowing/caring what it's transporting.

Okay, so you realize that the frame will only be transmitted from your channel
type to your channel type and every other channel type will ignore the frame,
right?  And that should happen only with a native bridge, which means that an
echo canceller or transcoder will only be in effect if your native bridge
implements it.

Every other channel type that cannot interpret the data will simply ignore
any such frame (having no idea what to do with it).  If you don't have a
native bridge, that's probably what you need, not a new frame type.

-- 
Tilghman