Dear VC Vendors: Please Fix Dialing

This post has been simmering in my brain for a while, especially after another season of Read Around the Planet and all the dialing challenges that come with it. I know that my technical knowledge is not complete, and this may not be accurate within a few months or years. Still, I think it needs to be said. I invite anyone who would like to correct me to please use the comment feature to add your knowledge and opinions, especially the vendors.

The Problem of Dialing

So here goes. As the vendors try to find ways around the limitations of IP address dialing, firewalls, etc., they are creating a nightmare of dialing problems for those of us who use VC to connect 95% of the time “off net”, off our network, and with schools around the world. Here’s my view of the current situation.

Polycom IP##Extension Format

Polycom’s firewall traversal unit means that outsiders dial the IP of the unit and then ## with the alias of the endpoint behind the firewall. This allows for one public IP to be shared with other units. This is true for the V2IU, and I don’t know about the new Video Border Proxy. In addition, the RMX uses this format for it’s meeting rooms, and the MGC can be set up this way for meeting rooms as well.

However, here’s where it doesn’t work:

  • Tandberg endpoints can’t dial this format
  • Tandberg MCUs can’t dial this format
  • Anything registered to a gatekeeper can’t dial this format because gatekeepers strip off the ##extension.

Currently on the RMX, if someone can’t dial the IP## Extension, and you can’t dial out to them, there’s no way to get them into the conference.

TANDBERG Extension@IP Format

TANDBERG endpoints behind a border controller are dialed using the extension@IP format.
Here’s where this doesn’t work:

  • Polycom endpoints can’t call that format
  • It’s intermittent with at least my TANDBERG MCU. It worked before Read Around the Planet but then since then I can’t call 3 different places in 3 different states that use this format. Haven’t had time to open a ticket yet, but it’s annoying that nothing changed that I know of and it just quit working.

TANDBERG Codian Far End Camera Control

On the MCU side, the Codian MCU, recently bought out by TANDBERG, most often uses an entry room where the enduser uses far end camera control or tone dialing to enter the correct conference. It remains to be seen how TANDBERG will adapt the Codian technology. The far end camera control method works on most endpoints, except:

  • Getting far end camera control to work through another MCU is problematic at best. The tones or far end camera control usually aren’t passed from one MCU to the other.
  • Some legacy endpoints such as VTel (yes those are still out there in schools)

School Scenarios

Now I can just hear in my head all you techies telling me, why are you doing endpoint to MCU to MCU to endpoint dialing? Why are you dialing off net? Why don’t you just dial out to these problematic sites? Why doesn’t everyone just get rid of those “legacy” units? Well, here’s what’s happening in schools.

  • Dial out only. Fairly often, techs are nervous about NATing a static IP for H323 videoconferencing, so they only allow dialing out. If you can only dial out and you can’t dial the other site’s weird dialing, then what?
  • Dial out only through MCU. Many educational service agencies have a WAN where their schools can only connect out through the MCU. Hook two schools together this way, and you have to do endpoint to MCU to MCU to endpoint. A large number of my calls are like this. Sometimes not even by technical necessity, but because it’s easier to support the local schools by scheduling calls for them.
  • Dialing Predominantly Offnet. I wish I could just drill it into engineer’s heads that if a school or district is getting videoconferencing for enrichment/content providers/collaborative projects etc, they will do almost ALL their calls off net. But the vendors seem to be thinking mostly about internal corporate communications on a corporate network. All the while they enjoy and promote big events such as Read Around the Planet and Kids Creating Community Content which require offnet dialing to outside schools.
  • Legacy Lasts a Long Time. We also tend to get VC equipment and expect it to last 10 years. VC is still most often purchased with grant funds (not sustainable) and schools can’t drop $6-10K every 3 years or so to upgrade their VC equipment. It’s just not happening!

Gatekeepers

Some sales guys have told me that dialing should only happen through gatekeepers. I realize that the higher ed / Internet2 / Megaconference community has the Global Dialing Scheme (GDS) which sometimes helps. However:

  • Schools not familiar with GDS don’t want to neighbor to each other’s gatekeepers. Imagine in the two weeks of RAP, the huge participating schools with 120 connections. That’s 120 different sites to call in two weeks. Should we neighbor to every single other site we connect to. It’s insane to expect this.
  • Many small schools just get an endpoint only. They don’t have an educational service agency or statewide network to connect to a gatekeeper and get on GDS. How will they dial?

It’s not realistic to expect that the K12 VC community would be able to do dialing through gatekeepers only. The necessary structure isn’t in place, and probably won’t be anytime soon.

Dear VC Vendors: Please Fix Dialing

So, this is my plea to the vendors. Please think of us in the K12 community where we make most of our calls off our network. Surely corporate customers need to call off their network too. When will H323 videoconferencing work like a phone (platform independent, just works)?

I don’t know what the answer is. But dear vendors, would please get over your proprietariness and make the dialing work between all H323 endpoints? Please!

14 replies on “Dear VC Vendors: Please Fix Dialing”

  1. Danny Maas says:

    I agree fully Janine that a dialing standard really does need to exist, or at minimum several standards that all work cross-platform will work. In Alberta’s K-12 system we have very few Tandbergs, so the issue isn’t as huge for us as it might be otherwise. If we want to bring in a Tandberg unit to a meeting room on our Polycom MGC 100 we’ll either get our bridge to dial out to that site or have the site dial in to our bridge, but it still requires a bridge operator to manually put that participant into a meeting room.

    One interesting thing though – in Alberta (as you know) we have a Polycom MCU and probably 70-80% Polycom endpoints (Sony 10-15%, Tandberg probably 5%) and we all dial each other on our Supernet VPN using extension@IP. Only those outside of Supernet attempting to dial a meeting room dial with IP##meetingroomextension. I saw you mention how you say Polycom doesn’t like extension@IP and that doesn’t seem to be the case with us.

  2. Janine Lim says:

    Danny – does that extension@IP work though when you’re gatekeepers are all neighbored together? I noticed in one of your projects you said outside schools should use the IP##meeting room. So it still requires the gatekeeper?

  3. James says:

    I think since TANDBERG bought the Codian bridge, it is only time before they upgrade their endpoints to allow ##extension dialing. At least it would make sense for them to do this. For one, it will make their endpoint work with their new bridge. Plus TANDBERG seems to be the one that is unlike the others, so this will solve the extension dialing. Any other new player wouldn’t want to deviate from the established standard at this point. Of course, I don’t think this will help the folks with TANDBERG bridges. I wouldn’t bet on TANDBERG upgrading the software on them since they bought the Codian.

    • Sean Lessman says:

      The dialing scheme using ## is a non-standard format that is only used by Polycom. The format per the ITU standard is extension@IP or extension@domain which is what TANDBERG has always used. To accomodate PLCM endpoints, the TANDBERG Border Controller, Gatekeepers and VCS will accept the ## format when dialed from a Polycom endpoint. However, as TANDBERG believes in using the ITU standards to keep products reliable and with reduced complexity, we have no plans to introduce the non standard Polycom dialing method to our endpoints. Supporting additional non standard methods increases unnecessary complexity and reduces the reliability of the deployment.

      Sean Lessman
      Senior Director Advanced Technologies
      TANDBERG

  4. Janine Lim says:

    Thanks so much for your comment, James! I hope, for the sake of VC, that you’re right about them upgrading. However, I did hear from TANDBERG that they intend to use what they learn on the Codian to improve their TANDBERG MCUs. Hope that’s true too!

  5. Danny Maas says:

    @Janine – How Alberta Supernet works is that all school jurisdictions (64 of them) are all connected to Alberta Supernet’s private VPN for videoconferencing traffic. Each jurisdiction has a V2IU to allow VC traffic in and out of their own secure jurisdiction networks, and the V2IU has an IP address, with each codec in that jurisdiction getting an extension. Schools dial other schools across other jurisdictions by dialing extension@IP, and the traffic goes first to the external IP of the V2IU of that particular jurisdiction, and the extension finds the exact endpoint.

    The way our meeting rooms work is currently through the Alberta Education MCU (Polycom MGC 100). There’s a Supernet feed coming in (199.216.149.3) as well as a separate feed from Internet (139.142.188.3), so those both within Supernet as well as those dialing from outside Supernet can reach the same meeting room. The Internet sites indeed dial with 139.142.188.3##extension (the VCRLN meeting rooms Terry D has set up are all 4-digit extensions, 3300 through 3306). I’m able to dial extension@139.142.188.3 from my Xmeeting client on my Mac, but most seem to need to dial IP##extension for those meeting rooms.

    The standard we decided to go with for extensions for Alberta school jurisdictions are 10-digit numbers using E.164 dialing, almost like telephone numbers.The first 3 digits tell what area of Alberta you’re dialing (499 southern Alberta, 799 northern Alberta), the next 7 are to identify the jurisdiction plus the endpoint itself. That 10-digit number gets put in the E.164 settings in the codec, and when the codec registers to the V2IU the first time a table entry goes in the V2IU for that codec.

    As far as I know nobody can dial in to Supernet directly, and some jurisdictions either buy a second V2IU just for Internet calls, or some just change settings to allow Internet calls coming in. The meeting rooms are probably the easiest way for Supernet/non-Supernet sites to call directly, and Alberta Education has also set up an Internet peering proxy which many (if not all) jurisdictions have table entries in their V2IU for. 99@IP address in many if not all jurisdictions will allow Supernet sites to dial out directly to a site outside of Supernet (no dial-in). The only time that’s a problem is when the site you’re dialing also doesn’t allow dial-in, in which case the call is either bridged through one of Alberta’s 2 MCUs or, the jurisdiction uses a bridge of its own. We’re seeing more and more jurisdictions purchasing Polycom RMX bridges, as the cost has come down so much from the MGC days.

    I don’t have anywhere near the technical awareness you do Janine, so I hope my lengthy (*yawn*) explanation makes some sense and answers your question.

    • Janine Lim says:

      Danny this was very interesting. It sounds to me like the V2IUs on your Supernet are neighbored to each other or to a Supernet gatekeeper. Do you think that is the case? Would that be why the extension@IP works only inside?

      By the way I turned on threaded comments to make the comments on this post easier to follow.

  6. Graham Walsh says:

    Hi Janine

    Just reading your post from a link on Twitter. The Polycom V2IU was renamed to the VBP, so the functionality is exactly the same.

    With regards to dialling methods, speak with your Polycom Reseller or Polycom local support as dialling E.164@IP is not a problem with the VBP.

    Also, you can use digit modifcation on the VBP to help overcome users who can’t get the # symbol or via verse use the @ symbol instead of the #.

    Cheers

    Graham

    • Janine Lim says:

      Graham, thanks so much for adding that! If a school has an older V2IU can they still do the digit modification?

      Also do you have any thoughts on gatekeepers stripping off the ## extension?

      Appreciate your time to answer!

      Janine

  7. Ken Martin says:

    Completely agree with the need for true compatibility. We’re having difficulty at the moment with a Codian bridge attempting to dial our RMX directly to a meeting room.
    We’ve had some success in other cases by putting the Polycom RMX meeting room (conference ID) in the ALIAS slot under participant properties on the Tandberg side. Not sure if that’s possible with the Codian bridge doing the dialing, though.

    • Janine Lim says:

      I’m pretty sure it’s possible, Ken. I don’t have a Codian, but I’ve had other Codians dial with the IP ## format by setting up a gateway and using that. From what was described to me, it included a gateway setting, and then adding the participant with the conference ID to use the gateway. Another person described it as using the e.164 field. Experiment! 🙂 I think half the problem is the documentation of how to dial all these weird ways is poor.

  8. Madell says:

    Janine,
    I just want to let you know that I agree. This has to be solved, and solved quickly. All vendors and I do mean all, not just the big ones, need to be on board to make video conferencing seemless. I love the Read Around the Planet time, the connections and the program but I do find it technologically challenging since my experience is so limited. We need to make video conferencing

  9. Vince says:

    Janine,

    apoligize if this is already posted somewhere…related to the experimentation of dialing e.164.

    Polycom – no GK – IP##e.164
    Polycom – GK – no DNS – e.164@IP
    Polycom – GK – DNS – e.164@FQDN
    Tandberg – DNS – e.164@FQDN
    Tandberg – no DNS – e.164@IP
    etc….

    Anyone have all of this explained?

Leave a Reply to Sean Lessman Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.