The Session Traversal Utilities for Network Address Translation (STUN) protocol is an integral component of the Audio/Video Media Relay service. It provides the routing information and signaling that is needed to establish a secure media connection for all endpoints that are involved in audio/video communications. This article explains the integration of the new STUN/Traversal Using Relay NAT (TURN) (STUN/TURN) extensions with the Microsoft Office Communications Server 2007 R2, A/V Edge Server and how the STUN/TURN protocols are used to communicate the various phases of setting up a media allocation for an audio/video communication between unified communications peers.
Author: Mike Adkins
Publication date: December 2010
Product versions: Microsoft Office Communications Server 2007 R2, Microsoft Office Live Meeting 2007
Microsoft Office Communications Server 2007 R2 provides A/V Edge services that allow Unified Communications (UC) clients at remote locations on the Internet to share A/V conferences with users that are located on an internal Office Communications Server 2007 R2 network.
This article discusses the Session Traversal Utilities for Network Address Translation (STUN)/Traversal Using Relay NAT (TURN) and Interactive Connectivity Establishment (ICE) protocols that are used by the Microsoft Office Communications Server, A/V Edge Server and the Microsoft UC clients, a description of the network processes that are used to establish secure A/V communications between the internal and remote UC clients, and what to look for in captures of network traffic that can be used to determine the establishment of a secured A/V session with remote UC clients.
To troubleshoot connectivity issues for the A/V session between internal and remote UC peers, you need to gather network captures and logging data from the Office Communications, A/V Edge Server and from each of the UC clients that are involved in the A/V conference. For the analysis of User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) STUN with TURN extensions, network traffic, I recommend using Microsoft Network Monitor 3.4. You can download it from here.
To view the contents of the Microsoft Office Communicator and Microsoft Office LiveMeeting 2007 client-side logging, you can download and install the Office Communications Server 2007 R2 Resource Kit Tools locally on the client computer. Use the Snooper.exe tracing tool to open and view any SIP logging that was gathered from the clients. You can also use Snooper.exe to analyze any SipStack logging taken from the A/V Edge Server.
The network capture and SipStack logging in this article were gathered from the remote access server and the A/V Edge Server during the initiation of an A/V session from a remote UC client. This information depicts a step-by-step setup of a media port allocation by the A/V Edge Server for audio and video communications between a remote UC client and an internal UC client.
STUN and TURN integration with Communications Server and Microsoft UC Interactive Connectivity Establishment (ICE) protocol clients requires that the remote client acquire the credential and connectivity information that it needs to contact the A/V Edge service STUN/TURN server. This credential and connectivity information is made available to the remote client through the existing SIP connection that exists between the Communication Server 2007 R2, Access Edge Server, the remote client, and the internal client on the Communications Server network. When the remote client requests an A/V session with an internal client, the remote UC client will send a SIP Service request for credentials to the Office Communications Server Audio/Video Authentication (RTCMRAUTH) service. When the SIP Service request for credentials is responded to by the RTCMRAUTH service, the remote client will receive its A/V Edge Server fully qualified domain name (FQDN) and port information (TCP Port 443 and UDP Port 3478) along with its user name and password credentials. These credentials are used to secure the information that is passed between the STUN/TURN server and the remote client for the upcoming STUN/TURN negotiations that use UDP Port 3478. These credentials are also used for sharing the encryption key information by using TCP Port 443 through the Office Communications Server A/V Edge (RTCMEDIARELAY) service. This secures the information that is passed between the internal and the remote clients during their A/V conference as shown in Figure 1.
Figure 1. Information passed between internal and external clients
Connecting to the STUN/TURN server requires that a STUN/TURN session be initiated. The remote client sends a STUN/TURN Allocate Request packet that contains the Username and MagicCookie attributes, and perhaps an Unknown attribute to the IP address of the external public interface of the A/V Edge Server. This initial Allocate Request packet won't contain the needed credential information to begin the STUN session with the A/V Edge Server. This causes the STUN server to return a STUN TURN Allocate Error Response packet that contains the following error information: "The request did not contain a message integrity attribute." This Allocate Error Response packet also contains the Nonce and Realm attributes that are passed back to the STUN/TURN UC client to use in its subsequent STUN/TURN Allocate Request packets. The value of the Nonce attribute is used for replay protection. The value of the Realm attribute should be the domain name of the STUN/TURN server's provider.
The remote UC STUN client begins the STUN/TURN session by sending the initial STUN Allocation request to the A/V Edge Server's A/V Edge (RTCMEDIARELAY) service. Notice that the Username attribute is passed to the STUN server. The STUN Server caches the user name information for future credential matches. No other attribute information is passed to the STUN server during the initial Allocation request.
The information in Figure 2 was gathered as a network capture taken from the A/V Edge Server by using Microsoft Network Monitor 3.4. Figure 2 is an in-depth look into the IP header information of the UDP port 3478 STUN packet and locates the STUN header information.
Figure 2. Username attribute passed to the STUN server
Because the initial Allocation request didn't contain a Message-Integrity attribute, the STUN/TURN server had to respond with an Allocate Error Response. This is a default mechinism that proves that physical connectivity between the client and the server is possible. Notice that the Nonce and Realm attributes are being passed back to the STUN client as shown in Figure 3.
Figure 3. Nonce and Realm attributes passed back to the STUN client
By default, this initial transaction fails, proving that DNS resolution for the STUN/TURN server's FQDN does work. The client can route requests to the A/V Edge STUN/TURN server. Now it is up to the client to provide the Allocate Request packet to the A/V Edge Server STUN/TURN that contains the attribute for Message-Integrity. The Message-Integrity attribute is a Message Digest 5 (MD5) hash of the user name and password credentials that have been provided to the UC STUN client as the secure SIP response for its Media Relay Authentication Service request and the Realm attribute that was provided to the client by the server's initial Allocate Response. Now the subsequent STUN/TURN Allocate Request packet is sent to the A/V Edge Office Communications Server Audio/Video Edge (RTCMEDIARELAY) service STUN/TURN server from the client that contains the value for the Message-Integrity attribute. It is formulated as follows:
Message-Integrity = MD5(username ":" realm ":" SASLPrep(password))
The RTCMEDIARELAY service STUN/TURN server now uses the user name information that was passed to the server from the remote client in the first Allocate Request packet. The STUN/TURN server performs the same MD5 hash of the user name that it cached from the previous Allocation Request and the realm and password information that it received in the subsequent STUN/TURN Allocation Request from the client. The credentials match, and Message-Integrity authentication is established between the remote Communicator client and the RTCMEDIARELAY service STUN/TURN server.
The user name and password credentials that are initially provided to the remote client through the SIP service response from the RTCMRAUTH service by using the Office Communications Server, Access Edge Server prior to any STUN/TURN negotiation has a duration period of 480 minutes. If the A/V session lasts for 480 minutes, the user name and password information is updated and the new credentials are passed to the clients. This forces the client to re-negotiate the STUN/TURN information that is needed to establish a new media session between the A/V peers.
The TURN client now passes the newly created Message-Integrity attribute back to the STUN/TURN server as shown in Figure 4.
Figure 4. TURN client passing Message-Integrity back to the STUN/TURN server
After the Message-Integrity attribute has been successfully negotiated, the A/V Edge service STUN/TURN server responds to the remote client with an Allocate Response packet as shown in Figure 5. This packet provides the remote client with the information that it needs to continue with additional STUN/TURN requests and the subsequent real-time transport protocol (RTP) A/V session between the remote and internal clients. The Allocate Response packet attributes list begins with the MagicCookie attribute and ends with the Message-Integrity attribute. Because of the design of the STUN/TURN protocol, the MagicCookie attribute is always the first attribute in the list for each STUN packet. Each STUN Response or STUN Request packet contains the Message-Integrity attribute as the last attribute in the list. The Message-Integrity attribute can be inserted into any STUN Packet as the last attribute on the Attributes list.
Figure 5. STUN/TURN server responds to the remote client with an Allocate Response packet
The Allocate Response packet also contains the following attribute information:
The XORMappedAddress attribute also contains Port and IP values that represent the reflexive IP Address and port combination of the client. The reflexive address is best defined as the IP address of the client or the IP address of the closest NAT to the Office Communications Server A/V Edge Server that the subsequent STUN/TURN Allocate Request packet from the client has passed through. Now when the remote client receives the Allocate Response packet from the Office Communications Server A/V Edge Server, the ICE client has gained knowledge of the absolute IP address of the Office Communications Server A/V Edge Server and the IP address of the closest NAT to the Office Communications Server A/V Edge Server.
The client can install permission for its allocation on the STUN/TURN server by sending data to a peer (or by doing certain other things). After a client's permission has been installed, any peer with the same IP address (the port numbers can differ) is permitted to send data to the client. Permissions have a time-out value of 5 minutes and can be refreshed by the application.
By design, the ICE client prepares the IP address information that it has acquired locally from its network connections and from the valid STUN/TURN Allocate Response packet. It provides the STUN/TURN server's IP address and the reflexive IP address of the client's NAT that is in the closest proximity to the STUN/TURN server. This IP address information is formatted as a component that can be passed between clients by using the SIP Invite and SIP 200 OK Session Description Protocol (SDP) information. An ICE-enabled client formats the acquired IP address information as part of an "a=candidate" component. The ICE client formulates two preferred components-one for use with RTCP and one for use with RTP. Each "a=candidate" component consists of the following:
Each candidate consists of at least two components and each local network interface on the client represents a candidate.
Note Keep in mind that the client may need to use TCP as its transport. Additional candidate information can also be made available for the TCP transport. The components' component ID value provides each component and IP address combination with a form of unique identification. This provides the client a way to specifically determine the route for RTP/RTPC communications when the same private IP address is shared by ICE hosts on separate subnets that may use the same private IP address class as shown in Figure 6.
Figure 6. A private IP address is shared by ICE hosts
TURN extensibility was added to STUN RFC 3489. This extensibility is consolidated into STUN RFC 5389 to provide the ongoing definition of the protocol. The following information may or may not be part of the STUN session that precedes the A/V session that you are researching. These TURN extensions may not be needed for every media allocation that is performed by A/V Edge Server's RTCMEDIARELAY service Binding Response packet.
Whenever clients receive a correct Allocate Response packet from the A/V Edge Server, they can provide other internal or remote clients with a STUN/TURN Binding Response packet. The client can now receive A/V traffic on the designated ports that are bound to either UDP or TCP that will manage the A/V session.
Prior to A/V data being bound to either UDP or TCP transports for routing between the remote and internal UC STUN/TURN clients, the clients must succeed at sending the A/V Edge Server a STUN/TURN Send Data packet. The Send Data request also includes DESTINATION-ADDRESS and Data attributes. These additional attributes contain the IP address of the peer and the encrypted Data request information, respectively. This request triggers the STUN/TURN server to check for a pre-existing allocation that matches the sending client's information. If the allocation is not listed on the STUN/TURN server's permissions list, the IPv4 address of the client can be added to the permissions list. The STUN/TURN server can pass the contents of the Send Data packet's Data attribute to its peer.
Upon the completion of the Binding Response and the Send Data procedures, the media allocation for the A/V session between the peers will be prepared to begin the relay. At this point, the STUN/TURN server sends Data Indication responses to the A/V session peers. The STUN/TURN Data Indication packets contain two specific attributes-RemoteAddress and Data. The RemoteAddress attribute contains the IP address of the sender that has the transport established for the A/V session. This can be the IP address of the A/V Edge Server or the IP address of a client. The Data attribute contains A/V information that is bound to a TCP or a UDP transport. At this point, the client is ready to begin sending information between the IP endpoints by using the transports that are established in the prior Binding Response.
This section provides a description of the network connectivity that the internal Communicator clients share with remote Communicator clients that are in the same A/V conference. A conference is defined as when three or more Communicator peers take part in the same session.
When conferencing, the internal Communicator clients have to use the SIP SDP MediaRelay connection information that is returned in the SIP 200 OK response to the RTCMRAUTH Service request as shown in Figure 7. This request was made by the internal Office Communications Server Enterprise Edition pool or Standard Edition server to the internal interface of the A/V Edge Server by using TCP Port 5062 as shown in Figure 7.
Figure 7. Request to the internal interface of the A/V Edge Server by using TCP Port 5062
The returned network address information is used by the internal Communicator clients so they can connect to the RTCMEDIARELAY service by using TCP port 443 and UDP port 3478 on the internal interface of the A/V Edge Server. This connection is needed for the internal and remote UC clients to request and receive the needed hash-based message authentication code (HMAC) key information that is used to encrypt and decrypt each of their RTP A/V media sessions. Before the media session can take place between all the Communicator clients, the internal Communicator clients must make a successful STUN/TURN Allocate Request-Allocate Response with the A/V Edge Server STUN/TURN server by using its internal interface as shown in Figure 2. The procedure is similar to the one that is used by remote Communicator clients. The internal Communicator clients have to acquire a valid STUN/TURN MessageIntegrity attribute that allows them to bind their soon-to-be A/V communication to a specific transport protocol-either TCP or UDP.
In this kind of Communicator A/V conferencing scenario, the STUN/TURN Binding Response takes place between the internal Office Communications Server, Enterprise Edition pool or Standard Edition server and the Communicator internal or remote clients. This allows the IM Conferencing Server (IMMCU) or the A/V Conferencing Server (AVMCU) on the server running Communications Server to manage A/V communications between it and all the Communicator clients that are involved with A/V conference. However, if the A/V traffic is between just one internal Communicator client and one remote Communicator client, the STUN/TURN Binding Response takes place between the two Communicator clients. The A/V session is between just these two Communicator peers. In any case, it requires more than two Communicator clients to initiate an A/V conference.
To make sure that Communicator peer-to-peer A/V communication functions properly, we must ensure that the internal interface of the A/V Edge Server can route the TCP Port 443 and UDP Port 3478 traffic that initiates from the internal Communicator client back to that client's network as shown in Figure 8.
Figure 8. TCP Port 443 and UDP Port 3478 traffic
It is important to mention that the Windows Office Live Meeting 2007 client is strictly a conferencing UC client. When just two of these UC clients are communicating, they will initiate a conference by using the RTCDATAMCU service on the internal Office Communications Server Web Conferencing server. However, the Live Meeting client supports A/V conferencing with both internal clients and remote clients. The internal Live Meeting client does not require access through the internal firewall when the client is involved in a multi-client A/V conference with other remote Live Meeting clients. In this A/V conferencing scenario, all UC clients connect to RTCAVMCU in a hub-and-spoke fashion as shown in Figure 9. Because of this, using Live Meeting for remote A/V conferencing can provide a more efficient security model for the internal firewall configuration.
Figure 9. UC clients connect to RTCAVMCU
The management of establishing a secure and reliable media connection between internal and remote UC clients is provisioned by the STUN/TURN protocols. Microsoft has integrated the extensibility of SIP signaling with the use of the STUN/TURN protocols to provide the allocation of secure and reliable A/V media connections between the Microsoft Unified Communications endpoints that participate in an A/V conference. Having a basic understanding about how these protocols coordinate the secure establishment of a media connection allocation that will be managed by the Office Communications Server A/V Edge Server is the first step that is needed to troubleshoot connectivity issues between internal and remote UC clients. Proper use of troubleshooting tools such as OCSLogger.exe and Network Monitor 3.4 (see Additional Resources) can quickly identify where the connectivity problem lies. After it is discovered, the needed corrective action can be taken to gain reliable connectivity between all the UC clients that will participate in the A/V conference.
For more information, check out the following articles:
Keywords: STUN, TURN, A/V, UC, allocation, RTCMEDIARELAY, RTCMRAUTH, ICE,
Reader Comment (paraphrased):
I am trying to make sure I understand this article correctly. By using Lync/OCS R2 AV conferencing server in a remote location, AV conference traffic from remote location attendees can be isolated in the remote leve,l as the article seems to be implying
closest traversing traffic on the network. If this is the case, is it possible to install an AV conferencing server(MCU) on a location where multiple users on an AV session is highly expected? Please advise. Thanks.
Response from Author, Mike Adkins:
Your question provides a description that depicts an internal network deployment of the OCS 2007 R2 A/V MCU. OCS 2007 R2 does support the use of the Expanded topology, which allows the separate server installation of the A/V MCU. The expanded installation
is strictly a command line installation. For a better comparison of the supported installation topologies for OCS 2007 R2, please read the information listed below.
Topology and Component Architecture:
The article "Troubleshoot STUN with TURN in Office Communications Server 2007 R2" discusses the OCS 2007 R2 A\V Edge server's use of the STUN\TURN protocols and SIP signaling processes, which precede the media address allocation that ensures a secure media
session between the remote (internet) and internal (AD network) A\V conferencing peers. The article also pertains strictly to the deployment of the OCS 2007 R2 A\V Edge Server in a Perimeter network environment. The information listed below describes the supported
deployment information for the OCS 2007 R2 A\V Edge Server.
Office Communications Server 2007 R2 Edge Server Deployment Guide:
If I have not answered your question correctly. please provide more details, describing what you are trying to achieve and we'll go from there.
I just posted a comment, infact more of a query :)
Incase you get time and can respond back to me please write me @firstname.lastname@example.org
Could you tell me more about SASLPrep algorithm?
For example, my password is "Microsoft" so what do i get from SASLPrep("Microsoft")?
Thanks a lot.