[asterisk-dev] AST_FRAME_DIGITAL

[Tilghman Lesher]

On Thursday 13 September 2007 04:52:20 Klaus Darilion wrote:
> Russell Bryant schrieb:
> > Klaus Darilion wrote:
> >> Thus, why do we have a AST_FRAME_IMAGE? Why is IMAGE not treated as
> >> VOICE? Obviously because Asterisk would transcode and the image is
> >> broken - the same reason why I like AST_FRAME_DIGITAL.
> >
> > I don't think that comparing IMAGE to DIGITAL is a valid comparison.  I
> > can look at the image in an IMAGE frame.  I can listen to the audio in a
> > VOICE frame. But what about DIGITAL?  How is Asterisk supposed to
> > interpret a DIGITAL frame?
>
> That's the whole point - it should not interpret it at all.

In that case, you should not queue the frame to Asterisk.  Period.  If you are
telling me that Asterisk should not know anything about the contents, then
it will not handle that frame for any reason whatsoever.

I don't think, however, that that is what you want.  You want, essentially,
Asterisk to become a carrier of proprietary information that it just blindly
passes on to whatever is on the other side.  That does not jibe with the
model of ANY of the existing channel drivers in Asterisk today.  EVERYTHING
must know _what_ it is that it is carrying, in order to properly queue it to
the other side.  We don't support unknown codecs, we don't support unknown
video types, and we certainly do not support "here's this packet of unknown
information, just pass it blindly".

Asterisk is an intelligent application, and you're trying to treat it like a
dumb pipe.

> >  It is completely arbitrary.
> >
> > I'm not sure how many ways I can say this.  The stream you're dealing
> > with is _voice_ and _video_, both of which have explicit frame types in
> > Asterisk.  The stream should be decoded and passed into Asterisk using
> > this method.  There are good reasons for it being this way.  It is the
> > whole reason that Asterisk is able to bridge calls between completely
> > different technologies - ISDN to IAX2 or whatever the case may be. 
> > Furthermore, by explicitly using the voice and video frame types,
> > Asterisk is able to handle transcoding if necessary.  If both ends of the
> > call are set up to use the same audio and video formats, Asterisk will
> > not touch the contents.
>
> Thus, if I have 3G video call bridged by Asterisk from chan_zap to
> chan_misdn Asterisk should decode the 3G video and then reencode it -
> does not sound well engineered.
>
> If Asterisk bridges a G4 fax call from chan_zap to chan_misdn Asterisk
> should decode the G4 fax into in an IMAGE and the reencode it to G4?

Probably so.  From the side of chan_zap, it does not know that it will be
talking to chan_misdn.  It could just as easily be talking to chan_sip, which
needs the data in a completely different format, which is why it needs to
be in an image format, which can then be re-encoded as T.38 on SIP.

-- 
Tilghman