Paul,
Do you mean RFC 2508?
In any case, Robert's point is indeed valid. This is where having a
specialize GW that multiplexes the RTP streams for delivery over the
long-haul is something practical.
Perhaps we could take that up as a work item with SG16? It would be
reasonable to specify how such an Gateway might function in order to trunk a
large number of active calls over long distance. Anyone interested in such
a work item?
Paul
----- Original Message -----
From: "Paul Long" <plong@packetizer.com>
To: <h323forum@mail.imtc.org>
Sent: Monday, December 16, 2002 7:49 PM
Subject: [h323forum] Re: Codec negotiation question
Robert,
Excellent point. I hadn't thought of that. I wonder what happened to
cRTP. Anybody know? That would sure help.
Paul
On Mon, 16 Dec 2002 12:53:34 -0500
"Paul Long" <plong@packetizer.com> wrote:
I know lots of folks would like a means of expressing exact
packetization, but isn't the solution trivial? All you need is a
FIFO and a few lines of code to re-packetize according to any
internal
requirements. Just write incoming frames regardless of size, e.g.,
30fpp, to the FIFO, and read whatever size frames you want, e.g.,
80fpp
from the FIFO (only read if there are at least X fpp in the FIFO).
DSP hardware is not the only reason for wanting to have the remote
endpoint send larger packets. We have many clients on long haul
internet
links (300ms+ ping times), often with a slow tail circuit (ISDN or
even
modem) and you REALLY want the other end to send more than one G.723.1
frame per packet to reduce the significant overhead that there is in
RTP.
It is unfortunate but true that there is no way of expressing a
minimum
acceptable number of frames per packet.
Regards,
Chris
Davide,
There is nothing in the standard that requires the acceptance
of an
OLC
or precludes terminating the call for any reason whatsoever so
both
EPs
are technically compliant.
Packetization in TCS and OLC expresses the _maximum_ frames per
Paul Long wrote:
packet,
but several vendors don't understand this simple concept and
continue
to produce products that expect an exact packetization. There
is a
good
chance that that is why EP A is rejecting the OLC. It wants the
channel
opened at exactly 80fpp, although there is no way to express
small
the
this
in
H.323. IMO, if this is the reason, that product is broken.
Paul
Hi all,
I have a question about a codec negotiation.
During H.245 negotiation, endpoint A (master) exports g711A-law
with
packetization 80, endpoint B (slave) exports g711A-law with
packetization 30. After that, endpoint A opens a channel with
packetization = 20 ms. Endpoint B acknoledges the OLC and tries
to
open
a channel with packetization = 30 ms.
Here Endpoint A rejects the OLC and the call is disengaged.
Does anybody can tell me which endpoint dosn't behave according
to
the H323 standard?
Thank you in advance.
Davide
---
You are currently subscribed to h323forum as: cwp@isdn-
comms.co.uk
To unsubscribe send a blank email to %%email.unsub%%
--
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
---
You are currently subscribed to h323forum as: equival@equival.com.au
To unsubscribe send a blank email to %%email.unsub%%
----------
Robert Jongbloed Equivalence Pty. Ltd.
Architect Open Phone Abstraction Library (OPAL) & OpenH323
Open Source Telecommunication Protocol Libraries
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quicknet's revolutionary MicroTelco Services offers
LOW WORLDWIDE RATES ANY TIME OF THE DAY with
No monthly fees! No monthly minimums! No connection fees!
US rates as low as 2.9 cents a minute! To see more rates,
visit www.microtelco.com
****LIVE VIDEO CONFERENCE NOW AVAILABLE*****
CUseeMe v5.0 software is an affordable easy-to-use software
application providing live visual communication between friends,
family and colleagues worldwide. To learn more, visit,
www.cuseemeworld.com
---
You are currently subscribed to h323forum as: paulej@packetizer.com
To unsubscribe send a blank email to leave-h323forum-27407I@mail.imtc.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@lists.intel.com
Paul E. Jones