Planet Collab

❌ About FreshRSS
There are new available articles, click to refresh the page.
Yesterday — April 22nd 2019Your RSS feeds

Managers Create Their Own Private Internet with SD-WAN

By Dave Gilbert

A WAN, or Wide Area Network, is a computer network in which the computers connected may be far apart, as opposed to a Local Area Network, where they are all close together (usually within a radius of a half a mile).  This enables businesses to connect branch offices to their headquarters, to allow retail locations to communicate with each other on the same network, sharing resources such as customer databases and price lookup tables.

Earth Day: What Makes Cisco a Sustainability Leader?

By Tae Yoo
In celebration of Earth Day, we spoke to three Cisco experts about how our teams and individuals are driving Cisco’s leadership in sustainability.

Digium Presents 2019 International Pinnacle Partner Awards

By Michael Dunham

Digium is proud to announce the 2019 Pinnacle Partner award winners for our valued international partners. These trusted partners serve as the face of Digium for customers around the world.

The post Digium Presents 2019 International Pinnacle Partner Awards appeared first on Inside the Asterisk.

Before yesterdayYour RSS feeds

Configuring Extension Mobility in CUCM

By Administrator

Configuring Extension Mobility in CUCM

Today let’s configure Extension Mobility as a service in Cisco Unified Communication Manager.
What is Extension Mobility? Cisco Extension Mobility allows users to access their Cisco Unified IP Phone configuration such as line appearances, services, and speed dials from other Cisco Unified IP Phones or Cisco IP Communicator.

Configuration of Extension Mobility on CUCM

Go to Device — Device Settings — Phone Services –> Add New
Service Name — Extension Mobility
ASCII Service Name — Extension Mobility
Service Description — EM
Service URL — http://X.X.X.X:8080/emapp/EMAppServlet?device=#DEVICENAME#
Service Category — XML Service
Service Type     — Standard IP Phone Service
Enable — Check Mark Enable to enable the service EM
Enterprise Subscription (Optional) — If you want to subscribe the service to all the devices, check mark Enterprise Subscription
** Note : -Service URL –  You may also either enter the Hostname of the CUCM as shown below
Click on Save
Click on Update Subscription.

Now you need to associate the Extension Mobility Service in the Device Profile.

Choose Device — Device Settings — Device Profile — click Add New.
From the drop down list, select the phone model to be configured, for example, Cisco IP Communicator
Click Next
Enter a Device Profile Name
From the Phone Button Template field
Click Save.
On the left hand side of the screen, click the link Line [1] – Add a new DN.
Choose a Directory Number
Select the Route Partition
Choose Appropriate CSS
Enter any Call Forward and Call Pickup Settings as necessary.
In the Display (Internal Caller ID), enter the User’s name.
Click Save.
From the Related Links: menu, select Subscribe/Unsubscribe Services.
In the Select a Service, select Extension Mobility, then click Next.
Click Subscribe.
Click Save.

Now you need to associate User Device Profile to a End User

Go to User Management > End User.
Click Find
Select the user from the list that matches the profile that was created.
Under Extension Mobility > Available Profiles, select the profile and move it to the Controlled Profiles selection.
Under Default Profile, select the profile.
Click Save.

Associate EM Service & Enable EM to Cisco IP Phone

Go to Device > Phone
Select the phone from the list of devices.
Under Extension Information on the Phone Page, check the Enable Extension Mobility box.
In the Related Links: field, select Subscribe/Unsubscribe Services and click Go
In the pop-up window, under Service Information, select Extension Mobility.
Click Next
Click Subscribe
Click Save
Close the pop-up window.
Click Save.

Now reset your IP Phone to reflect changes.

To login, Click on Services — Extension Mobility — Enter the User ID and Password and click on Submit to login


Published by Team UC Collabing

The post Configuring Extension Mobility in CUCM appeared first on UC Collabing.

Channel Parters Day 1 Highlights

Join Mike Cromwell and Dave Gilbert as they visit the Channel Partner's Expo 2019.  

CoreNexa is excited about contact center in the cloud, Teli mentions the impact that software engineers have on the communications market, and more.


Configure Mobile Voice Access

By Kanishka Singh

Have heard about MVA(Mobile Voice access). Yes, the talked about topic quite a while ago. I thought to cover this with you’ll. In nutshell, mobile users would first access the CUCM to place outbound calls.By accessing Call manager from their mobile device, the end user can enjoin the system to place calls and have the call appear from their desk phone. The caller ID would be DID number, not the users cell phone. However, to use the feature the user has to dial into the CUCM, authenticate (PIN: set for the user in end user section) and dial out. We can also accumulate MVA with Single number reach, in this case the called party returns the call to the office extension number and then call manager routes call to the mobile (SNR Destination). For example, the folks who are working from home, this is a lifeline for them is assuming they do not have Jabber or CIPC available with them.

First let’s go through the basic understanding of how it works: When we place a call from our cell phone to the configured mobile voice access (MVA) number, it matches the POTS dial peer on our voice gateway which is associated with MVA service which we create on the gateway. This service (MVA service), actuates MVA IVR on call manager. Once, you are directed to the IVR it then prompts for your PIN, basically authentication purpose. Once authenticated, you dial out the number.

So, let’s get started with the configuration:

Configuration done on CUCM:

  • Service Parameters  >Cisco CallManager > Clusterwide Parameters (System – Mobility)
  • Mention the following:
  • Enable Mobile Voice Access:True
  • Mobile Voice Access number: 12345
  •  Matching caller ID with Remote Destination: Partial match
  • Number of digits for caller ID Partial Match: 5 (herein, my remote destination number is  5)                                                                                     

  • Now,just to cross verify navigate to :
  • Cisco Unified Serviceability > Control Center Feature Services > Activate Cisco Unified Mobile Voice Access Service.

  • Now we will configure our MVA Directory Number;               remember which we gave in our service parameter:
  • Mobile voice Access Partition = “PT_MVA_Test” (it should be accessible from the phones)  >Media Resources >Mobile Voice Access
  • Now, we will associate end user, remote destination profile and enable mobility along with mobile voice access, so that we can use the services.
  • Device > Device Setting > Remote Destination Profile.
  • Device   >  Remote Destination

So, associate User ID, Remote Destination number and also the line number (which essentially should be your extension number).

  •  Next, we’ll configure a soft key template: Two modes we’ll turn on the on-hook state and off-hook state. Here, on-hook state allows users to turn on Mobile voice access on and off. Whether the employee is on pre-planned leave or a vacation, they can to do it as and when they want and secondly connected state, whenever they want to transfer a call from their mobile phone to their office extension
  • Device  >   Device setting  > soft key template >  create new
  • Navigate to On Hook status >Mobility  
  • Then navigate to connected status >  Mobility
  • Now, we are good to go with Voice Gateway:
  • First we need to configure service in Voice Gateway for MVA:


service mva http://CUCM PUB IP:8080/ccmivr/pages/IVRMainpage.vxml

You may verify the above command by:

show call application voice (This commands output displays detailed information about all interactive voice response (IVR) applications)

service mva http://CUCM PUB IP:8080/ccmivr/pages/IVRMainpage.vxml

  • Now, for inbound call, we will configure

dial-peer voice 10 pots

 description ** MVA IVR **

service mva


incoming called-number 12345

  • For outbound call, we will configure:

dial-peer voice 20 voip

description ** CUCM MVA **

destination-pattern 12345        

session protocol sipv2

session target ipv4:CUCM PUB IP

dtmf-relay rtp-nte

codec g711ulaw

no vad (To enable voice activity detection (VAD) for the calls using a particular dialpeer)

So, this was the configuration of MVA. This easy, go try it out and do let me know.

I hope this would have been informative for you and I’d like to thank you for viewing.

The post Configure Mobile Voice Access appeared first on UC Collabing.

RFC 8553: DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names

By Stéphane Bortzmeyer

Autrefois, de nombreux services et protocoles Internet avaient « réservé » de manière informelle, et sans enregistrement de cette réservation, des noms préfixés par un tiret bas, comme (cf. RFC 6186 pour cet exemple). Comme le RFC 8552 a mis fin à cette activité en créant un registre officiel des noms préfixés, il fallait réviser les normes existantes pour s'aligner sur les nouvelles règles. C'est le but de ce RFC 8553 qui modifie pas moins de trente-trois RFC !

Dans le nouveau registre, les entrées sont indexées par un couple {type d'enregistrement DNS, nom}. Par exemple, {TXT, _dmarc} pour DMARC (RFC 7489).

Les enregistrements SRV (RFC 2782) et URI (RFC 7553) posent un problème supplémentaire puisqu'ils utilisent un autre registre de noms, celui des noms de protocoles et services (dit aussi registre des numéros de ports) décrit dans le RFC 6335.

La section 2 du RFC décrit les usages actuels des noms préfixés par le tiret bas. Les enregistrements de type TXT, par exemple, sont utilisés dans sept RFC différents, comme le RFC 5518. Et les SRV dans bien davantage.

Enfin la section 3 du RFC contient le texte des changements qui est fait aux différentes spécifications utilisant les noms préfixés. (Il s'agit essentiellement de faire référence au nouveau registre du RFC 8552, il n'y a pas de changement technique.)

  • April 19th 2019 at 02:00

RFC 8552: Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves

By Stéphane Bortzmeyer

Une convention répandue pour les noms de domaine est de préfixer les services par un tiret bas, par exemple Cette pratique n'avait jamais été documentée mais c'est désormais fait. Et il existe désormais un registre IANA des noms ainsi préfixés.

Bien sûr, on peut mettre des ressources sous n'importe quel nom. Le DNS n'impose aucune restriction pour cela, et vous pouvez décider que le service X sera sous le nom $ (si vous ne me croyez pas, relisez le RFC 1035 et RFC 2181). Mais les humains aiment les conventions, par exemple pour les machines, comme www comme préfixe d'un serveur Web (préfixe d'ailleurs contesté, souvent pour de mauvaises raisons) ou mail pour un serveur de messagerie. Ce ne sont que des conventions, le DNS s'en moque, et on peut mettre un serveur Web en si on veut, cela ne perturbera que les humains. D'autant plus qu'on peut utiliser n'importe quel type de données avec n'importe quel nom (par exemple un enregistrement MX pour

La convention du tiret bas initial est répandue, notamment parce qu'elle évite toute confusion avec les noms de machines, qui ne peuvent pas comporter ce caractère (RFC 952). Elle est donc très commune en pratique. Cette convention permet de restreindre explicitement une partie de l'arbre des noms de domaine pour certains usages. Comme ce RFC ne fait que documenter une convention, il ne nécessite aucun changement dans les logiciels.

Une alternative au tiret bas serait d'utiliser un type de données spécifique. Quant aux types « généralistes » comme TXT, ils ont l'inconvénient qu'on récupère, lors de la résolution DNS, des informations inutiles, par exemple les TXT des autres services. Bref, vous créez un nouveau service, mettons X, vous avez le choix, pour le cas du domaine parent, entre :

  • Un nouveau type d'enregistrements DNS, nommons-le par exemple TYPEX (en pratique, c'est long et compliqué, et sans déploiement garanti, cf. RFC 5507),
  • Un type d'enregistrement générique comme TXT cité plus haut ou bien le URI du RFC 7553, menant à des ensembles d'enregistrements (RRset) potentiellement assez gros, problème détaillé en section 1.2,
  • Une convention de nommage comme,
  • Une convention de nommage avec un tiret bas (, l'objet de ce RFC 8552.
Un exemple d'un service réel utilisant la convention avec le tiret bas est DKIM (RFC 6376), avec le préfixe _domainkey :

% dig +short TXT
"v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDIgwhYZeeZgM94IofX9uaGAwQ+tynFX7rYs/igs+d1afqrrjMaoKay11IMprRyqhcVurQtJwGfk7PAWrXRjB+KpdySH9lqzvbisB3GrSs1Sf4uWscAbZ+saapw3/QD8YFyfYbsXunc6HROJQuQHM+U56OOcoiAiPHpfepAmuQyFQIDAQAB"

Comme beaucoup de choses, la convention « tiret bas » s'entend mal avec les jokers du DNS. D'abord, on ne peut pas utiliser les jokers entre le préfixe et le reste du nom (_x.* ne marche pas), ensuite, un joker couvre également les noms avec tiret bas donc * va répondre positivement pour même si on ne le voulait pas.

La section 1.5 de notre RFC détaille l'histoire de la convention « tiret bas au début ». Beaucoup de services utilisaient cette convention mais sans coordination, et sans qu'il existe une liste complète. Du fait de l'existence de plusieurs choix possibles (énumérés plus haut), ce RFC n'a pas obtenu de consensus immédiatement et les débats ont été longs et compliqués.

La section 2 du RFC explique comment remplir le nouveau registre des noms à tiret bas. On ne met dans ce registre que le nom le plus proche de la racine du DNS. Si un service mène à des noms comme, seul le _bar sera mis dans le registre. C'est particulièrement important pour le cas des enregistrements SRV qui ont souvent deux niveaux de noms préfixés (par exemple Seul le nom le plus proche de la racine, ici _tcp, est enregistré (ici, _sip est quand même enregistré car il peut en théorie être utilisé sans le _tcp mais il me semble que c'est rare en pratique).

Les règles pour les noms plus spécifiques sous le _bar (ou _tcp) sont spécifiées lors de la description du service en question. Par exemple, pour DKIM, le RFC 6376 précise que que sous le nom _domainkey, on trouve un sélecteur dont l'identificateur apparait dans le courrier signé. Donc, pour un message envoyé avec s=mail et, on cherche les informations DKIM en

Le formulaire pour demander l'enregistrement d'un nouveau nom préfixé par un tiret bas figure en section 3 du RFC. Il faut indiquer le type de données DNS (un enregistrement n'est valable que pour un certain type, donc la clé du registre est un couple {type, nom}), le nom et la référence du document décrivant le service en question. Le registre est décrit en section 4 du RFC. L'ajout dans ce registre se fait selon la politique « examen par un expert » (RFC 8126, section 4.5). La section 5 de notre RFC donne quelques indications à l'IANA sur cet examen.

Un ensemble d'entrées à ajouter pour initialiser ce nouveau registre est indiqué. On y trouve par exemple {TXT, _domainkey} pour DKIM, {TLSA, _tcp} pour DANE (RFC 6698), {TXT, _acme-challenge} pour ACME (RFC 8555), etc. Deux cas particuliers : le nom _example est réservé pour tous les types d'enregistrement, lorsqu'on a besoin de donner un exemple, sans spécifier un cas réel, et le nom _ta, qui sert au mécanisme de signalement des clés DNSSEC du RFC 8145, désigne en fait tous les noms commençant par _ta.

  • April 19th 2019 at 02:00

Cisco Unified Communications

By Administrator

Hello Everyone,
This is my first post and i hope i will continue this further and will try to put my best efforts to make it never ending and interesting post. I will try to gather stuffs from the real scenarios where i faced many challenges and will try simulate new stuffs as well. Will also try to gather stuffs from Forums and those will be first tested and then will be posted here.
A world of Cisco Unified Communications, its not a small world. It contains many devices like Cisco Unified Communication Manager (CUCM), Cisco Unity Connection (CUC), Cisco Unified Contact Center Express / Enterprise (UCCX / UCCE), Voice Gateways, Attendant Console, Arc Console, Unified Presence, Recording Solutions and many more.
So, let me try to start with a new topic and will continue further.

Published by Team UC Collabing

The post Cisco Unified Communications appeared first on UC Collabing.

How Experienced Trainers Backload Knowledge Transfer

By Michael Cromwell

There are (at least) two ways of delivering blended training.  That is to say, combining self service resources such as job aids and user guides in combination with live, recorded, or webinar training.  

Telecom Reseller: Sangoma Reiterates Commitment to UC [Podcast]

By Mac McCarver

A couple weeks ago, Jim Machi, our Vice President of Marketing, attended Enterprise Connect 2019. This event is the leading conference for enterprise communications and collaboration solutions in North America.

The post Telecom Reseller: Sangoma Reiterates Commitment to UC [Podcast] appeared first on Inside the Asterisk.

RFC 8574: cite-as: A Link Relation to Convey a Preferred URI for Referencing

By Stéphane Bortzmeyer

Ce RFC décrit un nouveau type de liens hypertexte permettant d'indiquer l'URI sous lequel on préfère qu'une ressource soit accédée, à des fins de documentation ou de citation précise.

Imaginons que vous accédez à un article scientifique en ligne. Vous utilisez un URI qui identifie cet article. Vous voulez ensuite citer cet article dans un de vos textes. Allez-vous utiliser l'URI d'accès ? Ce n'est pas forcément le meilleur, par exemple ce n'est pas forcément le plus stable sur le long terme. Le lien « cite avec » permet au serveur d'indiquer l'URI le plus pertinent pour une citation.

Ce RFC s'appuie sur la formalisation du concept de lien faite dans le RFC 8288. « Contexte » et « cible » sont donc utilisés comme dans cette norme, le contexte d'un lien étant le point de départ et la cible l'arrivée. En prime, notre RFC 8574 définit deux termes, l'URI d'accès, celui utilisé pour accéder à une ressource (par exemple une page Web) et l'URI de référence, celui qu'il faudrait utiliser pour la citation.

La section 3 du RFC décrit quelques scénarios d'usage. Le premier est celui des identificateurs stables. Normalement, lorsque le ou la webmestre est compétent(e) et sérieux(se), les URI sont stables, comme précisé dans l'article « Cool URIs don't change. Mais, en pratique, beaucoup de webmestres sont incompétents ou paresseux. Cela a mené à des « solutions » fondées sur la redirection, où il apparait une différence entre URI d'accès et URI de référence. C'est le cas avec des techniques comme les DOI (« use the Crossref DOI URL as the permanent [reference] link »), PURL ou ARK. Dans les trois cas, au lieu de gérer proprement les URI, on utilise un redirecteur supposé plus stable (alors que rien ne le garantit) et on souhaite utiliser comme URI de référence l'URI du redirecteur (donnant ainsi des pouvoirs démesurés à des organisations privées comme l'IDF, qui matraque régulièrement l'importance de n'utiliser que leurs identificateurs).

Un autre scénario d'usage est celui des ressources versionnées. C'est par exemple le cas de Wikipédia. La page Wikipédia sur l'incendie de Notre-Dame de Paris change souvent en ce moment. Comme toutes les pages Wikipédia, chaque version à un identificateur, et on peut se référer à une version particulier. Si renvoie à la dernière version, sans cesse en mouvement, renvoie uniquement à la toute première version, très sommaire et à une version intermédiaire déjà très fournie.

Souvent, quand on veut citer un article de Wikipédia, on veut se mettre à l'abri de changements ultérieurs, pas forcément positifs, et on souhaite donc citer exactement une version particulière. On clique donc sur « Lien permanent » (ou bien « Voir l'historique » puis sur la date la plus récente) pour avoir l'URI de la version qu'on vient de regarder. (Notez aussi le très utile lien « Citer cette page ».)

Troisième cas d'usage cité, celui des identifiants sur les réseaux sociaux. M. Toutlemonde a typiquement plusieurs pages le décrivant sur ces réseaux (dans mon cas,,,, et sans doute bien d'autres que j'ai oubliés, et ceux que j'ai eu la flemme de faire, comme FOAF). Or, on pourrait souhaiter décider qu'un de ces profils est meilleur que les autres, par exemple parce qu'il est plus directement contrôlé par l'utilisateur, ou mieux maintenu. Il serait alors intéressant d'indiquer lors de l'accès à chacun des autres profils quel est le profil de référence. (Le RFC est très irréaliste là-dessus : je vois mal un réseau « social » capitaliste permettre à ses utilisateurs de dire « allez plutôt voir là ».)

Enfin, un dernier cas d'usage est celui d'une publication composée de plusieurs ressources (par exemple un livre où chaque chapitre est accessible séparement, avec son propre URI). On souhaite alors que l'accès à chaque ressource indique, à des fins de citation, l'URI de référence (par exemple la page d'accueil).

La section 4 du RFC présente la solution : un nouveau type de lien, cite-as, qui permet de dire quel est l'URI de référence. (Le RFC recommande d'ailleurs que cet URI soit un URL : le but est d'accéder à la ressource !) Il est évidemment recommandé qu'il n'y ait qu'un seul lien de type cite-as. Ce lien n'interdit pas d'utiliser d'autres URI, il indique seulement quel est l'URI que le webmestre souhaite voir utilisé dans les références webographiques. cite-as est désormais dans le registre IANA des types de liens.

La section 6 du RFC donne des exemples concrets, puisque les liens peuvent se représenter de plusieurs façons. Par exemple, l'article de PLOS One auquel vous accédez en pourrait contenir, en HTML, le lien avec l'attribut rel="cite-as" :

 <link rel="cite-as"
           href="" />    

Cela indiquerait que les auteurs préfèrent être cités par le DOI (une mauvaise idée, mais c'est une autre histoire).

Autre exemple de syntaxe concrète pour les liens, imaginé pour arXiv, pour des articles avec versionnement, un lien dans un en-tête HTTP pour, qui pourrait indiquer qu'on est en train de regarder la première version, « v1 » (il existe une « v2 », essayez) :

HTTP/1.1 200 OK
Date: Sun, 24 Dec 2017 16:12:43 GMT
Content-Type: text/html; charset=utf-8
Link: <> ; rel="cite-as"

Comme arXiv garde les différentes versions successives d'un article, cela permettrait de récupérer la version actuelle tout en sachant comment la référencer.

Revenons au HTML pour l'exemple des profils sur les réseaux sociaux, imaginons un utilisateur, John Doe, qui place dans le code HTML de sa page personnelle un lien vers son profil FOAF en Turtle :

     <link rel="cite-as" href=""


Et un dernier exemple, celui d'une publication composée de plusieurs ressources. Ici, l'exemple est Dryad une base de données scientifiques qui permet l'accès à des fichiers individuels, mais où chaque jeu de données a un identificateur canonique. En HTTP, cela donnerait, lorsqu'on accès à (un fichier CSV qui fait partie de cette base de données) :

HTTP/1.1 200 OK
Date: Tue, 12 Jun 2018 19:19:22 GMT
Last-Modified: Wed, 17 Feb 2016 18:37:02 GMT
Content-Type: text/csv;charset=ISO-8859-1
Link: <> ; rel="cite-as"

Le fichier CSV est membre d'un jeu de données plus général, dont l'URI de référence est

Ainsi, dans un monde idéal, un logiciel qui reçoit un lien cite-as pourrait :

  • Lorsqu'il garde un signet, utiliser l'URI de référence,
  • Identifier plusieurs URI d'accès comme ayant le même URI de référence, par exemple à des fins de comptage,
  • Indexer les ressources par plusieurs URI.

D'autres solutions avaient été proposées pour résoudre ce problème de l'URI de référence. La section 5 de notre RFC les énumère. Il y avait notamment cinq autres types de liens qui auraient peut-être pu convenir, alternate, duplicate, related, bookmark et canonical.

Les trois premiers sont vite éliminés. alternate (RFC 4287) décrit une autre représentation de la même ressource (par exemple la même vidéo mais encodée différemment). duplicate (RFC 6249) désigne une reproduction identique (et cela ne traite donc pas, par exemple, le cas d'une publication composée de plusieurs ressources). Quant à related (RFC 4287), sa sémantique est bien trop vague. Un article des auteurs du RFC décrit en détail les choix de conceptions et explique bien le problème. (Je trouve cet article un peu gâché par les affirmations sans preuves comme quoi les DOI seraient « permanents ». Si le registre disparait ou fait n'importe quoi, il y aura le même problème avec les DOI qu'avec n'importe quelle autre famille d'identificateurs.)

Le cas de bookmark (normalisé par le W3C) est plus compliqué. Il est certainement proche en sémantique de cite-as mais ne peut pas être présent dans les en-têtes HTTP ou dans la tête d'une page HTML, ce qui en réduit beaucoup l'intérêt. Le cas compliqué de bookmark est décrit dans un autre article des auteurs du RFC.

Enfin, le cas de canonical (RFC 6596). Ce dernier semble trop restreint d'usage pour les utilisations prévues pour cite-as. Et il n'a pas vraiment la même sémantique. Par exemple, pour les ressources versionnées, canonical indique la plus récente, exactement le contraire de ce qu'on voudrait avec cite-as. Et c'est bien ainsi que l'utilise Wikipédia. Si je récupère :

<link rel="canonical" href=""/>

On voit que canonical renvoie à la dernière version. Le cas de canonical fait lui aussi l'objet d'un article détaillé.

Je n'ai pas mis de tels liens sur ce blog, ne voyant pas de cas où ils seraient utiles.

  • April 18th 2019 at 02:00

Important News about 3DES and Skype for business Online

By Dino Caputo

The original date for the deprecation of support for 3DES support in Office 365 (February 28, 2019) has come and gone..  Microsoft has released updated guidance around this topic.

The 3DES encryption cipher is being retired from Skype for Business Online starting on July 10, 2019. This impacts all commercial and GCC customers who are using the following clients to connect to Office 365:

    • Lync 2010 Windows clients
    • Lync for Mac 2011
    • Lync Phone Edition
    • Lync 2010 Mobile clients

If you are using one or more of the above clients with Office 365, please ensure you take the necessary steps to migrate to newer versions. Below is the list of versions that will work with Skype for Business Online:

  • Skype for Business Click-to-Run - Requires the April 2018 Updates:
    • Monthly and Semi-Annual Targeted – 16.0.9126.2152 and higher
    • Semi-Annual and Deferred Channel – 16.0.8431.2242 and higher
  • Skype for Business 2019 volume license
  • Skype for Business 2016 Desktop Client, MSI 0.4678.1000 and higher, including Basic
  • Lync 2013 (Skype for Business 2015) Desktop Client, MSI and C2R, including Basic 0.5023.1000 and higher
  • Skype for Business for Mac 16.15 and higher
  • Skype for Business for iOS and Android 6.19 and higher
  • Certified Skype for Business Online Phones -  Further guidance is located here.


  • Customer admins will be notified via the Office 365 Message Center during the period of April 17-19, 2019
  • If needed, further updates will be communicated via Message Center to customers
  • There are currently no plans for broad-based public communications via blogs or social


There is no impact to customers who are using on-premises servers. However, Microsoft recommends that customers evaluate their encryption needs and consider upgrading if needed.


3DES aka “Triple DES” is a public encryption protocol first defined via RFC1851 in 1995. It first appeared in software products in 1998. The encryption is now over 20 years old and is now longer generally considered a secure option. Microsoft is responding to customer requests to no longer provide it as an option for encryption.


  1. Microsoft public documentation for deploying the SFB client in Office 365
  2. Microsoft public documentation for technical reference details on O365 encryption
  3. Public information on 3DES -
  4. 2016 InfoWorld article on successful attacks against older versions of 3DES
  5. and run the Score Analyzer to see if you have users or devices that are actively using 3DES.
  • April 18th 2019 at 06:48

Cours HTTP au CNAM

By Stéphane Bortzmeyer

Le 17 avril 2019, c'était la première édition de mon cours HTTP de deux heures au CNAM. Pour l'anecdote, c'était dans le bâtiment où il y avait eu l'un des premiers serveurs HTTP publics en France.

Voici les supports de l'exposé :

Tout a été filmé et la vidéo est disponible :

J'ai fait aussi un cours BGP et un cours DNS au même endroit.

Merci à Éric Gressier pour l'idée et l'organisation, et aux élèves pour avoir posé plein de questions pas toujours faciles.

  • April 18th 2019 at 02:00

Top and Most useful Cisco IOS Commands Networking

By Administrator

Top and Most useful Cisco IOS Commands Networking

If you are very new to networking and you are using Cisco routers for the first time or you are in learning phase, the below list of commands are the ones which are mostly and commonly used in day to day life. Sometimes the use of below commands can also be asked during an interview.

  • no shutdown – This command will unshut or enable the interface like fast ethernet, ethernet etc.
  • show memory– This command will show memory statistics in the router
  • reload – This command will restarts the router
  • show run  or show running-configuration – This command will show the running configuration of the router/switch.
  • show version – This command will show information like Cisco IOS Version, Router/Switch up time, IOS Image name, Configuration register value, RAM and NVRAM Memory
  • show clock – This command will show date and time on router
  • show ip route – This command will show the router’s routing table which will have a list of networks that the router can reach.
  • show history – This command will shows the history of the commands used recently
  • show debug – This command will show all debugging that is currently enabled.
  • show buffers – This command will show statistics for router buffer pools, shows the size of the small, middle, big, very big, large and huge Buffers
  • show interface – This command will show the status of a router interface like Interface status where it is up or down, Interface protocol status, interface utilization, interface error, MTU configured on the interface.
  • no debug all – This command will turn off all debugging that are currently enabled
  • show flash – This command will show the flash memory and displays the size of files and the amount of free flash memory
  • show users – This command will show users connected to router currently.
  • show stacks – This command will show reason for last reboot, monitors the stack use of processes and interrupts routines
  • show protocols – This command will show which protocols are configured
  • banner motd  – This command will set or change banner which is displayed when someone access the router
  • hostname – This command is used to configure the hostname of the router
  • clear counters – This command will clear interface counters. This helps in troubleshooting.
  • copy running-configuration startup-configuration – This command will save the configuration that is currently being modified (in RAM). If the device is powered down due to any conditions, the NVRAM will preserve this configuration
  • show processes – This comamnd will show active processes running on router
  • show process cpu – This command will show cpu statistics on the router
  • show access-lists –  This command will show access lists information configured on the router
  • show cdp neighbor – This command will show a summary of connected cdp devices

Hope this helps!

Published by Team UC Collabing

The post Top and Most useful Cisco IOS Commands Networking appeared first on UC Collabing.