aLaw, uLaw Kompression Source Code
liebich
Does anybody know by chance a location to find some aLaw, uLaw related
stuff? Describtions, Manuals ore even Source Code?
aLaw and uLaw is used in ISDN to compress PCM (Pulse Code Modulation)
data of voice/fax gr.3 telephony.
Walter
jeffrey...@attws.com
In article <4l4unf$2b...@news-s01.ny.us.ibm.net>, writes:
Actually, A-law is used in 24 channel countries such as in North America
and mu-law is used in 30 channel countries such as in Europe. The "data
of voice/fax gr.3 telephony" is COMPANDED by A/mu-law, not COMPRESSED.
Companding is the act of quantizing the amplitude of an analog signal.
A-law uses 13 segments and mu-law 7 segments to linearly approximate
the amplitude for PCM encoding.
The book I recommend is Roger Freeman's TELECOMMUNICATION SYSTEM ENGINEERING
2nd Edition 1989 ISBN 0-471-63423-9. See pages 386 and 387.
Jeffrey Rhodes at jeffrey...@attws.com
ps. You need something like MCELP to actually compress a voice circuit
from 64kbps to something like 8kbps and then back to 64kbps. ADPCM can
be used (but adds delay characteristics) for compression from 64kbps to
32kbps back to 64kbps and this potentially can degrade a previously
MCELPed signal. I recommend BC=Speech to indicate a bear channel request
for NO FURTHER DIGITAL SIGNAL PROCESSING and BC=3.1KHz Audio to indicate
that it is OK (acceptable) to use further digital signal processing such
as compression. Yes, I know I am shouting, maybe the world will get this
way some day. For calls initiated from AT&T's cellular network, I am
championing this position within AT&T's entire ISUP signaling network.
jeffrey...@attws.com
Whoops, I meant to say A-law is for 30 channel countries, mu-law is for
24 channel countries.
A DS1 transmission signal can either be 1.5Mbps (24 channels) or
2Mbps (30 digital voice channels plus 2 others, one of which can be
digital voice when ISUP signaling is used or one of which can be
in-band non-ISUP signaling).
jcr
Laurence V. Marks
>
>In article <4l4unf$2b...@news-s01.ny.us.ibm.net>, writes:
>
>for NO FURTHER DIGITAL SIGNAL PROCESSING and BC=3.1KHz Audio to indicate
>that it is OK (acceptable) to use further digital signal processing such
>as compression.
Jeffrey, you've got that backwards. I am sure the current recommendations
define:
BC=3.1 KHz Audio ==> no lossy compression (e.g., modem data)
BC=Speech==> Lossy compression permitted (e.g., Voice)
I don't remember if this is per ITU-T, or ATA, but can look if it's important
to you.
Laurence V. Marks
IBM Corp. - Research Triangle Park, NC
John Powell
snip
>MCELPed signal. I recommend BC=Speech to indicate a bear channel request
>for NO FURTHER DIGITAL SIGNAL PROCESSING and BC=3.1KHz Audio to indicate
>that it is OK (acceptable) to use further digital signal processing such
>way some day. For calls initiated from AT&T's cellular network, I am
>championing this position within AT&T's entire ISUP signaling network.
Jeffrey,
Unless I am misunderstanding something, this is the opposite of what I
understood to be the recommendation. For example, DOSBS is almost
always done over 3.1K (which would assume no processing of the
signal). Also, most ISDN devices that are capable of analog emulation
set their BC as 3.1K for modem calls intentionally to avoid
processing.
You obviously know a lot more about this than I do. But the names
themselves (speech and 3.1K) would seem to suggest the opposite of
what you think ought to be done.
Are my assumptions correct based on the current interpretations of the
voice BCs (or am I off my rocker)?
Why do you think this should be changed? Unless there is a really
good technical reason for changing, the implications of how that would
affect current CPE operation is significant and perhaps not worth the
benefits.
I want to understand this concept, and why you think the current model
is flawed. Any enlightenment is appreciated.
JP
Robert Blackshaw
>jeffrey...@attws.com wrote:
>snip
>>MCELPed signal. I recommend BC=Speech to indicate a bear channel request
>>for NO FURTHER DIGITAL SIGNAL PROCESSING and BC=3.1KHz Audio to indicate
>>that it is OK (acceptable) to use further digital signal processing such
>>as compression. Yes, I know I am shouting, maybe the world will get this
>>way some day. For calls initiated from AT&T's cellular network, I am
>>championing this position within AT&T's entire ISUP signaling network.
>Jeffrey,
>Unless I am misunderstanding something, this is the opposite of what I
>understood to be the recommendation. For example, DOSBS is almost
>always done over 3.1K (which would assume no processing of the
>signal). Also, most ISDN devices that are capable of analog emulation
>set their BC as 3.1K for modem calls intentionally to avoid
>processing.
You are right. When a user requests speech he/she will get "speech",
which might include 32kbit/s ADPCM and even analog if the LEC
runs out of digital trunks. If the user requests 3.1kHz he/she is
telling the LEC that this connection is for an analog modem and
this restricts the use of analog or even 32kbit/s ADPCM (although
ADPCM is "supposed" to work with some modems.
>You obviously know a lot more about this than I do. But the names
>themselves (speech and 3.1K) would seem to suggest the opposite of
>what you think ought to be done.
>Are my assumptions correct based on the current interpretations of the
>voice BCs (or am I off my rocker)?
Correct.
>Why do you think this should be changed? Unless there is a really
>good technical reason for changing, the implications of how that would
>affect current CPE operation is significant and perhaps not worth the
>benefits.
>I want to understand this concept, and why you think the current model
>is flawed. Any enlightenment is appreciated.
>JP
Bob
Opinions expressed are those of the author and are copyrighted
RB & Associates - Consultants in Multimedia Teleconferencing
Stefan Uhlemann
>In article <4l4unf$2b...@news-s01.ny.us.ibm.net>, writes:
>> From: liebich (Walter Liebich) lie...@ibm.net
>> Newsgroups: comp.dcom.isdn
>> Hy,
>>
>> Does anybody know by chance a location to find some aLaw, uLaw related
>> stuff? Describtions, Manuals ore even Source Code?
>>
>> aLaw and uLaw is used in ISDN to compress PCM (Pulse Code Modulation)
>> data of voice/fax gr.3 telephony.
>>
>> Walter
>>
A-Law and mu-law is defined in the
CCITT (ITU-T) recommendation G.711.
It's not very difficult to implement in source code...
Regards
- Stefan U. -
==================================================================================
Name: Stefan Uhlemann
Org.: Siemens HL -----> I'm talking for myself only <------
Email: stefan....@p52.mch2.siemens.scn.dbp.de
(you can try this one as well:)
/c=de/a=dbp/p=scn/o=siemens/ou=mch2/ou2=p52/s=uhlemann/g=stefan/@x400.scn.de
==================================================================================
Justin Medlock
> jeffrey...@attws.com wrote:
> snip
> >MCELPed signal. I recommend BC=Speech to indicate a bear channel request
> >for NO FURTHER DIGITAL SIGNAL PROCESSING and BC=3.1KHz Audio to indicate
> >that it is OK (acceptable) to use further digital signal processing such
> >as compression. Yes, I know I am shouting, maybe the world will get this
> >way some day. For calls initiated from AT&T's cellular network, I am
> >championing this position within AT&T's entire ISUP signaling network.
> Jeffrey,
> Unless I am misunderstanding something, this is the opposite of what I
> understood to be the recommendation. For example, DOSBS is almost
> always done over 3.1K (which would assume no processing of the
> signal). Also, most ISDN devices that are capable of analog emulation
> set their BC as 3.1K for modem calls intentionally to avoid
> processing.
I've taken the following definitions from Bellcore SR-NWT-001953,
"Generic Guidelines for ISDN Terminal Equipment on Basic Access
Interfaces" and I think Bellcore agrees with you (well, so do I).
SPEECH
======
The essential characteristic is that the network may employ
processing techniques appropriate for speech, such as 4-wire
analog transmission, low bit-rate voice encoding, and time
assignment speech interpolation. Thus, bit integrity is not
assured. Conversion from m-law to A-law would be provided as
appropriate between networks. Performance of voiceband modems is
not guaranteed.
3.1kHz Audio
============
Transmission processes specific to speech, such as time
assignment speech interpolation and low bit-rate voice encoding,
are prohibited, but 4-wire analog transmission may be permitted.
Conversion from m-law to A-law would be provided as appropriate
between networks. The use of voiceband modems and group I, II,
III facsimile devices is intended.
UDI(64kbps clear)
=================
The essential characteristic of the circuit-mode Unrestricted
Digital Information (UDI) bearer service is that the received bit
stream is identical (within performance limitations) to the
transmitted stream at the user-network interface. Conversion
from m-law to A-law would not be provided at the internetwork
points between m-law and A-law countries.
UDI(56kbps)
===========
Some networks (North American) may support 56-kbps digital
information transfer capability between exchanges. Rate adaption
from a lower rate (e.g. 56kbps) to 64kbps will be provided by
user equipment. Rate adaption is defined in ITU-T Recommendation
I.463 and ensures that the all zero octet is not transmitted.
Conversion from m-law to A-law would not be provided at the
internetwork points between m-law and A-law countries.
justin
jeffrey...@attws.com
John,
We are naive to read the standards and then conclude that the ISUP
carriers' networks route BC=Speech any differently than BC=3.1KHz Audio.
In the example that you cite where an ISDN device emulates an analog
modem, it is the modem tones after answer and routing has been completed
that disable speech processing, not the BC request. If you were a LEC
and your customers were calling long distance, wouldn't you want to tell
the long distance carrier that every call was BC=3.1KHz, so that your
customer could avoid compression? When the LEC has to compete for a
customer base will they continue to send BC=Speech which might result
in a call that is perceived to be inferior by the LEC's customer?
Has anyone ever made an analog modem call across the ocean at 28.8kbps?
If so, they were lucky to get an uncompressed trunk and I dare say it
wouldn't matter whether the call started as BC=Speech or BC=3.1KHZ.
I suspect the reason all my intercontinental V.32 modem calls from
the US are always at less than optimal bps is because they are
compressed just like any other "voice" call. The BC=3.1KHz doesn't
get more bandwidth than a BC=Speech call, unless the call actually
turns out to be a modem or fax, and the TASM circuits "hear" a modem
tone to allocate 40Kbps instead of 32Kbps after the call is answered.
TASM will do this for modem/fax calls that come in as BC=Speech, too
(I think).
We have Bellcore to thank for the confusion on the use of these two
bearer channel requests. Bellcore recommends converting all incoming
non-ISUP borders to BC=3.1KHz (I guess just in case a modem/fax is
calling). Bellcore's work is distorted to make LECs happy (LECs fund
their operations) and has little to offer long distance carriers.
Maybe Bellcore will go away now that LECs are becoming long distance
carriers, too.
Since both voice BCs route the same thru ISUP switches, I propose
modifying the lesser used BC=Speech to request DON'T TOUCH THIS SIGNAL!
This may actually require an ISUP carrier to route BC=Speech separate
from BC=3.1KHz. (Of course, I would still want the BC=Speech route to
overflow to the BC=3.1KHz route if that is all that is available to
complete the call.) Within AT&T's network this may not be so hard to do
(calls from other networks entering AT&T's ISUP network can still be
given treatment according to standards). Anyway, according to Bellcore,
BC=3.1KHz does NOT imply no further digital signal processing.
According to I.230 for BC=3.1KHz "the network may provide speech
processing techniques provided they are appropriately modified or
functionally removed prior to non-speech information transfer."
Effectively what happens is the network sets up a call regardless
of BC=Speech or BC=3.1KHz and then listens for a modem/fax tone.
If modem/fax tone, cut-off signal processing, else continue. There
is no rerouting after answer and discovering a modem/fax tone which
is why so few V.32 modems can get 28.8k across the ocean.
At least that's the way I see it. Hope that helps.
Jeffrey Rhodes at jeffrey...@attws.com
ps. I do not intend to imply that True Voice signal processing makes
the MCELP to ISUP to MCELP call grossly distorted (it doesn't). I do
want to imply that human voice communication will be facilitated
when True Voice signal processing is not performed on an MCELP to
ISUP to MCELP call (this applies to maybe .001% of AT&T's calls today).
pps. Do you know what happens when MNP tries to compress an already
compressed file? The file transmitted is actually larger than the original
compressed file. V.42 compression recognises this situation and turns off
for file transmission. MNP compression is not a tragedy, it simply does
not transmit previously compressed files as well as V.42.
In article <31790e7b....@nntp.interramp.com>, <j...@interramp.com> writes:
>
> jeffrey...@attws.com wrote:
> snip
> >MCELPed signal. I recommend BC=Speech to indicate a bear channel request
> >for NO FURTHER DIGITAL SIGNAL PROCESSING and BC=3.1KHz Audio to indicate
> >that it is OK (acceptable) to use further digital signal processing such
> >as compression. Yes, I know I am shouting, maybe the world will get this
> >way some day. For calls initiated from AT&T's cellular network, I am
> >championing this position within AT&T's entire ISUP signaling network.
>
> Jeffrey,
>
> Unless I am misunderstanding something, this is the opposite of what I
> understood to be the recommendation. For example, DOSBS is almost
> always done over 3.1K (which would assume no processing of the
> signal). Also, most ISDN devices that are capable of analog emulation
> set their BC as 3.1K for modem calls intentionally to avoid
> processing.
>
> You obviously know a lot more about this than I do. But the names
> themselves (speech and 3.1K) would seem to suggest the opposite of
> what you think ought to be done.
>
> Are my assumptions correct based on the current interpretations of the
> voice BCs (or am I off my rocker)?
>
jeffrey...@attws.com
Justin,
Thank you for a most excellent definition of the terminal to ISDN carrier
encoding of the Q.931 setup message parameter for Bearer Channel request.
I am not concerned with that boundary but I am concerned about the use of
BC request in any subsequent ISUP carrier to ISUP carrier boundary and
the ISUP IAM setup message parameters for BC request used to setup calls
between ISUP carriers.
BTW, can the Nortel DMS change the BC=Speech request made by an ISDN
terminal to say, BC=3.1KHz Audio for the outgoing ISUP IAM? If you owned
a LEC and your switches let you do that, would you be tempted to "fool"
the competitive long distance carrier into believing that only the best
uncompressed routes are requested for your customer?
Bellcore has recommendations. In reality, BC=Speech and BC=3.1KHz Audio
use the same ISUP circuits for call completion. In reality, there is no
well-defined ISUP parameter to indicate downstream that NO FURTHER DIGITAL
SIGNAL PROCESSING IS REQUESTED.
Bellcore can recommend that carriers avoid TASI for BC=3.1KHz bearer
channel requests, but in reality carriers still compress voice and
analog modem/fax calls routed across the ocean. If you want to get the
full 64kbps, you need to use BC=UDI(64k Unrestricted) as you explain
below. If you made a VODBS (Voice Over Data Bearer Service) call and
then made an ISDN TA V.34 analog modem emulator training sequence to a
similarly inclined answering TA, you could realize a full 28,800 bps.
As of today, V.34 operates across the ocean at sub-optimum rates because
the BC=3.1KHz Audio bearer channel request is still compressed by TASI
to a mere 40kbps (5 for 8 compression) or ADPCM to 32kbps. Or at least
I categorically affirm that a V.34 analog modem is lucky to obtain an
uncompressed circuit from the U.S. to Europe and will most likely not
be able to achieve 28.8kbps due to overseas carrier compression.
Since the meaning of BC=3.1KHz is muddled by the fact that Bellcore
recommends treating the MF to ISUP interworking border to be BC=3.1KHz,
how is an ISUP carrier supposed to believe these calls all require
special circuits? Within a carrier's own network, the meaning of
BC=Speech can route separately from BC=Speech requests entering that
ISUP carrier's network on a separate trunk group. Since there is no good
incentive for one ISUP carrier to indicate to another ISUP carrier "it's
OK to compress this BC=Speech signal", why not use the BC=Speech ISUP
parameter within a single carrier's network to indicate a preference for
absolutely no further signal processing? This would achieve the routing
that the BC=3.1KHz parameter has been unable to ensure in today's U.S.
voice call processing routing.
Jeffrey
In article <4lghqj$e...@crchh327.rich.bnr.ca>, <med...@bnr.ca> writes:
> John Powell (j...@interramp.com) wrote:
> > jeffrey...@attws.com wrote:
> > snip
> > >MCELPed signal. I recommend BC=Speech to indicate a bear channel request
> > >for NO FURTHER DIGITAL SIGNAL PROCESSING and BC=3.1KHz Audio to indicate
> > >that it is OK (acceptable) to use further digital signal processing such
> > >as compression. Yes, I know I am shouting, maybe the world will get this
> > >way some day. For calls initiated from AT&T's cellular network, I am
> > >championing this position within AT&T's entire ISUP signaling network.
>
> > Jeffrey,
>
> > Unless I am misunderstanding something, this is the opposite of what I
> > understood to be the recommendation. For example, DOSBS is almost
> > always done over 3.1K (which would assume no processing of the
> > signal). Also, most ISDN devices that are capable of analog emulation
> > set their BC as 3.1K for modem calls intentionally to avoid
> > processing.
>
jeffrey...@attws.com
In article <4l9ihq$1d...@rtpnews.raleigh.ibm.com>, <lma...@vnet.ibm.com>
writes:
> In <NEWTNews.8298606...@jrhodespc.nwest.mccaw.com>,
jeffrey...@attws.com writes:
> >
> >In article <4l4unf$2b...@news-s01.ny.us.ibm.net>, writes:
> >
> > I recommend BC=Speech to indicate a bear channel request
> >for NO FURTHER DIGITAL SIGNAL PROCESSING and BC=3.1KHz Audio to indicate
> >that it is OK (acceptable) to use further digital signal processing such
> >as compression.
>
> Jeffrey, you've got that backwards. I am sure the current recommendations
> define:
> BC=3.1 KHz Audio ==> no lossy compression (e.g., modem data)
> BC=Speech==> Lossy compression permitted (e.g., Voice)
>
Laurence,
Bellcore defines things for LECs, ISUP carriers have a different point of
view. A Bearer Service request for BC=3.1KHz Audio is recommended to not
suffer lossy compression. Carriers compress these calls anyway. In reality,
as long as a 14,400 bps fax can cross the ocean, I guess no one complains.
Does the WaveRunner emulate a V.34 (28.8K) analog modem? If so, are you
(ever) able to call from the U.S. to Europe and achieve 28,800 bps
connections? I don't think so, and no one is writing back to counter my
assertion. If V.34 analog modems can only achieve ~24kbps connections
across the ocean, then I speculate that TASI or ADPCM circuits have
compressed/decompressed the signal such that 28,800 just isn't possible.
So while BC=3.1Khz is recommended to avoid TASI or True Voice circuits,
in reality it does not. The routing occurs the same as BC=Speech and then
after answer, if a modem/fax tone is detected, AT&T's True Voice will kick
out or TASI will allocate 40kbps compression of 64kbps instead of 32kbps.
The problem I have is that I want the digital cellular call to route
through AT&T's ISUP long distance to another digital cellular terminal
and make sure that nothing touches the MCELPed signal. It's not a tragedy
if True Voice "enhances" the human speech but the vocoders used for digital
cellular compression work best when the signal is MCELP-OUT to MCELP-IN.
Within AT&T's network, ISUP calls from cellular switches with BC=Speech
can indicate special routing to avoid True Voice and TASI (unless all
special routes are being used and the call needs to overflow onto normal
routes that are subject to True Voice and/or TASI in order to be completed
as dialed). ISUP calls from cellular switches with BC=3.1KHz can be
reserved for POAMPS (plain old AMPS) analog cellular calls.
If any LEC is sending ISUP IAMs to AT&T with BC=Speech, then AT&T can
treat these calls separately as the standards recommend. In reality, why
would any LEC do that? I would expect the LEC to request BC=3.1Khz Audio
on all calls, so that the LEC's customer will receive the best service!
I would expect all ISDN users to do the same. In reality, there is no
routing advantage to either BC request.
Jeffrey
ps. When an ISDN TA has an analog port, part of the TA's configuration
options determines whether analog calls will be BC=Speech or BC=3.1KHz.
An analog call starts as an off-hook. The TA delivers dial tone, then
DTMF tones dial the call which sends a Q.931 message with a BC request
already pre-defined. There is no way for the TA to determine whether
a modem is dialing or a human is dialing. This is true for a call from
a POTS phone, too. Since there is no way to tell apriori that a modem
or fax is calling instead of a human, Bellcore's recommendations for
BC=Speech and BC=3.1KHz are useless.
Hank Karl
On Fri, 26 Apr 96 15:25:26 PDT, jeffrey...@attws.com wrote:
>Bellcore defines things for LECs, ISUP carriers have a different point of
>view. A Bearer Service request for BC=3.1KHz Audio is recommended to not
>suffer lossy compression. Carriers compress these calls anyway. In reality,
>as long as a 14,400 bps fax can cross the ocean, I guess no one complains.
>
>Does the WaveRunner emulate a V.34 (28.8K) analog modem? If so, are you
>(ever) able to call from the U.S. to Europe and achieve 28,800 bps
>connections? I don't think so, and no one is writing back to counter my
>assertion. If V.34 analog modems can only achieve ~24kbps connections
>across the ocean, then I speculate that TASI or ADPCM circuits have
>compressed/decompressed the signal such that 28,800 just isn't possible.
One possibility you haven't mentioned is that the carrier compresses
voice, but decodes modem signals. If a DSP is used, it's just running
one algorithm or the other. The channel is set to the minimum
required for a voice call, because most calls are voice calls. The
carrier may use 16K CELP or ADPCM, or even 2.4K or 4.8K CELP. Thus,
you may only get a 2.4K channel for modem data.
I worked for a company that made TDM muxes for use by international
telephone service resellers ("call back services"). We used a DSP and
did automatically differentiate between voice and modem connections.
Hank Karl
Opinions mine, not my company's.
jeffrey...@attws.com
Hank,
Thanks for describing other compression techniques used on overseas
"voice" connections that can potentially limit the data thruput of
an analog modem or fax. You probably know for a fact, but I am still
conjecturing, that overseas compression limits V.34 modems to less
than optimal line speeds.
Perhaps you will elaborate, to help others like me understand effects
of compression. I have been told that TASI compression can recognise
modem signals after answer and dynamically allocates 40kbps compression
of 64kbps PCM rather than the normal 32kbps compression. Are you saying
that the TDM muxes differentiate the voice traffic and compress down to
2.4K channels but leave modem signals at 64kbps (or compress modem/fax
signals at a data rate of something greater than the default voice rate
like TASI)? Or (,I doubt this but I need to check,) are you saying that
the asynchronous content of the modem's signal is decoded before
entering the TDM channel and is then "piped" thru the TDM muxes at 2400
bps as raw data, to be uncompressed back to the 64kbps PCM modem signal
while injecting software flow control (XON/XOFF) to prevent a 28.8K
modem from overwhelming the TDM's 2.4kbps circuit?
Assuming that a modem signal is compressed down to 2.4K "voice" channels,
either as an accident because of bad routing or intentionally to handle
more calls with less bandwidth, what would you expect the modems to
negotiate for a line speed after answer?
If a 9600 bps fax or modem can only negotiate across compressed circuits
for max 2400 bps, is this considered a non-lossy circuit? Personally, I
consider this a lossy circuit (even though it operates with no errors)
and if I started this call from the analog port of an ISDN TA with a
BC=3.1KHz Audio request to the network, AND IF THE NETWORK ACTUALLY DID
WHAT BELLCORE RECOMMENDS FOR BC=3.1KHz AUDIO CALLS, ie. "avoid lossy
compression such as TASI", then one would expect overseas calls to
connect at 9600 bps, not 2400 bps. Since this is contrary to my
experience, eg. I have never made a 28.8Kbps connection between the US
and Europe, and since I know most non-private overseas circuits are
compressed, I have to conclude that overseas carriers ignore Bellcore's
Recommendations for handling BC=3.1KHz Audio!
Bellcore also recommends converting an incoming non-ISDN call to
BC=3.1KHz Audio for downstream ISUP connections. If overseas carriers
actually followed Bellcore's recommendations for special routing of
BC=3.1KHz Audio to avoid lossy TASI circuits, a lot of non-ISDN voice
calls would by-pass compression, too. Bellcore's recommendations are
slanted to favor a LEC's call processing interests at the cost of a
long distance carrier's interests.
Jeffrey
In article <31853768....@nntp.ix.netcom.com>, <hank...@ix.netcom.com>
writes:
Hank Karl
Jeffrey,
Sorry I wasn't clear.
On Thu, 02 May 96 09:06:03 PDT, jeffrey...@attws.com wrote:
>
>Hank,
>
>Thanks for describing other compression techniques used on overseas
>"voice" connections that can potentially limit the data thruput of
>an analog modem or fax. You probably know for a fact, but I am still
>conjecturing, that overseas compression limits V.34 modems to less
>than optimal line speeds.
>
>Perhaps you will elaborate, to help others like me understand effects
>of compression. I have been told that TASI compression can recognise
>modem signals after answer and dynamically allocates 40kbps compression
>of 64kbps PCM rather than the normal 32kbps compression. Are you saying
>that the TDM muxes differentiate the voice traffic and compress down to
>2.4K channels but leave modem signals at 64kbps (or compress modem/fax
>signals at a data rate of something greater than the default voice rate
>like TASI)?
Remember, I was not a DSP guy, so this is sort of second-hand info.
Decoding a modem signal is probably less work than (voice)
compression, and is loss-free (voice compression is lossy). Also,
modems "train" to the line. This signal can be recognized and used to
differentiate modem/fax from voice. There are plenty of automatic fax
switches that do something similar to this.
> Or (,I doubt this but I need to check,) are you saying that
>the asynchronous content of the modem's signal is decoded before
>entering the TDM channel and is then "piped" thru the TDM muxes at 2400
>bps as raw data, to be uncompressed back to the 64kbps PCM modem signal
>while injecting software flow control (XON/XOFF) to prevent a 28.8K
>modem from overwhelming the TDM's 2.4kbps circuit?
This can be done, but I don't know if anyone implements it this way.
What is done is to negotiate a lower speed. Most modems support
several modem spec's for compatibility with older modems. Bell 212A
(I think) is a 2400 baud modem that many V.34 modems support. If you
have a 2.4Kbps channel, you may negotiate the modem to 212A.
The TDM mux has to contend with other issues, however. Assuming you
set your serial port to 8 data bits, no parity, one stop bit, you need
10 bits per octet of data. A synchronous channel only needs to send 8
bits per octet of data, but it needs some overhead because async data
rates vary. Remember that the PC's async ports have their own
crystal. That crystal will have an initial deviation from its nominal
value. The crystal will further deviate as the temperature changes,
and as it ages. If a 9600 bps serial port has a tolerance of -3% to
+3%, then data rates from 9312 bps to 9888 bps must be accommodated.
Because only 80% of these bits are data, you may fit them in an 8K
channel (80% of 9888 is 7680). However, you need some way to signal
the other end to speed up or slow down to match the input, or run the
other end at the maximum rate and insert extra stop bits occasionally.
Also, you may want to send control signals (CTS, etc). I believe that
V.110 rate adaption requires a 16K channel for a 9600 rate adapted
signal because of the overhead and other signaling.
>
>Assuming that a modem signal is compressed down to 2.4K "voice" channels,
>either as an accident because of bad routing or intentionally to handle
>more calls with less bandwidth, what would you expect the modems to
>negotiate for a line speed after answer?
Depends on the TDM mux implementation. But I would expect some
popular type modem. I would also expect somewhere around 8 to 32
Kbps, as 2.4K (and 4.8K) CELP compression sounds terrible to me. It
does get better sounding as the per-minute price drops . . .
>
>If a 9600 bps fax or modem can only negotiate across compressed circuits
>for max 2400 bps, is this considered a non-lossy circuit? Personally, I
>consider this a lossy circuit (even though it operates with no errors)
Voice compression algorithms are all lossy as far as I know. If you
decode modem signals, it is non-lossy. No data bits are intentionally
dropped.
>and if I started this call from the analog port of an ISDN TA with a
>BC=3.1KHz Audio request to the network, AND IF THE NETWORK ACTUALLY DID
>WHAT BELLCORE RECOMMENDS FOR BC=3.1KHz AUDIO CALLS, ie. "avoid lossy
>compression such as TASI", then one would expect overseas calls to
>connect at 9600 bps, not 2400 bps. Since this is contrary to my
>experience, eg. I have never made a 28.8Kbps connection between the US
>and Europe, and since I know most non-private overseas circuits are
>compressed, I have to conclude that overseas carriers ignore Bellcore's
>Recommendations for handling BC=3.1KHz Audio!
Bellcore is an American institution, it was part of AT&T before the
breakup. Euro ISDN is different than North American ISDN, I don't
think that foreign based carriers conform to Bellcore recommendations.
In fact, American carriers don't have to conform to Bellcore's
recommendations.
But the reason you probably don't get a 28.8 connection is that Europe
(and much of the rest of the world) uses A-law companding, the U.S.
uses u-law. Translation is done "for" you by the carriers. 64K data
(or 56K) avoids this, but it costs more (at least it does where I am
located.)
>
>Bellcore also recommends converting an incoming non-ISDN call to
>BC=3.1KHz Audio for downstream ISUP connections. If overseas carriers
>actually followed Bellcore's recommendations for special routing of
>BC=3.1KHz Audio to avoid lossy TASI circuits, a lot of non-ISDN voice
>calls would by-pass compression, too. Bellcore's recommendations are
>slanted to favor a LEC's call processing interests at the cost of a
>long distance carrier's interests.
>
>Jeffrey
>
Hank Karl
Kristian Rask
You:
> From: jeffrey...@attws.com
Wrote to:
> Hank,
and said:
> Thanks for describing other compression techniques used on
> overseas "voice" connections that can potentially limit the data
> thruput of an analog modem or fax. You probably know for a fact, but I
> am still conjecturing, that overseas compression limits V.34 modems
> to less than optimal line speeds.
> BC=3.1KHz Audio to avoid lossy TASI circuits, a lot of
> non-ISDN voice calls would by-pass compression, too. Bellcore's
> recommendations are slanted to favor a LEC's call processing
> interests at the cost of a long distance carrier's interests.
My hybrid ISDN X.75, HDLC, V.34, V.FC, Fax G3 & G4 card
does always use 3.1 KhZ audio for analog connections.
This works fine all over Europe. (sometimes downto 10 sec's
off Dialing, Negotiating, CONNECT V.34/28K8) calling Italy/Spain
from Denmark (approx. 1500 miles).
Funny thing is that i allways get stable connects in Europe.
It's only when dialling a US number, that i occasionally
get a "bad line", eg. line drops in the middle of things.
I dont know what they do in the US, but in Europe, ISDN audio services _can_
get routed to PSTN networks when the ISDN is lacking bandwidth. I can _measure_
that, in the sense that the
negotiating fase of the modem goes from approx. 8 to 9 sek's to
as much as 30 sec's, typically followed by a "CONNECT V.34/26K4.
btw.: I have had a few US call's to my BBS, they went very well, also on pure
ISDN (64K0/X.75) but as i understand it, only a very limited number of
americans has equipment that can do X.75 or transparent HDLC.
Hope this info. is usefull to you in some way.
regards
Kristian Rask, Denmark
--
|Fidonet: Kristian Rask 2:238/12.41
|Internet: kr...@guanche.ping.dk
jeffrey...@attws.com
Hello, Kristian
What is the number to your BBS? I should like to call it. I am curious
about V.34 operation between our continents. Do you think that the
A-law, mu-law conversion limits operation to less than 28,800 bps? I
think this is transparent for the modem signals but that overseas
circuits use ADPCM or TASI compression which is much more detrimental
to the ability of two V.34 modems to negotiate training to a 28K CONNECT.
The ISDN X.75 calls from the US are ISDN long distance data calls and are
transported at 64kbps to Europe. Unlike Europe, where all voice circuits
are clear channel 64kbps, here in the US some (or maybe most) long distance
voice circuits are subject to a number of interferences on the least
significant bit of each octet in the 64kbps (8000 octets per second) PCM
stream. While this interference is not noticable for "talking", you
can imagine what it does to a 64kbps data stream. Hence, 56k rate adaption
imposes octets with 7 bits data, 1 bit save for the network to interfere
with.
Also, many times a US ISDN user is charged more for 64kbps data calls. We
have an informal convention to beat this surcharge (DOSBS stands for Data
Over Speech Bearer Service). We start our call as BC=3.1KHz Audio (to fool
the phone company into thinking this is a "voice" call) and then send 56k
data over the resulting connection. This (usually) works even when the
network is interfering with the least significant bit of each octet.
Jeffrey
ps. Have you ever had a 28,800 CONNECT between the US and Europe? Even if
a US TA can encode the modem signal as A-law, the US gateway will attempt
to convert the incoming A-law (presumed to be mu-law) to A-law which will
pretty much guarantee the modems WON'T be able to train above maybe 1200 baud.
In article <356_960...@guanche.ping.dk>, <kr...@guanche.ping.dk> writes:
>
> You:
>
> > From: jeffrey...@attws.com
said:
>
> > Thanks for describing other compression techniques used on
> > overseas "voice" connections that can potentially limit the data
> > thruput of an analog modem or fax. You probably know for a fact, but I
> > am still conjecturing, that overseas compression limits V.34 modems
> > to less than optimal line speeds.
>
Arthur Marsh
jeffrey...@attws.com wrote:
: What is the number to your BBS? I should like to call it. I am curious
: about V.34 operation between our continents. Do you think that the
: A-law, mu-law conversion limits operation to less than 28,800 bps? I
: think this is transparent for the modem signals but that overseas
: circuits use ADPCM or TASI compression which is much more detrimental
: to the ability of two V.34 modems to negotiate training to a 28K CONNECT.
I've achieve 28800 bps modem calls from my home in Australia to the
Multi-tech support bbs in the USA.
Calls to the Motorola support bbs only started working well after Telstra
fixed the echo cancellers in the international gateway exchange. (-:
: The ISDN X.75 calls from the US are ISDN long distance data calls and are
: transported at 64kbps to Europe. Unlike Europe, where all voice circuits
: are clear channel 64kbps, here in the US some (or maybe most) long distance
: voice circuits are subject to a number of interferences on the least
: significant bit of each octet in the 64kbps (8000 octets per second) PCM
: stream. While this interference is not noticable for "talking", you
: can imagine what it does to a 64kbps data stream. Hence, 56k rate adaption
: imposes octets with 7 bits data, 1 bit save for the network to interfere
: with.
Many locations in the USA seem to have terrible performance for modem calls.
: ps. Have you ever had a 28,800 CONNECT between the US and Europe? Even if
: a US TA can encode the modem signal as A-law, the US gateway will attempt
: to convert the incoming A-law (presumed to be mu-law) to A-law which will
: pretty much guarantee the modems WON'T be able to train above maybe 1200 baud.
Hmmm, I should have a new TA with POTS port this week... already have an old
TA with POTS ports working on the ISDN line, can check how V.34 works...
BTW, I'm surprised that there are now ISDN bbs's in Australia *yet*.
--
Arthur Marsh, telephone +61-8-370-2365, fax +61-8-223-5082
art...@dircsa.org.au
.endofsig