Tag Archives: psu

How to set up XMeeting for use with Penn State’s videoconferencing systems

XMeeting, the Mac OS video conferencing software I previously reviewed here, works very well with Penn State’s mostly-Polycom video systems. Here’s how to set it up.

  1. Start by reviewing this H.323 video systems overview written by TNS’s video group.
  2. Open the XMeeting Preferences panel. We’ll go through the tabs from left to right.

    1. General: Enter your name or user ID. This will be sent to the video bridge or remote site and display under your image, so don’t enter something silly here. You might consider including the abbreviation of your campus or department.

      Automatically accept incoming calls if you want to do so.

    2. Appearance: Everything here is up to you.

    3. Accounts: Click the + under H.323 Gatekeeper Accounts to set up a new gatekeeper.

      Account name: gk.video.psu.edu or your choice

      Gatekeeper host: gk.video.psu.edu

      User alias/ID: You can enter any five-digit identifier that is not already in use on the gatekeeper. Room systems use their ISDN or conference phone number; I chose to use the last five digits of my desk phone number. This is the number that others will use to “dial” you for a videoconferencing session.

      Phone number: same as above (five digits)

      Password: leave blank

      OK.

    4. Locations: You can edit the Default Location or set up a new one. I just edited the default.

      First, a note. The H.323 protocol uses a lot of dynamic UDP ports and it can be really tricky to get it to work through a firewall or NAT. There are settings here for going through a NAT but don’t count on it working! Your best bet is to have your Mac on a public, non-firewalled IP address. Scary, I know.

      That said, let’s look at the sub-tabs for the Default Location.

      1. Network:

        Bandwidth limit: No limit

        NAT Traversal: Try different settings. I ended up choosing Use IP address translation and Automatically get external IP address. I believe this does help with NAT traversal by sending the external IP of the NAT in the H.323 headers, rather than the internal IP address.

        Firewall settings: I lowered the ranges to 30000-30010 and 5000-5099 so that I could open these ranges on the Mac firewall.

      2. H.323: Click the box next to Enable H.323. I cleared the boxes next to Enable H.245 Tunnel and Enable Fast Start. For Gatekeeper Account, choose the account you set up just a minute ago.

      3. SIP: Do not enable SIP.

      4. Audio: I used the default audio settings with uLaw as the first preference and ALaw as the second. Packet Time is also Default.

      5. Video: Click the box next to Enable Video. I set the frame rate to 30. You can lower this on a slow connection.

        The video codec selection is important. You may have to come in to this screen from time to time and change settings.

        H.264: works only with point-to-point XMeeting-to-XMeeting. It may work with other endpoints but doesn’t work with Polycoms (i.e. all of Penn State’s videoconference rooms).

        H.263: widely accepted. Looks pretty good. Works on all point-to-point calls I’ve tried, but does not work with the video bridge.

        H.261: the oldest and lowest-resolution codec, but most compatible. You have to select H.261 (and only H.261) when connecting to the video bridge (MCU).

        My normal selection is to just disable H.264 and then enable H.263 and H.261, in that order. When I connect to the bridge for a multipoint call, I disable H.263.

        I checked the box next to Enable H.264 Limited Mode.

      That’s it for the Locations tab.

    5. Audio: Choose your audio device from the list. It’s best to use a headset because otherwise you’ll get bad echo. If you get a USB or Bluetooth headset, once you’ve set it up you’ll have to select it from the dropdown lists.

      Uncheck Enable Silence Suppression and check Enable Echo Cancellation. These worked best for me.

    6. Video Input: Here you can choose which devices you’ll want to use for sending video. I have all three enabled. The Live Camera Module is normally what you’d use, but you can also send your desktop with the Screen Module or a static picture with the Still Image module.

    7. Address Book: Default settings.

  3. Hit Apply. XMeeting should register with the gatekeeper and display a green dot and the word Idle. You can press Command-I to get a status window verifying your registration and your directory (phone) number.

  4. Before you go on, if you’re using the Mac OS X firewall, go add the following two rules to the firewall for XMeeting to send/receive data and call setup information:

    H.323 call setup: TCP and UDP port 1720
    XMeeting data: TCP ports 30000-30010 and UDP ports 5000-5099

  5. Make a test call to the loopback: 39344. This will test two things: your audio/video (you should see and hear yourself) and your gatekeeper registration. If the call doesn’t complete by phone number, try dialing by IP address: 146.186.47.10. If that works, go back and check your gatekeeper settings and verify that XMeeting registered.

  6. Make a test call to the video bridge: 2222test. Remember that you will have to disable all video codecs except H.261 in order for video to work.

You can utilize the Apple Address Book to store the names and numbers of room systems or other desktop video users. A directory of Penn State’s public videoconference rooms is available here; click the link on each record and look for PSU Dial Number to see the directory number you should use to connect to the room.

What happened last week?

I picked a good week to go on vacation.

VoIP users–specifically, Unity voicemail subscribers–at Penn State received e-mail notices from Saturday the 18th through Tuesday the 21st that voicemail services were unavailable. Here’s some more technical information as to what happened.

Unity uses Microsoft Exchange as its back-end message store. PSU’s configuration of Unity is voice-mail-only (VMO), meaning that the Exchange part of the system is completely hidden from and inaccessible to the user. (A more popular configuration of Cisco Unity is unified messaging (UM), where Unity is integrated with a company’s Exchange mail system; users see both e-mail and voicemail (as attached sound files) in their Outlook inbox, and can also manipulate both voicemail and e-mail through the telephone interface.) When the Exchange message store goes offline, callers can still leave voicemail, but it doesn’t get delivered to a subscriber’s voicemail box until Exchange is up and running again. Last weekend, one of the two Exchange servers that serve Unity experienced a full mailstore disk, leading to some corruption of the Exchange database which, I’m told, took a while to repair. Subscribers whose boxes were on that particular server wouldn’t have had access to them during the repair time. But one of the great features of Unity is that it stored those new incoming messages until that Exchange server was back up, at which time all the new messages were delivered. No messages were lost.