Anyone try this yet and compare it to Hangouts on a poor connection? I'm constantly dealing with colleagues in another office where the internet connection is sub-par.
Slack Calls: Now with video
91–100 of 127 posts
Re: Slack Calls: Now with video
#92Counting number of options I might have when trying to do a video/voice call with someone:
1. Facetime
2. Skype
3. Hangouts
4. GoToMeeting
5. Slack
6. Facebook
7. WhatsApp
The fragmentation / lack of standards we had with IM is now a reality in video/voice calling as well.
Re: Slack Calls: Now with video
#93Counting number of options I might have when trying to do a video/voice call with someone: 1. Facetime 2. Skype 3. Hangouts 4. GoToMeeting 5. Slack 6. Facebook 7. WhatsApp The fragmentation / lack of standards we had with IM is now a reality in video/voice calling as well.
Also line, wechat and webex, iMessage.
IMO, competitions, choices with communication SW are very good for all users. I like all the apps, options, free, ads, paid, webbase, mobile, etc. No need for unified standard.
Re: Slack Calls: Now with video
#94lovely. the sooner i can remove skype from my life the better. that said, why can't any of these phone systems deal with the use case of two people trying to call each other and then simply auto connect the two calls? why does one side have to drop the call and answer the other?
I can't stand Skype's sign in/closing experience. Linking my original Skype account with a Microsoft email definitely broke something. Also why do I have to tell it to exit in 3 different ways to get it to finally exit for real!?
Re: Slack Calls: Now with video
#95Earlier quoted context omitted.
I know dynamically linking to libraries is the Linux way, but wouldn't just bundling the correct version of glibc with the Slack app solve the problem? Sure, the app gets bigger, but a missing feature is worse than that, I would imagine.
You cannot sanely statically link glibc. This is because libnss effectively has to (by definition of how /etc/nsswitch.conf works) be able to `dlopen` arbitrary files you don't know about, so statically linking it has no meaning or breaks that (you pick!). For this reason, it's painful-to-difficult to bundle glibc with a program, and it WILL break some networking configuration options if you do it, which is probably…
> The right solution to this, which for some dumb reason they don't want to do
WebRTC requires GCC >= 4.9, which doesn't ship on RHEL or old Ubuntu, and upgrading to it would also upgrade the built glibc, which defeats the point.
Re: Slack Calls: Now with video
#96Earlier quoted context omitted.
Probably a wide band or at least mid-band codec. One thing I learned working with VOIP is people perceive quality based on what they have been using recently, which for most people is the absolutely horribly stepped on audio of skype, cheap voip, or the cellphone network. Carriers have pretty much let their baseline audio quality go to \ \ \ \ because no one cares anymore. (Remember the Sprint pin-drop campaign?) Now…
Their dropped packet handling is far far better than Skypes as well - in a dodgy wifi situation linq and skype are all but unusable while slack is crisp.
That is Opus actually, it can conceal up to 30% packet loss from the user, versus traditional G.711 where you can hear 1% packet loss quite easily.
Re: Slack Calls: Now with video
#97Has anyone else noticed how pristine the audio quality of a Slack call sounds? I wonder how they optimized it. My company's voip, and Lync, and Skype all fail to deliver the same kind of call quality. I've only noticed / admired better call quality when making a call within Cisco to another employee. I don't use video much but I hope they've done as good of a job as they did with audio.
Lync is awful, it does some adaptive optimization that always seems to kill audio quality. VoIP at work (At least with Cisco) is usually some grumpy telecom guy disabling HD audio or the company skimping on telephones.
HD Audio (G.722 & Opus) is essentially not supported outside internal networks sadly.
Re: Slack Calls: Now with video
#98Earlier quoted context omitted.
It sounds like you've extensively tried to work with both, correct?
Indeed. I'm the seemingly rare creature who was able and willing to jump through all the IRC hoops but can still understand the people who maybe can't but certainly won't.
I dunno, I get people on IRC all the time using web clients, there aren't many hoops to jump through to get on it. You don't even have to register either.
Re: Slack Calls: Now with video
#99Counting number of options I might have when trying to do a video/voice call with someone: 1. Facetime 2. Skype 3. Hangouts 4. GoToMeeting 5. Slack 6. Facebook 7. WhatsApp The fragmentation / lack of standards we had with IM is now a reality in video/voice calling as well.
Also tried Zoom (zoom.us) which worked quite nicely for small groups.
Re: Slack Calls: Now with video
#100Has anyone else noticed how pristine the audio quality of a Slack call sounds? I wonder how they optimized it. My company's voip, and Lync, and Skype all fail to deliver the same kind of call quality. I've only noticed / admired better call quality when making a call within Cisco to another employee. I don't use video much but I hope they've done as good of a job as they did with audio.
Slack audio calling is using webRTC tech. On Chrome, you can check out statistics and configuration for how they set up the call by going to chrome://webrtc-internals I checked, and it looks like they are using pretty standard webRTC settings. The audio is compressed with Opus codec. They look to be limiting the bitrate to 40 kbps. (I'm not sure, but I thought Chrome default limited the AVERAGE bitrate to 40 kbps, no…
> A lot of older VOIP tech used compression that severely limited the frequency response.
I don't think that's accurate. Most conventional VoIP (in North America) uses G.711µ, whose purpose is to provide the IP correlate to logarithmically companded PCM encoding used in a normal DS0 (digital PSTN loop carrier).
DS0s are not compressed. Logarithmic steps result in some approximation, but that has more to do with the mechanics of digital sampling and quantisation than bandwidth savings. In fact, G.711µ is an uncompressed 64 Kbps codec, exactly equivalent to the synchronous data rate of a DS0 in the circuit-switched world. This is in sharp contrast to codecs like G.729, which, to simplify things, use waveform translation tables to achieve significant compression (down to about 8 Kbps in the case of G.729 specifically). Some less patent-encumbered variants do similar things.
The frequency response is limited by the standard PSTN bearer channel range of ~3.1 KHz, which is for historical reasons. That was the most frequency response one could reliably squeeze out of copper analog lines, for both physical and economic reasons tied up in the history of the telephone system. Since the primary concern of the VoIP industry was—and still is—interoperation with the traditional telephone network (PSTN, or Publicly Switched Telephone Network), adopting codecs which translate readily into that world with a minimum of CPU-hungry transcoding and reframing makes sense.
WebRTC, as a peer-to-peer multimedia calling mechanism intended to resemble something like Skype, is more purely a product of Internet-orientated thinking and has a rather post-PSTN mindset. WebRTC endpoints, like IP phones supporting wide-band codecs (e.g. G.722), are not constrained by the requirement to talk to the old-school telephone network. So, they can use codecs like G.722 and Opus.