Planet Collab

🔒
❌ About FreshRSS
There are new available articles, click to refresh the page.
Yesterday — August 19th 2019Your RSS feeds

Cant install Office Web App Server 2013 on Windows Server 2012R2

By Dino Caputo

You attempt to install Office Web App Server 2013 on a machine running Windows Server 2012R2 that has had all its windows updates applied and get the following error:

image

Expert TIP:  This issue has come up before and there are a few blog sites that refer to it however the recommended fix has become outdated.  The workaround involves uninstalling a patch so I will show you how to solve this yourself as over time even the example I show you will become dated.

Assuming you have followed the pre-requisites for installing the Office Web Apps Server and have installed .NET 45, the issue is that a newer version of .NET 4.5 has been installed due to server patching.  This effectively blocks the installation of Office Web Apps Server and results in the error above.

Find out what version of .NET is installed on your server

In this case I dumped the version of .NET installed on the server using the following cmd:

Get-ItemProperty -Path “HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full” | Format-List Release

image

This shows that release 461814 is installed.  Some searching shows that this is .NET 4.7.2 – see https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed#net_b for full list of versioning.

This means we need to uninstall .NET 4.7.2 before we can install Office Web Apps Server. 

Some further searching shows what KB corresponds with .NET 4.7.2.

https://support.microsoft.com/en-ca/help/4054530/microsoft-net-framework-4-7-2-offline-installer-for-windows 

In this case its KB4054566. 

Uninstalling the .NET patch

So we must uninstall that patch, reboot the machine and we should be good to go to install Office Web Apps Server.

Goto Add/Remove programs and select uninstall an update.  Search for KB4054566 and uninstall it and reboot the server

image

After the restart, if you run the same cmdlet you will see the version is now 378675 which corresponds to .NET 4.5.1. 

image

You will now be able to install Office Web Apps Server!

image

  • August 19th 2019 at 10:55

Project HDMI Switcher Part 3 - The Macro

This is really where the pedal hits the medal and we start pulling our solution together. But before we get started if you didn't catch the previous posts take a look here:

Part 1 - Introduction

http://voipnorm.blogspot.com/2019/08/project-hdmi-switcher-part-1.html

Part 2 - In-room control

https://voipnorm.blogspot.com/2019/08/project-hdmi-switcher-part-2-touch-10.html

The macro framework on CE based devices (Webex Room Kits and such) as you should hopefully know by now is javascript based. There are two main functions to our script. This first is listenToGui and the second is switchHDMI.  ListenToGui takes input via the events generated by the widgets on the Touch 10 which then calls switchHDMI to send the HTTP GET request to the HDMI Switch IP interface which then switches HDMI inputs. Once you look at the script below you will see just how simple it really is.

--Script--

Your URL if using a different HDMI switch will differ of course but should be documented by the manufacturer if the switch is IP controllable. In my case  the ${source}AVx1 on line 6 is just the id of the widget we created in the last post. By using simple id's to identify each of the inputs we are able to keep our code simple as the HDMI switch uses the same identification to assign input ports.

Next up HDMI switch setup and final thoughts.

VoIPNorm


Change CUCM IP Address Cisco

By Administrator

Change CUCM IP Address Cisco

Changing the IP Address in Cisco Unified Communication Manager sounds very easy but this most crucial part as it may end up in dbreplication failures where you might encounter issues like “Database Communication Error”.  So, we have to be very careful when performing the steps. Please take a backup of your Cluster before performing the below steps.

Ensure that the Cluster is Healthy:

  • Login to CLI and check for dbreplication between the clusters and ensure that it is Good. Login to CLI and enter show perf query class “Number of Replicates Created and State of Replication”. If you have just Publisher you would see the Value as 0 or if you have Publisher + Subscribers you have to ensure you see the value to be 2 which means Good.

uccollabing
Change the IP Address in CUCM Admin Page

  • Login to CUCM  Publisher Admin Page GUI >
  • Go to System > Server > Click on the IP Address for which you want to change into a New IP Address.
  • Host Name/IP Address > Enter the IP Address of the Publisher/Subscriber and click on Save
  • Login to CUCM CLI > Enter “run sql select name,nodeid from ProcessNode” and ensure that you see the New IP Address in the Output table for the Publisher/Subscriber IP you have changed. If you don’t see the changes reflected yet, wait for sometime and verify it again. On successful verification only, go to the next step.

Change the IP Address in the OS Admin CLI

  • Login to the CLI of Publisher/Subscriber for which you have changed the IP Address in the above steps.
  • Configure the Default Gateway > set default gateway x.x.x.x
  • Change the IP Address of the Server > set network ip eth0 x.x.x.x  x.x.x.x  x.x.x.x         (First set of x.x.x.x is IP address, Second set of x.x.x.x is Subnet Mask and third set of x.x.x.x is the Gateway IP Address)
  • Enter “Y” to continue and restart and Publisher/Subscriber for which you have just changed the IP Address

Change the IP Address of Publisher Servers on Subscribers (**This is applicable only when you have changed the Publisher IP Address**)

  • Login to Subscriber > Enter the command “set network cluster publisher ip x.x.x.x”    (x.x.x.x represents Publisher IP Address)
  • Reboot your subscribers

Once the above steps are performed, wait for some time and verify DBReplication on your Publisher Server.
Hope this helps!!

Published by Team UC Collabing

The post Change CUCM IP Address Cisco appeared first on UC Collabing.

CUCM: TLS 1.2 and Legacy Phones

By Justin

Hello world!

Today’s post will be quick and dirty but hopefully useful.

In Cisco Call Manager (CUCM) version 11.5(1)SU3 support was introduced for Transport Layer Security (TLS) versions 1.1 and 1.2. Prior to this release 1.0 was the only supported version. With security being the driving factor in much of the IT world these days, there is a push to secure everything to the highest available level, that includes the Collaboration environment. I have many customers that want to take advantage of the higher TLS version levels and that is a good thing, but there are gotchas.

If you know anything about Cisco IP phone communications you know that several services; and specifically the Corporate and Personal directory service are pre-configured applets that run between the phone and CUCM. In the case of the directory service(s) they talk using 8443 which is a secure port and thus uses a certificate to communicate (along with the Trust Verification Service (TVS)). That certificate is directly encrypted with the help of TLS. Because support for the newer/higher TLS versions has only recently come into play there are several generations of IP phones that do not support anything above TLS 1.0 (or 1.1 in some cases). This list of legacy endpoints includes the 7900 series and Cisco’s previous “Cadillac” the 9900 series as well as others.

If you have legacy endpoints and change your TLS version to something above 1.0 you will notice that the directory services on those endpoints will fail with a “Host not found” error. What is actually happening involves a failed TLS handshake between the phone and the Trust Verification Service (TVS) on CUCM. Because the phone cannot communicate with the TVS using TLS 1.2 the handshake fails and the directory service cannot be accessed.

So what are your options?

  1. Replace your legacy phones, there is always a financial fix and this is it.
  2. You can manually create a directory service that talks HTTP and assign it to the phones. You could make this an Enterprise Subscription if you want everyone to use it. The URL that you should use is: http://YOURCUCMFQDNorIPHere:8080/ccmcip/xmldirectory.jsp. Since this is an HTTP service you can use the IP instead of the FQDN. This will allow the service to function whether name services are functional or not. This will require user training but may make the most sense depending on the environment.
  3. Revert to TLS 1.0. This sounds easy, but there are gotchas here too.

The gotchas of going back…

Switching from TLS 1.0 to TLS 1.1 or 1.2 (If you are going to change, go to 1.2) is a relatively straight forward process. You log into the platform CLI of your CUCM publisher and any subscribers and issue the following command set tls min-version 1.2. When you enter this command you will be asked to confirm and once confirmed (with yes) the system will restart. This happens immediately and should only be done during a maintenance window.

Switching back from TLS 1.2 to 1.0 follows the same steps with the same command and the same reboot process. However, when you switch back from a higher TLS version to a lower TLS version, anything that was encrypted using that higher TLS version becomes invalid. This includes certificates (which automatically regenerate) and also the application UI password store  (including your CCM Administration credential). This password must be reset from the CLI and changed to something different before you can log into the system again. Note that this does not change your Prime License Manager (PLM) admin password if co-resident with your CUCM.

Security is important and continually making our security better is the only way to prevent incidents. With that said, proper planning will stop security changes from turning into outages.

Cisco’s TLS 1.2 Compatibility Matrix: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/uc_system/unified/communications/system/Compatibility/TLS/TLS1-2-Compatibility-Matrix.html

Before yesterdayYour RSS feeds

Configure Call Handler Cisco Unity Connection

By Administrator

Configure Call Handler Cisco Unity Connection

Call Handlers in Cisco Unity Connection is a feature which provides services like IVR where the calls are handled and routed in an efficient manner. Basically Call Handler serves many purposes like answer the call, greet the caller, provide them information with options, routes the call, take messages and much more.

Example: – Let’s say we have a customer who generally calls us on our Board Number. The customer wants to talk to various departments like Finance, Security, IT department and Customer care on difference occasions. So, when he/she dials the board number, he will be greeted with a welcome greeting, then it will ask the customer if the customer wants to reach to Finance, Security, IT Department or Customer? Upon customer selection on the category he chooses, the call will be routed accordingly.

Call Flow: – Call comes on the gateway ==> Call routed to CUCM ==> Call routed to CUC ==> Checks the schedule if holiday/working/out of business hours ==> Take necessary actions accordingly.

Lets implement it.

Pre-requirements:-

1. Integration between Cisco Unified Communication Manager and Cisco Unity Connection: –

2. You will need 3 Prompts: –

a. Opening Hours Greeting + Menu Greeting in same WAV file.

b. Closed Hours Greetings

c.  Holiday Greetings

If you don’t have prompts, you can create prompts from the link here : Text To Speech Free

Configuration in CIsco Unified Communication Manager: 

********** Configuration of Line Group **********

1. Go to Call Routing ==> Route/Hunt ==> Line Group ==> Add New

Line Group Name: – Customer Response Solution LG

RNA:- 10

Distribution Algorithm: – Top Down

Available DN/Route Partition: – Select voicemail ports configured

Click on Save

Click Add Line Group

Line Group* – Select Customer Response Solution LG from Drop Down Menu

Click on Save

Click on Save

CallHandler-CUCM-LineGroup

********** Configuration of Hunt List **********

2. Go to Call Routing ==> Route/Hunt ==> Hunt List ==> Add New

Name: – Customer Response Solution HL

Description: – Customer Response Solution Hunt List

CUCM Group: – Select appropriate CUCM from the Drop down list.

Check Mark : – Enable this Hunt List (change effective on Save; no reset required)
Check Mark : – For Voice Mail Usage

Click on Save

CallHandler-CUCM-HuntList

********** Configuration of Hunt Pilot **********

3. Go to Call Routing ==> Route/Hunt ==> Hunt Pilot ==> Click on Add New

Hunt Pilot ==> Enter the number which should be triggered to Cisco Unity Connection

Route Partition ==> Select appropriate Route Partition based on your Calling Privileges and directory numbers.

Hunt List : – Select Customer Response Solution HL from Drop Down

Click on Save

CallHandler-CUCM-HuntPilot

Configuration in Cisco Unity Connection:

********** Configuration of Holiday Schedule**********

1. Go to System Settings ==> Holiday Schedules ==> Add New

Display Name : – Customer Response Schedule – Holiday Schedule 

Click on Add New : –

Holiday Name : – Diwali

Start Date : –

End Date : –

Click on Save

CallHandler-CUC-Holiday-Schedule

********** Configuration of Schedules like Working Hours / Non Working Hours**********

2. Go to System Settings ==> Schedules ==> Add New

Dispaly Name: – Customer Response Solution

Holiday Schedule: – Customer Response Schedule – Holiday Schedule

Click on Save

Add a new Schedule Detail : – Click on Add New

Name : – Working Hours

Start Time : – 8 : 30 : AM

End Time : – 5: 00 : PM

Check Mark : – Active Weekdays

Click on Save

CallHandler-CUC-Schedules

********** Configuration of Call Handlers **********

********** Adding a Call Handler **********

3. Go to Call Management ==> System Call Handlers ==> Add New

Display Name : – Customer Response Solutions

Click on Save

Phone System ==> Make sure that you select you Voicemail Phone System where Ports are associated

Active Schedule ==> Select Customer Response Solution

Click on Save

CallHandler-CUC-CallHandler

********** Configuration of Welcome Greetings **********

Go to Edit Greeting ==> Check Mark Holiday and Closed and Click on Save

CallHandler-CUC-Checkmark

Click on Standard ==>

Radio Check My Personal Greeting

Times to re-prompt caller ==> 3

Delay between re-prompts ==> 5

After Greeting Hang Up

Click on Play/Record and select the appropriate Welcome Greeting by selecting a .wav file

CallHandler-CUC-Standard-Greeting

** In my scenario, i have merged Welcome Greeting + Menu options in the save WAV file**

(Welcome to XYZ Company. Press 1 for Finance, Press 2 for Administrator, Press 3 for IT Department and Press 4 for Security)

********** Configuration of Closed Hours Greetings **********

Click on Closed ==>

Radio Check My Personal Greeting

Times to re-prompt caller ==> 0

Delay between re-prompts ==> 0

After Greeting Hang Up

Click on Play/Record and select the appropriate Closed Hours Greeting by selecting a .wav file

CallHandler-CUC-Closed-Greeting

********** Configuration of Holiday Greetings **********

Click on Holiday ==>

Radio Check My Personal Greeting

Times to re-prompt caller ==> 0

Delay between re-prompts ==> 0

After Greeting Hang Up

Click on Play/Record and select the appropriate Holiday Greeting by selecting a .wav file

CallHandler-CUC-Closed-Greeting

********** Configuration of Menu Selection **********

CallHandler-CUC-Caller-Input

Go to Edit ==> Caller Input ==> Click on 1

Call Action ==> Transfer to Alternate Contact Number

Extension ==> Extension Number for Finance Department

Description ==> Call Transfer to Finance Department

Go to Edit ==> Caller Input ==> Click on 2

Call Action ==> Transfer to Alternate Contact Number

Extension ==> Extension Number for Administrator Department

Description ==> Call Transfer to Administrator Department

Go to Edit ==> Caller Input ==> Click on 3

Call Action ==> Transfer to Alternate Contact Number

Extension ==> Extension Number for IT Department

Description ==> Call Transfer to IT Department

Go to Edit ==> Caller Input ==> Click on 4

Call Action ==> Transfer to Alternate Contact Number

Extension ==> Extension Number for Security

Description ==> Call Transfer to Security

CallHandler-CUC-Caller-Input-Number

********** Configuration of Direct Routing Rule**********

4. Go to Call  Management ==> Call Routing ==> Direct Routing Rules ==> Click on Add New

Display Name : – Customer Response Solution  – Direct Routing Rule

Radio Check : – Send call to : Call Hander : Customer Response Solutions

Click on Save

Add New Routing Rule Condition

Radio Check : Dialed in number = in       XXXXXX (The Hunt Pilot configured in CUCM)

Click on Save

CallHandler-CUC-Direct-Routing-Rule

********** ********** ********** End of Configuration ********** ********** **********

You are done with the Call Handler setup and now ready to receive calls. There are various ways to achieve customer’s requirement in Cisco Unity Connection and do necessary modifications as per your requirement.

If you are looking for Text to Speech Converter that converts to an Audio WAV file into the recommended format, follow below link:

Convert Text to Speech Online Free

Hope this helps!

Published by Team UC Collabing

The post Configure Call Handler Cisco Unity Connection appeared first on UC Collabing.

RFC 8576: Internet of Things (IoT) Security: State of the Art and Challenges

By Stéphane Bortzmeyer

Une blague très courante dit que, dans IoT (Internet of Things, l'Internet des Objets), le S veut dire sécurité… C'est peu dire que la sécurité de l'Iot est mauvaise. Elle est en fait catastrophique, comme l'analyse bien Schneier dans son livre « Click here to kill everybody ». C'est en grande partie dû à des raisons politico-économiques (les fabriquants se moquent de la sécurité notamment, parce que les failles de sécurité n'ont aucune conséquence négative pour eux) et en petite partie aux réelles difficultés techniques qu'il y a à sécuriser des objets qui sont parfois contraints en ressources (énergie électrique limitée, par exemple.) Ce nouveau RFC du groupe de recherche T2T (Thing to Thing) de l'IRTF se penche sur la question et essaie d'identifier les questions à long terme. À lire absolument, si vous vous intéressez à la sécurité des objets connectés. Et à lire également si vous ne vous y intéressez pas car, que vous le vouliez ou non, la sécurité des objets connectés va vous impacter.

On ne part pas de zéro pourtant. Contrairement à ce que disent parfois les vendeurs d'objets connectés pour justifier l'insécurité abyssale de leurs produits, des solutions techniques ont été développées. (Voir par exemple cet article qui parle de la sécurité des sondes Atlas.) Il existe des protocoles adaptés aux objets, comme CoAP (RFC 7252), une alternative légère à HTTP, qu'on peut sécuriser avec DTLS (RFC 6347). Mais il reste à les déployer.

Notre RFC suit un plan classique : il étudie d'abord le cycle de vie des objets connectés (section 2 du RFC), examine ensuite les risques (section 3), l'état de l'art (section 4), puis les défis pour sécuriser les objets (section 5), et enfin les prochaines étapes du travail nécessaire (section 6).

Le terme d'Internet des Objets fait partie de ces termes pipeau qui ne veulent pas dire grand'chose. Les « objets » n'ont pas grand'chose à voir, allant d'un ordiphone plus puissant que certains ordinateurs, à des étiquettes RFID, en passant par des voitures connectées qui disposent d'électricité et de puissance de calcul considérables, et des capteurs industriels qui sont au contraire très contraints. Quant à leur connexion, elle se limite parfois au réseau local et, parfois, à envoyer toutes leurs données, aussi privées qu'elles soient, vers leur maitre dans le mythique cloud. C'est le consortium privé Auto-Id qui a popularisé ce terme à la fin des années 1990, pour de simples raisons marketing. À l'époque, c'était limité à des étiquettes RFID n'ayant qu'une connexion très limitée, sans rapport avec l'Internet. Certains ont suggéré de réserver le terme d'« Internet des Objets » aux objets connectés en IP mais ces appels à la rigueur terminologique n'ont en général que peu d'impact. Bref, chercher des solutions pour l'« Internet des Objets » en général n'a que peu de chances d'aboutir, vu la très grande variété de situations que ce terme recouvre.

Mais revenons au début, au cycle de vie de nos objets connectés (section 2 du RFC). Comme la variété des objets connectés est très grande, le RFC choisit de partir d'un exemple spécifique, un système de gestion de bâtiment. Ce système contrôle l'air conditionné, le chauffage, la ventilation, l'éclairage, la sécurité, etc. Un tel système représente de nombreux objets, dont certains, notamment les capteurs installés un peu partout, peuvent être très contraints en ressource (processeur lent, énergie fournie uniquement par des batteries, etc). Pire, du point de vue des protocoles réseau, certains de ces objets vont passer beaucoup de temps à dormir, pour économiser l'énergie, et ne répondront pas aux autres machines pendant ce temps. Et les objets seront sans doute fabriqués par des entreprises différentes, ce qui soulèvera des questions amusantes d'interopérabilité.

La figure 1 du RFC représente un cycle de vie simplifié. Je le simplifie encore ici. L'objet est successivement :

  • fabriqué,
  • il peut rester assez longtemps sur l'étagère, attendant un acheteur (ce qui contribue à l'obsolescence de son logiciel),
  • installé et configuré (probablement par différents sous-traitants),
  • mis en service,
  • il va fonctionner un certain temps puis verra des évenements comme une mise à jour logicielle,
  • ou des changements de sa configuration,
  • à un moment, il cessera d'être utilisé,
  • puis sera retiré du bâtiment (à moins qu'il soit oublié, et reste actif pendant des années sans qu'on s'en occupe),
  • mais il aura peut-être droit à une reconfiguration et une remise en service à un autre endroit, recommençant le cycle,
  • sinon, il sera jeté.
Les différents objets présents dans le bâtiment ne seront pas aux mêmes étapes au même moment.

Le RFC remarque que le cycle de vie ne commence pas forcément à la fabrication de l'objet physique, mais avant. Pour des objets comportant du logiciel, le cycle de vie commence en fait lorsque la première bibliothèque qui sera utilisée est écrite. Les logiciels des objets connectés ont une forte tendance à utiliser des versions anciennes et dépassées des bibliothèques, notamment de celles qui assurent des fonctions de sécurité. Les bogues ont donc une longue durée de vie.

La sécurité est une question cruciale pour les objets connectés, car ils sont en contact avec le monde physique et, si ce sont des actionneurs, ils agissent sur ce monde. Comme le note Schneier, une bogue sur un objet connecté, ce n'est plus seulement un programme qui plante ou un fichier qu'on perd, cela peut être des atteintes physiques aux humains. Et les objets sont nombreux : pirater une machine ne donne pas beaucoup de pouvoir à l'attaquant, mais s'il arrive à trouver une faille lui permettant de pirater via l'Internet tous les objets d'un vendeur donné, il peut se retrouver à la tête d'un botnet conséquent (c'est exactement ce qui était arrivé avec Mirai).

Quels sont les risques exactement ? La section 3 du RFC décrit les différentes menaces, une liste longue et un peu fourre-tout. Avant tout, le code peut être incorrect, bogué ou mal conçu. C'est le cas de tout logiciel (ne croyez pas un instant les commerciaux qui assurent, sans rien en savoir eux-mêmes, que « le logiciel est conforme à l'état de l'art et aux préconisations de [insérer ici le nom d'un organisme quelconque] »). Mais comme vu plus haut, les conséquences sont plus graves dans le cas des objets connectés. En outre, il y a deux problèmes logiciels qui sont davantage spécifiques aux objets connectés : les mises à jour, pour corriger les bogues, sont plus difficiles, et rarement faites, et le logiciel est globalement négligé, n'étant pas le « cœur de métier » de l'entreprise vendeuse. On voit ainsi des failles de sécurité énormes, qui n'arrivent plus dans l'informatique plus classique.

Autre raison pour laquelle la sécurité des objets connectés est difficile à assurer, le fait que l'attaquant peut avoir un accès physique aux objets (par exemple s'il s'agit d'un type d'objet vendu publiquement). Il peut le démonter, l'étudier, et acquérir ainsi des informations utiles pour le piratage d'autres objets du même type. Si, par exemple, tous les objets d'un même type partagent une clé cryptographique privée, elle pourrait être récupérée ainsi (l'objet connecté typique n'est pas un HSM). Un modèle de sécurité comme celui de la boite noire ne s'applique donc pas. Dans le futur, peut-être que les PUF seront une solution ?

La sécurité impose de mettre à jour le logiciel de l'objet régulièrement. Mais cette mise à jour ouvre elle-même des failles de sécurité. Si le processus de mise à jour n'est pas sécurisé (par exemple par une signature du logiciel), un malveillant pourra peut-être y glisser sa version du logiciel.

Ensuite, l'objet, même s'il fonctionne comme prévu, peut faire fuiter des informations privées. S'il envoie des informations à des tiers (c'est le cas de presque tous les objets conçus pour l'usage domestique) ou s'il transmet en clair, il permet la surveillance de son propriétaire. Le chiffrement est évidemment indispensable, mais il ne protège pas contre les extrémités de la communication (le sextoy connecté qui envoie les informations sur son usage au vendeur de l'objet) et, s'il n'est pas accompagné d'une authentification du partenaire avec qui on communique, ile ne protège pas contre l'homme du milieu. Une des difficultés de l'authentification est qu'il faut bien, avant la communication, avitailler l'objet en informations (par exemple les clés publiques de ses correspondants), un défi pour des objets fabriqués en masse. Avitailler une fois l'objet sur le terrain est tout aussi difficile : ces objets n'ont souvent pas d'interface utilisateur. Cela impose des solutions comme le TOFU (faire confiance la première fois, puis continuer avec le même correspondant) ou bien l'appairage (on approche deux objets, on appuie sur un bouton et ils sont désormais appairés, ils ont échangé leurs clés).

Les objets ont souvent une histoire compliquée, étant composée de l'assemblage de divers composants matériels et logiciels, parfois promenés sur de longues distances, entre beaucoup d'entreprises différentes. Une des attaques possibles est de s'insérer quelque part dans cette chaîne d'approvisionnement et d'y glisser du logiciel ou du matériel malveillant. Est-ce que quelqu'un sait vraiment ce que fait cette puce dont on a acheté des dizaines de milliers d'exemplaires à un revendeur ? Dans le cas extrême, c'est l'objet entier qui peut être remplacé par un objet apparemment identique, mais malveillant.

Les objets connectés sont souvent dans des lieux qui ne sont pas physiquement protégés. Par exemple, les capteurs sont placés un peu partout, et parfois accessibles à un attaquant. Une fois qu'on peut mettre la main sur un objet, il est difficile d'assurer sa sécurité. Des informations confidentielles, comme une clé privée, peuvent alors se retrouver entre les mains de l'attaquant. Transformer chaque objet connecté en un coffre-fort inviolable n'est évidemment pas réalistes.

Les objets communiquent entre eux, ou bien avec des passerelles les connectant à l'extérieur. Cela ouvre de nouvelles possibilités d'attaque via le routage. Les objets connectés se servent souvent de protocoles de routage non sécurisés, permettant au malveillant d'injecter de fausses routes, permettant ainsi, par exemple, de détourner le trafic vers une machine contrôlée par ce malveillant.

Enfin, il y a la menace des attaques par déni de service. Les objets sont souvent contraints en ressources et sont donc particulièrement vulnérables aux attaques par déni de service, même légères. Et les objets ne sont pas forcément victimes, ils peuvent être aussi devenir zombies et, recrutés par un logiciel malveillant comme Mirai, être complices d'attaques par déni de service comme cela avait été le cas en octobre 2016. (Un outil comme Shodan permet de trouver facilement des objets vulnérables et/ou piratés.)

Bon, ça, c'étaient les menaces. Mais on n'est pas resté les bras ballants, on a déjà des mécanismes possibles pour faire face à ces attaques. La section 4 de notre RFC décrit l'état de l'art en matière de connexion des objets connectés, et de leur sécurisation.

Déjà, il existe plusieurs protocoles pour les objets connectés, comme ZigBee, BACnet ou DALI. Mais l'IETF se focalise évidemment sur les objets qui utilisent IP, le seul cas où on puisse réellement parler d'« Internet des Objets ». IP tel qu'il est utilisé sur les ordinateurs classiques n'est pas forcément bien adapté, et des groupes ont développé des adaptations pour les réseaux d'objets (voir par exemple le RFC 4944). De même, il existe des normes pour faire tourner IP sur des tas de couches physiques différentes, comme Bluetooth (RFC 7668), DECT (RFC 8105) ou NFC (RFC pas encore publié). Au-dessus d'IP, le protocole CoAP (RFC 7252) fournit un protocole applicatif plus adapté aux objets que le HTTP classique.

Questions formats, on a également le choix. On a JSON (RFC 8259), mais aussi CBOR (RFC 7049) qui, lui, est un format binaire, sans doute plus adapté aux objets contraints. Tous les deux ont des solutions de sécurité, par exemple la famille JOSE pour signer et chiffrer les documents JSON, et son équivalent pour CBOR, CORE (RFC 8152).

Le problème de la sécurité de l'IoT est connu depuis longtemps, et ce ne sont pas les solutions techniques qui manquent, que ce soit pour protéger les objets connectés, ou pour protéger le reste de l'Internet contre ces objets. Certains de ces protocoles de sécurité ne sont pas spécifiques aux objets connectés, mais peuvent être utilisés par eux, c'est le cas de TLS (RFC 8446). Une excuse classique des fabricants d'objets connectés pour ne pas sécuriser les communications avec TLS est le caractère contraint de l'objet (manque de ressources matérielles, processeur, mémoire, énergie, etc). Cet argument peut jouer pour des objets vraiment contraints, des capteurs bon marché disséminés dans l'usine et ne fonctionnant que sur leur batterie mais beaucoup d'objets connectés ne sont pas dans ce cas, et ont largement les moyens de faire tourner TLS. Quand on entend des fabriquants de télévisions connectées ou de voitures connectées expliquer qu'ils ne peuvent pas utiliser TLS car ce protocole est trop coûteux en ressources, on rit ou on s'indigne car c'est vraiment un argument ridicule ; une télévision ou une voiture ont largement assez de ressources pour avoir un processeur qui fait tourner TLS. (Je n'utilise que TLS et SSH pour communiquer avec un Raspberry Pi 1, avec son processeur à 700 Mhz et sa consommation électrique de 2 W.)

Outre les protocoles, la sécurité repose sur des règles à suivre. La section 4.3 liste les règles formalisées existantes. Ainsi, GSMA a publié les siennes, BITAG également, le DHS étatsunien s'y est mis, l'ENISA aussi et notre RFC liste de nombreux autres documents. Si les fabriquants d'objets connectés ne sont pas au courant, ce n'est pas faute d'information, c'est bien de la mauvaise volonté !

C'est d'autant plus grave que, comme l'a illustré le cas de Mirai, les objets connectés non-sécurisés ne sont pas un problème que pour le propriétaire de l'objet, mais peuvent également impacter tout l'Internet. Il est donc logique que beaucoup de voix s'élèvent pour dire qu'il faut arrêter de compter sur la bonne volonté des fabricants d'objets connectés, qui ont largement démontré leur irresponsabilité, et commencer à réguler plus sévèrement. (C'est par exemple une demande du régulateur étatsunien FCC.)

Cette disponibilité de très nombreuses solutions techniques ne veut pas dire que tous les problèmes sont résolus. La section 5 du RFC fait ainsi le point sur les défis qui nous restent, et sur lesquels chercheu·r·se·s et ingénieur·e·s devraient se pencher. D'abord, certains objets sont contraints en ressources (pas tous, on l'a vu), comme détaillé dans le RFC 7228. L'Internet est un monde très hétérogène, connectant des machines ayant des ressources très diverses, via des réseaux qui ont des capacités hautement variables. Pour ces objets contraints (qui sont une partie seulement des « objets », une caméra de vidéo-surveillance n'est pas un objet contraint), il est raisonnable de chercher à optimiser, par exemple la cryptographie. Ainsi, la cryptographie à courbes elliptiques (RFC 8446) demande en général moins de ressources que RSA.

Les attaques par déni de service sont un autre défi pour les objets connectés, qui disposent de peu de ressources pour y faire face. Des protocoles qui permettent de tester qu'il y a une voie de retour (return routability ou returnability) peuvent aider à éviter certaines attaques que des protocoles sans ce test (comme le DNS ou comme d'autres protocoles fondés sur UDP) rendent facile. C'est pour cela que DTLS (RFC 6347) ou HIP (RFC 7401) intègrent ce test de réversibilité. Évidemment, cela n'aide pas pour les cas de la diffusion, ou bien lorsque le routage est contrôlé par l'attaquant (ce qui est souvent le cas dans les réseaux « mesh ».) Autre protection, qui existe par exemple dans HIP : forcer l'initiateur d'une connexion à résoudre un problème, un « puzzle », afin d'éviter que les connexions soient « gratuites » pour l'initiateur. La principale limite de cette solution est qu'elle marche mal si les machines impliquées ont des capacités de calcul très différentes (un objet contraint contre un PC). Il y a également le cas, non mentionné par le RFC, où l'attaquant dispose d'un botnet et ne « paie » donc pas les calculs.

L'architecture actuelle de l'Internet n'aide pas au déploiement de certaines solutions de sécurité. Ainsi, un principe de base en sécurité est d'avoir une sécurité de bout en bout, afin de ne pas dépendre d'intermédiaires malveillants ou piratés, mais c'est rendu de plus en plus difficile par l'abus de middleboxes, qui interfèrent avec beaucoup de comunications. On est donc forcés d'adapter la sécurité à la présence de ces middleboxes, souvent en l'affaiblissant. Par exemple :

  • Il faut parfois partager les clés avec les middleboxes pour qu'elles puissent modifier les paquets, ce qui est évidemment une mauvaise pratique,
  • Le chiffrement homomorphe peut aider, en permettant d'effectuer certaines opérations sur des données chiffrées, mais toutes les opérations ne sont pas possibles ainsi, et les bibliothèques existantes, comme SEAL, n'ont pas les performances nécessaires,
  • Remonter la sécurité depuis le niveau des communications (ce que fait TLS) vers celui des données échangées pourrait aider. C'est ce que font COSE (RFC 8152), JOSE (RFC 7520) ou CMS (RFC 5652).

Une fois déployés, les objets connectés vont rester en fonctionnement des années, voire des décennies. Il est donc crucial d'assurer les mises à jour de leur logiciel, ne serait-ce que pour réparer les failles de sécurité qui ne manqueront pas d'être découvertes, qu'elles soient dans le code ou dans les algorithmes utilisés. Par exemple, si les promesses des ordinateurs quantiques se concrétisent un jour, il faudra jeter RSA et les courbes elliptiques (section 5.8 du RFC).

Mais assurer des mises à jour sûres n'est pas facile, comme le note Bruce Schneier. C'est que le processus de mise à jour, s'il est insuffisamment sécurisé, peut lui-même servir pour une attaque, par exemple en envoyant du code malveillant à un objet trop naïf. Et puis comment motiver les vendeurs à continuer à fournir des mises à jour logicielles des années après que le dernier exemplaire de ce modèle ait été vendu ? Capitalisme et sécurité ne vont pas bien ensemble. Et il se peut tout simplement que le vendeur ait disparu, que le code source de l'objet ne soit plus disponible, et qu'il soit donc impossible en pratique de développer une mise à jour. (D'où l'importance, même si le RFC ne le dit pas, du logiciel libre.) Enfin, si la mise à jour doit être effectuée manuellement, il est probable qu'elle ne sera pas faite systématiquement. (Un rapport de la FTC états-unienne détaille également ce problème.)

Mais les mises à jour automatiques posent également des tas de problèmes. Par exemple, pour des ampoules connectées (une idée stupide, mais le monde de l'IoT est plein d'idées stupides), il vaut mieux mettre à jour leur logiciel le jour que la nuit. Et il vaut mieux que toutes les ampoules ne soient pas mises à jour en même temps. Et les mises à jour supposent que le système ait été conçu pour cela. Par exemple, en cryptographie, il est souvent nécessaire de remplacer les algorithmes cryptographiques qui ont été cassés avec le temps, mais beaucoup d'objets connectés utilisent des systèmes cryptographiques mal conçus, qui n'ont pas d'agilité cryptographique. (Au passage, la section 5.8 du RFC traite le cas des possibles futurs ordinateurs quantiques, et des conséquences qu'ils auront pour la cryptographie. Les objets connectés peuvent rester actifs de nombreuses années, et il faut donc penser loin dans le futur.) Ces points, et beaucoup d'autres, avaient été traités dans un atelier de l'IAB, qui avait fait l'objet du RFC 8240. À l'IETF, le groupe de travail SUIT développe des mécanismes pour aider les mises à jour (mais qui ne traiteront qu'une petite partie du problème).

Rapidement dépassés, les objets connectés posent également des problèmes de gestion de la fin de vie. Au bout d'un moment, le vendeur va arrêter les différentes fonctions, comme les mises à jour du logiciel ou, plus radicalement, comme les serveurs dont dépend l'objet. Cet arrêt peut être volontaire (l'objet n'intéresse plus le vendeur, qui est passé à d'autres gadgets) ou involontaire (vendeur en faillite). Le RFC note qu'une des voies à explorer est la continuation de l'objet avec du logiciel tiers, qui ne dépend plus de l'infrastructure du vendeur. Bien des ordiphones ont ainsi vu leur vie prolongée par CyanogenMod, et bien des routeurs ont bénéficié d'OpenWrt. (D'où l'importance de pouvoir installer ce logiciel tiers, ce qu'interdisent beaucoup de vendeurs.)

Une autre question intéressante de sécurité posée par les objets connectés est la vérification de leurs capacités réelles et de leur comportement effectif. L'acheteur peut avoir l'impression qu'il est le propriétaire de l'objet acheté mais cet objet est suffisamment complexe pour que l'acheteur ne soit pas au courant de tout ce que l'objet fait dans son dos. Le vrai maitre de l'objet est alors le vendeur, qui continue à communiquer avec l'engin connecté. C'est ainsi que des malhonnêtes comme Lidl ou Google avaient installé des micros dans des objets qu'on installe chez soi, et évidemment sans le dire à l'acheteur. Et encore, un micro est un appareil physique, qu'un examen attentif (avez-vous vérifié tous les objets connectés chez vous ?) peut détecter. Mais savoir ce que raconte l'objet connecté à son maitre est plus difficile. Peu d'utilisateurs ont envie de configurer un routeur local, et d'y faire tourner tcpdump pour voir le trafic. Et encore, ce trafic peut être chiffré et l'acheteur (qui, rappelons-le, n'est pas le véritable propriétaire de l'objet, puisqu'il n'a quasiment aucun contrôle, aucune information) n'a pas les clés.

Le problème de fournir des informations à l'utilisateur n'est pas trivial techniquement. Beaucoup d'objets connectés n'ont pas d'interface utilisateur où afficher « je suis en train d'envoyer plein de données sur vous à mon maitre ». Une solution partielle serait une description des capacités de l'engin, et de ses communications, dans un fichier MUD (Manufacturer Usage Description, RFC 8520). Ceci dit, vu le niveau d'éthique dans le monde de l'IoT, gageons que ces fichiers MUD mentiront souvent, notamment par omission.

Puisqu'on a parlé de vie privée, c'est l'occasion de rappeler que l'IoT est une grave menace pour cette vie privée. Le RFC note que, dans le futur, nous serons peut-être entourés de centaines d'objets connectés. (Malheureusement, le RFC parle surtout des risques dûs à des tiers qui observeraient le trafic, et très peu des risques dûs aux vendeurs qui récoltent les données.) L'IoT permet une intensification considérable du capitalisme de surveillance.

Bref, la situation est mauvaise et, s'il y a en effet quelques progrès (on voit moins souvent des mots de passe identiques pour tous les objets d'un type), ils sont largement annulés par de nouveaux déploiements.

  • August 16th 2019 at 02:00

Project HDMI Switcher Part 2 - Touch 10 Control

If you not familiar with the setup for this project please visit for the introduction.

In part 2 we are going to cover building the Cisco Touch 10 UI for controlling out HDMI switch. This is pretty easy as the UI control involves a button that is available in in and out of calls and the panel to allow selecting different inputs.

In-Room Control Primer

If you are not familiar with building custom interfaces on a Touch 10 controller please check out this primer from the Webex Team I posted recently first. It's a great intro for getting into working with the tools that allow you to create projects just like this one.

Back to the Project...


After accessing the In-Room Control Editor I created a panel and added a 4 button widget. Make sure to select the "Panel is Available Always". You may want to switch HDMI inputs mid-call.

In-Room Panel Creation
Once you have created your panel, select your icon and color for the panel button.
Button icon and color selection
We have our panel selected, our color and icon for the button, let us take a closer look at those widgets. As you can see below it's pretty simple. The ID's are aligned to the inputs on our HDMI switch so not to confuse us. To make it simple the button IDs are 1 - 4. The ID's are super important as this is what the Macros will use to identify what was pressed. Make sure to label the buttons on the widget with what the HDMI selections are.


Simple Button ID

What you end up with is something similar to the screenshots below on the Touch 10. Our switch has a purple button with something that looks switch-ish for the icon.

Button alway available

Widget with button labels

If you would like to upload this as XML here is the XML file you will need:


Next post, we will cover the Macro used to turn the UI into actions to control our Switch.

VoIPNorm

Late Adopters of UCaaS are Poised to Buy

When any new technology emerges onto the market, it arrives in waves. Early adopters get access to the features first, but they also endure the setbacks, the bumps that need to be smoothed out, and of course the prices that have not had a chance to settle at a more reasonable spot.

Vacation Mode: UC Tricks for Workaholics on Vacation

By Jessica Campas

It’s been proven time and time again that taking a vacation from the office boosts productivity upon return, while also improving mental stability and overall happiness. Traveling with family and

The post Vacation Mode: UC Tricks for Workaholics on Vacation appeared first on Inside the Asterisk.

Configure Music on Hold (MoH) for Asterisk

By Administrator

Configure Music on Hold  for Asterisk

Configure Music on Hold on Asterisk/FreePBX/Elastix to allow music to be played when a call is on hold or call is on the Queue when no agents are available to pick the call.

Configuration in Asterisk

  • Login to Asterisk Server
  • Navigate to PBX > Music on Hold
  • Click on Add Music Category
  • Category Name > MoH Source
  • Click on Submit Changes
  • Click on Apply Configuration Changes
  • Click on Browse > Choose the WAV file which you would like to play when the call is on hold > Click on Upload

(The format of the WAV file should be in 16000khz, Sample rate 16 bit, Channel Mono)

  • Click on Apply Configuration Changes
  • Now configure Music on Hold for your Conference or Queue > Navigate to Music on Hold Class > Select MoH Source from the drop down menu.

Hope this helps!

Published by Team UC Collabing

The post Configure Music on Hold (MoH) for Asterisk appeared first on UC Collabing.

Mistakes Businesses Make When Implementing UC (and How to Avoid Them)

According to Enterprise Management 360, more than half of existing companies plan to move to Unified Communications as a Service in the near future. Moving their communications to a hosted or cloud-based platform gives businesses several advantages, from financial to technological. This decision is being made by companies of all sizes across all verticals.

RFC 8621: The JSON Meta Application Protocol (JMAP) for Mail

By Stéphane Bortzmeyer

Ce nouveau RFC décrit un remplaçant pour le traditionnel protocole IMAP, remplaçant fondé sur le cadre JMAP (JSON Meta Application Protocol, RFC 8620).

Le protocole décrit dans ce RFC fournit les mêmes services qu'IMAP (RFC 3501) : accéder aux boîtes aux lettres de courrier, chercher dans ces boîtes, gérer les messages (détruire les inutiles, par exemple), etc. Par rapport à IMAP, outre l'utilisation du format JSON, l'accent est mis sur la synchronisation rapide, l'optimisation pour les clients mobiles, et sur la possibilité de notifications. JMAP est sans état (pas besoin de connexion permanente). Ce « JMAP pour le courrier » s'appuie sur JMAP, normalisé dans le RFC 8620. JMAP est un protocole générique, qui peut servir à synchroniser bien des choses entre un client et un serveur (par exemple un agenda, ou bien une liste de contacts). Par abus de langage, je vais souvent dire « JMAP » dans cet article alors que je devrais normalement préciser « JMAP pour le courrier », premier « utilisateur » du JMAP générique.

JMAP manipule différents types d'objets. Le plus important est sans doute Email (section 4 du RFC), qui modélise un message. Il s'agit d'une représentation de haut niveau, le client JMAP n'a pas à connaitre tous les détails de l'IMF (Internet Message Format, RFC 5322), de MIME (RFC 2045), etc. Un objet de type Email a une liste d'en-têtes et un corps, et JMAP fournit des méthodes pour accéder aux différentes parties du corps. Il y a même plusieurs représentations d'un message, pour s'adapter aux différents clients. Par exemple, un message MIME est normalement un arbre, de profondeur quelconque, mais un client JMAP peut décider de demander une représentation aplatie, avec juste une liste d'attachements. (La plupart des MUA présentent à l'utilisateur une vue aplatie de l'objet MIME.) Voilà pourquoi l'objet Email a plusieurs propriétés, le client choisissant à laquelle il accède :

  • bodyStructure : l'arbre MIME, c'est la représentation la plus « authentique »,
  • textBody : une liste des parties MIME à afficher quand on préfère du texte,
  • htmlBody : une liste des parties MIME à afficher quand on préfère de l'HTML,
  • attachments : la liste des « pièces jointes » (rappelez-vous que le concept de « pièces jointes » a été créé pour l'interface avec l'utilisateur ; il n'a pas de sens en MIME, qui ne connait qu'un arbre avec des feuilles de différents types).
Les en-têtes doivent pouvoir être internationaux (RFC 6532).

Un message a évidemment des métadonnées, parmi lesquelles :

  • id, un identifiant du message (ce n'est pas le Message-ID:, c'est attribué par le serveur JMAP), contrairement à IMAP, l'identificateur d'un message ne change pas, même quand le message change de boîte, et il peut apparaitre dans plusieurs boîtes à la fois
  • blobIf, un identifiant du message représenté sous la forme d'une suite d'octets, à analyser par le client, par opposition à l'objet de haut niveau identifié par id,
  • size, la taille du message,
  • keywords, des mots-clés, parmi lesquels certains, commençant par un dollar, ont une signification spéciale.
En IMAP, les mots-clés spéciaux sont précédés d'une barre inverse. En JMAP, c'est le dollar. Parmi ces mots-clés, $seen indique que le message a été lu, $answered, qu'on y a répondu, $junk, que le serveur l'a classé comme spam, etc. Ces mots-clés sont dans un registre IANA.

Et quelles opérations sont possibles avec les objets de type Email ? Ce sont les opérations génériques de JMAP (RFC 8620, section 5). Ainsi, on peut récupérer un message avec Email/get. Cette requête :

[[ "Email/get", {
        "ids": [ "f123u456", "f123u457" ],
        "properties": [ "threadId", "mailboxIds", "from", "subject",
          "receivedAt", "header:List-POST:asURLs",
          "htmlBody", "bodyValues" ],
        "bodyProperties": [ "partId", "blobId", "size", "type" ],
        "fetchHTMLBodyValues": true,
        "maxBodyValueBytes": 256
      }, "#1" ]]      
    
peut récupérer, par exemple, cette valeur :
      
[[ "Email/get", {
     "accountId": "abc",
     "state": "41234123231",
     "list": [
       {
         "id": "f123u457",
         "threadId": "ef1314a",
         "mailboxIds": { "f123": true },
         "from": [{ "name": "Joe Bloggs", "email": "joe@example.com" }],
         "subject": "Dinner on Thursday?",
         "receivedAt": "2013-10-13T14:12:00Z",
         "header:List-POST:asURLs": [
           "mailto:partytime@lists.example.com"
         ],
         "htmlBody": [{
           "partId": "1",
           "blobId": "B841623871",
           "size": 283331,
           "type": "text/html"
         }, {
           "partId": "2",
           "blobId": "B319437193",
           "size": 10343,
           "type": "text/plain"
         }],
         "bodyValues": {
           "1": {
             "isTruncated": true,
             "value": "<html><body><p>Hello ..."
           },
           "2": {
             "isTruncated": false,
             "value": "-- Sent by your friendly mailing list ..."
           }
         }
       }
     ],
     "notFound": [ "f123u456" ]
     }, "#1" ]]

    
Notez que le client a demandé deux messages, mais qu'un seul, le f123u457, a été trouvé.

Tout aussi indispensable, Email/query permet de demander au serveur une recherche, selon de nombreux critères comme la date, les mots-clés, ou bien le contenu du corps du message.

Email/set permet de modifier un message, ou d'en créer un (qu'on pourra ensuite envoyer avec EmailSubmission, décrit plus loin). Notez qu'il n'y a pas de Email/delete. Pour détruire un message, on utilise Email/set en changeant la propriété indiquant la boîte aux lettres, pour mettre la boîte aux lettres spéciale qui sert de poubelle (rôle = trash).

Comme IMAP, JMAP pour le courrier a la notion de boîte aux lettres (section 2 du RFC). Une boîte (vous pouvez appeler ça un dossier ou un label si vous voulez) est un ensemble de messages. Tout message est dans au moins une boîte. Les attributs importants d'une boîte :

  • Un nom unique (par exemple Vacances ou Personnel), en Unicode (RFC 5198),
  • Un identificateur attribué par le serveur (et a priori moins lisible par des humaines que ne l'est le nom),
  • Un rôle, optionnel, qui indique à quoi sert la boîte, ce qui est utile notamment si le serveur peut être utilisé en JMAP et en IMAP. Ainsi, le rôle inbox identifie la boîte où le courrier arrive par défaut. (Les rôles figurent dans un registre IANA créé par le RFC 8457.)
  • Certains attributs ne sont pas fixes, par exemple le nombre total de messages contenus dans la boîte, ou bien le nombre de messages non lus.
  • Les droits d'accès (ACL, cf. RFC 4314.) Les permissions sont par boîte, pas par message.

Ensuite, on utilise les méthodes JMAP pour accéder aux boîtes (révisez donc le RFC 8620, qui décrit le JMAP générique). Ainsi, pour accéder à une boîte,, on utilise la méthode JMAP Mailbox/get, qui utilise le /get JMAP (RFC 8620, section 5.1). Le paramètre ids peut être nul, cela indique alors qu'on veut récupérer tous les messages (c'est ce qu'on fait dans l'exemple ci-dessous).

De même, pour effectuer une recherche sur le serveur, JMAP normalise la méthode /query (RFC 8620, section 5.5) et JMAP pour le courrier peut utiliser Mailbox/query.

Par exemple, si on veut voir toutes les boîtes existantes, le client JMAP envoie le JSON :

[[ "Mailbox/get", {
     "accountId": "u33084183",
     "ids": null
}, "0" ]]
    
et reçoit une réponse du genre (on n'affiche que les deux premières boîtes) :
[[ "Mailbox/get", {
     "accountId": "u33084183","state": "78540",
     "state": "78540",
     "list": [{
         "id": "MB23cfa8094c0f41e6",
         "name": "Boîte par défaut",
         "role": "inbox",
         "totalEmails": 1607,
         "unreadEmails": 15,
         "myRights": {
               "mayAddItems": true,
               ...},
	       {
         "id": "MB674cc24095db49ce",
         "name": "Personnel",
	 ...
    
Notez que state est l'identificateur d'un état de la boîte. Si on veut ensuite récupérer les changements, on pourra utiliser Mailbox/changes avec comme paramètre "sinceState": "88540".

Dans JMAP, les messages peuvent être regroupés en fils de discussion (threads, section 3 du RFC). Tout message est membre d'un fil (parfois membre unique). Le RFC n'impose pas de méthode unique pour constituer les fils mais suggère :

  • D'utiliser les en-têtes du RFC 5322 (In-Reply-To: ou References: indiquant le Message-Id: d'un autre message).
  • Et de vérifier que les messages ont le même sujet (après avoir supprimé des préfixes comme « Re: »), pour tenir compte des gens qui volent les fils. Cette heuristique est imparfaite (le sujet peut avoir changé sans pour autant que le message soit sans rapport avec le reste du fil).

On peut ensuite accéder aux fils. Le client envoie :

[[ "Thread/get", {
       "accountId": "acme",
       "ids": ["f123u4", "f41u44"]
}, "#1" ]]      
    
Et récupère les fils f123u4 et f41u44 :
[[ "Thread/get", {
       "accountId": "acme",
       "state": "f6a7e214",
        "list": [
          {
              "id": "f123u4",
              "emailIds": [ "eaa623", "f782cbb"]
          },
          {
              "id": "f41u44",
              "emailIds": [ "82cf7bb" ]
          }
...
    

Un client qui vient de se connecter à un serveur JMAP va typiquement faire un Email/query sans conditions particulières, pour recevoir la liste des messages (ou alors en se limitant aux N messages les plus récents), puis récupérer les fils de discussion correspondants avec Thread/get, récupérer les messages eux-mêmes. Pour diminuer la latence, JMAP permet au client d'envoyer toutes ces requêtes en une seule fois (batching), en disant pour chaque requête qu'elle doit utiliser le résultat de la précédente (backreference, membre JSON resultOf).

JMAP permet également d'envoyer des messages. Un client JMAP n'a donc besoin que d'un seul protocole, contrairement au cas courant aujourd'hui où il faut IMAP et SMTP, configurés séparement, avec, trop souvent, l'un qui marche et l'autre pas. Cela simplifie nettement les choses pour l'utilisateur. Cela se fait avec le type EmailSubmission (section 7 du RFC). Deux importantes propriétés d'un objet de type EmailSubmission sont mailFrom, l'expéditeur, et rcptTo, les destinataires. Rappel important sur le courrier électronique : il y a les adresses indiquées dans le message (champs To:, Cc:, etc, cf. RFC 5322), et les adresses indiquées dans l'enveloppe (commandes SMTP comme MAIL FROM et RCPT TO, cf. RFC 5321). Ces adresses ne sont pas forcément identiques. Lorsqu'on apprend le fonctionnement du courrier électronique, la distinction entre ces deux catégories d'adresses est vraiment cruciale.

Un EmailSubmission/set va créer l'objet EmailSubmission, et envoyer le message. Ici, on envoie à john@example.com et jane@example.com un message (qui avait été créé par Email/set et qui avait l'identificateur M7f6ed5bcfd7e2604d1753f6c) :

[[ "EmailSubmission/set", {
        "accountId": "ue411d190",
        "create": {
          "k1490": {
            "identityId": "I64588216",
            "emailId": "M7f6ed5bcfd7e2604d1753f6c",
            "envelope": {
              "mailFrom": {
                "email": "john@example.com",
                "parameters": null
              },
              "rcptTo": [{
                "email": "jane@example.com",
                "parameters": null
              },
              ...
              ]
            }
          }
        },
        "onSuccessUpdateEmail": {
          "#k1490": {
            "mailboxIds/7cb4e8ee-df87-4757-b9c4-2ea1ca41b38e": null,
            "mailboxIds/73dbcb4b-bffc-48bd-8c2a-a2e91ca672f6": true,
            "keywords/$draft": null
          }
        }
      }, "0" ]]      
    
Anecdote sur l'envoi de courrier : les premières versions de « JMAP pour le courrier » utilisaient une boîte aux lettres spéciale, nommée Outbox, où on mettait les messages à envoyer (comme dans ActivityPub).

JMAP a d'autres types d'objets amusants, comme VacationResponse (section 8), qui permet de faire envoyer un message automatiquement lorsqu'on est absent (l'auto-répondeur du serveur doit évidemment suivre le RFC 3834, pour éviter de faire des bêtises comme de répondre à une liste de diffusion). On crée un objet avec VacationResponse/set et hop, l'auto-répondeur est amorcé.

Et je n'ai pas parlé de tout, par exemple JMAP permet de pousser des changements depuis le serveur vers le client, si la boîte aux lettres est modifiée par un autre processus (RFC 8620, section 7).

JMAP a le concept de capacités (capabilities), que le serveur annonce au client, dans un objet JSON (rappel : JSON nomme « objets » les dictionnaires), et sous la forme d'un URI. JMAP pour le courrier ajoute trois capacités au registre des capacités JMAP, urn:ietf:params:jmap:mail pour dire qu'on sait gérer le courrier, urn:ietf:params:jmap:submission, pour dire qu'on sait en envoyer (cf. RFC 6409, sur ce concept de soumission d'un message), et urn:ietf:params:jmap:vacationresponse pour dire qu'on sait gérer un auto-répondeur.

Le courrier électronique pose plein de problèmes de sécurité intéressants. La section 9 de notre RFC les détaille. Par exemple, les messages en HTML sont particulièrement dangereux. (Il est toujours amusant de voir des entreprises de sécurité informatique envoyer leur newsletter en HTML, malgré les risques associés, qui sont aujourd'hui bien connus.) Le RFC rappelle donc aux clients JMAP (mais c'est valable pour tous les MUA) que du JavaScript dans le message peut changer son contenu, qu'un message en HTML peut récupérer du contenu sur l'Internet (via par exemple un <img src=…), ce qui trahit le lecteur et fait fuiter des données privées, que CSS, quoique moins dangereux que JavaScript, permet également des trucs assez limites, que les liens en HTML ne pointent pas toujours vers ce qui semble (<a href="http://evil.example/">cliquez ici pour aller sur le site de votre banque https://good-bank.example</a>), etc. Pour faire face à tous ces dangers du courrier en HTML, le RFC suggère de nettoyer le HTML avant de l'envoyer au client. Attention, outre que c'est une modification du contenu, ce qui est toujours délicat politiquement, le faire proprement est difficile, et le RFC recommande fortement d'utiliser une bibliothèque bien testée, de ne pas le faire soi-même à la main (il y a trop de pièges). Par exemple, en Python, on peut utiliser lxml, et son module Cleaner, ici en mode extrémiste qui retire tout ce qui peut être dangereux :

    
from lxml.html.clean import Cleaner
...
cleaner = Cleaner(scripts=True, javascript=True, embedded=True, meta=True, page_structure=True,
                                      links=True, remove_unknown_tags=True,
                                      style=True)

Mais il est probablement impossible de complètement sécuriser HTML dans le courrier. Le RFC explique à juste titre que HTML augmente beaucoup la surface d'attaque. Une organisation soucieuse de sécurité ne devrait pas traiter le HTML dans le courrier.

La soumission du courrier (cf. RFC 6409) pose également des problèmes de sécurité. Imaginez un client JMAP piraté et qui serve ensuite à envoyer du spam de manière massive, utilisant le compte de l'utilisateur ignorant de ce piratage. Les MTA qui acceptent du courrier ont des mécanismes de défense (maximum N messages par heure, avec au plus M destinataires par message…) mais ces mécanismes marchent d'autant mieux que le serveur a davantage d'information. Si la soumission via JMAP est mise en œuvre par un simple relais vers un serveur SMTP de soumission, certaines informations sur le client peuvent être perdues. De tels relais doivent donc veiller à transmettre au serveur SMTP toute l'information disponible, par exemple via le mécanisme XCLIENT.

JMAP a été développé essentiellement au sein de FastMail, qui le met en œuvre sur ses serveurs. Il existe une page « officielle » présentant le protocole, qui explique entre autres les avantages de JMAP par rapport à IMAP. Vous y trouverez également des conseils pour les auteurs de clients, très bien faits et qui donnent une bonne idée de comment le protocole marche. Ce site Web est un passage recommandé.

On y trouve également une liste de mises en œuvre de JMAP. Ainsi, le serveur IMAP bien connu Cyrus a déjà JMAP en expérimental.

  • August 14th 2019 at 02:00

Configuring Cisco Call Detail Record (CDR)

By Administrator

CDR Reporting? What is a CDR Report?

CDR (Call Detail Record) – According to the definition given webopedia, in IP Telephony, a call detail record is a data record that contains information related to a telephone call, such as the origination and destination addresses of the call, the time the call started and ended, the duration of the call, the time of day the call was made and any toll charges that were added through the network or charges for operator services, among other details of the call.
Source : – http://www.webopedia.com/TERM/C/call_detail_record.html

How to configure CDR Report?

  •  Login to Cisco Unified Communication Manager
  •  Go to System -> Service Parameters –> Select Server as  appropriate CUCM Server & Service as Cisco Call Manager (Active)
  •  Search the field CDR Enabled Flag Required Field and set it as True & CDR Log Calls with Zero Duration Flag as True
  • Click on Save

How to access CDR Report?

  • Login to CUCM CAR Reporting Tool https://x.x.x.x:8443/car/
  • Go to CDR -> Export CDR/CMR records
  • Select From Date (Date since when you want the CDR Report
  • Select To Date (Date till when you want the CDR Report)
  • Check Mark CDR Record and Unckeck CMR Record
  • Export To File
  • Save the file in your Desktop/Laptop to the location/drive you want to save

How to open the CDR Report?

  • Ensure that Microsoft Excel is installed in your system.
  • Open Excel Application -> Go to File -> Open -> Select All Files in Files of Type and Select the downloaded CDR Report and Click on Open
  • Select Delimited  and Click on Next
  • Check Mark Tab and Comma and click on Finish and here you go. Now you can see all the fields are popped up.

CDR Report Full
There are many fields in the CDR Report and the utility of these fields are important based on your requirement.
If you want only Calling Party Number, Called Party Number, Duration and Date and Time of Call then you need to ensure that you keep the following

callingPartyNumber finalCalledPartyNumber duration dateTimeOrigination

CallingPartyCalledPartyDurationDateandTime

Published by Team UC Collabing

The post Configuring Cisco Call Detail Record (CDR) appeared first on UC Collabing.

Data Traffic Trends and the (5G) Impact on Enterprise Communications

By Jim Machi

A couple of months ago, I spent some blog time going over the Cisco Visual Networking Index (VNI) report, specifically talking about the coming impact of video and WiFi on

The post Data Traffic Trends and the (5G) Impact on Enterprise Communications appeared first on Inside the Asterisk.

Addressing MPLS vs Over-the-Top and other UC & UCaaS Quality of Service Questions

When it comes to your UC deployment, whether it be on-prem, hybrid-cloud or UCaaS, I’m sure we can all agree that redundancy is critical.  So is security and your SBC (Session Border Controller).  So is the software you are using.  A lot of thought goes into addressing these issues, determining the best options and delivering a great solution.  U
But when push comes to shove all employees care about is whether their calls have jitter, are cutting in and out, or get randomly dropped.  While working to deliver the highest possible Quality of Service for their UC-platform, a common question businesses ask is “Do we need to run the solution over a dedicated MPLS network or is it OK to send calls over-the-top via the public Internet?”  
NOTE:  For those of you that are ready to geek out for 10 minutes, check out all the MPLS details your little heart desires, here.

KAZOOcon 2019

"Welcome to San Diego. This is the site of KAZOOcon 2019." - Dave Gilbert

Project HDMI Switcher Part 1 - Introduction

Before the advent of custom UI elements and Macros on the Cisco Touch 10, switching HDMI inputs from a controller was typically done with another third party touch screen that was designed for addressing the room environment. This may or may not have included the video endpoint controls in the room.

Complex conference room
Your conference room may have also looked like the picture posted.  Hopefully you are not dealing with this type environment. Comment below if you are. I typically find organizations that have this type of conference room are struggling with understanding the new capabilities that modern video conference room device can do to reduce complexity.

The HDMI switch example in this post while only a small piece of a puzzle shows how you can start leveraging the Cisco video device in the room to reduce complexity. 

The Project


Below is an overview of what we are trying to achieve. 

Project overview
The Webex Room Kit we will be leveraging the following features:
  • Macros
  • Custom Touch 10 UI
  • HTTP request GET method
Atlona AT-JUNO-451
The HDMI switch for this project is a Atlona AT-JUNO-451 pictured right.  Its around $400 on Amazon and one of the cheapest HDMI switches that is IP controllable. Comment below if you have used other HDMI switches with success.

For our project we need to complete the following steps:
  1. Custom UI inputs on our Touch 10
  2. Codec Macro creation
  3. HDMI switch setup
In the next post we will tackle the custom Touch 10 UI controls to control our switch.

VoIPNorm
❌