This affect both PureEngage and PureCloud. Trunk Capacity currently isn't set at a switch level, rather at a SIP Server level. This has been confirmed through our testing in our labs and review of the SIP Server Deployment Supplement (looking at BC deployments gave us the clue). This become more important at a SIP Cluster level where multiple SIP Server P/B pairs merely make up a node of the cluster, while feeding into a single switch. Today the problem is that if there are multiple SIP Servers connected to the same switch, there isn't a set number that can be prescribed at the trunk - in fact, division has to be preformed based on the number of primary SIP Servers connected to the switch. In fact, this also assumes that there is a true, even distribution to each data center by a carrier and at the SBC level. Specifically, if one requires to block at an inbound level (option: "tserver/capacity=(limit in positive integer) combined with tserver/capacity-limit-inbound=true", and state, no more than 200 calls on that trunk. Then one is working with two SIP Servers per data center within a node - connected to the same switch (in the case of SIP Cluster) - then one has to set the maximum number of calls on the trunk to 50, as it can go to any one of 4 SIP Servers - and each uses the trunk independently of the other statistics-wise. This makes reading the limit on the trunk non-intuitive, and forces the math to continue. However, what if there are 2 data centers? What if there is a 60% distribution in one data center and 40% in the other? If that is the case, then the limit of 200 is not accurate at 50, and it's not a linear limit because it's a shared trunk.