SDN Live View
This is a short summary of the german pages SDN - LiveView
Sometimes in 2014 Microsoft published a new Lync SDN API. the primäry goal is to allow network to optimize their usage based on information about currently established VoIP connections. It is an important component für larger companies and even carriers. Most smaller companies do not use a compatible hardware or software. But the knowledge about existing VoIP Connections is interesting für Lync Administrators. I did some research and developed a PowerShell-Sample to generate a "realtime Information" about active calls.
SDN Design
The design is based on a "Lync Dialog Listener (LDL)"-Modul, which has to be installed on every frontend server. Is tracks all INVITE/BYE-Commands and parses the SDP to find out the negotiated candidates. These are sent to a "Lync Dialog Manager" (LDM) using a HTTP-PORST. This is another service, which has to be installed somewhere within your network. The LDM will then talk to a network management backend to deliver the information. Here a simple picture of the components:
So thanks to microsoft we have a LDL-Module, which is tested and supported and collects all relevant message from the frontend servers and delivers them
How LDL is talking to the LDM
So first i installed exactly these system and used a network monitor to see, what they are doing. It is "simple standard technology" and easy to unterstand. LDM sends informations by using a HTTP-POST and the LDM anwers with a 200OK and a Counter
The LDL also checks the connection every second using a simple TCP-Keep-Alive- Packets. I assume, that this helps the LDL to swich over to a backup LDM, if required.
What's in the XML-Payload ?
So i did some more tracing and found some interesting XML-Parts in the Posts. Here are four samples: Keep in mind, that the SIP-Addresse is obfuscafed per default. You have change the configuration of the LDL to send the Data in clear text.
Start of a new connection
<LyncDiagnostics Version="1.0">
<ConnectionInfo>
<FrontEnd>lync2013fe</FrontEnd>
<CallId>42f4929eebd749c8a8b527c3f3c86f03</CallId>
<CSEQ>2</CSEQ>
<ConversationId>Ac8yT0wswlLEZPQYTDid8nAvVkEZEg==</ConversationId>
<TimeStamp>2014-02-25T17:30:38.5184126Z</TimeStamp>
</ConnectionInfo>
<StartOrUpdate Type="audio">
<From>
<Id>804d667da3</Id>
<EPId>ccdcf5ebc1</EPId>
<URI>sip:326C204F36B2541B@msxfaq.net</URI>
<IP>10.1.1.25</IP>
<Port>23504</Port>
</From>
<To>
<Id>81c96ba5</Id>
<EPId>5E9B554402</EPId>
<URI>sip:206939D5E70607C6@msxfaq.net;gruu;opaque=srvr:microsoft.rtc.applications.testbot</URI>
<Contact>sip:206939D5E70607C6@msxfaq.net;gruu;opaque=srvr:microsoft.rtc.applications.testbot</Contact>
<IP>10.1.1.21</IP>
<Port>49884</Port>
</To>
<Properties>
<Protocol>UDP</Protocol>
<EstimatedBandwidth Codec="G722/8000">
<Low>46100</Low>
<High>100600</High>
</EstimatedBandwidth>
<EstimatedBandwidth Codec="G7221/16000">
<Low>128000</Low>
<High>223600</High>
</EstimatedBandwidth>
<EstimatedBandwidth Codec="SIREN/16000">
<Low>46100</Low>
<High>52600</High>
</EstimatedBandwidth>
<EstimatedBandwidth Codec="PCMU/8000">
<Low>64800</Low>
<High>97000</High>
</EstimatedBandwidth>
<EstimatedBandwidth Codec="PCMA/8000">
<Low>64800</Low>
<High>97000</High>
</EstimatedBandwidth>
<EstimatedBandwidth Codec="AAL2-G726-32/8000" />
<EstimatedBandwidth Codec="CN/8000" />
<EstimatedBandwidth Codec="CN/16000" />
<EstimatedBandwidth Codec="RED/8000" />
<EstimatedBandwidth Codec="telephone-event/8000" />
</Properties>
</StartOrUpdate>
<StartOrUpdate Type="audio">
....
</StartOrUpdate>
</LyncDiagnostics>
End of a connection
After a connection is disconnected, we see the following Payload.
<LyncDiagnostics Version="1.0">
<ConnectionInfo>
<FrontEnd>lync2013fe</FrontEnd>
<CallId>373de56c178052948ba70814e97afe4c</CallId>
<CSEQ>3</CSEQ>
<TimeStamp>2014-02-25T17:56:49.017824Z</TimeStamp>
</ConnectionInfo>
<Ended>
<EndPoint>
<Id>8de45d648e</Id>
<EPId>ccdcf5ebc1</EPId>
<URI>sip:FB051BCCFF88FAD68E3BE528C9D8FE08@msxfaq.net</URI>
</EndPoint>
<EndPoint>
<Id>6e1e52882d</Id>
<EPId>5E9B554402</EPId>
<URI>sip:FB051BCCFF88FAD68E3BE528C9D8FE08@msxfaq.net;
gruu;opaque=srvr:microsoft.rtc.applications.testbot:wss8fws0aznmk1miznzaad8x</URI>
</EndPoint>
</Ended>
</LyncDiagnostics>
Error
I also found some error information, which might be useful für later processing
<LyncDiagnostics Version="1.0">
<ConnectionInfo>
<FrontEnd>lync2013fe</FrontEnd>
<CallId>d9aff9d99e1a4fe19507c0698ae5f3cd</CallId>
<CSEQ>1</CSEQ>
<TimeStamp>2014-02-25T17:56:12.7332588Z</TimeStamp>
</ConnectionInfo>
<Error>
<EndPoint>
<Id>5af2ea2db6</Id>
<EPId>ccdcf5ebc1</EPId>
<URI>sip:1FBFFBD1E76D4F7E60DEF1CA1B0C7248@msxfaq.net</URI>
</EndPoint>
<EndPoint>
<Id>E3FF980F002E85A2F242657513CD1EA8</Id>
<URI>sip:1FBFFBD1E76D4F7E60DEF1CA1B0C7248@msxfaq.net;gruu;opaque=app:locationprofile:get;default</URI>
</EndPoint>
<Properties>
<ResponseCode Code="403">Location profile only available when UC enabled.</ResponseCode>
<MSDiagnostics>2;reason="See response code and reason phrase";
AppUri="http://www.microsoft.com/LCS/TranslationService";source="lync2013fe.msxfaq.net"</MSDiagnostics>
</Properties>
</Error>
</LyncDiagnostics>
QoE-Data
You can also find QoE-Report Data after the call hat ended.
<LyncDiagnostics Version="1.0">
<ConnectionInfo Originator="24c094104b">
<FrontEnd>LYNC2013FE</FrontEnd>
<CallId>03783e26f8dd494c8ea2e1991b9f90e4</CallId>
<TimeStamp>2014-02-28T18:31:31.6464959Z</TimeStamp>
<Connectivity>DIRECT</Connectivity>
<StartTime>2014-02-28T18:29:46.0865Z</StartTime>
<EndTime>2014-02-28T18:31:31.0354Z</EndTime>
<AppliedBandwidthLimit>350000</AppliedBandwidthLimit>
<DialogCategory>BeforeMedServer</DialogCategory>
</ConnectionInfo>
<QualityUpdate Type="video">
<From>
<Id>687f6ca677</Id>
<URI>sip:User1@msxfaq.net</URI>
<Contact>sip:User1@msxfaq.net;opaque=User:epid:-ey0-raqhv6boojczrk_jwaa;gruu</Contact>
<IP>192.168.102.41</IP>
<Port>6508</Port>
</From>
<To>
<Id>24c094104b</Id>
<URI>sip:User2@msxfaq.net</URI>
<Contact>sip:User2@msxfaq.net;opaque=User:epid:v5mswjitsfyhyej4vldnkaaa;gruu</Contact>
<IP>192.168.103.2</IP>
<Port>33700</Port>
<Relay>80.66.20.21</Relay>
<RelayPort>51503</RelayPort>
<Inside>True</Inside>
<VPN>False</VPN>
<Connection>Ethernet</Connection>
</To>
<Properties>
<EstimatedBandwidth Codec="H264" />
<PacketUtilization>1538</PacketUtilization>
<PacketLossRate>0.001297973</PacketLossRate>
<PacketLossRateMax>0.01317565</PacketLossRateMax>
<JitterInterArrival>1</JitterInterArrival>
<JitterInterArrivalMax>3</JitterInterArrivalMax>
<VideoPacketLossRate Limit="0.1">0.001297973</VideoPacketLossRate>
<RecvFrameRateAverage Limit="7">15.02539</RecvFrameRateAverage>
<VideoLocalFrameLossPercentageAvg Limit="10">0.5873715</VideoLocalFrameLossPercentageAvg>
<LocalFrameLossPercentageAvg>0.5873715</LocalFrameLossPercentageAvg>
<BitRateMax>326694</BitRateMax>
<BitRateAvg>168614</BitRateAvg>
</Properties>
</QualityUpdate>
</LyncDiagnostics>
Build your own LDM
But that knowledge in my mind, i started to develop a PowerShell-Sample as "Proof of concept". It should fulfill three requirements:
- Receive the POST
the Script uses a HTTPListener to get the POST-messages from the LDL - Write the data to a file
this is always a great idea für debugging and later processing. But it can still be optimized - Parse and store the data
The Script grabs the interesting information out of the Payload and keeps a kind of "connection Table" in the memory - Generate a nice HTML-Output
A Browser can also connect to the service and use a GET. The Script will then generate a dynamic HTML-Stream and sends that to the browser.
It is a initial version, so do not expect SSL-Encryption, Authentication etc.
Even the Microsoft LDM/LDL-Paket does not use any authentication. So you should configure your firewall to prevent, that attackes may send invalid Data, which looks like sent by an valid LDL-Service
So the picture will change a little bit:
the PowerShell Script will work as a replacement für the LDM Service and listens on Port 9333 für incoming POST-Requests from the LDL. Additionally it also listen für GET-requests from any browser and generates a simple view like:
This is a picture from the initial version and shows an connection from me to the Lync Audio testbot. You can see that i'm on 173.10.121.193, which was a german DSL-Connection and the Audio-Stream was sent to 80.66.20.21, which is the public OF of the AVEdge-Server. This is only a reduced view, because my goal was to show primärily the Active Calls and not all Details of any Calls.
Download and Installation
The current version is a simple PowerShell Script, without any installer. You still have to download install the Lync LDL-Component on the Frontend Server and to configure the LDM-Adresse property:
Lync SDN API
Version 2.0
http://www.microsoft.com/en-us/download/details.aspx?id=39714
Version 2.1
http://www.microsoft.com/en-us/download/details.aspx?id=44274
Use your Servername, which will run the LDM or PowerShell replacement Script
After that you simply have to run the PowerShell-Script as an Administrator. Administrative permissions are required to create a HTTP-Listener. Start the Script with the option "-verbose" to see more details.
Script currently not working with SDN 2.1. Update work in progress
And then use your preferred browser and open http://servername:9333. A refresh will be done automatically by the browser.
Future
SDN is great even if you do not have a compatible network environment to consume the data. The data is still a good source to build small custom solutions or simply to track the Ports and connections and maybe, we will have a service or SQL-backend later to do some additional reporting.
Please keep in mind, that SDN cannot and will not replace the native Lync Monitoring Database (QoE). This contains more information and you have ready to use SQL Reports. Do not reinvent the wheel.
But it might be a good idea to escalate quality issues or even simply view the usage of certain endpoints. The next step is to build a "real service", which can run permanently and write down optimized report files. The Web output also need some work to do to allow some formatting and maybe Search-features für larger customers. But then we also have to add support für any kind of authentication. Maybe a ASPX-Website is a better approach. stay tuned.
