[asterisk-dev] AST_FRAME_DIGITAL

[Sergio Garcia Murillo]

----- Original Message ----- 
From: "Russell Bryant" <russell at digium.com>
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Sent: Wednesday, September 12, 2007 9:03 PM
Subject: Re: [asterisk-dev] AST_FRAME_DIGITAL


> Tzafrir Cohen wrote:
> > One concern that Klaus raises and that you have not addressed is that
> > you might want to transfer the frames with minimal changes from one
> > channel type to another.
> >
> > How does this compare with RTP transport between various VoIP channels?
>
> If the two channels are of the same type, then the streams could be
transferred
> with minimal changes using a channel driver's native bridge function.  An
> equivalent example would be the various ways that chan_sip can do a native
> bridge.  If the RTP stream is still going through Asterisk, it can still
be
> native bridged with very minimal effort using the "packet to packet"
native
> bridging method.
>
> In the case of two different channel types, such as chan_zap to
chan_misdn, then
> I would need an example of what information could be lost, so that I can
see if
> we have a way to address it.  Frames already have a lot of information
encoded
> in them.  With a VOICE frame, for example, you have the frame data itself,
a
> subclass (the codec), and timestamp information.  I suspect that in the
video
> world, where things are much more complicated, there may be additional
> information that there is no room for.

Yes and no. Using the rtp analogy, you could bridge rtp data from one sip
channel
to a h323 channel without asterisk needing to undestand the content.
It's much clear in the streaming world, which a streaming server can for
example
stream ANY codec in a mp4 file without caring about the internal format of
the
frame. It's all about metadata.

>
> However, that gets into the discussion we had at the developer conference
> pointing out the fact that we need to come up with a much more rich method
of
> describing formats so that we have an easier time supporting things like
> wideband and video going forward.

I agree with you at this point. The underlying problem is that asterisk has
a fixed
frame/format architecture and it's not able of handling channel format
metadata
and don't even think about creating dinamically types.

I think that the videocaps branch should have a much better way of dealing
with
the AST_FRAME_DIGITAL discussion than the trunk version.


>
> Notes from that discussion at the devcon are here:
>
> http://lists.digium.com/pipermail/asterisk-dev/2007-May/027890.html

I think that it's cleared stated there:

1.f) Our new format model should handle some data formats (such as with
faxing) in addition to text, audio, and video.

1.h) We should make sure we refuse unknown types of media streams.  We
should certainly refuse transports that we don't know about.  Also, for
now we should refuse codecs that we don't know about.  However, in the
future, we should probably allow passthrough for codecs that we don't
know about.

I understand your reticence to implement the new digital format, I would
also,
the beneficts of doing it are much less than the problems that could arose
in the
transition.

Best regards.
Sergio