Still, RTP and SIP came directly out of the MBone, and they bootstrapped the whole Internet multimedia phenomena we're all enjoying today while working from home.
Still, RTP and SIP came directly out of the MBone, and they bootstrapped the whole Internet multimedia phenomena we're all enjoying today while working from home.
A best-effort multicast approach would help here. Reach as many endpoints as you can utilizing otherwise-unused router memory for the group memberships then bridge the gaps created by saturated routers via unicast relays.
This makes it sound like a dynamic pool of memory which can be allocated for different purposes. I was talking about an ASIC where the amount of available memory for these state tables might be fixed and not available for sharing with other parts of the system. You get whatever the designers back in 2015 decided was needed and the point is there's not much reason for them to spend area implementing a bigger memory when the reality today is that it's hardly used. So I get what you are saying but it's not necessarily possible.
My main problems over 15 years of working with SIP have been with "helpful" boxes in the middle tampering with my SIP messaging. NAT used to cause a bunch of problems, but these days I have workarounds for most cases that work great until the aforementioned middleboxes start "helping".
Give me a NAT-free network where the packet that reaches the far end is the same one I sent and my SIP systems will be quite happy.