3 ms·

More specifically, packet-based rather than switched telecoms. Using a switch, each connection is a literal physical circuit. Multiplexing allows multiple ci

More specifically, packet-based rather than switched telecoms. Using a switch, each connection is a literal physical circuit. Multiplexing allows multiple circuits per phone line (through frequency separation at the carrier-frequency level), and much early telephony research involved increasing the multiplexing capacity and consequent issues. With packet-switched networks, the only circuits are the interconnects between routers, and each individual data packet can take a different route. Subject to quality of service / service level agreements (QoS / SLA), it's possible to support far more distinct individual connections over packet-switched networks, though there still remains a maximum total bandwidth. For time-sensitive modalities (e.g., realtime voice or video), excess traffic leads to congestion and buffering, distortion, or interference, so limits remain. But they're far more generous than with circuit-based networks. Put another way, packets give a greater assurance of establishing a link between any two nodes, whilst circuits give a greater assurance of a minimum bandwidth floor between those nodes. If you can get a connection, circuit-based line quality is often (though not always) superior, in terms of consistency, clarity, and low latency.

ssl-3 1y ago
That doesn't necessarily line up with my understanding of reality. In the US, a PRI can handle up to exactly 23 concurrent, native g.711u phone calls. That's it's capacity: No more, and no less. It's always 23, with each concurrent call using exactly 64kbps of symmetric bandwidth....just because that's the number of B channels provided. But if we take that same PRI and make it do IP packets instead using MLPPP, then our capacity is actually reduced. By adding the magic of packet switching, we also add overhead. And with that added overhead, we can only get only get ~19 g.711u calls through that same circuit. (Now, sure: In a bigger picture, that PRI may be better utilized as an IP pipeline than as a dedicated telephony circuit. It's certainly more flexible that way. But packetization is not something that automatically improves capacity. It often does the opposite.)
- dredmorbius 1y ago
  This is well outside my area of expertise, assess accordingly. From some quick DDGing, PRI (primary rate interface) is one of several possible options for a packet-switched telephony system, and is specifically contrasted with SIP VOIP connections in this article: <https://enterprise.spectrum.com/support/faq/voice-and-collaboration/what-is-a-pri-phone-system.html https://enterprise.spectrum.com/support/faq/voice-and-collab...> NB, "always 23" ... unless you're in Europe, in which case 23 === 30. More on PRI vs. SIP: <https://enterprise.spectrum.com/support/faq/voice-and-collaboration/what-is-the-difference-between-pri-and-sip-trunk.html https://enterprise.spectrum.com/support/faq/voice-and-collab...>. (Other than being able to spell PRI and the above articles, I've no knowledge on the topic.)
  - ssl-3 1y ago
    PRI is TDM. It isn't packet-switched; there are no packets on the voice-carrying B channels. It uses timeslots, instead. > NB, "always 23" ... unless you're in Europe, in which case 23 === 30. I believe I was very specific about the locality I was referring to, but I am appreciative of the seemingly-disingenuous pedantry that is apparently unfettered by such arcane concepts as "context".
    - dredmorbius 1y ago
      Where TDM == "time-division multiplexing". Expanding acronyms, particularly those from less-mainstream concepts and fields, is appreciated. It wasn't clear from your comment (or the source I'd read) that PRI is circuit based. The fact that circuits can be multiplexed (whether through frequency-separation, timeslicing, or other mechanisms, see <https://en.wikipedia.org/wiki/Multiplexing https://en.wikipedia.org/wiki/Multiplexing> for general MUXology) is irrelevant. They are still circuits. And there are limits to how many circuits can be maintained at a single time, regardless of the apparent endpoint combinatorial possibilities. Packet-based switching has far greater capacity and flexibility, as I, my sources, and several other comments to this thread, have noted. Pedantry aside, you seem to be confirming my initial point.
      - ssl-3 1y ago
- contingencies 1y ago
  Theoretically, yes. However, in practice, no. One of the great wins of packetization is that your infrastructure becomes generic in the sense that it is application-independent, allowing all subsequent improvements in eg. compression protocols to be applied retroactively. Therefore, if you would apply for example a variable bit rate, modern CODEC to the voice streams it's likely you would fit substantially more than a naïve set of voice channels on the raw PRI. The main costs are not in overhead, but enhanced session setup and round-trip latency and increased processing overheads at the edges. However, modern electronics offer embedded solutions making this ~free and a few ms are tolerable. IIRC voice is fine at <200ms latency, more or less, though less is obviously better. The philosophical battle was centralist vs decentralised, for-purpose vs generic infrastructure, single-mode vs. multi-mode network applications, circuit-switched guaranteed QoS vs. best-effort packets, waterfall vs. iterative development and investment. Packets won for general purpose networking, because the nature of physics and bureaucracy meant the cost and time savings for operators and users were substantial.
  - ssl-3 1y ago
    Using a different codec can improve call-carrying capacity of any compatible link, for sure. But that's wiggling a different variable: Packetization-vs-not is a whole different game than g.711u vs g.723 is. And I agree, completely: There's very good reasons for packet-switched networks having won over TDM technologies like PRI, with IP to tie it altogether. What we've arrived at is beautifully generic in that the packets themselves don't care at all about what combination of lower layers were used to get them from A to B. However it gets there, it's just IP. That's really neat. Latency-wise, I'm a little torn: With the latency involved in a normal phone call on my normal cell phone today, I find that I "talk over" people on phone calls more than I did decades ago in the TDM days. The pacing is very different than it was. Sometimes, when the echo cancellation fails at some level, I can hear myself echo from the far end of a call. That echo is annoying, but I mention it because it is something that lets me hear the latency of the call. It's often on the order of 500ms RTT...which is quite a lot. We never had latency like that in the TDM days for domestic calls. (Historically, in TDM world: The voice data always arrived at the right time and there was also always a place to put it at the right time. It was real-time instead of best-effort, so there just wasn't any utility to having any large buffers along the way: The timing was either resolutely correct or it didn't work at all. Things are a lot mushier today.)

ssl-3 1y ago

That doesn't necessarily line up with my understanding of reality. In the US, a PRI can handle up to exactly 23 concurrent, native g.711u phone calls. That's it's capacity: No more, and no less. It's always 23, with each concurrent call using exactly 64kbps of symmetric bandwidth....just because that's the number of B channels provided. But if we take that same PRI and make it do IP packets instead using MLPPP, then our capacity is actually reduced. By adding the magic of packet switching, we also add overhead. And with that added overhead, we can only get only get ~19 g.711u calls through that same circuit. (Now, sure: In a bigger picture, that PRI may be better utilized as an IP pipeline than as a dedicated telephony circuit. It's certainly more flexible that way. But packetization is not something that automatically improves capacity. It often does the opposite.)

dredmorbius 1y ago
This is well outside my area of expertise, assess accordingly. From some quick DDGing, PRI (primary rate interface) is one of several possible options for a packet-switched telephony system, and is specifically contrasted with SIP VOIP connections in this article: <https://enterprise.spectrum.com/support/faq/voice-and-collaboration/what-is-a-pri-phone-system.html https://enterprise.spectrum.com/support/faq/voice-and-collab...> NB, "always 23" ... unless you're in Europe, in which case 23 === 30. More on PRI vs. SIP: <https://enterprise.spectrum.com/support/faq/voice-and-collaboration/what-is-the-difference-between-pri-and-sip-trunk.html https://enterprise.spectrum.com/support/faq/voice-and-collab...>. (Other than being able to spell PRI and the above articles, I've no knowledge on the topic.)
- ssl-3 1y ago
  PRI is TDM. It isn't packet-switched; there are no packets on the voice-carrying B channels. It uses timeslots, instead. > NB, "always 23" ... unless you're in Europe, in which case 23 === 30. I believe I was very specific about the locality I was referring to, but I am appreciative of the seemingly-disingenuous pedantry that is apparently unfettered by such arcane concepts as "context".
  - dredmorbius 1y ago
    Where TDM == "time-division multiplexing". Expanding acronyms, particularly those from less-mainstream concepts and fields, is appreciated. It wasn't clear from your comment (or the source I'd read) that PRI is circuit based. The fact that circuits can be multiplexed (whether through frequency-separation, timeslicing, or other mechanisms, see <https://en.wikipedia.org/wiki/Multiplexing https://en.wikipedia.org/wiki/Multiplexing> for general MUXology) is irrelevant. They are still circuits. And there are limits to how many circuits can be maintained at a single time, regardless of the apparent endpoint combinatorial possibilities. Packet-based switching has far greater capacity and flexibility, as I, my sources, and several other comments to this thread, have noted. Pedantry aside, you seem to be confirming my initial point.
    - ssl-3 1y ago
contingencies 1y ago
Theoretically, yes. However, in practice, no. One of the great wins of packetization is that your infrastructure becomes generic in the sense that it is application-independent, allowing all subsequent improvements in eg. compression protocols to be applied retroactively. Therefore, if you would apply for example a variable bit rate, modern CODEC to the voice streams it's likely you would fit substantially more than a naïve set of voice channels on the raw PRI. The main costs are not in overhead, but enhanced session setup and round-trip latency and increased processing overheads at the edges. However, modern electronics offer embedded solutions making this ~free and a few ms are tolerable. IIRC voice is fine at <200ms latency, more or less, though less is obviously better. The philosophical battle was centralist vs decentralised, for-purpose vs generic infrastructure, single-mode vs. multi-mode network applications, circuit-switched guaranteed QoS vs. best-effort packets, waterfall vs. iterative development and investment. Packets won for general purpose networking, because the nature of physics and bureaucracy meant the cost and time savings for operators and users were substantial.
- ssl-3 1y ago
  Using a different codec can improve call-carrying capacity of any compatible link, for sure. But that's wiggling a different variable: Packetization-vs-not is a whole different game than g.711u vs g.723 is. And I agree, completely: There's very good reasons for packet-switched networks having won over TDM technologies like PRI, with IP to tie it altogether. What we've arrived at is beautifully generic in that the packets themselves don't care at all about what combination of lower layers were used to get them from A to B. However it gets there, it's just IP. That's really neat. Latency-wise, I'm a little torn: With the latency involved in a normal phone call on my normal cell phone today, I find that I "talk over" people on phone calls more than I did decades ago in the TDM days. The pacing is very different than it was. Sometimes, when the echo cancellation fails at some level, I can hear myself echo from the far end of a call. That echo is annoying, but I mention it because it is something that lets me hear the latency of the call. It's often on the order of 500ms RTT...which is quite a lot. We never had latency like that in the TDM days for domestic calls. (Historically, in TDM world: The voice data always arrived at the right time and there was also always a place to put it at the right time. It was real-time instead of best-effort, so there just wasn't any utility to having any large buffers along the way: The timing was either resolutely correct or it didn't work at all. Things are a lot mushier today.)