Media Relay Authentication Service (MRAS) und Edge

Ich habe lange überlegt, wie ich diese Seite "benennen" soll, denn MRAS ist nur eine Komponente beim Verbindungsaufbau von Lync. diese Informationen sind eng verwandt mit Lync Provisioning, Early Media, MediaBypass und natürlich SIP im Detail. Letztlich geht es hier um die Vorarbeiten, ehe ein SIP-Client mit dem anderen SIP-Client Daten austauschen kann. Und das erfolgt in mehreren Stufen: 

  1. Anmeldung und Konfigurationsdaten (u.a. MRAS Token) erhalten
  2. Candidates ermitteln (auch mit MRAS an den Edge)
  3. Candidates an die Gegenseite senden
    Wenn der Client nun seine Liste der Endpunkte zusammen hat, unter denen er erreichbar ist, kann er auf den INVITE des Anrufers antworten oder selbst einen INVITE starten und auf die Antwort der Gegenseite warten.
  4. Gültige Candidate-Paare ermitteln
    Wenn beide Partner ihre Candidates ausgetauscht haben. fangen Sie umgehend an die möglichen Kommunikationspaare zu proben und die beste Verbindung je Richtung zu ermitteln.
  5. Verbindung herstellen
    Wird das Gespräch angenommen, dann senden die Partner ihre ausgewählten Candidates zu, so dass die Audioübertragung starten kann.

Schauen wir uns die Einzelschritte etwas genauer an.

Anmeldung

Auf die einzelnen Details einer Anmeldung möchte ich hier nicht eingehen. Der Client nutzt SIP über den Frontend oder Edge, die er per DNS findet und meldet sich mit Anmeldedaten an. Sie wissen sicher, dass Lync vom Server ein Zertifikat bekommt und auch die LyncWeb-Dienste mit "WebTickets" arbeiten.

Wichtiger ist aber, dass der Client mit der Anmeldung eine sehr umfangreiche XML-Struktur vom Server bekommt., in der u.a. die Kontakte enthalten sind. Wichtiger ist hier aber, dass der Server dem Client auch Konfigurationseinstellungen (Polices) übermittelt. Eine Information darin ist der Edge-Server Pool, der dem Frontend-Server zugeordnet ist.

In der 200OK Antwort des Servers, die er auf den "SUBSCRIBE" des Clients sendet, steht unter anderem die MRAS-URI drin. Wenn Sie keinen Edge-Server haben, dann ist das Feld leer.

MRAS-Token im Snooper

Damit der Client später über den Edge kommunizieren kann, erwartet der Edge-Server eine "Authentifizierung". Nun ist es ja so, dass der Edge in der Regel in einer DMZ steht, nicht Mitglied des Active Directory ist und damit direkte Anmeldungen des Clients am Edge mit Benutzername/Kennwort, Zertifikat o.ä. gar nicht möglich ist. Daher fordert der Client ein Token über seinen Frontend-Server an. Der Frontend kann den Anwender ja identifizieren und dann die Anfrage zum Edge-Server weiterreichen. Die Verbindung zwischen Frontend und Edge ist wiederum über Computerzertifikate gesichert. Der Edge "vertraut" darauf, dass der Frontend den Endanwender korrekt authentifiziert hat und erstellt mittels dem AV-Edge-Zertifikat ein Token. Ein Client ist nicht nur ein Lync Communicator. Auch der Mediation Server, Exchange UM, UCMA und andere Clients, die über den Edge eine Kommunikation anfordern, können den Edge fragen. Sofern auf diesen Clients ein Lync-Stack aktiv ist, können Sie in der Regel mit Snooper hier auch ein gesondertes Logging einschalten.

Hier z.B.: der "Start" des Mediation Servers als "Client". Der Client sendet dazu einen SIP SERVICE-Request über den Frontend an den zugeordneten Edge-Server. Über den Suchfilter "MRAS" sollte direkt die Ticketabfrage zu sehen sein.

Paket 1 ist der Versand des Mediation Servers, welches hier als Paket 2 durch den Frontend Server empfangen wird. Erst Paket 3 ist auf dem Weg vom Frontend zum Edge Server:5062

Hier die SIP-Anfrage als XML-Struktur mit dem Content-Type "application/msrtc-media-relay-auth+xml"

Das Paket 4 und Interessant ist hier das dritte Paket, welches vom Edge dann über den Frontend wieder zum Client zurück kommt:

Interessant ist hier die der DNS-Name und die Ports, die als "MediaRelay" ausgeliefert werden. Es wird ein "Username" und "Kennwort" entsprechend BASE64 codiert übermittelt, die aber nur 480 Minuten (=8 Stunden) gültig sind und zudem keinem echten Konto entsprechend. Der Edge "merkt" sich diese ausgegebenen Daten temporär.

Anrufen und angerufen werden mit "Kandidaten"

Auf den Seiten Early Media und MediaBypass habe ich schon beschrieben, wie die verschiedenen SIP-Messsages eine Ruf einleiten, so dass ich hier nicht die unterschiedlichen Optionen auffächern möchte, sondern mich auf die Vorarbeiten zum Call beschränke.

Bei einem ausgehenden Call muss der Client mit dem INVITE auch seine" Candidates" mit senden, über die er erreichbar ist. Diese Liste enthält also Angaben über die Nutzlast (Audio, Video, Sharing etc.), die verwendeten Codecs und die IP-Endpunkte bestehend aus IP-Adressen, Ports und zusätzlichen Angaben zur Absicherung und Relay-Stationen. Hier ein Ausschnitt eines SIP-Pakets, welches einen SDP (Session Description Protocol) enthält.

Sie erkennen hier, dass die 192.16.100.100 meine direkt per UDP intern erreichbare IP-Adresse ist und der Lync-Client die Port 51398 (Für Audiodaten, RTP ) und 51399 (für die Steuerung RTCP) geöffnet hat. Das ist für den Client ja noch einfach, da er einfach seine lokalen Netzwerkkarten ablaufen muss. Allerdings funktioniert dieser Candidate nur, wenn der andere Kommunikationspartner im gleichen gerouteten Netzwerk ist und nicht Firewalls etc. die Verbindung stören. In der Regel also intern zu einem Gateway (bei MediaBypass), zum Lync Mediation Server oder zum Lync AV-MCU bei Konferenzen. für alle anderen Fälle muss der Client einen Weg finden, weitere Candidates zu ermitteln. Und hier kommt der Edge ins Spiel.

Edge und Clients mit TURN

Der Client versucht über den Edge-Server, der ihm bei der Anmeldung schon zugewiesen wurde, weitere Candidates zu ermitteln. Dazu sendet der Client mehrere Pakete an den EDGE-Server, um zum einen zu erfahren, mit welcher IP-Adresse der Edge den Client ankommen sieht (z.B. wenn der Client am heimischen DSL-Router hinter NAT verborgen ist.

Zudem sendet er auch Reservierungsanfragen, damit der Edge ihm ein paar Ports "leiht", über den Weg der Edge als Relay die Daten an den Client über einen dann bestehende Verbindung (vom Client zum Edge initiiert) senden kann.

Dass die ersten Anfragen mit einem ERROR quittiert werden ist normal, da der Client, wie so oft, erst mal anonym den Edge anspricht um dann anhand der Fehlermeldung zu wissen, wie er sich anmelden kann

Nach den fehlerhaften Paketen kommt dann endlich ein korrekt formatierter Request:

Diesen kann der Edge dann auch beantworten.

Zu der fraglichen Zeit habe ich also von meinem Edge die IP-Adresse und Port-Kombination "80.66.20.21:58969" auf Zeit geliehen bekommen. Wer genau hinschaut erkennt noch eine "XORMappedAddress". Dies ist die gleiche IP-Adresse, nur per XOR "verschlüsselt". Es gibt nämlich Firewalls und Proxies, die auch in den Inhalt von Paketen schauen und Daten ersetzen. Solche einfachen Firewalls erkennen dann diese XOR-Adresse nicht und wenn die MappedAddress verändert wird, dann fällt dies dem Client auf und er nutze diese nicht.

Austausch der Candidates und Probing der Verbindung

So bekommt jeder Client von "seinem Edge" dann die weiteren Kandidaten um sie dann beim initialen INVITE oder bei der Antwort auf einen INVITE auszutauschen. Entsprechend können dann die Clients starten, in jede Richtung die Kommunikationskanäle zu proben um eine mögliche Verbindung zu erhalten.

Der jeweils „beste“ gefundene Kandidat wird dann beim 200 OK bestätigt und genutzt. Auch dieses "Probing" können Sie mit NETMON nachverfolgen. Dies ist aber schon mühsamer und auch die Analyse der OCS Client-Logs ist nur bedingt zu gebrauchen. Sie können ja mal nach "MR-INFO" suchen.

Interessant sind hier natürlich "Error"-Meldungen oder Hinweise auf fehlerhafte Namensauflösung etc.

MRAS in CSCP

Im Lync Control Panel können Sie übrigens an mehreren Stellen die MRAS-Konfiguration sehen: über "Topologie" - "Status" bei den einzelnen Servern sehen.

  • Edge Server
    Hier ist die "EdgeServer"-Rolle interessant, auf der Sie z.B.: den Port 5062 erkennen sollten.
  • Mediation Rolle (Meist auf dem Frontend
    Hier ist z.B. auch der EDGE-Server sichtbar, bzw. sollte es sein. Ansonsten beschwert sich der Mediation Server im Eventlog mit dem Fehler "25026 A/V authentication service is not selected für Mediation Server. Connections that require firewall traversal may not be successfull"
  • Conferencing Rolle (Auf dem Frontend oder separaten AV-Servern)
    Auch die Audio/Video-MCU muss natürlich wissen, wie externe Clients und Federation Partner erreicht werden können.

Sie sehen aber, dass hier bei der "interne Name" zum Tragen kommt. Der MRAS-Dienst ist nicht von extern erreichbar.

MRAS und Exchange UM

Die "Voicemail" von Exchange wird in den meisten Fällen nur "intern" genutzt, d.h. das Gateway zur TK-Anlage verbindet sich in der gleichen AD-Site direkt mit dem UM-Server. Auch eine Einwahl per Telefon bleibt meist "intern". Erweiterte Medienwege über NAT oder EDGE sind kaum der Fall. Wenn aber mehr und mehr Mitarbeiter "unterwegs" sind oder "zuhause" arbeiten, dann kann es sehr wohl sein, dass der Edge Server und MRAS für Exchange UM relevant werden.

Die meisten Einstellungen erledigt schon das Skript ExchUCUtil.ps1 aber die Pflege des AVEdge Servers fehlt. Diese Information ist aber wichtig. SCOM überwacht die passenden Events dazu. (1438/1439/1440)

Log Name:      Application
Source:        MSExchange Unified Messaging
Event ID:      1438
Task Category: UMCore
Level:         Warning
Keywords:      Classic
Description:
The UM server has been configured to automatically use the Communications Server 
Audio/Video Edge resources associated with 'nawlync001.netatwork.de:5061'. Inbound 
and outbound calls involving remote users (located outside the enterprise) might 
be failing using the current Communications Server Audio/Video Edge resources. 
To correct the issue, set the SIPAccessService property using the Set-UMServer 
cmdlet. The Microsoft Exchange Unified Messaging  service will start using the 
Communications Server Audio/Video Edge resources corresponding to the new value.

Den Event kann man recht einfach lösen, indem auf dem ExchangeUM-Server der Edge-Server eingepflegt wird. Zuerst die Konfiguration vor der Änderung

Get-UmServer | fl name,sip*

Name                : NAWEX001
SipTcpListeningPort : 5060
SipTlsListeningPort : 5061
SIPAccessService    :
Set-UmServer nawex001 `
    -SIPAccessService nawlyncedge.netatwork.de:5062
Restart-Service msexchangeum

Eine Kontrolle im Eventlog zeigt dann, dass die Warnung nicht mehr erscheint. Statt dessen sollen Sie eine Bestätigungsmeldung sehen

Log Name:      Application
Source:        MSExchange Unified Messaging
Event ID:      1441
Task Category: UMCore
Level:         Information
Keywords:      Classic
Description:
The Microsoft Exchange Unified Messaging service will attempt to use the Communications 
Server Audio/Video Edge resources associated with : 'nawlyncedge.netatwork.de:5062'.

Parameter: SIPAccessService
The SIPAccessService parameter specifies the FQDN and Transmission Control Protocol (TCP) port of Office Communications Server A/V Edge servers used für inbound or outbound calls from remote users located outside the network.
Quelle: Set-UMServer http://technet.microsoft.com/en-us/library/aa996327.aspx

Weitere Links

SIP Signaling, Negotiation and Media Flows in Skype für Business, Explained
https://channel9.msdn.com/events/Ignite/2015/BRK4102
Sehr schöner Vortrag zu SIP und SDP