RSS Subscription 167 Posts and 2,643 Comments

Office Communications Server 2007 R2 Audio/Media Negotiation

Read the Lync Server 2010 version of this article here.

There are several ways in which we can utilize Audio/Video streams in Office Communications Server (OCS) R2.   The same “should… but not verified” work the same in OCS 2007 R1.  There aren’t really any places out there that describe how the media session works in different circumstances.  For example, what servers and ports are utilized when doing Audio/Video through the Live Meeting 2007 client when connected to the On-Premise Web Conferencing feature in OCS 2007 R2?  How about when you do a peer to peer with both users being internal to the network?  How about both users being external to the environment and connecting through the Edge?  How about when you do a peer to peer with one user being internal and one user being external?  Want to know?  Read on…

Media Ports and Restricting Amount of Ports Being Used

The first thing to understand is that in OCS 2007 R2, when a user attempts to activate any type of audio and/or video, they first attempt a peer to peer session.  The ports utilized here are TCP/UDP 1024-65535.  You can see what ports are used for OCS 2007 R2 here and here.  This port range is utilized mainly for users who are internal to the network.  If you want users to utilize peer to peer audio while internal to the network, you must ensure that this port range is open even if users are in different sites.

But what if you don’t want this entire port range open between your sites?  You can utilize Group Policy in both OCS 2007 R2  to limit the amount of ports that are being used.

These two settings include:

  • PortRange/MaxMediaPort
  • PortRange/MinMediaPort

The above group policy settings modify the following three registry keys:

  • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\Enabled REG_DWORD 1
  • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\MaxMediaPort REG_DWORD 40039 (for example)
  • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\MinMediaPort REG_DWORD 40000 (for example)

Note: Both clients must have these registry keys set in order for the modified port range to take effect.

You must have at least 40 ports open which is an IETF Interactive Connectivity Establishment (ICE) protocol requirement to ensure that Audio/Video port negotiation works for peer to peer while internal to the network.  ICE is a protocol that provides a mechanism for firewall or NAT traversal.  The RFC draft for this protocol can be found here.

Audio/Video Connectivity Scenarios

Two Users Internal to the Network (media ports open)

When these two users are internal , they will attempt peer to peer.  Because they can successfully connect to each other, they utilize peer to peer media.  This is why OCS scales pretty high; because a lot of connections are one to one which means that peer to peer media connections are never bridged through the server.  Because these users connect directly to each other for media, they have no need to connect to the Edge.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Audio/Video through the Web Conferencing Server

When users are connected through On-Premise Web Conferencing and activate Live Meeting (when internal or external… doesn’t matter), they are connecting directly through the Front End’s Conferencing MCU’s.  Because of this, even when it’s two users, the user’s are still connecting to the Front End MCUs.  If both user’s are external, they still connect through the Front End MCUs but are proxied through the Edge Server.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Two Users Internal to the Network and Any Users External to the Network

As previously stated, any time you have more than two users, peer to peer is no longer utilized and users always connect directly to the MCU on the Front End Servers.  This means that both users internal to the network will connect to their Front End server(s) and the external user will connect to the Front End server as well utilizing the Edge Server for proxying to the Front End.  There is absolutely no peer to peer connectivity in this situation.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Two Users on the Internet

When these two users are external , they will attempt peer to peer.  Because they can successfully connect to each other, they utilize peer to peer media.  This is why OCS scales pretty high; because a lot of connections are one to one which means that peer to peer media connections are never bridged through the server.  Because these users connect directly to each other for media, they have no need to connect to the Edge for Audio/Video.  You will still see the user connected to the Access/Edge over port 443 and/or 5061 (if these are your remote access port and federation port if you are using federation).  When users are connected through On-Premise Web Conferencing and activate Live Meeting, they are connecting directly through the Front End’s Conferencing MCU’s.  The Front End will have a certificate that contains the Pool Name and will/can contain SAN names for additional SIP domains that you may contain.  Because of this, SAN names are supported on Front End Servers.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Two Users Internal to the Network (media ports closed)

When these two users are internal , they will attempt peer to peer.  During their ICE negotiation, as previously stated, they will know the Internal Edge NIC in case their peer to peer connectivity fails. Because they fail to connect to each other, they will connect to the internal Edge NIC over either UDP 3478 or TCP 443.  ICE has a mechanism where it will test a lot of candidates to see where connections should be made.  ICE will test UDP 3478 and TCP 443 in parallel and if UDP 3478 works, the client will receive UDP 3478 due to it having less overhead.  If UDP 3478 does not work, the client will receive TCP 443.   If you anticipate on blocking ports between your users, make sure your Edge Server can scale high enough to deal with the amount of Audio/Video connections it will be handling.  To block one of your sites from doing peer to peer with other sites, block the peer to peer port range (discussed at the beginning of this article) from that site and block that site from communicating over UDP 3478 and TCP 443 to the Edge Server.  This will prevent clients from doing any type of media communication from user’s outside of their own site.  If you want to allow them to do peer to peer for users in some sites, modify the firewall ACLs accordingly for those sites.

Note: Diffserv markings for Quality of Service (QoS) are lost through an Audio/Video Edge Server.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

One User External and One User Internal

When one user is internal and one user is external , they will attempt peer to peer but not in the same sense as in two internal users. The external user will hit TCP 5061 to the Access Edge Server and will be provided with either UDP 3478 or TCP 443 for the Audio/Video Edge.  As stated earlier, UDP 3478 is preferred even if the connection test for TCP 443 and UDP 3478 were successful in testing.  If you attempt a telnet edgeserver.domain.com over the Internet, telnet will fail to connect.  This is because telnet uses TCP.  You can do a netstat -an to see your server listening on UDP 3478 and utilize a different program such as netcat which can attempt telnet to UDP by using netcat -u host 3478.  More information on netcat here.

Moving on… we see that the user will connect to the A/V Edge over UDP 3478 or TCP 443, but what about the internal user?  Because this is technically peer to peer, the internal user will NOT connect to the MCU on the Front End but will instead connect directly to the A/V Edge Server’s Internal NIC over UDP 3478 or TCP 443 as well.  The Front End A/V MCU will not be used in this scenario.  When you add a 3rd person to the conversation, the external user will connect to the Front End Server’s A/V MCU in which the A/V Edge will proxy this data for the user, and the internal users will connect to the Front End A/V MCU instead of the Internal Edge NIC.

Note: Diffserv markings for Quality of Service (QoS) are lost through an Audio/Video Edge Server.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Issue to be aware of in OCS 2007 R2 (not verified as an issue in Lync 2010)

Certain certificate vendors like to add www automatically to the CN of your certificate request with consent from the person requesting the certificate.

So for example, our certificate request for a regular certificate (non SAN) was CN=Servername.domain.com.  These vendors provided the following certificate:

  • CN=Servername.domain.com
  • SAN=www.Servername.domain.com

Now this is where you can run into an issue when doing peer to peer and falling back to the internal Edge NIC or when one person is on the Internet and one person is internal while using Communicator.  Some certificate vendors like to assign a www as a SAN name to your regular (non-SAN) cert.  So if you requested a CN of Servername.domain.com, these vendors will automatically add www in front of your CN.  This messes up peer to peer audio/video negotiation.

This is important to remember when getting a 3rd party certificate for the Internal Edge NIC.  It is not supported to have anything other than a CN for this certificate.  The reason why is ICE negotiation will not work properly.  Because the www.servername.domain.com will be there as a SAN, the client will be provided the www.servername.domain.com name for ICE connectivity to the internal Edge NIC which will obviously fail.  Because of this, the scenarios above which utilize the Internal Edge NIC will fail.  To recap, the following two scenarios end up using the Internal Edge NIC:

  • One user internal to the network and one user external to the network
  • Internal users attempting to do peer to peer (media ports being closed) and falling back to the Internal Edge NIC

There are a few ways to fix/workaround the problem:

  • Use a Windows PKI implementation for Internal Edge NIC
  • Deal with the SAN name but use a CNAME for www.servername and redirect that to the servername HOST/A record using Internal DNS to do this as you are dealing with the Internal Edge NIC.
  • If the vendor doesn’t add www to their SAN certs, you can get a SAN cert only with the CN filled out
  • Go with a different vendor that doesn’t automatically add www to their regular certificates.
Share

56 Responses to “Office Communications Server 2007 R2 Audio/Media Negotiation”

  1. [...] Vielleicht hilft dir das: Office Communications Server 2007 R2 Audio/Media Negotiation | Elan Shudnow's Blog [...]

  2. [...] Office Communications Server 2007 R2 Audio/Media Negotiation Posted on August 30, 2009 by johnacook http://www.shudnow.net/2009/08/29/office-communications-server-2007-r2-audiomedia-negotiation/ [...]

  3. on 12 Oct 2009 at 3:05 pmjason

    Hi
    if we just built the OCS EE Server, but didn't build the Edge Sever.
    Can we solve the peer to peer connectivity fails problem??

  4. on 12 Oct 2009 at 3:09 pmjason

    if the users have the nat issue…

  5. on 12 Oct 2009 at 11:23 pmElan Shudnow

    You can use NAT just fine as long as you only have one Edge. You can't use NAT at all if you have Load Balanced Edge Servers.

  6. on 13 Oct 2009 at 1:38 amjason

    Hi shudnow:
    tks for your reply. If we didn't build any edge server .The moc users in the internet and they have private ip (nat issue) in hotel or in airport. these users will fail to connect Audio/Video Connectivity, right?

  7. on 13 Oct 2009 at 1:49 amElan Shudnow

    The NAT issue is when the AV Public IP is behind a NAT when you have load balanced Edge Servers. NAT on your clients works fine.

  8. on 13 Oct 2009 at 2:10 amjason

    Hi shudnow:
    in my environment, we didn't hava any load balanced Edge Servers or A/V Edge Server, we only have depolyed the OCS SE Server. We put the SE Server in the DMZ zone to service the moc user.
    There are two users, one is the moc user A and he is in interent but he has the 192.168.0.1 ip. the otheris the moc user B and he also is in interent but he has the 10.1.0.1 ip . Then the user A want to make a pc 2 pc call to user B to communicate.
    Can these users communicate successfully ?

  9. on 13 Oct 2009 at 3:14 amElan Shudnow

    An OCS Front End is not supported in the DMZ. OCS isn't like Exchange where you can just open ports to the OCS Server and you have internet access to OCS. You want to move OCS to your internal network and deploy an Edge for internet accessibility. Once you do this, you can follow my guide to properly understand how the communication flow will work.

  10. on 13 Oct 2009 at 3:43 amjason

    You say OCS Front End is not supported in the DMZ??? Why? if we set a new DMZ zone and we can open any connect port that can make moc access ocs SE server . Can't the moc login the ocs server and use these ocs funcation ? Do you have any info to describe the issue? plz tell me many tks!!

  11. on 13 Oct 2009 at 3:58 amjason

    an additional remark:
    we set the new dmz zone, and we don't care the secutiy issue like hacker.. that is demo site and we want to build edge server
    So,I think the point is ocs Front End is implemented STUN/ICE/TURN ??

  12. on 13 Oct 2009 at 3:56 pmElan Shudnow

    Because there are so many ports that need to be opened for a Front End. It's not supported in the DMZ just like Exchange Servers other than the Exchange 2007 Edge role. The Edge was designed to be in the DMZ and that's what should be in the DMZ

  13. on 13 Oct 2009 at 3:56 pmElan Shudnow

    Any A/V uses ICE. TURN/STUN are the protocols for ICE. This article explains ICE negotiation with both FE and Edge Servers.

  14. on 19 Oct 2009 at 12:25 amShaneJohn

    We have a Front end OCS Server – OCS Director Server & Consolidated Access Edge Server. My issue is a External MOC user cannot make a MOC call to a Internal MOC user. External MOC to External MOC works / Internal MOC to Internal MOC works. What are the port requirements for an External user to make a call to the internal users? There seems to be no defined article outlining this.

  15. on 21 Oct 2009 at 1:30 pmElan Shudnow

    ShaneJohn, here are the required ports that you should open to allow external users to talk to the Edge and internal servers/users to talk to the Edge: http://technet.microsoft.com/en-us/library/dd4413

  16. on 30 Nov 2009 at 5:45 pmDirkG

    ShaneJohn, did you check this link : http://technet.microsoft.com/en-us/library/dd4413
    This clearly describes the possibilities and limitations when NAT-ing the external IP of the Edge Server.
    And it lists the ports that should be opened on the Firewalls at both sides of the Edge Server, especially the public/externe IP interface.
    Hope this helps

  17. on 22 Dec 2009 at 1:02 pmMoh

    Hi, Thanks for the great article. I am having issues with UCC Cert. Actually , I am using cert from godaddy which add http://www.domainname.com automatically in SAN entries. Problem is My internal network audio ,video works fine but externally nothing works. Communicator keeps on giving me certificate error. "There was a problem verifying certs from server" Though i can logon to Snom OCS Phone and call internal users but again no audio. I have tried putting cname in our external dns but it didnt work. My access edge and web conf are using a Public IP address and then AV server is using another Public IP. Can you please advice??

  18. on 22 Dec 2009 at 2:30 pmElan Shudnow

    Because this is the internal NIC on the Edge, you need to put that CNAME in Internal DNS so the http://www.domainname.com hits your EdgeFQDN.domain.com. I modified my article for clarity.

  19. on 13 Jan 2010 at 3:43 pmRichard

    Two Users on the Internet

    what if the 2 external users are both behind NAT, so no direct connection can be made between them? They should both send RTP to the EDGE public IP.

  20. on 15 Jan 2010 at 12:41 amElan Shudnow

    Richard. You first ask the question what happens and then make a statement saying that they both connect to the Edge. Are you asking or are you stating?

  21. on 16 Feb 2010 at 3:33 amShaneJohn

    If my OCS Edge Server is configured using the ports and protocols outlined in this Tecehnet Article http://technet.microsoft.com/en-us/library/dd4413… – Is there a requirement for high end udp ports to be opened as per this link (http://technet.microsoft.com/en-us/library/dd4252… through the external firewall for clients to transfer Audio/Media data?

  22. on 17 Feb 2010 at 11:47 amAdrian

    Hi Elan

    I wonder if you can help.. between two MOC OCS 2007 clients internally on the same subnet using RCC i can establish a Video Peer to Peer call. When i enable the two clients with Enterprise Voice for some reason the media stream gets flicked to the mediation server, then the mediation servet tries to contact the edge server, the video call fails. Is there anything different i need to configure for peer to peer video working with EV?

  23. on 18 Feb 2010 at 11:05 pmElan Shudnow

    That's a bit odd and I have not run into that issue. I do believe that Communicator will communicate with the Mediation Server for EV specific communication, but the video should still be going to Front End AFAIK. EV is more of a scenario I'm not too entirely sure how the media flow works. Either way, I haven't really run into any issues and you shouldn't as long as you're not blocking ports between clients and your internal servers.

  24. on 18 Feb 2010 at 11:07 pmElan Shudnow

    I only ever follow the external use that 1st article for external traffic. The only time I ever open up more ports other than what is specified in that document is when I need to allow file transfer to the outside. I then refer to that 2nd article for ports.

  25. on 04 Mar 2010 at 11:25 amKid’s Sno-Mocs | Pink Snow Boots

    [...] Elan Shudnow's Blog » Office Communications Server 2007 R2 Audio … [...]

  26. [...] Office Communications Server 2007 R2 Audio/Media Negotiation | Elan Shudnow’s Blog Posted on March 8, 2010 by johnacook http://www.shudnow.net/2009/08/29/office-communications-server-2007-r2-audiom… [...]

  27. on 19 May 2010 at 2:52 pmFantomas

    Hi Shudnow..
    In a external to internal load balance scenario for audio and video.
    On my setup we can ring each other but the call drops.
    In this case the internal user has a private address, how will the communication work ? at what point the private address is translated to a public? or does it get proxied by the edge ?

  28. on 25 May 2010 at 2:36 pmeshudnow

    Fantomas, you only need Public IPs on the Load Balancer and the NICs on the Audio/Video Edge Servers. The A/V Edge Servers will talk to the Front End Pool IP which does not need to contain a Public IP Address. The client will communicate with the Front End Server. This is how it works when you have 3 people in an A/V session. When it's Peer to Peer, the internal user will communicate with its private IP Address to the Internal VIP on the Load Balancer but the Internet user will communicate to the external Public IP VIP of the A/V Edge. So both the client and the external client connect to the Edge. So the Edge doesn't necessarily look for a client and pass the Audio to it. The clients make a connection to the Edge Server which bridges the two together.

  29. on 17 Jun 2010 at 1:22 amAhmed Khalil

    Hi Shudnow,
    Please confirm the following:
    If two users on the Internet can't start Peer to Peer connections, they will bridge the communications betwen them by using A/V Edge.
    Is that means also they will have A/V Edge in the middel all the time for the Peer to Peer connection.

    Regards

  30. on 17 Jun 2010 at 10:13 pmPhilip

    Is it possible to require 128 bit encryption on port 443 for the Edge server since it is Internet facing even though MOC clients use 128 bit already?

  31. on 19 Jun 2010 at 2:34 pmPawel

    Hi Elan!

    Many thanks for great article.
    I was thrilled to find out that scenario described in "Two Users Internal to the Network (media ports closed)" section is true indeed.
    Is this documented somewhere on MS technet?
    I thought that in case of p2p failuer two internal users would connect via Front-End server, like in case of every conference.
    Why are they routed via Edge?

    My question:
    If I force clients from two separate sites (subnets) to use required minimum 40 media ports, does this mean that amount of concurrent calls between these sites is limited?
    Each Communicator p2p call uses min. a few media ports, so max. number of conurrent calls is like ~10 in this case?

  32. on 29 Jun 2010 at 4:31 pmeshudnow

    I learned this through Escalation Engineer where he told me this and we verified it via the log files that Communicator generates. It's also discussed on a webcast that Byron Spurlock presents in.

  33. on 29 Jun 2010 at 4:44 pmeshudnow

    I believe so. This is the 1 scenario I'm not 100% certain on.

  34. on 02 Jul 2010 at 5:13 amDrRez

    Good article Elan. I confirmed with the principal program manager for media in Microsoft's Communications Server team. There's a slight incorrection. UDP 3478 and TCP 443 are tried in parallel, not in sequential order.

  35. on 02 Jul 2010 at 1:32 pmElan Shudnow

    Thanks, will update.

  36. on 14 Jul 2010 at 3:42 pmmoto822

    Hi All,

    So if I am understanding correctly, I need to open up 3478 or 443 from my client network to my DMZ to get peer to peer to work?

  37. on 22 Jul 2010 at 1:41 pmRavi Biradar

    Hi Elan .
    I am using External user
    I want block UDP ports or make udp ports unreachable so that ICE negotiation happens only in TCP, how to go about it any docs?

    Thanks in Advance,
    Ravi

  38. on 30 Jul 2010 at 12:37 ameshudnow

    Just don't open UDP. The ICE connection testing process tests both TCP and UDP at the same time, and if both works, UDP is provided to the client. If UDP fails but TCP works, TCP is provided to the client.

  39. on 22 Sep 2010 at 6:13 amMhoz

    Hi Elan, very instructive article-thanks for posting.
    Please let me put out another scenario which is the one i'll have to deal with shortly: "Two Users Internal to the Network (media ports closed) AND no Edge on network". This is an internal-only deployment, the customer's client network has several subnets and I know there will be no media ports available to/from some of the client networks.
    In the scenario you state that "Because they fail to connect to each other, they will connect to the internal Edge NIC over either UDP 3478 or TCP 443". What if no edge is deployed? should I expect the OCS Front-End to carry over the same task, OR the media connection is destined to fail? that's a quite critical piece of information. Thanks a lot. Cheers.

  40. on 22 Sep 2010 at 7:11 amElan Shudnow

    Haven’t tried that scenario. I would be inclined to say it fails but OCS sometimes goes out of its way to try to get connections to work. So, it may still work. But maybe not.

  41. on 12 Oct 2010 at 6:15 amPatrik Olsson

    Hi,
    this article is great ! I have one question: what about Federation ? One internal user and one Federated user. Do the federated user connect to their own Edge ?

    Thanks !
    Patrik

  42. on 12 Oct 2010 at 10:28 amElan Shudnow

    No, they don't connect to their own Edge. The Edge Servers in Federation only do SIP with each other. The Federated user would still make a connect to the Edge Server of the Federated organization.

  43. on 12 Oct 2010 at 7:27 pmvule

    Hi,
    What about two Internet user that cannot connect to each other (behind nated router). I have configured A/V edge with public IP address but communicator call only works if the two external user are in the same network. They always connect directly via UDP. Is there any configuration that I missed?

    Thanks,
    Vu.

  44. on 12 Oct 2010 at 11:20 pmElan Shudnow

    2 users on the internet should have no problems connecting to each other for P2P. If for some reason it fails, I'm not certain if they connect through the Edge.

  45. [...] Reference: http://www.shudnow.net/2009/08/29/office-communications-server-2007-r2-audiomedia-negotiation/ [...]

  46. on 16 Nov 2010 at 12:18 pmDavid

    Hi Elan, is there a way, in the new Lync 2010 client, to force the A/V stream when 2 users connect each other?

  47. on 18 Nov 2010 at 9:46 amElan Shudnow

    I don't believe they've allowed this capability in Lync.

  48. on 18 Nov 2010 at 3:18 pmMike

    Hi Elan,

    Have you tested New-CsConferencingConfiguration for setting up different client media ports via in-band provisioning?
    I understand these should apply for p2p sessions too.

  49. on 18 Nov 2010 at 3:34 pmElan Shudnow

    Good to know. The migration documentation says there are no equivalents but based on your reply, looks like there actually is.

    Update: 12/1/2010
    It appears the documentation has been updated. The previous migration document says there were no equivalent settings in Lync Server 2010 In-Band Provisioning but now there is. The New-CSConferencingConfiguration cmdlet seems to allow you to set up port ranges for several different modalities. I will update my documentation within the next few days.

  50. on 01 Dec 2010 at 2:51 pmRandy

    Hi Elan,
    Great overview. I do have one question. How does the media flow differ when you have 2 or more pools with two or more sets of edge servers with 2 (or more) users homed to different pools?
    Thanks.

  51. on 06 Dec 2010 at 12:43 amElan Shudnow

    Don't forget each Pool is connected to an Edge Server. You can have A/V and Web Conf in a different site servicing a different pool. If a user connects in, the Access Edge will refer the user to the appropriate A/V and Web Conf.

  52. on 28 Dec 2010 at 4:53 amHarish

    Hi, we are using Logitech 960 USB headset for communication purpose. Its working fine on all HP models except 8440p laptop. If you connect headset to the laptop then there is a lot of noise coming only from right side of headset speaker but if you connect same headset with other laptop (say HP 6930p) then its working fine.

    Any solutions on this ….???

  53. [...] Reference: http://www.shudnow.net/2009/08/29/office-communications-server-2007-r2-audiomedia-negotiation/ OCS 2007/R2 ← Office Communicator cannot place calls to the Exchange Unified Messaging Auto Attendant LikeBe the first to like this post. [...]

  54. on 04 Jan 2011 at 7:09 pmElan Shudnow

    The solution is to use a certified headset for OCS/Lync: http://technet.microsoft.com/en-us/lync/gg278173

  55. [...] Read the Office Communications Server 2007 R2 version of this article here. [...]

  56. [...] should point out that Elan Shudnow’s post on A/V negotiation (thanks Liam!) has a much more detailed view of what happens during communicator calls. Too bad I [...]

Trackback this post | Feed on Comments to this post

Leave a Reply