PSTN-Calling Germany / Calling Plan

Seit dem 1. November 2017 können Sie in Deutschland mit Skype for Business nicht nur Chatten und Konferenzen abhalten, sondern auch mit anderen Telefonteilnehmern telefonieren. Sie brauchen keine eigene Hybrid-Umgebung oder Skype for Business Cloud Connector Edition (CCE) mehr. Rufnummern UND TK-Trunk stellt Microsoft. Damit endet eine 5 monatige "PreView" Phase. Hier ein Praxisbericht meines Test und Pilot-Umfelds.

Zum 1. Oktober hat Microsoft die Bezeichnungen geändert

Was ist PSTN-Calling?

Mit der passenden Lizenz können Sie mit Skype for Business Online sogar richtig telefonieren. Eine Audio und Video-Verbindung per Skype mittels SIP-Adressen zu allen anderen Skype for Business und Skype Consumer-Nutzern ist unabhängig davon schon lange möglich und auch Audio-Konferenzen mit Telefoneinwahl sind schon lange verfügbar. Mit PSTN-Calling tritt Microsoft nun aber in den Markt der Carrier ein und bietet ihnen als Kunden sogar eine Rufnummer aus dem entsprechenden Land an. Angefangen hat alles in USA, Puerto Rico und UK. Danach sind Frankreich und Spanien dazu gekommen. Über die Preview wird es aktuell möglich sein, dass Sie auch in Deutschland von Microsoft Rufnummern bekommen oder sie ihre eigenen Rufnummern sogar portieren können und dann komplett ohne lokale TK-Technik mit anderen klassischen Telefonanwendern mittels "Nummern" sich verbinden.

Natürlich gibt es auch weiterhin die Optionen, sich mittels Hybrid Mode oder einer Cloud Connector Edition mit Rufnummern zu versorgen. Es wird auch immer Umgebungen geben, in denen Mehrwerte und Zusatzfunktionen einen lokale TK-Technik und eine lokale Anbindung erfordern. Speziell kleinere Firmen und insbesondere Selbständige und Handwerke können aber von einem E5-paket profitieren, mit dem sie nicht nur ein großes Exchange Postfach, XXL-OneDrive, etwas SharePoint und viele andere Dinge bekommen, sondern nun auch noch darüber vollwertig kommunizieren können

Nun warten wir mal ab, wie die Preview anläuft, welche Vorwahlen zur Verfügung stehen, wie die Portierung erfolgt und letztlich wie die Kosten berechnet werden. Aber vielleicht reicht mir zukünftig wirklich ein einfacher "Internet Anschluss" eines beliebigen Anbieters und die qualifizierten Mehrwertdienste kommen dann von Office 365.

Der Artikel wird fortgesetzt...

Hinweis: Die hier in den Bildern und Traces teilweise sichtbaren Rufnummern sind reine Testnummern und in der Regel nicht erreichbar. Zum Teil sind Sie von mir absichtlich auch verändert worden.

Aktivieren der Preview

Solange diese Funktion noch "Preview" ist, müssen Sie sich auf https://www.skypepreview.com/ mit ihrem Tenant erst einmal registrieren. Aktuell scheint Microsoft ca. alle 6 Wochen die Tenants dann auch wirklich zu aktivieren. Es kann also etwas dauern, bis die entsprechenden Funktionen und Menüs in ihrem Tenant dann auch erscheinen.

Nachdem ihre Tenant für PSTN Calling freigeschaltet wurde, finden Sie in ihrem Skype for Business Control Panel in Office 365 auch den Eintrag VoIP und sogar die GUI und Hinweise zu den noch nicht möglichen Portierungsaufträgen sind schon in Deutsch verfügbar.

Notfallstandort anlegen

Ehe Sie aber nun wild Rufnummern beantragen können, gibt es noch ein paar Vorarbeiten. Zuerst sollten Sie über den Punkt "Notfallstandorte" unter VoIP ihre echten Firmenstandorte hinterlegen. Hier sollten Sie dann auch "Deutschland" sehen:

 

Microsoft scheint die Adresse gegen einen Datenbestand zu prüfen. Ungültige Daten sind also nicht möglich. Aber ob Sie wirklich dort auch einen Standort haben, wird erst einmal nicht überprüft.

Rufnummern

In einigen Ländern können Sie die Rufnummern direkt per Webseite von Microsoft anfordern lassen. Wann und wie das in Deutschland der Fall sein wird, ist noch nicht klar. Das hängt sicher auch von den Ortsnetzen und den Notfallstandorten ab. Eine gute Übersicht liefert die folgende Seite

Wenn Sie unterschiedliche Rufnummerarten, z.B. Teilnehmernummer, ServiceNummer, kostenfreie Einwahlnummer, benötigen, müssen sie mehrere Formulare einsenden. Microsoft unterscheidet diese nummern nach "Belastung". eine Servicenummer wird intensiver eingehend benutzt, während eine Teilnehmernummer weniger aber bidirektionale Gesprächsminuten aufweist. Dies ist wichtig für die Planung der SIP-Verbindungen im Backend.

In den meisten Ländern erwartet Microsoft ein Dokument, womit sie letztlich bestätigen, dass Sie dazu berechtigt sind. Der Prozess der Portierung bestehender Rufnummern wird noch nachgereicht.

Das Formular senden Sie dann an die von Microsoft vorgegebene Mailadresse. Die jeweils gültige Adresse finden Sie auf der Webseite mit den Formulardownload.

Statusmeldung

Bei mir hat es nicht mal 10 Stunden gedauert, bis die erste Statusmeldung ankam. Anscheinend lesen noch Menschen die PDF-Dateien und stellen eine Anfrage nach den Nummern an die entsprechende Regulierungsbehörde.

Und ca. 7 Stunden später kam die Abschlussmeldung:

Rufnummer an Benutzer zuweisen

Danach finde ich alle Rufnummern direkt in meinem Tenant als "Unassigned". Ich bin sicher, dass später auch eine automatische Beantragung über das "+" am Anfang der Liste möglich sein wird.

Allerdings sehen Sie auch, dass im Antragformular noch 05257 als Rufnummer stand, aber die Rufnummern letztlich dann aus dem Ortsnetz Bielefeld gekommen sind. Anscheinend ist noch nicht jedes Ortsnetz verfügbar. Die "Emergency Location" ist entsprechend gepflegt und ich bin nur noch einen Mausklick davon entfernt, die Rufnummer einen Benutzer zuzuweisen. Sie wählen die gewünschte freie Rufnummer aus und weisen Sie einem Benutzer zu. Sie können nach Benutzern suchen. Die Anwender dürfen natürlich noch keine andere Rufnummer haben und benötigen eine entsprechende Lizenz (E5 oder E3 + CloudPBX + PSTN Calling, o.ä.)

Eine andere Ansicht erhalten Sie über den Reiter "Voice Users"

Hier sehen Sie dann alle Benutzer mit der passenden Lizenz und der aktuell zugewiesenen Rufnummer. Auch hier können eine Rufnummer zuweisen.

Hinweis: jeder Rufnummer ist eine "Emergency Location" zugewiesen und die Anwender müssen als "Location" ebenfalls dieses Land haben. Sie können eine Deutsche Rufnummer also nur einem Benutzer zuweisen, der auch "DE" als Office 365 Standort hinterlegt hat.

Dann dauert es noch ein paar Minuten bis die Replikation abgeschlossen ist und der Anwender sieht seine Rufnummer auch im Skype for Business Client.

Ausgehende Anrufe waren innerhalb von Minuten möglich. Ein Anruf auf diese Rufnummer dauert aber etwas länger. Die Nummer wurde zwar Microsoft schon zugeteilt aber bis diese auch wirklich "erreichbar" ist können weitere Stunden vergehen.

Praktische Erfahrung

Natürlich habe ich eine kleine Testserie gemacht, von der ich hier berichten will. Zuerst noch mal der zeitliche Ablauf

24. Jul 01:16  Versand der Rufnummernanforderung (PDF)
24. Jul 10:00  Einfang der Bestätigungsmail: Auftrag in Bearbeitung
24. Jul 17:15  Eingang der Bestätigungsmail: Rufnummern aktiviert
24. Jul 22:00  Zuweisen einer Rufnummer an einen Benutzer. Ausgehende Rufe funktionieren
25. Jul 08:00  Eingehende Rufe gehen noch immer nicht.
27. Jul Do ?   Eingehende Anrufe gehen, landen auf der VoiceMail
03. Aug xx:xx  Alle Nummern sind nicht mehr da. Seit ca. 3 Tagen gehören Sie einem anderen Tenant  OOPS.
10. Aug Sachverhalt geklärt: Die Nummer aus dem Ortsnetz 0521 hätte ich nie bekommen dürfen
        Meine Emergency Address passt nicht aber die zu der Zeit erforderlich manuelle Bearbeitung hat einen Fehler gemacht
        Ich habe nun neue Nummern im Ortsnetz 05257 erhalten. Sie sind nach ca. 2h auch produktiv.
        Dafür gibt es eben eine "Preview" um solche Fehler zu bemerken und den Prozess zu ändern.

Folgende Telefonate habe ich bislang geführt:

Testfall Ergebnis

Eingehender Anruf auf eine aktivierte aber nicht geroutete Rufnummer

Kurz nachdem die Rufnummer meinem Tenant zugewiesen wurde, habe ich einen Anruf versucht. Es scheint hier aber noch so zu sein, dass mir die Nummer schon gehört aber die Telekom z.B. noch nicht weiß, wohin diese zu routen ist. Nach ca. 5 Sek kommt eine Sprachansage "Sorry, but your call cannot be completed". Danach kommt dann die deutsche Ansage mit "Dieser Anschluss ist vorübergehend nicht erreichbar". Das Verhalten ist vom ISDN als auch Mobilfunknetz identisch. Es scheint so, als ob diese "Ansage" vor der eigentlichen Verbindung kommt. Hier die Ansage als Aufzeichnung.

(Ab Sekunde 5 beginnt erst der Ton. So lange braucht der Verbindungsaufbau)

Eingehender Anruf auf eine aktivierte aber nicht zugewiesene Rufnummer

Deutsche Ansage: "Kein Anschluss unter dieser Nummer"

Eingehender Anruf auf eine aktivierte und zugewiesene Rufnummer. Teilnehmer ist aber offline

Anruf landet auf der Voice-Mail

Eingehender Anruf auf eine aktivierte und zugewiesene Rufnummer. Teilnehmer ist online

Anruf wird am Client signalisiert mit kompletter E.164.Nummer. Bis es letztlich "klingelt" vergehen einige Sekunden (bis zu 8 Sek bei meinen Tests). Die Audioverbindung steht aber umgehend.

Ausgehender Anruf von SfB zu einem ISDN-Teilnehmer

Nach ca. 4 Sekunden klingelte das Telefon. Die Rufnummer wurde sauber angezeigt.

Ausgehender Anruf von SfB zu einem Mobilfunkteilnehmer

Hier dauerte es ca. 6-7 Sekunden, bis mein Mobilfunkprovider das Telefon angeklingelt hat.

Trace ausgehender Call

Natürlich kann ich bei Skype for Business Online keinen Trace auf dem Server direkt machen. Aber auch das UCCAPI-Log auf dem Client ist sehr aufschlussreich. Auch hier ist es wieder ein INVITE zur Rufnummer gefolgt von "100 TRYING" aber dann kommt schon ein Extra-Paket, welches OnPremise noch nicht sichtbar ist:

07/24/2017|22:18:10.298 3140:3144 INFO  :: SIP/2.0 101 Diagnostics
ms-user-logon-data: RemoteUser
Authentication-Info: TLS-DSK qop="auth", opaque="193AB12D", srand="1309B3FA"
Via: SIP/2.0/TLS 192.168.180.108:50230;received=79.196.135.146;ms-received-port=50230;ms-received-cid=1329D00
From: "Frank Carius (ADM)"<sip:user1@uclabor.de>;tag=7544ecb714;epid=c4b6275e0f
To: <sip:+4952579388085@fcarius.onmicrosoft.com;user=phone>
Call-ID: 496737479f5f4695acac4d416360fe50
CSeq: 1 INVITE
ms-telemetry-id: A5ABD95E-ED30-56FD-BF00-1AA677C0A5E3
ms-diagnostics: 42007;reason="Routing to Gateway";
   source="BL20R04RFE02.INFRA.LYNC.COM";
   Profile="12345678-1234-1234-1234-1234567890ab";
   Destination="de1.s4b.ims.colt.net";
   appName="BusinessVoiceRouting"
Server: BusinessVoiceRouting/7.0.0.0
Content-Length: 0
ms-edge-proxy-message-trust: ms-source-type=AutoFederation;
   ms-ep-fqdn=sipedgeblu2a.infra.lync.com;
   ms-source-verified-user=verified;
   ms-source-network=federation

Aus dem "MSDiagnostics-Header ist gut zu sehen, zu welchem Gateway (BL20R04RFE02.INFRA.LYNC.COM) der Anruf geroutet wird und auch welcher TK-Carrier (Colt) genutzt wird. Ein NSLookup auf de1.s4b.ims.colt.net liefert sogar eine IPv4-Adresse (213.86.212.171). Natürlich ist keiner der üblichen Port (5061,5067,5068) offen und ein WHOIS verortet das Gateway irgendwie in London, UK.

Die nächste Antwort ist der "183 Session Progress" mit den Kandidaten. Auch hier keine Überraschung (Trace gekürzt)

07/24/2017|22:18:10.575 3140:3144 INFO  :: SIP/2.0 183 Session Progress
ms-user-logon-data: RemoteUser
CSEQ: 1 INVITE
SERVER: RTCC/7.0.0.0 MediationServer
ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet
Ms-Mediation-Generated: yes

v=0
o=- 163439 0 IN IP4 131.253.178.43
m=audio 60600 RTP/SAVP 0 8 115 13 118 97 101
c=IN IP4 10.20.124.44
a=candidate:1 1 UDP 2130706431 10.20.124.44 60600 typ host
a=candidate:1 2 UDP 2130705918 10.20.124.44 60601 typ host
a=candidate:2 1 tcp-pass 174456319 52.112.162.29 55079 typ relay raddr 10.20.124.44 rport 60853
a=candidate:2 2 tcp-pass 174455806 52.112.162.29 55079 typ relay raddr 10.20.124.44 rport 60853
a=candidate:3 1 UDP 184548351 52.112.162.29 52504 typ relay raddr 10.20.124.44 rport 62322
a=candidate:3 2 UDP 184547838 52.112.162.29 55725 typ relay raddr 10.20.124.44 rport 62323
a=candidate:4 1 tcp-act 174848511 52.112.162.29 55079 typ relay raddr 10.20.124.44 rport 60853
a=candidate:4 2 tcp-act 174847998 52.112.162.29 55079 typ relay raddr 10.20.124.44 rport 60853
a=candidate:5 1 tcp-act 1684797439 10.20.124.44 60853 typ srflx raddr 10.20.124.44 rport 60853
a=candidate:5 2 tcp-act 1684796926 10.20.124.44 60853 typ srflx raddr 10.20.124.44 rport 60853

Ich bekomme von Office 365 private 10er IP-Adressen aber auch die Relay-Adressen des Edge Servers (Diesmal 52.112.162.29) angeboten. Ich sehe weder eine öffentliche IP-Adresse eines Mediation Servern, was aufgrund des Edge ehr nicht geht. Aber ich sehe auch keine IP-Adressen des Gateways von Colt. Media läuft, wie nicht anders zu erwarten, über die Edge Server zum Office 365 Tenant und von dort über den Mediation Server als Relay zum Gateway. Auch wenn als UserAgent hier ein "RTCC/7.0.0.0 Mediation Server" steht, verhält sich Skype for Business noch genau so wie Skye for Business On Premise.

Trace eingehender Call

Nachdem ich auch eingehende Anruf vom Festnetz auf Skype for Business bei Microsoft auslösen konnte, ist der eingehende Invite natürlich interessant:

07/31/2017|14:52:52.919 D48:17CC INFO  :: Data Received -52.112.67.44:443 (To Local Address: 192.168.180.108:49926) 5419 bytes:
07/31/2017|14:52:52.919 D48:17CC INFO  :: INVITE sip:79.196.147.38:49926;transport=tls;ms-opaque=615ce4530b;ms-received-cid=9806B00 SIP/2.0
ms-user-logon-data: RemoteUser
Record-Route: <sip:sippoolblu2a18.infra.lync.com:443;transport=tls;ms-fe=BLU2A18FES13.infra.lync.com;
Via: SIP/2.0/TLS 10.5.17.140:443;branch=z9hG4bKBE2B9A16.B0D3C7FB8186DC64;branched=FALSE;ms-internal-info="xxx"
Authentication-Info: TLS-DSK qop="auth", opaque="510B8BB9", srand="71498AE9", snum="20", rspauth="xxx", targetname="BLU2A18FES13.infra.lync.com", realm="SIP Communications Service", version=4
Max-Forwards: 64
Content-Length: 1690
Via: SIP/2.0/TLS 10.5.17.129:36507;branch=xx.xx;branched=TRUE;ms-received-port=36507;ms-received-cid=xx
Via: SIP/2.0/TLS 10.5.17.141:42202;branch=xx.xx;branched=FALSE;ms-received-port=42202;ms-received-cid=xx
Via: SIP/2.0/TLS 10.5.16.45:50524;branch=xx.xx;branched=FALSE;ms-received-port=50524;ms-received-cid=xx
Via: SIP/2.0/TLS 10.201.0.35:46615;branch=xx.xx;branched=FALSE;ms-received-port=46615;ms-received-cid=xx
Via: SIP/2.0/TLS 10.201.0.100:38953;branch=xx.xx;branched=TRUE;ms-received-port=38953;ms-received-cid=xx
Via: SIP/2.0/TLS 10.201.0.41:38752;branch=xx;received=10.201.1.254;ms-received-port=38752;ms-received-cid=x
Record-Route: <sip:sippoolblu2a18.infra.lync.com:5061;transport=tls;ms-fe=BLU2A18FES02.infra.lync.com;opaque=state:F;lr>;tag=x
Record-Route: <sip:sipedgeblu2a.infra.lync.com:5061;transport=tls;opaque=state:Ifi;lr>;tag=x
Record-Route: <sip:sipedgeAM30R.infra.lync.com:5061;transport=tls;opaque=state:Ifi;lr>;tag=x
Record-Route: <sip:srppoolam30r04.infra.lync.com:5061;transport=tls;ms-fe=xx.infra.lync.com;lr>;tag=x
From: <sip:+495257938808@fcarius.onmicrosoft.com;user=phone>;epid=xx;tag=xx
To: <sip:+495219227851@fcarius.onmicrosoft.com;user=phone>;epid=xx
CSeq: 527562 INVITE
Call-ID: 1ab56ae3-cd54-487f-b2a5-43d7b67f2793
Contact: <sip:AM30R00MED03.infra.lync.com@resources.lync.com;gruu;opaque=srvr:MediationServer:JrWI_cSr8VK0y6txcQxzKwAA;grid=xx>;isGateway
Supported: replaces
Supported: ms-safe-transfer
Supported: ms-bypass
Supported: ms-anonymize-from
Supported: replaces
Supported: ms-safe-transfer
Supported: ms-bypass
Supported: ms-anonymize-from
Supported: ms-dialog-route-set-update
Supported: timer
Supported: 100rel
Supported: gruu-10
User-Agent: RTCC/7.0.0.0 MediationServer
Content-Type: application/sdp
Allow: ACK
ms-gateway-callid: 1409823026_17272531@213.86.212.171
ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet
ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet
ms-trunking-peer: de1.s4b.ims.colt.net
Session-Expires: 1800
Min-SE: 90
Allow: CANCEL,BYE,INVITE,REFER,NOTIFY,PRACK,UPDATE
ms-telemetry-id: 8950C7F2-128C-5945-A988-0BEEA2B1AF01
ms-edge-proxy-message-trust: ms-source-type=Pstn;ms-ep-fqdn=AM30R04RFE01.infra.lync.com;ms-source-verified-user=verified
history-info: <sip:user1@uclabor.de>;index=1;ms-target-phone="tel:+4952192278510"

v=0
o=- 250974 0 IN IP4 131.253.178.12
s=session
c=IN IP4 10.201.0.41
b=CT:1000000
t=0 0
m=audio 62516 RTP/AVP 0 8 115 13 118 97 101
c=IN IP4 10.201.0.41
a=rtcp-rsize
a=rtcp-fb:* x-message app send:dsh recv:dsh
a=rtcp:62517
a=ice-ufrag:FDT8
a=ice-pwd:gyjB8nktbbRb1h1fCyxFwJEe
a=candidate:1 1 UDP 2130706431 10.201.0.41 62516 typ host
a=candidate:1 2 UDP 2130705918 10.201.0.41 62517 typ host
a=candidate:2 1 tcp-pass 174456319 52.112.161.141 58415 typ relay raddr 10.201.0.41 rport 60434
a=candidate:2 2 tcp-pass 174455806 52.112.161.141 58415 typ relay raddr 10.201.0.41 rport 60434
a=candidate:3 1 UDP 184548351 52.112.161.141 54532 typ relay raddr 10.201.0.41 rport 63254
a=candidate:3 2 UDP 184547838 52.112.161.141 56548 typ relay raddr 10.201.0.41 rport 63255
a=candidate:4 1 tcp-act 174848511 52.112.161.141 58415 typ relay raddr 10.201.0.41 rport 60434
a=candidate:4 2 tcp-act 174847998 52.112.161.141 58415 typ relay raddr 10.201.0.41 rport 60434
a=candidate:5 1 tcp-act 1684797439 10.201.0.41 60434 typ srflx raddr 10.201.0.41 rport 60434
a=candidate:5 2 tcp-act 1684796926 10.201.0.41 60434 typ srflx raddr 10.201.0.41 rport 60434
a=label:main-audio
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:xxxx|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:xxxx|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:xxxx|2^31
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,36

07/31/2017|14:52:52.919 D48:17CC INFO  :: End of Data Received -52.112.67.44:443 (To Local Address: 192.168.180.108:49926) 5419 bytes

Interessant sind folgende Daten:

  • AM30R00MED03.infra.lync.com
    Das ist der Name des Mediation Servers. Ein NSLOOKUP liefert sogar eine öffentliche IP-Adresse 131.253.178.12. Ich nehme an, dass damit Microsoft den SIP-Trunk zu den Carriern aufbaut. Es wäre natürlich interessant, wenn die Clients auch direkt den Mediation Server erreichen könnten (Stichwort Media Bypass). Aber die IP-Adresse erscheint nicht in den SDP-Kandidaten und über einen Edge-Server ist aktuell auch kein Bypass möglich
  • ms-trunking-peer: de1.s4b.ims.colt.net
    Das dürfte der Name bzw. das Gateway des SIP-Trunks sein. Meine Rufnummer wird also von Colt verwaltet und der Host löst auf die IPv4-Adresse 213.86.212.171 auf. Laut WhoIS steht er wohl in London
  • Codec-Reihenfolge
    Interessant ist, dass G711 (A/U-Law) als erstes stehen und dann noch X-msrta kommt aber kein RTAudio oder gar SILK angeboten wird.

Durchaus interessante Daten. Ich kann nur hoffen, dass zukünftig vielleicht auch ein Gateway in Deutschland angeboten wird. In Anbetracht des Brexit und der nicht garantierten verschlüsselten Kommunikation auf dem SIP-Trunk wäre das ein wichtiger Faktor.

Latenzzeit

Einmal von Hövelhof über Telekom-ISDN zu Colt und dann per SIP-Trunk zu Microsoft und dann über Internet und T-DSL wieder nach Hövelhof. Da stellt sich schon die Frage nach der Laufzeit. Ich bin hier dreigleisig gefahren

  • Echo-Test
    Ich habe einfach einen Ton auf einem Endgerät generiert und mit einem Sprachrecorder den ersten Ton und den wiedergegebenen Ton aufgezeichnet. Mit Audacity kann man recht einfach dann die Verzögerung ausmessen
  • UCCAPI-Log
    Während und nach dem Gespräch sendet der Skype for Business Client entsprechende QoE-Daten per SIP an den Server. Dies kann im UCCAPI-Log eingesehen werden
  • QoE-Dashboard
    Natürlich hält auch Skype for Business Online entsprechende Auswertefunktionen für die Gesprächsqualität bereit.

Schauen wir uns die einzelnen Reports einmal an

Latenz mit Echotest

Mit meinem Smartphone habe ich die Diktierfunktion genutzt und einfach beide Geräte (Telefonhörer des ISDN-Telefons und den PC) nebeneinander gehalten und per "klopfen" einmal auf dem Mikrofon des Hörers und einmal auf den PC-Gehäuse entsprechende Signale generiert. Interessant ist hier natürlich auch, dass durch die Rückkopplung der Ton ein paar mal wiederholt wird.

Dies ist ein Test, bei dem ich auf den Hörer des ISDN-Telefons getippt habe. (ca. 3,28 Sek nach starte der Aufzeichnung)  ca. 340ms später (3,62) nimmt mein Smartphone den Ton aus dem PC auf, der aber auch vom Telefon wieder erfasst wird und an der Position 3 (ca. 3,98 Sek)wiedergegeben wird. In die Gegenrichtung scheint es minimal schneller zu sein. Ein "Tippen" auf dem PC wird im Telefonhörer wiedergegeben.

Der Ton bei Sekunde 13,80 wird bei ca. 14:11, also 330ms später, wiedergegeben. Das ist natürlich sehr langsam aber über diesen einfachen Test konnte ich die Ursache nicht ermitteln.

Beachten Sie, dass dies nicht die Latenzzeit auf dem LAN/WAN ist sondern durchaus auch noch Verzögerungen der AD-Wandung und Paketierung sind. Interessant ist nun natürlich auch, wo die Zeit auf der Stecke bleibt.

Latenz aus QoE-Report

Der QoE-Report, der aus der lokalen UCCAPI-Log-Datei extrahiert werden kann, ist nach einer XML-Umformatierung über 400 Zeilen lang. Die will ich nicht komplett abdrucken. Sie können aber gerne die Zeilen anschauen

pstncalling-qoereport.txt
QoE-Report XMLS

Ich habe ein paar Zeilen extrahiert

07/31/2017|14:56:42.181 D48:17CC INFO  :: Qoe media line: 

<MediaLine xmlns="ms-rtcp-metrics" xmlns:v2="ms-rtcp-metrics.v2" xmlns:v3="ms-rtcp-metrics.v3" xmlns:v4="ms-rtcp-metrics.v4" xmlns:v5="ms-rtcp-metrics.v5" xmlns:v6="ms-rtcp-metrics.v6" Label="main-audio">
	<Description>
		<Connectivity>
			<Ice>RELAY</Ice>
		</Connectivity>
		<Security>SRTP</Security>
		<Transport>UDP</Transport>
		<NetworkConnectivityInfo>
			<NetworkConnection>wifi</NetworkConnection>
			<v3:TraceRoute><v3:Hop>0</v3:Hop><v3:IPAddress>192.168.180.1</v3:IPAddress><v3:RTT>278</v3:RTT></v3:TraceRoute>
			<v3:TraceRoute><v3:Hop>1</v3:Hop><v3:IPAddress>192.168.178.1</v3:IPAddress><v3:RTT>279</v3:RTT></v3:TraceRoute>
			<v3:TraceRoute><v3:Hop>2</v3:Hop><v3:IPAddress>87.186.225.45</v3:IPAddress><v3:RTT>297</v3:RTT></v3:TraceRoute>
			<v3:TraceRoute><v3:Hop>3</v3:Hop><v3:IPAddress>217.0.92.86</v3:IPAddress><v3:RTT>309</v3:RTT></v3:TraceRoute>
			<v3:TraceRoute><v3:Hop>4</v3:Hop><v3:IPAddress>217.5.118.10</v3:IPAddress><v3:RTT>459</v3:RTT></v3:TraceRoute>
			<v3:TraceRoute><v3:Hop>5</v3:Hop><v3:IPAddress>80.157.131.138</v3:IPAddress><v3:RTT>321</v3:RTT></v3:TraceRoute>
			<v3:TraceRoute><v3:Hop>6</v3:Hop><v3:IPAddress>104.44.9.254</v3:IPAddress><v3:RTT>321</v3:RTT></v3:TraceRoute>
			<v3:TraceRoute><v3:Hop>7</v3:Hop><v3:IPAddress>104.44.5.17</v3:IPAddress><v3:RTT>323</v3:RTT></v3:TraceRoute>
			<v3:TraceRoute><v3:Hop>8</v3:Hop><v3:IPAddress>104.44.9.147</v3:IPAddress><v3:RTT>322</v3:RTT></v3:TraceRoute>
			<v3:TraceRoute><v3:Hop>11</v3:Hop><v3:IPAddress>52.114.124.13</v3:IPAddress><v3:RTT>345</v3:RTT></v3:TraceRoute>
		</NetworkConnectivityInfo>
	</Description>
	<InboundStream Id="203170591">
		<Network>
			<Jitter><InterArrival>27</InterArrival><InterArrivalMax>34</InterArrivalMax><v3:InterArrivalSD>5.386507</v3:InterArrivalSD></Jitter>
			<PacketLoss><LossRate>0.002363851</LossRate><LossRateMax>0.05517241</LossRateMax></PacketLoss>
			<Delay><v3:RelativeOneWay><v3:Average>0.0580002</v3:Average><v3:Max>0.2931534</v3:Max></v3:RelativeOneWay></Delay>
		</Network>
		<QualityEstimates>
			<Audio>
				<RecvListenMOS>2.24</RecvListenMOS>
				<RecvListenMOSMin>1.06</RecvListenMOSMin>
				<NetworkMOS>
					<OverallAvg>3.267494</OverallAvg>
					<OverallMin>3.194154</OverallMin>
					<DegradationAvg>0.05250621</DegradationAvg>
					<DegradationMax>0.1258461</DegradationMax>
				</NetworkMOS>
			</Audio>
		</QualityEstimates>
	</InboundStream>
	<OutboundStream Id="647143680">
		<Network>
			<Jitter><InterArrival>27</InterArrival><InterArrivalMax>206</InterArrivalMax><v3:InterArrivalSD>32.59972</v3:InterArrivalSD></Jitter>
			<PacketLoss><LossRate>0.1205602</LossRate><LossRateMax>0.794702</LossRateMax></PacketLoss>
			<Delay><RoundTrip>156</RoundTrip><RoundTripMax>1174</RoundTripMax></Delay>
		</Network>
		<QualityEstimates>
			<Audio>
				<SendListenMOS>2.08</SendListenMOS>
				<SendListenMOSMin>1.53</SendListenMOSMin>
			</Audio>
		</QualityEstimates>
	</OutboundStream>
</MediaLine>

Zuerst ist zu sehen, dass es eine Verbindung über ein "RELAY" war, d.h. der Edge-Server in der Cloud hat die Verbindung vermittelt. Interessant ist dann aber schon der "Traceroute", der an Microsoft gemeldet wird. Hier ist jede Zwischenstation zu sehen. Microsoft dürfte so eine sehr umfangreiche Landkarte der Endpunkte und die Laufzeiten bekommen. Interessant ist hier aber auch, dass schon auf der ersten Strecke eine Roundtrip-Zeit von 278ms abliegt.

WiFi und Bandbreitenwettbewerber

Meine "Messung" mit Audacity aber auch die QoE-Report haben gezeigt, dass "Delay" durchaus zwischen 200-350ms ist. die "Route" in den QoE-Reports zeigt aber auch, dass sogar schon auf dem ersten Hop hier ein Problem ist. Dazu muss ich aber eine Hintergrundinformation mitliefern: Der Client ist nicht einfach nur hinter meiner Fritz!Box am DSL 16.000 angeschlossen, sondern in einem gesonderten O3365 Test-LAN. Wer genau hinsieht erkennt, dass der Client im Netzwerk 192.168.180.x ist und der zweite Hop das Default-LAN der Fritz!Box (192.168.178.1) ist. Zwischen beiden ist ein Router der zudem eine Bandbreitendrosseln von 100kbit Upstream und 1000KBit Downstream hat. Ich möchte schon sehen, wie ein Client mit beschränkter Bandbreite zurecht kommt. In dem fall ist das 180er LAN zugleich das "Gäste-LAN", in dem auch Besucher eingebucht sein könnten. Zum Testzeitraum war dies aber nicht der Fall.

Aber die Beschränkung der Bandbreite war im Ressource Manager als auch beim PING auf den ersten Router schon zu sehen:

Auf den ersten Blick ist zu sehen, dass der Client per WLAN eingebucht ist und ca. 72kbit sendet aber die 1MBit fast komplett ausreizt. In den Details ist dann auch zu sehen, welche Prozesse noch aktiv sind:

Skype for Business, welches immer noch "lync.exe" heißt, ist mit seinen paar kbit gar nicht mal so aktiv. Parallel ist hier OneDrive aber auch OfficeClickToRun.exe kräftig aktiv. Das ist natürlich ein wesentlicher Faktor, warum schon auf der ersten Teilstrecker die Latenzeit im Beriech von 90-120ms. Wenn ich die beiden Hintergrunddienste beende/pausiere, dann ist das WLAN dieses Clients auch frei und die Verzögerung des ersten Hop reduziert sich entsprechend um ca. 100ms.

Das ist ein gutes Beispiel, dass CloudPBX und PSTN-Calling aber auch Skype for Business mit VoIP im allgemeinen von der Leistung des Netzwerks abhängt. Dabei ist das "Internet" nicht einmal zwingend der Flaschenhals, sondern oftmals ist es ein WLAN oder eine Throttling-Policy pro Client in Kombination mit Hintergrundprozessen, die Bandbreite belegen. Zu diesen Hintergrundprozessen gehören neben den beiden hier genannten Beispielen natürlich noch Windows Update und andere Sync-Client wie Dropbox u.a. und sicher auch der ein oder andere Streaming-Dienst. Gerade im Heimnetzwerk ist aber QoS und Priorisierung für Endgeräte nicht einfach möglich.

Daten aus dem Office 365 Portal

Als Administrator haben Sie natürlich im Office 365 Portal weitere Möglichkeiten die Verbindungen zu analysieren. Da gibt es das Reporting im Skype for Business Admin Center:

Hier fällt z.B. auf, dass die "From Uri" und "To Uri"-Felder anscheinend vertauscht sind, denn das Gespräch habe ich vom ISDN-Telefon her aufgebaut. Schade ist, dass die Zeit als UTC-Zeit und nicht als lokale Zeit verwendet wird. Auch bei der Auswahl der Ende-Zeit zum Filtern kann ich zwar ein Datum anwählen, aber er nutzt dann immer 00:00 morgens und nicht 23:59 abends als Ende.

Im Skype for Business Admin Center gibt es ebenfalls die Funktion nach Anrufen zu suchen und diese anzuzeigen. Hier ist die Aufbereitung der Anzeige sehr schön gelöst, auch wenn die PSTN-Seite und der SIP-Trunk keine Daten liefern.

Zuletzt gibt es noch das Call Quality Dashboard (https://cqd.lync.com/), welches in der aktuellen Version aber eher für eine Übersicht der Anrufe nach Standorte und Zeiten dient aber noch keine Analyse eines einzelnen Anrufs zulässt.

Weitere Links