[GameBreaker64]

Hope I'm not buggin y'all with all these posts, haha

I'm interested in learning more about the "InPerson" software that came bundled with IRIX 6.2(?) in terms of what it could do and how you would get connected to a video conference.

I'm also wondering if it would be possible to use the software in 2021.

[weblacky]

Most of the software back then was H.323 and was somewhat interoperable. It wasn’t as standardized as SIP later on. I don’t know if people got Microsoft netmeeting to fully work with inperson. I was told that audio was pretty standard but the video compression used was all over the place. And so full interoperability was extremely rare with products back then. But I was led to believe that there had been some success using an H.323 gateway and manually connecting net meeting an in person and getting audio to work. But don’t quote me on that.

[GameBreaker64]

Wouldn't it be easier to get two SGIs connected?

[Raion]

InPerson could be still used, but it's highly insecure and would only be useful over a LAN. Using it over the web is like being a wounded gazelle on the serengeti.

[weblacky]

Wouldn't it be easier to get two SGIs connected?

Then I wouldn’t be answering the original question about newer software and interoperability.  Duct tape is great when it sticks to itself.  

cheers!

[Shiunbird]

I've been doing video conferencing infrastructure, and now including Zoom and Teams and etc, for 12 years now... so, what I've seen.

H.323 is actually better, compatibility-wise, than SIP.
It won't support any modern features, but at least it works for sending audio and video.

The call negotiation messages are also very easy to read and you can find out even without much experience whether you had issues negotiating a video codec, or an audio codec, or issues with transport.

Now the industry is moving on the direction of trying to lock every into their walled gardens, and interoperability became a pain.

I have full access to SIP proxies and H.323 gateways, and bridges where to land test calls on.
If you would like to test, let me know. I can give you a few H.323 gateway IPs to dial, log in to the backend and we can see what happens.

[weblacky]

I was led to believe (though never read any RFCs) that H.323 was simpler but didn’t rigidly define video codecs, so each company used what they wanted, leading to video interoperability problems. I was also lead to believe that interception and redirect were trivial on H.323 so call security wasn’t even a real thought (old world border firewalls with complete trust internally). So when the idea of the Internet came around you’d be expected to secure your branch to branch network connections, then just run insecure telephony through it.

But from person to person over the internet, SIP had encrypted options for either (or both) protocol and transport. Though many products don’t use them anyway…

So really I was under the impression that H.323 was abandoned purely on the later point (external calling security).

I think SIP interoperability is much better thought out but video codec selection was still an issue when I was last dealing an with these systems 8 years ago (build your own for internal business use).

I think client to client is still predominant, instead of customer PBX supporting video to client.

I think inPerson was a great attempt, perhaps too early but a great one. If PCs had been a little more powerful and webcams were as cheap as they are today (with cheap peripheral interfaces that supported those videos speeds) maybe SGI would have found themselves in the video conferencing business as well.

But when you needed another high end UNIX station to complete the call, I’d expect only meeting room-level conferences at that point. Not desk to customer or the like.

[Shiunbird]

Both H.323 and SIP are very painful - it's just a different kind of pain.
Think of something like POSIX - yes, each implementation will return different values and have different limits depending on the platform, and there's a narrow "safe" window that you can assume to work well.

For the devices made on the last 15 years, H.263/G.711 for audio is a safe bet. For the last 10 years, H.264 and H.264-HP are safe for video. You get screwed when you try to run far end camera control or content sharing. In general, compatibility is getting worse.
Now with Zoom and Teams, the pain is greater than ever. Zoom offers a SIP gateway implementation called Zoom CRC, but Microsoft has no native SIP. You need to work with a partner and use their solution. Cross-platform implementation is usually basic WebRTC with no advanced features and awful user experience.
It makes me miss the ISDN days. We still have ISDN in our bridges for the odd client that doesn't trust anything on the Internet and we use it once per month.

H.323 handles traversing firewalls worse.
SIP, as far as I know, does not handle payload encryption on the protocol level. This is still up to the implementation. Most will do AES-256.
Also, if you are talking to video bridges, the value of payload encryption is questionable, because the bridge manager can watch your stream from the management console.

I'm also interested in testing the HP-UX conferencing solution, but I don't have all the supporting hardware.
I have an audio card here wanting to be installed.

For test, I have multiple meeting room level codecs at home, and I can hook them up to my TV in no time. I've got Poly G7500, X50, X30, some old Cisco box and in the office I have older Polys. I have full access to 4 RMX bridges - one of them is DEV and I can change settings to test.

For VoIP, you are right, our internal calls are unencrypted. However, this is mostly to avoid throwing thousands of perfectly functional phones that only support unencrypted G.711 in the trash bin. And once you go to PSTN, well, it's just a plain call. I don't know what the plans are, because I stopped dealing with VoIP 5 years ago. The Avaya system is very impressive in capabilities, and it offers a full text-based management interface that I love. No awful web UIs are required to get the system fully configured and running.

Our video conferences are fully encrypted internally and externally, but we use our bridges nowadays only to support locations that have issues connecting to Zoom (Middle East, Russia, Sri Lanka, for example) - we intercept the dial strings, modify them to land the calls and a script in our bridges makes a leg out to Zoom. So when a colleague in Sri Lanka dials zoomcrc.com, we automatically cascade it through our network.

For example, in Sri Lanka, government doesn't allow VoIP. Carriers end up just blocking SIP and, well, it ends up breaking video conferencing as well. We route calls to a SIP gateway and that's it.
In Russia, the problem is different. It's forbidden to import equipment that supports AES-256 so instead of making unencrypted calls over the internet we make an internal call to our bridges and a leg out to Zoom from somewhere in the EU.

It's honestly a complete mess and dealing with the vendors is extremely painful. They are very resistant to offering part of the solution and always try to sell you the whole pie. Not to say that meeting with sales reps is AWFUL because they don't have answers to any technical questions ever.

[weblacky]

In my defence, my referencing to encryption centered about SIP TLS (SIPS) and Secure RTP (SRTP). But as I mentioned it's often not used. I think for the most part SRTP is more likely than SIPS (due to interop)...but again I haven't used this stuff in 8 years..that's when I got out of it all in my old employer.

I do understand your current thoughts on interop being an issue with "clients" (ZOOM, Skype, Teams, etc...) As person-to-person becomes the "known" technology, the backend standards start to become less flexible in terms of interop. Many people hyper-focus on Endpoint to Endpoint...but fail to understand that for a business infrastructure to be made to work...you have to somehow come up with these bridges from one solution to another. If you can control last-mile (to end-user) you just use normal VoIP phones and Smartphone client software.

As you described, once you have endpoint problems..it's now all about conversion...not something I'd like to tackle.

I think you are right in suggesting a new walled-garden. We were doing so well in 2010 with standards...but now in 2020+ it's about endpoints for working at home and NOT being part of the branch infrastructure controlled by IT. That last hop is a killer due to the mercy of whatever ISP and POS router the employee has at home. Not to mention VoIP timeliness when your employee "shares" they home ISP with other members.

Nearly all consumer (even high-end) routers do not have SFQ or other guaranteed bandwidth (reserved) queuing to ensure latency. The real issue I've seen is the lack of adaptability with non-dedicated lines throughout. A messy business to be sure when the internet has no such tagging or fairness guarantees (no time constant). I was hoping that by now ISPs would support primitive VLAN tags or IP TOS headers as an optional feature to allow EASY use of VoIP devices from consumer homes and just use the correct "marking" technique and BAMN, instant priority.

I feel like we are really behind without some basic marking ability in our own home ISPs. I could operate so much smoother if I could MARK streaming video, versus remote desktop, versus HTTP download via my ISP (perhaps more than just at the gateway). Sure I can mark it internally, but the best I can do is FIFO on my ISP modem and hope that means something. If the marking went all the way through it would affect the respondent's upload and MY upload in response, something we can in fact both control, locally.

If we developed the internet to have some kind of priority lanes accessible to customers, we could at least use simpler connections to achieve a greater user experience without additional home equipment or computation by the end-user.

[indigofan]

I believe that you can do point to point, for H.323 best to route through a gateway, for call routing.. If anyone has on hand a US Robotics Total Control Hub, with the telephony gateway installed on Windows NT, you're off to the races. I am sure that there are more modern services to tap into, but have not been involved in any of this stuff since the late 90's.