CICD - Descriptions Flashcards
UNITY - Cisco Unity Connection (CUC) - 7 Keys
- Voicemail, auto-attendant, voice recognition (VUI)
- Max 20k mail boxes per CUC server
- Integrated IMAP server (Email Client Access) or Exchange Integration
- Web-based Voicemail Access
- Integrated with SCCP or SIP signaling and Traditional Telephony (PBX)
- Visual voicemail (Phone view) with Jabber or Cisco IP phones
- CUC needs a SIP TRUNK to be Integrated with CUCM
Cisco Unity Connection Architecture
Cisco Unity Express - 300 per Server - Router - NO
Unified CM Business Edition - 500 per Server - Appliance - NO
Cisco Unity Connection - 20,000 per Server - Appliance - Active / Active
Cisco Unity - 15,000 per Server - Windows Server - Active / Passive
Cisco Unity Connect or Connection has a different type of storage of your messages than Cisco Unity. Cisco unity actually needs an external e-mail solution such as Exchange or Lotus Notes because it leverages the exchange database store to actually store your voicemail messages with Cisco Unity Connection all of the messages are stored locally in an IBM Informix Database. So, we don’t have to rely upon, in other words that exchange server to be up and running in order for our messages to be stored
IMP - Instant Messaging and Presence - 5 Keys
- Cisco version of HANGOUTS, SKYPE, SAMETIME
- Integrated with CUCM (2 modes)
- Allows connections to outside domain (WEBEX, GOOGLE TALK,…)
- Prefers JABBER
- Max 45k users in UC mode
Max 75k users in STANDALONE mode
Max 40k users in LYNC interop mode (Skype for Business)
TMS - Telepresence Management Suite - 6 Keys
- Telepresence device provisioning
- Outlook (Exchange) telepresence scheduling
- Click-to-call video conferences
- Multi-source phone books
- Management of in-progress conferences
- Ressource utilization reports
VCS - Video Communication Server - 5 Keys
- Is like CUCM to telepresence endpoints
- Can handle video calls for registered endpoints
- VCS (combined with TMS) handles “UNCONTROLED” endpoints
- Includes : VCS CONTROL (incoming and outgoing calls to video endpoints)
VCS EXPRESSWAY (firewall traversal through “CORE” and “EDGE” components) - Can enable the “JABBER GUEST”
CUBE - Cisco Unified Border Element
Is designed to be the marker between your network and someone else network. CUBE is like your firewall for voice. This is the end of your company network. CUBE will be the only known server by your ITSP and will, based on Dial Plan, deliver to your company servers
VoIP Provider Connect
In order for us to connect out to let’s say an IP telephony service provider for example, we would need a special operating system and that special operating system is called the Cisco Unified Border Element. We call it CUBE for short, and what this allows us to do is connect a Voice over IP connection to another Voice over IP connection. In this example we’re talking about service provider, so if I want to connect my network to an IP telephony service provider, I would need to use this Cisco Unified Border Element to interconnect these two networks, and basically what happens here is the CUBE helps us with a demarcation point between the two entities, so between myself and the service provider we can have security, NAT - I may not want my private IP addresses exposed and then we might even want billing to take place.
JABBER - the ultimate collaboration clients - 6 Keys
- All plateformes Softphone, can Control desktop IP phones (can also replace the desktop Phone)
- Instant Messaging and Presence
- Employee Directory (LDAP)
- Voicemail Control
- Audio and Video Calls / Web Conferencing
- Communication History
Cisco Jabber client applications
These Cisco Jabber client applications reside on top of the Clients Services Framework, which provides a simplified client interface and an abstraction layer that allows access to the following underlying communications services:
- SIP-based call control for voice and video softphone clients from UnifiedCM
- Deskphone call control and “Click to Dial” services from UnifiedCM’s CTI interface
- Voice and video media termination for softphone clients
- Instant messaging and presence services using XMPP, from either the Cisco IM and Presence Service or Cisco WebEx. Cisco WebEx Meeting Center also offers hosted collaboration services such as online meetings and events
- Scheduled audio, video and web conferencing services
- Desktop sharing using either, video desktop sharing (BFCP) or WebEx desktop sharing
- Visual voicemail services from Cisco Unity Connection using IMAP
•Contact management using:
–UnifiedCM User Data Service (UDS) as a contact source (LDAP directory synchronization supported)
–Directory access using Microsoft Active Directory or supported LDAP directories as a contact source
–WebEx Messenger service
–Client Services Framework cache and contact list
•Microsoft Office Integration, which provides user availability status and messaging capabilities directly through the user interface of Microsoft Office applications such as Microsoft Outlook
VLAN - Virtual Local Area Network - 5 Keys
- Logically Groups Users
- Segments Broadcast Domain
- Subnet Correlation
- Access Control
- Quality of Service
VOICE VLAN - 4 Keys
- TRUNK = TAGGING PORT
- Phone connected to a type of “TRUNK” port
- Phone sends TAGGED TRAFFIC
- Computer sends UNTAGGED TRAFFIC
Data traffic needs to be segmented into 4 types of Data
- Mission critical (business Data)
- Transactional (dB replication)
- Best Effort (web surfing)
- Scavenger (peer to peer traffic)
QoS - MODELS
- Best effort
- Integrated Service (INTSERV) based on RSVP
- Differenciated Service (DIFFSERV)
QoS - METHODS
- Classification and marking
- Queuing (congestion management)
- Policing and Shapping
- Congestion avoidance (WRED)
- Link efficiency
QoS - Queuing Algorithms (5)
FIFO
First packet in is first packet out; only one queue
Priority queuing (PQ) Empty queue 1l if queue 1 is empty, then dispatch packets from queue 2, and so on
Weighted fair queuing (WFQ)
Flow-based algorithm that simultaneously schedules interactive traffic to the front of a queue
Class-based weighted fair queueing (CBWFQ)
Extends WFQ functionality to provide support for user-defined traffic classes
Low-latency queueing (LLQ)
Brings strict PQ to CBWFQ; allows delay-sensitive data like voice to be dequeued and transmitted before packets in other queues are dequeued
QoS - Link Efficiency Mechanisms
- PAYLOAD COMPRESSION
Squishing the data - HEADER COMPRESSION
Squishing the header (key for RTP) - LINK FRAGMENTATION AND INTERLEAVING
Blowing up big packets
DSCP and IP PRECEDENCE
DSCP IP Precedence Conversion Table
At its simplest, the higher the value of the IP Precedence field, the higher the priority of the IP packet. Simple…
DSCP Name - DS Field Value in Binary/Decimal - IP Precedence CS0 - 000 000/0 - 0 CS1 - 001 000/8 - 1 AF11 - 001 010/10 - 1 AF12 - 001 100/12 - 1 AF13 - 001 110/14 - 1 CS2 - 010 000/16 - 2 AF21 - 010 010/18 - 2 AF22 - 010 100/20 - 2 AF23 - 010 110/22 - 2 CS3 - 011 000/24 - 3 AF31 - 011 010/26 - 3 AF32 - 011 100/28 - 3 AF33 - 011 110/30 - 3 CS4 - 100 000/32 - 4 AF41 - 100 010/34 - 4 AF42 - 100 100/36 - 4 AF43 - 100 110/38 - 4 CS5 - 101 000/40 - 5 EF - 101 110/46 - 5 CS6 - 110 000/48 - 6 CS7 - 111 000/56 - 7
CS - Class Selector (RFC 2474)
AFxy - Assured Forwarding (x=class, y=drop precedence) (RFC2597)
EF - Expedited Forwarding (RFC 3246)
Where can you apply QoS methods For INBOUND QoS - 3 Keys
- Classify
- Mark
- Police
Where can you apply QoS methods For OUTBOUND QoS - 7 Keys
- Queue
- Mark
- Avoid
- Shape
- Police
- Compress
- LFI
AUTOQoS VOIP / AUTOQoS DISCOVERY… - 5 Keys
- Provides a template based QoS configuration
- Reduce QoS deployment time
- Minimize human errors
- Provides consistant configurations
- Allows manual changes
ANALOG vs DIGITAL
ANALOG is ONE active call per phone
DIGITAL is MULTIPLE active calls per phone broken into T1, E1 and ISDN standards
DS0
Quantization: 256 levels Sampling: 8,000 samples/second Coding: 8 bits/sample "Pulse Code Modulation" (PCM) 8,000 bytes per second 64,000 bits/second = 64 kb/s DS0 rate
There are three steps in voice digitization: quantization, sampling and coding.
The telephone system quantizes the voice signal to 256 levels. This number is chosen to reduce the quantization error, which would be heard as noise after the signal is reconstructed, so that a person can’t hear it on the line. The diagram shows bin numbers 127 and 128 around zero volts.
The second step is sampling. Since this is a voiceband signal, the frequency bandwidth is about 3000 Hz, and so the sampling rate must be at least 6001 times per second, following the Dr. Nyquist’s sampling theorem. To ensure that there are no aliasing errors, the telephone system samples more often: 8,000 samples per second.
The third step is coding. The telephone system uses 8 bits to code the value of each sample. This technique of using 8 bits per sample is called by some Pulse Code Modulation (PCM), which doesn’t really mean anything.
To determine the number of bits per second required, multiply the number of samples per second (8,000) by the number of bits per sample (8) to get 64,000 bits per second, or 64 kb/s for short.
This 64 kb/s rate is called a DS0 rate signal (Digital service level zero, or digital signal rate zero, just called “DS0s” in the business). This is the base rate of most transmission systems and digital voice systems. When someone talks about a channel on a digital transmission system, they usually mean a DS0.
Commercial transmission systems which are actually deployed were designed to carry digitized voice, and thus move multiple DS0s. Since they are digital systems, they can be easily be adapted to carry data or video as well as digitized voice.
CUCM - SCCP Phone registration
- SCCP phone obtains the Power (PoE or AC adapter).
- The phone loads its locally stored firmware image.
- The phone learns the Voice VLAN ID via CDP from the switch.
- The phone uses DHCP to learn its IP address, subnet mask, default gateway and TFTP server address.
- The phone contacts the TFTP server and requests its configuration file. Each phone has a customized configuration file named SEP.cnf.xml created by CUCM and uploaded to TFTP when the administrator creates or modifies the phone.
- The phone registers with the primary CUCM server listed in its configuration file. CUCM then sends the softkey template to the phone using SCCP messages.
Cisco SCCP IP Phone Startup Process
Okay, step one, the phone has to get power. Whether they get it from the switch or from that brick plugged into the wall. The phone is going to load a locally stored image at that point, and it’s also going to go on a little power-on self test too. So once we get power to it, it does a little power-on self test, gets that little locally stored image started, and now the switch provides VLAN information to the IP phone by the Cisco Discovery Protocol. So CDP kicks in here. The phone sends a DHCP request now, because it now knows what VLAN it’s a member of and it gets the IP information and option 150, the TFTP server address. Now the phone goes to the TFTP server and it now needs to download the configuration file. At that point within that configuration file it now knows a lot of information including the Communications Manager that it should register with. We can set up a group of Communications Manager in the graphical administrative interface that says, “you can try this Communications Manager, if that’s not available try the next and then finally try the third”, so you can list up to three. So now our Communications Manager sends the softkey template to the phone using the Skinny Client Control Protocol message.
CUCM - SIP Phone registration
- Phone obtains the Power (PoE or AC adapter).
- Phone loads its locally stored firmware image.
- Phone learns the Voice VLAN ID via CDP from the switch.
- Phone uses DHCP to learn its IP address, subnet mask, default gateway and TFTP server address.
- Phone contacts the TFTP server and requests the Certificate Trust List file (only if the cluster is secured).
- Phone contacts the TFTP server and requests its SEP.cnf.xml configuration file.
- If the SIP Phone has not been provisioned before boot time, the SIP Phone downloads the default configuration XMLDefault.cnf.xml file from the TFTP server.
- The SIP phone requests a firmware upgrade (Load ID file), if one was specified in the configuration file. This process allows the phone to upgrade the firmware image automatically when required for a new version of CUCM.
- Phone downloads the SIP dial rules configured for that phone.
- Phone Establish connection with the primary CUCM and the TFTP server end to end.
- Phone Registers with the primary CUCM server listed in its configuration file.
- Phone downloads the appropriate localization files from TFTP.
- Phone downloads the softkey configurations from TFTP.
- Phone downloads custom ringtones (if any) from TFTP.
Cisco SIP Phone Startup Process
So far the focus has been on Skinny, the Skinny Client Control Protocol. Let’s look at SIP now, because you could have your phones running this SIP firmware. The first few steps are the same. We have our Skinny Client Control Protocol and our SIP phones that need to gain access to that configuration file. So we are going through the power-on process, we’re going through the fact that we need to download our configured file or we need to download the default file and then go through the process of resending information back to the Communications Manager which reconfigures the file. Now the phone sends it back with the appropriate MAC address, so we went through that process. Now, where we vary, is that the SIP phone tries to download a certificate trust list file, that’s a CTL file. And it contains a set of certificates, so it’s really from the security standpoint. And it’s only used when the Communications Manager Cluster Security has been enabled, so if you didn’t turn on security in your cluster then that step is skipped.
Now your SIP phone again is going to request its config file from the TFTP server. If it’s new, the file is not going to be found, so we are going to download the default file from the TFTP server then that file contains the system-wide config parameters, and we will now locate the Communications Manager for that SIP phone.
Auto-registration kicks in, now the file contains the auto-registration name and then we go through the process of finding the Communications Manager and finishing the boot sequence, even though it still doesn’t have a legitimate directory number and nothing has been configured yet.
Now the SIP phone loads its load file. This is one that we specified in the default config file, so that default config file does contains some good information for your phones to boot up. So the SIP phone now attempts to obtain the new image at that point from the TFTP server, so hopefully at that point we’ve downloaded it so the SIP phone gets all of its information and now a connection is established with the Communications Manager server. Because within that file we have the IP address listed.
After that the phone can register with the Communications Manager server with the highest priority. Again remember we can list three. So the first one we attempt to register with it and once that has happened then the SIP phone is going to need to get some information, it still doesn’t have a directory number yet. So, we need to identify the special auto-registration name that’s been used, and create an entry in the database for the new phone, so that we can generate the appropriate MAC address config file and now we accept that registration with an acknowledgement. We notify the phone to come get that new file and now the phone will automatically reset and reboot once it gets that file. Now the SIP phone will load the config file and it’s now ready to go at that point, so it’s quite a process that these phones go through, especially initially in order to get registered and get all of the pertinent information set up on the device so that it is ready now to make calls.
What is in that SEPmac_address.cnf.xml file?
The file contains a list of CUCM server, in order, that the phone should register with. It lists the TCP ports it should use for SCCP communication. It also lists the firmware version for each device model and the service URLs that each device should be using.
The CUCM server sends other configurations, such as DNs, softkeys, and speed dials, via SCCP messages in the last phase of the registration process. The configuration files for SIP phones are generally larger than the equivalent files for SCCP phones. This is because SIP phones have no equivalent mechanism for configuring items that are set by SCCP messages on SCCP phones; these items must be included in the configuration file downloaded from TFTP.
TFTP Device Configuration XML File
Now let’s pretend that your IP phone is brand new, out of the box and you’re plugging it in for the first time. What is the expected behaviour? It’s going to take a little bit longer to boot up, it’s going to go through several iterations, you will see it on screen. Because what has to happen is the IP phone is going to look for a specific file from the TFTP server, and that specific file contains the MAC address. But because we’ve got this brand spanking new phone that doesn’t have a TFTP server file just yet, we have to download the XMLDefault.cnf.xml file. Now the IP phone obtains its list of Communications Managers, and it then attempts to auto-register to the primary server. And in that process that’s where you’re going to see things can slowdown, just a bit. Because it’s going to try to register with the Communications Manager. It then has to create its unique file, because that unique file is going to be what we’re going to leverage every time that phone reboots. And that’s going to make things happen quicker too, but it’s going to return information including the MAC address as part of that config file.
So, the IP phone with this MAC address, downloads this configuration file that it now has, specific to that phone and it’s going to contain the information for that IP phone to register with its Communications Manager. And again it’s going to see IP addresses here. So these IP addresses will give them a direct connection back to the Communications Manager server that is going to be hosting that IP phone for you.
Device Defaults
The Device Defaults page lists all the supported endpoints (with separate entries for SCCP and SIP as necessary), and the firmware load, device pool, and phone button template each endpoint uses by default. This allows an administrator to set useful system-wide defaults for any newly registered device of each type.
Softkey Template and Phone Button Template
The softkey template controls what softkey button functions are available to the user; these are typically used for feature access (conference, transfer, park, Extension Mobility, and so on). Seven softkey templates are available by default, and you can create as many more as your design requires.
The Phone Button template defines the behavior of the buttons to the right of the phone screen (for most models). Eighty (or more) are defined by default because there are unique templates for each supported phone type—and for most phones, a separate template for SCCP and SIP. The default templates typically provide two lines and as many speed dials as there are remaining buttons on a particular phone model; you can add and customize the templates to assign each button one of many different functions.
IP Phone Configuration
When you look at how you configure a phone in the Communications Manager, there’s really two different areas. There’s the actual device itself. That would include things like the calling search space it belongs to, AAR, all of your softkey templates and phone button templates, and what protocol it’s using. Then there’s the specific lines, so the directory numbers. The directory numbers may house different partitions and calling search spaces. They might have limitations on the maximum number of calls they can accept. There’s an external phone number mask that we could associate with them. And we can associate these lines with one or more devices. So there’s two different areas that we may need to configure on our IP phones.
Endpoint Basic Configuration Elements
When we get into the graphical user interface, the main administrative page of the Communications Manager, we have lots of options for our phones. We can set up those Date and Time groups, Presence capabilities, the Device Pool – we are going to love this because it’s kind of a template that we can add to our phones – the Security Profile, the Softkey Templates, what our phone buttons look like, Common Phone Profiles, and then if we do have SIP Phone we’ll go ahead and implement the needs of those SIP phones, under the SIP phones configuration. Here is list with some of the most important parameters:
- Date/Time Group
- Presence Group
- Device Pool
- Cisco Unified CM Group
- Regions
- Locations - Security Profile
- Softkey Template
- Phone Button Template
- Common Phone Profile
- SIP Phones
- SIP Profile (SIP Phones Only)
- Phone NTP Reference (SIP)
About TFTP server
TFTP is a critical service for IP Phones. The Phone use TFTP to download their config files, firmware and other data. Without TFTP, the phones simply do not function properly. When you make a configuration change to a device, CUCM creates or modifies a config file for the device and uploads it to the TFTP server. TFTP service much therefore provided by one or more CUCM servers in the cluster.
Note: A generic TFTP server will not have the integrated capability that a CUCM TFTP server does and will not correctly fulfill the role.
Understanding DIAL-PEERS or CALL LEGS
- Define the voice route path - POTS CALL LEGS
- Matched Inbound and Outbound - VOIP CALL LEGS
POTS DIAL-PEERS : traditional telephony connections, anything without an IP address (PORT)
VOIP DIAL-PEERS : packet-based network connections (IP ADDRESSES)
Destination pattern wildcards
. Indicates a single-digit placeholder. For example, 555…. matches any dialed string beginning with 555, plus at least four additional digits.
[] Indicates a range of digits. A consecutive range indicated with a hyphen (-), or a nonconsecutive range with a comma (,). Hyphens and commas can be used in combination ie [5-7,9].
Note Only single-digit ranges are supported. ie [98-102] is invalid.
() Indicates a pattern; for example, 408(555). It is used in conjunction with the symbol ?, %, or +.
? Indicates that the preceding digit occurred zero or one time. Enter ctrl-v before entering ? from your keyboard.
% Indicates that the preceding digit occurred zero or more times. This functions the same as the “” used in regular expression.
+ Indicates that the preceding digit occurred one or more times.
T Indicates the interdigit timeout. The router pauses to collect additional dialed digits.
Asterisk () and pound sign (#)–These characters on standard touch-tone dial pads can be used anywhere in the pattern. They can be used as the leading character (for example, *650), except on the Cisco 3600 series.Dollar sign ($)–Disables variable-length matching. It must be used at the end of the dial string.Circumflex symbol (^)–When used within brackets, allows you to eliminate a digit from considerationfor dial peer matching purposes. For example, a destination pattern including [^7] would not match any string beginning with 7.
COR Behaviour
With class of restriction, I like to equate it to having a lock and having a key ring with lots of keys on it. Because, we have an outgoing COR list, that’s the lock, then we have an incoming COR list, this contains the keys to open the lock. So, the way it works is an outgoing COR list is actually a subset of your incoming COR list and if we match the call is routed. If the outgoing COR list is not a subset of the incoming COR list we’re blocked.
