Regarding Lync 2013 traffic monitoring.
The customer requested the possibility to monitor Lync (2013) traffic. (Voice &Video).
I checked the docs, release notes and the intro at APMU:
So far I understood as of 12.3 Lync is supported within DC RUM; Proactive Lync monitoring enables in-flight VoIP call quality control.
With the following remarks:
- On premise only in 12.3
- Only audio is decoded
- High level data available using NBAR2
The question I have is mainly architectural; This international customer has a few data-center locations, and globally a lot of sites where end-users reside. The HQ has different buildings acoss the city (could see them as sites) Lync is supposedly a point-to-point application; How would we need to deploy the necessary equipment, if we want to measure the Lync traffic: regarding:
- use of AMDs, placement. Central, in the DC locations?
- how to feed the AMDs with data. NBAR/NetFlow from sites (access routers) to AMD?
- any other means to feed the CAS with this kind of information?
Solved! Go to Solution.
Lync uses two main protocols. First it uses a signalling protocol (SIP over TLS) to set up and frame the conditions for the call. Once the callee has been contacted and answered, it then uses RTP/RTCP to exchange the audio data. The signalling will go to what is essentially call manager, but the subsequent audio exchange over RTP will indeed go peer to peer (point to point). In order for DC RUM to decode and report on this traffic the AMD must be placed in a position to see both the signalling (call set up) and subsequent audio exchange. What this normally means is that the AMDs are positioned at the ingress/egress to the site, as they will then be able to see that call set up and traffic as well as the following audio. It should be noted this works only for on premises Lync deployments because Lync uses SIP over TLS and so you will also need access to the keys. NetFlow in conjunction with NBAR2 is slightly different in as much as it will support all forms Lync deployments , again assuming that the device creating the flow sets actually sees the traffic passing over its interfaces, it will currently report only on usage figures for the conversations, and will not populate the CAS VoIP reports. In the case of NetFlow with NBAR2 the deployment approach is the same, as the NetFlow source will be best served form that site ingress/egress point, but the position of the AMD Flow collector is then only dependent on being able to receive the flow sets sent form those site devices.