Award Consulting

Metaswitch consultants

You can copy call-policy-sets in Perimeta!

By

I’m a little behind the curve here, but I just discovered that since Perimeta V4.4.20 it has been possible to copy a call-policy-set in the CLI. Hallelujah!

(Apparently my team has known this for a while, but I’ve not been doing much technical work myself recently.)

For those who have no idea what I’m talking about, let’s review some background real-quick:

  • In a Metaswitch CFS your “translations” are contained within a config set, which has a bunch of tables that make routing decisions.
  • In a Perimeta SBC, the equivalent configuration is known as call-policy-sets – again structured as a series of tables that make routing decisions.
  • In the CFS, it’s always been the case that to make a change, you had to take a copy of a config set, then update the copied version, then “switch over” to the new config set to make it live.
  • On the Perimeta, you had two options. You could make an inline change to the active call-policy-set, which was pretty high risk for all but the simplest updates. Alternatively, you could create a new call policy set, and then make it active.

HOWEVER, for a long time, there was no way in the Perimeta CLI to copy a config set. So you would need to copy an entire config set to a text file, then create a new config set and paste in all the original text (often pages and pages of configuration).

This wasn’t the end of the world – the Perimeta does a really good job of supporting copy-and-paste from a text file – but it was pretty clunky and annoying.

But apparently, this limitation is no more.

How do you make a copy of a call-policy-set?

From within the Perimeta CLI, enter the following commands (to create a new call-policy-set number 3, that is a copy of existing call-policy-set 2:

actions
sbc
signaling
call-policy-set
copy-call-policy-set 2 into 3 description "CPS3 is a copy of CPS2"

You can also do the same thing through MetaView Explorer or MetaView Web if you manage Perimeta from those interfaces – but that has been available for longer than the CLI option.

Why are you so excited?

It’s the little things that make a product pleasant or annoying to use. I can well imagine the product roadmap meetings where the Perimeta Product Managers were talking about all the cool new features they could add to the product, and how easy it would have been to overlook the “copy-call-policy-set” idea. Who cares about that, right?

But as someone who uses a product, anything that makes it just a little bit easier to use is a big win. Particularly if it removes a longstanding minor annoyance.

A plea for overriding call-policy-sets

In case anyone from PM is reading this, my next feature request is a way of implementing overriding call-policy-sets for specific calls or subscribers in the Perimeta. There’s a similar feature in the CFS, which is really useful for testing significant updates to the routing logic – and it’s tough to manage without this in the Perimeta. We have designed a workaround, which helps a lot, but a product feature to aid testing would be fantastic. If you happen to have some free time.

Reader Interactions