Login
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:
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.
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
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.
In this case its KB4054566.
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
After the restart, if you run the same cmdlet you will see the version is now 378675 which corresponds to .NET 4.5.1.
You will now be able to install Office Web Apps Server!
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.
Change the IP Address of Publisher Servers on Subscribers (**This is applicable only when you have changed the Publisher IP Address**)
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.
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?
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
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.
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
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
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 UsageClick on Save
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
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
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
********** 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
Go to Edit Greeting ==> Check Mark Holiday and Closed and Click on Save
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
** 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)
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
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
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
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
********** ********** ********** 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.
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 :
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 :
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.
 |
| In-Room Panel Creation |
 |
| Button icon and color selection |
 |
| Simple Button ID |
 |
| Button alway available |
 |
| Widget with button labels |
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.
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 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.
(The format of the WAV file should be in 16000khz, Sample rate 16 bit, Channel Mono)
Hope this helps!
Published by Team UC Collabing
The post Configure Music on Hold (MoH) for Asterisk appeared first on UC Collabing.
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.
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 :
Planet Collab 
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).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
foisblobIf, 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.$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 :
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.)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 :
In-Reply-To: ou
References: indiquant le
Message-Id: d'un autre message).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.
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
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 |
Published by Team UC Collabing
The post Configuring Cisco Call Detail Record (CDR) appeared first on UC Collabing.
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.
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.
 |
| Complex conference room |
 |
| Project overview |
 |
| Atlona AT-JUNO-451 |
