After a bit of trial and error, and some help from PSS, we at PointBridge now have a fully function Office Communication Server 2007 environment! The implementation went quite well, with the exception of one spot: getting audio and video conferencing to work with external users.
For some reason, we couldn’t have LiveMeeting 2007 bridge in the audio and video of people who were outside the network. I tried for a long time to get it to work, but users kept getting the following error:
Voice and Video Error Information
—————————
Your audio and/or video session was unexpectedly disconnected.
Action required: Please rejoin audio and/or video.
—————————————————————————
More details for technical support:
—————————————————————————
Message Category: 2 (kNetworkError)
Message Code: 8 (kMediaConnectivityFailure)
Root Cause Error: 0x00000000
Root Cause Component: kNetwork
Audio Input Device: SoundMAX Digital Audio
Audio Output Device: SoundMAX Digital Audio
Video Input Device:
Audio Muted: Yes
Media State: (43,2,2,10,0,0,Reinviting)
AvMcu Uri: sip:INTERNAL_FQDN_OF_OCS_MACHINE:5063;transport=tls
Avmcu Reachable: Yes
Acp Reachable: No
Diagnostics Information:
—————————————————————————
To copy this message, press CTRL+C or press ALT+PRINT SCREEN.
—————————
OK
—————————
I did a couple network traces on the client machine and for some reason – the clients were trying to connect to the private IP address of the OCS server. As I knew from previous troubleshooting with OCS, this typically happens when you can’t reach the OCS edge service from the outside. But this was making no sense to me at all: everything else was working fine.
I hacked around for a while and then I started getting a sneaking suspicion as to what it was: the OCS documentation says that you must use an external, publicly routatble, non-NAT address for the A/V edge service. I originally laughed off this requirement. To me, it seemed like a requirement for non-network savvy people. But I had confidence that a little firewall/network knowledge would allow me to skirt this "crazy" requirement. WRONG!! I was in for a treat.
Here was my conversation with PSS:
PSS: "You need a public IP".
ME: "Dude, that is nuts! Everything else works, including audio/video ad-hoc conferences".
PSS: "Hmm, yeah, it might seem crazy, but that’s the way it works. I can’t tell you why, but if you want to fix your problem, do it!"
ME: "This seems weird"
PSS: "Didn’t you see the requirement in the docs?"
ME: "Yeah, but I didn’t take it seriously"
PSS: "Um, you should. It says it like 20 times."
ME: "Ok, I’ll try it. But I won’t like it."
I tried it. And it worked. I called PSS back.
ME: "Dude, you were right."
PSS: "It wasn’t me, it was in the docs!"
ME: "Yeah, but it seems so weird that you can’t use NAT"
PSS: [some varation of : "I don’t cook ’em, I just serve ’em"
Now, to be fair, I did have a some trouble getting the public IP on my Edge server. I posted this in the MS forums, but it’s worth reprinting here…
Here’s what I had to do to make it all work:
1) Configure the Edge server with 1 "internal" IP address for the inside edge (10.x.x.x)
2) Configure the Edge’s second NIC with 3 "external" non-NAT IP addresses (38.x.x.x)
3) Configure an interface on my sonicwall firewall for "transparent" mode, which passess traffic through from the WAN interface without NAT.
4) Plug the second NIC of the Edge server into this new interface on the firewall
5) rebind all the edge services to their new external IP addresses
Step 2 is the craziest. I had to configure every external interface on the edge with a publicly routable IP. I tried to just configure the AV edge server with the public IP (leaving auth and webconf with NAT IPs), but that did _VERY_ strange things to the routing table on the Edge server.
The edge started getting confused as to how to route outbound traffic because external traffic was coming to it from two sources: the SIP traffic was coming from one of the internals (bound to the auth service) and the AV traffic was coming in on the external (bound to AV edge). There can be (should be) just 1 default gateway on a windows box, so all the traffic on the way back out was exiting the external interface (my default gateway). Well, that broke all the SIP traffic cause it was coming in to the internal IP and exiting the external. I couldn’t make it work.
So I bit the bullet and configured all the edge IPs as their public addresses.
This defintitely solved the problem.
I can only see 2 other ways to do this:
1) Have a separate edge A/V server. Configure 1 internal IP (10.X.x.x) and one external (38.x.x.x) – that way you can have a separate server for webconferencing and A/V authentication with their NAT IPs (10.x.x.x) on the external interfaces.
or
2) Have 3 different networks on your Edge server:
– 1 External (38.x.x.x) for A/V Edge service
– 1 Internal (10.x.x.x) for the edge internal interface
– 1 DMZ (172.16.x.x) for the web conf and A/V auth
– add persistent static routes for 172.16.x.x and 10.x.x.x on your edge server
The problem with this is that you use two interfaces on your firewall: 1 for the external transparent A/V edge, 1 for the DMZ.
For now, I am sticking with my solution; it works well. I just am still slightly unsettled by needing to put convert all the IPs to publicly routeable ones. There’s no harm in doing it, because the firewall is still only allowing certain ports through, but it still seems strange to me.
OK – I’ve learned my lesson. Follow the directions even if they seem like they won’t work. If it’s printed a few times in one doc, it probably isn’t a typo. Got it! I am going to try to figure out why NAT isn’t supported (I still want to know) but for now I’m okay knowing it isn’t supported, cause my system works. And it’s awesome!
