Marco Moock <mm@dorfdsl.de> writes:
On 20.03.2026 10:48 Uhr Richmond wrote:
Marco Moock <mm@dorfdsl.de> writes:
On 18.03.2026 21:32 Uhr Richmond wrote:
I thought that the highest compression would be negotiated
automatically. But it seems SDP (Session Description Protocol)
doesn't necessarily choose the highest level, because it
considers quality and latency. Progress seems slow. Signal has
a better frequency range but has the usual drop outs.
Conversation means CPU power is needed, something the ISP want to
avoid for hundreds of calls, especially if the other side doesn't
have any advantage.
Why does the ISP need to do processing?
If the 2 subscribers use different codes, the signal needs to be
converted.
But they can negotiate the same codes.
Marco Moock <mm@dorfdsl.de> writes:
On 18.03.2026 21:32 Uhr Richmond wrote:
I thought that the highest compression would be negotiated
automatically. But it seems SDP (Session Description Protocol)
doesn't necessarily choose the highest level, because it considers
quality and latency. Progress seems slow. Signal has a better
frequency range but has the usual drop outs.
Conversation means CPU power is needed, something the ISP want to
avoid for hundreds of calls, especially if the other side doesn't have
any advantage.
Why does the ISP need to do processing?
This sort of thing seems insignificant to me, compared to streaming
audio and video.
The problems I think are NAT, Firewalls, and publicity. If you know
someone's SIP address you ought to be able to make a direct call over
the internet in the same way as Signal does. It would be free of any per minute cost. The compression would be done with equipment at either end,
not by the ISP. That's how it looks to me anyway.
Richmond wrote:
If you know someone's SIP address you ought to be able to make a
direct call over the internet in the same way as Signal does. It
would be free of any per minute cost. The compression would be done
with equipment at either end, not by the ISP.
The call setup (SIP) is done via the VoIP provider, but normally the
actual speech (RTP) is direct between the caller and callee, rather than
via the provider.
But I don't think you'd want a tidal wave of AI vishing calls would you?--
On 20.03.2026 11:58 Uhr Andy Burns wrote:
The call setup (SIP) is done via the VoIP provider, but normally the
actual speech (RTP) is direct between the caller and callee, rather
than via the provider.
I haven't seen that. Are there SIP setups that handle it this way?
I have set up my SIP service using IPv6 and have not opened ports on
IPv4, but I can do phone calls to people with only IPv4, so there
cannot be a direct connection in that case.
Are you sure? I dont think that would bypass NAT...
But I don't think you'd want a tidal wave of AI vishing calls would you?
On 2026/3/20 11:58:39, Andy Burns wrote:
[]
But I don't think you'd want a tidal wave of AI vishing calls would you?
Fishing, I used to know. Phishing, I sort of know these days. but what's vishing - video phishing? Something else?
J. P. Gilliver writes:Correct; another term for it would be SPIT (spam over internet telephony).
Andy Burns wrote:
I don't think you'd want a tidal wave of AI vishing calls would you?
Fishing, I used to know. Phishing, I sort of know these days. but what's
vishing - video phishing? Something else?
Assuming it is Voice Phishing
I was investigating whether using a proper SIP phone, as opposed to a
DECT phone plugged into an ATA, would provide a better sound quality, including the lower pitch sounds.
I thought that the highest compression would be negotiated
automatically. But it seems SDP (Session Description Protocol) doesn't necessarily choose the highest level, because it considers quality and latency.
The call setup (SIP) is done via the VoIP provider, but normally the
actual speech (RTP) is direct between the caller and callee, rather than
via the provider.
Richmond wrote:
The compression would be done
with equipment at either end, not by the ISP.
On 20/03/2026 11:58, Andy Burns wrote:
The call setup (SIP) is done via the VoIP provider, but normally the
actual speech (RTP) is direct between the caller and callee, rather
than via the provider.
Whilst that is possible, I don't think it is common, and, as others
have implied, it would be a nightmare with NAT, let alone the CGNAT
that a consume, and, in particular, mobile phone user, is likely to encounter. Historically, one side would have been ISDN (circuit
switched), so it wouldn't have been possible.
At least in the USA, I think you can get a halfway house, where a
retail ITSP offers the media address of its wholesale ITSP.
(Asterisk, an open source SIP PABX (more correctly toolkit) only
officially supports setting up media on a one hop basis, and then reconfiguring the media path to cut out intermediates.)
Richmond wrote:
The compression would be done
with equipment at either end, not by the ISP.
Codecs are converting between analogue and digital domains, not doing
simple compression. A 16 bit, 44.1kHz codec would still be a codec,
even though it is CD quality.
I don't know the context of that quotation of mine above, but, codecs do compression right? mp3 does compression, mp3 is a codec? They don't
*have* to do compression, but if you want to get more data over an old copper phone line you would do compression.
If you have two VOIP customers speaking directly to each other, can you
not get better sound quality than analog? This must be possible I think,
as you can stream movies over a copper wire, so improving the sound
quality of voice ought to be a walk in the park.
I don't know the context of that quotation of mine above, but, codecs do compression right? mp3 does compression, mp3 is a codec? They don't
*have* to do compression, but if you want to get more data over an old
copper phone line you would do compression.
If you have two VOIP customers speaking directly to each other, can you
not get better sound quality than analog?
Regarding another reply, "codec" is often used to mean the output format produced by a codec, rather than the the actual process that does theI thought it was a combination of coder and decoder, i. e. it's the
coding and decoding, but the word "codec" is a combination of code and decode, so refers to the process.
End to end analogue signals degrade as they travel. Digital signals
also degrade in the analogue forms in which they are modulated, but can nearly always be regenerated to their original form, although, if that
fails, the result can much severe than the degradation of an analogue signal.
On 01/04/2026 16:56, Richmond wrote:
I don't know the context of that quotation of mine above, but, codecs do
compression right? mp3 does compression, mp3 is a codec? They don't
*have* to do compression, but if you want to get more data over an old
That's an implementation detail, and assumes that the initial A/D to conversion produces a large number of bits, which is probably true.
They way they get lots of data down a twisted pair transmission line (aluminium would be similar to copper, and silver might be better)
The idea of using lots of sub-carrier frequencies is something of a
analogue concept, although it will actually be implemented digitally,
these days.-a Different sub-carriers will be impacted differently by the imperfections in the transmission line, but there won't be enough
variation within a sub-carrier to invalidate it completely.
On 2026/4/1 23:54:29, David Woolley wrote:
[]
Regarding another reply, "codec" is often used to mean the output formatI thought it was a combination of coder and decoder, i. e. it's the
produced by a codec, rather than the the actual process that does the
coding and decoding, but the word "codec" is a combination of code and
decode, so refers to the process.
actual hardware (or software, or firmware).
David Woolley <david@ex.djwhome.demon.invalid> writes:
On 01/04/2026 16:56, Richmond wrote:
I don't know the context of that quotation of mine above, but,
codecs do compression right? mp3 does compression, mp3 is a
codec? They don't *have* to do compression, but if you want to
get more data over an old
That's an implementation detail, and assumes that the initial A/D
to conversion produces a large number of bits, which is probably
true.
As I understand it G.722 does do some compression to allow it to
have a frequency range going down to 50Hz, whereas the analog phone
only goes down to 300Hz. This latter difference makes the voice sound
thin and distant.
Google Meet on the other hand has a much fuller sound with those low
frequencies making it sound more realistic.
The compression G.722 uses is ADPCM (Adaptive Differential Pulse Code Modulation).
https://en.wikipedia.org/wiki/Adaptive_differential_pulse-code_modulation
So really the question is, with the right SIP/VOIP telephoneequipment, and a VOIP to VOIP connection, can I achieve this full
frequency?
I do have FTTP. It seems the things standing in the way are legacy,
NAT, and firewalls.
fails, the result can much severe than the degradation of an analogueOh yes, the "digital cliff", where the error correction fails. Although
signal.
the improvement in going to (corrected!) digital is vast (and gives me
many more channels), I find it_much_ more irritating when it_does_
fail - for video - than a noisy analogue channel. I think it's because
there is so much less warning, so it's so sudden.
I found this:
https://www.vodafone.co.uk/newscentre/press-release/vodafone-brings-hd-voice-call-quality-to-customers/
"Vodafone UK has rolled out High Definition Voice technology across the UK Customers making Vodafone-to-Vodafone calls on compatible phones will
enjoy exceptionally clear conversations with family, friends and work colleagues"
Unfortunately their customer service is intolerable to me.
On 02/04/2026 01:08, J. P. Gilliver wrote:
On 2026/4/1 23:54:29, David Woolley wrote:
[]
Regarding another reply, "codec" is often used to mean the output format >>> produced by a codec, rather than the the actual process that does theI thought it was a combination of coder and decoder, i. e. it's the
coding and decoding, but the word "codec" is a combination of code and
decode, so refers to the process.
actual hardware (or software, or firmware).
Of course it is. Certain people don't know as much as they want you to believe they do,
Codec is a device that interfaces between generally analogue signals of
some sort at one end and a digital data stream at the other. How that digital data stream is transferred is implementation specific. As is
any signal processing, digital or analogue, that is carried out by the aforesaid codec.
It's mostly applied to software layers these days with the actual
digital to analogue (and vice versa) being performed by devices with
other names, like 'modem' or 'DAC'
All comms is a (digital) signal imposed on an analogue carrier. Unless
you are counting atoms and electrons individually *everything* is
analogue at the bottom.
In general the old baseband phones were converted to 64kbps synchronous
TDM with iirc an 8 bit 8kHz sample rate giving an effective upper
frequency limit of about 3Khz and S/N ratio of about 45dB. I*n those
days (1960s?)the computer power to do compression didn't exist and nor
did the algorithms
It's very easy to do a lot better than that with a compressed VOIP
signal, and in today's broadband world you can go a LOT faster than
64kbps if you want. And voice, with distinct lack of much at the top
end of the frequency band and plenty of pauses, and only a single
frequency set, is absolutely ideal for compression.
I heard once (apocryphal) that intelligible speech could be transmitted
at 50 bytes per second.
G722 is actually slightly above the old 8kHz sample and the bandwidth extends to 7kHz. And does use compression because the final bitrate is
variable at 16, 24 and 32 kbps
I have no idea if it is the 'general standard' but one things is clear,
that excluding *mobile* (RF) phone technology, VOIP over broadband is superior to a baseband phone in every respect.
On 02/04/2026 01:14, J. P. Gilliver wrote:
fails, the result can much severe than the degradation of an analogueOh yes, the "digital cliff", where the error correction fails. Although
signal.
the improvement in going to (corrected!) digital is vast (and gives me
many more channels), I find it_much_ more irritating when it_does_
fail - for video - than a noisy analogue channel. I think it's because
there is so much less warning, so it's so sudden.
OTOH digital with error correct maintains quality well beyond what an analogue signal can.
UIf you are getting degradation the signal level is already so corrupt
or low that no analogue is likely to be useable
Strictly, I don't think of the ADC/DAC as part of the CoDec; on the
whole, I wouldn't think of analogue processing stages as part of it
either. but I can see that they could be. Academic nowadays - and for
some time - anyway; compression nearly always done by software
(occasionally firmware), in the digital domain, rather than a piece of hardware.
Never thought of MoDem as part of it eiter, but I suppose it could be.
On 2026/4/2 13:53:48, The Natural Philosopher wrote:Well that is an intersting point. Certainnly at the level of conversion
[]
All comms is a (digital) signal imposed on an analogue carrier. Unless
A lot of modern schemes, I'd say "on several analogue carriers". Sure,
you can insist it's one, but that makes the nature of the digital
signal, and the imposing, considerably more complex.
you are counting atoms and electrons individually *everything* is
analogue at the bottom.
:-)
[]
In general the old baseband phones were converted to 64kbps synchronous
TDM with iirc an 8 bit 8kHz sample rate giving an effective upper
frequency limit of about 3Khz and S/N ratio of about 45dB. I*n those
days (1960s?)the computer power to do compression didn't exist and nor
did the algorithms
did it even do error-correction?
Oh absolutely, Its more like resynthesising speech from tokens
It's very easy to do a lot better than that with a compressed VOIP
signal, and in today's broadband world you can go a LOT faster than
64kbps if you want. And voice, with distinct lack of much at the top
end of the frequency band and plenty of pauses, and only a single
frequency set, is absolutely ideal for compression.
I heard once (apocryphal) that intelligible speech could be transmitted
at 50 bytes per second.
I could believe it, though I imagine grotty, though intelligible. (you
might not be able to identify the speaker, for example.)
G722 is actually slightly above the old 8kHz sample and the bandwidth
extends to 7kHz. And does use compression because the final bitrate is
7 kHz implies 14+kHz sample rate (unless throwing away some of the
bottom and mixing).
--variable at 16, 24 and 32 kbps
I have no idea if it is the 'general standard' but one things is clear,
that excluding *mobile* (RF) phone technology, VOIP over broadband is
superior to a baseband phone in every respect.
True. It's just that error correction hides the_fact_ of the
degradation - until it "falls off the cliff"_suddenly_. With analogue,
you get some_warning_ that something is going wrong (and, occasionally,
can do something about it, such as moving the aerial, or attending to
the source of the interference); with (corrected) digital, you have
little or no hint until it's too late.
When you learn network theory there is somewhere a 7 layer model.
When you end up designing real kit all that goes out the window, The
layers are blurred, part of 'layer 2' is being done by the hardware
that 'does layer 3'; etc etc.
Aeons ago when I first joined a company as an apprentice to learn electronics as it was practiced, I was given some boards to service,
from a radar rack.
I hazed in amazement at a board with two capacitors, thirteen resistors
and one op amp chip covering an area of around 46 square inches with a
gold plated edge connector that cost more than the rest of the board
put together...
I finally figured it out., A boffin had drawn a *block diagram* of the
whole radar set and one of the blocks was an analogue adder.
Then the job had been passed to a technician who had assigned each
block, a circuit board, whether it needed it or not, because he was
thick and lazy. And money was no object.
And another technician had dutifully taken that block and turned it into
a circuit board.
And that is how the world works.
This isn't about technology - this codec thing, Its about word
definition, Semantics. One builds circuits, they do stuff. They have hardware and software. Somehow they get fiddled with till they work.
Then people argue over what to call them - where to draw the line
between 'codec' and 'DAC' , and whether a filter in hardware that does
the same thing as one in software is in fact the same thing.
Because stupid people want simple stories, that make them look smart. So they argue over definitions and pretend it's about technology.
TLDR. VOIP is coming. Over broadband. You dont need to know how it
works, just that it does, and how to use it, and to know that in general
its better quality than old school TDM telephony. Because it uses
better tech and more of it.
The specifications of the interchange protocols like G722 are what they
are, and designed by people with better math skills than any of us , including me.
Whether the circuits that perform the translation between G722 and
baseband audio are (called) codecs, DACs ,ADCs digital signal processors
or orgasmatrons, is supremely irrelevant unless you want to try to
appear smarter than you are.
Just let it drop.
On 02/04/2026 23:24, J. P. Gilliver wrote:
True. It's just that error correction hides the_fact_ of the
degradation - until it "falls off the cliff"_suddenly_. With analogue,
you get some_warning_ that something is going wrong (and, occasionally,
can do something about it, such as moving the aerial, or attending to
the source of the interference); with (corrected) digital, you have
little or no hint until it's too late.
Well if you care enough you can build in a 'quality;' monitor on the incoming signal...
Raw error bit rate is a typical metric. How many times did you have to
error correct?
So really the question is, with the right SIP/VOIP telephone equipment,
and a VOIP to VOIP connection, can I achieve this full frequency?
The compression G.722 uses is ADPCM (Adaptive Differential Pulse Code Modulation).
I do
have FTTP
In that "digital signals" always, for most of about the last
fortysomething years, means "digital signals with error correction";
this is so often assumed as to be understood, but the omission of the
fact confuses newcomers to the subject (who are left wondering_why_ are digital signals better - and/or more reliable - until this point is explained. Which it often isn't).
On 02/04/2026 10:13, Richmond wrote:
So really the question is, with the right SIP/VOIP telephone equipment,
and a VOIP to VOIP connection, can I achieve this full frequency?
There is no point in having the low frequencies; they don't contribute
to voice intelligibility
The problem that G.722 addresses, is transmitting the higher speech frequencies, which allow one to distinguish between s, sh, and h, etc.,
but aren't weren't carried on analogue carrier systems, nor are they
carried on the 8kHz sampling channels that was used in the original
digital phone systems.
David Woolley <david@ex.djwhome.demon.invalid> writes:
On 02/04/2026 10:13, Richmond wrote:
So really the question is, with the right SIP/VOIP telephone equipment,
and a VOIP to VOIP connection, can I achieve this full frequency?
There is no point in having the low frequencies; they don't contribute
to voice intelligibility
There is no point if all you want is to understand the speech, but it
does change the sound and make it more real and immediate, and I
appreciate that, I think it is worth doing, especially as we now have
band width coming out of our ears with fibre.
On 04/04/2026 19:12, David Woolley wrote:
The problem that G.722 addresses, is transmitting the higher speech frequencies, which allow one to distinguish between s, sh, and h, etc., but aren't weren't carried on analogue carrier systems, nor are they carried on the 8kHz sampling channels that was used in the original digital phone systems.
Whilst sibilants in >4KHz range carry a lot of *fidelity* they do not in
any sense contribute to intelligibility.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 04/04/2026 19:12, David Woolley wrote:Well that's not true in my experience, I've lost quite a lot of
The problem that G.722 addresses, is transmitting the higher speech
frequencies, which allow one to distinguish between s, sh, and h, etc.,
but aren't weren't carried on analogue carrier systems, nor are they
carried on the 8kHz sampling channels that was used in the original
digital phone systems.
Whilst sibilants in >4KHz range carry a lot of *fidelity* they do not in
any sense contribute to intelligibility.
hearing at the high frequency end
differentiate between, say, 'sallow' and 'fallow', or 'cyst' and
'fist'. (there's probably better examples but I can't think of them
now). Obviously context helps a lot but when my wife suggests an
answer to a crossword clue there isn't any context and that's when I
have difficulty.
Telephones have always been able to carry low frequencies but the old
carbon mics couldn't generate them and nor could the primitive earpieces reproduce them.
A long tome ago simple tests revealed that provided you could send 300Hz-3kHz adequately, speech was intelligible and clear.
Whilst sibilants in >4KHz range carry a lot of *fidelity* they do not in
any sense contribute to intelligibility.
On 05/04/2026 12:01, The Natural Philosopher wrote:
Whilst sibilants in >4KHz range carry a lot of *fidelity* they do not
in any sense contribute to intelligibility.
That's not the position normally taken on the "speech banana" model <https://en.wikipedia.org/wiki/Speech_banana>.-a Sibilants are above
4kHz, so the 3.4kHz cut-off for normal telephone audio requires the
brain to guess from context.
I think even low end hearing aids are designed with a 6kHz cut--a off,
these days.
I was investigating whether using a proper SIP phone, as opposed to a
DECT phone plugged into an ATA, would provide a better sound quality, including the lower pitch sounds. It seems most VOIP providers don't
support G.722 which is the compression algorithm which would provide
this. Perhaps this is because in most cases calls would be going to
analog lines. But now it seems that 78% of homes have access to full
fibre. Does this mean they are actually using it though? Well
apparently not, the actual uptake is less than half, maybe 39%.
But PSTN is only being used by about a quarter of landlines. (This
figure is hard to be certain about because VM were using some other
analog system EMTA.)
So why not switch on G.722?
On 17.03.2026 22:45 Uhr Richmond wrote:
I was investigating whether using a proper SIP phone, as opposed to a
DECT phone plugged into an ATA, would provide a better sound quality,
including the lower pitch sounds. It seems most VOIP providers don't
support G.722 which is the compression algorithm which would provide
this. Perhaps this is because in most cases calls would be going to
analog lines. But now it seems that 78% of homes have access to full
fibre. Does this mean they are actually using it though? Well
apparently not, the actual uptake is less than half, maybe 39%.
But PSTN is only being used by about a quarter of landlines. (This
figure is hard to be certain about because VM were using some other
analog system EMTA.)
So why not switch on G.722?
I can only speak for Germany, but I assume the situation won't much
differ in the UK.
Most people use analog phones connected to their ATA RJ11 jack at the
router, so there won't be better audio quality for them.
SIP phones for home users are a corner cases and ISDN phones were also
phased out, many current CPEs vendors don't provide S0 anymore or
never did.
G.711 works in most cases with most equipment. If all use that codec,
there is no need for a translation between the ISPs.
I assume even if G.722 were used by default, the amount of phone calls
where that codec could be used (both ISPs support it, including the
transit interconnection ISPs, both customer CPEs have it enabled, both customers use SIP/DECT/ISDN phones that have proper microphones),
would be low.
I thought that the highest compression would be negotiated
automatically. But it seems SDP (Session Description Protocol) doesn't necessarily choose the highest level, because it considers quality and latency. Progress seems slow. Signal has a better frequency range but
has the usual drop outs.
On 18.03.2026 21:32 Uhr Richmond wrote:
I thought that the highest compression would be negotiated
automatically. But it seems SDP (Session Description Protocol)
doesn't necessarily choose the highest level, because it considers
quality and latency. Progress seems slow. Signal has a better
frequency range but has the usual drop outs.
Conversation means CPU power is needed, something the ISP want to
avoid for hundreds of calls, especially if the other side doesn't have
any advantage.
Marco Moock <mm@dorfdsl.de> writes:
On 18.03.2026 21:32 Uhr Richmond wrote:
I thought that the highest compression would be negotiated
automatically. But it seems SDP (Session Description Protocol)
doesn't necessarily choose the highest level, because it considers
quality and latency. Progress seems slow. Signal has a better
frequency range but has the usual drop outs.
Conversation means CPU power is needed, something the ISP want to
avoid for hundreds of calls, especially if the other side doesn't have
any advantage.
Why does the ISP need to do processing?
This sort of thing seems insignificant to me, compared to streaming
audio and video.
The problems I think are NAT, Firewalls, and publicity. If you know
someone's SIP address you ought to be able to make a direct call over
the internet in the same way as Signal does. It would be free of any per minute cost. The compression would be done with equipment at either end,
not by the ISP. That's how it looks to me anyway.
If you know someone's SIP address you ought to be able to make a
direct call over the internet in the same way as Signal does. It
would be free of any per minute cost. The compression would be done
with equipment at either end, not by the ISP.
Marco Moock <mm@dorfdsl.de> writes:
On 18.03.2026 21:32 Uhr Richmond wrote:
I thought that the highest compression would be negotiated
automatically. But it seems SDP (Session Description Protocol)
doesn't necessarily choose the highest level, because it considers
quality and latency. Progress seems slow. Signal has a better
frequency range but has the usual drop outs.
Conversation means CPU power is needed, something the ISP want to
avoid for hundreds of calls, especially if the other side doesn't
have any advantage.
Why does the ISP need to do processing?
This sort of thing seems insignificant to me, compared to streaming
audio and video.
The problems I think are NAT, Firewalls, and publicity.
If you know someone's SIP address you ought to be able to make a
direct call over the internet in the same way as Signal does. It
would be free of any per minute cost. The compression would be done
with equipment at either end, not by the ISP. That's how it looks to
me anyway.
The call setup (SIP) is done via the VoIP provider, but normally the
actual speech (RTP) is direct between the caller and callee, rather
than via the provider.
On 20.03.2026 10:48 Uhr Richmond wrote:
Marco Moock <mm@dorfdsl.de> writes:
On 18.03.2026 21:32 Uhr Richmond wrote:
I thought that the highest compression would be negotiated
automatically. But it seems SDP (Session Description Protocol)
doesn't necessarily choose the highest level, because it considers
quality and latency. Progress seems slow. Signal has a better
frequency range but has the usual drop outs.
Conversation means CPU power is needed, something the ISP want to
avoid for hundreds of calls, especially if the other side doesn't
have any advantage.
Why does the ISP need to do processing?
If the 2 subscribers use different codes, the signal needs to be
converted.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:50:27 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
10 files (20,373K bytes) |
| Messages: | 264,321 |