Over the years, I’ve seen a number of different discussions about the directors, what they do, how they behave, and when we should use them. This post summarizes what I believe to be the salient points concerning the director component. Hopefully, this will serve to clarify rather than confuse.
One of the advantages of directors that we originally touted was that it “offloaded authentication” and relieved the pool of that duty. This is only partially true. The behavior is slightly different whether we are talking about external users or internal users.
Please consider the following diagram while I describe the traffic flow:
External case (the Chicago user in the diagram):
Internal case (the London user in the diagram):
Given the above understanding, let’s make some application. Here are the benefits of directors:
Security: In an environment with an access edge but no director, unauthenticated traffic will be sent to your production pool for authentication. The edge server will validate some SIP headers but it would be possible to craft a SIP message that gets through. This gives an attacker a direct path to your internal production server. The director component lets you isolate that unauthenticated traffic to a server that is less critical. Some organizations will find this very important even in single pool deployments.
Performance: For remote users, the director will proxy all SIP traffic. Without directors, you have to pick a pool that will proxy the traffic. This could have a performance impact to the users homed on that pool. The director is also handling authentication for those remote users.
I have been asked if there’s a certain number of users that your deployment should be supporting before it makes sense to have a director. It’s not the user-count that is important; it is whether or not the deployment has remote access and the number of internal pools. Let’s consider the four different combinations of these two factors:
Note: I should point out that in the above traffic flow descriptions, when evaluating how to handle the registration request, the director or the pool doesn’t really know if the user is external or internal. All it knows is whether it is the first hop or not (based on SIP Via headers). The default behavior of every OCS front end (whether in a director pool or a user pool) is to redirect traffic to the correct home server if it is the first hop and proxy the traffic if it is not. (This default behavior can be changed by modifying the RedirectMethods property of MSFT_SIPEsEmSetting.)
This post has been brought to you by Visio. Pretty drawing, huh?
this is an swesome post doug! and needed! thank you!
Very good post. Do we need Directors in a Hosted OCS 2007 deployment where all the users are external/remote?
@jm: Strictly speaking, a director is not required to get any scenario working. The question is: do the benefits of a director justify deploying one?
Since all of your users are remote, you may be less interested in the security benefit of preventing unauthenticated traffic from reaching your pool. You have no internal users to protect.
You should consider the likelihood that you'll have more than one pool in the future. Whether it's to provide additional capacity or for a side-by-side version upgrade, I suspect most customers will eventually have more than one pool. In that case, the benefits of the director become more compelling.
Great Blog post Doug. This really cuts to the heart of the issue about a Director's functionality and when it should be used.
Do I have to point the internal SRV-record towards the director if I only want it to handle authentication of my external users?
As I understand I specify the director as the next hop (internal) on the edge server. So all externa users will be sent to the director for authentication. Internal users shoud be able tp "by-pass" the director and go directly to the load balancer, right?
@Rikard: Yes, you are correct. There is no requirement that the SRV record for internal users point to the director. If you only have one internal pool, it makes perfect sense to point the internal users directly to it. If you have more than one internal pool, pointing users to the director begins to make more sense (but still not required).