So for a g711 call with default payload carried over ethernet:
Total Packet Size: 40 + 18 + 160 = 218 bytes = 1744 bits
PPS = 64,000 (bitrate) / 1280 (payload size) = 50
Bandwidth = 1744 * 50 = 87,200 (or 87.2 kbps)
You could also use the Voice Bandwidth Calculator from TAC:
https://tools.cisco.com/Support/VBC/do/CodecCalc1.do
Sometimes working with a large amount of phones (10,000+) it can take a whole day to export into a csv, and makes more sense to view and manipulate data in the live database. Caution should be taken when handling the live database, so if you are not a programmer, you may want to stick to the canned scripts below as an overly broad query could lock up your server!
I was recently tasked with running firmware updates on a large amount of phones, various models for over 100 device pools. Anything that can help organize and divide workload and cut down on unnecessary bulk jobs is a huge help!
UC Guerilla has a good blog on this here
Cisco’s documentation you can find here, but a tough read for a non-programmer
Count the number of devices per type, total:
run sql select count(Device.name) Device_count, typemodel.name Device_Type from Device inner join typemodel on device.tkmodel=typemodel.enum group by typemodel.name
Count the number of phones in each device pool, sorted by device pool name:
run sql select count(d.name), dp.name as DevicePool, tc.name as DeviceType from Device as d inner join DevicePool as dp on d.fkDevicePool=dp.pkid inner join typeClass as tc on tc.enum=d.tkClass group by dp.name, tc.name order by dp.name
Count the number of each type of phone per device pool, sorted by device pool name:
run sql select count(Device.name) Device_count, DevicePool.name Device_Pool, typemodel.name Device_Type from Device inner join DevicePool on Device.fkDevicePool=DevicePool.pkid inner join typemodel on device.tkmodel=typemodel.enum group by DevicePool.name,typemodel.name order by DevicePool.name
ILS is a new feature service in CUCM 9.0 that allows for sharing of Directory-URIs between clusters.
A Directory URI is much like an email address, formatted like jlevensailor@ciscolab.com where jlevensailor is the user portion and ciscolab.com is the host portion. The user portion is actually case sensitive, but only in the context of CUCM, and is actually an enterprise parameter that can be set to fix this.
The internet uses dns via _sip._udp/tcp or _sips._tls SRV records to route calls between Directory URIs much like email uses mx records. CUCM uses sip route patterns for Directory URIs much like they use standard route patterns for DNs. To tell CUCM that a particular Directory URI is on-net within a particular multi-cluster environment, ILS was introduced.
*It is recommended to first change the Cluster ID enterprise parameter in both clusters to something unique.
To get started, I’ll assume you have a sip trunk has been created already between the two clusters, directly or via SME. Go to Advanced Features and ILS Configuration.
You’ll change the role to “Hub Cluster” and enter the corresponding clusters domain name or ip-address in the popup. For authentication you can either use TLS certificates and exchange certs (default), or you can use a password. Note: The password does require a restart of the ILS service, in case you were already running this.
The advertised route string is what you will create a sip route pattern for on the other cluster, pointing to the ICT so calls can work. When you are done, you can go ahead and start the service if you haven’t already, wait until synchronization finishes and run a route plan report to confirm:
As you can see, any URI on the remote hub cluster will be discovered, not just those that happen to match the advertised route string, which by default is the cluster FQDN.
The call flow is: nbates@car.lab wants to call test@dur.lab. CUCM checks the CSS of nbates@car.lab and proceeds to search for the URI in the list of ordered partitions as usual. When it finds test@dur.lab, it sees that it is a “Learned URI” from sbcucm.dur.lab, and uses the target from the sip route pattern of “dur.lab” I created to call the remote user.
The benefit of this is that sip route patterns won’t have to be created for each remote domain, just one for each ILS partner cluster. I would imagine you’ll start seeing a blank sip route pattern pointed to VCS/Expressway-C for outside domains and a specific ILS route pattern for internal domains/on-net traffic.
Official Documentation HERE