Index

» Home

» OCS Deployment

» Front End Server

» Edge Server

» Web Conferencing Server

» Archiving Server

» Certificates

» Communicator Web Access

» A/V Server

» VOIP 'N' Mediation

» Group Chat Server

» Migration

» Exchange UM

» OCS Issues

» OCS Disaster Recovery

» Miscellaneous

 

 

Publicly routable IP address on the external interface of the AV Edge Server

Publicly routable IP address on the external interface of the AV Edge Server

The external interface on the A/V Edge server requires an IP Address which is public routable.

Why do we need the public IP?

Following are the two reasons which leads an AV edge server to have routable IP Address on its interfaces.

·         A) The A/V Edge server need to reflect back the IP Address it observed from an external user’s router because of the following two reasons.

o    This external user IP address is used to enable the use of efficient media paths using the ICE protocol.

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

·         B) To support UDP load balancing: UDP is the preferred protocol to transfer RTP packets for real time Audio\Video traffic. 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: Due to same reason we need routable IP address on the internal interface as well of the A/V Edge server.

What is ICE?

ICE is a protocol for Network Address Translator (NAT) traversal for multimedia session signaling protocols based on the offer/answer model, such as the Session Initiation Protocol (SIP). This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of existing protocols, such as Simple Traversal of UDP through NAT (STUN) and Traversal Using Relay NAT (TURN). ICE makes use of STUN in peer-to-peer cooperative fashion, allowing participants to discover, create and verify mutual connectivity. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04231.html

What is STUN protocol?

Simple Traversal of UDP through NATs (STUN), is a network protocol allowing a client behind a NAT (Network Address Translator) to find out its public address, the type of NAT it is behind and the internet-side port associated by the NAT with a particular local port. This information is used to set up UDP (User Datagram Protocol) communication between two hosts that are both behind NAT routers. The protocol is defined in RFC 3489

What Microsoft Says?

http://communicationsserverteam.com/archive/2008/03/25/133.aspx


 
OCS Made Easy!
 

 

Copyright, OCSpedia.com. Microsoft, MS-DOS, Windows, Windows 2000, Windows XP, Windows Server 2003, Windows NT, Windows 98, Windows 95 are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and other countries. All other names are registered trademarks of their respective companies. Should any right be ran afoul, it is totally unintentional. Send us an e-mail and we will promptly and gladly rectify it. All external sites will open in a new browser. Ocspedia.com does not endorse external sites and is not responsible for their content. For broken links, site problems or any feedback - please send an email at uc@ocspedia.com.