CVM Missed Call
Mit dem Wechsel der Sprachaufzeichnung in die Cloud und dem Wechsel nach Teams ändert sich auch etwas das Verhalten für verpasste Anrufe.
Eingehender Anruf
Der eingehende Anruf wird noch ganz normal über die Microsoft Vermittlung oder DirectRouting zum Anwender geleitet und bei Nutzung der Einstellung "HostedVoiceMail:$true" auch über den Skype for Business Edge-Server in die Cloud gemeldet. Cloud Voice Mail sieht den Anruf und folgt der Konfiguration des Anwenders, wann es den Anruf annimmt. Es ist aber genauso häufig der Fall, dass der Anrufer nicht die Geduld aufbringt und seinerseits den Anruf vorzeitig beendet. SIP-technisch kommt dann ein "CANCEL" bei der Infrastruktur an.
Cloud Voice Mail nutzt diese Meldung als Information eines "verpassten Anrufs" und erstellt eine Meldung. Schon hier kommt aber der erste Unterschied. CVM prüft den Teams-Koexistenzmode und verhält sich unterschiedlich:
Teams Mode | Aktionen |
---|---|
Teams Only |
CVM stellt dem Anwender eine Meldung in Teams bereit, dass er einen verpassten Anruf hatte. CVM sendet aber keine E-Mail in das Postfach. |
Sonst |
CMV erstellt eine Mail an das Postfach, welches in der Cloud oder On-Premises liegen kann. Das ist dann wieder egal |
Wer also schon "Teams Only" nutzt, bekommt keine sofortigen Mail mehr. Wenn der Teams-Anwender natürlich länger nicht in Teams aktiv ist, bekommt er schon wieder die üblichen "Sie verpassen etwas in Teams"-Mails.
Skype On-Premises
Aktuell gibt es aber noch sehr viele Kunden, die Exchange und Skype for Business auf eigenen Servern betreiben. Selbst ein Postfach in der Cloud ändert nichts, solange Sie mit Skype for Business arbeiten. CVM kann ihnen in dem Fall keine "Missed Call"-Notification in einen Teams Bereich ablegen, sondern muss eine Mail senden. Sie sollten dazu natürlich ein korrektes Exchange Hybrid Setup haben, damit diese Mails den kurzen verschlüsselten Weg zu ihrem lokalen Exchange Server laufen und nicht über das Internet, MX-Record und Spamfilter geroutet werden. Ein Header meiner Mail sah wie folgt aus (gekürzt um hier nicht relevante EOP/Antispam-Zeilen):
Received: from hybrid.msxfaq.net (192.168.12.12) by ex2016.msxfaq.net (192.168.12.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5 via Mailbox Transport; Mon, 23 Mar 2020 13:24:59 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (104.47.13.58) by hybrid.msxfaq.com (192.168.12.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1913.5; Mon, 23 Mar 2020 13:24:59 +0100 Received: from DB8P191CA0008.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:130::18) by AM6PR08MB3861.eurprd08.prod.outlook.com (2603:10a6:20b:80::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20; Mon, 23 Mar 2020 12:24:58 +0000 Received: from DB5EUR03FT060.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:130:cafe::e1) by DB8P191CA0008.outlook.office365.com (2603:10a6:10:130::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20 via Frontend Transport; Mon, 23 Mar 2020 12:24:58 +0000 Authentication-Results: spf=softfail (sender IP is 52.114.76.82) smtp.mailfrom=msxfaq.com; msxfaq.com; dkim=none (message not signed) header.d=none;msxfaq.com; dmarc=none action=none header.from=; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning msxfaq.com discourages use of 52.114.76.82 as permitted sender) Received: from EUR03B.map.protection.outlook.com (52.114.76.82) by DB5EUR03FT060.mail.protection.outlook.com (10.152.21.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Mon, 23 Mar 2020 12:24:58 +0000 Content-Class: MissedCall X-CallingTelephoneNumber: +49 160 xxxxxxxx X-AzureVoicemail-CallId: <guid1> X-AzureVoicemail-FirehoseActivityId: xxxxxxx X-IsPstnCall: True X-ShareDataEnabled: False To: <frank.carius.ext@msxfaq.com> From: <+49 160 xxxxxxxx> Reply-To: +49 160 xxxxxxxx <noreply@skype.voicemail.microsoft.com> Subject: Verpasster Anruf X-VoiceMessageLanguage: de Priority: normal Content-Type: multipart/mixed; boundary="_002_a4bcd9a515b44b9d8eceb05d7333675fpiotk5m200exchangecorpm_" MIME-Version: 1.0 Message-ID: <guid2>@DB5EUR03FT060.eop-EUR03.prod.protection.outlook.com> Return-Path: noreply_skype_voicemail_<guid1>@msxfaq.com Date: Mon, 23 Mar 2020 12:24:58 +0000 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM6PR08MB3861:Skype X-MS-Oob-TLC-OOBClassifiers: OLM:1728; X-Microsoft-Antispam: BCL:0; X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthSource: TreatMessagesAsInternal-DB5EUR03FT060.eop-EUR03.prod.protection.outlook.com
Beachten Sie dabei folgende Zeilen, die den Hinweis auf CloudVoiceMail geben.
Content-Class: MissedCall X-CallingTelephoneNumber: +49 160 xxxxxxxx X-AzureVoicemail-CallId: <guid1> X-AzureVoicemail-FirehoseActivityId: xxxxxxx X-IsPstnCall: True X-ShareDataEnabled: False To: <frank.carius.ext@msxfaq.com> From: <+49 160 xxxxxxxx> Reply-To: +49 160 xxxxxxxx <noreply@skype.voicemail.microsoft.com> Subject: Verpasster Anruf X-VoiceMessageLanguage: de
Diese Mail landet in meinem Outlook dann als Nachricht mit der Klasse "IPM.Notes.Microsoft.Missed.Voice". Dieser String ist so aber nicht in dem Header enthalten aber wenn Exchange die eingehende Verbindung als "trusted" ansieht, dann setzt Exchange die Content-Class entsprechend auf die MAPI-Klasse um.
Kontrollieren Sie daher in Outlook, dass die Nachrichten von Exchange UM auch tatsächlich in Exchange über die Suchordner gefunden werden. Wenn dies nicht der Fall ist, dann kontrollieren Sie die "Nachrichtenklasse" (Siehe Messageclass) und auch ein Blick den Header "Content-Class" hilft, da Exchange diesen ggfls. anpasst.
Beispiel + Beschreibung | Status |
---|---|
Content-Class: MissedCall X-MS-Exchange-Organization-AuthSource: TreatMessagesAsInternal-VExxx.eop-EUR01.prod.protection.outlook.com Wenn diese Content-Class unverändert bis in Outlook erhalten bleibt, dann sollte die UM-Message auch entsprechend ankommen und im richtigen Suchordner des Postfachs erscheinen. Der Server im Feld "X-MS-Exchange-Organization-AuthSource" in der vertrauenswürdigen Übertragungskette ist hier ein Exchange Online Server. Alle Zwischenstationen waren also sauber verkettet. |
OK |
Content-Class: unauthenticated,MissedCall X-MS-Exchange-Organization-AuthSource: edge.msxfaq.de Auf dem Weg zu ihrem Exchange Server wurde eine "unsichere Verbindung" genutzt, so dass der empfangende Server die Mail nicht mehr als vertrauenswürdig ansieht. In dem Beispiel waren die Connectoren auf dem Edge Server nicht passend konfiguriert. Der Server im Feld "X-MS-Exchange-Organization-AuthSource" ist hier mein Edge-Server. Er hat also der eingehenden Verbindung von Office 365 nicht "vertraut" und daher sich als "erste vertrautes System" eingetragen. Der Fehler ist also hier vergraben und schnell gefunden. Schauen Sie sich den "Receive Conector" an, ob er die richtigen TLS capabilities hat. Es sollte folgendes drin stehen. [PS] C:\>Get-ReceiveConnector | select tlsdomaincapabilities Domain : mail.protection.outlook.com Capabilities : AcceptCloudServicesMail |
Fehler |
Diese Zuordnungen gibt es natürlich auch für die anderen Klassen:
Klasse | Nachrichtenklasse | Heaer |
---|---|---|
Voicemail |
IPM.Note.Microsoft.UM.CA |
X-AttachmentOrder: audio.mp3 X-VoiceMessageDuration: 8 Content-Class: Voice-CA X-CallingTelephoneNumber: +49 160 xxxxxxxx X-IsPstnCall: True X-ShareDataEnabled: True X-VoiceMessageLanguage: de X-AzureVoicemail-TranscriptionRequestId: <guid> X-VoiceMessageTranscription: =?utf-8?b?SmEsIEhlxxx= X-VoiceMessageTranscriptionLanguage: de-DE X-VoiceMessageConfidenceLevel: high X-VoiceMessageInitialSilence: False |
Missed Call |
IPM.Notes.Microsoft.Missed.Voice |
Content-Class: MissedCall X-CallingTelephoneNumber: +49 160 xxxxxxxx X-IsPstnCall: True X-ShareDataEnabled: False X-VoiceMessageLanguage: de |
Verpasste Unterhaltung |
IPM.Notes.Microsoft.Missed |
Kein Header, da durch SfB abgelegt |
Erst wenn die Mails auch im Suchordner von Outlook erscheinen, kann der nächste Schritt funktionieren.
- Messageclass
- 2.2.2.1 Message Classes
https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxoum/102b3a8b-1aad-4f29-90a3-998262d9fa26 - 1.1 Glossary: Missed Call Notification
https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxoum/7f02aeef-6cd9-4665-83fc-064d22c0f0bd#gt_cf6375e3-8bd7-480a-9c7a-2cfc2cea70a0
Skype for Business Client und Voice Mail
Nochmal: wer schon Teams mit "Teams Only" als Betrieb nutzt, muss hier nicht weiter lesen. Alle anderen Anwender mit Skype for Business sollten aber wissen, dass der Skype for Business Client natürlich per Autodiscover und EWS auf der Suche nach dem Postfach des Anwenders ist und genau hier drin auch die Mails per EWS sucht. Damit das schnell geht, sucht der Client nicht den Posteingang ab, sondern bedient sich ganz genau der "Such Ordner" in Exchange/Outlook. Das können Sie mit Fiddler auch sehr gut sehen.
Der Payload dieses Request enthält die "vordefinierten" Suchordner, von denen "Voicemail" noch ein vordefinierter Eintrag ist aber die anderen beiden Ordner nur über eine ID erfragt werden.
In der Antwort können Sie dann aber die Displayname der Ordner sehen:
Hier sehen Sie auch, dass ich zwei Sprachnachrichten, fünf verpasste Unterhaltungen und zwei verpasste Anrufe habe. Nachfolgenden EWS-Abrufen liest der Skype for Business Client die Details zu diesen Vorgängen um diese dann dem Anwender auch anzuzeigen.
Wenn sie daher in Outlook die Elemente finden und Skype for Business diese nicht anzeigt, dann ist eine genauere Analyse mit Fiddler angebracht.