[asterisk-dev] AST_FRAME_DIGITAL

Tilghman Lesher tilghman at mail.jeffandtilghman.com
Wed Sep 12 19:05:22 CDT 2007

On Wednesday 12 September 2007 18:48:19 Sergio Garcia Murillo wrote:
> On Wednesday, September 12, 2007 8:15 PM, Russell Bryant wrote:
> > 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?  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.
> So basically you're telling me that if i want to bridge one video call
> from a pri with chan_zap to a bri with chan_misdn I should try another
> pbx because asterisk architecture cannot handle it?

No, basically, we're telling you that you should work within the architecture
of Asterisk to do that.  You're telling us that you don't want to comply with
the architectural constraints of the application.  Why you don't want to work
within the architecture is beyond me.  You'll save yourself a ton of hassle
later on when you want to bridge two channels which use different video sizes
and codecs, if you decode it at the channel layer and use the capabilities of
Asterisk to handle changing it into whatever is needed on the opposite side.

It is completely ridiculous to say that we're telling you that Asterisk can't
handle it, when we're telling you EXACTLY how Asterisk SHOULD handle it,
and you are steadfastly refusing to take that approach.


More information about the asterisk-dev mailing list