Test-CSFederationPartner

Ein sehr nettes Commandlet im Skype for Business Umfeld ist Test-CSFederationPartner zur Verifikation der SIP-Verbindung nach extern. Über Federation werden nicht nur Status und Messages übertragen sondern auch per INVITE Verbindungen zu anderen Skype for Business Benutzern und Meetings aufgebaut. Diese Seite beschreibt Aufruf, Funktionsweise und übliche Fehlermeldungen.

Aufruf

Zum Aufruf des Commandlets hat Microsoft auf verschiedenen Seiten dokumentiert.

Wichtig sind drei Parameter:

  • TargetFqdn
    Die ist der FQDN-Hostname des eigenen lokalen Edge-Servers, der als "Relay" genutzt wird. Das Commandlet baut eine TLS-Verbindung auf Port 5061 auf um darüber dann einen OPTIONS-Request abzusetzen
  • Domain
    Hier geben Sie die SIP-Domäne der zu prüfenden Gegenstelle ein.
  • ProxyFqdn
    Optional können Sie hier den FQDN des SIP-Access Edge der Gegenseite eingeben. Ohne die Angabe macht der Edge Server dann eine DNS-Abfrage nach "_sipfederationtls._tcp.<domain>

Der Aufruf kann auf jedem System erfolgen, auf dem die Skype for Business PowerShell installiert wurde. Als Rückgabe kommt ein Objekt mit den angezeigten Properties

   TypeName: Microsoft.Rtc.SyntheticTransactions.TaskOutput

Name           MemberType Definition
----           ---------- ----------
Equals         Method     bool Equals(System.Object obj)
GetHashCode    Method     int GetHashCode()
GetType        Method     type GetType()
ToString       Method     string ToString()
Diagnosis      Property   string Diagnosis {get;}
Error          Property   string Error {get;}
Latency        Property   timespan Latency {get;}
Result         Property   Microsoft.Rtc.SyntheticTransactions.ResultStatus R...
TargetFqdn     Property   string TargetFqdn {get;}
WorkflowLogger Property   Microsoft.Rtc.SyntheticTransactions.Logging.Synthe...

Das Feld "Diagnostics" enthält weitere Details und ist ein String, den Sie mit ".split(",")" aufteilen können

Diese Test funktioniert natürlich nur, wenn Sie einen Edge-Server installiert haben, der von dem ausführenden Client von intern über per 5061 erreichbar ist und Federation generell auch erlaubt ist.

Erster Basistest

Die Federation zu Office 365 ist immer eine dankbare Gegenstelle für erste Tests:

PS C:\> Test-CsFederatedPartner -TargetFqdn edge.msxfaq.net -Domain push.lync.com -ProxyFqdn sipfed.online.lync.com

Target Fqdn : edge.msxfaq.net
Result : Success
Latency : 00:00:00
Error Message :
Diagnosis :

Da dieser Weg auch für mobile Clients (IOS, Windows Phone) genutzt wird ist er bei korrekter Konfiguration eigentlich immer erreichbar.

Massentests

Da Test-CSFederationPartner natürlich ein Powershell-Script ist, können Sie damit sehr einfach ihre eingetragenen Federation-Partner regelmäßig überprüfen lassen. Hier ein Beispiel, welches die manuell gepflegte Liste mit "GET-CSAllowedDomain" ausliest und per Pipeline an Test-CSFederationPartner übergibt und dann nach den verschiedenen Fehlercodes gruppiert.

Get-CsAllowedDomain `
   | ForEach-Object {`
        Test-CsFederatedPartner `
           -TargetFqdn "edge.msxfaq.net" `
           -Domain $_.Identity`
    } `
   | group "Error"

Natürlich können Sie genauso einfach eine Textdatei als "Input" verwenden und die Ausgaben in ihr Monitoring-System überführen.

Fehlerfälle

Test-CSFederationPartner ist auch mein erstes Tool, um Probleme mit der Federation zu verifizieren. ich erspare mir dabei häufiger schon den Umgang mit OCSLogger, CLSLogger , Snooper und Eventlog. Exemplarisch habe ich ein paar Fehlerfälle dokumentiert, da sie sehr einfach schon einen Hinweis auf das Problem geben:

Fehlerfall Diagnosis-Meldung

Nicht existierende Domain

Wenn Sie als "Domain" eine SIP-Domäne angeben, die es nicht mehr gibt., dann sehen Sie folgenden Fehler.

 
Target Fqdn   :
Result        : Failure
Latency       : 00:00:00
Error Message : 404, Not Found

Diagnosis     : ErrorCode=1008,
                Source=sip.msxfaq.net,
                Reason=Unable to resolve DNS SRV record,
                domain=example.com,
                dns-source=WireQuery,
                dns-srv-result=NegativeResult
                Microsoft.Rtc.Signaling.DiagnosticHeader

Prüfen Sie per NSLOOKUP auf dem Edge Server auf _sipfederationtls._tcp.<sip-domain> die entfernte Domäne

Wildcard auf Access Edge

Der Einsatz von Wildcard-Zertifikaten auf dem Edge-Server ist problematisch, da z.B. die Microsoft Server sehr wohl prüfen, welcher Name im Zertifikat steht und ob dieser mit dem Federation-Eintrag übereinstimmt. Wer also z.B.: ein "CN=*-<domain>"-Zertifikat auf dem Access-Edge installiert hat, wird z.B. Probleme mit der Push-Benachrichtigung auf IOS und Windows Phone bekommen.

Der Fehler enthält auch den Namen des Source Servers bei Microsoft und die Information, dass dieser eben keine korrekte Routinginformation für den Rückweg kennt.

 
Target Fqdn   :
Result        : Failure
Latency       : 00:00:00
Error Message : 504, Server time-out

Diagnosis     : ErrorCode=2,
                Source=sipfed2E.online.lync.com,
                Reason=Serverresponse code and reason phrase,
                hresult=0xC3E93D8F(SIPPROXY_E_EPROUTING_INVALID_EDGE_ROUTE_DESTINATION)
                Microsoft.Rtc.Signaling.DiagnosticHeader

Die Korrektur durch Tausch des Zertifikats kann wohl bis zu 24h dauern, da die Edge-Server von Office 365 einen Cache haben.

Geblockte Domain

Der Skype for Business Admin kann mit "Add-CSBlockedDomain" bestimmte SIP-Domänen verbieten. Das kann in Umgebungen genutzt werden, die per Default mit "Open Federatoin" arbeiten.

 
Target Fqdn   :
Result        : Failure
Latency       : 00:00:00
Error Message : 504, Server time-out


Diagnosis     : ErrorCode=1064,Source=sip.msxfaq.net,Reason=Cannot route to
                blocked domain,domain=carius.de,suffix=carius.de
                Microsoft.Rtc.Signaling.DiagnosticHeader

Wenn die Kommunikation mit der SIP-Domäne erforderlich ist, dann müssen Sie diese aus der Liste der "Blocked Domains" entfernen.

Federation auf sich selbst

Auch wenn ich es hier als "letzten Punkt" aufführe, habe ich diesen Test natürlich zuerst gemacht. Ich habe geschaut, ob ich mich selbst fragen kann. Da hat mein Edge aber dann doch verhindert.

Insofern ist dies kein valider Test, wenn man keine Gegenstelle kennt. Nutzen Sie einfach Office 365 als Prüfpunkt.

 
PS C:\> Test-CsFederatedPartner -TargetFqdn edge.msxfaq.net -Domain msxfaq.net

Target Fqdn   :
Result        : Failure
Latency       : 00:00:00
Error Message : 404, Not Found

Diagnosis     : ErrorCode=1003,Source=sip.msxfaq.net,Reason=User does not
                exist,destination=Options_User@msxfaq.net
                Microsoft.Rtc.Signaling.DiagnosticHeader

Diese Abfrage kann aus Prinzip nicht gehen.

Funktionsweise

Den Test mit der Office 365 Push-Services habe ich genutzt, um per CLSLogging und Snooper auf dem Edge-Server die SIP-Pakete genauer zu inspizieren. Hier sieht man unverschlüsselt dann die Pakete und erkennt, was der "Test-CSFederationPartner" im Hintergrund macht:

Links ist der interne Client, der per TLS sich mit dem angegeben "Target-FQDN" verbindet und den Options-Request einstellt. Der Edge leitet das Paket nach extern weiter und die Antwort geht über die gleichen Stationen zurück:

Im Detail sieht das dann so aus:

Beschreibung SIP-Daten

Der interne Client sendet einen OPTIONS an die interne Edge des IP

 

Direction: incoming;source="internal edge";destination="external edge"
Peer: sfb01.msxfaq.net:52080
Message-Type: request
Start-Line: OPTIONS sip:Options_User@push.lync.com SIP/2.0
FROM: <sip:Options_User@msxfaq.net>;epid=xxxx;tag=xxxx
TO: <sip:Options_User@push.lync.com>
CALL-ID: x
CSEQ: 1 OPTIONS
CONTACT: <sip:sfb01.msxfaq.net;transport=Tls>
VIA: SIP/2.0/TLS 192.168.100.102:52080;branch=xxxx
ROUTE: <sip:sipfed.online.lync.com;transport=tls;lr>;ms-edge-route
MAX-FORWARDS: 70
CONTENT-LENGTH: 0 User-AGENT: RTCC/6.0.0.0

Der Edge-Server addiert ein paar Header und sendet die Anfrage nach extern

 

Direction: outgoing;source="internal edge";destination="external edge"
Peer: sipfed.online.lync.com:5061
Message-Type: request
Start-Line: OPTIONS sip:Options_User@push.lync.com SIP/2.0
FROM: <sip:Options_User@msxfaq.net>;epid=xxxx;tag=xxxx
TO: <sip:Options_User@push.lync.com>
CALL-ID: xxx
CSEQ: 1 OPTIONS
CONTACT: <sip:sfb01.msxfaq.net;transport=Tls>
Via: SIP/2.0/TLS 192.168.66.22:53396;branch=xx.xx;branched=FALSE;ms-internal-info="xxxx"
Via: SIP/2.0/TLS 192.168.100.102:52080;branch=xx;ms-received-port=52080;ms-received-cid=278D0F00
ROUTE: <sip:sipfed.online.lync.com;transport=tls;lr>
Record-Route: <sip:sip.msxfaq.net:5061;transport=tls;lr;ms-key-info=xxxx;ms-route-sig=xxxx>;tag=xx
Max-Forwards: 69
CONTENT-LENGTH: 0 User-AGENT: RTCC/6.0.0.0
ms-asserted-verification-level: ms-source-verified-User=verified

Die Antwort von Microsoft liefert

 

Direction: incoming;source="external edge";destination="internal edge"
Peer: sipfed.online.lync.com:5061
Message-Type: response
Start-Line: SIP/2.0 200 OK
FROM: <sip:Options_User@msxfaq.net>;epid=xxxx;tag=xxxx
To: <sip:Options_User@push.lync.com>;tag=xxxx
CALL-ID: xxx
CSEQ: 1 OPTIONS
Via: SIP/2.0/TLS 192.168.66.22:53396;branch=xxxx;branched=FALSE;ms-internal-info="xxxx";
   received=52.112.131.126;ms-received-port=53396;ms-received-cid=363A2900
Via: SIP/2.0/TLS 192.168.100.102:52080;branch=xxxx;ms-received-port=52080;ms-received-cid=278D0F00
Record-Route: <sip:sip.msxfaq.net:5061;transport=tls;lr;ms-key-info=xxxx;ms-route-sig=xxxx>;tag=xxxx
Content-Length: 0

Der Edge leitet das Paket wieder an den Client weiter.

 

Direction: outgoing;source="external edge";destination="internal edge"
Peer: sfb01.msxfaq.net:52080
Message-Type: response
Start-Line: SIP/2.0 200 OK
FROM: <sip:Options_User@msxfaq.net>;epid=xxxx;tag=xxxx
To: <sip:Options_User@push.lync.com>;tag=xxxx
CALL-ID: xxx
CSEQ: 1 OPTIONS
Via: SIP/2.0/TLS 192.168.100.102:52080;branch=xxxx;ms-received-port=52080;ms-received-cid=278D0F00
Content-Length: 0
ms-edge-proxy-message-trust: ms-source-type=AuthorizedServer;ms-ep-fqdn=edge.msxfaq.net;
   ms-source-verified-User=unverified;ms-source-network=federation;ms-local-fcp=yes

Ein direkter Kontakt mit dem User "Options_User@push.lync.com" ist nicht möglich. Er hat keine Präsenz und nimmt auch keine Messages an:

Schon der SUBSCRIBE wird mit einem "404 not found" quittiert. Der INVITE ebenso.

SIP/2.0 404 Not Found
From: "Carius, Frank"<sip:frank.carius@msxfaq.net>;tag=ed02c96064;epid=2385f4c267
To: <sip:options_User@msxfaq.net>;tag=xxxx
Call-ID: xxxxxxxx
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 192.168.103.61:53845;ms-received-port=53845;ms-received-cid=xxxx
ms-diagnostics: 1003;reason="User does not exist";destination="options_User@msxfaq.net";source="sip.msxfaq.net"
Server: RTC/6.0

Diese spezielle SIP-Adresse dürfte in Verbindung mit dem OPTIONS-Request fest hinterlegt sein.

Weitere Links