IIIIIII

1. Subscribers access the database to update UFF

   Anmerkungen:

   • Subscriber can READ-WRITE user facing features but other than that all changes to database are to be made by publisher only. The subscriber data is then synced in the full mesh I.e cluster minus publisher. When publisher comes back online the changes are pushed to publisher as well.
   1. Changes by subscriber updated to FULL MESH (Cluster minus Publisher)
   2. UFF started from 4.1.3 version
      1. Allows features to work in Publisher's absence
2. Static Data

   Anmerkungen:

   • stores STATIC configuation data (devices like phone, gw n trunks, servers in a cluster, activated services, users and dial plan etc)
   1. Phones, GW, Users, Dial Plan, Servers & Active Services
3. Dynamic Data
   1. UFF (suscriber can change)
      1. Call forwarding, MWI, Privacy, DND, Hunt Group login status, Device Mobility, Extension Mobility, CTI CAPF cert authorization
      2. Services which don't work witout PUB
         1. CCMAdmin, CCMUser, BAT, TAPS, AXL, AXIS_SOAP, CCM, LiCAUDIT

            Anmerkungen:

            • CCMadmin (Ccna voice - anything that is provisioned) , CCMUser (end user web admin page access not available when publisher goes down but still call forwarding from phone can be done- UFF) , BAT, TAPs, AXL - provision everything ( only readable through subscriber not writable), AXIS-SOAP - enable \disable services, CCM - - inserts phone, LDAP No chchanges made in active directory syncs until pub comes back, license audit- any update to licenses.
      3. DB Access control
         1. SUB requires special config
            1. Pre-Add SUB

               Anmerkungen:

               • adding subscribers servers list to publisher before installing subscribers
            2. Same security pswd which was used in PUB instllation

               Anmerkungen:

               • during subscriber installation entering same database security pswd used during publisher installation.
         2. Protected by IPtables firewall & security password.

1. Device Based

   Anmerkungen:

   • we
2. User Based

Anmerkungen:

•  Even if two branch phones talk with each other then signaling goes to DC but media stays local. Signaling takes very low BW for the phones hanging off in a branch so it traverses over the WAN

1. Low BW so can traverse WAN without much impact

Anmerkungen:

• media (24-28 kbps avg approx. G729 (more with Ethernet overhead) /G711 - 100kpbs approx.) takes lot of BW hence stays local.

1. More BW so stays local
2. MEDIA OVER WAN

   Anmerkungen:

   • Only time the media shud traverse CUCM cluster should be during MOH (unidirectional from CUCM to endpoint) or Conf bridge 
   1. MOH or Conf bridge
3. Shuffling

   Anmerkungen:

   •  Even if two separate cluster are connected via ICT trunk the media should only flow over the WAN between the end phones (bypassing the two CUCM's).

Anmerkungen:

• DHCP reaches DNS server if cnf.xml files tells that CUCM is reachable through FQDN instead of IP. DHCP provides IP addr/GW addralong with TFTP info to phone > Phone contacts TFTP (one of the CUCM servers acting as TFTP) >Phone contacts CUCM via IP/DNS and gets the cnf.xml file back wherein it refrences a FQDN (of CUCM) so phones needs to contact DNS to resolve this server name.

1. Phone Registration

   Anmerkungen:

   •  DHCP provides IP addr/GW addralong with TFTP info to phone > Phone contacts TFTP (one of the CUCM servers acting as TFTP) >Phone contacts CUCM via IP/DNS and gets the cnf.xml file back wherein it refrences a FQDN (of CUCM) so phones needs to contact DNS to resolve this server name.
   1. Phone gets its own IP Addr, GW & the TFTP IP from DHCP server
      1. TFTP gives a conf.xml file which if has CUCM in a 1) IP format then all hunky dory 2) FQDN - the phone needs to reach out to the DNS in order to translate CUCM FQDN to ip & get registered with it.
      2. TFTP may be one of the CUCM servers acting as TFTP
2. ISSUE
   1. During a WAN issue a local CUCM (cluster over WAN or SRST mode) was available but with DNS being down phones could not resolve the hostname of local CUCM

      Anmerkungen:

      • During a WAN issue if Main Cluster CUCM was not available but a local CUCM (cluster over WAN or SRST mode) was available which phones could have gone to but with DNS being down could not resolve the hostname of local CUCM the phones would stay un-serviced hence Cisco though supports DNS but doesn't recommend using it.