Поделиться через

Lync 2013 and Skype for Business 2015 Client RTPRTCP Changes

  • Статья

With the release of the April 14th, 2015 Lync 2013\SfB client patch (15.0.4711.1002) we introduced the idea of Multiplexed RTP\RTCP ports. This change was made to align with Web RTC standard and address NAT/FW traversal issues. What this means is that we will use a single UDP port for both RTP and RTCP when negotiating final candidates for Audio\Video modalities. This will affect all clients running the April 14th update regardless of which GUI interface is being used or against which server version is running on the backend. There is one caveat to the backend server version which I will discuss later.

Candidate Behavior

First let's take a look at what this behavior actually looks like. If you have ever looked at UCCAPI client logs before this patch you noticed when negotiating final candidates for RTP you would see one port used for RTP and a separate port used for RTCP (Figure 1). Now with the introduction to the April client patch you only see a single UDP Port being used (Figure 2). If you look at the initial invite SDP we will still send with both ports (Figure 3) because we are unsure if the other side will be an updated client and understand the multiplexing RTP behavior.

 

Figure 1: RTP Candidates prior to the April 14th, 2015 update

 

Figure 2: RTP Candidates with the April 14th, 2015 Patch installed - Multiplexing UDP port

 

Figure 3: Initial Invite SDP

 

Traffic Classification Impact (QoS)

If your customers are using a Lync/Skype for Business traffic classification solution to prioritize voice and video communication relying on the separate RTC or RTCP traffic1, the solution will not work in new Lync 2013/Skype for Business 2015. Traffic might not be prioritized as expected and call quality might be impacted.  Please advise your network infrastructure providers and customers to re-evaluate their solution.

 

1Using RTP or RTCP to classify the Lync/Skype for Business was never been recommended, tested, nor supported way of determining Lync media heuristics.

 

 Modalities Impacted

Currently only the following modalities are impacted, but more will follow with future updates:

  • Joining an AV conference from a Lync 2013/Skype for Business 2015 client with the April 2015 update on a Skype for Business Server 2015 or Skype for Business Online.
  • Two clients running Lync 2013/Skype for Business 2015 client with the April 2015 update.

 

Microsoft recommendation on Lync/Skype for Business traffic classification

Microsoft recommends two different ways to prioritize traffic:

  • Using Quality of Service (QoS) by marking traffic with DSCP.
  • Using network equipment that can leverage Software Defined Networking (SDN) and integrate it with the SDN API that Lync/Skype for Business offers

Both options are explained in detailed in the Lync Server Networking Guide.

Comments

  • Anonymous
    June 15, 2015
    Good to know.
  • Anonymous
    June 16, 2015
    Can we still define the port range for the different client modalities and have that be honored via inband provisioning? We use the below today and QoS respectively around these port ranges:

    Set-CsConferencingConfiguration -ClientMediaPortRangeEnabled 1
    Set-CsConferencingConfiguration -ClientAudioPort 20000 -ClientAudioPortRange 40 -ClientVideoPort 20040 -ClientVideoPortRange 40 -ClientAppSharingPort 20080 -ClientAppSharingPortRange 40 -ClientFileTransferPort 20120 -ClientFileTransferPortRange 40 -ClientMediaPort 20160 -ClientMediaPortRange 40
  • Anonymous
    June 17, 2015
    Good Job
    nice short and good article to read by breakfast :)
  • Anonymous
    June 18, 2015
    @Chad - Yes
    @Darwin - Thanks