[asterisk-dev] AST_FRAME_DIGITAL

[Sergio Garcia Murillo]

----- Original Message ----- 
From: "Matthew Fredrickson" <creslin at digium.com>
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Sent: Thursday, September 13, 2007 8:45 PM
Subject: Re: [asterisk-dev] AST_FRAME_DIGITAL


> Tilghman Lesher wrote:
> > On Wednesday 12 September 2007 10:45:26 Klaus Darilion wrote:
> >> Russell Bryant schrieb:
> >>> Christian wrote:
> >>>> I vote for AST_FRAME_DIGITAL too! I think i suggested that about over
> >>>> one year already..  It would be very useful to transport Digital Data
> >>>> like HDLC Frames which might occur in the media channel of chan_zap
and
> >>>> chan_misdn. At the moment such data would be sent with
AST_FRAME_VOICE
> >>>> which is not appropriate.
> >>> I will not argue that such a thing would not be useful.  However, I
want
> >>> to be _very_ strict about what it could be used for.  In the context
of
> >>> this thread, where the stream is actually voice and video, it is
> >>> absolutely not appropriate.
> >> What about another way to implement DIGITAL calls inside Asterisk. I
> >> could add a voice codec called AST_FORMAT_DIGITAL. As there will be no
> >> codec_digital Asterisk does only support pass through of
> >> AST_FORMAT_DIGITAL. This would be a compromise - no new frame type -
> >> just a certain codec to prevent that digital calls will be treated as
> >> u/alaw with potential transcoding problems.
> >
> > What is so wrong with demuxing the frames into their component frames?
I
> > would think that this process should take very little CPU, as you are
doing
> > zero transcoding, just separating packets of data.  Once you starting
dealing
> > with component frames, then we can start discussing ways to ensure that
you
> > get the raw component frames, never any attempts to transcode them.
> >
>
> I can see their point though.  Why do it when you don't have to.  I
> think my propsed AST_FORMAT_DIGITAL with different subclasses that can
> be transcoded using an extension to the translation core would solve all
> of these issues.


I completelly agree with you.
In fact the idea of your translator is what I tried to implement, but the
only
posibility I have was using the convination of an application an a local
channel.

To change the focus of the discussion, let's use another example, the
transcoder
application I write for video transcoding

http://sip.fontventa.com/content/view/30/57/

What I needed was to plug the transcoder in the channel between the two
endpoints,
so it was able to resize, transcode and trasnrate the video in each
direction.
So the solution I found was handling the channel in an application, but i
still needed to
reach the other party so i just create a new local channel and insert it
back again into
the asterisk pbx core.
So efectivelly i have stuck my application in the middle of a channel and it
still can
be handled in the dialplan.

The example below use it in conjuction with app_rtsp to be able to transcode
the mpeg4
video to h263

 [default]
exten => 201,1,Answer
exten =>
201,2,transcode(,s at camera,h263 at qcif/fps=10/kb=52/qmin=4/qmax=12/gs=50)
exten => 201,3,HangUp

[camera] exten => s,1,Answer
exten => s,2,rtsp(http://192.168.1.2/live.sdp)
exten => s,3,HangUp

So what you get is something like that:

channel=>trascoder=>local channel=> end point [app_rtsp/dial/...]

It's not the perfect solution but it behaves very simillar to the translator
idea, but you have
to use two channel (or more)  to implement it.

Also app_h324m use the same principle, you can even compose them for example

channel=>h324m_gw=>local channel=>transcoder=>local channel =>end point
[app_rtsp/dial/...]

The good way would be implement it dinamically and in vertical:

             transcoder
            ------------
            h324m_gw
            ------------
               [filters]
channel ========> end point [app_rtsp/dial/...]

The good thing of it is that you could insert your filter at any point of
the pile, and remove it
if you want.

Other uses for this technique would be echo cancellation, faxing, volume
adjustment, music on
hold, etc...


Best regards
Sergio