Audiocodes QoS
Auch wenn ein Audiocodes keine Lync-QoE-Reports unterstützt, so protokolliert er doch den ein oder anderen Wert mit und wenn Sie z.B. die Daten per Syslog mitschneiden, dann können Sie darauf durchaus Rückschlüsse ziehen. Das ist insbesondere wichtig bei der Nutzung von MediaBypass, wo Sie ansonsten nur die "Hälfte" der Daten sehen.
Aktivieren in der Konfiguration
Allerdings müssen Sie auf dem Mediant erst die QoS-Reports aktivieren. Dies geht unter "VoIP - SIP Definitions - Advanced Parameters". Sie müssen sich eventuell noch die "Advanced Parameter List" rechts oben aktivieren. Es gibt zwei Stellen, an denen Sie QoS-Einstellungen aktivieren können:
Sie bedeuten:
- QoS Statistics in Release
Msg
Hierbei wird beim BYE ein Statistik-Report mitgeliefert, den Sie leider in Lync nicht auswerten können. Sie sehen diese aber im Syslog und bei aktiviertem Lync Server/Clientlogging auch in den Snooper Logs - CDR Reporting
Eigentlich aktivieren Sie nur das Audiocodes CDR-Reporting. Allerdings enthält der CDR-Record auch QoS-Daten
CDR Record
CDR-Daten haben nicht direkt etwas mit QoS zu tun, da sie keinen direkten Einfluss auf die Pakete auf dem LAN haben. Die Informationen in den CDR-Daten aber enthalten auch Informationen über die QoS-Verbindung. So sind folgende Felder im CDR-Log für QoS-Auswertungen interessant
- InPackets
- OutPackets
- PackLoss
- RemotePackLoss
- LocalRtpPort
- RTPdelay
- RTPjitter
- TxRTPIPDiffServ
- TxSigIPDiffServ
Sie können z.B. erkennen, welche Latenz der Pakete gemessen wurde aber auch, mit welchem QoS-Tag eingehende Pakete gekennzeichnet waren. Auch können Sie den verwendeten RTP-Port auslesen und so ermitteln, welche Endgeräte vielleicht noch nicht in der Port-Range kommunizieren, die Sie für QoS-Tagging aktiviert haben.
Zum CDR-Recording habe ich auf Audiocodes CDR eine eigene Seite geschrieben.
BYE Daten mit X-RTP-Stat
Die QoS-Reports in der Release Message finden sich im BYE, welches vom Mediant gesendet wird, wenn die andere Seite auflegt.
BYE sip:nawlync001.netatwork.de:5068;maddr=192.168.100.100;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 192.168.100.107;branch=z9hG4bKac1153483696;alias Max-Forwards: 70 From: <sip:+495246700971@nawm1000.netatwork.de;User=phone>;tag=1c946812170 To: "Carius, Frank"<sip:+495251304613;ext=613@netatwork.de;User=phone>;epid=4D7606;tag=7276e71463 Call-ID: 6d15d4bc-7d91-4804-9ef9-5c5b4ec2e988 CSeq: 1 BYE Supported: em,timer,replaces,path,resource-priority Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SuBSCRIBE,uPDATE User-Agent: Audiocodes-Sip-Gateway-Mediant 1000/v.6.40A.042.004 Reason: Q.850 ;cause=16 X-RTP-Stat: PS=152; OS=23525; PR=173; OR=27362; PL=0; JI=0; LA=0 Content-Length: 0
Legt der Lync Anrufer auf, so sind die Meldungen in den "200 OK" Antwort auf das BYE enthalten
SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.100.100:52141;branch=z9hG4bKfd394583 From: "Carius, Frank"<sip:+495251304613;ext=613@netatwork.de;User=phone>;epid=4D06;tag=7af46 To: <sip:+49524670071@nawm1000.netatwork.de;User=phone>;tag=1c14 Call-ID: e93ab990-4dbd-4ee6-84ce-5160e527ccf7 CSeq: 8850 BYE Contact: <sip:192.168.100.107:5060;User=phone;transport=tcp> Supported: em,timer,replaces,path,resource-priority Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SuBSCRIBE,uPDATE Server: Audiocodes-Sip-Gateway-Mediant 1000/v.6.40A.042.004 X-RTP-Stat: PS=99; OS=15522; PR=0; OR=0; PL=0; JI=0; LA=0 Content-Length: 0
Leider gibt es nun Seitens des Mediation Servers als "Next Hop" in Richtung Lync/Skype4B keine Möglichkeit solche "Custom Header" einzusammeln und zu verwerten.
Bedeutung der Werte
Aus einem Trace habe ich die Werte einmal extrahiert und die Bedeutung dazu geschrieben.
Wert | Bedeutung |
---|---|
PS=152 |
Packets Sent |
OS=23525 |
Octet Sent |
PR=173 |
Packets received |
OR=27362 |
Octet received |
PL=0 |
Packet Loss |
JI=0 |
Jitter in ms |
LA=0 |
Latent in ms |
Wenn also eine "Gegenseite" diese Werte auslesen würde, könnte Sie so einen QoE-Report erstellen
Ideen
Denkbar wäre natürlich, dass ein MSPL-Script auf dem Mediation Server diese Daten abfängt und als QoE-Report weiter leitet. Ebenso wäre es natürlich möglich, über die SYSLOG-Funktion des Mediant diese Daten zu erhalten und weiter zu verarbeiten.