Login
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.
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.
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.
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
http://CUCMHOSTNAME:8080/emapp/EMAppServlet?device=#DEVICENAME#
Click on Save
Click on Update Subscription.
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.
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.
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.
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.
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:
So, associate User ID, Remote Destination number and also the line number (which essentially should be your extension number).
application
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
dial-peer voice 10 pots
description ** MVA IVR **
service mva
direct-inward-dial
incoming called-number 12345
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.
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 _submission._tcp.example.net (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.)
Une convention répandue pour les noms de domaine est de préfixer les services
par un tiret bas, par exemple
_xmpp-client._tcp.jabber.ietf.org. 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 $X%.example.com
(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 mail.example.com 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
www.example.org).
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
example.org, entre :
Planet Collab 
TYPEX (en pratique, c'est
long et compliqué, et sans déploiement garanti, cf. RFC 5507),x.example.org,_x.example.org), l'objet de ce RFC 8552._domainkey :
% dig +short TXT mail._domainkey.gendarmerie.interieur.gouv.fr
"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.*.example.net ne marche pas), ensuite, un
joker couvre également les noms avec tiret bas donc
*.example.net va répondre positivement pour
_x.example.net 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 _foo._bar.example.org, 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 _sip._tcp.cisco.com). 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
d=gendarmerie.interieur.gouv.fr, on cherche
les informations DKIM en mail._domainkey.gendarmerie.interieur.gouv.fr.
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.
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.
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.
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.
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 https://fr.wikipedia.org/wiki/Incendie_de_Notre-Dame_de_Parishttps://fr.wikipedia.org/w/index.php?title=Incendie_de_Notre-Dame_de_Paris&oldid=158468007https://fr.wikipedia.org/w/index.php?title=Incendie_de_Notre-Dame_de_Paris&oldid=158478416
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, https://mastodon.gougere.fr/@bortzmeyerhttps://twitter.com/bortzmeyerhttps://www.linkedin.com/in/sbortzmeyer/https://seenthis.net/people/stephane
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 https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0171057rel="cite-as" :
<link rel="cite-as"
href="https://doi.org/10.1371/journal.pone.0171057" />
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 https://arxiv.org/abs/1711.03787
HTTP/1.1 200 OK
Date: Sun, 24 Dec 2017 16:12:43 GMT
Content-Type: text/html; charset=utf-8
Link: <https://arxiv.org/abs/1711.03787v1> ; 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 :
<html>
<head>
...
<link rel="cite-as" href="http://johndoe.example.com/foaf"
type="text/turtle"/>
...
</head>
<body>
...
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
à https://datadryad.org/bitstream/handle/10255/dryad.98509/PIPFIL_M_BCI.csv
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: <https://doi.org/10.5061/dryad.5d23f> ; 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 https://doi.org/10.5061/dryad.5d23fAinsi, dans un monde idéal, un logiciel qui reçoit un lien
cite-as pourrait :
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 https://fr.wikipedia.org/w/index.php?title=Incendie_de_Notre-Dame_de_Paris&oldid=158478416
<link rel="canonical" href="https://fr.wikipedia.org/wiki/Incendie_de_Notre-Dame_de_Paris"/>
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.
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:
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:
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.
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é :
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.
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.
Hope this helps!
Published by Team UC Collabing
The post Top and Most useful Cisco IOS Commands Networking appeared first on UC Collabing.
