Generically, SIP can use (at least) 3 types of transport. Office Communications Server supports TCP and TLS, with the latter being the default (actually, TLS runs on TCP).

There are three issues with UDP:

1) It is not encrypted, so you can’t ensure end to end security of SIP messages. There is no shortage of opinions on the security, or the lack thereof, of SIP (e.g. Cert® Advisory, ). As a text based protocol that is human readable (if ‘readable’ is the right word…it is not exactly prose…) there are privacy/security issues of sending SIP ‘in clear’. Furthermore, UDP allows for easier spoofing of packets since connection state doesn’t need to be maintained (remember Slammer?....UDP). This is why OCS customers are strongly recommended to accept TLS over TCP as the default SIP transport within the OCS network.

2) UDP has a fundamental flaw for large SIP messages: the size of the UDP datagram is limited to 1500 bytes, so a SIP message larger than that will be broken into two or more packets. The application layer (client or server) can receive the fragments out of order or a fragment could be lost (see 3 below). Since OCS SIP messages tend to contain various XML bodies, machine generated unique IDs (e.g. GRUUs), ICE candidate attributes, (etc.) they will normally span multiple packets.

3) UDP is a "fire and forget" protocol: this is to say that the transport layer does not consider lost or delayed packets. The onus of tracking messages for which no response has been received (and the generation of new requests) is left to the application layer: this leaves the application (the client or the server) vulnerable to overload situations. In bad network conditions, the best case scenario is a call setup delay. The worst case scenario is that the SIP network can reach a tipping point where the session timers are tripping for every transaction because the network elements are busy generating, or responding to, "retries" – a so-called "retry storm".

· Stateful vs. Stateless

· Authentication vs. no Authentication

· Encryption vs. no Encryption

An IBM Research article "Evaluating SIP Proxy Server Performance" examined, among other things, the impact of the choice of SIP transport protocol on SIP transaction throughput. The authors found clear evidence that stateless UDP with no authentication (and therefore no encryption) has, by far, the highest throughput. However, this modality is completely incompatible with a reliable and secure commercial communications service. Stateful transaction processing with authentication yielded a 43% transaction degradation when using TCP compared with UDP. However, the authors were using an open source proxy server and brought to light various performance issues that were implementation specific.

An IEEE Article "SIP Security Issues: The SIP Authentication Procedure and its Processing Load" further examines the security and authentication overhead issue and found only a 5.5% overhead to TCP vs. UDP. Their summary includes the comment:

The debate regarding whether or not TCP is inefficient/expensive has been going on for many years. An IEEE Landmark Article "An Analysis of TCP Processing Overhead" published in June 1989 disproves the notion that TCP (by then a 15 year old protocol) is an inefficient protocol. The fact that it is still in use nearly 20 years later suggests that the authors were correct and that current anti-TCP sentiment is based upon "techno-urban legend", rather than scientific analysis.

From a historical perspective, the original SIP spec, RFC 2543 (published in March 1999), states:

Note that equal priority was given to TCP and UDP. If you take a look at the current SIP spec, RFC 3261 (published in June 2002), you will see in section 18 the following statements related to SIP transport:

· We have evaluated whether or not UDP is a good protocol for a commercially reliable, secure and scalable communications service

· We have examined the evidence that TCP, with stateful transaction processing and authentication, is significantly less performant than UDP

· We have determined whether there is any basis for a bias towards UDP in the SIP standards

· We have also examined the support of UDP, TCP and TLS in the majority of enterprise and service provider SIP deployments

Recently, there have been some server changes made by two of our Public IM Connectivity partners Yahoo! Inc. and MSN (Windows Live). These changes will affect only those Microsoft Office Communications Server 2007 and Microsoft Office Live Communications Server 2005 customers whose external firewalls accept traffic on TCP port 5061 only from known IP addresses.

On May 22, 2008, Yahoo! Inc. moved their servers that provide instant messaging (IM) federation with Microsoft Office Communications Server 2007 and with Microsoft Office Live Communications Server 2005. As a result, The fully qualified domain names (FQDNs) and IP addresses for the Yahoo! gateway servers have changed. However, Yahoo! will not change the name of the service provider for instant messaging, which is configured in Microsoft Office Live Communications Server 2005 Access Proxy and Microsoft Office Communications Server 2007 Access Edge Server. This name will remain lcsap.msg.yahoo.com.

Meanwhile, MSN (Windows Live) has also changed the IP address for its LCS and OCS gateway. The name of the service provider for instant messaging will also remain the same, which is federation.messenger.msn.com.

As documented in the documentation for Live Communications Server 2005 SP1 and for Office Communications Server 2007, the recommended firewall configuration when federating with public IM providers is to allow any IP address to connect to port 5061 on the Access Proxy. However, certain enterprises prefer to enforce stricter firewall rules and restrict incoming connections to specific IP addresses. For those customers, the IP addresses that are used by the public IM networks need to be specifically allowed on the enterprise firewall. The following lists contain the new IP addresses that are currently used by each service provider:

IP address that is used by MSN (Windows Live)
• 65.54.227.249

IP addresses that are used by Yahoo!
• 76.13.22.8
 
• 76.13.22.9
 
• 76.13.22.10
 
• 76.13.22.11
 
• 98.136.47.8
 
• 98.136.47.9
 
• 98.136.47.10
 
• 98.136.47.11
 
IP addresses that are used by AOL (unchanged)
• 64.12.162.248
 
• 205.188.153.55
 
For further information about the Yahoo! Change, please refer to the following Microsoft KB article:

http://support.microsoft.com/kb/952209

For other Known issues that occur with public IM connectivity, please refer to the following Microsoft KB article:

http://support.microsoft.com/kb/897567

Hao Yan
Sr. Program Manager

 What is Enhanced Presence?

OCS 2007 allows its client applications to publish and subscribe to Enhanced Presence information. The enhanced presence infrastructure includes categories and containers. State, note, contact information, or calendar data (e.g. Free/Busy) are examples of categories. Containers are logical buckets into which the clients publish the categories of presence information.

A user can control what presence information other users see.  For example, if userA@fabrikam.com places userB@fabrikam.com in his Public container, userB can see only userA's name, e-mail address, and basic contact information. If userA places userB in his Personal container, userB can see detailed information like additional phone numbers, location etc.

OCS 2007 notifies watchers of presence changes for the container they have permission to access.  OCS 2007 supports this functionality through the use of Access Control Lists (ACLs) that map a user’s contacts into Containers.  Each end user can configure their ACLs via the “Access Level” or “Access Levels Management” view in the Office Communicator client.  ACL’s can define the set of users which can access a container based on a number of different criteria:

URI list (e.g. “userA@fabrikam.com”)

Domain List (e.g.“fabrikam.com”)

Same Enterprise

Federated Users

Public Cloud Users

 
Enhance Presence Feature Set
The main features of the enhanced presence model are as follows:
• Enhanced presence status
• Automatic sensing of activity
• Access levels
• Interruption management
• Multiple points of presence (MPOP)
• Extensible presence status
• Integration with Office applications

To enable enhanced presence for a single user

1. Click Start, click Control Panel, click Administrative Tools, and then click Office Communications Server 2007.
2. In the console tree, expand Communications Enterprise Edition Pools.
3. Expand the pool that contains the user you want to enable for enhanced presence, and then click Users.
4. In the details pane, right-click the user, and then Properties.
5. In the Properties dialog box, click Configure.
6. In the User Options dialog box, select the Enable enhanced presence check box.
7. When the enabling enhanced presence message is displayed, read the information, and then click Yes to complete the enabling of enhanced presence for the user.

What happens when a user is enabled for enhanced presence?

After you have enabled your users for enhanced presence, deploy Office Communicator 2007 to all client computers for these users. After a user is enabled for enhanced presence, the user can no longer sign in to previous versions of Office Communicator, Communicator Web Access, or Communicator Mobile.

Note: When you do enable Enhanced Presence on the user object following the migration, the user is still able to sign-in using legacy clients. When the EH aware client signs-in, the database information is upgraded to include EH information. From this point forward, the legacy client does not function.

Any user created in OCS 2007 pool\server already has enhanced presence enabled and cannot be changed.

An example of user activity category publication in Enhanced Presence

 
For more information regarding Enhanced Presence, please see:  http://communicatorteam.com/archive/2008/03/06/103.aspx
Important links:
OCS Enhanced Presence Model: http://www.microsoft.com/downloads/details.aspx?FamilyID=df0ba247-3884-43c7-a1e1-791d64b8bfa8&displaylang=en
OCS Resource kit: http://www.microsoft.com/MSPress/books/10482.aspx

Ram Ojha

Support Engineer

OCS 2007 Voice Connectivity

In Office Communications Server 2007 (OCS) there are 3 modes of voice calling:

1. OCS point to point: User A calls User B – call is VoIP end to end.

·         The endpoint could be Office Communicator (OC) or an IP phone (e.g. Polycom CX700)

·         Users could be either inside the network or roaming

·         Applies equally to multi-modal communications (i.e. IM, Video, Collaboration)

 2.OCS Federation-a User in domain A calls a User in domain B -   the call is  VoIP end to end over the public internet.

         ·    Federated calls still carry the same capabilities as point to point  calls described above – roaming, video, etc.

 3. PSTN to OC: a telephony user (PSTN, mobile, PBX) calls an OC user (or vice versa).

As previously stated, direct interoperability via SIP/RTP with Telephony Service Providers: aka “SIP Trunking” is not supported in OCS 2007.

What is “SIP Trunking”?

What do we mean by “SIP Trunking”?  OCG’s definition was laid out in the white paper referenced above.  The very fact that we needed to define it shows that there are many interpretations of this term.  To further complicate matters, OCG is not the only Microsoft Business Unit engaged in offering this feature – the ResponsePoint group (see: http://www.microsoft.com/responsepoint/default.aspx) is also shipping a SIP Trunk feature in their product and that has a slightly different technical specification to the one we are considering.

Jonathan Rosenberg has formally defined a “SIP Trunk” here: (http://tools.ietf.org/id/draft-rosenberg-sipping-siptrunk-00.txt ) in at least 4 different guises (and who am I to dispute that ?)  However, as a vendor of equipment that at some time in the future will support this function, it is incumbent on OCG to define what that function might be.

For Microsoft OCG, “SIP Trunking” is the use of SIP and RTP to pass telephony traffic from the enterprise network edge to a network service provider over an IP connection (i.e. without traversing TDM or circuit networks).  For cases where OCS is connecting to a Gateway or IP-PBX, as we qualify through the Unified Communications Open Interoperability Program (http://technet.microsoft.com/UCOIP), we use the term “Direct SIP”

Why SIP Trunking?

The value proposition of SIP Trunking for an OCS customer is:

1.       Not having to deploy, maintain, and operate IP-PSTN gateways on-premise either regionally or at remote offices

2.       Consolidation of data/voice networks (recurring costs)

3.       Reduction of call degradation by reducing the number of conversions of the call from IP to TDM (and back): note that most calls today are carried on a long distance network over IP transports.

The benefit of providing a SIP Trunking feature for Microsoft OCG is:

·         In the short term, offering OCS customers the choice of how to connect to the PSTN

·         The long term value of SIP Trunking is ultimately about creating a roadmap of federated multi-media communications via managed networks

The value proposition of SIP Trunking for Telephony Service Provider is to bring new value to their IP customers and to define a services-based UC value-proposition.  IP-centric service providers, on the other hand, are hoping to access a new channel for their services. 

Is SIP Trunking defined in a standard?

A technical recommendation for “IP PBX / Service Provider Interoperability” was created by the SIPconnect technical working group of the SIP Forum in 2006.  In many ways, this was a useful document, but it has not been broadly supported by equipment vendors or the network service providers.  Indeed, the actual uptake of SIP Trunking services has lagged far behind the apparent demand for such a service: the voice traffic traversing a SIP Trunk is currently a tiny proportion of total global trunked traffic.

In an attempt to address the adoption issue, the SIP Forum has launched a new initiative to revise the SIPconnect specification.  The Board of the SIP Forum recognized that Microsoft, as a leading vendor of unified communications solutions, could be a positive proponent of this effort.  In parallel, we realized that the number of service providers (wireline, IP and mobile) around the world was significantly greater than the number of PBX vendors.  We also came to realize that a minority of these Service Providers were currently offering SIP Trunking, and those who did were not necessarily compliant with the SIP RFCs.  Thus, the easiest way for us to address the issue of there being no defacto standard was to work with the SIP Forum to help define a standard that all vendors and service providers can support.

 The natural outcome of this mutual realization was that, at the invitation of the Board of the SIP Forum, Microsoft OCG has submitted a base specification for SIPconnect 1.1 (see: http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,45/Itemid,75/ ) and, at the time of writing, the document has been downloaded 300 times.  As of May 7^th, the Technical Working Group has started work on the effort, lead by Rich Shockey of Neustar.  The timelines for completion have not been finalized, but we hope that a final draft of SIPconnect 1.1 will be ready by the end of the year. 

Russell Bennett

Lead Program Manager

This week, Cisco introduced its personal telepresence technology to the world and announced their entry into the “market for in-person virtual communications with new endpoints for the personal office and large group meetings”.

It is great to see Cisco endorsing and supporting video conferencing for the masses, something we have long felt was critical for organizations to see real benefits. But I think there are some serious limitations to the approach they have taken.

Budget and environmental impact are just a numbers game at the end of the day. There are 100’s of information workers for every executive in the world, and the impact of any technology you can give to executives will be amplified if you can do it for everyone. To see these benefits, technology must be affordable and accessible to the masses.

High end telepresence units, costing businesses $300,000 a piece before network upgrades and annual maintenance, are out of reach for all but a privileged few in the organization. If you had that kind of telepresence system for every 50 information workers in world (an expected ratio of workers to meeting rooms), it would cost more than the GDP of Spain! But while we at Microsoft were out announcing plans for a $300 high def camera that would revolutionize the accessibility of high quality video conferencing for everyone, Cisco is announcing a stripped down version of its flagship telepresence product selling for $34,000 per unit.

I just don’t believe you get mass adoption when the price point evokes the question “should I buy this or the helicopter?”. The market is limited to literally a few hundred units. Units like the Polycom HDX 4000, for example, have been around for years at a fraction of the price. Stephen Lawson at IDG sums it up well when he says “The System 500 is not the consumer device Cisco envisions, which former Chief Development Officer Charlie Giancarlo last year predicted could be sold within two to three years for about US $1,000.”

In contrast, Microsoft RoundTable sells for $3,000-$4,000 and has already built up over 700 customers and thousands of units sold after launching in October 2007. For the price of two personal telepresence units which would enable two executives to talk to one another, customers can buy 20+ RoundTables, enabling a much larger number of people in remote offices to communicate and collaborate more effectively, while reducing travel costs.

I also don’t get the argument about personal telepresence “shortening sales cycles” or to “improve productivity”? Most information workers spend a significant portion of their time collaborating using applications and yet telepresence systems don’t have an easy way to share applications with others. Sales people are often out visiting customers or on the road and more and more workers are working from home these days, but they can’t lug around a 400 pound telepresence unit with them to stay connected. While the world is moving towards integrated collaboration and mobility, personal telepresence seems to be focused on very expensive video conferencing as the one trick pony.

At Microsoft, we have really focused on building video conferencing into common applications and user experiences to make business processes more engaging. Integration into tools such as Live Meeting and Communicator, which are compatible with many third-party audio and video devices, make it easy to use video conferencing for face to face conversation, multimedia document collaboration or telework.

Finally, to make a communication tool useful and impactful, you have to make it interoperate with common legacy equipment. This includes colleagues on Tandberg or Polycom systems, which account for over 75% of the installed base of video conferencing today. Or federated customers and partners for example. The lack of interoperability makes the system  an isolated island in a customers’ broader environment. If you are going to go for a telepresence solution, you should consider systems that interop with broader installed base, such the Tandberg Experia or the Polycom RPX for example.

It’s great to see that Cisco has joined the tide of video conferencing for the masses but clearly there is a long way to go beforeGiancarlo’s vision is realized.

Moz Hussian

Director of Product Management

The Prep Forest step requires a decision on the location for OCS Global Settings – you can choose to store these in the System container in the root domain (default and recommended) or the Configuration partition which is replicated Forest-wide.

Refer to the OCS AD guide for addition detail on Active Directory Global Settings and Objects.

http://technet.microsoft.com/en-us/library/bb803604.aspx

Factors to consider for storing OCS Global Settings:

1.       Do you have LCS?  If you do, the configuration partition option selection will be grayed out - choose the domain partition.  If you have server or MMC performance problems related to access to the root domain, follow the Tip below to move to the configuration partition. 

Tip

If LCS/OCS is running into issues because of poor root connectivity – this typically shows up in poor MMC performance and errors in LCS/OCS server event logs – you can remove LCS/OCS from the forest and then rerun Prep Forest choosing the configuration partition.  To remove LCS, first deactivate and remove all LCS and OCS servers, remove Prep Domain configuration (use the DomainUnPrep Action with LCSCmd.exe) and remove Prep Forest configuration (use the ForestUnPrep Action with LCSCmd.exe).

2.       Do you have a mature Exchange implementation? If you do, you are already replicating Exchange configuration settings Forest-wide so adding OCS configuration will not significantly impact your network – choose the configuration partition.

3.       Do you have a Distributed Forest with Domains or Sites where you will deploy OCS servers (all roles - Front End, Mediation server, etc. - except edge servers which are not domain joined) that do not have a reliable and fast connection to a root domain DC?  If so, choose the configuration partition.

4.       Do you have an empty root (a root domain that does not host users or servers) in your Forest?  If so, you can run into issues deploying OCS servers in child domains at a site without reliable and fast connectivity to a root domain controller.  This is similar to #3 above – choose the configuration partition.

5.       Is this a Greenfield installation?  If this is a new installation without LCS, Exchange or a complex Forest, then go with the default and recommended root domain naming context storage as this will reduce AD replication traffic on your network.  If you have a distributed deployment with sites/domains that now or in the future will house OCS servers without good and fast connectivity to at least one root domain DC/GC, you are in the same situation as #3 or #4 - choose the configuration partition. 

The following decision tree can be used as general guidance within the above context:

Andrew Sniderman

- Architect, Microsoft Consulting Services

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 publically 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 publically 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.

Understanding the design features and security mechanisms of the A/V Edge Server will enable a meaningful discussion between the IT engineers deploying OCS and the security team protecting the corporate network.

-Alan Shen, Senior Program Manager

Today, at VoiceCon 2008, we announced a global strategic alliance with Aspect Software to bring unified communications and software-powered voice to the contact center.  Under terms of the multi-year, global alliance, Aspect will integrate its .NET-based contact center suite, Aspect Unified IP, with Office Communications Server.  Over the next several years, Aspect will increase this interoperability and integration to deliver its next-generation contact center solution built on Office Communications Server’s voice call processing and unified communications capabilities. This new solution will be Aspect’s lead offering to both new and existing customers.  Aspect will also build a professional services practice to help customers deploy, customize, and manage Microsoft’s unified communications software in the contact center – and throughout the enterprise.  As part of the relationship, Microsoft is also making an equity investment in Aspect to accelerate development and adoption of the new offerings.  This announcement provides strong validation and momentum for Microsoft’s software-powered voice and unified communications platform. We’re excited about the opportunity to work with them, and bring them into our partner ecosystem.

As customers make UC platform decisions – including voice – we know that they are increasingly looking for end-to-end technology and services capabilities in all parts of their organizations, including the contact center.  Our joint roadmap with  Aspect’s Unified IP and Unified Command and Control platforms, and Microsoft UC (including OCS), will give customers a compelling alternative to PBX- centric models.  Contact centers have some of the most demanding voice and communications requirements, and there’s a huge focus on metrics and ROI.  This is a place where we believe there is great value for software-powered voice and seamless communications (voice, IM, presence, email).

We are seeing a growing number of enterprises and contact centers who will deploy the Microsoft UC platform and this is a key priority for us in this partnership.  As a result, as part of our announcement, Aspect is creating a new arm in their professional services group focused on Microsoft’s unified communications platform.  While this agreement will start in the contact center, it will extend to the enterprise communications needs more broadly through Aspect’s professional services arm.  By later this year, Aspect will have services professionals inside and outside North America - fully trained on the Microsoft UC platform including OCS (IM, Presence, and Voice) and Exchange 2007, and specializing in architectural design, implementation and integration.  Aspect’s software today is already used in more than 3,000 companies in over 55 countries, and through this professional services component of our alliance, Aspect will be equipped to help these companies deploy unified communications across their organizations for contact center agents, information workers, mobile and teleworkers, and all other areas of the enterprise for software-powered voice, conferencing, IM, and presence. 

Enterprise adoption of OCS is going strong.  More than 35% of the Fortune 500 have licensed OCS, and this portion of our Aspect alliance is sure to accelerate this adoption and the transformation of the voice industry away from the network PBX and towards software-powered voice.

Zig Serafin

General Manager

Microsoft Unified Communications Group

If you see yourself as a leader in the world of unified communications, I invite you to join me and my team at INTERACT 2008 as we look at how communications have evolved and how these industry changes position you for exciting new opportunities.

INTERACT 2008  is our exclusive event focused on building community among technology professionals, specifically, those who are evaluating and deploying Microsoft’s Unified Communications products. It will be held on April 8-10 in San Diego, California and will provide ample opportunities for attendees to network with one another. More than fifty members of our product  engineering teams will be there for interactive technical sessions, birds of feather sessions, and social events at what we’re calling “PubWorld”.  I’ll be there talking about what we’re seeing in the new world of communications technology and I’d like to hear what you are seeing and hear your feedback on our products.

If you see yourself as a leader in bringing Unified Communications technologies to your organization and taking your career to the next level, I’d encourage you to come.

Register today and use this special code [OCS08].

Be among the first 5 people to register, I will buy either your ITForum 2009 or TechEd 2009 registration pass.

See you in sunny San Diego!

Gurdeep

Register today! http://www.interact08.com/ with code OCS08

The planning tool provides you prescriptive guidance to get you started with planning your Office Communications Server 2007 topology. The tool asks you a series of interview questions about the features that you are interested in, as well as information about your organization. Based on the answers you provide, the planning tool draws out a recommended topology based on Microsoft’s Office Communications Server 2007 User Model that has been tested. The planning tool also provides customized links to the appropriate documentation to help you plan and deploy your topology.

You can download the Planning Tool for Office Communications Server 2007 at http://www.microsoft.com/downloads/details.aspx?FamilyID=06793661-cd69-4490-bb4b-e97dd271209d&displaylang=en

Remco Stroeken

Senior Product Manager

Add private certificate to the x509 Anchors keychain

1. Open keychain access application.

a. Use finder and find the HDD/Applications/Utilities/Keychain Access.app file and
start the application.

2. Add the X509 Anchors to the view, it is not in the view by default.

a. File menu
b. Add keychain

i. Open HDD/System/Library/Keychains/X509Anchors
ii. Caution not to use the HDD/Library/Keychain the file is not there.

3. Import the certificate into the X509 Anchors

a. Highlight X509 Anchors

Import the Root Certificate or Chain
b. Choose File->Import Items

c. Browse to find your Root CA certificates files you need to add then choose open.

d. Password prompt for root access

e. Pop up asking if you want to trust the certificate

f. Click Always Trust

Michael Wagner

Support Escalation Engineer

If you’ve read or begun to read the Microsoft Office Communications Server 2007 Resource Kit book, thank you! 

Now, we want to hear from you.  Let us know the good, the bad, and the ugly. J  Send us your constructive criticism so that we can address your information needs in the second edition of this book.  Tell us (the authors) what you like and dislike. What vital information is missing or confusing? 

NOTE   To correct specific incorrect information in the current Resource Kit book, send your feedback directly to MSPress, rkinput@microsoft.com, where corrections will be made. 

We want to hear back from you!  As a thank you, we will recognize your contribution in the foreword of the next edition of this book.  Please use the form below to submit your feedback.

Thank you!

Sometimes, when you upload a new .cab file for Microsoft Office Communicator 2007 Phone Edition or Microsoft RoundTable using the OCS 2007 Software Update Service Management Console Upload Software feature, the upload fails with an HttpException and the message Request timed out in the event log. The actual exception might vary, but the real reason is typically lack of resources on the WSS server. The resources lacking might be memory or CPU or a combination of both. You typically get the exception because the upload of the .cab times out. If you run into this try to add resources, i.e. more memory or more CPU capacity. If that is not possible here are a couple of tips you can use to increase the various time-outs.

On the server running the OCS 2007 Software Update Service Management Console you can edit the web.config file found in C:\Program Files\Microsoft Office Communications Server 2007\Web Components\UC Device Updates\Management Console. The web.config file controls the .NET requests the Management Console is using to talk to the WSS server. The web.config is per default read protected, so you have to make it writeable before editing it. In the file is a XML section called httpRuntime. This is the section you can tune. HttpRuntime is described here http://msdn2.microsoft.com/en-us/library/e1f13641(VS.71).aspx. In my test environment I'm using the following settings <httpRuntime maxRequestLength="900000" executionTimeout="300" appRequestQueueLimit="30"/>. This mean that the client will time-out after 300 seconds or 5 minutes.

Now you have changed the client time-out, but you typically also need to change the server side time-out on the WSS server. This is done by tuning the IIS time-out setting. The default is 120 seconds, but you can increase that by using the instructions in http://support.microsoft.com/default.aspx/kb/925083. On my test system I use 300 seconds. After changing the time-out stop and restart the web site hosting WSS.

Update 21-JAN-08: The above tuning is not the complete fix. The code itself is using other timeouts. We are investigating this and will report back.

Update 28-FEB-08: Please install the build released today  http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=889c542e-8b09-46c2-bd86-671c21668830. It should fix the issue with .cab upload error.

Jens Trier Rasmussen

-PRINCIPAL CONSULTANT II

Are you creating new diagrams or architecture drawings for your OCS rollouts? If so, take advantage of the new OCS 2007 Visio stencils. The icons in the stencil include all OCS 2007 components. They also include various individual functions that you can use to create your own new icons. The icons and your new icons can be added easily to the stencil.

http://www.microsoft.com/downloads/details.aspx?FamilyID=543705f6-d02a-436e-8b34-5c796550022a&displaylang=en

Remember to visit the OCS TechCenter to for more great information on all the UC products.

- Kevin Engman

  OCS Community Manager