Cloud Voice Mail (CVM)

Seit Exchange 2019 gibt es keine UM-Rolle "on Premises" mehr. Und am 8 Feb 2019 wurde angekündigt, dass auch in Exchange Online die Voice Mail Funktion zum Feb 2020 entfällt.

Genau genommen war das auch nicht überraschen, zumal die Funktion durch "Azure Voice Mail"/"Cloud Voice Mail" bereit gestellt wird.

Wenn Sie Skype for Business Online oder Teams mit Exchange Online in der Cloud nutzen, dann ist das Setup durch Microsoft schon vorbereitet. Aber Cloud Voice Mail funktioniert auch mit Exchange On Premises und Skype for Business 2019 und 2015 On-Premises. Auf dieser Seite stelle ich die Funktion und Technik vor.

Interessant ist hier vor allem der Einsatz mit Skype for Business 2015 On Premises. Ich erwarte, dass viele Firmen ein Update zu Skype for Business 2019 möglichst lange hinauszögern um dann zu entscheiden, ob sie vielleicht mit Teams in der Cloud weiter machen. Aktuell (Dez 2018) ist die Entscheidung nicht einfach, da Teams noch lange nicht die Funktionen von Skype for Business 2015 bietet. Aber die Lücke wird immer kleiner. Aber eine Migration der Postfächer nach Exchange Online ist bei vielen Firmen schon geplant oder in Arbeit.

Hinweis
Sie können die VoiceMail Funktion natürlich auch mit anderen Produkten bereit stellen. Siehe dazu 3rd Party.

Server und Systeme

Microsoft hat auf der Seite Plan Cloud Voicemail Service (https://docs.microsoft.com/en-us/skypeforbusiness/hybrid/plan-cloud-voicemail) ein nettes Bild, welche die Optionen treffend aufzeigt.

Es zeigt den zentralen Service in der Cloud, welcher sowohl von Online-Benutzern aber auch von Benutzern mit Skype for Business On-Premises genutzt werden kann. Das Backend bleibt Exchange und auch hier kann das Postfach wahlweise in Exchange Online (Cloud) oder On Premises liegen. Das war lange Zeit noch nicht so, da Microsoft mit dem Release von Skype for Business 2019 Server und Exchange 2019 einige Einschränkungen vorgesehen hat. Ich würde eher sagen, dass vielleicht noch nicht alle Kombinationen "getestet" und damit nicht supportet sind. Entsprechend sieht die Tabelle aus. Der rote umrandete Teil zeigt die Funktion in der Preview. Der Blau umrandete Teil zeigt, dass Exchange 2013/2106 UM On-Premises erforderlich wäre.


Quelle https://docs.microsoft.com/en-us/skypeforbusiness/hybrid/plan-cloud-voicemail Dez 2018

Allerdings haben Sie auf dem Bild vorher die Situation gesehen, dass Skype for Business 2019 auch Cloud Voice Mail nutzen kann und dabei sogar lokale Exchange Postfächer unterstützt werden. Insofern ist die Tabelle so nicht mehr ganz akkurat, da zumindest der grüne Teil ja schon dokumentiert war. Skype for Business 2015 Server ist aber auch noch bis 2020, also 2 weitere Jahre, supportet. Insofern war es einfach nur logisch, dass auch der violett umrandete Teil noch realisiert wird. Im Rahmen einer frühen Evaluierung habe ich die folgenden Tests durchführen können.

Hinweis:
Der "Zugangspunkt" zu Cloud Voice Mail wird durch den Wechsel von Exchange Online UM zu Cloud Voice Mail nicht geändert. Microsoft steuert in der Cloud, welche Domain zu welchem Backend-System geroutet wird. Sie können also nicht über eine Einstellung auf dem Client oder On-Premises Server die Nutzung von Cloud Voice Mail erzwingen.

Der Zugriff auf Exchange ist etwas kniffliger, da Cloud Voice Mail wohl versucht, per EWS auf das Postfach zuzugreifen. Das ist auch erforderlich, wenn Sie als Anwender die Sprachnachrichten in ihrem Postfach abhören wollen. Der Exchange Administrator muss also schon Exchange korrekt einrichten. Allerding kennt Cloud Voice Mail auch ein Fallback auf SMTP, wie aus dem folgenden Zitat entnommen werden kann:

Phone System voicemail supports depositing voicemail messages only in an Exchange mailbox and doesn't support any third-party email systems. As a fallback mechanism, Phone System voicemail can resend messages using SMTP, which means users with a mailbox on a third-party email system will receive their voicemail messages with no guaranteed service uptime or other voicemail features, such as changing their greetings and other settings.
Quelle: Set up Phone System voicemail https://docs.microsoft.com/en-us/microsoftteams/set-up-phone-system-voicemail

Lizenz

Ehe Sie an die Einführung gehen, müssen wir noch einmal das Thema Lizenzen behandelt. Es gibt doch einige Fälle, in denen nicht ganz klar ist, welche Lizenz der Tenant und der Benutzer brauchen und wann die Lizenz in einem bestehenden Paket enthalten ist.

If you have an on-premises only deployment--that is, only Exchange and Skype for Business on-premises servers--but you want to take advantage of Cloud Voicemail, you need the ON-PREM license.
Quelle: Plan Cloud Voicemail service  https://docs.microsoft.com/en-us/skypeforbusiness/hybrid/plan-cloud-voicemail

For Skype for Business Online and Calling Plans users, Phone System voicemail is automatically set up and provisioned for users after you assign a Phone System license and a phone number to them.
If the Phone System feature isn't included in your plan, you may need to purchase Phone System add-on licenses. You also need to purchase an Exchange Online license.
Quelle: Set up Phone System voicemail https://docs.microsoft.com/de-de/microsoftteams/set-up-phone-system-voicemail

Man könnte also daraus folgern dass, jeder User auch eine Phone-License in der Cloud braucht. Das gilt aber nur für Benutzer, die auch in der Cloud telefonieren. Wer Exchange und Skype vor Business OnPremises betreibt, braucht wohl die Exchange Plus-Lizenz OnPremises und Exchange Online E3)

So ganz sind hier aber wohl noch nicht alle Worte gesprochen. Es gibt durchaus auch Aussagen, dass ein Tenant nur genau eine "Phone License" brauchen würde.

Server exap.um.outlook.com:5061

Cloud Voice Mail ist ein eigener Service, den Microsoft in Azure betreibt und entsprechend einfacher geografisch verteilen und skalieren kann. Von Anfang an wird Cloud Voice Mail z.B. eine "Speech to Text"-Transcription mit mehr Sprachen mitbringen, als Exchange UM je hatte. Ich denke dass auch ein großer Teil des Codes von Exchange UM auch zu Cloud Voice Mail umgelagert wurde. Wenn Sie sich aber die Exchange UM Rolle anschauen, dann war sie ja schon immer ein "angefügtes" Modul, welches auf einer Seite per SIP mit Gateway und Skype for Business kommuniziert hat und auf der anderen Seite Sprachnachrichten per SMTP an das Postfach zugestellt und per EWS den Voice Access und MWI - Message Waiting Indicator bereit gestellt hat. Beide Funktionen sind aber keine besonders enge Integration in Exchange und können von jedem eigenständigen Programm ebenso bereit gestellt werden.

Natürlich erfolgt die Signalisierung eines Gesprächs auch weiterhin per SIP und wenn Sie Skype for Business nutzen, dann senden Sie einen Einladung an die Voice-Mail über ihren Edge-Server zur Cloud Voice Mail. Ihr Client nutzt natürlich ihren lokalen Edge-Server als Media Relay (STUN/TURN) und auch Cloud Voice Mail hat seine eigenen Server. Die Adresse dazu kennen Sie ja schon.

Der Zugang ist übrigens für das alte Exchange UM als auch Cloud Voice Mail die gleiche URL. Allerdings schaltet Microsoft pro SIP-Domäne das Routing entsprechend auf das Zielsystem um. Das ist später bei der Konfiguration noch relevant.

Konfiguration

Zuerst müssen Sie natürlich sicherstellen, dass sie einen Office 36 Tenant haben und eine korrekte Hybrid-Konfiguration eingerichtet ist.

  • AADConnect
    Ihre lokalen Exchange Benutzer und Skype Benutzer müssen natürlich im AzureAD "bekannt" sein. Ein korrekt installierte AADConnect mit aktvierter Skype und Exchange Hybrid Bereitstellung ist Voraussetzung.
  • Skype Hybrid für Edge
    Für die Verbindung benötigen Sie einen Edge Server. Aber das ist ja schon für die Hybrid-Bereitstellung von Skype for Business mit Skype Online Voraussetzung und sollte daher schon vorhanden sein.
  • Exchange Hybrid mit Authentifizierung
    Wenn ihre Exchange Postfächer noch "On Premises" liegen, dann muss Cloud Voice Mail natürlich per Autodiscover die Eingangspunkte zu ihren Exchange Servern finden und sich als "Trusted Application" auch anmelden können. Das ist aber das normale Exchange Hybrid Setup, damit Cloud Voice Mail per EWS auf die Daten im Postfach zugreifen kann

Dann geht es noch an die Konfiguration. Der Zugang zu Exchange UM und Cloud Voicemail erfolgt über die gleiche Einstellung und wenn Sie schon Exchange UM in der Cloud genutzt haben, dann könnten Sie einen Eintrag wie den folgenden schon lokal vorfinden

PS C:\> Get-CsHostedVoicemailPolicy
Identity     : Tag:Office365UM
Description  : Office 365 Voicemail
Destination  : exap.um.outlook.com
Organization : uclabor.mail.onmicrosoft.com

Dieser Eintrag ist eine Policy, die dann den Benutzer zugewiesen wird, deren VoiceMail in der Cloud liegt weil z.B. ihr Postfach schon in die Cloud verschoben wurde. Als ich Cloud Voice Mail parallel testen durfte, habe ich mi reine weitere HostedVoiceMailPolicy mit einer anderen Domäne angelegt:

PS C:\> New-CsHostedVoicemailPolicy -Identity tag:CVMPilot -Description "Cloud Voice Mail Pilot" -Destination exap.um.outlook.com -Organization uclabor.de
Identity     : Tag:CVMPilot
Description  : Cloud Voice Mail Pilot
Destination  : exap.um.outlook.com
Organization : uclabor.de

Dann hat Microsoft mit die Domäne "uclabor.de" auf Cloud Voice Mail umgestellt. Ich musste die neue Richtlinie nur noch meinen Testusern zuweisen:

Grant-CsHostedVoicemailPolicy `
   -Identity user1@uclabor.de `
   -PolicyName tag:CVMPilot

Das hat also nichts mit der SMTP oder SIP-Domain zu tun sondern ist nur ein Routing.Eintrag für die ExchangeUM-Routing-Logic in meinem Skype for Business Frontend Servers

In der Cloud können Sie nun natürlich für den Anwender noch die ein oder andere Einstellung vornehmen.  Hier einfach mal die Steuerung bezüglich der "Voicemail Transcription"

Set-CsOnlineVoicemailPolicy `
   -EnableTranscription $false `
   -EnableTranscriptionProfanityMasking $true

Grant-CsOnlineVoicemailPolicy `
   -Identity sip:user1@uclabor.de `
   -PolicyName NoTranscriptionAllowed

Wie immer müssen Sie sich überlegen, welche Einstellungen sie in einer Policy zusammenfassen und an Benutzer zuweisen können. Auch hier gilt: Weniger Richtlinien ist besser um beim Support-Prozess nicht zu viele Sonderkonstellationen berücksichtigen zu müssen

Diagnose auf dem SfB 2015 Server

Ehe ich einige Calls beschreibe, habe ich auf meinem Skype for Business Server ein eigenes Szenario für das Thema Cloud Voice Mail angelegt. Dieses kann ich dann im CLSLogging einfach aktivieren und habe nur die Events, die mich für das Routing von Voice Mails interessieren:

New-CsClsScenario `
   -Identity "Global/CloudVoiceMail" `
   -Provider {Add=Name=ExumRouting;
Type=WPP;Level=Info;Flags=All;Guid=;Role=,
Name=InboundRouting;Type=WPP;Level=Info;Flags=All;Guid=;Role=,
Name=OutboundRouting;Type=WPP;Level=Info;Flags=All;Guid=;Role=,
Name=SIPStack;Type=WPP;Level=Info;Flags=TF_PROTOCOL,TF_CONNECTION,TF_SECURITY,TF_DIAG;Guid=;Role=}
 

Im Logging Tool kann ich dann das Szenario und die entsprechenden Server auswählen:

Über die GUI oder per PowerShell kann ich dann schnell einen Trace ziehen:

Search-CsClsLogging `
   -Pools "sfb.uclabor.de,sfbedge.uclabor.de" `
   -StartTime "18.12.2018 12:09:37" `
   -EndTime "18.12.2018 12:14:37" `
   -LogLevel "All" `
   -Uri "us1@uclabor.de" `
   -MatchAll `
   -OutputFilePath "C:\temp\CLSLog-CloudVoiceMail.txt"

Alles andere ist ja auf den Seiten zum Tracing beschrieben. Auch das UCCAPILOG auf dem Client ist durchaus eine Hilfe bei der Fehlersuche wenn Sie z.B. nicht sofort auf dem Server zugreifen wollen. Die Fehlermeldungen werden durchaus bis zum Client durchgereicht:

Call Flow mit SfB 2015 (Failed)

Nun schauen wir uns einfach mal an, wie so ein Anruf an die Cloud Voice Mail aussieht. Ich habe einfach meinen Skype for Business Client gestartet, de sich mit meinem On-Prem-Konto angemeldet hat. Über das Wahlfeld habe ich meine Voicemail selbst angerufen und siehe sehen, den eingehenden INVITE auf dem Skype Server, der dann zur Cloud Voice Mail geleitet wird. Hier funktioniert das aber noch nicht richtig. Ich habe daher gleich den Fehler genutzt, um auch diesen Fall zu beschreiben:

Interessant ist hier der blau umrandete ausgehende Invite zu Office 365, den ich hier noch mal als Textauszug verkürzt bereitstelle:

Direction: outgoing;source="internal edge";destination="external edge"
Peer: exap.um.outlook.com:5061
Message-Type: request
Start-Line: INVITE sip:user1@uclabor.de;ms-organization=uclabor.de SIP/2.0
From: "User1"<sip:user1@uclabor.de>;tag=cb790378b8;epid=768288fe52
To: <sip:user1@uclabor.de;opaque=app:voicemail>
Call-ID: xxxxxxxxxxxxxxxxxxxxx
CSeq: 1 INVITE
Contact: <sip:user1@uclabor.de;opaque=user:epid:xxxxxxxxx;gruu>
Route: <sip:exap.um.outlook.com;transport=tls;lr>
Record-Route: <sip:sip.uclabor.de:5061;transport=tls;lr;ms-key-info=xxx-xxx--xxx-xxx-xxx-xxx-xxx-xxx-xxx-xxx;ms-route-sig=xxx-xxx>;ms-rrsig=xxx-xxx;tag=xxx
Record-Route: <sip:fe1.uclabor.de:5061;transport=tls;opaque=state:T;lr>;tag=xx
Max-Forwards: 14
Content-Length: 2461
Content-Type: application/sdp
ms-split-domain-info: ms-traffic-type=SplitIntra
Referred-By: <sip:user1@uclabor.de>;
    ms-identity="xxx/xxx+xxx/xxx/xxx+xxx+xxx+oPwPVcP+xxx+xxx+xxx/xxx/xxx+xxx==:Sat, 15 Dec 2018 22:49:29 GMT";
    ms-identity-info="sip:sip.uclabor.de:5061;transport=tls";ms-identity-alg=sha256RSA
P-Asserted-Identity: "Carius, Frank"<sip:user1@uclabor.de>,<tel:+495257938808;ext=808>
Message-Body: 
v=0
o=- 0 0 IN IP4 80.66.20.56
.....

Sie sehen beim INVITE die "ms-organization" und das es über den Edge-Server raus geht. Das "100 Trying" im nächsten Paket kommt noch vom eigenen Edge-Server als Zwischenbestätigung. Das nächste Paket ist aber ein "403 Forbidden". Das schauen wir und auch mal genauer an.

Direction: incoming
Peer: sfbedge.uclabor.de:5061
Message-Type: response
Start-Line: SIP/2.0 403 Forbidden
FROM: "User1"<sip:user1@uclabor.de>;tag=4acaaeb618;epid=768288fe52
TO: <sip:user1@uclabor.de;opaque=app:voicemail>;epid=A3CDFA83A5;tag=dd5b12e9e5
CALL-ID: xxxxxxxxxxxxxxxxxxxxx
CSEQ: 1 INVITE
Via: SIP/2.0/TLS 192.168.1.102:55134;branch=z9hG4bK8F89BD67.1C9A2A287AC0786A;branched=TRUE;ms-received-port=55134;ms-received-cid=20E5400,SIP/2.0/TLS 192.168.102.148:56464;ms-received-port=56464;ms-received-cid=399300
CONTENT-LENGTH: 0
ms-diagnostics-public: 15636;source="CWLP265CA0131.GBRP265.PROD.OUTLOOK.COM";reason="The ms-organization parameter maps to a domain which is not marked as authoritative. Value: uclabor.de."
ms-split-domain-info: ms-traffic-type=SplitIntra;ms-remote-fqdn=exap.um.outlook.com
P-ASSERTED-IDENTITY: <sip:user1@uclabor.de;opaque=app:voicemail>
$$end_record

Der gelb markierte Bereich ist die Fehlermeldung, die ich von Cloud Voice Mail bekomme. Damit ist aber bewiesen, dass bei mir soweit alles vermutlich korrekt ist und der INVITE meine Topologie Richtung Cloud verlässt und auf der Gegenseite noch etwas nicht stimmt. Nach einigen Stunden hat Microsoft den Fehler gefunden und behoben. Genau dafür sind ja "Early Adopters" auch da, um ebne solche Dinge zu finden und zu melden.

Anruf: Klingeln beim Ziel

Nachdem der Fehler bereinigt war, konnte ich auch problemlos meine VoiceMail anrufen. Interessanter ist aber nun der Weg eines Anrufs von extern auf meinen Skype for Business On-Prem Benutzer, der aber nicht rangeht. Nach der eingestellten Zeit wird der Anruf dann zu Cloud Voice Mail weiter gegeben. Allerdings verzichte ich darauf, den kompletten Ablauf zu beschrieben. Es waren bei mir über 179 Zeilen im Trace für einen einzigen Anruf. Ich zitiere aber ein paar ausgewählte SIP-Paketen.

Zuerst kommt der Anruf rein und wird an die Endpunkte gemeldet. Bei mir ist das ein PC und ein Smartphone. Das spielt sich alles in weniger als 2 Sekunden ab.

Ganz unten sehen Sie aber schon das erste Paket, welches bei 23:39:10.486 eine Änderung meldet, die wir uns nun etwas genauer anschauen.

Anruf: CANCEL nach Zeitablauf

Die Wartezeit für ExchangeUM ist erreicht und der Skype for Business Server stoppt die ausgehenden Anrufe mit einem CANCEL

Die beiden Gegenstellen quittieren dies mit einem "487 Request Terminated".

Anruf: Aktvierung ExumRouting

Bei 23.39:11:780 sehen wir dann die Diagnose-Ausgabe, dass ExumRouting aktiv geworden ist.

TL_INFO(TF_DIAG) [sfb01\sfb01]4250.2AD8::12/20/2018-23:39:11.780.000020FC (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(827)) [4091604815] $$begin_record
Severity: information
Text: Routed a request on behalf of an application
SIP-Start-Line: INVITE sip:user1@uclabor.de;ms-organization=uclabor.de SIP/2.0
SIP-Call-ID: 61cdeed6-ab3d-46ba-8f42-15228bc09903
SIP-CSeq: 1949 INVITE
Peer: sfbedge.uclabor.de:5061
Data: application="http://www.microsoft.com/LCS/ExumRouting"
$$end_record

TL_INFO(TF_DIAG) [sfbedge\sfbedge]189C.16B4::12/20/2018-23:39:11.782.0000208C (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(827)) [2774529140] $$begin_record
Severity: information
Text: The message has a Discovered Domain
SIP-Start-Line: SIP/2.0 100 Trying
SIP-Call-ID: 61cdeed6-ab3d-46ba-8f42-15228bc09903
SIP-CSeq: 1949 INVITE
Peer: exap.um.outlook.com:5061
Data: domain="uclabor.de"

Anruf: Auflösung exap.um.outlook.com

Dass der Edge-Server nicht zum Skype for Business Edge in der Cloud geht, sondern einen eigenen Eingang nutzt, ist gut im Log zu sehen. Er löst auf exap.um.outlook.com auf und verbindet sich per TLS. Diesen Eintrag müssten Sie also bei sich auch sehen:

TL_INFO(TF_DIAG) [sfbedge\sfbedge]189C.144C::12/20/2018-23:39:11.532.0000206F (SIPStack,SIPAdminLog::WriteDNSEvent:SIPAdminLog.cpp(692)) [0] $$begin_record
Severity: information
Text: DNS query was successfully resolved
Query: exap.um.outlook.com
Query-Type: A
Query-Result: 52.112.193.167
Origin: +495257938808@uclabor.de
Query-Time: 31
TTL: 300
$$end_record

TL_INFO(TF_CONNECTION) [sfbedge\sfbedge]189C.0D04::12/20/2018-23:39:11.548.00002070 (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(464)) [2563599753] $$begin_record
Severity: information
Text: TLS negotiation started
Local-IP: 192.168.66.22:59072
Peer-IP: 52.112.193.167:5061
Peer: exap.um.outlook.com:5061
Connection-ID: 0x42A301
Transport: M-TLS
$$end_record

Anruf: INVITE zu exap.um.outlook.com

Und dann sehen wir auch endlich den INVITE zu ExchangeUM. Maßgeblich ist hier der "Route"-Eintrag:

TL_INFO(TF_PROTOCOL) [sfb01\sfb01]4250.2AD8::12/20/2018-23:39:11.781.000020FD (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(261)) [4091604815] 
Trace-Correlation-Id: 4091604815
Instance-Id: 50B16
Direction: outgoing
Peer: sfbedge.uclabor.de:5061
Message-Type: request
Start-Line: INVITE sip:user1@uclabor.de;ms-organization=uclabor.de SIP/2.0
From: <sip:+495257938808@uclabor.de;user=phone>;epid=61361A45EC;tag=d734bedf
To: <sip:+495251304613@uclabor.de;user=phone>
Call-ID: 61cdeed6-ab3d-46ba-8f42-15228bc09903
CSeq: 1949 INVITE
Contact: <sip:sfb01.uclabor.de@uclabor.de;gruu;opaque=srvr:MediationServer:o02UtjEH3V-4_CETtcNUOgAA;grid=0f5126569e1b43dcab018942afaaa29d>;isGateway
Via: SIP/2.0/TLS 192.168.1.102:61618;branch=z9hG4bK2B2C81B5.8355E36A82D3D92F;branched=TRUE
Via: SIP/2.0/TLS 192.168.1.102:50083;branch=z9hG4bK7338a585;ms-received-port=50083;ms-received-cid=F9900
Route: <sip:exap.um.outlook.com;transport=tls;lr>;ms-edge-route
Record-Route: <sip:sfb01.uclabor.de:5061;transport=tls;lr>;tag=B6B8F0A1C2C603679C2ABC6C5EB06074
Max-Forwards: 15
Content-Length: 2738
Content-Type: multipart/alternative; boundary=jJ8QEUH5nw6TANVxeAiX6o2TyrSAtlMB
ms-split-domain-info: ms-traffic-type=SplitIntra
Message-Body: 
--jJ8QEUH5nw6TANVxeAiX6o2TyrSAtlMB
Content-Type: application/sdp

v=0
o=- 159 0 IN IP4 192.168.1.102
s=session
c=IN IP4 192.168.1.102
b=CT:10000000
t=0 0
m=audio 57156 RTP/AVP 0 8 115 13 118 97 101
c=IN IP4 192.168.1.102
a=rtcp-rsize
a=rtcp-fb:* x-message app send:dsh recv:dsh
a=rtcp:57157
a=ice-ufrag:20kZ
a=ice-pwd:wILcSy0AHdhjYDf6Z/8d2EJa
a=candidate:1 1 UDP 2130706431 192.168.1.102 57156 typ host
a=candidate:1 2 UDP 2130705918 192.168.1.102 57157 typ host
a=candidate:2 1 tcp-pass 174456319 80.66.20.56 58929 typ relay raddr 192.168.1.102 rport 52905
a=candidate:2 2 tcp-pass 174455806 80.66.20.56 58929 typ relay raddr 192.168.1.102 rport 52905
a=candidate:3 1 UDP 184548351 80.66.20.56 54113 typ relay raddr 192.168.1.102 rport 50490
a=candidate:3 2 UDP 184547838 80.66.20.56 50669 typ relay raddr 192.168.1.102 rport 50491
a=candidate:4 1 tcp-act 174848511 80.66.20.56 58929 typ relay raddr 192.168.1.102 rport 52905
a=candidate:4 2 tcp-act 174847998 80.66.20.56 58929 typ relay raddr 192.168.1.102 rport 52905
a=candidate:5 1 tcp-act 1684797439 192.168.1.102 52905 typ srflx raddr 192.168.1.102 rport 52905
a=candidate:5 2 tcp-act 1684796926 192.168.1.102 52905 typ srflx raddr 192.168.1.102 rport 52905
a=label:main-audio
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:xxx|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:xxx|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:xxx|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

Ich habe den INVITE nur minimal gekürzt. Sie sehn also auch die SDP-Kandidaten, die hier eine private IP-Adresse aber auch die Edge-Adressen der On-Premises Topologie anzeigen.

Anruf: 180 RINGING von ExUM

Kurz nach dem "100 Trying" des lokalen Edge-Servers kommt dann schon direkt das RINGING von Cloud Voice Mail. hier aber noch ohne SDP-Kandidaten und einer sehr lange "RECORD-ROUTE", die ich etwas gekürzt habe.

TL_INFO(TF_PROTOCOL) [sfbedge\sfbedge]189C.16B4::12/20/2018-23:39:11.864.0000208F (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(261)) [4091604815] 
Trace-Correlation-Id: 4091604815
Instance-Id: 567F7
Direction: incoming;source="external edge";destination="internal edge"
Peer: exap.um.outlook.com:5061
Message-Type: response
Start-Line: SIP/2.0 180 Ringing
FROM: <sip:+495257938808@uclabor.de;user=phone>;tag=d734bedf;epid=61361A45EC
TO: <sip:+495251304613@uclabor.de;user=phone>;tag=1c268a26e3;epid=413D105698
CALL-ID: 61cdeed6-ab3d-46ba-8f42-15228bc09903
CSEQ: 1949 INVITE
CONTACT: <sip:sip2.lgw.skype.com:50102;ms-fe=c-lgw-euwe-02.lgw.skype.com;transport=Tls>;isGateway;text;audio;video;image;application
Via: SIP/2.0/TLS 192.168.66.22:59072;received=52.112.131.125;branch=z9hG4bK1EE15A7C.24459BEA509B692F;branched=FALSE;ms-internal-info="xxx";
   ms-received-port=59072;ms-received-cid=69C49500,SIP/2.0/TLS 192.168.1.102:61618;....
RECORD-ROUTE: <sip:exap.um.outlook.com:5061;transport=tls;epid=413D105698;lr;ms-key-info=x-x-x-x-x-x-x-x;ms-route-sig=x>,....
   <sip:sfb01.uclabor.de:5061;transport=tls;lr>;tag=B6B8F0A1C2C603679C2ABC6C5EB06074
CONTENT-LENGTH: 0
ms-split-domain-info: ms-traffic-type=SplitIntra
P-ASSERTED-IDENTITY: ""<sip:user1@uclabor.de>
$$end_record

Cloud Voice Mail arbeitet also nicht mit Early Media oder "183 Session Progress".

Anruf: 200 OK von ExUM

 Der 200 OK kommt dann 42ms später mit den Kandidaten:

TL_INFO(TF_PROTOCOL) [sfbedge\sfbedge]189C.1710::12/20/2018-23:39:14.808.00002093 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(261)) [4091604815] 
Trace-Correlation-Id: 4091604815
Instance-Id: 567F8
Direction: incoming;source="external edge";destination="internal edge"
Peer: exap.um.outlook.com:5061
Message-Type: response
Start-Line: SIP/2.0 200 OK
FROM: <sip:+495257938808@uclabor.de;user=phone>;tag=x;epid=x
TO: <sip:+495251304613@uclabor.de;user=phone>;tag=x;epid=x
CALL-ID: 61cdeed6-ab3d-46ba-8f42-15228bc09903
CSEQ: 1949 INVITE
CONTACT: <sip:sip2.lgw.skype.com:50102;ms-fe=c-lgw-euwe-02.lgw.skype.com;transport=Tls>;isGateway;text;audio;video;image;application
Via: SIP/2.0/TLS 192.168.66.22:59072;received=52.112.131.125;branch=x.x;branched=FALSE;ms-internal-info="x";
   ms-received-port=59072;ms-received-cid=69C49500,SIP/2.0/TLS 192.168.1.102:61618;branch=x.x;branched=TRUE;
   ms-received-port=61618;ms-received-cid=3BB000,SIP/2.0/TLS 192.168.1.102:50083;branch=x;
   ms-received-port=50083;ms-received-cid=F9900
RECORD-ROUTE: <sip:exap.um.outlook.com:5061;transport=tls;epid=413D105698;lr;ms-key-info=x-x-x-x-x-x-x-x;ms-route-sig=x>,
   <sip:sip.uclabor.de:5061;transport=tls;lr;ms-key-info=x-x-x-x-x-x-x-x-x-x-x-Se-x-x-x-x-x-x-x;ms-route-sig=x-x>;ms-rrsig=x-x;tag=x,
   <sip:sfb01.uclabor.de:5061;transport=tls;lr>;tag=x
CONTENT-LENGTH: 2031
CONTENT-TYPE: application/sdp
ms-split-domain-info: ms-traffic-type=SplitIntra
P-ASSERTED-IDENTITY: ""<sip:user1@uclabor.de>
Message-Body: 

v=0
o=- 48589 0 IN IP4 127.0.0.1
s=session
c=IN IP4 52.136.229.107
b=CT:10000000
t=0 0
m=audio 51072 RTP/SAVP 0 8 13 118 97 101
c=IN IP4 52.136.229.107
a=rtcp-rsize
a=rtcp-fb:* x-message app send:dsh recv:dsh
a=x-signaling-fb:* x-message app send:dsh
a=rtcp:51073
a=ice-ufrag:yZ3F
a=ice-pwd:1WuA7tlCOkDWI3HkQkwjA8Ws
a=candidate:1 1 UDP 2130706431 52.136.229.107 51072 typ srflx raddr 192.168.0.14 rport 51072
a=candidate:1 2 UDP 2130705918 52.136.229.107 51073 typ srflx raddr 192.168.0.14 rport 51073
a=candidate:2 1 UDP 184548863 52.114.124.113 52488 typ relay raddr 52.136.229.107 rport 53246
a=candidate:2 2 UDP 184548350 52.114.124.113 50365 typ relay raddr 52.136.229.107 rport 53247
a=candidate:3 1 tcp-pass 174455807 52.114.124.18 52148 typ relay raddr 52.136.229.107 rport 50172
a=candidate:3 2 tcp-pass 174455294 52.114.124.18 52148 typ relay raddr 52.136.229.107 rport 50172
a=candidate:5 1 tcp-act 174848511 52.114.124.18 52148 typ relay raddr 52.136.229.107 rport 50172
a=candidate:5 2 tcp-act 174847998 52.114.124.18 52148 typ relay raddr 52.136.229.107 rport 50172
a=x-candidate-ipv6:6 1 tcp-pass 174454783 2603:1027:0:8040::4 52148 typ relay raddr 52.136.229.107 rport 50172
a=x-candidate-ipv6:6 2 tcp-pass 174454270 2603:1027:0:8040::4 52148 typ relay raddr 52.136.229.107 rport 50172
a=x-candidate-ipv6:7 1 tcp-act 174847487 2603:1027:0:8040::4 52148 typ relay raddr 52.136.229.107 rport 50172
a=x-candidate-ipv6:7 2 tcp-act 174846974 2603:1027:0:8040::4 52148 typ relay raddr 52.136.229.107 rport 50172
a=candidate:9 1 tcp-act 1684796415 52.136.229.107 51072 typ srflx raddr 192.168.0.14 rport 51072
a=candidate:9 2 tcp-act 1684795902 52.136.229.107 51072 typ srflx raddr 192.168.0.14 rport 51072
a=label:main-audio
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:mdQtQzOmkSsm6f+w/3EX5I48Nlnhe6vdGCIoN7Ay|2^31|1:1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
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
a=ptime:20

Interessant ist hierbei, dass die Server bei Microsoft intern auch mit privaten Adressen (192.168.0.14) arbeiten, die sich hinter einem Edge-Server verbergen. Allerdings ist dies nicht für TCP-Kandidaten der fall, die aber bei Sprache eigentlich nicht zum Einsatz kommen sollten. Microsoft bietet extern für TCP auch IPv6 an, welche aber intern auf öffentliche IPv4-Adressen umgesetzt werden. Die Codecs sind hingegen nicht sonderlich spannend. Es ist eher überraschend, dass nur G711 und weder RTAUDIO noch SILK angeboten wird. Das spart zwar ein Transcoding zwischen Gateway und ExchangeUM und könnte sogar "MediaBypass" erlauben, wenn das Gateway ebenfalls aus de Internet erreichbar wäre.

Anruf: ReINVITE mit SDP

Beim nächsten INVITE sind dann nur noch die vereinbarten Kandidaten und Codes im SDP.

TL_INFO(TF_PROTOCOL) [sfbedge\sfbedge]189C.16B4::12/20/2018-23:39:15.152.0000209E (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(261)) [4091604907] 
Trace-Correlation-Id: 4091604907
Instance-Id: 567FA
Direction: outgoing;source="internal edge";destination="external edge"
Peer: exap.um.outlook.com:5061
Message-Type: request
Start-Line: INVITE sip:sip2.lgw.skype.com:50102;ms-fe=c-lgw-euwe-02.lgw.skype.com;transport=Tls SIP/2.0
From: <sip:+495257938808@uclabor.de;user=phone>;epid=61361A45EC;tag=d734bedf
To: <sip:+495251304613@uclabor.de;user=phone>;epid=413D105698;tag=8ff1a6044
Call-ID: 61cdeed6-ab3d-46ba-8f42-15228bc09903
CSeq: 1950 INVITE
Contact: <sip:sfb01.uclabor.de@uclabor.de;gruu;opaque=srvr:MediationServer:o02UtjEH3V-4_CETtcNUOgAA;grid=0f5126569e1b43dcab018942afaaa29d>;isGateway
Content-Type: application/sdp
ms-split-domain-info: ms-traffic-type=SplitIntra
Message-Body: 

v=0
o=- 159 1 IN IP4 192.168.1.102
s=session
c=IN IP4 80.66.20.27
b=CT:10000000
t=0 0
m=audio 57156 RTP/SAVP 0 8 115 13 118 97 101
c=IN IP4 80.66.20.27
a=rtcp-rsize
a=rtcp-fb:* x-message app send:dsh recv:dsh
a=rtcp:57157
a=ice-ufrag:20kZ
a=ice-pwd:wILcSy0AHdhjYDf6Z/8d2EJa
a=candidate:6 1 UDP 1862270719 80.66.20.27 57156 typ prflx raddr 192.168.1.102 rport 57156
a=candidate:6 2 UDP 1862270462 80.66.20.27 57157 typ prflx raddr 192.168.1.102 rport 57157
a=remote-candidates:1 52.136.229.107 51072 2 52.136.229.107 51073
a=label:main-audio
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:78hYtRHMhCfXBj41YxKQtR3fWwhDtQ+oAI5hrQBb|2^31|1:1
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

Bei den Codecs sehen Sie aber auch "101 telephone-event/8000", d.h. die DTMF-Steuerung erfolgt innerhalb von RTP und ist daher nicht mehr im Trace zu sehen: Der Anruf lief also von 23:39:15 bis 23:39:42 über eine Dauer von 27 Sekunden. Genug Zeit um eine Nachricht zu hinterlassen.

Anruf: Auflegen mit BYE

Am Ende hat der Anrufer einfach aufgelegt. Das Gateway zum Amt bekommt die entsprechende Meldung und sendet ein BYE nach intern, welches dann durch den Frontend über den Edge zu exap.um.outlook.com geleitet wird.

Das BYE vom FE zum Edge sieht wie folgt aus:

TL_INFO(TF_PROTOCOL) [sfbedge\sfbedge]189C.16B4::12/20/2018-23:39:42.368.000020AE (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(261)) [4091604908] 
Trace-Correlation-Id: 4091604908
Instance-Id: 567FE
Direction: outgoing;source="internal edge";destination="external edge"
Peer: exap.um.outlook.com:5061
Message-Type: request
Start-Line: BYE sip:sip2.lgw.skype.com:50102;ms-fe=c-lgw-euwe-02.lgw.skype.com;transport=Tls SIP/2.0
From: <sip:+495257938808@uclabor.de;user=phone>;epid=61361A45EC;tag=d734bedf
To: <sip:+495251304613@uclabor.de;user=phone>;epid=413D105698;tag=8ff1a6044
Call-ID: 61cdeed6-ab3d-46ba-8f42-15228bc09903
CSeq: 1951 BYE
Contact: <sip:sfb01.uclabor.de@uclabor.de;gruu;opaque=srvr:MediationServer:o02UtjEH3V-4_CETtcNUOgAA;grid=x>;isGateway
Via: SIP/2.0/TLS 192.168.66.22:59072;branch=z9hG4bK180627A7.9B51D2AF5824194E;branched=FALSE;ms-internal-info="x-x"
Via: SIP/2.0/TLS 192.168.1.102:61618;branch=z9hG4bK06A9F27E.5659308A8A5C994E;branched=FALSE;ms-received-port=61618;ms-received-cid=3BB000
Via: SIP/2.0/TLS 192.168.1.102:50083;branch=z9hG4bK7e45266d;ms-received-port=50083;ms-received-cid=F9900
Route: <sip:exap.um.outlook.com:5061;transport=tls;epid=413D105698;lr;ms-key-info=x-x-x-x-FDeOvegOVAEYpqAFo0-x-x-x;ms-route-sig=x>
Max-Forwards: 68
CONTENT-LENGTH: 0
ms-diagnostics-public: 10027;reason="Normal termination response from gateway after the call was established";component="MediationServer";sip-reason="Q.850 ;cause=16"
ms-split-domain-info: ms-traffic-type=SplitIntra
P-Asserted-Identity: <sip:+495257938808@uclabor.de;user=phone>
$$end_record

Kurze Zeit später kommt dann auch das "200 OK" auf das Bye von Cloud Voice Mail zurück

TL_INFO(TF_PROTOCOL) [sfb01\sfb01]4250.2AD8::12/20/2018-23:39:42.693.00002151 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(261)) [4091604908] 
Trace-Correlation-Id: 4091604908
Instance-Id: 50B3E
Direction: incoming
Peer: sfbedge.uclabor.de:5061
Message-Type: response
Start-Line: SIP/2.0 200 OK
FROM: <sip:+495257938808@uclabor.de;user=phone>;tag=d734bedf;epid=61361A45EC
TO: <sip:+495251304613@uclabor.de;user=phone>;tag=8ff1a6044;epid=413D105698
CALL-ID: 61cdeed6-ab3d-46ba-8f42-15228bc09903
CSEQ: 1951 BYE
Via: SIP/2.0/TLS 192.168.1.102:61618;branch=z9hG4bK06A9F27E.5659308A8A5C994E;branched=FALSE;ms-received-port=61618;ms-received-cid=3BB000,SIP/2.0/TLS 192.168.1.102:50083;branch=z9hG4bK7e45266d;ms-received-port=50083;ms-received-cid=F9900
CONTENT-LENGTH: 0
ms-split-domain-info: ms-traffic-type=SplitIntra;ms-remote-fqdn=exap.um.outlook.com
P-ASSERTED-IDENTITY: ""<sip:user1@uclabor.de>
$$end_record

MWI Message

Ca. 99ms hat es gedauert, bis nun eingehend eine Meldung an mich gekommen ist, dass eine neue Sprachnachricht vorhanden ist.

Der NOTIFY enthält natürlich nicht die Payload:

TL_INFO(TF_PROTOCOL) [sfbedge\sfbedge]189C.16B4::12/20/2018-23:39:48.792.000020C9 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(261)) [3646542384] 
Trace-Correlation-Id: 3646542384
Instance-Id: 56808
Direction: incoming;source="external edge";destination="internal edge"
Peer: exap.um.outlook.com:61066
Message-Type: request
Start-Line: NOTIFY sip:user1@uclabor.de:5061 SIP/2.0
FROM: <sip:user1@uclabor.de:5061>;epid=12B6E59DE1;tag=1e1bd77e9e
TO: <sip:user1@uclabor.de:5061>
CALL-ID: 1ca5128a995149e2a00d4124a368f76a
CSEQ: 230 NOTIFY
CONTACT: <sip:user1@uclabor.de:5061>
Via: SIP/2.0/TLS 52.112.131.79:61066;branch=z9hG4bK728E4460.3379F6F31DFAB955;branched=FALSE;ms-internal-info="drBNixdRsWJldpuAvdl9QCWTYsJ8qmoB1uzBG4a0bf6PXz9nkzA7Md2QAA"
Via: SIP/2.0/TLS 20.177.34.85:42243;branch=z9hG4bK70f66a1;received=10.21.15.254;ms-received-port=42243;ms-received-cid=6CB4FB00
Max-Forwards: 69
CONTENT-LENGTH: 96
CONTENT-TYPE: application/simple-message-summary
ms-split-domain-info: ms-traffic-type=SplitIntra
Message-Body: 
----****MESSAGE BODY DELETED****----

Der Client hat aber so schon sehr schnell die Information bekommen, dass eine Sprachnachricht im Postfach gelandet ist

Voicemail im Posteingang

Im Postfach landete nun meine Sprachnachricht als MP3-Datei. Ein Blick auf die Zeit verrät, dass es 0:40 gewesen sein soll. Der Zeitstempel im SfB Logging ist aber UTC-Zeit, so dass aus dem 23:39:42 (BYE) natürlich ein 00:39:42 wird. Im später abgebildeten SMTP-Header sehen sie, dass die Sendezeit auf 00:39:44 angegeben wird. Wenn die Zeiten so stimmen, dann hat die Verarbeitung gerade mal 2 Sekunden gedauert.

In der Zeit wurde auch noch die Nachricht fast fehlerfrei als "Text" transkribiert und der Text ist zwar nicht 100 korrekt bezüglich Groß- und Kleinschreibung aber der Inhalt ist korrekt wiedergegeben. Dafür, dass die Aufnahme "nur" ein Telefonat mit beschränkter Bandbreite und keine High-End-Audioaufzeichnung mit Headset war, ist das schon beeindruckend. Die Funktion gab es ja schon bei Exchange UM aber eben nicht für Deutsch.

Im Postfach ist die Mail dann ca. 2 Sekunden später gelandet, wie Sie aus dem verkürzten SMTP-Header sehen können.

Received: from AM0PR04MB5011.eurprd04.prod.outlook.com (2603:10a6:20b:56::29)
 by AM6PR04MB5013.eurprd04.prod.outlook.com with HTTPS via
 AM6PR0502CA0052.EURPRD05.PROD.OUTLOOK.COM; Thu, 20 Dec 2018 23:39:46 +0000
Received: from VI1PR04CA0095.eurprd04.prod.outlook.com (2603:10a6:803:64::30)
 by AM0PR04MB5011.eurprd04.prod.outlook.com (2603:10a6:208:c9::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.19; Thu, 20 Dec
 2018 23:39:45 +0000
Received: from DB5EUR03FT050.eop-EUR03.prod.protection.outlook.com
 (2a01:111:f400:7e0a::205) by VI1PR04CA0095.outlook.office365.com
 (2603:10a6:803:64::30) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.19 via Frontend
 Transport; Thu, 20 Dec 2018 23:39:45 +0000
Authentication-Results: spf=fail (sender IP is 52.114.75.28)
 smtp.mailfrom=uclabor.de; uclabor.de; dkim=none (message not signed)
 header.d=none;uclabor.de; dmarc=none action=none header.from=;
Received-SPF: Fail (protection.outlook.com: domain of uclabor.de does not
 designate 52.114.75.28 as permitted sender) receiver=protection.outlook.com;
 client-ip=52.114.75.28; helo=EUR03B.map.protection.outlook.com;
Received: from EUR03B.map.protection.outlook.com (52.114.75.28) by
 DB5EUR03FT050.mail.protection.outlook.com (10.152.21.128) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.1382.18 via Frontend Transport; Thu, 20 Dec 2018 23:39:44 +0000
X-AttachmentOrder: audio.mp3
X-VoiceMessageDuration: 12
Content-Class: Voice-CA
X-AzureVoicemail-CallId: d4ef2b28-3cae-4250-93bf-0bb24fe7b254
X-AzureVoicemail-FirehoseActivityId: 4778385926234516264
X-IsPstnCall: True
X-ShareDataEnabled: True
To: <Frank.Carius@uclabor.de>
From: <+49 5257 938808>
Reply-To: +49 5257 938808 <noreply@skype.voicemail.microsoft.com>
Subject: Voicemail (11 Sekunden)
X-AzureVoicemail-TranscriptionRequestId: b7c6e9d5-e1e5-4ad7-ab64-4a38434f988c
X-VoiceMessageTranscription: =?utf-8?b?SGFsbG....bi4=?=
X-VoiceMessageConfidenceLevel: high
X-VoiceMessageInitialSilence: False
X-VoiceMessageLanguage: de-DE
Priority: normal
Content-Type: multipart/mixed;
	boundary="_002_a4bcd9a515b44b9d8eceb05d7333675fpiotk5m200exchangecorpm_"
MIME-Version: 1.0
Message-ID:
 <a80cfd61-4128-44fb-85aa-44a3e46e2743@DB5EUR03FT050.eop-EUR03.prod.protection.outlook.com>
Return-Path:
 noreply_skype_voicemail_d4ef2b28-3cae-4250-93bf-0bb24fe7b254@uclabor.de
Date: Thu, 20 Dec 2018 23:39:44 +0000
X-MS-Exchange-Organization-ExpirationStartTime: 20 Dec 2018 23:39:44.9237
 (UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 2:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
 34a5cf84-9d99-4f13-15a0-08d666d46bec
X-EOPAttributedMessage: 0
X-MS-Exchange-Organization-MessageDirectionality: Originating
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthSource:
 TreatMessagesAsInternal-DB5EUR03FT050.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report:
 CIP:52.114.75.28;IPV:NLI;CTRY:US;EFV:NLI;SFV:SKI;SFS:;DIR:INB;SFP:;SCL:-1;SRVR:AM0PR04MB5011;H:EUR03B.map.protection.outlook.com;FPR:;SPF:None;LANG:de;
X-OriginatorOrg: uclabor.onmicrosoft.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 34a5cf84-9d99-4f13-15a0-08d666d46bec
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=x-x-x-x-x;Ip=[52.114.75.28];Helo=[EUR03B.map.protection.outlook.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB5011
X-MS-Exchange-Transport-EndToEndLatency: 00:00:02.1342384

Hier ist selbst nichts viel zu sehen. Zwei Dinge fallen vielleicht auf:

  • Absender und ReplyTo (blau)
    Beide gelb markierten Adressen verhindern eine Rückantwort an den Anrufer.
  • SPF-Check (rot)
    Der SPF-Check schlägt natürlich fehl, wenn Cloud Voice Mail mit meiner per SPF-Eintrag gesicherten SMTP-Domäne einliefern will. Ich denke aber dass Microsoft hier die Cloud Voice Mail Sender per Whitelisting den Filter außer Kraft setzen. Allerdings bin ich schon irritiert, dass der Check überhaupt ausgeführt wird.

Alle anderen Einträge sind wohl bekannt. Da es gerade Weihnachten ist, hab ich auch mal einen kurzen Teil der Weihnachtsgeschichte eingesprochen

Die Weihnachtsgeschichte nach Lukas Es begab sich aber zur der Zeit, dass ein Gebot von dem Kaiser Augustus ausging, dass alle Welt geschätzt würde. Und diese Schätzung war die allererste und geschah zur Zeit, da Quirinius Statthalter in Syrien war. Und jedermann ging, dass er sich schätzen ließe, ein jeder in seine Stadt. Da machte sich auf auch Josef aus Galiläa, aus der Stadt Nazareth, in das jüdische Land zur Stadt Davids, die da heißt Bethlehem, weil er aus dem Hause und Geschlechte Davids war, damit er sich schätzen ließe mit Maria, seinem vertrauten Weibe; die war schwanger. Und als sie dort waren, kam die Zeit, dass sie gebären sollte. Und sie gebar ihren ersten Sohn und wickelte ihn in Windeln und legte ihn in eine Krippe; denn sie hatten sonst keinen Raum in der Herberge.
Quelle: https://www.theology.de/kirche/kirchenjahr/weihnachtsgeschichtelukas2120.php

Mit Übertragung der Sprache in Text von Cloud Voice Mail ist gar nicht mal so schlecht.

Es sollte auf jeden Fall reichen, um den Inhalt einer Sprachnachricht zu verstehen ohne diese erst abhören zu müssen.

QoE-Report

Meine On Premises Umgebung hat natürlich auch eine Skype Monitoring Rolle installiert. Allerdings ist der Anruf natürlich von einem lokalen Gateway über den eigenen Frontend und Edge zu einem Endpunkt in der Cloud gelaufen. Mein lokales Gateway sendet erst mal keinen Skype-konformen QoE-Report. Das kann nur der Mediation Server. Aus der Cloud hingegen erwarte ich besser keinen QoE-Report, denn die Cloud Voice Mail-Rolle ist ja erst einmal nur ein Service, der auch ohne Skype for Business Online-Nutzung genutzt werden kann.

Allerdings habe ich aktuell noch kein Portal gefunden, in dem die Nutzung von Cloud Voice Mail nachvollziehbar wäre. Gesucht habe ich in:

Hier steht also sicher noch etwas Arbeit an.

VoiceMail ? Teams

Als ich Anfang Februar meine VoiceMail mal wieder angerufen habe, habe ich eine verwirrende Meldung bekommen. Angeblich sei ich zu Teams gewechselt.

Das war natürlich nicht der Fall, da ich zu dem Zeitpunkt weiter auf Skype for Business On Premises gearbeitet habe. Ein Blick in den Trace habe aber die Ursache gezeigt:

02/05/2019|22:54:23.061 5488:2C8C INFO  :: Data Received -80.66.20.22:443 (To Local Address: 192.168.178.50:61232) 2308 bytes:
02/05/2019|22:54:23.061 5488:2C8C INFO  :: 
SIP/2.0 180 Ringing
ms-user-logon-data: RemoteUser
Via: SIP/2.0/TLS 192.168.178.50:61232;received=46.85.243.26;ms-received-port=61232;ms-received-cid=C295200
Authentication-Info: TLS-DSK qop="auth", opaque="154F9B0D", srand="E626911E", snum="3700", rspauth="x", targetname="sfbfe01.uclabor.de", realm="SIP Communications Service", version=4
FROM: "Carius, Frank"<sip:user1@uclabor.de>;tag=x;epid=x
TO: <sip:user1@uclabor.de;opaque=app:voicemail>;tag=x;epid=x
CSEQ: 1 INVITE
CALL-ID: xxxxxxxxxx
RECORD-ROUTE: <sip:exap.um.outlook.com:5061;transport=tls;epid=x;lr;ms-key-info=xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx;ms-route-sig=xx-x>,
   <sip:sfbedge.uclabor.de:5061;transport=tls;opaque=state:Si;lr>,
   <sip:sfbfe01.uclabor.de:5061;transport=tls;opaque=state:F;lr;received=192.168.100.102;ms-received-cid=C2B8100>
RECORD-ROUTE: <sip:sip.uclabor.de:443;transport=tls;opaque=state:Ci.Rc295200;lr;ms-route-sig=x>
CONTACT: <sip:sip2.lgw.skype.com:50104;ms-fe=a-lgw-euno-02.lgw.skype.com;transport=Tls>;isGateway;text;audio;video;image;application
CONTENT-LENGTH: 0
ALLOW: CANCEL
ALLOW: BYE
ALLOW: UPDATE
ALLOW: PRACK
P-ASSERTED-IDENTITY: ""<sip:user1@uclabor.de;opaque=app:voicemail>
SERVER: RTCC/7.0.0.0 LyncTeamsGateway/1.1.187.0
ms-lync-skype-gw-teams: true
ms-telemetry-id: 33A39C74-2F47-52C4-8D3E-AAF698C88BB4

Im Gegensatz zum ersten "180 RINGING" vom 20.12.2018 ist hier nun ein "LyncTeamsGateway" als Server aufgetaucht und das scheint für den Skye for Business Client das Signal zu sein, dem Anwender die Meldung zu zeigen. In dem Kontext ist das natürlich falsch und auch nicht sonderlich sinnvoll. Microsoft kenn den Bug aber schon.

3rd Party

Wenn Sie nun partout nicht ihre Voice Mail in der Cloud nutzen wollen, dann spricht natürlich nichts dagegen, die Funktion weiter lokal durch Exchange 2016 oder auch Drittprodukte bereit zu stellen. Das trifft natürlich nur dann zu, wenn Sie selbst die SIP-Anbindung nutzen. Wer Telefonie mit einem Microsoft Minutenpaket nutzt, kann keine Alternativen nutzen.

Exchange UM war aber schon immer etwas "an Exchange angeflanscht" und nur minimal in OWA oder Outlook integriert. Natürlich kann Exchange UM auch LDAP-Felder von Skype for Business lesen aber das können andere auch. Also was war denn genau Exchange UM noch mal genau?

  1. Anrufer landen auf einer Sprachboy, wenn ich nicht erreichbar bin
    Ohne VoiceMail wird Skype for Business oder Teams ein "Not reachable" an den SBC/das Gateway zurück melden. Jedes halbwegs gute Gateway kann diese Meldung abfangen und den Anruf auf ein anderes System Routen.
  2. Sprachnachrichten landen in meiner Mailbox
    Auch ein 3rd Party System kann die aufgezeichnete Sprache per SMTP oder EWS in das Postfach des Benutzers als Anlage zustellen.
  3. Sprachnachrichten abhören
    Auch das 3rd Party System kann einfach per Telefon unter einer eigenen Nummer angerufen werden und per PIN den Zugang freischalten. Genau genommen kann die 3rd Party Software sogar per EWS auf das Postfach zugreifen und Mails vorlesen oder dort die MP3-Dateien suchen.
  4. Termine per Sprache steuern
    Ich habe die Funktion bei Exchange nie genutzt aber technisch könnte auch das eine 3rd Party Lösung nutzen

Da Microsoft ja nur die Exchange UM-Rollen On Premises und in der Cloud entfallen lässt, heißt das ja nicht dass Outlook und OWA nicht doch weiterhin MP3-Anlagen wiedergeben können. Alle anderen Funktionen sind außerhalb von Exchange auch weiterhin möglich. Auch in der Vergangenheit gab es schon gute Gründe nicht Exchange UM einzusetzen. Einer war der zusätzliche Kostenaspekt durch die erforderliche Exchange Enterprise CAL. Insofern gibt es einen gut sortierten Markt an 3rd Party Lösungen, die sich per SIP an einen SBC/Gateway anbinden und gerne die verpassten Anrufe über eine SBC Umleitung annehmen.

Weitere Links