How-To: copying data from one esxi 6.5 to another (6.7)



simply check hostname to avoid mistakes due to confusion, with the following

esxcli system hostname get

Screenshot 2020-04-05 at 3.31.28 AM

Now, To see firewall action ACTUAL properties,¬† we all know DROP is bad ūüôā

Screenshot 2020-04-05 at 3.31.46 AM

esxcli network firewall get

At this point, might be worth enabling rule to allow SCP over SSH with the following

esxcli network firewall ruleset set –ruleset-id sshClient –enabled=true


Now COPY with this command from ESXI253 (source ESXI i.e.,

scp /vmfs/volumes/500-253-A/2020-WIN-COLLIERS/* root@

Screenshot 2020-04-05 at 3.32.32 AM

this was installed windows 2012 VM i wanted to copy complete Directory



Another useful command, if you’re willing to copy whole Directory files to other server Datastore Directory

scp -r /vmfs/volumes/DS-1000-D-NEW/ISO root@

Note – Most important thing in above command is the no-slash at source, but the destination with-slash

Screenshot 2020-04-05 at 9.07.15 AM


just so you know there’s tons of commands to achieve what you want.


SAF Configuration

SAF Configuration is the prescribed approach for inter-site (on-net) calling where you’ve sites spread over multiple cluster.

Let’s take example of 2 sites, Site-A registered over Cluster-A and¬† Site-B registered over Cluster-B.


  • Phones should be registered;
  • There should be routing already working;
  • Cluster ID [under Enterprise Paramters should be unique]
  • I assume we don’t have any PT/CSS in picture and you’ve fair understanding on same.


  • Create SIP Trunk on both cluster’s ( only need ‘Device Security Profile’ and ‘SIP Profile’ ) again nothing specific.

Screen Shot 2015-08-02 at 9.38.52 PM

  • Create SAF Security Profile on each cluster

Screen Shot 2015-08-02 at 9.44.00 PM

  • Specify SAF Forwarder on each cluster

Screen Shot 2015-08-02 at 9.44.29 PM

  • Create Group for DN / On-Net Extensions, under CCD

Screen Shot 2015-08-02 at 9.44.49 PM

Screen Shot 2015-08-02 at 9.45.12 PM

  • Tell about on-net Extensions / DIDs to Call Control Discovery Service

Screen Shot 2015-08-02 at 9.45.32 PM

  • Ofcourse now you want these to be advertised, to other clusters

Screen Shot 2015-08-02 at 9.45.51 PM

  • Whatever being advertised from one end, needs to requested by other cluster.

Screen Shot 2015-08-02 at 9.46.10 PM

  • As SAF came out of EIGRP (it does not matter what you have prevailing as routing protocol in your network i.e., i myself had OSPF) some SAF set of commands configuration needed on both routers.

Screen Shot 2015-08-02 at 9.51.48 PM

  • on R2 Router

Screen Shot 2015-08-02 at 9.52.36 PM

  • Testing / Verification – Login to RTMT, Call Manager Tab to see what being published and registered/established.

Screen Shot 2015-08-02 at 9.54.25 PM Screen Shot 2015-08-02 at 9.54.44 PM Screen Shot 2015-08-02 at 9.56.13 PM Screen Shot 2015-08-02 at 9.56.53 PM

Hope that was OK!

New Features – CUCM 10.X

Already, here is some stuff i could grab from xyz places to start with for CUCM 10.X !

  • Only VMWare Deployment – Bye-Bye MCS servers
  • Hostname and IP Change – For changing the HN or IP of the node, only single step now.
  • RTP and SRTP Port Ranges Configuration – For the first time Administrator’s are given option to configure port ranges that are used by Annunciator, CFB, MTP, MOH and SIP Endpoints. For IPVMS Service Parameters 9051-61000 and SIP End-Points 2048-65535.
  • Preemptable Number Configurations – Calls like 911 or emergency won’t be disconnected. MLPP Preemption checkbox in Calling Party Transformation Pattern Settings Needed.
  • LDAP Look First/Commercial Cost Avoidance – Calling External number results in check of LDAP first for same user if internal number exists.
  • Multiple Codecs in SDP Answer – Endpoint behind SIP Trunk answers all possible codecs it supports. CUCM identifies Trunk capability for multiple codecs
  • User Data Services – Personal Directory and Phone Services supported through Data Services, if disabled then no phone services and Directory button.
  • Video on Hold – For Video contact centres on CUCM new option for VOH server i.e., Media content server separately provisioned to store and stream FHD, HD and 360P. Cisco Media Sense does the job.
  • Collaboration Edge – to connect without Cisco AnyConnect or other VPN solutions (IM, Call-Control and visual voicemail for Jabber)
  • Jabber Guest – Guest user connects with company employees on Jabber i.e., jabber video
  • LRG Enhancement – Multiple LRGs association possibility for Emergency Dialing per Device Pool. Eventually reduces number of Route Lists.
  • UC Self-Care / Self-Provisioning – Basically advanced User Options. Like TAPS(with CCX environment) in past, now allows user to do provisioning (How – dial unique number and enter extension…to phone settings, names, directories, speed-dials and other¬†personal phone settings) few user prompts won’t be bad if Administrator is set free.
  • Incoming Called-Party Transformation – For MGCP Gateways, SIP Trunks and H323 Trunks/Gateways.
  • Urgent Priority DNs – Previously was with T302 timer help for Translation Pattern, Route Pattern or Hunt Groups.
  • IM & Presence – Now part of CUCM Cluster itself.
  • Audit Log Viewer – New option in RTMT displays historical configurations records.
  • Translation Pattern Enhancement – TPs can now use Originator’s Calling Search Space. More Granularity and Less Patterns can do the job easily
  • Prime Collaboration Provisioning Standard – to administer CUCM, CUCME, Unity, Unity Connection and CUE. Integrated with LDAP.
  • Prime Collaboration Assurance Standard – provides additional monitoring tools for the UC environment including CUCM, Unity Connection, and TelePresence.¬†Also, you can customize performance alerts based on user-configurable thresholds to facilitate proactive notification of problems.
  • Network-Based Call Recording – enables call recording for any device . Recording happening at gateway, including mobility capture.
  • Intelligent Proximity – Allows customers to automatically link a mobile phone with a corporate desk phone. Above mobility more seamless, though limited number of devices now.

It would be worth doing some YouTube videos / screenshots for above.

Passed IE Collab !

Finally, i cleared my IE Collab exam…YAY!

it was fun though during the whole lab exam i was stable and hungry. I decided not to have something cause i wasnt sure if i have something that would make me feel sleepy or low on energy cause of carbs…

Best part was whole situation was under control through out. After configurations were done almost, i focussed on verify my configurations and outcome. i almost did verify each task 6-8 times.

Few Facts;

  • SIP Phones i’m in love with and really like the way they behave(as i dont have much in office)
  • Video endpoints again are great too (i didn’t had deployed in office either)
  • Whats Next ??? was one of the question never bothered me, as i’m pretty good in deciding my interest/glide path for future.
  • Guess What, How did i celebrate ??? I upgraded my home lab to CUCM 10.5 cluster complete including MCP this time and most likely i may be seen bidding for some advanced equipment on
  • How do i feel ??? thats important..huh. i feel as i used to, bit more happy though as i have one target achieved.
  • Be ready for some posts on new and advanced features of CUCM 10.5 and some new¬†features.


  1. 3 Services mandatory for EMCC to work on CM 8.X
    1. Call Manager
    2. Cisco TFTP
    3. EM Service
  2. Create Service on CM Administration
    1. http://<EMCC IP>:8080/emapp/EMAppServlet?device=#DEVICENAME#&EMCC=#EMCC#
  3. Add Device Profile (Cisco 7975 SCCP) udp_7975 DN#45002
    1. Subscribe EMCC service
  4. Add End User HQU1
    1. Associate controlled profile udp_7975
    2. Subscribe EMCC
  5. Subscribe EMCC to the Phone DN #45001
    1. Also Enable Extension Mobility.
  6. OS Administration
    1. Security > Bulk Certificate Management > Enter SFTP SERVER Address (Should be reachable to Both Clusters)
    2. Directory Path to be set “/emcc/” and SAVE.
    3. EXPORT Certificate Type “ALL”¬† (Needs to be done on both clusters)
    5. Import New Certificates to Both Clusters.
  7. Go to Servicability
    1. Service Activation > Enable Bulk Provisioning Service > Started
  8. CM Administration
    1. Device > Device Settings > Common Device Configuration > Add New
    2. “Default CDC” and Save
    3. Bulk Administration > EMCC > EMCC Template > “EMCC_DEV_TEMP”
    4. Assign Device Pool and SIP Profile > Save
    5. Bulk Administration > EMCC > Insert/Update EMCC
    6. Select “Update EMCC Devices” & Choose EMCC Template…RUN IMMEDIATELY.
    7. Check Bulk Administration Tool > Job Scheduler > Status “Completed”
    8. Again Bulk Administration > EMCC > Insert/Update EMCC
    9. Select “Insert EMCC Devices” & Put “5” for No. of Devices to be added*…RUN IMMEDIATELY.
    10. Check Bulk Administration Tool > Job Scheduler > Status “Completed”
  9. System > Enterprise Parameters > CLUSTER ID (Should be Unique****)
  10. System > Geolocation Filter > Add New > Name “emcc_geofilter”
    1. Also Tick/Check¬† “country using the…State, Region….City or Township” SAVE.
    1. Update Fields “Default TFTP Server” “EMCC Geolocation Filter” “Default Server for Remote Cluster Updates” SAVE
    1. Assign “Device Pool”, “SIP Trunk Security Profile” and “SIP Profile”
    2. IMPORTANT: Check/Tick “Send Geolocation Information”
  13. Advanced Features > EMCC > EMCC Intercluster Service Profile
    1. Check/Tick EMCC “Active”, PSTN Access & RSVP Agent as “Active”
  • Advanced Features > EMCC > EMCC Remote Cluster
    1. Cluster ID copy/paste in from Remote Cluster to Home Cluster and FQDN/IP Address. VICE-VERSA TOOOOOOO!
    2. Update & See Remote Cluster will populate Home Cluster Details.
    3. Update & See Home Cluster will populate Remote Cluster Details.

TCL Script

Put a text file on router flash without file transfer

Say, you want to put a text-based file on a router’s flash memory.¬† It could be a license file, a config file, or some scripts.

The ‘regular’ way is to use TFTP/FTP to transfer the file.¬† But it could be a problem in some circumstances.¬† For example:

1) You’re accessing the router through a terminal server (console port).¬† There’s no network connectivity between your PC and the router.
2) Firewall/security policy prevents TFTP/FTP from happening.

It would be great if Cisco IOS has a ‘notepad’ (or ‘vi’) so we can create/edit the file from IOS CLI.¬† But it has not.

Fortunately, Cisco IOS has tclsh.  You may use tclsh create a file in flash memory and write some text to it.

Router(tcl)#puts [open “flash:script.txt” w+] “Some sample text”

Router#dir flash:
Directory of flash:/
2 -rwx 2072 Jan 9 2014 10:24:23 -06:00 multiple-fs
3 -rwx 676 Feb 28 1993 18:01:35 -06:00 vlan.dat
4 -rwx 3570 Jan 9 2014 10:24:23 -06:00 private-config.text
5 -rwx 16 Jun 9 2014 09:34:35 -05:00 script.txt
6 drwx 192 Feb 28 1993 18:06:36 -06:00 c2960-lanbasek9-mz.122-55.SE7
562 -rwx 7340 Jan 9 2014 10:24:23 -06:00 config.text

32514048 bytes total (18987520 bytes free)

Router#more flash:script.txt
Some sample text


What if you want to create a file with multiple lines?¬† Just escape the ‘enter’ with ‘\n’.¬† For example:

Router(tcl)#puts [open “flash:script.txt” w+] “Line 1 \n Line 2 \n Line 3”

Hope this helps!


UCCX – Contact Center Express

  • A complete customer Interaction Management System.
  • Comes in 4 different packages (flavors).

CCX Primary Functions

    1. Compatible with CM/CME.
    2. Software application provides self-service type of activities i.e., AA, Bank, Customer Care Services.
    3. Caller provides information via DTMF/spoken word and IVR responses back via Audio Speech, TTS, Generated Prompts.
  • ACD AUTOMATIC CALL DISTRIBUTION (Standard, Enhanced & Premium) Various levels of customer interaction
    1. Compatible with CM/CME.Screen Shot 2014-09-12 at 3.27.33 AM
    2. Software application provides inbound/outbound calls to Customer Service Representatives.
    3. User Agents as targets to route i.e., sales, tech-support calls or emails.

IP IVR Provides

  • IP Call Queuing
  • IP intelligent voice response functionality for call-centres.

CCX Standard Provides

  • Basic IVR port option (No License)
  • Conditional Call-Routing and Queuing of inbound ACD calls.
  • Resource Group or Skill Based call routing.
  • Cisco IP Phone Agent.
  • No CAD but CSD.
  • 1 ACD Line and 3 Secondary Lines for Historical Reporting.
  • AA & Spoken Name upload option provided.
  • Integration with ICM as subordinate ACD.
  • Integrate with CUPS.
  • Real time & Historical Reporting.
  • SNMP and Alarm Servicves

CCX Enhanced Provides

  • Standard Provided features
  • High-Avaialblility (with additional licenses)
  • Priority queuing
  • CAD (standard desktoip & Browser Edition)
  • CSD Advanced
  • Agent Level Routing
  • Additional Real time and Historical Rporting
  • Also includes JAVA License enabling customized Java Extensions.

CCX Premium Provides

  • Enchanced Provided features
  • Advanced IVR port options i.e., ODBC, RMI, VXML, OB EM
  • MRCP Integration
  • Remote Silent Monitor
  • CAD (Multi-tab Browser)
  • Agent Email
  • Workforce Optimizations WM(KRA,KPI) QM (Screen Recording)

CME & CCX Deployment Limitations

  • Only SCCP Phones.
  • Only G.711 CODEC
  • CAD Call-Control Feature Disabled.
  • Supervisor can’t Barge/Intercept.
  • Only 1 instance of CCX.
  • No High-Availability.
  • No Presence Integration.
  • No Outbound Preview Dialer.
  • No Remote-Monitoring.
  • No ICME integration for CCE Deployments.
  • User Creation & configuration maintained by CCX.
  • No CTI ports (CCG created as part of Install)
  • CCX can run either CCX or IVR.

Things to Remember

  • CCX 8.0 = cm7.1(3) – 8.0(1)
  • CME 7.1 = 8.0
  • CAD = 8.0
  • WO QM = 8.0
  • WO WM = 8.3(4)
    1. Physical CPU dedication to VM.
    2. Memory Reservation 4 GB.
    3. NIC GIG/FE.
    4. Avoid OB Contention.

Preliminary Information Requirements (SIZING CCX)
Designers are advised to create a sizing document to do the following:
‚ÄĘScope out the preliminary configuration information for the Cisco Unified CCX server.
‚ÄĘSize the gateways for the system.
To determine the size of the call center, obtain answers to the following questions:
‚ÄĘHow many IVR ports do you need?
‚ÄĘHow many PSTN gateway trunk ports do you need?
‚ÄĘHow many agents will answer incoming calls?
Average handle time (AHT) – Average duration of a call plus after-call work time, i.e., wrap-up time after the caller hangs up.
Average IVR port usage time – Total time for prompt playout and/or menu navigation (if any) in the Cisco Unified CCX script. This should not include the queue time the caller spends waiting in queue before an agent becomes available. Queue time is calculated using Erlang-C
.Service level goal for agents – Percentage of calls answered by agents within a specific number of seconds.
Busy Hour Call Attempts (BHCA) – Average number of calls received in a busy hour.
Grade of service (% blockage) for gateway ports to the PSTN – Percentage of calls that get a busy tone (no gateway trunks available) out of the total BHCA


  • GWs – To Convert Media Type (T1/E1/ISDN)
  • RTRs – To route VOIP Traffic to-and-from CM.
  • CM – Call processing Engine IP PBX.
  • CCX – Performs IVR Functions and ACD Functions.
  • SE – To create or modify scripts.
  • CDWFA – Allows configuration of Agent Interface setting up Reason Codes, Defining Agent Work Flows & Keystroke Macros.
  • CCX HRC – Provides Information about call activities of CCX (view, print, sort, filter, schedule reports, PDF, CSV, Custom Reports)
  • CCX Agent – Requires Phone & CAD. Phone connects to CM for Call Control, CAD Connects to CCX for Agent Control.
  • External Servers – WO, ASR, TTS, DB Servers.
  • CCX integrates with MRCP compliant ASR & TTS Servers (NUANCE/IBM)


Screen Shot 2014-09-12 at 3.27.55 AM

CCX ENGINE consists

  • Core ACD, IVR & CTI Services.
  • Processes and Accepts Calls/Web contacts.
  • Communicatea with CM (JTAPI)
  • Exexution of Sxcripts
  • System Management and Administration.
  • Agent State Machine for Agent Monitoring and Selection.
  • Communicates with CAD for Agent State Control, Call Control & CTI Screenpop.

Screen Shot 2014-09-12 at 3.27.33 AM


  • To store CCX Data (4 Data Stores)
    1. Agent Data Store – Agents Logs, Statistics, Pointers to recorded files.
    2. Configuration Data Store – Agents, Skills, RG, Teams, CSQ Informaiton.
    3. Historical Data Store – CCDR’s
    4. Respository Data Store – Prompts, Grammars and Documents.


  • For monitoring and recording Agent Calls.


  • To Accept and Store Agent Call Recordings.
    1. will work on G.711 and G.729 Phones.
    2. But not work on Encrypted RTP.
    3. CCX Provided SPAN & Desktop Monitoring.

CCX Deployment HAoWAN

  • Deploy ASR & TTS servers locally.
  • CCX setup to use local CM, as primary.
  • 2 sets of CTI Ports (master/stand by)
  • Restoration of WAN Link during OOH.
  • No support for VPN tunneling across WAN.

CCX Integration Models

  • Standalone IP IVR
  • IP IVR with ICM
  • IP IVR with ICM & CCE
  • CCX Standalone (premium no Queue point)


CTI Ports configured/associated with JTAPI UA, that will provide logical Connection with CCX and CTI Services.

  • Required for each call during script processing.
  • 1 CTI port is required for each call connection to CCX.

IVR Ports in CCX

  • Basic IVR Ports (Routing ScreenPOP)
    1. Provide Queue-point,
    2. custom messaging & prompting,
    3. caller input collection & processing via DTMF Available in Standard & ENhanced
  • Advanced IVR Ports¬†
    1. Licensed on Per-inbound voice seat-basis with Premium Only.
    2. 1 inbound voice-seat = 2 Advanced IVR Ports.

Screen Shot 2014-09-12 at 3.28.22 AM


QOS i.e., Quality of Service is ability for us to provide consistent predictable performance based on provisioning network LAN and WAN devices to provide special services to traffic we deem important or interesting.

Screen Shot 2014-09-12 at 12.09.37 AM

Disadvantages to PSTN

  • No dedicated connection as with circuit-switched network.
  • No inherent guarantee the packet will arrive(packet loss)
  • Not always enough BW available(but much easier to add)
  • Delay can occur at various router hops along the way(End-to-end delay)
  • Delay can and often does vary greatly from hop-to-hop(Jitter)

Types of Delay

  • DSP Delay
  • Packetization/Processing Delay
  • Queuing Delay
  • Serialization Delay
  • Propagation Delay
  • Dejitter Buffer Delay

Screen Shot 2014-09-12 at 12.06.05 AM


Ways to mitigate BW & DELAY

  1. Transit VOICE/VIDEO (important) packets first.
  2. Compress L2 Payload and/or L3(IP)/L4(RTP) Header.

Ways to mitigate PACKET LOSS

  1. Guarantee adequate BW to packets requiring it.
  2. Prevent congestion from occurring by dropping less-important packets before it begins.

Screen Shot 2014-09-12 at 12.06.25 AM


  • Smooth (flows at even rate, doesn’t burst)
  • Benign (not greedy for lots of BW fairly low per call)
  • Drop-sensitive
  • Delay-sensitive
  • UDP-based (can’t be retransmitted as no confirmation, TCP takes times to setup 3-way handshake)
  • Needs priority


  • Bursty (part of picture moves rest is static on screen cause of keyframes)
  • Greedy (more BW you define, better the picture quality is)
  • Drop-sensitive
  • Delay-sensitive
  • UDP-based
  • Needs Priority


  • Can be Smooth/Bursty (typically later)
  • Can be Benign/Greedy (typically later)
  • Drop-insensitive
  • Delay-Insensitive
  • Can be UDP, TCP-based retransmits.

Important Steps to Provision QOS

  • Identify Traffic and its requirements
    1. identify all types of traffic on the network.
    2. determine how important each type of traffic is (or is not) to the business.
    3. determine requirements for service levels and response times per traffic type.
  • Divide Traffic into various classes
    1. Voice and Video media (RTP) i.e., priority and low-latency
    2. Voice and Video signaling .i.e., guaranteed bandwidth
    3. Other important business Apps .i.e., SAP, SQL,E-Commerce might Guaranteed Bandwidth
    4. Everything Else .i.e., Best Effort (No Guarantee at all)
  • Define Policies for each traffic class
    1. Defining minimum (and possibly maximum) BW guarantee to each class
    2. Assign priorities to classes that require them.
    3. Manage the congestion.

How to Implement QOS

  • Using CLI i.e., MQC
  • Auto QOS
  • QOS Policy-Manager .i.e, QPM

3 Models of QOS Deployment

Screen Shot 2014-09-12 at 12.15.14 AM

  • Best-Effort
  • Intserv
    1. Integrated Service using RSVP(CAC) i.e., every router in path must support.
    2. Applications basically signal the network control plane to inform/instruct that they need QOS.
  • Screen Shot 2014-09-12 at 12.05.30 AM
  • Diffserv (Differentiated Services)
    1. Network does the work of classifying different types of traffic and assigning DSCP markings to place them into QOS classes.
    2. Because bot eevery device in the IP Path must support Diffserv to make it still very effective, it inherently becomes the most scalable and therefore most deployed today.
    3. Terminology [DSCP (value in IP header used to classify/define traffic) + BA (Grouping of packets with same DSCP/ given class)+ PHB (the forwarding behavior applied to BA at any given node in the network) ]

Screen Shot 2014-09-12 at 12.03.59 AM


  • Classification & Marking ( first element to QOS policy to classify/identify the traffic that is to be treated differently. Marking tools can set an attribute to a frame/packet to a specific value i.e., either phone marks or closest ingress-point, NBAR en-routes also does it)
  • Policing ( determines whether packets are conforming to administratively defined traffic rates and take action accordingly. such action would include marking, remarking or dropping a packet)
  • Scheduling (Congestion Management-Queuing¬† & Congestion Avoidance-Dropping)¬†¬† (scheduling tools determine how a packet/frame exits a device. Queuing algorithms are activated only when a device is experiencing congestion and are deactivated when the congestion clears )
  • Link-Specific Mechanisms (Shaping, Fragmentation, Compression, TX-Ring)¬†¬† (offers network administration tools to optimize link utilization)

Screen Shot 2014-09-12 at 12.18.47 AM

Screen Shot 2014-09-12 at 12.07.03 AM


  • Header Compression (used with RTP & RTCP) Results in decreased consumption of BW. Delay reduces automatically.
  • FRTS Delays excess traffic using buffer or queuing mechanisms to hold packets and shape the dlow when Data > expected.
  • FRF.12 (Frame Relay Fragmentation and Implementation Agreement) Ensures predictability for voice traffic aiming to provide better throughput on low-speed serial links bu interleaving delay-sensitive traffic on one VC with fragments of a long gram on another VC utilizing same interface.
  • PSTN Fallback Provides mechanism to monitor congestion in IP network and either direct calls to PSTN or reject calls based on network congestion.
  • IP RTP Priority & Frame Relay IP RTP Priority Provides strict priority queuing scheme that allows delay-sensitive data such as voice to be dequeued-and-sent before packets in other queues are dequeued. Specially useful for slow-speed links including FR, MLP, and T1 ATM Links, works with WFQ and CBWFQ.
  • IP to ATM COS Feature suite that maps QOS characteristics between IP & ATM. Offers differential service classes across the entire WAN. Gives Mission-Critical Apps exceptional service during periods of high-network-usage and congestion.
  • LLQ Provides strict priority queuing on ATM VC and Serial Interfaces. In actual this feature allows you to configure the priority status for a class within CBWFQ not limited to UDP port numbers as is IP RTP priority.
  • MLP Allows large packets to be multi-link encapsulated and fragmented so that they are small enough to satisfy the delay requirements if real time traffic. Also provides special queue.
  • RSVP It supports the reservation of resources across the IP networks. Allows end-systems to request QOS guarantees from the network. Networks using VOIP, RSVP with PQ, TS and Voice Call-Signaling can provide CAC for voice-traffic. Cisco also provides RSVP support for LLQ & Frame Relay.


  • Classification and Marking
    1. CS3 best practice today for marking signaling traffic
    2. CM and Phones mark DSCP properly
    3. VOIP Dial-Peers and MGCP mark all signaling traffic to AF31 by default.
  • Policing
    1. CAR i.e., commited access-rate or todays class-based policing.
  • Queuing (Congestion Management)
    2. Screen Shot 2014-09-12 at 12.04.37 AM
  • Congestion Avoidance
    1. RED (Discard) or WRED (weight based)
  • Shaping
    1. FRTS (on FR interfaces) or GTS(All other interfaces)
  • Link-Specific Mechanisms
    1. Compression
    2. Traffic-Shaping
    3. Link-Fragmentation and Interleaving (FRF.12, MLPPP)

Screen Shot 2014-09-12 at 12.19.20 AM


  • Classification
    1. Explicit classification  (based on ACLs)
    2. Trust (conditional/outright) L3 DSCP/CDP or LLDP if not cisco phone.
  • Marking
    1. L3 DSCP or L2 COS?  (need 802.1Q header for 802.1P bits)
  • Mapping
    1. L2 COS to L3 DSCP / L3 DSCP to L2 COS / L3 to L3
  • Ingress Interface Queuing (switch)
  • Egress Interface Queuing (router)
  • Scavenger Traffic Policing
    1. Drop or Policed-DSCP for future rate-limiting for offending traffic
    2. Microflow(per-flow) or Aggregate(all of them)
    3. Interface or VLAN based
  • Memory and Buffers
  • Weighted Tail-Drop Thresholds.


Screen Shot 2014-09-12 at 12.19.01 AM

Screen Shot 2014-09-12 at 1.04.59 AM

  • IPV4 – 3 most significant bits of TOS Byte are called IP Precedence (IPP) other bits are unused.
  • Diffserv – 6 most significant bits of TOS Byte are called DSCP; remaining 2 bits are used for flow-control.
  • Diffserv is backward compatible with IP Precedence.
  • DSCP first 3 bits¬† work as class-selector.
  • DSCP last 3 bits work as Drop-probability and latency.

Screen Shot 2014-09-12 at 12.20.07 AM

Screen Shot 2014-09-12 at 12.04.26 AM

802.1Q Header

  • 802.1P user priority field also called COS.
  • Different types of traffic are assigned different COS Values.
  • COS 6 and 7 are reserved for network use.

Screen Shot 2014-09-12 at 1.04.27 AM

Screen Shot 2014-09-12 at 1.04.46 AM

Screen Shot 2014-09-12 at 1.05.11 AM


  • EF Expedited Forwarding (46)
  • CSx Class-Selector=x (IPP backwards compatible) 8,16,24,32,46,48,56
  • AFxy Assured Forwarding (only 1-4 used for AF classes) AF41>AF43 [y=Drop Probability] 10,12,14/18,20,22/26,28,30/34,36,38,46
  • BE Best-Effort (0)

Screen Shot 2014-09-12 at 1.16.49 AM

Screen Shot 2014-09-12 at 1.17.21 AM


  • Queuing algorithms manage the front-end of the queue.
  • Congestion avoidance algorithms manage the tail of the queue.
  • WRED
    1. WRED can operate in Diffserv complaint mode.
    2. Drops packets according to their DSCP marking
    3. WRED works best with TCP based applications like Data.


  • Egress Only.
  • Out-of-profile packets are queued until buffer gets full and only then discarded (tail-drop).
  • Buffering reduces TCP retransmits.
  • Marking/Remarking not supported, dropping occurs when buffer gets full.
  • Shaping supports FR congestion interaction.


  • Either Egress or Ingress(preferred)
  • Out-of-profile packets are discarded.
  • Dropping causes TCP retransmits.
  • Allows for Marking/Remarking packets, instead of Dropping.
  • Less Buffer (memory) usage.

Both above are similar at first, but different in execution.


  • IETF designed peer-to-peer protocol.(each side can take decisions)
  • Based on HTTP and SMTP messages.
  • can be used with any kind of POTS circuits.
  • By default uses UDP port 5060, but can be changed to TCP.
  • Needs local dial-plan on IOS GW (decentralized)
  • User-Agents(UA=UAC i.e., receiving message + UAS i.e., sending message)
  • SIP Header .i.e., responsible for setup, tear-down and maintenance of call.
  • SDP Header .i.e., used mainly to negotiate media but can contain much more info (session, time, media)
  • All PSTN signaling terminates on GW.
  • SIP communication between GW and CUCM.

Pros. for SIP

  • since already defined dial-plan on every GW, SRST has a ready dial-plan for fall-back.
  • voice translation-rules per GW.
  • Every pots type and MMOIP supported.
  • No audio loss when fallback to SRST.
  • Better fax support.

4 Logical types of SIP Servers

  • SIP Proxy server
  • SIP registrar server
  • SIP location server
  • SIP redirect server

All above 4 types of server functionality are combined into platforms CUCME & CUCM. Also note that they all 4 can be spread across physical servers.


Screen Shot 2014-09-11 at 11.06.01 PM


  • Developed by IETF, RFC #4566
  • used with SIP and MGCP, Can be used as standalone protocol to define RTP streams.
  • 3 main descriptions
    1. Session Description
    2. Time Description
    3. Media Description

Screen Shot 2014-09-11 at 11.06.30 PM

SIP CALL FLOWS (Early-Offer, Delayed-Offer or Early-Media)

Screen Shot 2014-09-11 at 11.06.50 PM

SIP CALL FLOW (in case of 2 GWs)

Screen Shot 2014-09-11 at 11.07.03 PM


Screen Shot 2014-09-11 at 11.07.11 PM


Screen Shot 2014-09-11 at 11.07.20 PM


Screen Shot 2014-09-11 at 11.06.39 PM


  • ITU-T Spec umbrella/suite(above protocol) based on ISDN Q.931.
  • Peer-to-peer protocol (any side GW/CA can take decisions).
  • Needs local dial-plan on IOS GW (Decentralized).
  • Sub-signaling protocols
    1. H.225 (for call-setup, by default uses port 1720, possible to change to UDP)
    2. H.225 RAS (comes with GK in picture Registration. Admission and status)
    3. H.245 (for negotating media dtmf-relay, codec, vad. Capabilities exchange, OLC for medai pass-through, flow-control messages, uses TCP port range 11000-11999)
    4. Audio codecs G.711, G.722, G.723, G.728, G.729a, and GSM
    5. Video codecs H.261, H.263, and H.264

  • Call signaling phase of an H.323 call uses RAS and H.225. to coordinate the offering and answering of a call between two parties. In addition to its functions related to call signaling, RAS provides messages to allow H.323 endpoints to associate themselves with network elements that can help with call routing and call admission control (which can prevent VoIP calls from over-utilizing network bandwidth and degrading the voice quality of all calls). H.225 handles the basic call-setup and tear-down .
  • Media control phase of an H.323 call uses H.245. to provide the endpoints with the information they need to send and receive properly encoded media streams to and from each other.
  • Media exchange phase of an H.323 call allows the speakers on either end of a call to exchange information. G.711, G.723, G.729a, and GSM are codecs that encode audio information, while H.263 allows an endpoint to encode and decode video information.

CallManager and the H.323 Control Model

H.323 defines several network elements and several models for controlling calls. The most important of the network elements are endpoints and gatekeepers .

H.323 endpoints are the entities that place and receive calls, and the protocols are therefore designed for the establishment of sessions in between these endpoints. However, endpoints need not necessarily be user devices, but instead can serve as gateways from one type of network to another or even as just a protocol suite to another protocol suite.

H.323 gatekeepers are centralized points that fulfill an administrative role. They can aggregate endpoint registrations, provide a centralized call routing function for endpoints, and manage network resources to ensure that network bandwidth is not oversubscribed.

Below Figure demonstrates three main control models for H.323 calls.

H.323 Call Models

  • Peer-to-peer model includes no gatekeeper at all. Endpoints communicate directly with each other, first via H.225 to coordinate the establishment of a call and then with H.245 to establish the media flow between the two endpoints. The other models include a gatekeeper. Using a gatekeeper necessitates the use of RAS, which permits endpoints to locate gatekeepers to serve them, register with those gatekeepers, and, when calls are placed, to ask for permission to admit calls into the network. In the direct signaling model, endpoints communicate with the gatekeeper using only RAS for call admissions and, when it admits calls, the gatekeeper provides enough information to the endpoints for them to negotiate H.225 call signaling and H.245 media control signaling with each other. In the gatekeeper-routed call, endpoints communicate not only RAS but also H.225 and H.245 signaling to the gatekeeper. Certain gatekeepers may also route the actual media flow through themselves by controlling the H.245 addresses.

CallManager fits into the H.323 model as follows:

  • CallManager acts as an H.323 endpoint – H.323 endpoints need not simply be user devices. Cisco IOS H.323 gateways, for instance, operate using VoIP protocols on their network interfaces and translate this signaling to activity on a circuit. Similarly, CallManager acts as an IP-to-IP call signaling and media control gateway to permit H.323 devices to communicate with non-H.323 devices such as SCCP endpoints. (Unlike Cisco IOS H.323 gateways, however, CallManager doesn’t terminate the media path .) Below figure shows the similar roles that Cisco IOS H.323 gateways and CallManager have.

    CallManager’s Role as H.323 Endpoint

    In H.323, in many respects, H.323 endpoints are completely autonomous entities. For example, if one endpoint in a call is supporting a variety of circuit-switched interfaces, the other endpoint doesn’t see those interfaces. To it, the other endpoint acts as a black box.

    From a configuration standpoint, this means that H.323 endpoints that act as gateways are call agents in their own right. In practice, this means that if you deploy Cisco IOS H.323 or other H.323 gateways, you must often configure call routing settings directly on both CallManager and the H.323 gateways that connect to it.

  • CallManager acts according to the peer-to-peer and direct signaling models – In H.323, endpoints either signal each other directly or, via an H.323 gatekeeper, indirectly. Using CallManager Administration, you can configure static associations between CallManager H.323 trunks and other CallManagers and H.323 gateways -the peer-to-peer model -or you can configure CallManager H.323 trunks to allow a gatekeeper to provide routing and call admission control via RAS -the direct signaling model.

    When the other end of an H.323 trunk is CallManager or a set of CallManagers, the connection is given the special term intercluster trunk (ICT). But, in fact, except for a few wrinkles in the media negotiation when CallManagers are connected via H.323 trunk, CallManager relates to other CallManagers as if they were H.323 gateways. (In the peer-to-peer model, you provision CallManager-to-CallManager trunks explicitly, so CallManager adjusts for the slightly different media signaling. In the gatekeeper models, CallManager automatically detects whether the other side is a CallManager and adjusts its signaling accordingly .)

    One other distinction between intercluster trunks and IP trunks to gateways is that CallManager supports H.323 Annex M, which permits the tunneling of the QSIG protocol over H.323 connections. CallManager uses QSIG tunneling to provide better feature transparency between clusters. The subsection “QSIG” goes into more detail about QSIG.

    Below figures show CallManager using the peer-to-peer and direct signaling models to access both H.323 gateways and other CallManagers.

    CallManager’s Support for H.323 Call Models

H.323 Call Signaling Details

This section goes into more detail about the actual signaling exchanges that occur in RAS, H.225, and H.245, and describes the ways in which CallManager uses these protocols.


H.323 endpoints use the Registration, Admission, and Status (RAS) protocol to interact with H.323 gatekeepers. RAS provides the following functions for endpoints:

  • Gatekeeper location, provided via the GRQ, GCF, and GRJ messages

  • Endpoint registration and KeepAlive, provided via the IRQ, IRR, RAI, RAC, RRQ, RCF, RRJ, URQ, UCF, and URJ messages

  • Call routing, call admissions, and call clearing, provided with the ARQ, ACF, ARJ, DRQ, DCF, DRJ, LRQ, and LCF messages

  • Mid-call bandwidth adjustments, provided via the BRQ, BCF, and BRJ messages

The sections that follow describe each of these functions in more detail. Each section first describes the standards-supported methods and then describes how these standards are implemented in CallManager.

At the end of this section, “RAS Messaging Details” provides a detailed breakout of the RAS messages CallManager sends and receives.

Finding a Gatekeeper

Endpoints that need to be controlled via H.323 must first locate a gatekeeper with which to register. H.323 provides two methods by which H.323 endpoints can find a gatekeeper: manual discovery and automatic discovery.

In manual discovery, the H.323 is statically configured with the address of the gatekeeper that serves it.

In automatic discovery, an H.323 endpoint broadcasts the GRQ (Gatekeeper Request) message on multicast address Gatekeepers in the network listening for such requests examine the specified address of the requestor (which can be either an alphanumeric alias or an E.164) and decide whether they want to serve the requesting endpoint. Gatekeepers that do want to be considered return a GCF (Gatekeeper Confirm) message; those that do not return a GRJ (Gatekeeper Reject) message or send no reply at all. Figure 4-13 depicts this procedure.

Automatic Gatekeeper Discovery

CallManager does not support automatic gatekeeper discovery. Instead, when you add a gatekeeper-controlled H.323 gateway or gatekeeper-controlled intercluster trunk, CallManager Administration allows you to specify the address of a primary gatekeeper that CallManager’s H.323 interface should register with.

Registering with a Gatekeeper

When a gatekeeper-controlled H.323 endpoint learns which gatekeepers are available to control it, it chooses to register with one of them.

To register, an H.323 endpoint issues an RRQ (Register Request) message, which the gatekeeper responds to with an RCF (Register Confirm) message if it wants to accept the registration and an RRJ (Register Reject) message if it wants to deny the registration. The RRQ contains information that the gatekeeper uses to authorize inbound and outbound calls to and from the endpoint. For instance, a registration contains the IP and port information that callers should use when they attempt to establish an H.225 session with the registering endpoint.

RAS is a protocol that operates over UDP. Unlike TCP, UDP does not establish and maintain connections. As a result, it is possible for an endpoint to register with a gatekeeper and then disappear from the network. The gatekeeper needs some way of knowing when this event occurs.

When you configure CallManager with the address of your gatekeeper, you specify a few values. One of these values is a gatekeeper refresh timeout, which defaults to 60 seconds (Registration Request Time To Live field on the Gatekeeper Configuration page). To keep the gatekeeper informed that CallManager is still operating, CallManager periodically sends a lightweight RRQ as a registration keepalive. If the H.323 gatekeeper doesn’t receive a periodic refresh of the registration, it expires the registration of the endpoint.

Several other fields configured on the Trunk Configuration page in CallManager Administration come into play during registration:

  • Zone settings

  • Technology prefix settings

  • Device pool settings


The zone setting helps gatekeepers determine which H.323 endpoints they control. Cisco IOS gatekeepers only accept registrations for endpoints that register with zone information that the gatekeeper’s configuration has defined as local to it. If you are using a gatekeeper, you should assign each CallManager cluster in your enterprise its own unique zone.

Technology Prefix

The technology prefix is a routing-related setting that allows a gatekeeper to differentiate between groups of endpoints in the same zone. When an endpoint registers, it communicates both its zone information and its technology prefix, and the gatekeeper associates these values. The section “Admitting Calls” describes how zones and technology prefixes relate when a gatekeeper admits calls on to the network.

Device Pool

Like other CallManager devices, you assign device pools to H.323 trunk devices. Device pools , which contain CallManager group lists, normally control which CallManager nodes a physical device such as an IP phone attempt to connect to during registration. But CallManager’s H.323 trunks are built directly in to the software and therefore cannot possibly lose their connection to CallManager. What’s going on?

Like with physical IP devices, the CallManager list for H.323 trunks relates to redundancy. If, when you created an H.323 trunk, you created it only a single CallManager and statically associated it with either a gateway or a single CallManager in another cluster, calls between endpoints in your enterprise connected via the H.323 trunk will fail if a particular CallManager crashes. For example, in below Figure, if either CallManager 1B or 2E fails, IP phones in cluster 1 cannot call IP phones in cluster 2.

Figure 4-14. Nonredundant H.323 Trunk

Therefore, when a CallManager cluster comes online, each CallManager starts one instance of the H.323 trunk on each configured H.323 trunk that includes the CallManager in its device pool. This behavior provides redundancy, but in a different way depending on whether the trunk is peer to peer or gatekeeper controlled.

When the trunk is peer to peer, in addition to configuring a device pool, you also configure a specific list of up to three IP addresses to which the H.323 trunk should connect. Because CallManager creates one H.323 trunk instance per CallManager in the CallManager list and the trunk is configured with up to three IP addresses to connect to in another cluster, this creates a 3×3 meshed connection between the clusters, as depicted in Figure below

Redundant Peer-to-Peer H.323 Trunk

When a user in one cluster calls a user in the other cluster over a peer-to-peer H.323 trunk, two load-sharing strategies occur.

The first load-sharing algorithm relates to which internal trunk device the CallManager cluster selects for placing the outbound call to the other cluster.

When CallManager attempts to place a call on behalf of a user, CallManager may create the call on any node in the cluster (although it typically creates the call on the same node as the caller). If CallManager detects that an H.323 trunk to the caller’s destination trunk exists on the same node as the call, CallManager uses that local instance. If no such local instance exists, CallManager chooses randomly from the H.323 trunk instances selected by the call. Assuming callers are evenly distributed around the active nodes in a cluster, this strategy can provide an even load across the H.323 trunk instances that the CallManager nodes create.

After a given H.323 trunk instance has been given the opportunity to extend the call to the other cluster, a round- robin approach takes over. For each subsequent call, the H.323 trunk instance selects the next IP address in its list of remote CallManager nodes. This process tends to spread out the burden of incoming peer-to-peer H.323 calls. It’s important that H.323 trunks in the receiving cluster be configured on the appropriate CallManagers to ensure the outbound call is accepted.

When an H.323 trunk is configured as gatekeeper controlled, the device pool provides a similar load-sharing mechanism via a different method.

When, in a given CallManager, an H.323 gatekeeper-controlled trunk comes online, it looks to see whether the other H.323 trunks in its device list have come online. When registering with the H.323 gatekeeper, CallManager specifies each other online H.323 trunk in its device pool as an alternate endpoint.

When resolving a dialed address, the H.323 gatekeeper, instead of specifying just a single H.323 call signaling address in the admission response, specifies all addresses sent in the original registration, including the alternate endpoints. In conjunction with the load-sharing mechanism whereby CallManager selects either a local or a random outbound trunk, this allows an H.323 trunk to attempt to route a call to alternate destinations if the attempt to contact the primary CallManager fails.

With gatekeeper-controlled H.323 trunks, the gatekeeper is also a component that is subject to failure. Therefore, just as endpoints can specify alternate endpoints when registering (via RRQ), when an endpoint registers, an H.323 gatekeeper can specify alternate gatekeepers when accepting a registration (via RCF). If, when an H.323 trunk attempts to place an outbound call, it cannot contact its gatekeeper, it can contact one of the alternate gatekeepers provided on the original registration.

When confirming the registration and providing a list of such alternate gatekeepers, the H.323 gatekeeper can specify the requiresRegistration field. When this field is set, an H.323 trunk issuing a call must actually register with one of the alternate gatekeepers before asking the alternate gatekeeper to admit the call.

Admitting Calls

When a gatekeeper-enabled endpoint wants to place or receive a call, it first asks for permission from the gatekeeper via the ARQ (Admissions Request) message. Although the ARQ includes information about the calling party and the called party, this information is only indirectly related to the actual call establishment. Rather, the sending of the ARQ is primarily related to policy enforcement.

When deploying an H.323 gatekeeper with CallManager, admissions requests hinge primarily on two factors. First, H.323 gatekeepers permit you to configure a multiple-cluster route plan in a centralized place. Without a gatekeeper, if your deployment exceeds two clusters, configuring a route plan to route calls in between clusters requires quite a bit of redundant configuration, because you must manually provision routes from cluster to cluster.

Below figure demonstrates the redundancy when you use the peer-to-peer model in a network requiring three or more clusters. In this figure, directory numbers are scattered around the enterprise with no use of number blocks to help algorithmically route the call. As a result, when a directory number is added to one cluster, specific routes must be provisioned in the other two clusters to route the call. Although it’s certainly possible to manage such a deployment, the configuration isn’t ideal.

Redundant Routing Information in a Multiple-Cluster Peer-to-Peer H.323 Network

If you use a gatekeeper-routed model instead, you can configure routing so that all calls that a given cluster doesn’t know how to route locally query the gatekeeper, which has a centralized configuration containing all routable addresses for the enterprise. This configuration scales much better because instead of having to configure a given address once in CallManager and once each in every other CallManager cluster, you just need to configure the address twice, no matter how many clusters you have. Figure 4-17 demonstrates this technique.

Routing Information in a Multiple-Cluster Gatekeeper-Controlled H.323 Network

As the section “Registering with a Gatekeeper” mentioned, zones also allow H.323 gatekeepers to set up policies related to endpoints grouped in a zone.

In particular, with IOS gateways, you can associate a certain amount of bandwidth that is available for calls to and from the zone. When you use gatekeeper-based call admission control, the gatekeeper tracks all gatekeeper-assisted H.323 calls and deducts a codec-based amount of bandwidth for each call placed between zones. When the bandwidth is exhausted, the gatekeeper permits no calls into or out of the depleted zone until one of the calls in the zone releases.

When an endpoint places a call, it provides the dialed address to the gatekeeper. The Cisco IOS gatekeeper compares these digits to the DN ranges assigned to each zone. For instance, assume cluster A manages directory number range 40000 to 49999, and cluster B manages directory number range 50000 to 59999. The following gatekeeper configuration allows the gatekeeper to understand the different numbering ranges:

zone local cluster-A

zone prefix cluster-A 4....

zone local cluster-B

zone prefix cluster-B 5....

If a caller dials 45555, CallManager’s gatekeeper-controlled H.323 trunk provides these digits to the gatekeeper. By comparing the dialed digits to the zone prefixes, the gatekeeper identifies the dialed address as being related to cluster A.

Upon identifying the zone, the Cisco gatekeeper looks for specifically registered endpoints in that zone. For instance, one could deploy a bunch of non-CallManager-controlled H.323 endpoints that specifically register their addresses with the Cisco gatekeeper.

When CallManager registers with a gatekeeper, it provides its zone information, but it does not provide any information related to specific endpoints; that is, CallManager does not register specific contacts for its SCCP phones, MGCP and H.323 gateways, route patterns, translation patterns, and so on. Instead, CallManager relies on a feature of the Cisco gatekeeper called the default technology prefix .

Normally, if the gatekeeper locates no specific registered contact, it rejects the call. But if you configure a default technology prefix with

gw-type-prefix 1# default-technology

then when no specific match is found, the Cisco gatekeeper looks for endpoints that have registered with the specified technology prefix (in this case, 1#) and chooses one of these endpoints to route the call to. In the example, the dialed digits 45555 would first bind to zone cluster A, then the gatekeeper would find no specifically registered alias, the gatekeeper would find its default technology prefix of 1#, and then the gatekeeper would offer the call to the H.323 trunks that registered in the cluster A zone with technology prefix 1#.

As a result, for intercluster routing, you’d configure the zone of cluster A’s H.323 trunks as cluster-A and its technology prefix as 1# and the zone of cluster B’s H.323 trunks as cluster-B and its technology prefix as 1# .

When users conversing over an admitted call finish their conversation, each H.323 endpoint notifies the gatekeeper of call termination via the DRQ (Disengage Request) message, which the gatekeeper accepts by sending a DCF (Disengage Confirm) message (and rejects by sending a DRJ [Disengage Reject] message, although it’s hard to conceive of a case in which a gatekeeper would do this in practice).

Changing Bandwidth Mid-Call

When configuring a gatekeeper with zone information, you can specify a maximum amount of bandwidth available for calls to and from that zone. When an H.323 endpoint asks the gatekeeper to admit the call to the network, it provides an amount of bandwidth that it wants the gatekeeper to grant. If the zone has been provisioned with a bandwidth limit, the gatekeeper compares the highest-bandwidth codec in the list of capabilities against the bandwidth available for the zone. If enough bandwidth is available, the gatekeeper admits the call.

Sometimes during a call, the codecs used by endpoints in a conversation can change. RAS includes the BRQ (Bandwidth Request) message to handle this event. If the gatekeeper wants to approve the bandwidth request, it issues a BCF (Bandwidth Confirm) message; if not, it returns a BRJ (Bandwidth Reject) message. If the bandwidth request is not granted, CallManager clears the affected call.

If the required bandwidth for an H.323 call changes during the call -for instance, if a phone in one region places the call on hold, and a phone in a different region retrieves the call -CallManager notifies the gatekeeper of the new information so that the gatekeeper can properly track the amount of network bandwidth available. Because an attempt to change bandwidth might get rejected and cause calls to drop, you must specifically enable bandwidth adjustment using CallManager service parameters.

Gatekeepers can also request that endpoints adjust bandwidth. If CallManager receives a BRQ, it responds with a BRJ.

RAS Messaging Details

The RAS message support provided by CallManager is the H.225 version 2 protocol. Refer to Appendix C for detailed information about specific fields in H.225 RAS messages.


H.225 is the protocol used in H.323 to actually offer a call to a destination. Unlike RAS, which is always supported over UDP, H.225 can run over UDP or TCP. CallManager supports H.225 over TCP but not UDP.

The default port for H.225 call signaling is well-known port 1720, although CallManager allows you to configure this per each H.323 device.

If multiple H.323 devices are configured with the same port, it would seem logical that CallManager could not reconcile messages from different H.323 endpoints. However, when accepting inbound H.225 messages from a given IP address, CallManager examines the source IP address to determine to which inbound trunk the message is inbound. CallManager delivers the inbound H.225 message to the H.323 trunk you’ve configured that specifies the sender’s IP address as its peer. However, this limitation does prevent you from specifying two different peer-to-peer H.323 trunks to the same IP address, which you might want to do if you want to take advantage of trunk-level policy settings such as calling search space or CallManager locations.

CallManager gatekeeper-controlled H.323 trunks act differently. When CallManager instantiates these trunks, it dynamically selects a port for receiving inbound messages and, when registering the trunk with the gatekeeper, provides the gatekeeper with this trunk value. As a result, with gatekeeper-controlled trunks, you can set up multiple H.323 trunks to apply different CallManager policy settings for different inbound calls. Similarly, when CallManager attempts to have a call admitted on to the network, one of the values that the gatekeeper specifies in the ACF message is the IP address and port to which CallManager should send the outbound call offering message.

When using gatekeeper-controlled trunks, you can specify one H.323 trunk that listens on port 1720. The service parameter Device Name of GK-controlled Trunk That Will Use Port 1720 enables you to specify the name of the gatekeeper-controlled H.323 trunk that listens on the well-known port. This can guarantee that H.323 endpoints on the other side of firewalls can still communicate with CallManager, because using dynamic ports might require that a firewall administrator unsecure more ports than are needed for processing H.323 calls.

Figure below presents the steps involved in call establishment via RAS and H.225.

H.225 Call Establishment

In Figure above, a non-H.323 caller composes the address of a called party and provides the information to CallManager, whose routing tables indicate that the call should be offered out an H.323 trunk.

If the trunk is gatekeeper-enabled, CallManager first asks for permission from the gatekeeper to place the call. The gatekeeper examines the dialed address (possibly transformed by CallManager), possibly checks to see whether there is enough bandwidth to admit the call based on the caller’s specified codec, and then admits the call, providing CallManager the IP address and port to which it must issue the call request.

After the gatekeeper (if one exists) grants permission, CallManager issues a call setup request to the selected gateway on the appropriate IP address and port. In some cases, this setup includes information about the media addresses of the caller, a process called fast start . H.245 describes the media processes related to fast start more extensively.

If the receiving H.323 gateway or CallManager is gatekeeper-controlled, it also queries the gatekeeper, this time to ask permission to receive a call. If such permission is granted, the receiving H.323 endpoint can present the caller to the called user. In the case of the trunk devices this chapter describes, the gateway is likely to issue a call setup request of its own to the connected network.

Assuming the receiving endpoint considers the address complete, it notifies CallManager with a PROCEED message. In many cases, this first backward message contains information about the receiving endpoint’s media information to enable CallManager to begin setting up media channels for conversation. This approach, called early media , helps ensure that after the called party answers none of her speech is dropped or “clipped” because no end-to-end media path has yet been established.

When the terminating network offers the call to the called party, it sends some sort of alerting indication (which varies according to the nature of the terminating network) to the receiving endpoint, which sends an H.225 ALERTING message to CallManager. This message allows CallManager to instruct the related gateway to provide ringback to the caller.

When the called party answers, the terminating network sends some sort of answer indication (which varies according to the nature of the terminating network) to the receiving gateway, which sends an H.225 CONNECT message. If media is not yet established between the caller and called party, the CONNECT message causes CallManager to issue the H.245 control messages needed to establish media.

After all media information has been exchanged, the two parties can converse . When one hangs up -in this case, the called party -the receiving gateway receives disconnection information, and issues an H.225 RELEASE COMPLETE message to CallManager. If the receiving endpoint and CallManager are gatekeeper-controlled, they issue DRQ messages to the gatekeeper to notify it of call termination.

Upon receiving RELEASE COMPLETE, CallManager starts tearing down the media channels between caller and called party, and the call concludes.

H.225 Messaging Details

The call signaling protocol that is supported in the H.323 protocol umbrella is H.225. H.225 includes the call signaling messages and the RAS messages. This section covers the specific details of the call signaling messages.

H.225 messages follow the ITU-T Q.931. In H.225, the user-user information element (UUIE) conveys the H.225-related information. The H.323 user information protocol data unit (PDU) is ASN.1-encoded. The ASN.1 is encoded using the basic aligned variant of the packed encoding rules as specified in X.691. The ASN.1 structure begins with H323-UserInformation.

Tables in Appendix C list each H.225 message and provide the specific fields of the H.225 call signaling messages that CallManager exchanges with an H.323 gateway or CallManager H.323 trunk (GW in table). See Appendix C for more information.


H.245 is the protocol used in H.323 to allow endpoints to coordinate their media.

Originally, in H.323, H.225 controlled just the actual mechanics of call offer and answer, and then H.245 took over to permit the exchange of media information. This approach sometimes led to clipped speech, so a procedure called fast start was defined.

Before learning about fast start, you need to understand the purer H.245 flows.

Like H.225, H.245 signaling occurs over a TCP session. Four major types of events occur over an H.245 session:

  • Determination of which side of the H.245 is the master and which is the slave – This assignment of roles allows the protocol to deal with glare conditions within the protocol and doesn’t directly relate to the media session itself.

  • Exchange of capabilities – This event permits the endpoints in the conversation to choose a media encoding method that they can be confident that the other side supports. Although CallManager can be configured to insert special devices called “transcoders” (discussed in Chapter 5) into a conversation between two parties that don’t otherwise share a common codec, direct end-to-end media streams are preferable.

  • Exchange of streaming IP address and port – This event tells the endpoints where to send their encoded media stream.

  • Mid-call button presses for interaction with connected services – Connected services include services such as voice mail and interactive voice response (IVR) units.

One of the functions of RAS in the gatekeeper-controlled model was to provide to the calling H.323 endpoint the IP address and port with which it should attempt to establish the H.225 session (TCP or UDP).

Similarly, one of the functions of the H.225 session is to provide the endpoints, both calling and called, with the IP address and port to which the H.245 session (TCP) should be established. In H.225, the caller generally provides the address to which the called party should send H.245 control messages on the SETUP message; the called party provides the address to which the calling party should send H.245 control messages on one of the following backward messages:




In the backward direction, the earlier this information is communicated, the earlier the end-to-end media connection can be established.

Finally, one of the functions of the H.245 session is to provide the endpoints with the IP address and port to which the actual encoded media should be sent (Real-Time Transport Protocol [RTP] headers, wrapped in UDP packets).

Because CallManager wants to be involved in the signaling session and the media control session but not the exchange of media, CallManager constructs the messages so that the signaling and media transport addresses point to it but the actual media addresses are those of the endpoints. Figure below demonstrates this progression.

Progressive Establishment of Call Sessions

Figure below illustrates a full H.245 message exchange between two H.323 endpoints.

H.245 Message Exchange

Use of H.245 to Provide Features

Because H.323 decouples the media control signaling from the call signaling, it provides a way for endpoints to change bandwidth mid-call, to add new channels of information to an existing call (such as video or application collaboration), or to renegotiate codecs mid-call.

The ITU specification H.450 defines a framework by which H.323 endpoints can provide call-related features such as transfer, call completion, call forwarding, and others. CallManager does not support this standard. Nevertheless, H.323 endpoints can participate in features in three ways:

  • CallManager supports the carriage of hookflash and dialed digits through the H.245 userInfoIndication field. This allows H.323 endpoints to interact with IVRs, voice mail systems, and so on.

  • Many CallManager features operate solely through the use of established calls. Although an H.323 endpoint cannot park a call, because the version of H.323 CallManager supports does not give CallManager a way to detect that the H.323 endpoint wants to invoke a feature, an H.323 endpoint can retrieve a parked call, because this operation requires only that an endpoint be able to offer a call containing the address of the park code.

  • H.323 endpoints can passively participate in features invoked via Cisco IP Phones via support for mid-call renegotiation of capabilities. H.323 requires that endpoints suspend sending media when they receive a mid-call request to select a new codec from an empty list of codecs. This capability is termed empty capability set support . What it means is that although an H.323 endpoint doesn’t have a way to initiate a transfer or hold or other mid-call feature, if an IP phone that the H.323 gateway is talking with initiates such a feature, the gateway’s media stream can be temporarily suspended while CallManager acts on the IP phone’s feature request. CallManager uses this capability to effect features such as hold and transfer.

Below figure demonstrates how CallManager uses the empty capability set to effect a call park and call park retrieval.

H.245 Feature-Related Message Exchange

In Figure above, 2000 parks a call from an H.323 gateway. CallManager tells the gateway that 2000 supports no codecs, which the gateway interprets as a requirement to suspend sending media to 2000. (As part of the park operation, CallManager also tells 1000 to cease sending media to the gateway.)

When 1000 dials the park code to retrieve the call, CallManager begins another H.245 media control session with the gateway. The H.323 gateway and 1000 exchange codecs via CallManager and, as part of the coordination of the media streams, CallManager provides the gateway the IP address and port to which it should send media and vice versa.

Not all H.323 endpoints support the receipt of empty capability sets. When configuring CallManager to support one of these gateways, you must configure the H.323 trunk to use a media termination point (MTP). The MTP is a device that CallManager can insert into a call to insulate endpoints from incompatibilities between each other’s media control processing, to provide dual-tone multifrequency (DTMF) relay, and to provide call progress tones. Chapter 5 goes into more details about MTPs.

H.245 Fast Connect

One charge levied against H.323 is that it can cause clipping -the loss of the first few seconds of a voice conversation (often the important first words “Hello?”) because media negotiation occurs in a completely separate phase from the actual call establishment.

With the use of fast connect (also called fast start ), H.323 allows endpoints to embed information about the IP address, port, and codecs that they want to use for a particular conversation in the H.225 messages actually used to place the call. CallManager can respond to and forward fast start requests that it receives.

Fast start can speed the establishment of a conversation and avoid clipping. However, because mid-call feature invocations don’t generate H.225 events, the full H.245 media renegotiation of necessity must occur. As a result, although the media channels related to initial call setup can occur quickly, media resumption can sometimes take longer when calls are transferred, retrieved from hold, retrieved from park, or the calls are the subject of other mid-call features. Normally, this isn’t an issue. When receiving calls, users are conditioned to immediately answer with a “Hello,” but users generally have fewer ingrained expectations when a mid-call feature is invoked.


  • Developed by IETF RFC#2705, 3360, 3435, 3661
  • Allows for per-port control of TDM GW circuits.
  • Uses port 2427 for basic client/server control.
  • can be used for FXO, FXS,E&M,T1 CAS(only), T1/E1 PRI, BRI
  • For usage with ISDN PRI or BRI, ISDN Layer 3(Q931) is BACKHAULED to CCM.i.e., No Intelligence with GW.
  • ISDN Layer 3 sent via TCP port 2428.
  • ISDN Layer 2 still terminated and controlled locally by the IOS GW.
  • No dial-plan needed on IOS GW.
  • Dial-peers are used however to link POTS circuits to MGCP Application.(service MGCPAPP)
  • MGCP tunnels the ISDN to CM and CM controls it.
  • Only MGCP version 0.1 is supported by CUCM.

Screen Shot 2014-09-11 at 10.12.44 PM

Pros. for MGCP

  • simplified dial-plan configuration.
  • simplified IOS configuration.
  • supported ISDN Q.SIG for PBX integration.(Rich feature-set for inter/intra-PBX communications.

Client(GW)-Server(CA) Protocol used in centralized deployment. Following are the series of commands that are exchanged between the client and the server. (useful for troubleshooting and determining call-flow)

Screen Shot 2014-09-11 at 9.55.06 PM

Connection Commands

  • CRCX = CReate Connection
  • DLCX = DeLete Connection
  • MDCX = MoDify Connection

Audit Commands

  • AUEP = AUdit EndPoint
  • AUCX = Audit Connection

Request Command

  • RQNT = Request for Notification

Endpoint Command

  • EPCF = EndPoint ConFiguration

Notify Command

  • NTFY = Notify

Restart Command

  • RSIP = ReStart In Progress

Below are the messages/notifications visible in case of various scenarious.

Screen Shot 2014-09-11 at 9.59.43 PM Screen Shot 2014-09-11 at 9.59.29 PM Screen Shot 2014-09-11 at 9.59.15 PM Screen Shot 2014-09-11 at 9.58.53 PM

MGCP configuration

MGCP configuration on Cisco gateway

! keep in mind hostname & domain name are important in MGCP configuration

Card type e1 0 0


network-clock-participate wic 0

network-clock-select 1 E1 0/0/0


isdn switch-type primary-net5


controller E1 0/0/0

framing no-crc4

linecode hdb3

pri-group timeslots 1-31 service mgcp


voice-port 0/0:15


mgcp call-agent

ccm-manager mgcp

ccm-manager redundant-host

ccm-manager music-on-hold

ccm-manager config

mgcp dtmf-relay voip codec all mode out-of-band




interface Serial0/0/0:15

no ip address

encapsulation hdlc

isdn switch-type primary-net5

isdn incoming-voice voice

isdn bind-l3 ccm-manager

no cdp enable


MGCP Gateway configuration in CUCM

To add the gateway to CUCM follow below instructions:

– From CUCM Administration, choose Device > Gateway.

– Click the Add New button. The Add a New Gateway window will open.

– From the Gateway Type drop-down list, choose the appropriate MGCP gateway (2801, 2811, etc) and click next.

– Choose MGCP from the Protocol drop-down menu and click Next.

– Enter the hostname or fully qualified domain name of the gateway in the Domain Name field. The name has to match the hostname or the hostname and domain name (fully qualified domain name) of the Cisco IOS router.

– Enter a description for the gateway.

– Select a CUCM group.

– Configure the IDSN switch type.

– Click Save. Reset the gateway for the configuration changes to apply.

– Locate the Configured Slots, VICs, and Endpoints section, and select the voice hardware module placed in the slot.

– Click Save. The subunits (voice interface cards slots) of the selected voice module will display.

– For each subunit (voice interface cards slot), select the subunit. (show diag at th gateway will list modules and interface cards that the gateway is equipped with)

– Click Save. The endpoints of the selected voice interface card will display.

To configure an MGCP endpoint, follow these steps:

– Click the endpoint identifier.

– Select the device protocol or signaling for the endpoint. T1 and E1 interfaces support channel associated signaling (CAS) or command channel signaling (CCS) via ISDN PRI. Analog interfaces support ground-start and loop-start signaling. Select the protocol that should be used on the endpoint and click Next.

– Enter a description for the endpoint

– Select the device pool that should be used by this endpoint.

– Click Save. Reset the gateway for configuration changes to be committed to the gateway
MGCP Gateway Registration Verification:

use show ccm-manager at the gateway to verify MGCP Gateway registration to CUCM was successful

use show mgcp endpoints at the gateway to verify MGCP Endpoints have registered

Troubleshooting the IOS MGCP Gateway

One way call failure, on either outbound call or inbound calls individually, can occur in an IOS MGCP gateway. In order to resolve this issue, reconfigure the MGCP gateway. Generally, this involves a reconfiguration of the PRI interfaces and/or FXO interfaces. Then, a restart of the mgcp protocol on the gateway by issuing the no mgcp IOS command and the mgcp command in global configuration mode.

Cannot make calls from an analog phone connected to the MGCP IOS gateway. A busy tone is received.

Perform this procedure in order to resolve this problem:

  1. Make sure the application mgcpapp command is configured on the applicable port.


As we know each time-slot is of 8 bits.

T1 (24 channels / Time slots)24 ts X 8 b = 192 + 1 synch bit = 193 bpfif CAS, 1 bit reduced from each slot8000 fps X 193 bits = 1544000 bps (1.544 MBPS)12 FRAMES = 1 SF  & 24 FRAMES = 1 ESFE1 (32 channels / Time slots)32 ts X 8 b = 256 bpf8000 fps X 256 b = 2048000 bps (2.0 MBPS)16 FRAMES = 1 MF (CRC4 / No-CRC4)


Deals with electrical pulses sent on actual link. Layer 1 Functionality

AMI (Alternate Mark Inversion)

  • used with T1 / E1 both.
  • older method.
  • Binary 1 is ‘mark’ and 0 is a ‘space’.

B8ZS (Biploar with 8 zero substitution)

  • used with T1 only.
  • most common in NA and JP.
  • replaces each string with 8 zeros with ‘000VB0VB’

HDB3 (High Density Bipolar of order 3)

  • most common in rest of the world.
  • replaces any instance of 4 consecutive 0 bits with one of the patterns (000V / BU0V)

Digital Voice Circuits

T1 CAS – TDM to transmit digital data(voice) over all 24 time slots(channels) [all channels are used for voice & data]

E1 CAS – TDM to transmit digital data(voice) over all 32 time slots(channels) [30 bearer channels + 1 for Framing + 1 for Signaling]

ISDN – uses CCS to send voice & data. T1 PRI 23 B +1 D / E1 PRI 30 B + 1 D / BRI 2 B + 1 D

NFAS (Network Facilities Associated Signaling) – method to allow multiple PRI interfaces to be grouped together and allows a single D-Channel to control all integrated Bearer (B) Channels.

QSIG – needed for PBX-to-PBX connections & Also carries MWI for legacy voice mail.

H323/SIP or MGCP – Voice Gateway Failover


  • H323/SIP intrinsically resilient.
  • successive voip or pots dial-peers (by preference) attempted on failure.
  • each call setup is independent.
  • flapping ip links don’t interfere significantly with call setup operation.


  • MGCP requires fail over features.
  • while call-agent is out-of-contact, MGCP GW fails over to local control.
  • ISDN D-Channel is reset to gain control of call-state.
  • flapping ip links interfere significantly with call setup.


Dial-Peers and Matching

Basic and Important Note – Every call on a Gateway(IOS, CM, CME) must have 2 call legs (inbound & outbound).

Matching Inbound Dial-Peers (VOIP or Digital TDM)

  • incoming called-number (DNIS)
  • answer-address (ANI)
  • destination-pattern (ANI)
  • port (for pots calls only)
  • default dial-peer (bad choice) i.e., chooses any codec, no dtmf-relay, DSCP 0, VAD is enabled, No RSVP, No TCL or VXML Apps, No DID

Matching Outbound Dial-Peers

  • destination-pattern
  • session-target or port (voip/pots)

Recommended : always explicitly configure a matching inbound dial-peer.

VOICE / VIDEO Gateway Hardware & Modes

Primary Hardware

  • ISR G1 – 2800/3800 EOL
  • ISR G2 – 2900/3900 (supports PVDM3 and advanced features)

Special Usage Hardware

  • ATA 186 (2 FXS ports)
  • VG224 (24 FXS ports) with CM as SCCP/MGCP.
  • VG248 (48 FXS ports) with CM as SCCP/MGCP.
  • AS5350 XM (Larger Deployments)
  • AS5400 XM (More Larger Deployments)
  • 7206 VXR (Extremely Large Deployments)

Gateway Modes

  • Voice Switching (pots to pots) – Analog Signaling (FXO,FXS,E&M) / Digital Signaling (ISDN PRI, QSIG, SS7)
  • VOIP Gateway (pots to ip) very common – Analog Signaling (FXO,FXS,E&M) / Digital Signaling (ISDN PRI, QSIG)
  • IP-to-IP Gateway – CUBE

CCIE Collaboration Written Blueprint Topics

CCIE Collaboration Written Blueprint Topics

The CCIE Collaboration Written Blueprint is broken into the following eight main sections. 
  1. Cisco Collaboration Infrastructure [10%]
  2. Telephony Standards and Protocols [15%]
  3. Cisco Unified Communications Managers [25%]
  4. Cisco IOS UC Applications and Features [20%]
  5. Quality of Service and Security in Cisco Collaboration Solutions [12%]
  6. Cisco Unity Connection [8%]
  7. Cisco Unified Contact Center Express (UCCX) [4%]
  8. Cisco Unified IM Presence [6%]


Cisco Collaboration Infrastructure

  • UC Deployment Models
  • User Management
  • IP Routing in Cisco Collaboration Solutions
  • Virtualization in Cisco Collaboration Solutions
    • UCS
    • VMware
    • Answer Files
  • Wireless in Cisco Collaboration Solutions
  • Network Services
    • DNS
    • DHCP
    • TFTP
    • NTP
    • CDP/LLDP
  • Power over Ethernet
  • Voice and Data VLAN
  • IP Multicast
  • IPv6

Telephony Standards and Protocols

  • SCCP
    • Call Flows
    • Call States
    • Endpoints types
  • MGCP
    • Call Flows
    • Call States
    • Endpoints types
  • SIP
    • Call Flows
    • Call States
    • SDP
    • BFCP
  • H323 and RAS
    • Call Flows
    • Call States
    • Gatekeeper
    • H.239
  • Voice and Video CODECs
    • H.264
    • ILBC
    • ISAC
    • LATM
    • G.722
    • Wide band

Cisco Unified Communications Manager

  • Device Registration and Redundancy
  • Device Settings
  • Codec Selection
  • Call Features
    • Call Park
    • Call Pickup
    • BLF Speed Dials
    • Native Call Queuing
    • Call Hunting
    • Meet-Me
  • Dial Plan
    • Globalized Call Routing
    • Local Route Group
    • Time of Day Routing
    • Application Dial Rules
    • Digit Manipulations
  • Media Resources
    • TRP
    • MoH
    • CFB
    • Transcoder/MTP
    • Annunciator
    • MRG/MRGL
  • CUCM Mobility
    • EM/EMCC
    • Device Mobility
    • Mobile Connect
    • MVA
  • CUCM Serviceability and OS Administration
    • Database Replication
    • CDR
    • Service Activation
    • CMR
  • CUCM Disaster Recovery
  • ILS/URI Dialing
    • Directory URI
    • ISL Topology
    • Blended Addressing
  • Call Admission Control
    • RSVP
    • SIP Pre-conditions
  • SIP and H323 Trunks
    • SIP Trunks
    • H.323 Trunks
    • Number Presentation and Manipulation
  • SAF and CCD
  • Call Recording and Silent Monitoring

Cisco IOS UC Applications and Features

    • SCCP Phones Registration
    • SIP Phones Registration
    • SNR
  • SRST
    • CME-as-SRST
    • MGCP Fallback
    • MMOH in SRST
  • CUE
    • AA
    • Scripting
    • Voiceview
    • Web Inbox
    • MWI
    • VPIM
  • IOS Based Call Queuing
    • B-ACD
    • Voice huntgroups
    • Call Blast
  • IOS Media Resources
    • Conferencing
    • Transcoding
    • DSP Management
  • CUBE
    • Mid-call signaling
    • SIP profiles
    • Early/Delayed offer
    • DTMF interworking
    • Box-to-Box Failover/Redundancy
  • Fax and Modem Protocols
  • Analog Telephony Signaling
    • Analog Telephony Signaling Theories (FXS/FXO)
    • Caller ID
    • Line Voltage Detection
    • THL Sweep
    • FXO Disconnect
    • Echo
  • Digital Telephony Signaling
    • Digital Telephony Signaling Theories (T1/E1, BRI/PRI/CAS)
    • Q.921 and Q.931
    • QSIG
    • Caller ID
    • R2
    • NFAS
  • IOS Dial-Plan
    • Translation Profile
    • Dial-peer Matching Logics
    • Test Commands
  • IOS Accounting

Quality of Service and Security in Cisco Collaboration Solutions

  • QoS: Link Efficiency (e.g. LFI, MLPPP, FRF.12, cRTP, VAD)
  • QoS: Classification and Marking
    • Voice vs Video Classification
    • Soft Clients vs Hard Clients
    • Trust Boundaries
  • QoS: Congestion Management
    • Layer 2 Priorities
    • Low Latency Queue
    • Traffic Policing and Shaping
  • QoS: Medianet
  • QoS: Wireless QoS
  • Security: Mixed Mode Cluster
  • Security: Secured Phone Connectivity
    • VPN Phones
    • Phone Proxy
    • TLS Proxy
    • 802.1x
  • Security: Default Security Features
  • Security: Firewall Traversal
  • Security: Toll Fraud

Cisco Unity Connection (CUC)

  • CUCM and CUCME Integration
  • Single Inbox
  • MWI
  • Call Handlers
  • CUC Dial-plan
  • Directory Handlers
  • CUC Features
    • High Availability
    • Visual Voicemail
    • Voicemail for Jabber
  • Voicemail Networking

Cisco Unified Contact Center Express (UCCX)

  • UCCX CTI Integration
  • ICD Functions
  • UCCX Scripting Components

Cisco Unified IM Presence

  • Cisco Unified IM Presence Components
  • CUCM Integration
  • Cisco Jabber
  • Federation
  • Presence Cloud Solutions
  • Group Chat and Compliance

Cisco UC & Architecture

  • IP Communication
  • Mobile Applications (Phones Services)
  • Customer Care (Contact Centre)
  • Tele-presence
  • Conferencing (Meeting Place & Webex)
  • Messaging (Voice Mail, Unified Messaging, Jabber, CUPC IM)
  • Enterprise Social S/W


Endpoints (IP Desk Phone, Wifi Phones, Video Phones, CUPC, CIPC, Jabber)

Applications (Unity Connection, Meeting Place/ MP Express, IPCC/UCCX(Express)/UCC Enterprise), Video Advantage, CUPS(Presence), CUMC(Mobile Connect)


Infrastructure (Routers, Switches, Firewalls, QOS, High-Availability)


IPV6 Types in Collaboration

  1. Unicast – sending messages to single network destination unique address.
  2. Anycast – assigned to set of interfaces, mainly belong to different nodes, packet is delivered to the closest interface.
  3. Multicast – single data stream to subset of all hosts simaltaneously.

IPV6 Addressing

  1. Link-Local Address – auto/manual configured on ipv6 interface.
    1. used for communication in between 2 devices on same link.
    2. also used for NDP and stateless auto-config process.
    3. automatically configured uses link-local prefix and interface ID.
  2. Unique-Local Address (like private ip address in ipv4)
    1. Not advertised beyond local site. Used for local communication intersite VPN.
    2. subnet id are defined using heirarchy addressing plan to allow route summarization.
  3. Global Address (Routable across internet)
    1. identified by 3 high level bits set to 001. assigned by service providers.
  • CM supports 1 LL, 1 UL or 1 GA and 1 IPV4 address.
  • IP Phones supports 1 LL, multiple UL or multiple GA and 1 IPV4 address.(GA takes precedence over UL)Note- if multiple UL or GA exist, 1st address is used as signaling and media address to CM.
  • IP Phones IPV6 (GA or UL) for signaling and media.
  • IOS Devices support 1 LL, multiple UL, multiple GA and multiple IPV4. (LL for routing)

Enabling IPV6 in CM

  • must be done via CLI or OS Administration
  • Enterprise Parameters IPV6 to true(SLAAC ON, media preference ipv6, preference signaling IPv6)
  • common device configuration (phones/sip trunk to enable ipv4 and ipv6 addm signaling, oref, phone auto config)

Routed Access Campus Design

As previously, Traditional Cisco Campus Design had Layer 2 at access layer & layer 3 at distrubution and core layers.

Cisco modified it with collaboration, by extending layer 3 to the access layer switches to acheive fast convergence, single control plane, dynamic traffic load balancing.

STP to be limited to access switches and layer 3 links should be used throughout.



CISCO Proprietary

  • deliver -48V DC up to 6.3-7.7W per port on pins 1236.
  • came first before industry standard
  • switch sends FLP(Fast Link Pulse) to connected device, Device loops FLP back to switch, switch releases power.

IEEE 802.3AF Standard

  • deliver -48V DC up to 15.4W per port on pin 1236/4578.
  • switch applies voltage -2.8 to -10 V, after which if resistance of 25K ohm is detected, switch releases power.

Network Services – DHCP, DNS, TFTP, NTP, CDP, LLDP



  • Recommended for EP’s in successful deployment, but not mandatory hard-coding ip’s can be done too(unreal world).
  • IP addressing & Scopes needs to match minimum total number of EP’s at that site.
  • CM, GW, DHCP server can do the job.
  • DHCP Option 150 recommended to provide TFTP redundancy.
  • “ip helper-address x.x.x.x” command relays DHCP request further.



  • Used for Name resolution.
  • Useful for management purposes and Load-balancing requirements.
  • Still, cisco doesn’t recommend critical communication in collaboration network(SPOF).



  • IP Phones require to get firmware, configuration file, phone button template, and everything else they need.
  • Only way to provide redundancy to Critical TFTP is by using DHCP option 150. multiple CM’s can function as TFTP.
  • CM also supports PROXY TFTP feature which forwards requests to their respective clusters. No need for manually defining option 150 for any subnet.
  • LOAD Server parameter useful for remote site with low-speed WAN. (placing local tftp server i.e.,win/ios)
  • Peer Firmware Sharing allows peering in between 3 phones. [1:2 PARENT:HOSTS] ratio makes it tree-based.(same subnet phones and need to be peer enabled) After peering establishes Parent contacts TFTP server¬† 8.3.1 and later


  • to synchronize clocks on phones and CMs.
  • CDR, logs & Traces accuracy.
  • cisco router or atomic clock recommended. (< stratum 3)



  • Layer 2 Cisco Proprietary to discover neighbor devices.
  • cisco devices advertise & listen existence.
  • operates on SNAP supporting media(LAN, FR, ATM).
  • CDP messages are multicast advertisements with destination 01:00:0C:CC:CC:CC on each enabled interface.
  • CDP message consists DEV ID, Port ID, Add, Cap., Ver, Platform, Native VLAN.


  • Vendor-Neutral Layer 2 protocol for interoperability.
  • Used by network devices to advertise their identity, cap., and neighbors (for NON-CISCO EQUIPMENT or EPs)
  • non-cisco switches, LLDP-MED to detect power & voice vlan to cisco ip phones.
  • Again cisco switches, LLDP-MED used to support 3rd party phones.
  • By default LLDP disabled on cisco routers and switches.