End-user perspective on small office tools & technology

Wideband Audio In Gizmo5

The past couple of days I’ve been playing around with the Gizmo5 client on my desktop. It’s actually pretty slick. I wanted to see if I could pass a wideband call to/from Gizmo5 from my Polycom 650s or Eyebeam. So far no joy. There seems to be a problem completing a call from Gizmo5 to OnSIP via SIP URI. The call rings on the IP650 but cannot be answered. Not certain if its an issue with Polycom firmware or both devices being behind the same NAT and trying to connect directly. I’ll try and work that out when I’m back at home.

A quick search of the Gizmo5 knowledgebase reveals that they support a handful of codecs, including the GIPS iSac, the wideband adaptive codec made popular by Skype. In their early days if there was one big reason why Skype calls sounded better than the PSTN iSac was likely it.

It is curious that Gizmo5 goes to the trouble of supporting iSac, which I presume has some cost when they don’t support G.722. That could be implemented with little or no cost as there’s no licensing or royalties involved. Here’s the list of codecs they support:

  • GSM — fixed bit rate, not loss tolerant, narrow band (8khz sampling rate).
  • iSAC — variable bit rate, loss tolerant, narrow and wideband (8 to 16khz). Varies based on Bandwidth, packet loss, delay*
  • iLBC — variable bit rate, loss tolerant, narrow*
  • PCMA — fixed bit rate (8kHz sampling rate)
  • PCMU — fixed bit rate (8kHz sampling rate, high band width)
  • IPCMWB — 16 kHz sampling rate*
  • EG711 (enhanced g711) — fixed bit rate, loss tolerant, narrowband
  • iPCM — fixed bit rate, loss tolerant, wide band.*

Those marked with * are from the GIPS codec family. Their other software component offering is “NetIQ” an adaptive jitter buffer and packet loss concealment module.

This seems like an oversight so I’ve shot an email to Gizmo5 suggesting that G.722 support be added in the future. They might well consider G.722.1 under it’s new royalty-free terms. But royalty-free is not the same as zero cost so that may be a stretch.

This Post Has 3 Comments

  1. Hey Michael,

    I am sure you may have seen this new product release, but just in case here is the link:
    http://blog.tmcnet.com/blog/tom-keating/voip/snom-820-voip-phone.asp

    It says it will support ” wideband to the handset” and the other cool part is WiFI. I’ve played with the LG SIP video phone that supports WiFi and that is a nice to have in some cases.

    Sorry if this is a little off topic…
    I enjoy your blog thanks for all your great info.

    Eric

  2. Yes, snom’s latest looks very nice. Since their KlarVoice handset is not available for the 300 series this new model may be the first snom phone that can really handle G.722 properly.

    I’m not sure which snom phone I’ll end up with but I’d like to get one to further play with G.722 interoperability.

  3. Two things: 1) I believe GP uses an API for their codecs which GIPS provides that includes all the GIPS codecs plus the basic standards. It’s not likely that it includes a competitor to their iSAC codec, so adding that might be tricky.

    2) Contacting yourself from GP to another local phone/softphone SHOULD bounce RTP data through their rtp proxy (if you look at the old GP SIP messages, you’d often see an extra tag in there so you’d know that said something like RTPProxy: Yes — not sure if it’s still in there). However, optimising an rtp proxy for recognising when two phones are behind the same NAT can be problematic at best. GP gets around this wen using GP to GP clients on the local net by using Rendezvous, I believe (which is why it installs on the local machine when you install Gizmo Project). The logic behind a determination WITHOUT help might be difficult. Of course, if you disable STUN, then the local client won’t sent your external IP address and GP will likely hard-code the RTP proxy into the mix, assuming NAT for both sides.

    My recommendation for a test would be to disable STUN on at least one of the devices when registering with GP for the purpose of the internal network test.

    SIP and NAT are still an incredibly tricky mix. At IdeaSIP we (perhaps improperly, but you have to draw the line somewhere) assume a single user per home for direct REGISTER calls, and that people with many users in a home are more likely (currently, anyway), to have Asterisk running as their local PBX to ferry the registrations off to IdeaSIP. It means that direct calling between users on the same local network simply won’t work unless your local router knows how to hairpin the RTP data (which is unlikely). Well… technically, you can CALL the user on the same NATted network. You just won’t get any audio. This is, in part, because we require STUN to connect to IdeaSIP (it minimises problems with people sending private IPs as their REGISTER info) — the SDP info gets filled in with the public IP (assuming STUN is working), and that requires the audio portion of a direct call to go from inside the net to the external interface of the router, and back inside again. Most can’t handle this. Registering all the local extensions/users with Asterisk means calls between users can be handled fully locally, and calls exiting the network will be ferried via the local PBX.

    Again, these are BIG assumptions, and sometimes incorrect. But I’d say in 90% of cases, they’re valid assumptions, and so we build for them. It’s still unusual in a consumer-level scenario to find, say, two people living in the same house with two phone lines that call each other instead of just walking up the stairs. Does it happen? Absolutely. But when you reach an intractable problem that occurs in very few cases, you can spend all your time building for it, or you can simply accept that there are some situations for which an elegant solution does not yet exist and move on.

    I know. I go on and on. But stuck in a CEO role all day, sometimes it’s nice to blather on about the tech side of things.

Comments are closed.

Back To Top