Browsed by
Category: VoIP

Cisco IP DECT Solutions

Cisco IP DECT Solutions

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

Cisco 6825 IP DECT Handset
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
  • Waist Clip
  • Dimensions: 117 mm x 46 mm x 20 mm
  • Weight: 86 gr.

Cisco 210 IP DECT Base Station

Cisco 210 IP DECT Base Station
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
  • Multicell Technology
  • 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
You Can Use Multiple Cisco 210 Base Stations In Your Network (source cisco.com)
You Can Use Multiple Cisco 210 Base Stations In Your Network (source cisco.com)

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.

Supported Platforms

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:

  • Asterisk
  • Cisco BroadSoft BroadWorks
  • Cisco BroadCloud
  • Centile
  • Metaswitch

Even looking at this list, you can actually understand Cisco’s strategy in unified communications solutions. 🙂

Last Words

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.

What Is WebRTC?

What Is WebRTC?

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.

WebRTC stands for Web Based Real Time Communication. Multimedia applications can be designed using HTML5 and Javascript APIs.

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+
    • Safari 11+
    • Opera 18+
    • Vivaldi 1.9+
  • Android
    • Google Chrome 28+
    • Mozilla Firefox 24+
    • Opera Mobile 12+
  • iOS
    • MobileSafari / WebKit (iOS 11+)
  • Chrome OS
  • Firefox OS
  • BlackBerry 10
  • Tizen 3.0

WebRTC Components

There are 3 main components in WebRTC:

1. MediaStream API

The MediaStream API provides user access to the camera, microphone or screen using javascript.

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.

WebRTC Signaling Process

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.

STUN Server

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.

TURN Server

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

1. Mesh

In the mesh network, all peers send their streams separately to other connected peers directly on the network.

All Peers Communicate With Each Other in Mesh Topology

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.

2. SFU

SFU stands for Selective Forwarding Unit. An SFU receives incoming media streams from all users and then decides which users to send to.

SFU Transfers Media To All Peers Separately

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.

3. MCU

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.

MCU Combines Media of All Peers & Sends a Single Stream to Peers

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

Initial Information About CUCM 14 & IP Phones That Won’t Be Supported

After version 12, CUCM will jump 13 for suchreasons, and will probably appear as 14 early next year. In version 14, as in the 11.5 and 12 versions, some IP phones will not be supported either.

IP Phone Models Won’t Be Supported in CUCM 14

With the CUCM version 14, some IP phone models that have been in the market for many years will no longer be available. The following list includes models that will not be supported:

  • Cisco Unified IP Phone 3911, 3951
  • Cisco Unified IP Phone 6911, 6921, 6941, 6945, 6961
  • Cisco Unified IP Phone 7906G, 7911G, 7925, 7925G-EX, 7926, 7931, 7936, 7937G, 7940, 7941, 7960, 7961, 7985
  • Cisco Unified IP Phone 8941

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:

  1. Identify unsupported phones and schedule your upgrade to version 14 on time.
  2. Take advantage of competitive trading programs (Trade-in, Cisco Capital, etc.) or work with Cisco teams to cost-effectively renew the phones.
  3. Consider the strategy of migrating to software-based end devices like using Jabber.
  4. 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.

Changing IP Address & Hostname CUCM

Changing IP Address & Hostname CUCM

Hello, in this article you can find the configuration steps to change the CUCM IP address and hostname.

CUCM Changing IP Address & 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 
 hours.
  
 =======================================================
  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 
        before proceeding.
 =======================================================
  
 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:

 Hostname:       cucm                                                   
 IP Address:     192.168.0.137
 IP Subnet Mask: 255.255.255.0
 Gateway:        192.168.0.1
  
 Do you want to continue [yes/no]? yes 
    
 calling 1 of 5 component notification script: ahostname_callback.sh                      
 Info(0): Processnode query returned =
 name       
 ========== 
 bldr-vcm18 
 updating server table from:'oldHostname', to: 'newHostname'
 Rows: 1
 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 =
 name 
 ==== 
 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.

Cisco Meeting Server (CMS): Basic Configuration

Cisco Meeting Server (CMS): Basic Configuration

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:

hostname cms1

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:

webadmin enable

Now you can use the web interface with same CLI user.

You can also find these procedures in the video below:

Cisco Meeting Server (CMS) Basic Configuration

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.