SIP-Wege

SIP funktioniert wie SMTP. Ein Client sendet seine Daten direkt oder über einen SIP-Proxy zum Registrar, der die dann über Proxies zum Zielregistrar sendet so dass der Empfänger die Information bekommen kann. Bei der Einrichtung von Skype for Business Hybrid, d.h. Online und On-Prem mit der gleichen DNS-Domäne können die Wege schon etwas verschlungener sein. Diese Seite beschreibt, welche Wege SIP bei Skype for Business in den verschiedenen Welten geht.

Übersicht

Das folgende Bild wird sie erst einmal erschrecken, denn es enthält doch sehr viele Komponenten. Ich habe versucht die Komponenten so zu benennen, dass Sie später im Text dann doch sehr einfach wieder zu erkennen sind. Sie sehen zuerst einmal dir vier großen Blöcke in drei Farben:

  • Grüne = Zwei Blöcke als Firmen
    Dies soll zwei Firmen darstellen, die jeder eine On-Prem Installation mit Skype for Business hat. Die Umgebung ist mit Office 365 per "Hybrid" verbunden. Die Pfeile zeigen schon auf dass die entsprechenden DNS-Einträge auf die On-Prem Umgebung verweisen.
  • Rot = Internet
    Im Internet stehen keine Server aber es gibt je zwei Clients pro Firma, die entsprechend ihrer Farbe auf den Servern gehostet sind
  • Blau = Cloud
    Office 365 stellt ebenfalls Services in Form von Edge Servern und Frontend Servern für die beiden Firmen bereit.

Die Server selbst sind entsprechende nach dem Standort nummeriert. Auch die Anwender sind eindeutig gekennzeichnet

  • A-Benutzer sind On-Prem der jeweiligen Firma gehostet
    • A1i = Anwender A der Firma 1 im Internen LAN
    • A1e = Anwender Ader Firma 1 von extern (Internet)
    • A2i = Anwender A der Firma 2 im Internen LAN
    • A2e = Anwender A der Firma 2 von extern (Internet)
  • B-Benutzer haben ihren HomeServer in in Office 365
    • B1i = Anwender A der Firma 1 im Internen LAN
    • B1e = Anwender A der Firma 1 von extern (Internet)
    • B2i = Anwender A der Firma 2 im Internen LAN
    • B2e = Anwender Ader Firma 2 von extern (Internet)

Ich werde nun nicht alle Permutationen einzeln durchspielen, sondern mich auf eine Auswahl beschränken, die ihnen aber die Funktion deutlich macht und sie die nicht beschriebenen Fälle selbst herleiten können. Die Bezeichnung ist als Template zu lesen, welches durchaus mehrfach genutzt werden kann. Wenn ich später z.B. "A1i -> R1 -> R1 ->A1i" schreibt, dann ist das wie folgt zu lesen

  • A1i -> R1
    Ein Benutzer der Firma 1 auf dem On-Prem Server sendet ein Paket an seinen Registrar, der On-Prem steht
  • R1 -> R1
    Ein On-Prem Registrar sendet das Paket zu einem anderen On-Prem Registrar
  • R1 -A1i
    Ein On-Prem Registrar stellt das Paket zu einem On-Prem Anwender im internen LAN der Firma 1 zu. Dieser A1i ist aber ein andere Benutzer als der A1i am Anfang.

Das mag etwas verwirrend sein, aber ich wollte nicht noch jeden User doppelt anlegen und damit mit sechzehn Benutzerobjekten jonglieren.

Grundprinzip

Beachten Sie dabei immer die Grundregel, dass ein Client immer mit seinem "HomeServer" spricht, auf dem er angelegt ist. Das kann direkt oder über einen Edge Server sein und beim Verbindungsaufbau werden insbesondere die Office 365 Benutzer dennoch zuerst den Weg zur "On-Prem"-Umgebung suchen und hoffentlich finden. Sie bekommen dann aber von dem On-Prem-Server den Hinweise, dass Sie auf einem anderen Server angelegt sind und sie sich dorthin wenden sollen.

Zudem werde ich immer den Weg vom "Sender" zum Empfänger" beschreiben. Bei SIP ist es üblich, im Header den Weg von A nach B mit zu übergeben und die Antwort auf dem gleichen Weg wieder zurück zu senden. ein Dialog bleibt also immer auf dem aufgebauten Kommunikationskanal.

Wenn Sie im UCCAPI-Log eines Clients schauen, dann sehen sie bei allen empfangenen Messages den Laufweg anhand des "Via:"-Headers.

Via: SIP/2.0/TLS 192.168.77.21:50480;branch=z9hG4bK9C47551D.5DA62F176855C34C;branched=FALSE;ms-received-port=50480;ms-received-cid=8F71D00
Via: SIP/2.0/TLS 52.112.0.33:36199;branch=z9hG4bK87561EEF.B9F21FCD99C4634C;branched=FALSE;ms-received-port=36199;ms-received-cid=C676C00
Via: SIP/2.0/TLS 10.5.16.49:50713;branch=z9hG4bKA4DDC881.B787D954576D034C;branched=FALSE;ms-received-port=50713;ms-received-cid=CA0BA800
Via: SIP/2.0/TLS 10.5.16.109:30156;branch=z9hG4bK6B0A7C78.A17B62FA823CF34C;branched=FALSE;ms-received-port=30156;ms-received-cid=22D33D00
Via: SIP/2.0/TLS 10.5.16.113:39643;branch=z9hG4bK6A3102EA.CC5539AC2E64D34C;branched=FALSE;ms-received-port=39643;ms-received-cid=1B72900
Via: SIP/2.0/TLS 192.168.178.61:52486;received=10.5.17.254;ms-received-port=52486;ms-received-cid=2989C00

Sie sehen hier aber auch, dass anstelle von FQDNs hier reale IP-Adressen erscheinen. Es sind aber nur die Proxy-Server sichtbar. Dieses Beispiel ist ein Paket eines Office 365 Benutzers eines Tenant in den USA an einen On-Prem Benutzers in Deutschland einer Hybrid-Konfiguration, der Extern" ist. Sie sehen immer die IP-Adresse, von dem das Paket versendet wurde und an welches das Rückpaket weiter geleitet wird. jeder Proxy führt eine Session-Table mit, anhand der er gültige aktive Verbindungen und entsprechenden SIP-Messages zuordnen kann. Von unten nach oben gelesen gibt dies:

  • 192.168.178.61
    Das ist die IP-Adresse des Clients, welcher das Paket gesendet hat.
  • 10.5.16.113
    Das ist die IP-Adresse des Edge Servers, mit dem der Client verbunden war und mit der er das Paket intern weiter gibt
  • 10.5.16.109
    Ich vermute, dass dies der erste Frontend ist, an den der Edge Server das Paket weiter gegeben hat. Auf dem Server ist aber kein Anwender, so dass er das Paket weiter gibt
  • 10.5.16.49
    Das dürfte die IP-Adresse eine weiteren Registars sein, der ausgehend die Federation über einen anderen Edge aufbaut
  • 52.112.0.33
    Die Public IP des Edge in Office 365, der die Verbindung zum On-Prem Edge aufgebaut hat. Wenn Sie sich das Zertifikat hinter der IP-Adresse anschauen, dann steht im CN = sipfed.online.lync.com
  • 192.168.77.21
    Die interne IP-Adresse des Edge Servers "On-Prem"

In dem Weg sind also nicht alle Stationen sichtbar. Mein Empfänger ist extern und über den Edge mit dem On-Prem Frontend verbunden. Dieser Pfad ist hier nicht sichtbar. Mein Client muss die Antwort einfach an die Adresse 192.168.77.21 senden und das macht er sowieso immer über seinen "HomeServer". Anders wäre diese private Adresse auch gar nicht erreichbar.

Bei eingehenden Paketen , auf die ein SIP-Client antwortet, sind es die "route"-Header, damit das Paket den gleichen Weg zurück nimmt:

Route: <sip:sippoolAM30E08.infra.lync.com:443;transport=tls;ms-fe=AM30E08FES03.infra.lync.com;opaque=state:F:Ci.x;lr;ms-route-sig=gdF-x-x>;ms-rrsig=gdRrFAY4guhiIJU-x;tag=x
Route: <sip:sipedgeAM30E.infra.lync.com:5061;transport=tls;opaque=state:Sfo;lr>;tag=x
Route: <sip:sip.uclabor.de:5061;transport=tls;lr;ms-key-info=x-x-M_pht-x-x-x-x-UqCfTjPr3c5FwtgdY5m-2_YLXiVbsX6T-x-x-x-x-x-x-x-x-x-x-x-x-x-x;ms-route-sig=x>;ms-rrsig=x;tag=x
Route: <sip:SfBstd01.uclabor.de:5061;transport=tls;lr>;tag=x
Route: <sip:sfbedge01.uclabor.de:5061;transport=tls;lr>;tag=x
Route: <sip:sip.msxfaq.de:5061;transport=tls;epid=2385f4c267;lr;ms-key-info=x-xxx-T-xx-Z0--x-x-x-USx;ms-route-sig=brFK-x>;ms-rrsig=x;tag=x
Route: <sip:sfb01.msxfaq.de:5061;transport=tls;opaque=state:T;lr>;tag=x

Als Vorgeschmack auf die Beschreibung der Stationen weiter unten sieht dies so aus:

Der Anwender B1e  (Anwende aus Firma 1, der extern arbeitet und in Office 365 gehostet ist) sendet über den Office 365 Edge das Paket an die Cloud die das intern über zwei Server zum ausgehende Edge routet, der die Daten zum E1 (On-Prem Edge) weiter gibt. Von dort geht es über den Frontend des Anwender (R1) und den Edge E1 zum Anwender. Der Weg vom R1 zum Zielanwender ist aber keine aktive SIP-Verbindung, sondern nur eine Antwort innerhalb einer bestehenden Verbindung.

Anmeldung

Zur Einstimmung möchte ich die Stationen beschreiben, die bei der Anmeldung eines Clients am Registrar durchlaufen werden. Erst wenn dann die Sender und Empfänger letztlich an ihrem HomeServer angemeldet sind, können wir dann weitere Anfragen beschreiben. Ich halte den Abschnitt kurz. Eine genaue Beschreibung der eigentlichen Anmeldung mit WebTickets etc. finden Sie auf Lync Client Discover, SIP Logon, und LLync Client Zertifikate.

Szenario/th> Beschreibung

Anmeldung A1i

Der interne Client meldet sich am Server in der Firma an. Der Weg ist wohl bekannt

  • Suche per Lyncdiscoverinternal.<sipdomain> oder _sipinternaltls._tcp.<sipdomain> führt zum lokalen Server
  • TLS-Verbindung mit dem lokalen Skype for Business Server

Anmeldung A1e

Der externe Client meldet sich am Server in der Firma an. Auch dies sollte bekannt sein

  • Suche per Lyncdiscoverinternal.<sipdomain> oder _sipinternaltls._tcp.<sipdomain> führt ins Leere
  • Suche per Lyncdiscover.<sipdomain> oder _sip._tcp.<sipdomain> verweist den Client auf die Webdienste bzw. den Edge E1
  • TLS-Verbindung mit Edge Server als Proxy zum lokalen Skype for Business Server

Anmeldung B1i

Der interne Client meldet sich am Server in Office 365 an. Beim Skype for Business Hybrid Mode muss der lokale Server etwas mithelfen, da die DNS-Einträge nicht direkt in die Cloud verweisen.

  • Suche per Lyncdiscoverinternal.<sipdomain> oder _sipinternaltls._tcp.<sipdomain> führt zum lokalen Server
  • Der lokale Server weiß aber, dass der User "hosted" ist und sendet ihm einen Redirect auf onmicrosoft.com
  • TLS-Verbindung mit dem Skype for Business Server in Office 365 Edge Server als Proxy zum Frontend in der Cloud

Der lokale Edge Server und Frontend Server wird von diesem Client in der Folge nicht weiter genutzt. Auch die STUN/TURN-Dienste des lokalen Edge Servers interessieren den Client nicht

Anmeldung B1e

Der externe Client meldet sich am Server in Office 365 an. Beim Skype for Business Hybrid Mode muss der On-Prem Server etwas mithelfen, da die DNS-Einträge nicht direkt in die Cloud verweisen.

  • Suche per Lyncdiscoverinternal.<sipdomain> oder _sipinternaltls._tcp.<sipdomain> führt ins Leere
  • Suche per Lyncdiscover.<sipdomain> oder _sip._tcp.<sipdomain> verweist den Client auf die Webdienste bzw. den Edge E1
  • Per Lyncdiscover bekommt der Client die Umleitung auf die Cloud-Services
  • TLS-Verbindung mit dem Skype for Business Server in Office 365 Edge Server als Proxy zum Frontend in der Cloud

Der lokale Edge Server und Frontend Server wird von diesem Client in der Folge nicht weiter genutzt. Auch die STUN/TURN-Dienste des lokalen Edge Servers interessieren den Client nicht

Die Anmeldung für den Anwender A2 und B2 im internen LAN und aus dem Internet verfolgen identisch. Auch die mobilen Clients finden den Weg mittels Lyncdiscover zu ihrem Homeserver und nutzen dann dessen Dienste.

SIP-Messages in einer Firma

Interessant wird es nun, wenn ein Client dem anderen eine Nachricht senden will. Ich habe dazu zwei PCs an den unterschiedlichen Standorten in Betrieb genommen und allein auf dem Client über das UCCAPI-Log auf dem Empfänger die Information extrahiert. Das funktioniert natürlich so nicht für die Abfrage des Status. Daher habe ist dem Status ein Folgekapitel auf dieser Seite gewidmet.

Szenario Beschreibung

A1i -> A1i

Wenn zwei interne Benutzer miteinander kommunizieren, dann ist der Weg sehr einfach. Selbst mit einem zweiten Frontend in der Topologie ist es einfach:

A1i -> A1e

Der Benutzer A1e ist über den Edge Server angemeldet, so dass die Pakete über diesen Proxy zum A1e laufen. Der externe A1 User kann durchaus auf einem anderen Frontend Server sein als der interne A1, so dass intern ein weiterer Hop eingeführt werden könnte. Nur wenn beide Benutzer auf dem gleichen Frontend gehostet sind, entfällt der Zwischenschritt.

A1e -> A1i

Hier ist es nun gerade anders herum:

A1e -> A1e

Nun sind beide Clients extern und entsprechend gehen beide Über den Edge. Der Edge ist aber immer nur Proxy, so dass die Homeserver ebenfalls involviert bleiben:

Den zusätzlichen Schritt, dass eine SIP-Nachricht von einem Registrar zum anderen Registrar muss, lasse ich in den folgenden Beispielen weg.

SIP-Messages mit Hybrid

Interessant wird es nun, wenn ein Client dem anderen eine Nachricht senden will, der aber nun in Office 365 gehostet ist. In der Cloud gibt es aber keinen B1i. Alle Benutzer in der Cloud sind immer extern.

Szenario Beschreibung

A1i -> B1e

Der interne Anwender sendet ein Paket an den Office 365 Anwender. Der Weg ist schon um ein paar Hops länger. Er geht aber zweimal durch den Edge in der Cloud.

Der Weg ist der gleich, wenn das Office 365 Ziel im Homeoffice (=Internet) oder in ihrer Firma sitzt und den Office 365 Edge per NAT oder Proxy anspricht.

A1e -> B1e

Ist der On-Prem-Benutzer auch noch extern, kommen weitere Hops dazu.

B1e -> A1i

Auch umgekehrt ist der Weg noch einfach beschrieben. On-Prem kann noch mal ein Hop zwischen Frontends dazu kommen.

 

B1e -> A1e

Wenn A1 auch extern ist, dann drehen die Pakete auch noch mal eine Ehrenrunde über den On-Prem Edge.

Zusätzliche Registrar-Stationen habe ich nicht mehr addiert.

Zur Erinnerung
Diese Wege sind nur für die Signalisierung, Kontaktkarten und Kurzmitteilungen relevant. Audio, Video, Dateitransfer und Desktop-Sharing finden anderen Wege über ICE und Kandidaten

SIP-Messages mit Federation

Im diesem dritten Abschnitt beschreibe ich erst einmal die "gewöhnliche" Federation, wie sie auch ohne Office 365 betrieben werden kann. Die DNS-Eintrage "_sipfederationtls._tcp.<sipdomain>" verweisen auf die On-Prem-Server, so dass Office 365 hier noch nicht tangiert wird.

Szenario Beschreibung

A1i -> A2i

Beide Anwender sind intern und kommunizieren per Federation miteinander

A1i -> A2e

Wen ein Anwender extern ist, muss das Paket eine Schleife durch die On-Prem-Umgebung des Ziels laufen

A1e -> A2i

Auch wenn der Absender extern ist und das Ziel intern, laufen wir eine Schleife durch die Umgebung des Absenders

A1e -> A2e

Und wenn beide Extern sind, ist der Weg bei der Konstellation am längsten

Hybrid Federation

Als letzte Steigerung ist nun auch noch die Federation mit einer Gegenstelle zu beschreiben, die ebenfalls Hybrid nutzt und der Empfänger oder Absender in Office 365 gehostet ist. Und sie können sich schon denken, dass die Wege diesmal noch weiter werden können, da der DNS-Eintrage "_sipfederationtls._tcp.<sipdomain>" natürlich auf den On-Prem-Server verweisen.

Bei der Federation ist der Moment interessant, bei der das Paket den Office 365 Service verlässt. Microsoft hat hier zwei Optionen:

  • Zustellung zum Hybrid Partner
    Das wäre sauer aber würde einen Umweg und Abhängigkeit von der On-Prem Umgebung bedeuten
  • Direkte Zustellung zum Federation Partner
    Damit würde eine Abkürzung genutzt. Aber Edge-Server identifizieren ihren gegenüber über den Namen im Zertifikat und MTLS. Kann sich Office 365 denn als jede SIUP-Domäne ausgeben?

Hier die Leitwege

Szenario Beschreibung

A1i -> B2e

Der interne Anwender von Firma 1 sendet eine Meldung an den Office 365 Benutzer der Firma 2.

Es macht auch hier keinen Unterschied, ob Der Anwender B2 nun im Home-Office (=Internet) oder in der Firma (mit NAT oder Proxy zur Office 365) ist.

A1e -> B2e

Noch  länger wird der Weg, wenn auch A1 extern ist:

B1e -> A2i

Umgekehrt muss das Paket aus der Cloud natürlich auch zum On-Prem-User kommen

B1e -> A2e

Auch wenn der A2 Benutzer extern ist, kommt ein Hop dazu.

B1e -> B2e

Zuletzt gibt es noch den Fall, dass beide Teilnehmer in Office 365 gehostet sind.

Dass die SIP-Pakete immer über den On-Prem Edge gehen, sehen Sie bei den eingehenden als auch den ausgehenden Paketen. Hier ein eingehendes Paket von einem Federation Partner an einen Office 365 Anwender im UCCAPI-Trace des Empfängers.

INFO sip:user1@msxfaq.de;opaque=user:epid:V5mswjItSFyHyej4vLDNKAAA;gruu SIP/2.0
Via: SIP/2.0/TLS 10.1.29.18:49855
Max-Forwards: 70
From: "O365user1" <sip:o365user1@uclabor.de>;epid=450365190a;tag=032625e1b8
To: "Carius, Frank"<sip:user1@msxfaq.de>;tag=77987abb89;epid=2385f4c267
Call-ID: ff9304d85afe4c39a7e4895a9b956c04
CSeq: 1 INFO
Route: <sip:sippoolAM30E08.infra.lync.com:443;transport=tls;ms-fe=AM30E08FES03.infra.lync.com;opaque=state:F:Ci.x;lr;ms-route-sig=gdF-x-x>;ms-rrsig=gdRrFAY4guhiIJU-x;tag=x
Route: <sip:sipedgeAM30E.infra.lync.com:5061;transport=tls;opaque=state:Sfo;lr>;tag=x
Route: <sip:sip.uclabor.de:5061;transport=tls;lr;ms-key-info=x-x-M_pht-x-x-x-x-UqCfTjPr3c5FwtgdY5m-2_YLXiVbsX6T-x-x-x-x-x-x-x-x-x-x-x-x-x-x;ms-route-sig=x>;ms-rrsig=x;tag=x
Route: <sip:SfBstd01.uclabor.de:5061;transport=tls;lr>;tag=x
Route: <sip:sfbedge01.uclabor.de:5061;transport=tls;lr>;tag=x
Route: <sip:sip.msxfaq.de:5061;transport=tls;epid=2385f4c267;lr;ms-key-info=x-xxx-T-xx-Z0--x-x-x-USx;ms-route-sig=brFK-x>;ms-rrsig=x;tag=x
Route: <sip:sfb01.msxfaq.de:5061;transport=tls;opaque=state:T;lr>;tag=x
User-Agent: UCCAPI/16.0.4266.1001 OC/16.0.4266.1001 (Skype for Business)
Supported: ms-dialog-route-set-update
Supported: timer
Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="B98D442A", targetname="AM30E08FES03.infra.lync.com", crand="7c9c139b", cnum="341", response="x"
Content-Type: application/xml
Content-Length: 

Anhand des "Route": Eintrags sieht man, wie das Paket gelaufen ist und dass es genau den Weg wieder zurück gehen wird. Das ist aber kein Beleg daf����r, dass ein "neues" Paket auch über den Weg geht, sondern zeigt nur die eingehende Richtung zu einem Office 365 Hybrid User an.

 

Präsenz-Status

Die Abfrage der Präsenz ist der Übermittlung von Nachrichten sehr ähnlich. Es kommt der gleiche Signalweg zum Einsatz, wenn der Client fragt per SIP beim Registrar des Gegenübers den Status nach. Die Anfrage wird aber schon vom Homeserver des Ziels beantwortet und gelangt daher nicht mehr zum Teilnehmer selbst. Bei den verschiedenen Beispielen fällt also bei internen Clients der letzte Hop weg und bei externen Clients der Weg über den Edge zum Client.

Weitere Links