[asterisk-dev] New frame type for IAX: AST_FRAME_RAW ?

[Tilghman Lesher]

On Wednesday 07 February 2007 06:57, Andrew Kohlsmith wrote:
> On Tuesday 06 February 2007 7:44 pm, Tilghman Lesher wrote:
> > And I'm saying that you shouldn't.  IAX (and any other intelligent
> > protocol) should always know what it is transporting.  It is not
> > acceptable to simply say that you're transporting "stuff".  It may not
> > know directly how to decode something (such as an image) and it may
> > not know the final destination.  But it should know _what_ that object
> > (that it is transporting) is.
>
> That seems awfully limiting; What is the difference between passing raw
> data and encoding raw data into audio frames and sending them through an
> IAX2 host?  If it's not the final destination and it doesn't have to
> transcode, it'll pass the data through without mangling it, or even without
> taking it apart to make sure the data is valid.
>
> How is this different?

It's different because the protocol knows that it is audio, with a subtype
indicating what codec was used.  It's also important to realize, as Tim
pointed out, that IAX has a retry mechanism only for certain bits of
information, not for most media frames (which travel inside mini frames).
Any particular audio frame may or may not reach its destination.  It's
important for maximum efficiency (which is part of the point of the protocol).

Depending upon the "stuff" encoded into a "raw" frame, that packet dropping
may or may not be catastrophic failure.  How do we know, if we have no idea
what's inside that frame?  How much of the "stuff" is time-sensitive?  Again,
we don't know.  If the packets arrived out of order, would that be a problem?
Don't know.  Do you see where this is going?  Do you see why all these
unknowns create a massive (unsolvable) problem?

Now compare that situation to one where we know what's inside those packets.
Okay, this frame is audio, encoded inside a mini-packet, if it doesn't get
through in time, we won't retransmit; next frame is a fax, so we decode it at
the endpoint and send the tiff through in full frames, so dropped packets
don't create a failure on the whole file.  Another frame is AOC, so that gets
encoded as an AOC IE inside a full frame, and so on.  Since we know what
each bit of information is, we can properly treat it according to the
appropriate rule, and we aren't left either dropping critical packets or
retransmitting packets that are irrelevant as they were past expiration
anyway.

-- 
Tilghman