FastStart and payload size

[Chris Wayman Purvis]

Francois, Paul,

For the cost of no more than half a round-trip time you could forget about
fastStart and do everything using tunnelled H.245 (which was always the better
"fast starting" idea, and was originally put up as an alternative to what
you're describing as "half-baked" - don't ask ME why both ended up getting
standardized!).  I believe you can tunnel TCS & MSDet in Setup, and TCS,
MSDetAck and OLC into CallProceeding - stick an OLC or two into a (caller to
callee) Facility message and you're quite likely to have everything ready to go
by the time Connect happens!
If we can make this standard practice we might even (with luck) eventually be
able to deprecate fastStart rather than forever patching it...  Except that
then certain people will get upSET...  (Sorry: couldn't resist that one!)

Regards,
Chris


> Francois Audet wrote:
>
> Yep, you are right: it has always been the maximum size.
> The difference is that if you have capability negotiation before
> (non fast-start), it is understood that you would attempt to indicate
> a larger maximum size in the OpenLogicalChannel than what was indicated
> in the terminal capability negotiation.
>
> Also, I would guess that "fixed sized" payload (let say in
> increments of 10 ms) may be less demanding on the hardware or DSP.
>
> > Exactly, the caller has to make a series of educated guesses regarding
> > outgoing caps, based on the implementor's experience and common sense.
> >
> > (Wait a minute. Let me get on my high horse... okay, I'm on... :-)
> > These fields have always indicated _maximum_ framing. For
> > example, if I
> > indicate that I can receive packets containing as many as 20
> > frames per
> > packet (for G.711, a frame happens to be 1ms in duration),
> > that means you
> > can send me packets containing 1, 20, 10, 2, 15, 8, etc.,
> > frames. Mix and
> > match. Put a different number of frames in each successive
> > packet if you
> > want to. It doesn't matter. The _only_ constraint is that no
> > packet may
> > contain more than 20 frames. It has never meant that you can
> > only send me 20
> > frames per packet for each and every packet, which for G.711
> > would be 20ms
> > packets all the time. However, several vendors apparently have
> > "extra-normative" technical constraints that they must deal
> > with regarding
> > packet size, i.e., DSPs that require being fed chunks of
> > fixed-size audio,
> > e.g., 20ms packets. But there is no way in H.245 and
> > therefore H.323 to
> > indicate a fixed-size packet. These vendors should either
> > "fix" their DSPs
> > or perform re-framing between transport and decoder. In our
> > software-only
> > implementation, we have a FIFO into which we shove all incoming audio
> > frames. Once frames are installed in the FIFO, it doesn't
> > matter where the
> > packet boundary was. The decoder just processes frames in the
> > order they
> > were received. I'm sure that there are really good technical
> > reasons why
> > some implementations require fixed-size audio packets. Based
> > on our perhaps
> > too simplistic implementation, however, this has always puzzled me.
> >
> > Paul Long
> > Smith Micro Software, Inc.
> >

--
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
Phone: +44 1344 899 007
Fax:   +44 1344 899 001