[asterisk-dev] AST_FRAME_DIGITAL

[Sergio Garcia Murillo]

----- Original Message ----- 
From: "Tilghman Lesher" <tilghman at mail.jeffandtilghman.com>
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Sent: Saturday, September 08, 2007 4:35 PM
Subject: Re: [asterisk-dev] AST_FRAME_DIGITAL


> 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.

In fact the problem is when you want to transmit the data from a channel to
an application. The real case that we have to deal with is with h234m
(i.e. 3g  videocalls).
The call is received by the isdn channel (chan_zap in klaus case), but the
content
is a h223 multiplexed data carrying h245 negotiation data, h263 video and
amr
audio.
So the problem is, how do we implement a pseudo channel in top of that
channel?
We could have modified the chan_zap to decode it an directly output the
demuxed frames to asterisk. The problem is that appart of beeing
innecesarily
difficult I would have to patch each isdn channel not only chan_zap.
So what I decided to do is implement an application to receive the incomming
data
and demultiplex it into a new local psuedo channel.
The problem is that the data between the channel and the application is
neither
ALAW nor ULAW, or any other asterisk voice formats, and any conversion or
transformation done will  screw the data.

Best regards
Sergio Garcia