PSTNHUB Insights
Beider Analyse und Fehlersuche, die ich auf der Seite Direct Routing, REFER und TLS beschrieben habe, sind mir einige interessante Einblicke in die andere Seite des Direct Routings gelungen, die ich hier beschreibe.
Auslöser
Meine Kollegen bei Net at Work sind einem sporadischen Problem nachgegangen, bei dem eingehende Anrufe bei der Weiterleitung von einem Auto Attendant zu einer Call Queue mit einer Fehler beendet wurden. Ursache war, dass der von Teams kommende "REFER" nicht beim lokalen SBC aufgrund einer TLS-Unstimmigkeit nicht angekommen sind.
Wir waren aber nicht sicher, ob es nun an der Firewall, am SBC oder vielleicht auch bei Microsoft liegt. In dem Zuge haben wir mehrere Gigabyte an SYSLOG-Protokollen durchsucht und nach verschiedenen Kriterien sortiert und gruppiert
Findings
Soll mir einer sagen dass Support langweilig und dröge ist. Im Support kann man sehr schnell sehr viel lernen und manchmal lernt man auch auf die harte Tour etwas über die Hintergründe. Bei der recht tiefen Analyse haben wir auch mit IP-Adresse und Ports, SIP-Paketen und SIP-Headern zu tun gehabt. Da habe sich einige interessante Informationen ergeben:
- DNS-RoundRobin
Eine Namensauflösung auf sip.pstnhub.microsoft.com liefert immer mal wieder eine andere IP-Adresse aber mit einem TTL von 60 Sekunden ist das deutlich weniger aufgeregt als z.B. die Media Relays unter worldaz.tr.teams.microsoft.com. - Loadbalancer
Aber auch hinter einer IP-Adresse versteckt sich nicht nur ein SIPProxy, sondern eine größere Menge. Das kann ich z.B. auf die Antwort eines "OPTIONS"-Request erkennen, in der im "User-Agent" sowohl die Version als auch vermutlich der Server versteckt ist. Hier ein paar Beispiele:
Microsoft.PSTNHub.SIPProxy v.2021.12.1.4 i.EUNO.4 Microsoft.PSTNHub.SIPProxy v.2022.1.3.2 i.EUNO.2 Microsoft.PSTNHub.SIPProxy v.2022.1.3.2 i.EUWE.0 Microsoft.PSTNHub.SIPProxy v.2022.1.3.2 i.EUWE.10
- Split-Rückkanal
Ich kann für eine CallID eine Verbindung von meine SBC zum Microsoft SIPProxy aufbauen. Das ist aber keine Garantie, dass diese Verbindung auch für alle Rückwege gehalten wird. SIP schreibt das nicht vor und indem Beispiel passiert es auch, dass der REFER über eine neue TLS-Verbindung eingeliefert wird. Das sollte keine Herausforderung für eine Firewall sein, aber sollten Sie wissen - Kein "Direct Server Return"
Anscheinend versteckt Microsoft seine SIPProxy-Systeme aber auch ausgehend hinter der Loadbalancer IP. Würden die ausgehenden Verbindungen so gestartet werden, wüsste der SIPProxy ja nicht, wohin die Antworten zugestellt werden sollten.
SIP, SIP2 oder SIP3
Microsoft bietet ihnen ja an, dass Sie zuerst den Eintrag "sip.pstnhub.microsoft.com" in ihrem SBC konfigurieren. Für Firmen in Europa ist das ein System in Europa. In den USA löst der Namen auf Zugänge in den USA auf. Zusätzlich sollten Sie aber auch als Backup/Failover-System eine zweite Route zu sip2.pstnhub.microsoft.com konfigurieren, die immer dann genutzt wird, wenn die erste Umgebung tatsächlich einmal offline sein sollte. Das sollte aber nicht der Regelfall sein, dass Sie Rufe und Audio einmal über den Teich senden.
In jedem SIP-Antwortpaket von Microsoft gibt es aber einen User-Agent. Hier exemplarisch eine Antwort auf einen OPTIONS-Request
2022-01-01 20:01:00 <157>[S=6985820] [SID=8a2170:64:303764] OPTIONS sip:sbx.msxfaq.de:5061;transport=tls SIP/2.0 FROM: <sip:sip-du-a-as.pstnhub.microsoft.com:5061>;tag=xxxxxx TO: <sip:192.168.14.100> CSEQ: 1 OPTIONS CALL-ID: <guid> MAX-FORWARDS: 70 VIA: SIP/2.0/TLS 52.114.32.169:5061;branch=z9hG4bKa8b9d90 CONTACT: <sip:sip-du-a-as.pstnhub.microsoft.com:5061> CONTENT-LENGTH: 0 USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2021.12.1.4 i.JAEA.2 ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
Interessant sind hier drei Zeilen, die etwas Aufschluss vom Absender geben.
- FROM:
<sip:sip-du-a-as.pstnhub.microsoft.com:5061>;tag=xxxxxx
Das ist der Absender und die ersten Buchstaben könnten etwas mit dem Datacenter und der Region zu tun haben. - CONTACT:
<sip:sip-du-a-as.pstnhub.microsoft.com:5061>
Das ist bei der "OPTIONS"-Antwort der gleiche Text wie bei FROM. - USER-AGENT: Microsoft.PSTNHub.SIPProxy
v.2021.12.1.4 i.JAEA.2
Das Feld finde ich aber am interessantesten, denn hier ist eine Versionsnummer und vermutlich ein Systemname codiert.
Wenn hier da "JA" für Japan steht und "EA" für "East Asia", dann könnte die 2 eine laufende Nummer sein. "Asien" würde auch zum Code "AS" in der From und Contact-Zeile passen.
Also habe ich diese Daten aus den SYSLOG-Traces extrahiert. Select-String macht einen recht guten Job, wenn es um größere Datenmengen geht und ist meist schneller als "Get-Content".
Meine SYSLOG-Dateien lasse ich durch die NXLog Community Edition auf einen Windows Server schreiben, wobei jede Stunde ihren eigenen Dateinamen hat. Damit kann ich auch schnell bestimmte zeitliche Abschnitte selektieren. Zuerst habe ich einfach nur mal eine Stunde am 14.11.2021 von 23:00-23:59 genutzt, um den Servernamen und die Häufigkeit der Vorkommen zu ermitteln.
Select-String `
-Path syslog-2021-11-14-23*.* `
-Pattern "USER-AGENT: Microsoft.PSTNHub.SIPProxy "`
| %{$_.tostring()}`
| convertfrom-csv `
-Delimiter " " `
-Header "feld1","feld2","version","server" `
| Group-Object server -NoElement
Count Name
----- ----
72 i.EUWE.8
62 i.USEA.4
11 i.JAEA.0
3 i.ASSE.1
28 i.JAEA.2
2 i.ASSE.4
16 i.JAEA.3
Schon in einer "nächtlichen inaktiven" Stunde gibt es 194 SIP Antworten der Cloud. Da sind sicher einige OPTIONS-Anfragen drin aber vielleicht auch der ein oder andere Anruf.
Interessant wird nun aber mal eine längere Auswertung. die Auswertung. die 1,9 GB wollte ich aber nun nicht mit Convertfrom-csv und zwei Pipelines bei "Group-Object" einkippen und ein Out of Memory riskieren. Ich brauch nur den einen Wert. Daher habe ich mir eine Hashtabelle gebaut und gefüllt.
$hashtable = @{}
Select-String `
-Path syslog-2022-*.* `
-Pattern "USER-AGENT: Microsoft.PSTNHub.SIPProxy "`
| %{`
write-Host "." -nonewline;
` $hashtable[($_.tostring().split(" ")[3])]+=1
}
$hashtable.GetEnumerator() | select key,value | sort value -Descending
Key Value
--- -----
i.USEA.0 10290
i.USEA.7 5183
i.JAEA.3 4517
i.JAEA.1 4038
i.JAEA.0 3269
i.EUNO.0 2770
i.JAEA.4 2719
i.JAEA.2 2605
i.EUNO.4 2385
i.USEA.4 1303
i.EUWE.6 1281
i.EUNO.6 1192
i.EUWE.5 1078
i.EUWE.0 1034
i.EUWE.7 1002
i.EUWE.8 989
i.EUNO.11 964
i.EUWE.1 935
i.EUNO.2 929
i.EUNO.5 923
i.EUNO.10 910
i.EUNO.12 907
i.EUWE.4 898
i.EUNO.1 896
i.EUNO.9 895
i.EUWE.10 883
i.EUWE.12 881
i.EUWE.2 879
i.USEA.2 865
i.USEA.1 864
i.EUWE.11 854
i.EUNO.3 754
i.EUWE.9 744
i.EUWE.3 738
i.EUNO.8 737
i.EUNO.7 728
i.USEA.6 637
i.USEA.3 545
i.ASSE.2 498
i.ASSE.1 435
i.USEA.5 404
i.USEA.8 296
i.ASSE.3 263
i.ASSE.0 237
i.ASSE.4 218
i.USWE2.5 171
i.USWE2.0 48
i.USWE2.4 42
i.USWE2.2 28
i.USWE2.6 14
i.USWE2.7 7
Die Verteilung finde ich schon interessant. Der überwiegende Anteil der Antworten kommt von Servern aus EUNO und EUWE aber es sind auch häufige Antworten aus den USA dabei. Eine genauere Inspektion des Syslog ergab, dass der SBC auch sip2.pstnhub.microsoft.com anspricht und da natürlich eine Antwort aus den USA bekommt. Also musste ich mal schnell die Summen bilden.
$hashtable.GetEnumerator() `
| select key,value `
| where {$_.key -like "??EU*"} `
| measure -Property value -Sum `
| select count,sum `
|fl
Count : 26
Sum : 27186
Insgesamt habe ich folgende Treffer und zusätzlich habe ich zur Region die IP-Adresse und die dazugehörige DNS-Auflösung aus dem Syslog extrahiert.
| Region | Anzahl Server | Anzahl Requests | DNS-Name |
|---|---|---|---|
EU |
26 |
27186 |
sip1.pstnhub.microsoft.com |
US |
15 |
20697 |
sip2.pstnhub.microsoft.com |
AS |
5 |
1651 |
sip3.pstnhub.microsoft.com |
JA |
5 |
17148 |
sip3.pstnhub.microsoft.com |
| Summe | 51 | 66682 |
EU ist natürlich schon häufiger vorhanden aber das US und JA nicht allzu weit abgeschlagen sind, finde ich beachtlich. Also habe ich mal die eingehenden OPTIONS-Requests analysiert und tatsächlich probt der Audiocodes alle drei Proxysets regelmäßig ab und kommt so auf diese Werte. Entsprechend sind vielleicht gerade mal ca. 7000 eingehende SIP-Pakete mit einem Call verbunden. Wenn ein Call vielleicht 10 SIP-Pakete hat, käme ich auf 700 Calls in "ruhigen" 7 Arbeitstagen, was dann schon wieder hinkommt.
Die OPTIONS-Requests machen also einen großen Anteil der Anforderungen aus. Mit hilft es hier aber etwas "Datenanalyse" gegen die Direct Routing Gegenstellen zu machen.
Ob Microsoft in Europa wirklich "nur" 26 Server stehen hat, kann ich nicht zuverlässig sagen. Das ist mit der Auswertung der Teams Transport Relay zu vergleichen. Es könnt aber schon sein, dass in Europa viel mehr Kunden ihre eigene SIP-Verbindung mitbringen und in den USA vielleicht Operator-Connector oder Microsoft Dialpläne häufiger genutzt werden und daher weniger SIPProxy-Systeme laufen.
Es ist nur eine Momentaufnahme und könnte durch Zoning etc. verfälscht sein. Vielleicht erreiche ich per DNS nur eine Teilmenge der Server, die optimal zu meiner Internet-Anbindung passen.
Versionsnummern
Die zweite Information in der "User-Agent"-Zeile liefert ein paar Details zur Version. Dazu habe ich das Skript kurz angepasst, um die 60 Tage zu erfassen. Die Versionsnummer scheint auch nach dem Format "v.YYYY.MM.TT.xx" zu folgen.
$hashtable = @{}
Select-String `
-Path syslog*.* `
-Pattern "USER-AGENT: Microsoft.PSTNHub.SIPProxy "`
| %{ $hashtable[($_.tostring().split(" ")[2])]+=1 }
$hashtable.GetEnumerator() | sort -Property name
Name Value
---- -----
v.2021.11.2.11 42829
v.2021.11.22.3 42731
v.2021.12.1.4 173534
v.2022.1.10.7 11495
v.2022.1.3.2 36107
In den ca. 60 Tagen habe ich fünf verschiedene Versionen gesehen. Wenn ich nun mal vereinfache, dann dürfte die Version vom 1. Dezember 2021 bis ca. 3. Jan 2022 im Betrieb gewesen sein. Ich sehe hier natürlich keinen "Rolloutplan". Das wäre natürlich auch interessant, wann und wo eine neue Version das erste mal erscheint und wann eine vorherige Version das letzte mal erkannt wird. Dann wäre eine große Abschätzung erkennbar, wie lange Microsoft für einen "Rollout" braucht.
