Directory Number Inventory

The number inventory can exist at a different level to the lines for users and devices that consume (device/cucm/Line) are typically at the site level with the user, service or device they are on. However, the inventory can exist at the customer level.

Use this procedure to add a single directory number (DN) or range of DNs for your customer. The DNs (extensions) you specify are validated against the Dial Plan type (Type 1 to 4). The extension length assigned to the site is enforced for site location code (SLC)-based dial plans. The maximum number of directory numbers you can add at a time is 1,000. For more information on Type 1 to Type 4 dial plans, see Directory Numbers.

If the allocation and availability of numbers is not site specific, for example E164 dial plan/Type 4 flat dial plan, then generally it is easier to have the inventory at the customer level. This saves moving numbers around sites to increase availability and keeps a more central inventory of available numbers. It is also key if numbers are going to be shared across sites.

If the number allocation is site specific, for example site code+ext dial plan, local breakout if E164 dial plan, then these numbers can be added or assigned to a site level.

Number inventory cannot exist at a intermediate node - only provider, customer, or site.

Number inventory is not partition or cluster aware. If the same numbers are used multiple times but in different partitions, then these all map to the same inventory number. This should be taken into account when thinking about the hierarchy level that the number inventory exists.

Also, not being cluster aware, if the same number exists on different clusters, this again will map back to the same inventory value unless numbers are assigned to the site level.

Since the inventory is not partition aware, if the same directory number is used on a cluster but in different partitions, then VOSS-4-UC workflows will update the inventory when any of those instances are changed - for instance, if there is a directory number 1111 in Cluster X partition and a directory number 1111 in Cluster Y partition, and the inventory entry is marked used.

If one of those instances are deleted, we check to see if there are other instances of that line based on the number only (not partition), before clearing the “used” flag. In this case, the other instance will be found and the inventory will stay marked as “used”.

Deleted numbers, e.g. as a result of a subscriber or phone delete are automatically placed into a cooling period for a predetermined amount of time as specified in the Global Settings. During this period the number is unavailable and cannot be used, i.e. allocated to a subscriber, phone, device, etc.

The Cooling End Date (yyyy-mm-dd) displays the date on which the cooling period elapses, at which time the number becomes available in the list of available numbers.

Numbers in the cooling period can also be manually removed from the cooling period, and reintroduced into the list of available numbers. See also Number Cooling.

Note

  • A number cooling auto expiry schedule runs daily. This schedule polls the Cooling End Date field on the number inventory list view to determine which numbers have completed their cooling period. These numbers are then returned to the list of available numbers at the specific hierarchy level.
  • You cannot add directory numbers if Number Management has been disabled for the customer.
  • If you are a customer with multiple sites using a Type 4 dialing plan, ensure that the directory numbers you specify are unique across sites.
  • This procedure creates the DN inventory only in VOSS-4-UC. The numbers are not synced to Cisco Unified Communications Manager.
  • Directory numbers can only be added or deleted. You cannot edit the directory numbers once they are added. The usage and availability property for each DN is associated with a line or taken into use by a service.
  • Using bulk loader sheet or API, you can create the Directory Number (DN) Inventory only at the customer hierarchy. The Details column of Sub-transactions shows whether the DN already exists or it is creating a new DN. If any DNs exist in the range, the sub-transaction fails and parent transaction shows the status Success with Async Failures.