locked
ICE and STUN RRS feed

  • Question

  • I am trying to understand how ICE uses STUN to ascertain what the NAT-ed public IP address I client should use in a SIP request from an Enterprise LAN to an Internet client.  Where is the STUN server located?  Is this included within the OCS servers (e.g. the A\V server)? or it it necessary to deploy a STUN server?

    Friday, December 21, 2007 4:13 PM

All replies

  • The A/V Edge Server is the 'STUN Server'; there is no need to deploy any addtional, non-native component(s) in order to get all aspects of external access working with OCS.  Just make sure the A/V Edge Server interface has a fully routable public IP address assigned and you'll meet the requirements as described in the OCS Planning Guide (in the section Publicly Routable IP Address for External A/V Access).

    Saturday, December 22, 2007 3:40 AM
    Moderator

  • Some good info about routable IP addresses on the AV Edge server....



    http://www.ocspedia.com/Misc/PublicIP_AVEdge.htm


    Regards,
    R. Kinker
    MCTS - LCS 2005, MCTS - OCS 2007
    http://www.ocspedia.com
    http://www.itcentrics.com/LCS_Home.htm

    Sunday, June 1, 2008 9:20 AM
  • For convience here's a link to the official Microsoft documentation I referenced above:

    http://www.microsoft.com/downloads/details.aspx?familyid=723347c6-fa1f-44d8-a7fa-8974c3b596f4&displaylang=en

     

     

    To enable this external access to media sessions and audio and video, the A/V Edge server and Office Communications Server clients rely on Interactive Connectivity Establishment (ICE) and Simple Traversal of User Datagram Protocol (UDP) through network address translators (NATs) (STUN) protocols. To support the protocol requirements, the A/V Edge server requires the assignment of a publicly routable IP address to its external interface.

    The follow except from RFC 3489 summarizes the reasons that STUN requires a publicly routable IP address.

    STUN assumes that the server exists on the public Internet.  If the server is located in another private address realm, the user may or may not be able to use its discovered address to communicate with other users. There is no way to detect such a condition. (RFC 3489 Section 14.3).

    STUN imposes some restrictions on the network topologies for proper operation. If client A obtains an address from STUN server X, and sends it to client B, B may not be able to send to A using that IP address.  The address will not work if any of the following is true:

    The STUN server is not in an address realm that is a common ancestor (topologically) of both clients A and B.  For example, consider client A and B, both of which have residential NAT devices.  Both devices connect them to their cable operators, but both clients have different providers. Each provider has a NAT in front of their entire network, connecting it to the public Internet.  If the STUN server used by A is in A's cable operator's network, an address obtained by it will not be usable by B.  The STUN server must be in the network which is a common ancestor to both - in this case, the public Internet.  

    The STUN server is in an address realm that is a common ancestor to both clients, but both clients are behind the same NAT connecting to that address realm.  For example, if the two clients in the previous example had the same cable operator, that cable operator had a single NAT connecting their network to the public Internet, and the STUN server was on the public Internet, the address obtained by A would not be usable by B. That is because some NATs will not accept an internal packet sent to a public IP address which is mapped back to an internal address.  To deal with this, additional protocol mechanisms or configuration parameters need to be introduced which detect this case. (RFC 3489 Section 14.3).

    In an A/V Edge Server array, where the edge servers operate as logical entity one and are supported by the use of hardware load balancer, each A/V Edge Server in the array requires a dedicated public IP address.

    Not placing a publicly routable IP address on the A/V Edge Server drastically reduces the effectiveness of STUN and hampers the ability of the ICE protocol to establish A/V communications between clients.  The loss of functionality due to this improper configuration ranges from inconsistent A/V connectivity between clients to the complete inability to establish a successful connection.

    In Office Communications Server 2007, Microsoft does not support non-publicly routable IP address on the A/V Edge server.  If a reported problem is believed to be caused by the A/V Edge Server, we will be unable to continue support until the configuration is adjusted. 

     

    Sunday, June 1, 2008 12:35 PM
    Moderator
  • Jeff

    I'm wondering if I could run something by you. I have an edge server (one for all 3 edge roles), where the edge isn't the edge between a private and a public network, but rather an edge between two disjoint private networks. There's no NAT anywhere and no firewalls as well. Basic sign-in and communication works fine - the "external" MOCs authenticate against my access edge, and then send messages to the edge which forwards them to my internal network and vice versa. It also works for signalling for a communication with audio, however the audio path is never established.

    Looking at the SIP packet exchange I have determined why this is: the external client will figure out that there's no NAT so it'll send it's own IP address (which is a private address) as endpoint address for the media stream. The edge receives that packet, and forwards it like any proxy would. However, it keeps the SDP header in the INVITE unchanged.. so the INVITE that makes it to the internal network contains the IP address of the external client. Since the two networks are disjoint and the only way is to pass through the edge, that means the internal client has no way of sending media back. And on the path from internal to external we see the same.. the ACK is sent back to the edge, which sends it back to the external client, with no modification in the SDP header, so the external client then tries to send media to the internal client directly.. once again that path is not supported.

    I understand that STUN will tell the external client to use its own IP.. which is fine. What I do not understand is why the edge does not modify the SDP. My understanding (looking at the design documents) is that the media stream always passes through the a/v edge, so regardless of what kind of network setup you have, the edge must always tell internal clients to send media to the internal NIC of the edge, and tell external clients to send media to the external NIC of the a/v edge (assuming we have one server.. ).

    So I believe my question boils down to this: What exactly is the edge looking for in determining if it needs to rewrite the SDP?

    Regards
    Stephan
    Wednesday, August 6, 2008 12:46 PM
  • Stephan,

    Maybe it is not a direct answer on your question but, like the internal OCS frontend server, the A/VEdge server has its own MCU (Multipoint Control Unit) which is a kind of central broadcasting station for Audio and Video to all external users that are (in most cases) behind firewalls. In order for clients to successfully connect, the endpoint (or videoconferencing unit) must be set outside your firewall and your IU network firewall. The endpoint must have a static or public IP address assigned to it. Clients that use NAT will not be able to successfully connect with the Edge Server unless they manually assign a public IP address its videoconferencing unit (in this case the AV/Edge).

    /Thomas
    Wednesday, August 6, 2008 9:19 PM