Flight Deck

Official OCS/LCS product blog site

2008-04-15T23:50:00Z

I jsut wanted to make sure everyone was aware of the official blog site at http://communicationsserverteam.com/. Content is provided from many different resources from within Microsoft. I would definately bookmark this site!

Transitioning positions

2008-04-02T14:59:00Z

I wanted to let everyone know that I am transitioning to a new position and will no longer be working on OCS/LCS issues. While I'm very excited to be taking on the role of Team Manager within the Exchange Support organization, I will miss working with OCS/LCS.

However, I am working with the OCS Support Team to establish a blog site and transfer all of the content that is here to a new site. I'll post more details when we can get that in place.

Thank you all for your participation in this community!

- Chad A. Lacy

A/V Edge and Publicly routable IP addresses (Part ii)

2008-03-12T15:50:54Z

I happen to be part of an e-mail thread this week with several members of the product group and we were discussing the need for publicly routable IP address on the external interface of the A/V edge server. I wanted to share with you the information that Alan Shen, Program Manager involved with this technology, shared with us (this is some of the best stuff I've seen fully explaining everything):

The A/V edge server enables users to participate in audio and video connections from outside the corporate network, such as a point to point call, a conference, leaving a voicemail with Exchange UM, or making a PSTN call. Contoso has deployed the A/V Edge server with two NICs in the perimeter network. The “external” firewall separates the edge server from the Internet and the “internal” firewall separates the server from the corporate network. In order for the A/V Edge server to function correctly, the internal firewall must allow traffic to UDP 3478, TCP 443, and TCP 5062 (A/V authentication port). And the external firewall must allow bi-directional traffic to the following ports: UDP 3478, TCP 443, UDP 50,000-59,999, and TCP 50,000-59,999. No NATing behavior is allowed on either firewall. The external IP address must be publicly routable and the internal IP address must be routable from within the corporate network.
The ports on the external edge tend to undergo greater scrutiny because they involve more ports open to the Internet. This sidebar first explains why are there are so many publicly addressable ports and then how these ports are secured from an attack.

Why the A/V Edge has so many ports

Needing UDP ports

UDP connections are more resilient to packet loss than TCP. When a UDP packet is lost, the transport delivers subsequent packets without delay. When a TCP packet is lost, the transport holds all subsequent packets because TCP inherently must provide a reliable stream of data. This results in increased audio latency as we wait for the lost packet to retransmit and the rest of the TCP stream to "catch up".
Needing TCP ports
Although UDP is a more efficient transport, some clients can only reach the Internet via TCP, typically due to a corporate firewall policy. OCS also supports a TCP media transport in case a UDP path is not available. At the start of each call or conference, the two endpoints use the IETF's ICE protocol to dynamically choose the optimal media path available. This protocol prefers direct media paths over those that go through a media relay, and UDP paths over TCP paths.
Needing the port range at 50,000
The A/V Edge server is an implementation of the IETF's STUN protocol with TURN relay extensions. The standard requires this port range because it cannot assume the remote party has access to the same media relay server. Phone calls often traverse company boundaries, such as a federated VOIP call in OCS2007. Calls to standalone SIP devices are another example that one could envision as VOIP technology continues to evolve. The federated company cannot access the local company’s A/V Edge server via UDP3478/TCP443. The 50,000 port range allows media to traverse in a federated call. It is a port range instead of a multiplexed port to enable efficient relaying of RTP packets. A multiplexed port would require increased packet inspection and lowered efficiency of the server. As you’ll see below, the port range also increases the security of the A/V Edge Server.

Needing a publicly routable IP address on the external interface
The external A/V Edge requires a publicly routable IP address for several reasons. First, the A/V Edge server implements the STUN protocol, a mechanism whereby the A/V Edge server reflects back the IP address it saw from a user’s home router. This home router IP address is used to enable the use of efficient media paths using the ICE protocol and is also needed to ensure proper IP permissions are set on the A/V Edge server’s 50,000 port range. If the A/V Edge external address was behind a NATed IP, the A/V edge server would return that address instead of the address of the home router, leading to less efficient (sometimes broken) media paths and permission issues on the 50,000 port range. A second reason for publicly routable IPs is to support UDP load balancing. For real time audio/video traffic, UDP is the preferred protocol to transfer RTP packets. However, UDP is a stateless protocol, so some load balancers distribute UDP packets to the servers without any context for the current session. To mitigate this, the A/V edge server returns its external IP address on the first UDP packet of a media session, and OC or the Meeting Console client sends subsequent UDP traffic directly to that IP address instead of through the load balancer. In order for this mechanism to work, the external IP must be publicly routable. Note that supporting a publicly routable IP address on the external edge does not preclude a company from using a firewall. To the contrary, Microsoft recommends that all externally facing servers be protected with a firewall…provided that firewall does not NAT the IP address.

Needing a routable IP address on the internal interface
For the same reason of needing to support UDP media across load balancers, the A/V edge server returns its internal IP address on the first UDP packet of a media session, and OC or the Meeting Console client sends subsequent UDP traffic directly to that IP address instead of through the load balancer. That is the reason why the internal IP address needs to be routable from the corporate network. And to be specific, this internal IP address needs to be routable by client endpoints (OC/Meeting Console) as well as server endpoints (Mediation Server/AVMCU/ExchangeUM), given that OCS 2007 supports media point to point and via a conference.

Understanding the technology is not enough, though. Like most corporations, Contoso’s IT department is composed of emerging technology and network security engineers. Deploying the technology described above will only happen if it passes a security review. The following section discusses security aspects, first providing a summary of the mechanisms in place along with a more detailed description afterward.

Security Overview
Security of A/V Edge Server Auth Port TCP5062 (internal edge only)
OCS front end servers must provide a validly signed certificate whose subject name matches the FQDN of that server. (The OCS front end server performs the same check against the A/V Edge Server’s certificate.)

The OCS front end server FQDN must be on a trusted list of the A/V Edge Server. (The OCS front end server performs the same check against the A/V Edge Server FQDN.)
All SIP signaling is protected with 128-bit TLS encryption.

Security of UDP3478/TCP443(internal and external edges)
Port allocation is protected by 128-bit digest “challenge” authentication, using a computer generated password that rotates every 8 hours.

A sequence number and random nonce are used to deter replay attacks.

Media relay packaged messages (UDP3478/TCP443) is protected with a 128-bit HMAC signature.

Security of UDP/TCP 50,000-59,999 (external edge only)
Ports are allocated randomly within that range per call. An attacker needs to predict which port is active and complete an attack before the call ends.
Incoming traffic is filtered according to the IP addresses of the other endpoint’s candidates. Even if an attack finds a port in use, it must also spoof the correct IP address.
These two examples actually make the port range more secure. If all traffic was multiplexed through one port, it would accept traffic from IP addresses of all remote endpoints.
Security of end to end media
Media packets are protected with end to end SRTP, preventing any eavesdropping or packet injection.

The key used to encrypt and decrypt the media stream is passed over the TLS secured signaling channel.

Details of Security

Security of A/V Edge Server Auth Port TCP5062(internal edge only)
When a user logs in to OC or joins a meeting, it first acquires a username/password token from the media relay by sending a SIP SERVICE message over the TLS secured signaling channel. The last leg of this signaling path is a TCP connection from the user’s OCS front end server to the A/V authentication port of the A/V Edge server. This connection is only accepted on the internal facing IP address of the A/V Edge Server. Before accepting the SIP SERVICE request, a TLS connection must be set up where both sides validate the following: 1) Other server provides a certificate signed by a trusted authority, 2) the certificate’s subject name matches the FQDN of that server, and 3) that server’s FQDN matches one of the servers on a local trusted server list. (In fact, all servers in the OCS system perform this series of checks before allowing any communication to or from another OCS server.) If all three checks pass, the TLS connection is established and the SIP SERVICE command carried to the A/V Edge Server, which responds with a 200OK containing the computer generated username/password token.

Security of UDP3478 and TCP443 (internal and external edges)
The A/V Edge Server is an enterprise managed resource, so restricting access to authorized users is important for security and resource considerations. Communication on the UDP3478 and TCP443 ports is only allowed for clients that belong to the corporation managing that A/V Edge Server. A client uses these two ports to allocate UDP and TCP ports within the 50,000 port range for the remote party to connect to. Using the computer generated username/password obtained via the SIP SERVICE request, the client performs digest authentication against the A/V edge server to actually allocate the ports. An initial allocate request is sent from the client and responded with a nonce challenge message from the A/V Edge Server. The client sends a second allocate containing the username and an HMAC hash of the username and nonce. A sequence number mechanism is also in place to prevent replay attacks. The server calculates the expected HMAC based on its own knowledge of the username and password. If the HMAC values match, the allocate procedure is carried out, otherwise the packet is dropped. This same HMAC mechanism is also applied to subsequent messages within this call session. The lifetime of this username/password value is a maximum of 8 hours, at which time the client will reacquire a new username/password for subsequent calls.
Security of UDP/TCP 50,000-59,999 (external edge only)
The question arises, “Are 10,000 ports less secure than a couple well known ports?” One might think so, but actually the answer is no. From an attacker’s standpoint, each of those 10,000 ports behaves exactly the same. The more pertinent question is: “How secure is each of those 10,000 ports?” One consideration is that allocations in this range are chosen randomly. At any given time, it’s likely that many of these ports aren’t even listening for packets. (Contrast that with a well known port that an attacker can focus on.) The security mechanism in place on each port is to filter traffic for only those packets that originate from the remote endpoint’s IP address. This IP address is communicated over the TLS secured signaling channel, and packets from any other IP addresses are dropped by the A/V edge server. In this situation, having a range of ports actually improves security. Since a random port allocation happens for each call, this design forces the attacker to 1) deduce an active port, 2) break the TLS signaling channel, and 3) spoof the remote user’s IP address…all in the span of a single call. Can this port range be reduced? Yes, but doing so limits A/V Edge scale in peak conditions, and does not increase security. A reduced port range should factor no less than 6 UDP/TCP ports per user in a peak load condition. Can this port range be eliminated altogether for companies that don’t require audio/video federation? Unfortunately, this scenario has not been tested and is currently an unsupported configuration.

Security of end to end media
OCS clients perform signaling to the server using 128-bit TLS encryption with validation that the server certificate has a matching FQDN and is signed by trusted authority. This same mechanism is used by e-commerce sites. To secure the media channel, OCS uses the IETF’s SRTP protocol. The mechanism carries out a 128-bit key exchange over the secure signaling channel which the two endpoints then use to encrypt and decrypt the media stream via 128-bit AES. Even if an attacker can perform a “man in the middle” attack of the media path, no eavesdropping or false packet injection is possible.

Dual Forking with Nortel CS1000

2008-02-07T19:09:41Z

Many people have been asking for the capability to use OCS 2007 with their IP-PBX without the need of a media gateway. Nortel has been working closely with Microsoft to make this a reality with their CS1000 system.

For more information, go to http://technet.microsoft.com/en-us/office/bb735838.aspx

uploading handouts in Live Meeting 2007 fail

2007-12-29T00:12:47Z

Handouts in LiveMeeting 2007 are a way to transfer files to members of a meeting.

When the user attempts to upload a file to handout he will get the error Upload Failed.

If you check the Pwconsoledebug.log you will find the following error. This log is use to troubleshoot LiveMeeting 2007 and is on by default. It is located in %temp% directory on the client.

You will see the following error in the Pwconsole Log.

MC] 17:36:50:963 GMT [PID 2416] [THREAD 5044] [D] FileTransferProgressDialog::OnInit
[MC] 17:36:51:119 GMT [PID 2416] [THREAD 5044] [D] BlobManagerC::cRejectUpload
[MC] 17:36:51:119 GMT [PID 2416] [THREAD 5044] [D] BlobManagerC::threadAndServerDone
[MC] 17:36:52:525 GMT [PID 2416] [THREAD 5044] [D] FileTransferProgressDialog::OnDestroy

On the server side you would use the OCSLogger tool to log data from DataMCU component. We got the error below on the server side.

TL_ERROR(TF_COMPONENT) [1]04DC.08C8::12/13/2007-22:47:37.647.000003cc (DataMCU,Logger.error:254.idx(78))( 49296756 )class
placeware.apps.blobparts.BlobManagerS=BlobManagerS::sRequestUploadBlob - block all files

Resolution:

1. Bring up the OCS 2007 MMC

2. Right click the Pool

3. Click Application Properties

4. Click Intelligent IM Filter

5. Click File Transfer Filter Tab

6. Remove the Block all file Extension setting and Click OK

7. Restart Frontend Service

You can get more information on the Intelligent IM Filter in the OCS 2007 Administration Guide.

http://www.microsoft.com/downloads/details.aspx?FamilyId=CB7DC2DE-4504-484E-9229-BD8614BE0633&displaylang=en

single ocs 2007 front end interop with lcs 2005

2007-12-29T00:10:49Z

Here's another common problem I'm seeing when users attempt to setup interop between OCS 2007 and LCS 2005. With OCS 2007 we fully support an Enterprise Edition Front End server running without a hardware load balancer. However, with LCS 2005 we didn't. With LCS 2005 you had to have a hardware load balancer. Now, I said had to have, but there is actually a workaround. With LCS 2005 you could add a second IP address to the network card. Then associate the pool FQDN with one IP address and the server FQDN with the other IP address. This tricked LCS 2005 into thinking that the IP address for the pool was associated with VIP of a load balancer.

So, the problem comes in when you have LCS 2005 and a single OCS 2007 front end and that OCS front end isn't behind a hardware load balancer. OCS 2007 will work just fine. However, LCS 2005 will not like this configuration because it sees the pool and the server from the same IP address. So, to fix this you'll need to add a second IP address to the OCS 2007 server and associate the pool FQDN to one address and the server FQDN to the other. Once you restart the services, both should play nicely with each other.

A/V Edge Server with Load Balancer....still need public IP ADDRESS?

2007-12-21T16:23:00Z

The question has been raised a few times, now that some enterprises are moving beyond the testing phase of OCS 2007 and into large scale production, about the need for a publicly routable IP address when using multiple A/V Edge servers behind a load balancer. First, let me paint you a picture of what a scaled edge topology looks like:

So, you see in this picture we can have multiple edge servers feeding a particular site. In this example we have decided to scale the A/V Edge Server on its own hardware because we anticipate using a high volume of A/V traffic with extended users and federated partners. Since A/V traffic is the most resource intensive traffic, we want to make sure we can handle the load. So, we have load balanced two A/V Edge Servers. By the way, I'm borrowing this diagram from the Edge Server Deployment document. I highly recommend you set this website (http://www.microsoft.com/downloads/browse.aspx?displaylang=en&productID=5EFC9E68-052F-4CAB-9F29-02BFA05A8F2F) in your favorites because it will link you to all the documentation for OCS.

With that said, the question is, I know that the A/V Edge Server needs a publicly routable IP address. So, where do I put it? On the server or on the load balancer? The answer is...both! The A/V Edge Server FQDN needs to resolve to the public IP address of the load balancer. But the A/V Edge servers still need a publicly routable address as well because the allocated ports of 50,000-59,999 will be on the actual A/V Edge server's IP address, not the load balancer. All the load balancer does is select which A/V Edge server to use. Once that selection is made, that external client will communicate directly with the A/V Edge Server itself.

Partition address book by Organizational unit

2007-12-04T16:46:53Z

I happen to run across this rather unknown setting the other day while working with a customer and thought it was interesting. I'm not sure why anyone would use it, but thought I'd share the information because I'm sure someone out there has a need to do this. Say you wanted to limit your user's ability to search the address book and only allow it to return users and groups that are in the same OU as the user. You didn't want them to be able to search for anyone else. They can still IM other users, they just can't search for them. Well, there is a setting to do that. In order to do it you need to make the change in WMI. So, we have to do the following:

1. Click 'Start' -> 'Run' and type 'WBEMTEST'

2. Click 'Connect'

3. Under 'Namespace' type 'root\cimv2' and click 'Connect'

4. Click 'Enum Classes'

5. Click 'Recursive' and then 'OK'

6. Locate MSFT_SIPAddressBookSetting and double-click it

7. Click 'Instances'

8. Double-click the instance

9. Under 'Properties' find 'PartitionOutputByOU' and click 'Edit Property'

10. The default value is FALSE, change this to TRUE

11. Click 'Save Property'

12. Click 'Save Object'

13. Click 'Close'

14. Click 'Save Object'

15. Click 'Close'

16. Click 'Exit'

Now you need to restart the services. What you will see is in the output location for the Address Book files there will be new folders created that correspond to the OU structure in AD. Each of these folders will have their own set of LSABS and DABS files in them. When users logon to OCS, they will get the address book files that correspond to the OU to which their user account belongs.

A/V does not work externally

2007-11-27T01:05:00Z

I have seen several cases where the customer states that A/V works internally, but doesn't work externally. So, there are a few troubleshooting steps we can take to figure out the problem. First, are we using a publicly routable IP address on the external interface of the A/V Edge Server? Next, does your external firewall have UDP & TCP ports 50000-59999 open. Please check this carefully as earlier betas used the range of 50000-52999 (not 59999). The RTM version is 50000-59999. Finally, is the OCS pool referencing the A/V Authentication Service correctly. By default, the A/V Authentication service is listening on port 5062. So, first go to Forest, right click, go to Properties, then Global Properties and then click on the Edge Servers tab. You see a dialog page like this:

You'll see the bottom half of this dialog page is asking for the internal FQDN of the A/V Authentication Service and port. This will be whatever you set the FQDN of the internal interface for the Edge Server to be. It also asks for the port. By default, the Edge Server sets this to 5062. Once this is set here, then we have to select it in the properties of the A/V Conferencing Server. The Properties of the A/V Conferencing Server looks like this:

So, once you have it entered in Global Properties, you can select it from the drop down menu here. It should also be noted that as long as it is selected here, it cannot be deleted from the Global Properties. Once this is set, the pool now knows how to route A/V Authentication between the A/V Conferencing Server and the Edge Server. This type of issue will likely show up as a Failed on Media Connectivity error.

Another excellent blog

2007-11-26T06:00:00Z

I wanted to make you all aware of another excellent source of information. Jens has just sarted his blog and already has some great information. I've had to pleasure of working with Jens (virtually) on the OCS Beta for the past year and he has been a great source of information. Jens was way ahead of the curve on voice implementation with OCS. I would definately add him to your RSS feed.