Cisco has introduced IP DECT Solutions, which have been developed to meet the need for wireless telephony. Until now Cisco didn’t have a DECT phone solution in its product family and this situation being complemented by Wi-Fi or 3rd party DECT products.
Cisco IP DECT products operate in the USA and Canada in the frequency band range of 1920 – 1930 MHz and 1880 – 1900 MHz frequency band in other countries. The IP DECT series currently consists of 210 series base station and the 6825 series handheld terminal.
Let’s take a closer look at these products:
Cisco 6825 IP DECT Handset
2 Inches 240 × 320 Pixels 65K Color Display
Up to 17 Hours of Talk, 200 Hours of Standby Time
2 Lines Supported
Narrow Band (G.726) and Wide Band (G.722) Codec Support
Bluetooth and 3.5mm Wired Headset Support
Dimensions: 117 mm x 46 mm x 20 mm
Weight: 86 gr.
Cisco 210 IP DECT Base Station
30 Handheld Terminal Registration Per Single Base Station
5 Simultaneous Calls With Broadband Codecs and 10 Simultaneous Calls With Narrowband Codecs in Single Base Station
Scalability Up To 254 Base Stations
Total 1,000 SIP Device Registrations
Total 1,000 Simultaneous Calls with Broadband Codec, 2,000 Simultaneous Calls with Narrow Band Codec
G.711 (A-law & mu-law), G.722.2, G.726, G.729 (a & ab) Codec Support
PoE Class 2
In the Multicell concept, there is no central mechanism to control base stations. When deployed, one base station becomes the master station, and the other stations connect to master with the “Chain ID” defined on the base station and start their data synchronization. Yeah, that’s all.
Since the IP DECT series is a multiplatform product, it supports almost all PBXs using the standard SIP protocol. Here are Cisco’s officially supported platforms:
Cisco BroadSoft BroadWorks
Even looking at this list, you can actually understand Cisco’s strategy in unified communications solutions. 🙂
Although Cisco has always put WiFi phones in the foreground, DECT phones -which have a soft belly in the projects- have started to meet the need. As I wrote in my previous article, we will see if Cisco can surpass its competitors in this field with OpEx oriented solutions such as UCaaS and HaaS.
We’ve been hearing the name WebRTC a lot lately. In fact, WebRTC, which has been in use since 2011, is not a new technology but is a technology that provides simultaneous media communication (audio and video). The most important feature of WebRTC, which has many advantages, is that it can work directly on many popular browsers without requiring additional software.
We can define the communication format used in WebRTC as peer-to-peer. This communication is directly between peers, so you don’t need any media servers. WebRTC is free and has a BSD license, so you can develop WebRTC applications for free. (For example, you can experience a video conference virtual room with WebRTC at this link)
WebRTC Supported Browsers
Nowadays, the following browsers support WebRTC:
PC & MAC
Microsoft Edge 12+
Google Chrome 28+
Mozilla Firefox 22+
Google Chrome 28+
Mozilla Firefox 24+
Opera Mobile 12+
MobileSafari / WebKit (iOS 11+)
There are 3 main components in WebRTC:
1. MediaStream API
2. RTCPeerConnection API
The RTCPeerConnection API provides NAT traversal, codec processing, mutual SDP negotiation, media transmission, and secure connection functions between peers.
3. RTCDataChannel API
The RTCDataChannel API provides the functionality of establishing bidirectional data transfer channels between peers.
Establishing Peer-to-Peer Connection
Signaling is a process that forms the connection between peers. It can be achieved by WebSocket, XMPP, SIP or any other mechanism. WebRTC technology utilizes protocols such as RTP, STUN, SIP and ICE.
Session Description Protocol (SDP)
Also known as SDP, it is a protocol used to communicate media capabilities (voice codecs, IP and port information, etc.) between peers before establishing a connection and to meet each peer at a common point.
Interactive Connectivity Establishment (ICE)
ICE is a framework for the NAT traversal mechanism. ICE collects all available candidates (local IP addresses, STUN return IP addresses, and transmitted IP addresses – TURN). All collected addresses are then sent to remote peers via SDP.
The STUN server enables peers to find public IP addresses, the types of NAT they use, and the relationship between the Internet-side port information associated with the local port information specified by NAT.
When STUN usage is not possible, it is used to transmit media streams over a TURN server (you may think of it as a proxy).
WebRTC is not always peer-to-peer (P2P), but in multiple communication situations (eg video conferencing), different solutions are available. Let’s take a look at these.
Multi-Point Communication Types
In the mesh network, all peers send their streams separately to other connected peers directly on the network.
Since this structure is completely distributed, there is no need to have any media servers in the center. The disadvantage of the mesh structure is the use of high bandwidth. In a multi-video call using a mesh structure, if each user generates a 1 Mbps stream, the amount of data sent and received per user will be 4 Mbps in each direction.
SFU stands for Selective Forwarding Unit. An SFU receives incoming media streams from all users and then decides which users to send to.
In this model, each user transmits their own generated media stream to the SFU server. The SFU server can send whoever wants the stream. In this way, bandwidth is used more effectively. Similar with the mesh example above, if each user generates a 1 Mbps stream, the total outgoing data amount per user will be 1 Mbps and the total incoming data amount will be a maximum of 4 Mbps.
MCU stands for Multipoint Conferencing Unit. An MCU receives incoming media streams from all users, decodes them, creates a new layout, and sends it to all users as a single stream.
The difference of this structure from SFU is that a single combined stream will be sent to each user and the total transmission and reception amount per user will be 1 Mbps in each direction. The disadvantage of this structure, as you can imagine, is the high cost of the MCU with a high processing power in the center.
Initial Information About CUCM 14 & IP Phones That Won’t Be Supported
If you are using any of these phone models, CUCM will block registration for these phones after upgrading to CUCM version 14. If the IP phone stays on, it will create unnecessary network traffic as well as load the CallManager service as the phone will try to register itself again and again.
Reasons For Not Supporting These Phones
Apparently Cisco will only use the 7800 and 8800 series telephones at the end of the day, and the reasons for this are explained in four subheadings:
Security – Because older phone models cannot receive critical software updates, to protect users as new security issues arise.
New Features and Applications – Since some phone models have been introduced many years ago (eg, 7900 series was introduced in early 2000’s), the older processors and hardware in these phone models creates a number of problems in implementing new applications and security features, so that the user experience can not be maximized.
Sustainability – To ensure sustainability because older phones no longer have development support or regression tests.
End-of-Life Products – The phone models listed above have made end-of-sale and end-of-life announcements in the past. These phone models will expire when the CUCM 14 is launched.
If you have a plan to upgrade to CUCM 14 and you have older model phones that is no longer supported, Cisco offers the following advice:
Identify unsupported phones and schedule your upgrade to version 14 on time.
Take advantage of competitive trading programs (Trade-in, Cisco Capital, etc.) or work with Cisco teams to cost-effectively renew the phones.
Consider the strategy of migrating to software-based end devices like using Jabber.
Talk with Cisco partners about switching to 7800 and 8800 series IP phones which are supported.
You can find the Field Notice on Cisco.com by clicking this link.
Hello, in this article you can find the configuration steps to change the CUCM IP address and hostname.
Note 1: Before you start, if you plan to change the hostname, make sure that the corresponding DNS records are also updated. Otherwise you may experience communication problems.
Note 2: If you are going to change the IP addresses or hostnames of all nodes on a CUCM cluster, start from Publisher first. And then change the Subscribers individually.
After these warnings, now we can start:
1. Connect to CUCM OS Admin CLI via SSH and use the following command to change the hostname:
admin:set network hostname
ctrl-c: To quit the input.
*** W A R N I N G ***
Do not close this window without first canceling the command.
This command will automatically restart system services.
The command should not be issued during normal operating
Note: Please verify that the new hostname is a unique
name across the cluster and, if DNS services are
utilized, any DNS configuration is completed
Security Warning : This operation will regenerate
all CUCM Certificates including any third party
signed Certificates that have been uploaded.
Note: For hostname changes, if your CUCM or cluster uses certificates that are signed by a CA, you will need to sign these certificates again according to the new hostname and upload them to the CUCM. If self-signed certificates are used, this process will be renewed automatically and your endpoints will be reset to receive the new ITL file.
2. Enter the hostname after reading the warnings:
Enter the hostname:: cucm
3. If you want to change the IP address, subnet mask and default gateway, enter the relevant information followed by yes:
Would you like to change the network ip address at this time [yes]:: yes
Warning: Do not close this window until command finishes.
ctrl-c: To quit the input.
*** W A R N I N G ***
Note: Please verify that the new ip address is unique
across the cluster.
Enter the ip address:: 192.168.0.137
Enter the ip subnet mask:: 255.255.255.0
Enter the ip address of the gateway:: 192.168.0.1
4. The information you entered will be displayed on the screen. If all are true, you can start the change process by typing yes:
IP Address: 192.168.0.137
IP Subnet Mask: 255.255.255.0
Do you want to continue [yes/no]? yes
calling 1 of 5 component notification script: ahostname_callback.sh
Info(0): Processnode query returned =
updating server table from:'oldHostname', to: 'newHostname'
updating database, please wait 90 seconds
updating database, please wait 60 seconds
updating database, please wait 30 seconds
Going to trigger /usr/local/cm/bin/dbl updatefiles --remote=newHostname,oldHostname
calling 2 of 5 component notification script: clm_notify_hostname.sh notification
Verifying update across cluster nodes...
platformConfig.xml is up-to-date: bldr-vcm21
cluster update successfull
calling 3 of 5 component notification script: drf_notify_hostname_change.py
calling 4 of 5 component notification script: regenerate_all_certs.sh
calling 5 of 5 component notification script: update_idsenv.sh
calling 1 of 2 component notification script: ahostname_callback.sh
Info(0): Processnode query returned =
Going to trigger /usr/local/cm/bin/dbl updatefiles --remote=10.10.10.28,10.67.142.24
calling 2 of 2 component notification script: clm_notify_hostname.sh
Verifying update across cluster nodes...
Shutting down interface eth0:
If your CUCM or cluster is in mixed-mode, and you have done this with the CTL Client, run the CTL client again and update the CTL file. If you used tokenless CTL, run utils ctl update CTLFile from CLI to update the CTL file.
Hello, in this article you can find the basic configuration steps and how to enable web interface of Cisco Meeting Server (CMS).
There are 3 different interfaces for configuring Cisco Meeting Server: command line (CLI), GUI and API. The first CLI interface can be accessed via the server’s console or SSH (after the IP address is given). Now let’s start with the basic configuration steps, starting with the CLI interface and continue with switching to the GUI interface:
Cisco Meeting Server CLI Basic Configuration
When you connect to CMS via console, a login screen is displayed. You can log into CMS with default user admin and admin as password. After you log in, it asks you to change the password.
After passing this step, we can proceed to IP settings. By default, the CMS uses the IP which is received via DHCP, and if you want to configure CMS with a static IP address, you can use the following CLI command according to your own settings:
ipv4 a add 192.168.0.133/24 192.168.0.1
In this command, a is the name of a interface, 192.168.0.133is the IP address /24 is subnet mask and as you would expect 192.168.0.1 is default gateway.
Once you set the IP address, you can now connect to the CMS over SSH.
You can change the hostname which is defined as acano by default by issuing this command:
After this command, the CMS will ask you to reboot CMS in order to activate new hostname. You can reboot the CMS with the reboot command.
You need DNS and NTP servers for CMS to work properly. Considering that they are already up and running, enter the following DNS (.100) and NTP (.101) IP configurations:
ntp server add 192.168.0.101
dns add forwardzone. 192.168.0.100
You can noe continue with the configuration to activate the GUI.
WEB GUI Configuration
In order to use the web GUI, first you need a certificate for HTTPS connections. This certificate can be either a self-signed or a CA-signed certificate. For ease of operation, you can use the self-signed certificate by issuing this command:
pki selfsigned cms1
After that, specify the interface and HTTPS port for the web interface:
webadmin listen a 445
For the certificate (s) to be used, we specify the self-signed certificate created in the upper section and with the relevant key:
webadmin certs cms1.key cms1.crt
You can use the following command to route HTTP requests to HTTPS:
webadmin http-redirect enable
Then finally activate the web admin module:
Now you can use the web interface with same CLI user.
You can also find these procedures in the video below:
At this point, I must point out that you need to use either CLI, GUI and API interfaces to configure the different services of CMS. So this means that you can’t do everything from GUI or CLI only. I hope this situation will change with next releases.