Learn How To Manage Your Cfs Translations

LEARN HOW TO
MANAGE YOUR CFS

TRANSLATIONS
Learn How To
Manage Your
CFS Translations
Estella Chesneau
CONFIDENTIAL
Copyright 2000 – 2018 Metaswitch Networks. All rights reserved.
This manual is issued on a controlled basis to a specific person on the

understanding that no part of the Metaswitch Networks product code or
documentation (including this manual) will be copied or distributed without prior
agreement in writing from Metaswitch Networks.
Metaswitch Networks reserves the right to, without notice, modify or revise all
or part of this document and/or change product features or specifications and
shall not be responsible for any loss, cost, or damage, including consequential
damage, caused by reliance on these materials.
Metaswitch and the Metaswitch logo are trademarks of Metaswitch Networks.

Other brands and products referenced herein are the trademarks or registered
trademarks of their respective holders.
01 February 2018
Version: 3
CONFIDENTIAL
Contents
Learn How To Page
Get to grips with the guide...................................................................................................7
What are "translations"?.......................................................................................................8
Identify your base configuration..........................................................................................10
Manage your translations using Config Sets.......................................................................11
Look inside a Config Set.....................................................................................................19
Fit translations into the 7 steps...........................................................................................21
Collect digits using Digit Maps............................................................................................23
Modify, classify and block calls in Number Validation..........................................................28
Use search selection fields to set values easily in translations.............................................41
Follow a call through Number Validation.............................................................................42
Record call properties using Attributes...............................................................................53
Extend the built-in Attributes using Line Class Codes and User Defined Attributes.............60
Get ready to discuss overlap signaling................................................................................64
Use file-based Number Validation Tables............................................................................68
Look for the called number on the CFS in On-Switch Lookups...........................................73
Decide how to test your translations...................................................................................77
Do live testing using Override Config Sets..........................................................................78
Do thorough testing and build a test suite using Route Verification Tests............................81
Get diagnostics for a call using the Service Assurance Server............................................90
CONFIDENTIAL
Contents
Learn How To Page
Route a call off the CFS using Trunk Routing......................................................................95
Handle trunk failures and rerouting...................................................................................107
Follow a call through Trunk Routing..................................................................................114
Choose how to edit your translations................................................................................118
Get ready to discuss Number Portability...........................................................................121
Get started with long distance call services and the associated terminology.....................124
Maintain and understand the configuration for ANI Screening...........................................126
Maintain and understand the configuration for Authorization codes..................................131
Celebrate - you've finished!..............................................................................................135
Glossary...........................................................................................................................136
CONFIDENTIAL
CONFIDENTIAL
Get to grips with the guide
Get to grips with the guide
If you're new to CFS translations, then this guide is designed for you. If you're looking to refresh
your memory or for a reference guide then you can use it too!
This guide is based on the classroom translations courses that we have been running and
developing for several years. It assumes no prior knowledge of translations, either on the CFS
or on any other switch. If you start at What are “translations”? on page 8 and work through
the guide in order then the topics should flow comfortably and you will build up a very solid
understanding of the translations on the CFS.
The guide does assume that:
• You are comfortable with using MetaView Explorer to edit the configuration in the object
tree (also known as the Tree View Panel).
• You do not have a NANP (North American Number Plan) deployment. If you do have a
NANP system then everything in this guide is still correct but please be aware that this
version of the guide does not cover some key extra NANP features, such as carrier code
handling and LNP lookups.
Note: Use the MetaView Explorer User's Guide if you want to learn about using the MetaView
Explorer.
Some of the chapters include suggested exercises and we recommend doing them. Since
we don't know exactly what configuration you've got on your CFS, the exercises are just
suggestions for things to try and there are no definitive answers. If you've got other ideas
that you'd like to investigate, then that's fine. Most people learn a lot more by doing than by
reading. In fact, my experience is that people learn most by making mistakes and then fixing
them, so just have a go!
Note: At Metaswitch we like technical terms and we really like acronyms. The Glossary on page 136
will help you make sense of the terminology you'll come across in translations.
Will I be an expert at the end?

Yes and no. You'll know almost everything about how CFS translations work and you'll know
how to make simple changes. However, this version of the guide does not cover how to design
large structural changes to your translations.
The guide does cover all of the individual concepts that you need to make structural changes,
but you also need to consider things like supportability, maintainability and future-proofing when
designing translations. If you want to make significant changes to your translations then it's
worth using the Translations Group on Communities (we'll cover this in What are “translations”?
on page 8) or talking to Metaswitch Support first, to make sure your new design is sensible.
CONFIDENTIAL 7
What are "translations"?

Before you can learn how to configure, maintain and troubleshoot your CFS translations, you
first need to know what "translations" are!
Translations are at the heart of your CFS. Every incoming or outgoing call goes through the
translations configuration and it's fundamental to how calls get processed.
Are translations really the heart of your CFS? The translation configuration is my favourite CFS
topic so I may be biased, while the software and hardware developers who've spent years
working in other areas think their areas are the most important! So, it probably depends on
who you're talking to.
Translations do 6 key things during a call.
• Collect the dialed digits.
• Modify digits, usually those in the destination number.
• Classify the call. For example, work out if it's a national call, an emergency call etc.
• Look for the called number in the CFS's subscriber database.
• Choose the outgoing trunk for calls going to the network.
• Control some of the signaling messages used for calls.
If you want to do any of these then get ready to dive into translations.
Don't panic
If you've not dealt with switch translations before, or if you've just realized how long this manual
is, then you may be starting to worry that there's too much to learn.
Did you know? "DON’T PANIC" is a quote from the

Hitchhiker's Guide to the Galaxy, which was a very popular
and surreal British radio comedy originally broadcast in
1978. Over the years it has expanded to several books,
films and computer games. The plot is impossible to explain
here, but suffice it to say that it includes a book which is
a hitchhiker's guide to the galaxy. This book has "DON'T
PANIC" inscribed in large friendly letters on its cover.
8 CONFIDENTIAL
The translations configuration on your CFS is immensely powerful and potentially very complex.
However, you don't have to build it from scratch or on your own.
We provide an initial configuration (often called the base configuration) that provides most of
the configuration that you need to handle calls in your particular country or region. This base
configuration is added to your CFS as part of the initial commissioning phase. (We'll look at
base configurations and regions in more detail in Identify your base configuration on page 10.)
Once the base configuration is installed you then just need to make small changes to the base
configuration to match your particular deployment. We also expect service providers to make
basic changes to maintain the configuration, for example by adding support when a new area
code is turned up or a trunk is added.
Get help with translations

This guide tries to cover all of the information you may need to manage your translations at a
basic level. However, translations is not an easy subject, so you may have questions and even
translations experts need to keep up-to-date with the latest features and guidelines. You need
the Translations Common Interest Group on Communities!
1. Log in to Communities (https://communities.metaswitch.com).
2. Click on Support.
3. Click on Common Interest Groups.
4. Select Translations from the Common Interest Groups window on the left.
Here you can post questions to the Metaswitch translations expert using the Ask button.
5. Click on Receive email notifications in the Actions box on the left.
You will now receive email notifications about new content in the Translations space. It's a
great way to keep up-to-date with translations news.
6. If you require further help with translations, contact your Metaswitch CSE or Account
Manager. They will be happy to answer your questions.
Get even more help

Even with this manual and the Communities Translations group, some service providers are not
confident working with translations or they simply want to outsource doing regular translations
updates. Metaswitch Professional Services can often help in these situations; just get in touch
with your CSE or Account Manager for more information.
Checkpoint: You now know what CFS translations configuration does, so you can appreciate
why it's important and why you need to understand it. You also know that you don't have to
design your translations from nothing, because we'll provide an initial base configuration that
does most of what you need. Finally, you also know how to get more help with translations.
That's a great start!
Before we start looking at the actual configuration, you just need to quickly Identify your base
configuration on page 10.
CONFIDENTIAL 9
Identify your base configuration
Identify your base configuration

We usually install one of two possible base configurations when we commission the translations
on your new CFS. The base configurations are customized for your particular dial plan and
calling areas, but generally the configurations on every CFS look very similar. Using a standard
base configuration has several advantages.
• We've developed tools that let us create the customized base configurations quickly and
effectively.
• Metaswitch Support personnel can easily and quickly understand any customer's
configuration.
• The base configuration builds on our many years of experience in designing and maintaining
translations. Using the base configuration means you benefit from the lessons we've
learned the hard way!
Why do we have 2 base configurations? We've found that customers using the North
American Numbering Plan (NANP) have distinct requirements, which means it's best to use
a dedicated translations scheme, known as the NANP base configuration or NANP scheme.
For non-NANP regions, we've designed a more generic scheme that's easy to customize for
different countries and regions. This is known as the International base configuration or
International scheme.
How can you tell which scheme is on your CFS? If you're used to talking about things like 10D
calls, interLATA calls and carrier codes, then you're almost definitely a NANP deployment.
On the other hand, if you've no idea what those mean, then you'll almost definitely have an
International system!
Does it matter? Not much. This version of the guide is aimed at International schemes but it's
mostly focussed on fundamental features and properties of translations. So, almost everything
applies regardless of which scheme you're using or which country you're in. However, there are
a few places where I've flagged features that only apply in one scheme.
Note: Most of the screenshots in this guide were taken on an International system. If you have a
NANP deployment, don't be surprised if the configuration in the screenshots doesn't match
your own configuration exactly.
Checkpoint: You now know whether you have a NANP or International system, so you're ready
to jump into the configuration. Let's begin at the top with how to Manage your translations using
Config Sets on page 11.
10 CONFIDENTIAL
Manage your translations using Config Sets
Config Sets are the key top-level configuration objects in translations. Even if you never edit
translations yourself, you may still need to manage Config Sets provided by other people, such
as Metaswitch Professional Services. So, what is a Config Set and how do you use it?
A Config Set contains all of the configuration you need to define the translations on your CFS.
(Actually it's not exactly all of the configuration if you use some of the advanced features, but
for now it's much simpler to remember that a Config Set is everything you need!) We’ll soon
look at what’s inside a Config Set, but first we need to look at how you use Config Sets to
manage your translations.
Does it seem odd to start managing Config Sets before you know what's inside them? Don't
worry - there is a reason for starting here! The first step whenever you edit translations is to
create a new Config Set, so doing this section first means you can start practicing translations
as quickly as possible.
You'll find the Config Sets under Trunk Routing and Policy Services under the Call Feature
Server.
We're using MetaView Explorer because you can't view or edit translations using MetaView
Web (it's intended for subscriber management). If you have a distributed softswitch then also
remember that all translations configuration is on the CFS, not the UMG, since it’s to do with
phone numbers and only the CFS is aware of phone numbers.
Trunk Routing and Policy Services also includes Line Class Codes and User Defined Attributes,
but we’re going to ignore those for now because they're an optional and advanced topic. (We'll
cover them later in Extend the built-in Attributes using Line Class Codes and User Defined Attributes
on page 60, when you'll be ready for them.)
Finally, before we look at the actual objects, I really recommend that you 'bookmark' the Trunk
Routing and Policy Services object by creating a new custom object view in MetaView Explorer,
as shown in this example.
CONFIDENTIAL 11
Using a custom view makes it much easier to get back to this area in the future. I suggest also
creating views for other key objects when you're working on them.
Note: See the Custom Object Views section in the MetaView Explorer User's Guide if you want
more information on how to create and use custom views.
Recognize the different Config Set states

If you look at the Config Sets in your object tree, you'll probably find that they have a range of
activation icons. Config Sets can be in one of several states, and the state defines what you
can do with the Config Set.
Firstly, let's look at deactivated and disabled Config Sets. It's easy to spot these in the object
tree.
Deactivated or disabled Config Sets can be edited. You cannot use them for live traffic or test
them using Route Verification Tests (RVTs). In terms of editing and traffic, the disabled and
deactivated states are the same. The key difference is that disabled Config Sets are not loaded
in memory. This is why we recommend disabling Config Sets when you’re not using them.
Note: Route Verification Tests will be covered later in Do thorough testing and build a test suite using
Route Verification Tests on page 81.
12 CONFIDENTIAL
Once you've finished editing your deactivated or disabled Config Set, you need to test it, so
you need to make it active. Again, you can easily recognize active Config Sets in the object
tree.
When you activate a Config Set, the CFS does internal consistency checking to make sure that
any references are valid; for example, to ensure that one piece of configuration doesn’t reference
another piece that has been deleted. If you try to activate a Config Set with a consistency error
then it will fail with an appropriate error message.
Once a Config Set has been activated, you can no longer edit it, but you can use it for live traffic
and test it using Route Verification Tests.
Finally, only 1 Config Set can be in use for live traffic. This is known as the live or in-use Config
Set and it must be an active Config Set. Once a Config Set is live, you can still test it using
RVTs but it can’t be deactivated, edited or deleted (in other words, you can't change it at all).
(Actually you can temporarily put test traffic through non-live Config Sets but we'll cover that
later in Decide how to test your translations on page 77, so for now just assume that all traffic
goes through the live Config Set!)
Checkpoint: You can now identify what state a Config Set is in, and you know how the states
affect what you can do with the Config Set. Now let's see exactly how you will use Config Sets.
Use Config Sets

So far you know that Config Sets contain everything you need to define the translations and the
state of a Config Set defines what you can do with that particular Config Set. But how do we
actually use Config Sets? For example, what if you want to make a change to the translations
in a Config Set?
The first key point is:
• Only 1 Config Set is live and all traffic runs through this Config Set.
The live Config Set is set on the Trunk Routing and Policy Services object. It also shows up as
a reference in the Object Tree under the Trunk Routing and Policy Services object.
Calls go through the live Config Set sequentially, i.e. one call completes routing before the next
call enters the Config Set. The CFS won't swap to a new live Config Set until it has finished
processing the current call, so you don't need to worry about the Config Set changing while
processing a call.
CONFIDENTIAL 13
The second key point is:

• The live Config Set cannot be edited, to reduce the risk of breaking calls.
So, how can you make changes to your translations? It's simple: you need to have multiple
Config Sets.
Most systems have at least 3 Config Sets:
• The live Config Set
• A backup Config Set with old configuration
• A new Config Set which you’re currently editing.
Once you’ve finished editing the new Config Set (and you’ve tested it thoroughly!), simply make
the new Config Set live and all traffic will start running through that new Config Set. There are
some tricks and tips you can use here to make your life easier so make sure you read the full
recommended procedure for creating Config Sets in the next section.
Reduce the load on the CFS

Config Sets can get very large and if you have lots of large Config Sets then this could put
a large load on the CFS, especially when you copy a Config Set. This is not an issue for the
majority of customers, but a few customers have very large Config Sets (for example, the
Config Sets may contain lists of every ported number in the country). To avoid any problems
we make the following recommendations.
• Aim to have 5 or fewer Config Sets. The CFS has a hard limit of 15.
• Disable Config Sets when they’re not in use, so that the configuration is not stored in active
memory.
In addition, the CFS limits you to 3 copies and/or deletes per 2 minutes, since these actions
can be CPU-intensive for large Config Sets. Most of the time you probably will not hit this limit;
we mostly hit it in training classes when 10 students want to copy a Config Set at the same
time!
Checkpoint: You now have a high-level view of how you need to use Config Sets when you
want to edit your configuration. You're now ready to look at this process in more detail.
Create a new Config Set, step-by-step

If you want to edit the translations configuration then you first need to create a new Config Set.
Here I'll walk you through the process for creating and using a new Config Set.
You never need to start with a completely new Config Set. If you create a Config Set by selecting
the Trunk Routing and Policy Services object and then clicking on the add sub-component
button, it will create a new and completely empty Config Set. Don't do this! Instead you need
to clone the existing Config Set and make edits to the cloned copy.
Note: For some customers this method for editing translations does not fit well with their working
practices. If this sounds like you, don't panic. We'll look at some alternative methods later in
Choose how to edit your translations on page 118.
First, here's an overview of the process.
14 CONFIDENTIAL
The rest of this section goes through the 7 stages in more detail. You haven't yet learned how
to edit or test Config Sets, but you'll still be able to follow the remaining steps to create a new
Config Set that's an exact copy of an existing one.
Step 1: Clone the existing live Config Set

• Select the current live Config Set in the object tree.
• Click on the copy button or right-click and choose copy from the pop-up menu.
Checkpoint: There is now a new Config Set in the object tree. It will have a blank name.
CONFIDENTIAL 15
Step 2: Name the new Config Set

Good naming is essential. It’s easy to end up with lots of Config Sets and no idea where they
all came from!
We recommend including 4 bits of information in the name:
• Your name.
• The date you created the Config Set.
• The number of the set you copied.
• The change(s) you made to the Config Set.
Here’s an example:
• Type the new Config Set name into the Config Set name field on the new Config Set
object.
• Click on apply to apply the new name.
Checkpoint: The new Config Set now has a useful name.
Step 3: Edit the new Config Set
The rest of this guide will teach you how to edit a Config Set and then you'll be able to carry
out this step. We're not going to look at this step in any more detail here. For now simply don't
edit the Config Set.
Note: If you make changes over a long period of time, or if you want to check when a Config Set
was last edited, then the Last modification time field on the Config Set shows the time and
date of the last change.
Checkpoint: You've completed all of your edits.

Step 4: Make the Config Set active
Once you have finished making changes to your Config Set, you need to activate it before you
can test it or use it.
• Select the new Config Set in the object tree.
• Click on the enable button or right-click and choose enable from the pop-up menu.
• Click on the activate button or right-click and choose activate from the pop-up menu.
Checkpoint: The Config Set is now fully active and has a green triangle icon in the object tree.
Step 5: Test the changes
Later in this guide you'll learn how to test a Config Set and then you'll be able to carry out this
step. We're not going to look at this step in any more detail here. For now you don’t need to
test the new Config Set because you haven't edited it.
Unless you're a translations genius (or just very lucky!), then you'll probably discover that you
made a mistake. In which case, deactivate the Config Set (there's no need to disable it), make
your corrections and then activate and test it again.
Checkpoint: You should now be happy that your changes are correct.
16 CONFIDENTIAL
Step 6: Make the new Config Set live
You now need to make your new Config Set live, so that all traffic goes through the new Config
Set. Depending on the size of your changes and how busy your system is, you may prefer to
do this during a quiet period in case there's a mistake in the new Config Set.
• Select the Trunk Routing and Policy Services object.
• Click on the … button for the Trunk Routing Config Set field. This will produce a popup
window listing the active Config Sets.
• Select your new Config Set from the list.

• Click on the Apply button.
Checkpoint: The new Config Set is now live and appears as a reference under the Trunk
Routing and Policy Services object in the tree.
Note: If your new Config Set is active but doesn't appear in the list of available Config Sets,
it usually means that your new Config Set is missing a Digit Map that's referenced by a
Subscriber Group. We'll look at Digit Maps and Subscriber Groups later in Collect digits using
Digit Maps on page 23.
Step 7: Disable the old Config Set

You should now disable the old live Config Set to minimize the load on the CFS.
• Select the old live Config Set in the object tree
• Click on the deactivate button or right-click and choose deactivate from the pop-up
menu.
• Click on the disable button or right-click and choose disable from the pop-up menu.
Checkpoint: The old live Config Set is now disabled. You should now have a go at the exercises
below to test what you've learned in this chapter.
CONFIDENTIAL 17
Suggested exercises
1. Find the Trunk Routing and Policy Services configuration on your CFS.
2. Create a new view in the Trunk Routing and Policy Services object for easy navigation.
3. Identify which Config Set is currently in-use on your system.
4. Check that most Config Sets are disabled.
5. Follow the first two tasks in the procedure above to create a new Config Set that's an exact
copy of the current live Config Set on your system. As you go through the guide you can
edit and test your new Config Set.
6. Since it's currently an exact copy, if you want you can practice making this new Config Set
the live Config Set and then swapping back to the original Config Set. Please don't do this
on a busy system, just in case you've made a mistake!
Checkpoint: You now know exactly how to create a new Config Set and make it live on your
system. Well done! In the rest of this guide you'll learn more about the placeholder steps -
editing and testing your new Config Set. Next we need to Look inside a Config Set on page 19.
18 CONFIDENTIAL
Look inside a Config Set
We’ve already said that a Config Set contains all of the configuration you need to make your
CFS translations work, but what exactly is "all of the configuration"? To answer that question,
let’s look inside a Config Set.
For now we'll ignore the italic references, so there are 4 areas of configuration in a Config Set:
• Digit Maps
• Number Validation
• On-Switch Lookups (note, this is ‘On-Switch and LNP Lookups’ for a NANP system)
• Trunk Routing
A new call passing through the CFS will go through all of these stages in turn, so let’s see what
they all do.
Stage 1 in a call - Digit Maps

Digit Maps collect the digits as they're dialed by a CFS subscriber. They are only used when
the CFS is responsible for programming a device to collect the digits. This device may be a
device at the subscriber’s premises, e.g. an MGCP ATA, or it may be a media gateway (like the
UMG), e.g. for GR-303 phones. The device uses the Digit Map to decide how many digits to
collect and then it passes these digits up to the CFS for the next stage of processing.
You can ignore the Digits Map section in the following cases.
• Calls coming from the network. The originating switch is responsible for gathering the
digits.
• Calls coming from SIP or ISDN subscribers. The Digit Map will be programmed directly
onto the end device and this programming is not done by the CFS.
We'll be learning more about Digit Maps next, in Collect digits using Digit Maps on page 23.
Stage 2 in a call - Number Validation

Number Validation is the largest section of translations. Number Validation classifies the call
and, if required, modifies the numbers associated with the call (usually the destination number).
We'll cover Number Validation in plenty of detail later in Modify, classify and block calls in Number
Validation on page 28.
CONFIDENTIAL 19
Stage 3 in a call - On-Switch Lookups

The On-Switch Lookups section tells the CFS which called numbers to look for in the CFS
subscriber database and, if it doesn’t find a matching subscriber, what to do next. This section
consists of a list of number prefixes. If the called number matches one of the prefixes, then the
CFS will look for the called number in the on-switch subscriber database.
The On-Switch Lookups section still exists on a pure Class 4 system. However, the list of
prefixes will be empty since the CFS will never need to look for the called number on the CFS.
Instead, all calls will be routed to a trunk.
We'll learn about On-Switch Lookups later in Look for the called number on the CFS in On-Switch
Lookups on page 73.
Note: In the NANP scheme this configuration section is called On Switch and LNP Lookups since it
also tells the CFS when to do an LNP (Local Number Portability) lookup. We won't cover
LNP lookups in this guide.
Stage 4 in a call - Trunk Routing

Trunk Routing is the final stage of CFS translations and is where the CFS chooses the
outgoing trunk (also known as a Media Channel or Trunk Group) for a call. If a call has already
terminated to an on-switch subscriber then this section does nothing. Trunk Routing is also
the component that handles rerouting, for example if the trunk initially chosen is not available.
We'll look at Trunk Routing later in Route a call off the CFS using Trunk Routing on page 95.
Suggested exercises
1. Open the new Config Set that you created earlier and confirm that it contains all 4
translations areas.
Checkpoint: You now know, at a simple level, all of the 4 translations stages when processing
a call. You also know which stages don't apply for Class 4 systems and which ones don't apply
to calls from trunks. Now you'll learn how the 4 stages of translations fit into the "7 steps" view
of call processing that we teach for troubleshooting.
20 CONFIDENTIAL
Fit translations into the 7 steps
The "7 steps" is a simple way to gain a good understanding of how the CFS processes a call.
Knowing the 7 steps means you can easily interpret diagnostics and work out if, and where,
a call is going wrong. In this chapter you'll learn how the 4 stages of translations (Digit Maps,
Number Validation, On-Switch Lookups and Trunk Routing) fit into the 7 steps.
Let's start with the standard 7 steps diagram. You've probably seen this in other training
courses and material.
Translations are key to this diagram. Translations account for steps 2, 4 and 5 and can influence
the other 4 steps. Let's go through the steps in detail.
Step 1 is Signaling in, which is the incoming signaling message that initiates the call. For calls
from trunks and some subscribers this signaling is determined by other devices. However, for
some types of subscriber, such as GR-303, the CFS provides the Digit Map and so translations
can affect the contents of the incoming signaling message.
Step 2 is Number Validation. This is the second, and largest, stage of translations. It's where
the CFS classifies the call.
Step 3 is the appropriate Caller's CFS services, such as call barring. Why doesn't the CFS do
the outgoing call services first, as soon as the call arrives? You now have enough translations
knowledge to answer this question. The call services need Number Validation to classify the
call first. For example, the call barring service needs to know the call type. The translations
configuration therefore has a big influence on this step because the services rely on work done
by Number Validation.
Step 4 is where the CFS looks on the switch to find the called number. This is part of the
3rd stage of translations - On-Switch Lookups. Calls always go through this step but if they're
going to a trunk then the CFS doesn't do any database lookup.
Step 5 is Trunk Routing, which is the 4th stage of translations. Like Step 4, calls always go
through this step. If the CFS has already determined that the call is going to a subscriber, then
the CFS just doesn't bother going through the Trunk Routing configuration.
Step 6 is the called party's call services, if the call has been routed to a subscriber. Like step
3, this may depend on the call properties as determined by Number Validation.
Step 7 is the outgoing signaling to the called party. Translations can have some influence
over the contents of the signaling.
CONFIDENTIAL 21
Checkpoint: You now have a good idea of how translations fit into the standard "7 steps" view
of how a call is processed on the CFS. This will help you when troubleshooting calls on your
own system. We're now going to look at the stages in turn, starting with Digit Maps.
22 CONFIDENTIAL
Collect digits using Digit Maps
Note: Using only SIP or ISDN subscribers? You can ignore this chapter! For these subscribers the
end device is responsible for deciding which digits to send to the CFS and it will usually send
the full set of dialed digits to the CFS in a single message.
Digit Maps are the first step in processing a call from a subscriber (except for SIP and ISDN
subscribers). They define how many and which digits to collect before passing the set of
dialed digits to the CFS. In this chapter you'll learn why you need Digit Maps and how they're
configured on the CFS.
Here's an example of why we need digit maps. In the UK the number for the emergency
services is 999. If a subscriber starts by dialing 99, then the system must wait for them to dial
the final 9 and then pass the resulting ‘999’ to the CFS, rather than just immediately passing
up the ‘99’.
The Digit Maps are defined under the Config Set. For easier reading, each Digit Map definition
is split into Digit Map Sections. The screenshot below shows the section that covers freephone
calls (also known as toll-free calls) for this particular CFS. (We'll cover the notation in the next
section, so don't worry about understanding it at the moment.)
Note that the names of the Digit Map sections are there to help you find the appropriate
configuration; they are not used to define the type of a call. For example, just because a dialed
call matches something in a section called National numbers does not mean that it will
automatically be handled as a national call. It's Number Validation that actually identifies the
type of the call.
As you can see in the screenshot above, you can have multiple Digit Maps defined on a CFS.
For a simple system this may not be required but you will need multiple Digit Maps if different
groups of subscribers can dial different sets of digits. For example, some subscribers may
be able to call local numbers without using an area code while subscribers in another area
always have to use an area code, so these 2 groups of subscribers need different Digit Maps.
Subscribers are linked to specific Digit Maps via the Subscriber Group object.
CONFIDENTIAL 23
Did you know? The English word digit comes from the Latin digitus, meaning finger or
toe. Since people often count on their fingers, 'digit' came to mean 'numeral' as well. This
isn't true for other languages though, so perhaps English speakers are particularly keen on
counting with their fingers!
Note that the Subscriber Group field is mandatory for a subscriber and the Digit Map field
is mandatory on a Subscriber Group object. This means that even if you don't use the Digit
Maps on the CFS because you only have SIP or ISDN subscribers, you must still have 1 Digit
Map and Subscriber Group configured just so that you can set the Subscriber Group field
on your subscribers. In this situation the actual contents of the Digit Map are irrelevant since
it'll never be used.
In early versions of the CFS, Subscriber Groups were also often used to separate groups
of subscribers that needed special processing. For example, all subscribers in a particular
town, such as London, would be associated with a specific Subscriber Group. The translations
would then look at the Subscriber Group to decide what area code to add and other related
processing. On most CFSs this function is now performed by Line Class Codes, also known
as LCCs. We'll cover LCCs later in Record call properties using Attributes on page 53; for now
you just need to know that the main purpose of Subscriber Groups is to link subscribers to
Digit Maps.
24 CONFIDENTIAL
Note: Digit Maps are slightly more complex if you need to deal with Business Group subscribers
(also known as HPBX or Business Services). In this case, the CFS first sends the Business
Group Line an auto-generated Digit Map based on the Business Group's external line code,
intercom codes, short codes etc.
If the subscriber dials an intercom code or short code then the CFS converts the code to the
full destination number before passing the call into Number Validation.
If the subscriber dials the external line code, the CFS sends the standard Digit Map to collect
the destination number. This destination number is then passed into Number Validation.
Checkpoint: You can now explain why the CFS needs Digit Maps for certain types of subscriber.
Now we need to look at how Digit Maps are defined.
Understand the notation used for Digit Maps

The notation used to define Digit Maps on the CFS is based on the notation used for MGCP
Digit Maps and similar notation is often used to configure Digit Maps on SIP devices, so it may
look familiar to you.
() Digit Maps start and end with round brackets.
| The vertical pipe separates valid entries in the Digit Map.
X X is a wildcard that matches any digit 0-9.

For example, 3X will match 30, 31, 32, 33 etc. up to 39.
* # These represent the * and # keys on a keypad.

For example, *XX* matches the star key, followed by 2 digits, followed by the
star key again.
[ ] Choose one value from those inside the square brackets.

For example, [45]9 will match 49 or 59.
. Repeat the value directly before the "." any number of times, including zero times.
For example, 79. will match any of 7, 79, 799, 7999 and so on.
- The hyphen is used to specify a range of possible values. This is always used in
square brackets.
For example, 1[1-3] will match 11, 12 or 13.
T The critical timer. We'll look at this parameter in more detail in the next section.
Understand timers in Digit Maps

Timers (also known as timeouts) are used in CFS Digit Maps to decide how long to wait for the
caller to dial more digits. The CFS uses two timers - the critical timer and the partial timer.
Here we'll look at how the timers are used and where they are defined.
CONFIDENTIAL 25
The critical timer is defined in a Digit Map as "T" and is typically 4 seconds long. This timer is
used when a valid digit string also forms part of a longer valid string. Once the subscriber has
dialed the first valid string, the device starts the critical timer. If the subscriber does not dial
more digits before the timer expires, the first valid string is passed to the CFS. If the subscriber
dials more digits, the device assumes that the subscriber is trying to dial the longer valid string.
Did you know? While we're talking about maps… The distinctive London Underground
(or "Tube") map was first designed by Harry Beck in 1931 as a personal project in his spare
time. Since then his topological, rather than geographical, style has been widely adopted
by other networks around the world. In 2006 it was voted 2nd on a list of 20th Century
British design icons in a television poll, beaten only by Concorde.
For example, in the USA "0" and "00" are both valid phone numbers (they're used for operator
calls). In addition, 011 and 01 are valid number prefixes (they're used for international calls and
international calls with operator). So, if the subscriber dials "0", how on earth can the device
tell what number the subscriber is trying to call?! Here's the relevant part of the Digit Map that
makes it work.
0T|00|01[2-9]XXX.T|011[2-9]XXX.T
So, when the subscriber dials 0, the device starts the critical timer then waits to see what
happens.
• If the subscriber doesn't dial anything else before the timer expires, then the device matches
0T and passes the digit string to the CFS.
• If the subscriber dials a second 0 before the timer expires, then the device matches 00 and
passes the digit string to the CFS.
• If the subscriber dials 1 before the timer expires, then the device cancels the timer and
waits for more digits to see whether the subscriber is dialing an 01 or 011 international
call. Numbers can be different lengths in different countries so international calls can be
of variable length. Hence, both international call digit map sections end with X.T. This
indicates that the device must wait for any number of digits (including none) followed by
the critical timer.
The partial timer is used when a subscriber has started to dial something that matches the
first part of a valid string. As an example, consider a Digit Map that contains the following
section
02XXXXXXXXX
(This section matches on 02 followed by 9 digits.) If the subscriber dials 0212345 then
pauses, the device will start the partial timer. If the subscriber then starts dialing again, the
timer is canceled and the device continues collecting digits. If the subscriber doesn't dial any
more digits, the device sends the incomplete string to the CFS. The partial timer defaults to 16
seconds, which gives a subscriber plenty of time if, for example, they need to refer back to their
address book while dialing a number.
Define the Digit Map timers

For most types of subscriber, the Digit Map timers are defined on the device itself. Depending
on your deployment, this may mean that you cannot access or change the timer values.
The exception is for subscribers using devices that send dialed digits individually to a gateway
controlled by MeGaCo, such as a Metaswitch Universal Media Gateway (UMG). In this
case it is the gateway that applies the digit map to decide which digit strings to send to the
CFS. This applies to subscribers using GR-303 or T1 CAS. For these devices the value of the
timers can be set by the CFS. The configuration for these timers is on the Digit Map object, so
that each Digit Map can have its own timers.
26 CONFIDENTIAL
Suggested exercises
Make sure you use your new Config Set (which you created in Manage your translations using
Config Sets on page 11) for all of the exercises.
1. Find the Digit Map(s) configured on your CFS.
2. Check that you understand all of the Digit Map sections - what types of call do they match
on?
3. Configure a Digit Map to accept a new length of Speed Dial code, by editing or adding a
Section.
4. Create a new Digit Map with a critical timer of 5 seconds and a partial timer of 12 seconds.
5. List a selection of dialed digits that would match the Digit Map (101XXXX|950XXXX|[0-9*].#).
6. List a selection of dialed digits that would match the digit map (0T|00|555XXXX).
7. Add a new Digit Map Section for some test numbers that you are going to use, where the
test numbers can be either: 101 or 1011 or 100 or 102-109, or 7 digits in length prefixed
by 958 or 959.
Checkpoint: You can now find and understand the Digit Map configuration on your CFS,
including the challenges of using timers to distinguish similar number patterns. That's everything
you need to know about Digit Maps (they're really not very difficult), so now we're going to get
to the heart of translations and learn how to Modify, classify and block calls in Number Validation
on page 28.
CONFIDENTIAL 27
Modify, classify and block calls in Number Validation

Number Validation (often shortened to NV because we need to refer to Number Validation
configuration so frequently) is the largest and most complex part of translations. So, make sure
you're comfortable with Number Validation before you move onto the later chapters!
So, let's start by asking the simple question - what does it do? Number Validation performs 3
important roles.
• Editing numbers
• Blocking bad calls
• Call classification
Let’s look at these in a bit more detail.
Firstly, Number Validation is the main place for you to edit the numbers associated with a
call. The most common change is to change the called number to a standard length, but there
are many other possibilities. Here are some examples of typical modifications.
• If the subscriber dials a local number without the area code, then Number Validation adds
the area code as a prefix.
• If the subscriber dials a prefix, e.g. 0 or 1, to indicate that something is a long-distance call,
then often the prefix is removed in Number Validation.
• A Freephone (also known as toll-free) number for a business is hosted on your CFS so
the Freephone number is changed to the business’s real office number.
Generally, the aim is to ‘normalize’ all relevant numbers to match the format that you use for
defining subscribers on your CFS, which is usually the area code plus a personal number. This
needs to be done before the CFS looks for the called number in the subscriber database.
Normally, you want to edit the called number, but it is also possible to edit other numbers
associated with the call, such as the calling number.
Note: You can also edit numbers in Trunk Routing, but typically you only do this if you need to make
a last-minute edit, such as removing the area code, because the call is going to a specific
trunk or destination.
Number Validation is also where you can block bad calls. For example, if a subscriber
accidentally misdials a number and dials too many digits, then Number Validation should reject
the call. Similarly, Number Validation may block incoming trunk calls if the called number format
is not recognized. Digit Maps (covered earlier in Collect digits using Digit Maps on page 23) will
also help to stop misdials and remote switches hopefully will not send bad numbers, but
Number Validation is the most powerful place to check numbers.
Once you have blocked misdials and normalized the digits, the main purpose of Number
Validation is to classify the call by identifying the properties of the call. Number Validation
analyzes the call and records the properties of the call in Attributes (which we’ll cover later
in Record call properties using Attributes on page 53). The rest of the CFS then just acts on the
Attributes, rather than needing to re-analyze the call.
Checkpoint: You now know what Number Validation does, so you can probably spot that it
contains quite a lot of configuration! You're now ready to start looking at the configuration,
starting with an overview.
28 CONFIDENTIAL
Get an overview of Number Validation configuration
We're now going to look at the concept behind Number Validation configuration before we dive
into the actual configuration objects. This is all generic information and applies regardless of
which base scheme we’ve installed on your system.
It can be overwhelming the first time you open up the Number Validation configuration because
the tree looks very full, but don’t panic!
The concept behind Number Validation is actually very simple – it’s just a flow chart. If you can
represent your translations as a flow chart, then you can configure it.
Your flow chart is then configured using just 2 types of object – Tables and Entries. Tables are
the boxes in your flow chart, while Entries are the arrows between the boxes.
CONFIDENTIAL 29
Note: Please don't use this as an example of how to name your Tables! You should give your
Tables and other objects names that make clear what they do. This makes it much easier to
understand the configuration. In this example, the Table should ideally be named something
like "Block calls to certain countries".
Another way of looking at Number Validation is that Tables ask the questions – “which trunk
did this call come from?” – and Entries are the possible answers – “SIP Trunk A”, “ISUP Trunk
B” etc. As you may spot from the diagram, the Entries are also where you can modify numbers
and record information about the call, e.g. “this is an international call”.
Checkpoint: You now know what Number Validation does and you know how the configuration
fits together to create a flow chart to handle the different types of call. Now we can move onto
the actual configuration objects, starting with Tables.
Understand Number Validation Tables

Now you know how Number Validation configuration fits together, let's now look at the actual
configuration. We'll start by looking at Number Validation Tables.
There are 2 main starting points in Number Validation that you need to find – one for calls from
subscribers and one for calls from trunks. These are defined by fields on the Config Set and
are also shown as links in the tree, so they’re easy to spot and follow.
Looking at the sample screenshot above, if a call arrives from a subscriber then the call will
first start in Number Validation Table 50, while calls from trunks start in Number Validation Table
10000. Depending on your configuration you may see similar looking references in the tree to
Attributes Sets. We’ll cover Attributes later, so ignore them for now and make sure that you’re
looking at the Call from subscriber/trunk: Number Validation Table references!
If you click twice on the reference, it’ll open up the Number Validation configuration and take
you to the appropriate Table. In the following screenshot I’ve followed the reference for a call
coming from a trunk.
30 CONFIDENTIAL
Note: Get into the habit of using the references in translations. It's faster (and much less error
prone!) than opening the tree and trying to find the relevant object manually.
Depending on your configuration and which

reference you followed, you may find that the Did you know? Mensa is an international
initial Number Validation table isn’t the table at society for people with a very high IQ. When
the top of the list in the object tree. The Tables
the society was formed its monthly journal
are ordered in the tree according to their index
numbers. The index number is also used to was going to be called Mens, which is Latin
identify Tables uniquely, but it has nothing to for "mind". However, they realized this could
do with the order in which Tables are used. cause confusion with another journal called
For example, a call could start in Table 100, Men Only. Eventually they decided to call
then go to Table 90, and then on to Table 200.
themselves Mensa, which is Latin for "table"!
So, ignore the index numbers when following
calls through Number Validation.
The next step is to identify what a Table is looking for, i.e. what question it’s asking. Firstly, each
Table must match on a number (don't worry, you can set up a Table that ignores the number,
but we'll cover that in detail in the next section). This is usually the called number, but can also
be the source (i.e. calling) number and various other numbers that can be associated with a
call. The type of number is controlled by the Address match type field, as shown below.
Once you have chosen the type of number you want to look at, there are 3 types of match,
controlled by the Search type field - Complete, Unique and Prefix.
CONFIDENTIAL 31
• In a Complete match Table, the entire number must match a child Entry. This means both
the contents of the digits and the number of digits must match. This type of Table is used if
you want to separate calls based on the number's length; for example, to identify different
permitted speed dial number calls from subscribers.
• The Unique match type is only used if you're doing overlap signaling, where the destination
digits can arrive at the CFS split between more than one signaling message. In comparison,
the majority of CFSs deal with enbloc signaling, where the destination address arrives in a
single message. We're going to ignore overlap signaling for now (we'll cover it later in Get
ready to discuss overlap signaling on page 64), so just ignore this option for now.
• With a Prefix match Table, the start of the number you're looking at needs to match one
of the child Entries. This type of Table is used to identify calls with a distinctive prefix, such
as international calls.
Most Tables in Number Validation are typically configured to do a Prefix match on the
Destination number (i.e. the called number).
As well as matching on the number, you can match on up to 3 other parameters by using the
Match Attribute fields. In the following example the Table is matching on the source address,
plus Match Attribute 1 is set to “Incoming Media” which means the Table will also look at the
incoming trunk (a.k.a. media channel).
When you create Entries in a Table, the Entries are automatically created with the fields that
correspond to the match type(s) set on the parent Table. For the example above, Entries in the
Table will have fields to define the required source address plus fields to define the required
incoming trunk. We’ll look at configuring Entries later in this chapter.
For a call to pass successfully through a Table, it must find a matching Entry. Before we look at
Number Validation Entry objects in detail, let's quickly consider a couple of error cases.
Firstly, what happens if a Table has more than one Entry that matches a call? There must not
be more than one Entry in a Table that matches identically; this is a misconfiguration. The CFS
will choose the Entry with the lowest index so that it can continue to process the call, but it will
also produce an error log stating that it found 2 possible matches. Note that it's fine to have
more than one possible match, as long as one of the Entries is a better match than the others.
We'll look at this in more detail in the next section.
Secondly, what happens if there's no possible matching Entry in a Table? In this situation the
default behaviour is for the call to be rejected. In many cases this is probably not an error! For
example, in the screenshot below there are Entries for all speed dial formats supported on this
particular CFS. If a call doesn’t match one of the Entries then it’s a misdial and we do want the
call to be rejected.
32 CONFIDENTIAL
In other words, it's a white list model because a call must match one of the Entries to pass.
Note: The numbers shown in brackets at the end of the Entries in the tree, such as (7) and (9), are
the Entry index numbers. As with Table index numbers, each Entry in a Table has a unique
index but it's not used for matching so you can generally ignore it.
Occasionally you may want the opposite behaviour; it may be easier to configure a Table so
that all calls pass by default unless they match one of the Entries. In this case you can use the
Action if no match field on the Table to control what happens if no match is found.
Checkpoint: You now know how to configure a Number Validation Table object to match on
certain call parameters; effectively, to ask a question about the call. You also know how to
block misdialed calls by not having a matching Entry in a Table. Now let's see how the child
Number Validation Entries provide possible answers to the question asked by the Table.
Identify which Number Validation Entry matches a call

Each Number Validation Entry matches on a unique combination of call properties and then
defines what to do next with the call. Here you'll learn how the CFS chooses which Entry to
use for a particular call.
When a call reaches a particular Table, the CFS will look at all of the child Entries to see which
Entry is the best match for that particular call. The exact match fields shown on the child Entries
will depend on the match fields on the parent Table.
The first field the CFS will look at is the Number field, which is always present.
Note: The Minimum match length field only applies if you're doing overlap signaling, so you can
ignore it here. We'll cover overlap signaling later in Get ready to discuss overlap signaling on
page 64.
The value of the Number field needs to match the appropriate number associated with the call
(as defined by the Address match type field on the parent Table). Here's a list of the notation
used for the Number field.
Symbol What does it match? Example

A digit The digit "3" matches "3"
CONFIDENTIAL 33
Symbol What does it match? Example

X Any digit 0-9 3X matches on 30, 31, 32, 33… up to 39
A, B, C, D The letter “A” matches on “A”
* and # The * and # on the *55 matches *55

telephone.
Digit in Digit is optional (0)1 matches both 1 and 01

parentheses
Square Match one of the [23] matches 2 or 3.

brackets with numbers in the brackets [12-4] matches 1 or 2 or 3 or 4
2 or more Using square brackets to match on multiple
digits or a numbers in a single Entry can be helpful if you
range want to minimize the number of Entries in a
large Table.
The notation used for Number field notation is intentionally very similar to the Digit Map notation
(which we covered earlier in Collect digits using Digit Maps on page 23), but there are slight
differences. In particular, in Number Validation you can do explicit prefix matches which only
look at the start of a number. Therefore there is no need for the “.” symbol; in Digit Maps this
means repeat a symbol any number of times. There’s also no need for the “T” symbol (critical
timer) since generally the complete number will be passed onto Number Validation in one go.
Note: Note that, as in Digit Maps, the “*” matches the star on the keypad and is not used as a
wildcard. The only wildcard symbol is the X, which will match any digit 0-9.
It's also acceptable to leave the Number field blank. If this is a complete match Table, then a
blank Number field will only match if there's no number present. If this is a prefix match Table,
then a blank Number field will match any number. This is how you can configure a Number
Validation Table that effectively ignores the number and just looks at the Match Attributes.
The CFS will choose the best match based on the Number field. If there are multiple possible
matches then the CFS has to find the most specific match. For example, consider a prefix
Table with the following Entries (the numbers in brackets at the end are the Entry indices so you
can ignore them when considering matches).
If the call is to 321, then all 3 Entries are possible matches, but the 321 Entry is the more
precise match. Similarly if the call is to 324, then both 32 and 32X will match, but 32X is the
better match because it is closer in length. If you can’t work out which Entry is the best match,
then it probably means you need to configure your Tables differently so that it’s clearer!
Make sure you check whether the Search type field on the Table is Prefix match or Complete
match when looking to find a match based on the number. If you use a prefix match, the dialed
digits must be at least as long as the prefix defined in the Number field. For example, an Entry
with 1234 will match 1234 or 12345, but not 123. On the other hand, if you use a complete
34 CONFIDENTIAL
match then the full length of the number must match. For example, an Entry with 1234X will
only match a set of 5 dialed digits (e.g. 12345), not 1234 or 123456.
If the number matches, the CFS then looks at the other match parameters, as defined by the
Match Attributes on the Table, to decide which Entry is the best match. These match fields
are in the Attribute values section and only appear if you've set the Match Attribute fields
on the parent Table. We'll cover call properties and Attributes in more detail in the next chapter
(Record call properties using Attributes on page 53), but here's a quick example with 2 Entries that
match on an incoming trunk.
You can see that a call arriving on the TR_1000 SIP trunk will match the second Entry because
this is the better match, while a call arriving on any other SIP trunk will match the first Entry.
Checkpoint: You can now look at the Entries in a Number Validation Table and identify which
Entry is the best match for a particular call. This is the Entry that the CFS will use to process
the call. Now let's learn how the Entry controls what happens to the call.
Find out what happens when a Number Validation Entry matches a call
When a call matches a specific Entry in Number Validation, the configuration on that Entry tells
the CFS what to do with the call, so now we need to look at what the remaining fields in an
Entry do.
This configuration has two parts - modifications to the call and what to do next, after the
modifications. I find that the fastest way to understand what an Entry does is actually to start
with the second part - what to do next. This behaviour is controlled by the Next action field,
which is mandatory.
CONFIDENTIAL 35
The Next action field is usually set to one of the following two values.
• Complete validation. This means that we’ve done everything we want to do in Number
Validation, so the CFS can now move to the next stage of translations.
• Look up. This tells the CFS to continue Number Validation by looking for a match in the
next Table, as defined in the Next Number Validation Table field. Don't let the name of
this option confuse you - it's nothing to do with looking for the number in a database!
Using these two values builds up your Number Validation flow chart.
You'll see the other possible values for the Next action field less frequently but you will still
come across them. Here's the full list of values and what they do.
Next action What it does
Use default This means the Next action for the Entry is taken from the
Default next action field on the parent Table. The Default next
action field on a Table takes the same values as the Next action
field on an Entry.
Complete validation As described above, this means the call has finished Number
Validation.
Look up As described above, this means the CFS needs to move to

another Number Validation Table, which will be defined by the
Next Number Validation Table field.
Reject and announce Reject the call immediately and play an error announcement. By
default this will be a generic error announcement, but you can
also apply Attributes to choose a specific announcement. We'll
cover Attributes later in Record call properties using Attributes on
page 53. For now, just remember that it's possible to control
which announcement is played.
Announce and This is the same as Reject and announce except that after
complete validation playing the announcement the CFS will complete Number
Validation so that the call moves on to the next stage of
processing.
36 CONFIDENTIAL
Next action What it does
Announce and lookup This is the same as Reject and announce except that the
CFS will move to another Number Validation Table after playing
the announcement. The next Table will be defined by the Next
Number Validation Table field.
Store carrier ID and This is typically used in NANP deployments where a subscriber
restart can choose the carrier for a call by dialing 101CCCC before the
number, where CCCC is the carrier's unique code. This is referred
to as casual dialing. This Next action value will store the CCCC
code and then restart Number Validation with the rest of the
dialed digits, which will be the final destination number. Carrier
calls are not covered in this version of the guide.
Store carrier ID and This is the same as Store carrier ID and restart, except that the
lookup CFS will move to another Number Validation Table, which will be
defined by the Next Number Validation Table field.
Handle as SAC This means the call has been identified as a Service Access Code
(SAC). Number Validation will now finish and the CFS will try to
find the call service which owns the SAC. The call service will then
handle the call.
Fail ANI Screening ANI Screening is where calls are blocked or permitted based on
the caller's number. We'll cover this service and its configuration
in detail later in Maintain and understand the configuration for ANI
Screening on page 124.
Checkpoint: You can now use the Next action field to understand how the Entry fits into the
Number Validation flowchart. Now you need to learn how Entries can modify calls, starting with
changing the numbers associated with a call.
Modify numbers in Number Validation

One of the most important things that a Number Validation Entry can do is modify one of the
numbers associated with a call. The most common changes are adding and removing prefixes
to standardize dialed numbers, but you can make many other changes. Here you'll learn how
this feature is controlled by the Number action fields in an Entry.
CONFIDENTIAL 37
Note: Don't be confused - the Number action fields are below the Next action field, but the CFS will
only do the Next action when it has finished doing everything else configured on the Entry,
including the Number action.
An Entry can only modify the type of number that it matches on. For example, if the Table
matches on the destination then the child Entries will only have the Called number action
field. If the Table matches on the source then you can modify more numbers, but only those
associated with the calling party. If you want to modify both the source and destination numbers
then you will need to use multiple Tables.
The notation used in the Number action fields is very simple. There are two types of action
you can use: automatic actions that normalize the number into a particular format and manual
ones that let you edit the number more precisely.
The following number actions perform automatic number normalization for the locale set on
your CFS:
• NF<NDP>: national format with national dialing prefix (typically a 1 or 0).
• NF<NAT>: national format without national dialing prefix.
• NF<IAC>: international format with access code.
• NF<INT>: international format without access code.
There are also lots of number actions that let you manually edit the number. These are the key
ones:
• PA<string> (Prefix Append). Add <string> to the start of the number.
• PD<number> or SD<number> (Prefix/Suffix Delete). Delete <number> of digits from start/
end.
• SD#. Delete the trailing # symbol, if there is one.
• R<new string>. Replace the existing number with <new string>.
38 CONFIDENTIAL
Note: Here's a handy tip for those of us who don't have photographic memories! Scroll to the
bottom of the help panel in MetaView Explorer to see the notation and options for all the
available number actions.
Checkpoint: You now know how to modify numbers in Number Validation. We're now going to
finish learning about Entries by looking briefly at the other things Entries can do to a call.
Do other things to a call using Number Validation Entries

So far we've looked at how a Number Validation Entry can modify numbers and how the Next
action field affects a call, which covers a lot of what an Entry does. For completeness, we're
now going to look briefly at the other fields on an Entry. Here's a sample Entry that we'll go
through.
The first field is the Number Validation Entry name. This isn't mandatory but I wish it was
because a good name makes it much easier to understand what an Entry is supposed to
do! Using the name fields effectively is a common theme throughout this guide. When you're
actively working in translations a lot, then you may be able to remember what a particular
object does. However, if someone else needs to understand your configuration, or if you have
a break from translations, then it really helps if things are clearly labeled.
After the name, the Number and Minimum match length fields tell the CFS what number
this Entry will match. We've already looked at number matching in detail earlier in this chapter.
The next field is the Routing Attribute Set. Attributes are used to record properties of the call
for use later in the call by translations, and also by other CFS components. Number Validation
classifies calls by adding Attributes. Attributes deserve their own chapter, so we'll cover them
later in Record call properties using Attributes on page 53.
After the Routing Attribute Set, the Next action field tells the CFS what to do next. We've
already covered this field. The Next action field is followed by two billing-related fields - Use
number for main billing record and Use number in billing Module 611. These fields
are used if a number is going to be modified in Number Validation but you want to use the
original number in the billing records, rather than the modified final number. The billing fields are
followed by the Number action section, which we looked at earlier; it's where you can modify
the numbers associated with a call.
The final fields are in the Attribute values section. We've covered these earlier in the chapter;
they're used to match on other call properties.
CONFIDENTIAL 39
Suggested Exercises
1. Choose a type of call, such as local or national, and draw a flow chart for how you expect
it to be processed in Number Validation.
2. Identify the first Number Validation Table in your Config Set for calls from subscribers and
for calls from trunks.
3. Consider a Complete match Table with an Entry with the Number field set to [3-9]11.
Which numbers will this match?
4. Consider a Prefix match Table with 3 Entries that match on 123XX, 12XXX and XXXXX. If
the incoming number is 12345, which Entry will the CFS use?
5. If the incoming destination number is 56789, and the Called number action field is set to
PD3PA101, what is the resulting destination number?
6. If your configuration contains a Table called something like "Digits main table",
"Digits main" or "main", then look at the Table and its child Entries and make sure you
understand what each Entry will match on.
Checkpoint: You now have a good understanding of how Number Validation Tables and Entries
work together to process calls (ignoring Attributes for now, because we'll cover them later).
We're now going to take a slight detour from specific configuration objects and look at how you
can use selection fields effectively.
40 CONFIDENTIAL
Use search selection fields to set values easily in translations
Use search selection fields to set values easily in translations
Many fields in translations that refer to other objects are set using search selection fields.
This type of field has a magnifying glass button at the right-hand side of the field.
This button works in a similar way to dialog selection fields (the ones with the '…' button),
except that you can type in match parameters in the field box before clicking on this button as
a short cut to find the object you want. This is particularly useful in translations where you may
have, for example, hundreds of Number Validation Tables, so waiting for the full list of Tables to
appear in the popup will be tedious.
The main two ways to search are by prefix and by index. To search by prefix, type the prefix,
for example Fan in the example above, in the field box before hitting the search button. To
search by index, type =Index in the box, for example =10 in the example above. You can also
search by a range of prefixes or indices. For full details of these see the MetaView Explorer
User's Guide.
Searching by name or index is particularly useful if you have a standard naming or numbering
convention. For example, in the NANP translations scheme, the Number Validation Tables for
particular local calling areas have distinctive indices. This numbering was designed so that
users can make full use of this search selection feature. You may want to do something similar
if you have a large number of objects.
Checkpoint: You've now learned a trick that will be very useful if you have large numbers of
translation objects. After that short aside, we're going to use what you learned in the previous
chapter to follow a sample call through Number Validation.
CONFIDENTIAL 41
Follow a call through Number Validation

Now that you've learned how Number Validation is configured, you're ready to try following a
call through Number Validation. This is a useful test because it makes sure that you understand
how the CFS uses the configuration.
As a summary from Modify, classify and block calls in Number Validation on page 28, here are the
steps for following a call.
1. Go to the first Table
2. Identify what the Table is matching on
3. Find the best match Entry
4. See if the Entry modifies the call
5. Find out what happens next
6. Repeat Steps 2-5 until Number Validation is finished
In this example I'm going to follow a call to 01632 762000, a national number through the
International base scheme customized for a UK dial plan. If you also have the International
scheme on your CFS then many of the Tables will look similar.
Note: If you have a NANP scheme then the Tables will be different but the techniques for following
a call are still the same. We covered the two different schemes earlier in Identify your base
configuration on page 10.
Once we've followed this specific call, we'll then take a step back and take a high-level look at
the International translations scheme.
Go to the first Table

First you need to find the starting Number Validation Table. This depends on the type of call.
Is it a call from a subscriber or from a trunk? Once you've identified the call type, look at the
references under the relevant Config Set object and find the appropriate Call from reference.
The fastest way to get to the first Table is to click twice on the reference, then the MetaView
Explorer will take you to the Table. Remember that the first Table may not be the one at the top
of the list in MetaView Explorer. In our example, it's a call from a subscriber, which means we'll
start at Table 50: "Application server preprocessing".
It can be easy to get lost in the translations configuration because there are so many objects.
However, don't panic! If you end up on the wrong object then just use the back button until you
get back to somewhere that you recognize.
42 CONFIDENTIAL
Did you know? New York is the considered to
be the world's most linguistically diverse city, with
around 800 languages spoken. Only 51% of New
Yorkers speak English at home, with the most popular
non-English languages being Spanish, Chinese and
Russian.
Table 50, "Application server preprocessing"

Personally, I think that Table 50 is the hardest Table to understand in the base configuration,
which is unfortunate since it's the first Table that many people look at when they're learning
translations! If the rest of this section makes your head spin, don't worry, just skim this Table
and look at the other Tables first. Once you're comfortable with how the other Tables work,
come back to this Table.
Identify what the Table is matching on

So, now that you've got to the starting Table, you need to find out what the Table is matching
on. In Modify, classify and block calls in Number Validation on page 28 we referred to this as the
question that the Table is asking. To find this, look at the match fields.
Every Table matches on a number. In this example, the Table will do a Prefix match on the
Destination. This means the Entries will look at the start of the called number. If the called
number matches, the Entries will look at up to 3 other properties.
In this example the Table is matching on the Called Address Scope. We'll cover scope
in more detail later in Record call properties using Attributes on page 53, but for now you can
simply assume that scope indicates the type of the call. Remote ISUP destinations can signal
this parameter as the Nature of Address Indicator (NOA). Remote SIP destinations can signal
international scope by putting a + on the front of the destination in the URI, or they may omit
the + and simply include the appropriate international dialing prefix as part of the destination
number.
CONFIDENTIAL 43
This Table is interested in the scope because it's responsible for converting any calls from
Application Servers, such as the MetaSphere Enhanced Application Server (EAS), to the same
format that a subscriber would use to dial the call. When an Application Server makes a call,
it may not dial the call in the format required by your particular country. For example, it may
include the country code for all calls, even if they're going to the local country. This Table is
responsible for changing the destination number to the same dial plan format that a subscriber
would use.
Find the best match Entry

Now that you've identified what the Table is looking for, you need to look at the child Entries
and decide which one is the best match. Here are the Entries in our example.
Since we're following a national call dialed by a subscriber, just by looking at the Entry names
you can guess that the call should match the All other calls Entry. As you can see, giving
objects sensible names makes your life much easier! However, before we look at that Entry
in detail, the other two Entries are interesting, so I'm going to take a closer look at them first.
First, here's the Add intl prefix to international calls Entry.
You can see that the Number field is effectively blank. Since this is a Prefix match Table,
that means that the Entry will match any possible number and will therefore match all calls.
Since the number matches, the CFS will then look at the Attribute values section. We'll look
at Attributes later (in Record call properties using Attributes on page 53), but you can see that it's
matching on International scope calls.
44 CONFIDENTIAL
This Entry will therefore match any calls made from Application Servers where the Server has
flagged the call as international. The Number action section then shows that the CFS will add
a prefix of 00, which is the international dialing code on this system.
The other special Entry is Calls dialed as international to local country.
This Entry spots calls that the Application Server has dialed as international calls but that are
actually for the local country.
The Entry spots these calls by looking for an international scope and a country code of 428 (the
country code in this example). The Entry then modifies the called number by doing PD3PA0.
This removes the first 3 digits and then appends a 0, which converts the number to a standard
national call.
In our example we'll assume the call was dialed directly by a subscriber, so the scope will not
have been set yet. The call will therefore not match either of these Entries. Instead, the best
match is the All other calls Entry, which matches on any possible value of the scope,
including no scope.
CONFIDENTIAL 45
See if the Entry modifies the call

We have now identified the Entry that the CFS will use for this call. Now let's see if the Entry
modifies the call in any way. First, check the Number action section. This is blank, so the Entry
will not modify the called number.
If you really want a detailed view of the call processing then you should also check the Routing
Attribute Set field. However, Attributes can cause confusion and they're not essential at this
stage, so ignore them for now (we'll cover them later in Record call properties using Attributes
on page 53).
Find out what happens next

Finally, find out what will happen next by looking at the Next action field. This has been set to
Use default, which means the Entry will use the value from the Default next action field on
the parent Table.
This means the call will now go to Table 100, "Digits prefix table".
Table 100, "Digits prefix table"

We now go through the same steps again for Table 100, the "Digits prefix table". First, you
need to look at the Table to see what it's matching on. In this case it's simply doing a Prefix
match on the Destination number, so we don't have to consider any other call properties.
46 CONFIDENTIAL
The "Digits prefix table" is responsible for doing the initial separation of calls into different types.
It identifies 3 types of call that are easily distinguished by their prefix - Service Access Codes,
international and all others.
Service Access Codes (SACs) can be identified by their prefix - either * or #. Remember
that the * represents the star on a keypad; it's not a wildcard (we covered the notation in
Modify, classify and block calls in Number Validation on page 28).
These calls are sent to Table 5000, "Service Access Code call processing", which has Entries
that match on the expected SAC dial patterns. For example, your CFS may support access
codes of the form *XX*, but not *X*. The Entries in Table 5000 have the Next action field set
to Handle as SAC. The CFS will then complete Number Validation and find the call service that
owns the dialed access code. The call service will then handle the call.
International calls can be identified by the international dial prefix. It's a good idea to
separate them out from other calls early in the processing. This is mostly because international
destination numbers don't have a known, fixed length (since different countries have different
dial plans). That means you can't use Complete match Tables when dealing with international
calls.
CONFIDENTIAL 47
International calls are sent to Table 3000, "International preprocessing", where the international
dialing prefix is removed (on the assumption that the prefix should not be included when the
call goes to the network). After that, Table 3020, "International processing", records the length
of the country code because some types of signaling, such as MF, may signal the country code
separately.
This is followed by two Tables to try to reduce call fraud. Table 3040 bars calls to high-risk
countries. You can control this feature on a per-subscriber basis using Line Class Codes. We'll
cover these later in Extend the built-in Attributes using Line Class Codes and User Defined Attributes
on page 60. Table 50000 then bars calls that have been forwarded rather than dialed directly.
This is because we've seen call fraud at some service providers where criminals get access to
someone else's account and set up forwarding to international destinations so that they can
make free calls. You can remove or edit these Tables if you want to change the behaviour, but
be careful: they're there to protect you and your revenue!
All other calls match the Default entry in Table 100. The Number field is blank so that it
matches all possible numbers. Our example national call will use this Entry.
Like the other Entries in this Table, this Entry itself doesn't do anything. It simply sends the call
to another Table - "Digits main table".
Before we look at that Table, it's worth noting that the International base scheme is designed
so that the Table index values increment as the call flows through. This means that calls always
start near the top of the Number Validation object list and then go down the Tables. The Tables
are designed this way because it makes it easier to understand the configuration and follow
a call. If you add Tables we recommend that you set their index to retain this downward flow.
(The NANP configuration, on the other hand, has evolved more and calls jump up and down
the Number Validation Tables, which is harder to follow!)
Table 200, "Digits main table"

At this point we've isolated the 'normal' calls, meaning those that aren't SACs or international.
This means that, for many countries, we can now easily separate out the different types of call
based on their prefix and length. This is what "Digits main table" does.
48 CONFIDENTIAL
As before, start by finding out what the Table matches on. In this case it does a Complete
match on the Destination. Since it's a Complete match, the length of the number needs to
match exactly, not just the prefix.
The Table contains lots of Entries, each of which matches on a specific type of call. Obviously
the exact contents of this Table depend on your particular dial plan. Here are the Entries in the
example configuration I'm using.
The main purpose of this Table is to split the calls by type and send them to other Tables
for type-specific processing. Since the Table is doing a Complete match, the Entries can
distinguish calls based on the length, as well as the prefix. So, for example, there are Entries to
separate 2-digit numbers and 3-digit numbers.
CONFIDENTIAL 49
Again, good naming means it should be easy to identify the best match Entry for your call.
In this case, it's the National geographical call processing Entry. It's called a
geographic call because the 01632 prefix is belongs to a specific area rather than being a
national code.
This Entry adds an Attribute Set to the call. We'll cover Attribute Sets later in Record call
properties using Attributes on page 53. For the moment just ignore Attributes. The Entry then
sends the call to Table 1200, "National geographical preprocessing".
Table 1200, "National geographical call preprocessing"

This Table play a similar role to Table 3000, "International preprocessing". It normalizes the
called number by removing any national dial prefix. The national dial prefix is 0 in this example.
50 CONFIDENTIAL
This means that coming out of Number Validation we'll have a number that contains the area
code plus the subscriber number. This is the required format if the CFS needs to look for the
number in the subscriber database. It's also the most common format for signaling calls on
trunks. If a particular trunk needs a different format then the number modification is usually
done in Trunk Routing. We'll cover this later in Route a call off the CFS using Trunk Routing on
page 95.
After normalizing the number, the call then passes to Table 60000, "Outbound post-processing
portal".
Table 60000, "Outbound post-processing portal"

All calls from subscribers, regardless of type (except for SACs), finish in Table 60000. By default
this Table doesn't do anything, but it's there as a placeholder in case you need to add any
processing that applies to all outgoing calls. There's a similar Table, Table 70000, that applies
to all calls coming from trunks.
Having all calls go through a single Table means it's easy to add processing that applies to
all calls, rather than having to find and update different final Tables for different call types. In
addition, both of these post-processing Tables have very high indices. This is so that you can
add extra Tables and still keep these Tables at the bottom of the Number Validation Table, so
that it's easy to see the flow. This is an example of how we use our experience of dealing with
many systems to design a base configuration that is easy to maintain and extend.
Understand the International base configuration for calls from subscribers

If you follow several types of call through the International scheme, you may start to recognize
that almost all calls from subscribers follow this simple pattern.
1. Do any pre-processing that applies to all calls from subscribers.
2. Split the calls according to type.
3. Do processing based on the call type.
4. Do any post-processing that applies to all types of call.
These 4 stages apply, regardless of the country or dial plan. To make it easier to understand
how the Tables fit together, the Table indices in the International base scheme are designed so
that the different stages are in order in the Number Validation object tree. In other words, the
pre-processing stage is at the top, followed by stage 2, followed by stage 3 and then the post-
processing Table(s) are at the bottom.
What about calls from trunks?

So far we've focussed on calls from subscribers. What about calls arriving from trunks?
There's a lot of variation in how different switches need to handle incoming trunk calls, so there
isn't really a standard base configuration for these calls. The base configuration has a few
placeholder Tables but we expect to modify these significantly during the commissioning stage.
CONFIDENTIAL 51
Suggested Exercises
1. Follow some other types of call, such as an emergency call, through your Number Validation
Tables. Record which Tables and Entries are used to process the call. Are these calls
processed as you'd expect?
2. Follow a typical call arriving at your CFS from a trunk through Number Validation. Record
which Tables and Entries are used to process the call. Does this match how you expect
that call to be processed?
Checkpoint: You've now followed a simple call through Number Validation and you can describe
roughly how the International translations scheme works. Now you're ready to look at how call
classification works in more detail, by learning how to Record call properties using Attributes on
page 53.
52 CONFIDENTIAL
Record call properties using Attributes
Attributes are used on the CFS to represent different properties of a call and can have a
huge influence on how the CFS handles a particular call. They're set in various places as the
CFS learns about the call and then components such as Trunk Routing or Billing look at the
Attributes to decide how to process the call (rather than having to analyze the call again). In this
chapter you'll learn how Attributes are associated with a call and how you can use Attributes
to change how a call is processed.
Attributes are recorded for a call at 2 main points – when the call arrives and when the call
passes through Number Validation.
When the call first arrives, the CFS automatically adds Attributes for the call properties it can
deduce from the incoming signaling and where the call came from. For example, it may add
these Attributes:
• The incoming trunk (obviously only applies for calls from the network!)
• The nature of address parameter (if this was signalled)
• Useful information from the database record for the subscriber (and this only applies for
calls from subscribers!)
You can't control how these Attributes are added, but you can access them in Number
Validation.
Number Validation is the second place where Attributes are added. This is the area we're
going to be looking at in this guide. As the call passes through Number Validation, the CFS
adds more Attributes based on its analysis of the call. For example, the call type (emergency,
international, local etc.) is set by analyzing the called number. You can also edit some of the
original Attributes added to the call if required.
Note: One way to think of Attributes is that they are like sticky notes added to a call with one
note per property. The notes are written in pencil so you can edit them as you learn more
about the call. The notes are added when the call arrives and during Number Validation.
Call Services and other components can then read the sticky notes if they’re interested in a
particular property.
Other CFS components after Number Validation can then use the Attributes to decide how
to process the call, which is more efficient than every component re-analyzing the call. For
example, the Call Barring service will look at the call type and compare it with the subscriber’s
CONFIDENTIAL 53
configuration to decide if they’re allowed to make a particular call. Similarly, Trunk Routing
will use the Attributes to set the parameters, such as the nature of address, in the outgoing
signaling message.
The base configuration that we put on your CFS will ensure that the key Attributes are set
correctly by the time a call leaves Number Validation. If you edit Number Validation then make
sure you've set the Attributes correctly; otherwise, calls may behave oddly.
Get help with Attributes

There are a lot of Attributes. Don’t panic!
As with the Number Validation Tables and Entries, we provide a base configuration that adds
the appropriate Attributes with the necessary values for your deployment, so you don’t need to
set up this configuration yourself.
Did you know? In the Hitchhiker's Guide to the Galaxy, the Babel fish was a small fish
that you inserted into your ear where it would perform instant translations. The hero of the
book discovers it early on, thereby allowing him to communicate seamlessly with aliens for
the rest of the story. It's also the name of two different online translation services started
in 1995 and 1997. The history of these Babel Fish applications (according to Wikipedia) is
even more complicated than the plot of the Hitchhiker's Guide.
Very few people know what all of the Attributes do and some of the Attributes are only used
in a few deployments, so you may never come across them. If you want to know what an
Attribute does, the Help panel in MetaView Explorer should explain how the Attribute is used.
If an Attribute can be added in Number Validation then the most informative help is usually for
the Attribute value field on the Attribute object. The contents of the Help panel are also in the
MetaView Explorer Object Reference manual, which can be handy if you're not logged in to
MetaView Explorer.
Note: If you don’t understand the help or it doesn’t give you enough information, please let us
know! If you find the help unhelpful then we need to fix it before other people hit the same
problem.
Checkpoint: You now know what Attributes do and when they're set during a call. You also
know that you don't need to memorize what all of the Attributes do. Now let's see how
Attributes are actually applied and edited in Number Validation.
Use Attributes in Number Validation

Attributes are used in 2 ways in Number Validation – matching and adding (including editing).
We’ve actually already covered matching on Attributes in the previous chapter (Modify, classify
and block calls in Number Validation on page 28) although we called it matching on call properties
or parameters rather than explicitly talking about Attributes.
54 CONFIDENTIAL
To recap: to match on a particular Attribute value simply set the Match Attribute field(s) on the
Table to the appropriate Attribute type and then set the appropriate Attribute value field(s) on
the Entry. The screenshot below shows an example.
So, we now need to look at how to apply Attributes. Since you often need to apply more
than one Attribute at a time, Attributes are applied in Attribute Sets, which are just groups of
Attributes. You can find these under Number Validation.
If you want, you can apply an additional group of Attributes at the start of Number Validation
by default. These are defined on the Config Set object using the Attribute Set – call from
subscriber and Attribute Set – call from trunk fields for the different incoming types of call.
These Attributes are applied before the call enters the first Number Validation Table, so it's a
handy way to add any Attributes that you want to apply to all calls.
CONFIDENTIAL 55
Once you’ve entered the main body of Number Validation, Attributes are applied using the
Routing Attribute Set field on an Entry. Note that it’s not mandatory to apply an Attribute Set
in each Entry.
In the previous chapter I mentioned that some of the Next action field values result in an
announcement being played to the caller. You can choose which announcement is played by
applying Attributes. The Announcement ID attribute lets you choose from a range of pre-
configured announcements, such as Bad area code, while the Customer Announcement
ID lets you select a custom announcement that you've uploaded previously to the UMG. If you
use announcement Attributes, make sure to read the Announcement Parameters section
at the bottom of the MetaView Explorer help for Attribute Entries - this contains important
information about how to define the extra parameters required for some announcements.
If lots of Entries in the same Table will apply the same Attribute Set, then you may find it
simpler to configure the Default Routing Attribute Set on the Table and then set the Routing
Attribute Set field on the Entries to Default. This makes it slightly easier if you often add new
Entries to a Table (for example, it may list the prefixes in a local calling area) because you just
need to leave the Routing Attribute Set field as Default (which is the default value) rather than
having to set the field to the appropriate Attribute Set.
The downside of this approach is that you cannot set the Routing Attribute Set field to None.
So, if you want the majority of Entries to use the Default Routing Attribute Set and some
56 CONFIDENTIAL
Entries to use no Attributes, you will need to create an empty Attribute Set for those Entries to
use.
Edit existing Attribute values

As well as applying new Attributes, it’s also possible to edit many Attributes even after they’ve
been added. This is done by simply applying the same Attribute again, but with a different
value. The new value will overwrite the original value. For example, you can set the Maximum
call duration to 40 minutes in one Table and then later on add the Maximum call duration
Attribute again, but this time with the value set to 90 minutes.
Make sure the mandatory Attributes are set

A few of the Attributes are mandatory, meaning that they must be set before a call exits Number
Validation because they are required for other components to process the call successfully.
For example, the call type (either US Call type or UK Call type as appropriate) must be set
somewhere in Number Validation. We'll look at some of the key Attributes in the next section.
If a mandatory Attribute is not set in Number Validation then the call will be blocked at the end
of Number Validation, with a log explaining which Attribute is missing. The base configurations
that we provide will ensure that these Attributes are set, so you should only hit this problem if
you make significant changes to your translations (and make a mistake!)
Understand two Key Attributes - scope and type

Here we'll take a closer look at 2 key Attributes – Called address scope, Call type (US call
type in a NANP deployment and UK call type elsewhere). The scope and type are important
because these concepts are used in multiple places, not just in Number Validation.
CONFIDENTIAL 57
Called address scope
The scope of an address is the area over which the number is unique. As an example, consider
our UK office number….
Our full number is 442083661177, where 44 is the UK country code. This is an international
scope number, because it uniquely identifies a particular party across the entire world.
If you’re in the UK, then I’d give our office number as 2083661177, where 20 is the area code
for London. This number has a national scope because the number is unique in the country.
However, if you tried dialing the digits from a different country then you’d be connected to a
completely different party (or it may be an unallocated number, etc.).
Note: Actually, I’d usually give our office number as “02083661177” with an area code of “020”.
Technically, the 0 is the national prefix (also known as the trunk prefix or long-distance code),
which you dial when you want to make a long-distance call rather than part of the area code,
but the custom in the UK is to say the “0” as part of your number. For comparison, in the
USA you need to dial 1 for a long distance (intra or inter LATA) call, but you don’t normally
include the “1” when giving someone your number.
Note: Depending on your requirements, subscribers on your CFS may be configured with or
without the national prefix. This is something we'll discuss with you when commissioning your
CFS.
If you are in the local London area, then the number is 83661177. This has a subscriber-level
scope because those digits only identify the subscriber uniquely if you’re in the local area. If
you try dialing those digits from a phone in a different town then again you’ll be connected to a
completely different party. Call service access codes are another example of subscriber scope
numbers. Dialing *72 may enable call forwarding for a certain subscriber on a certain CFS but
may have no effect when dialed from another subscriber or from another CFS.
The Called address scope must be set before the call leaves Number Validation for calls
made by subscribers. It’s equivalent to the ISUP “Nature of Address Indicator” (noa) parameter,
so if a call arrives on an ISUP trunk then this Attribute is automatically set when the call arrives.
Similarly, if a call is signaled out over an ISUP trunk then the Called address scope Attribute
set in Number Validation is used to determine the value of the Nature of Address parameter.
Finally, note that the scope must be set to National at the end of Number Validation if you
want to route a call to a subscriber. This is because subscribers are stored in the CFS database
indexed by their national scope phone number (i.e. the area code plus the local number). If you
complete Number Validation with any other scope then the CFS won’t be able to find the called
number in its database.
58 CONFIDENTIAL
UK call type (US call type in NANP deployments)
Despite the name, the UK Call Type Attribute applies to all international CFSs, not just those in
the UK. This Attribute is used to record the type of call, for example Local, Mobile or Operator.
This Attribute is used by Billing and ETSI-style Call Barring, so they don’t need to re-analyze
the called number. There’s a very similar Attribute – US Call Type – which is used for Telcordia-
style deployments.
Note: Why is this Attribute called the UK Call Type? It was originally developed for use on a
UK system running ETSI services. The Attribute is now used for all ETSI systems but, for
backwards compatibility, the name has not been changed.
Your system may produce different types of billing records (e.g. call types and structure codes if
you use BAF billing files) based on the Call Type. Therefore this Attribute must be set to a value
other than Unknown before the call leaves Number Validation.
Be careful not to confuse this Attribute with two similar-looking values for the Attribute type field:
Called address type and Billing - call type! The Called address type Attribute indicates
the format of the destination digits and can be either Dialed digits or E.164. The Billing - call
type Attribute only applies if you use BAF format billing records. These billing records contain
a numerical field which is the call type; for example, "5" indicates a local call. The Billing - call
type Attribute lets you override the default call type code in the billing record for a call.
Suggested Exercises
1. Get a pad of sticky notes and a piece of paper. Follow a call from a subscriber through
Number Validation and record the Tables and Entries on the paper. Each time an Attribute
is set, write the details on a sticky note and stick them to the paper. At the end of Number
Validation, check what all of the Attributes are, particularly the Call Type and the Called
address scope.
2. Use the MetaView Explorer help (or read the MetaView Object Reference manual) to find
out what each of the Attributes applied during the call does.
Checkpoint: You can now explain what Attributes are and how they're set and used. You also
know how to get more information on any particular Attribute, which will be very helpful as you
do more advanced things in translations. You're now ready to learn how to Extend the built-in
Attributes using Line Class Codes and User Defined Attributes on page 60.
CONFIDENTIAL 59
Extend the built-in Attributes using Line Class Codes and User Defined Attributes
Extend the built-in Attributes using Line Class Codes and

User Defined Attributes
Line Class Codes (LCCs) and User Defined Attributes (UDAs) let you expand the standard
set of Attributes. They are extremely useful and very common, but they are optional. So, if
you're starting to feel overwhelmed by new information, I suggest skipping this chapter for now
and coming back later. Otherwise, get ready to learn how you can define your own Attributes!
So far you've learned that the CFS has a large number of built-in Attributes, which control
the CFS behaviour for a given call. The base configuration ensures that the Attributes are set
correctly. But what if you want to do something in translations that isn't covered by a standard
Attribute? That's where LCCs and UDAs come in.
Let’s first consider two sample scenarios where you might want to go beyond the standard
Attributes.
• New call service – Limited duration international calls.
• You want to offer a service whereby subscribers will be limited to 30 minutes duration
for international calls. Limiting the call duration is done by applying the Maximum call
duration Attribute in Number Validation so that bit is easy, but how can you identify
which subscribers have signed up for the service? You could list all of the relevant
subscribers by phone number in a Number Validation Table, but subscriber provisioning
staff may not have access to translations configuration. How can you record this
configuration on a subscriber object that they can access?
• Storing variables – passing trunk information from Number Validation to Routing.
• Your particular configuration means that it’s easy to work out in Number Validation
which particular trunk to use for a call. How can you transfer this information to Trunk
Routing? There’s no “route to this trunk” Attribute and it doesn’t make sense to duplicate
the analysis in Trunk Routing. If you come from a programming background then you
may be thinking - how can I set up a local variable to record the trunk?
These types of problems are addressed by using Line Class Codes and User Defined Attributes.
There are some similarities between LCCs and UDAs. They're both numerical fields and you
decide what the specific numerical values mean. You can define up to 20 LCCs and 20 UDAs,
directly under the Trunk Routing and Policy Services.
The key difference between LCCs and UDAs is that LCCs can be set on the subscriber objects
themselves (in addition to Number Validation), while UDAs are can only be set in Number
Validation. They're both then used during Number Validation and Trunk Routing. The rest of this
chapter looks at LCCs and UDAs in more detail.
60 CONFIDENTIAL
Line Class Codes (LCCs)
LCCs are used to define extra properties for a subscriber, beyond those defined by the standard
fields. In the first scenario above, you may decide that LCC2 represents the “Limited duration
international calls” call service subscription. LCCs (and UDAs) are numerical fields, so you
could use LCC2 = 0 to mean the subscriber does not have the service while LCC2 = 1 means
the subscriber does have the service.
In the screenshot above you can see that values can be Validated or Non-validated. If it is
possible to provide a complete list of all possible values, then we recommend using Validated
LCC values, so that people can't accidentally set an LCC to an invalid value. It's also a very
good idea to include a text description for each value, so that it's easy to see which value
you need to use for a particular subscriber. While we're on the subject of making provisioning
easy, you can also use MetaView Web Templates to set LCCs, which is another way to reduce
configuration errors!
Once the LCCs have been defined, you can then match on LCC2 Attribute using the Match
Attribute fields on the Table (we covered these in Modify, classify and block calls in Number
Validation on page 28) to decide whether or not to apply the Maximum call duration Attribute.
An example of this is shown below. Note that the Match Attribute field drop-down only
includes the LCCs that you have defined and it includes the Display name to make it easy to
find the correct LCC.
CONFIDENTIAL 61
Note that LCCs can be used for both on-switch subscribers and long-distance subscribers.
We'll cover long-distance subscribers later in Get started with long distance call services and the
associated terminology on page 124.
User Defined Attributes

UDAs are used to store information about extra call properties during Number Validation and
Routing. In the second scenario above you may decide that UDA10 represents the “which
outgoing trunk to use” property. The numerical value of UDA10 then shows which trunk to use,
e.g. UDA10 = 1 means route on Trunk 1, while UDA10 = 45 means route on Trunk 45. As with
UDAs, you can define a display name for the UDA so it's easy to see what UDA10 represents,
but unfortunately you can't currently restrict the permitted values or give them names, so you
may want to keep a separate record of the definitions.
In Number Validation, once you’ve worked out which trunk to use, apply the UDA10 Attribute
with the appropriate value. Note that only the UDAs that you have defined will appear in the
Attribute type drop-down list, and the Display name is included to make it easy to find the
correct UDA.
In Trunk Routing you can then match on UDA10 and route to the trunk based on the value,
without needing to re-analyze the number. We’ll cover Trunk Routing later, so for the moment
just remember that you can use UDAs to record and transfer information about a call that’s not
covered by the standard Attributes.
If you plan ahead the Attribute Set index can reflect value of the UDA. For example, UDA1
= 104 could be set in Attribute Set 1104. This isn't necessary but makes it easier to use
the search selection button to select the Attribute Set if you've got lots of Attribute Sets.
(We covered search selection buttons earlier in Use search selection fields to set values easily in
translations on page 41.)
Note: In addition to UDAs, there are also User Defined String Attributes or UDSAs. These work
exactly the same as UDAs but can store much longer values: UDA values can be numbers up
to 9 digits long, whereas UDSAs can store strings up to 255 characters long comprising of
numbers, the letters A-F, * and # (that is, the characters you see in a dialing string).
62 CONFIDENTIAL
Suggested Exercises
You need to be very careful when playing with Line Class Codes because, unlike Config Sets,
there's only one set of LCCs on the CFS. For example, if you add a new LCC, it will immediately
appear in the list of LCCs in MetaView Web, which may confuse anyone doing provisioning.
Also, if you add a new validated LCC, any subscriber that doesn't have that LCC set to a
permitted value will immediately alarm, which could cause confusion! I therefore suggest you
only try these exercises on a lab system.
1. Add a new validated Line Class Code with a list of permitted values with good names. Make
sure that one of the permitted values is 0. This is the default value for a Line Class Code
on a subscriber so including it in the list of permitted values will ensure that subscribers will
not alarm.
2. Edit a subscriber in MetaView Web or MetaView Explorer and check that there is now
a field for the new Line Class Code. Check that you can only set the field to one of the
permitted values.
3. (Advanced exercise) Create a Number Validation Table that matches on this new Line
Class Code. Create Entries to match on all of the permitted values and Complete Number
Validation. Make all calls from subscribers go through this Table at the end of Number
Validation.
4. Add a new User Defined Attribute.
5. Create an Attribute Set that applies the new UDA.
6. (Advanced exercise) Update your new Number Validation Table to apply the new Attribute
Set to all calls.
Checkpoint: You now know what Line Class Codes and User Defined Attributes are, why you
might use them and how to use them. Now that you've covered Attributes fully, we're going
to go back to Number Validation to consider overlap signaling, which we previously ignored.
CONFIDENTIAL 63
Get ready to discuss overlap signaling

Overlap signaling is where the destination address may arrive in multiple signaling messages.
The alternative is enbloc signaling, where all of the destination address arrives in a single
message. If your CFS needs to handle overlap signaling then Metaswitch Support will discuss
this with you and implement appropriate configuration during the commissioning phase. In this
chapter you'll learn the key configuration that's required for overlap signaling so that you're
prepared for any discussions.
Handling enbloc messages is simpler, so why do networks use overlap signaling? Consider the
case of a call to an international destination. Different countries have different dial plans, so the
originating switch probably doesn't know how many digits to collect to make a valid number.
One option in this situation is to start setting up the call once the originating switch has enough
digits to identify the destination country. Any further digits are sent in extra signaling messages.
Once the destination switch has sufficient digits, it can send a message back to indicate that
it has enough digits. In ISUP, for example, the initial message is the Initial Address Message
(IAM) and additional digits are then sent in Subsequent Address Messages (SAMs).
As you can see, an originating or transit switch in this scenario will need to route the call before
it has the full set of digits. This is possible because, generally, they only need to look at the
prefix, such as the area code or country code, to decide how to route the call.
So, now you know why the CFS might need to support overlap signaling, let's look at the
required configuration.
Configuration related to overlap signaling

In this section we'll look at the three bits of configuration that you may need to use if your CFS
handles overlap signaling. In the following section we'll then put all the bits together to see how
Number Validation processes a call with overlap signaling.
Enable support for inbound overlap signaling using SIP-I

If you're going to receive overlap signaling over ISUP, you don't need to do anything to enable
support for it.
However, when you want to receive overlap signaling using SIP-I, you need to go to the SIP
object under Signaling and set the option Allow inbound overlap signaling with SIP-I.
As well as turning support for inbound SIP-I overlap signaling on and off, you can configure the
amount of time the CFS will wait after each INVITE before considering the address complete
using the Inter-digit timeout option.
64 CONFIDENTIAL
Permit routing for incomplete numbers
If the CFS will be sending overlap messages to a remote switch (known as overlap to overlap
signaling), you need to make sure that your Config Set will let calls with incomplete destination
numbers complete Number Validation. This is controlled by the Routing on incomplete call
number allowed option on the Config Set. If this option is not set, then the CFS can still
receive overlap signaling messages but a call cannot enter Trunk Routing until the number is
complete.
Use the Called Address Complete Attribute appropriately

You may need to set the Called address complete Attribute at some point during Number
Validation. The presence of this Attribute tells the CFS that the destination address is complete
and that it won't receive any more digits. Until this Attribute is set the CFS will listen for more
incoming digits, even after the call has entered Number Validation.
If your CFS only needs to handle enbloc signaling, the Called address complete Attribute
should be set early in the Number Validation configuration for all calls. If your CFS needs to
handle overlap signaling then don't set this Attribute until all of the destination digits have been
received.
The Called address complete Attribute does not have to be set before a call leaves Number
Validation. This is because you may want a call to complete Number Validation and go through
Trunk Routing before all of the digits have arrived. However, the Called address complete
Attribute must be set if you want to do an on-switch lookup.
Use the correct Number Validation Table types

Finally, the permitted Search type values for a Number Validation Table are different. Until the
destination number is complete (which means the Called address complete Attribute has been
applied), then you cannot use Complete match Tables. Almost all Number Validation Tables
in an overlap scenario are Prefix match Tables, since they look at the start of the number to
decide how to process the call.
It's extremely rare, but you can also use Unique match Tables if you have an incomplete
number. This type of Table effectively combines a prefix match with a limit on the number
length. The length of the Number field defines the maximum length of the number, while the
Minimum match length field defines the minimum permitted match.
To see this in action, consider the following Entry
CONFIDENTIAL 65
This Entry will match the following destination numbers.

• 123 - 3 digits is the shortest number, as defined by the Minimum match length field.
• 1234.
• 12345 - the maximum length, as defined by the Number field.
Destination numbers longer than 5 digits will be rejected because they're longer than the
Number field. In the next section you'll see how the CFS handles destination numbers that are
too short to match any Entry.
Understand how an incoming overlap signaling call is processed

Bearing all the configuration described above in mind, how does the CFS process an incoming
call with overlap signaling?
The basic principle of Number Validation is the same as for enbloc signaling - the CFS looks
for a best match Entry in each Number Validation Table. However, with overlap signaling, the
CFS may have to wait in a Table for more digits to arrive before it can identify the best match.
For example, consider a Prefix match Table with these Entries.
If the destination number is currently "12" and the Called address complete Attribute has not
been set (so the CFS knows that more digits may arrive) then all of these Entries are possible
matches. The CFS will therefore wait until more digits arrive.
If the next digit is 3, making the destination "123", then Entry A is the best match. If the next
digit is anything else then Entry B is the best match. If no more digits arrive then Entry C is the
best match. Once the CFS has identified the best match Entry then the CFS will process that
Entry just as it did for enbloc signaling.
When the call reaches the end of Number Validation, the CFS will look at the Called address
complete Attribute. If this Attribute has not been set then the CFS will check that the Config
Set is configured to permit routing with an incomplete number. If so, the call will skip over On-
Switch Lookups and go to Trunk Routing. If the Config Set is not configured to support routing
incomplete numbers then the call will be rejected.
The call will then pass through Trunk Routing and be routed to a trunk. Any additional signaling
messages (such as SAMs for ISUP) will be passed through directly to the destination, without
going through translations.
If the CFS is transiting overlap to overlap calls, the configuration is generally fairly simple. The
CFS just needs to collect enough digits to identify calls by their prefix (for example, the area
code or the country code) and then the CFS will route based on that prefix.
However, sometimes the CFS may need to handle overlap to enbloc calls. For example, the
CFS will need to convert a call to enbloc signaling if:
• The outgoing trunk uses a protocol that does not support overlap signaling (e.g. plain SIP).
• The call might terminate to a subscriber on the CFS. The CFS will only look for the called
number in the subscriber database if the Called address complete Attribute is set.
In this scenario the CFS needs to collect all of the digits before setting the Called address
complete Attribute and then finishing Number Validation.
66 CONFIDENTIAL
This is often done by configuring Number Validation Prefix match Tables which have Entries that
match on the possible lengths of call number, based on the numerical prefix. For example, a
national number that starts 0208 in the UK will have 7 additional digits, so can be represented
by an Entry with the Number field set to 0208XXXXXXX. The CFS will continue to gather digits
until the number matches one of the Entries, which means we must have gathered all of the
digits. At this point the Called address complete Attribute is added and the call can complete
Number Validation.
Checkpoint: You now know the configuration options involved with supporting overlap
signaling, so you can discuss with Metaswitch Support how overlap signaling should be
implemented for your specific deployment. Now let's move back from theoretical discussions
to real configuration and look at file based Number Validation Tables.
CONFIDENTIAL 67
Use file-based Number Validation Tables

This is an optional feature so feel free to skip this chapter if you want to focus on the key
translations concepts first. However, at this point in a training course I find that some students
are worried that editing Number Validation using the object tree directly won't work well for their
deployment, for the reasons outlined below. If that sounds familiar, then you should read this
chapter carefully!
If you have very large Number Validation Tables (e.g. 1000s of Entries) or you need to update
Number Validation Tables frequently or you want to have several people editing the configuration
at the same time, making all of your updates directly in the MetaView Explorer object tree can
be difficult. In these cases you should consider using file-based Number Validation Tables.
Let's start by introducing file-based Tables and considering the advantages and disadvantages.
Did you know? The most famous Table Mountain overlooks Cape Town in South Africa
but it's actually a common name for flat-topped mountains around the world. These include
Crug Hywel in the UK (that's Welsh for Table Mountain), the Stolowe (Polish for Table)
Mountains in Poland and not one but four different Table Mountains in California.
So, how are file-based Number Validation Tables different from the Number Validation Tables
we’ve looked at so far? With a file-based Number Validation Table, there is still an object in
the tree representing a Number Validation Table, but the child Entries are defined in a text file
stored on the CFS, rather than as objects in the MVE tree. The Number Validation text file is in
a CSV format, with each row representing an Entry. The content of the Table can be updated at
any time by uploading a new version of the text file. (We'll look at creating and updating these
Tables in more detail later in this chapter).
There are several advantages to using file-based Number Validation Tables, as listed below. For
some customers these advantages mean that they definitely need to use file-based Number
Validation Tables.
• Better support for large Tables. Tables with hundreds of Entries can be difficult to work with
in the object tree while File-based Number Validation Tables can contain up to 500k Entries.
68 CONFIDENTIAL
For example, you may need very large Tables if you need to include national lists of ported
subscribers in Number Validation.
• Updates without changing to another Config Set. The live Config Set is not editable in the
object tree, so if you want to make changes via the object tree then you have to copy it, edit
it and then swap to the new Config Set. To update a file-based Number Validation Table
simply upload the new text file - there’s no need to swap to another Config Set.
• Better support for multiple users. If multiple people want to make translations changes
via the object tree at the same time then you need to have processes in place to ensure
that one person creates a new Config Set then everyone makes their changes to the
new Config Set and then one person makes the new Config Set live once all changes are
complete. With file-based Number Validation Tables everyone can upload new Table files
to the live Config Set, so you just need to make sure that only 1 person is trying to edit any
particular Table at a particular time.
However, there are also some disadvantages that you should be aware of before deciding to
use file-based Number Validation Tables.
• You can’t view the Entries in the object tree, which can make it harder to follow and
troubleshoot the processing.
• Not all Number Validation features are supported in file-based Number Validation Tables;
the features are limited to the ones most demanded by customers. Firstly, Entries can only
match on a number; you cannot match on other Attributes. Secondly, Entries can only do 1
of 3 different things (as of V8.2) – add UDAs, change the number or set a Location Routing
Number (LRN).
• All Entries have to have the same Next Action. However, you can often work around this by
setting a UDA in the file-based Table and then using the UDA in a later Table to do different
things to different calls.
Note: There's also a different type of file-based Number Validation Table called a File-based
Attribute Matching Table, which lets you efficiently assign routing policy for use during Trunk
Routing. These tables are pretty advanced so we're not going to cover them here, but if you
want to more check out Number validation: file-based attribute matching (for flexible routing
policy) in the MetaSphere CFS Management Guide.
Checkpoint: You can now choose when to use file-based Number Validation Tables for a given
deployment. Now let's see how to use them.
Create a new file-based Number Validation Table

Assuming that you've decided that you need to use file-based Number Validation Tables, the
first step is creating a file-based Number Validation Table. The process for that is relatively
simple.
1. Create a text file, myfile.txt, with the appropriate format.
2. SFTP the file to the CFS as a craft user.
3. Create a Number Validation Table that uses the file.
The file is uploaded automatically when the Config Set is activated and the text file is
replaced automatically with a new results file.
4. Check the new results file.
The rest of this section has more information on these steps. Once you've created the Table,
it's very simple to update it; we'll cover that in the next section.
CONFIDENTIAL 69
Step 1 - Create a text file

As of V8.2, there are 3 supported types of file-based Number Validation Table.
• Set the User Defined Attributes (UDAs).
• Change the called (a.k.a. destination) number based on a weighting.
• Add a Location Routing Number (LRN). This is typically only used in NANP.
The exact format of the CSV file depends on the type of Table; for the full details see the
Number Validation: file-based section in the MetaSphere CFS Management Guide. Here we’ll
look at an example of a Table to set some UDAs. This is the most common type of file-based
Number Validation Table, but it also illustrates the key points that apply to all file-based Number
Validation Table files. Here's a very short sample file.
;NVFILE 3.0
DN,UDA5,UDA6,UDA7,UDA12,UDA15
2012031,1,4,7,6,3
201203[2347],3,7,5,12,2
;Catch all 202 numbers
202,43,1,7,2,1
202134,,,,1,2
;NVFILE END
Let's go through the lines individually and see what they do. The first line must always look
like ;NVFILE 3.0. The 3.0 gives the version of the file-based function. There have been 3
releases of the file-based Number Validation Table function. Each release added a new table
type but may also have slightly different requirements on the file format. Setting the version
number tells the CFS which exact file formats it should look for. The versions are backwards
compatible so once you’ve got your Tables and files working, you don’t need to change the
version number or format when you upgrade your CFS.
The next line, DN,UDA5,UDA6,UDA7,UDA12,UDA15, defines a template for the remaining
lines. In this example it defines which UDAs to set.
After these first two lines, the remaining lines define the actual Entries. Each line starts with a
number prefix match. The last digit can use the []notation to match multiple possible values,
which can help to reduce the number of Entries that you require. The other numbers on each
line define the UDA values to set if the call matches that Entry. For example, if the call matches
2012031, then UDA5 will be set to 1.
The fifth line in this example, ;Catch all 202 numbers, is a comment line. Any line starting
with ";" is a comment and will be ignored, except for the first and last lines which are special.
Blank lines will also be ignored.
The final two Entries in this Table show that you can have overlapping Entries; the CFS will
simply choose the more specific match for the particular call. You can also have an Entry with a
blank prefix. This will match all calls that don't have another, more specific, match in the Table.
The final Entry also shows that you can have Entries that don't set all of the UDAs.
Finally the end line must always be ;NVFILE END.
70 CONFIDENTIAL
Step 2 - Upload the file using SFTP
The Uploading number validation files section in the MetaSphere CFS Management Guide
gives more information on how to upload the file. The key things to note are that:
• the files go directly to the CFS, not the MVS (which is where you need to upload MVE
import files)
• the files go into the ftp/nvfiles subdirectory.
Step 3 - Create a Number Validation Table that uses the file

To create a file-based Number Validation Table, start by creating an Number Validation Table as
normal, but change the Table type field from Normal (the default) to File-based. The other fields
on the Entry will then change to reflect the new type.
When you activate the parent Config Set, the file will now be loaded up into memory and the
fields highlighted above will change to show you what happened. The File header line and the
Number of entries loaded should match the contents of your file. If the upload failed, click on
the button next to the File status log correlator field to see the error. (The button is greyed
out in this screenshot because the upload was successful.)
Step 4 - Look at the results file

When the file has been fully read into memory, the original text file will be replaced by a results
file. For example, if the original file was myfile.txt and the import was successful then the
new file will be myfile@ok. If the import failed then the new file will be myfile@fail and the
file will contain more information about the problem.
Update a file-based Number Validation Table

To update a file-based Number Validation Table, simply upload a new version of the text file to
the CFS. The CFS will then read the file into memory and start using it. However, you need to
note the following points.
• For files with a very large number of Entries (near the maximum of 500 000), it may take
several minutes to process the file and the call processing capacity of the CFS may be
slightly reduced. Therefore you should avoid uploading big files during your peak periods.
CONFIDENTIAL 71
• While the CFS is processing the new file, the Number Validation Table will contain a mix of
Entries from the old file and the new file, so calls may be processed by old or new Entries.
Once the file is fully processed, all old Entries will be removed.
Suggested Exercises
1. Read through the lists of advantages and disadvantages and decide if you might use file-
based Number Validation Tables on your CFS.
If you think you might use file-based Number Validation Tables then try the following.
2. Find the section in the manuals that describes the format for file-based Number Validation
Tables.
3. Choose a type of file-based Number Validation Table that might be useful for your system.
4. Create a short file-based Number Validation input file of that type with a few Entries.
5. Upload the file to the CFS.
6. Create a file-based Number Validation Table in your Config Set that uses the input file and
check that the file is loaded into memory correctly.
Checkpoint: You now have enough knowledge to choose when to use file-based Number
Validation Tables and you know how to create and maintain them. You may also be getting very
bored with Number Validation! If so, you'll be pleased to know that we're now leaving Number
Validation and moving on to On Switch Lookups.
72 CONFIDENTIAL
Look for the called number on the CFS in On-Switch Lookups
Look for the called number on the CFS in On-Switch
Lookups
Once a call has passed through the Number Validation Tables, the destination number will be
in the right format for looking for the number in the CFS subscriber database. Here you'll learn
about the On-Switch Lookups (On-Switch and LNP Lookups on a NANP system) configuration
that controls the lookup behaviour. If you have a pure Class 4 deployment with no subscribers
configured on the CFS then you may want to skip this chapter.
Before we look at the configuration in MetaView Explorer, one key thing to understand is that
lookups are actually a two-stage process. Firstly, after passing through the Number Validation
Tables, Number Validation looks at the On-Switch Lookups configuration section to see if the
called number might be on the switch and sets appropriate flags.
Secondly, after the call has passed through Number Validation completely, it is passed to the
Lookup (also known as On switch routing or Local routing) component which looks at the flags
set by Number Validation and, if required, looks for the number in the subscriber database.
This separation is a fairly subtle distinction and often we talk about On-Switch Lookups as if it’s
a single step, so why should you care that it’s actually done in 2 stages? It's mostly because
you'll see the two stages in the SAS trace (we'll look at SAS traces later in Get diagnostics for a
call using the Service Assurance Server on page 90).
Note: Remember from Record call properties using Attributes on page 53 that the CFS will only bother
looking for a number on the switch if the Called address scope is set to National and the
Called address complete Attribute has been applied. Both of these will automatically be set
correctly in the base configuration so most of the time you can ignore this reminder!
Now let’s dive in and look at the configuration. It’s under the On-Switch Lookups (or On-Switch
and LNP Lookups) section of a Config Set.
Compared with Number Validation, you’ll be pleased to hear that the configuration here is
much, much simpler! The On-Switch lookups configuration defines 2 things.
1. Which called numbers to look for in the CFS subscriber database.
2. What to do if we look but don’t find the called number in the database.
On-Switch lookups therefore consist of a list of prefixes, called Lookup Number Blocks. If the
called number matches one of the prefixes, then the CFS should look for the number in the
database. If the called number doesn’t match one of the prefixes, then the CFS won’t look in
the database, thereby avoiding unnecessary lookups. As you may be able to tell, for a pure
Class 4 switch (where there are no on-switch subscribers), the On-Switch Lookups section will
be empty.
CONFIDENTIAL 73
So, the presence of a Lookup Number Block tells the CFS to look for the called number in the
subscriber database. The Number block type of the Lookup Number Block then tells the
CFS what to do if it didn’t find a matching subscriber record. For example, you may want the
CFS to reject the call, or you may want to route the call to an outgoing trunk.
Now let's look at the Lookup Number Block types in more detail. The values that you will need
to use will depend on whether porting is supported and how it's implemented in your network.
However, let’s start by considering the simplest situation, where there’s no subscriber porting.
In this situation each switch owner is given a block of numbers that they can assign to
subscribers on that switch. If someone calls a number in the switch’s block and the CFS can’t
find a matching subscriber record, then we know the number is unassigned or unallocated – it
won’t be on any other switch. Therefore the CFS should reject the call. To get this behaviour,
set the Number block type field to Owned.
Once you introduce porting, you will probably need to use some of the other Number Block
types. Most of the Number block types are only used in NANP deployments where they use
Local Number Portability (LNP) lookups to find the current home switch for a called number.
This version of the guide doesn't cover NANP deployments so we'll ignore those values. That
means we only need to consider the simplest way to implement porting in Lookup Number
Blocks, which is the Sparsely owned option.
Note: We'll look at ways to implement number portability in more detail later on, in Get ready to
discuss Number Portability on page 121.
If the Number block type is set to Sparsely owned then it tells the CFS that it doesn't
uniquely own all of the phone numbers in that block. If the CFS can’t find a matching subscriber
record then, rather than failing, the call will automatically move into Trunk Routing and be
routed down an outgoing trunk. You will need to ensure that your Trunk Routing is configured
to send it to the appropriate place.
Note: We’ll look at Trunk Routing configuration later in Route a call off the CFS using Trunk Routing on
page 95.
The Sparsely owned type is also useful if you’ve split a number block between the CFS and
another switch, for example, as part of migrating subscribers from a legacy switch to the CFS.
In this case, set the appropriate Lookup Number Block to Sparsely owned. The CFS will look
for the called number on the CFS first, but if it doesn’t find it, it will route the call to the legacy
switch. If the legacy switch also doesn't find the called number then it should fail the call.
74 CONFIDENTIAL
Avoid confusion! Lookup Number Blocks are not Number Ranges
Before we finish On-Switch Lookups, I want to take a quick look at something that can cause
confusion. Lookup Number Block objects in translations and Number Range objects under
Subscribers have similar names and they both define a block of numbers that might contain
subscribers – what’s the difference?
Number Blocks in translations tell the CFS which called numbers it should look for in the
subscriber database and, if it doesn’t find them, what to do next (reject call, reroute to trunk,
do an LNP query etc.). If you configure a subscriber in a new number range and you don’t add
a corresponding Number Block then the subscriber will be able to make calls, but the CFS will
never route calls to the subscriber.
Number Ranges under Subscribers are there to let the CFS do number space management.
You should configure Number Ranges for all blocks of numbers that you own (i.e. where you
can choose how to assign the numbers to your subscribers). When you add a new subscriber,
the CFS will check that the subscriber’s directory number is within one of the defined Number
Ranges. If it isn’t then the CFS will reject the configuration on the assumption that you have
mistyped the number!
The exception to this rule is if you set the Number status field on the subscriber to Ported
to. This tells the CFS that you do not own the subscriber's phone number so the CFS will not
check that the phone number is in a Number Range.
The CFS also uses the configured Number Ranges to suggest available numbers when you're
creating a subscriber. This can be particularly helpful when configuring Business Groups and
PBXs if you want to assign a block of numbers.
CONFIDENTIAL 75
So, if you start putting a new set of subscribers on your CFS in a new owned block of numbers
(e.g. you’ve just moved into a new area code), then you will need to add both Number Ranges
(to let you configure the subscriber objects) and Lookup Number Blocks (so that translations
knows to look for the new numbers in the database).
Suggested exercises
1. Find the On-Switch Lookups section on your CFS.
2. Look at the Lookup Number Blocks on your CFS and check that the Number block type
field is set as you expect for each block of numbers.
3. Check that you understand what will happen for each configured block if the CFS does not
find a subscriber that matches the called number for a call.
4. Find the Number Range configuration on your CFS. Check that there are Number Ranges
configured for each owned block of numbers, but not for any numbers ported to the CFS.
Checkpoint: You now know how to configure On Switch Lookups based on how your
deployment handles portability. That's all there is to the On Switch Lookups section, so now
you can move on to testing your translations configuration.
76 CONFIDENTIAL
Decide how to test your translations
Decide how to test your translations
If someone reports a problem that you think may be caused by translations, or if you have
made a change and you want to check that the change is correct before it goes live, you need
a way to test your configuration. In this chapter we'll look at the options for testing and in the
next chapters we'll look at these options in more detail.
Note: Why are we learning about testing translations now, when we haven't finished learning about
configuring them? Because you now know enough to start making changes to Number
Validation and that means you know enough to be dangerous! If you edit your translations
then you should always test the changes before you make them live. So, get into a good
habit and always remember to do testing!
One obvious way to test your translations is to make calls from a test line using the live Config
Set and then look at the trace output to check the call behaved as expected (we'll cover this
later in Get diagnostics for a call using the Service Assurance Server on page 90). However, this
approach has some definite disadvantages.
• You need access to phones that can trigger the right type of call. This may be especially
difficult for calls that arrive at the CFS from the network.
• It only tests the live Config Set. This is fine if someone reports a problem, but if you've made
a configuration change then it's much better to test your change before it goes live!
The CFS therefore supports 2 other ways to test your translations, which avoid these issues.
• Live testing using an Override Config Set. This lets you make real calls using a non-live
Config Set.
• Route Verification Tests (RVTs), which simulate and test a call going through translations.
You can use RVTs to create a test suite to check a Config Set before making the Config
Set live.
If you're new to CFS translations then making test calls using Overriding Config Sets is the
easiest way to start testing your configuration, so we're going to cover those first. However,
there are several situations where you have to use Route Verification Tests, so make sure you
don't skip the RVT chapter!
Checkpoint: You should now know what the options are for testing your translations. In the
next chapters you'll learn how to use Override Config Sets and then how to use RVTs.
CONFIDENTIAL 77
Do live testing using Override Config Sets

The Overriding Config Set feature lets you test updates to your CFS translations by making
real calls that go through a non-live Config Set. The rest of the CFS traffic will continue to flow
through the live Config Set; only specific test traffic will go through the Override Config Set.
Here you'll learn how to configure Override Config Sets for specific calls.
To use the Overriding Config Set feature you need to tell the CFS which Config Set to use
and when to use it. The exact configuration depends on whether you want to test calls from a
subscriber or from a trunk; full details are given below.
In both cases calls will only work if the Overriding Config Set is active. (we covered the different
Config Set stats in Manage your translations using Config Sets on page 11). If you're testing a
Config Set then it's very easy to forget to re-activate the Config Set after making an edit.
If your test call fails then I recommend checking the Config Set state first, before you start
troubleshooting your changes!
Finally, using Overriding Config Sets is very simple, so it can be tempting to use it inappropriately.
The Overriding Config Set feature is only intended for short-term use while testing changes
to translations. It's not intended for permanent use and you may find it does not behave as
expected in complex scenarios (typically those involving a call being passed between multiple
subscribers).
If you want calls from particular subscribers to go through different translations from other
subscribers then you need to have a single Config Set but with different paths based on an
appropriate property, typically the Subscriber Group or a Line Class Code configured on
the subscribers.
Note: We covered Line Class Codes earlier in Extend the built-in Attributes using Line Class Codes and
User Defined Attributes on page 60.
Configure live test calls from a subscriber

The Overriding Config Set field on a subscriber object in MetaView Explorer is near the end,
amongst the other diagnostic fields.
If you're working in MetaView Web then the Overriding Config Set field is on the Diagnostics
tab for the subscriber.
78 CONFIDENTIAL
Remember to set the Overriding Config Set back to None when you've finished. If you forget
to change it, you may be surprised in the future when calls from your test line don't behave as
you expect!
Finally, it's worth noting that live testing is the only way you can test the translations for calls
from a Business Group Line. We'll look at why when we cover RVTs later (in Do thorough testing
and build a test suite using Route Verification Tests on page 81).
Configure live test calls from a trunk

To set an Overriding Config Set for a call arriving on a trunk you first need to create a Call Trace
object that will match the incoming call. These Call Trace objects are under the appropriate
signaling section on the CFS.
For a test call that will arrive on an SS7 trunk, you need to create an ISUP Call API Trace object
under the ISUP Call Diagnostics section for the appropriate ISUP Local Signaling Destination.
Similarly, for a call that will arrive on a SIP trunk, create a SIP Call API Trace object under SIP Call
Diagnostics in the SIP signaling section. These objects are shown in the following screenshot.
CONFIDENTIAL 79
Once created, the Call Trace objects have the same fields, regardless of the signaling type,
as shown below. Set the Called number and / or Calling number fields to the appropriate
values to catch your test call(s) and then set the Overriding Config Set field to the Config Set
that you want to test.
Remember to set the Overriding Config Set field back to None (or just delete the Trace
object) when you've finished, so that all calls go through the live Config Set.
Suggested Exercises
1. Change a subscriber so that it uses your Config Set rather than the live Config Set. If you
don't have a suitable subscriber, set up a Call Trace for an incoming call on a trunk.
2. Make a call from the subscriber or trunk. Check that the call works.
3. Deactivate your Config Set and make the call again. Check that the call now fails. (Later
in Get diagnostics for a call using the Service Assurance Server on page 90 we'll see how you
can use SAS to check which Config Set is used for a call, which is a better method than
intentionally breaking the Config Set!)
4. (Advanced exercise) Update your Config Set to play an announcement for calls from your
test subscriber and check that you hear the announcement. (Hint: Use a Number Validation
Table that matches on the source address and applies the appropriate Announcement
Attributes.)
5. Remember to unset the Overriding Config Set field or delete the Call Trace when you've
finished.
Checkpoint: You can now use the Override Config Set feature to test translations using
live calls. However, you also now know that live testing is not always the best way to test
translations! So next we'll look at testing using Route Verification Tests.
80 CONFIDENTIAL
Do thorough testing and build a test suite using Route Verification Tests
Do thorough testing and build a test suite using Route
Verification Tests
Route Verification Tests (RVTs) simulate and test a call going through a Config Set. We
strongly recommend building up a test suite of RVTs on your CFS covering a wide range of
calls, and then running them after each change. RVTs are also useful when you cannot make
a suitable real test call for some reason, e.g. you don't have access to the required remote
switch. In this chapter you'll learn how to configure, run and interpret RVTs.
Did you know? Even if two people nominally speak the same language, they can
still have problems with translation. For example, in America pants means trousers. It's
therefore perfectly acceptable to compliment someone on their 'nice pants'. However, in
Britain, where we also speak English, pants means underwear. It's absolutely not a good
idea to compliment a British citizen on their 'nice pants'!
When you run an RVT, the RVT component initiates a new call, using the information provided
on the RVT such as the called number. The call is then passed into translations at the start of
Number Validation and, as far as the translations component is concerned, it's a real call.
The RVT component interrupts the call after Number Validation (which includes the On-Switch
Lookups section) and records the results, such as any change to the called number and which
Attributes have been added to the call. The CFS then continues processing the call, treating it
as a real call. The RVT component then interrupts the call again after Trunk Routing, records
the results again and then terminates the call. Therefore an RVT is effectively a real call but it
won't trigger a billing record and no signaling messages will leave the CFS.
Note: The RVT component is actually implemented in the code as a call service. Therefore in
SAS you'll see traces saying that a call service has initiated a call and that a call service has
terminated a call.
RVTs have several advantages over live testing (which we covered in the previous chapter, Do
live testing using Override Config Sets on page 77).
• You don't need access to a real phone to test a call.
• They are much faster to run than a real call because you don't have to dial digits and there's
no external signaling involved.
• You can create lots of RVTs and run them in groups, thereby testing lots of your translations
very quickly.
• You can see the details of how the call was processed, such as the Attributes added, not
just whether the call was connected or not.
We strongly recommend configuring a wide range of RVTs on your CFS and running them
after each change. These RVTs should test all of the paths that calls might take through your
configuration. For example, you should have RVTs to test all of the types of call (local, national,
international, operator etc.) from all of the subscriber areas that you support.
You should also have RVTs that test calls that you expect to fail, such as misdials or calls to
numbers that may be blocked. Before making a new Config Set live simply run your standard
RVTs to check they all behave as expected; you can then be confident that the new Config Set
is good to go live.
However, as with everything, there are some disadvantages to RVTs.
• They only test the configuration on the CFS. If there's a problem in your network then RVTs
won't find it.
CONFIDENTIAL 81
• RVTs pass a complete number in to translations starting at Number Validation, so they

don't test Digit Maps. Business Groups have special, dynamic, Digit Map requirements
(which aren't covered in this guide) so the CFS won't let you create RVTs from Business
Group Lines.
• Since RVTs pass a complete number to Number Validation, you can't use RVTs to test
Overlap Signaling. We covered overlap signaling earlier in Get ready to discuss overlap
signaling on page 64.
Checkpoint: You can now explain the benefits of RVTs. Let's now learn how to create and use
them for straight-forward calls. Later in this guide (in Handle trunk failures and rerouting on page
107) we'll also look at using RVTs to test rerouting and trunk failures.
Configure simple RVT Groups and RVTs

Now you know why RVTs are a good idea (I'd even say they're a Good Idea, for extra
emphasis!), we can now look at how to configure Route Verification Tests (RVTs) to make test
calls through a Config Set.
The first step is to find the RVT section, which is under the Test Function section of the CFS.
Note: I recommend 'bookmarking' the Trunk Routing and Policy Services object by creating a
new custom view. This makes it much easier to find your way around, especially if you're
swapping between a Config Set and the RVTs while you're doing testing.
Under the Route Verification Tests object, the RVTs are then split into Route Verification Test
Groups.
These Groups serve a couple of purposes. Firstly, you can set default values on the RVT
Groups, which the child RVTs then inherit. This makes it faster and simpler to configure RVTs.
Secondly, putting RVTs into groups of related tests, e.g. incoming calls from a particular SIP
trunk, makes it easier to find and run specific RVTs. It's therefore a good idea to split your RVTs
into convenient groups, rather than having a few very large groups.
82 CONFIDENTIAL
Under an RVT Group there are then 2 types of RVT: Subscriber and Trunk. Subscriber Route
Verification Tests mimic calls from a subscriber on the CFS. Trunk Route Verification Tests
mimic calls arriving at the CFS from a trunk. You can have both types of RVT in the same Group
but the configuration is usually simpler if each RVT Group only contains one type of RVT.
We'll now look at how to create an RVT Group and then how to create individual RVTs. Once
we've covered the configuration, we'll look at how to run and interpret your RVTs.
Create an RVT Group

The RVT Group object defines the default field values for the child RVTs. These are starting
properties of the call, such as the incoming trunk and the calling party number. In short, if an
Attribute (see Record call properties using Attributes on page 53) can be set before a call enters
Number Validation based on information from the incoming signaling or the calling subscriber,
then you can set a field on the RVT Group and child RVTs that corresponds to that Attribute.
To make it easy to create individual RVTs, try to use default values on the RVT Group as much
as possible. You can override the values on the child RVTs, but it's easier if you can just use
the default values inherited from the RVT Group. If you need to override the default values a
lot for some child RVTs, then consider creating a separate RVT Group with appropriate default
values for those RVTs.
An RVT Group object has many fields, since there are many Attributes that you can set on a call.
However, only a few fields are mandatory so we'll focus on those. Since a Group can contain
both subscriber and trunk RVTs, a few of these mandatory values apply only to subscriber
RVTs and some apply only to trunk RVTs. If the values won't apply to your child RVTs just fill in
the fields (since they're mandatory) and don't worry about the value because the RVTs won't
use them.
Looking at the mandatory fields, the first one is the Default trunk routing config set. Set this
to the Config Set that you want to test and do not override the value on child RVTs. If you want
to test a different Config Set in the future you will only need to make a single field change to run
all of the child RVTs in a Group against the new Config Set. This is much easier than having to
update each RVT individually!
The next mandatory field is the Default subscriber type, which can be Configured or
Hypothetical.
If you choose Configured then you must fill in the Default subscriber directory number,
which must match an existing subscriber on the CFS. (Remember that you can't use a Business
Group Line with RVTs.) The RVT will then mimic calls from that subscriber and use values taken
CONFIDENTIAL 83
from the subscriber's record, such as the Subscriber Group and Line Class Code values. It's
simplest if you have a suitable subscriber that you can use for this field.
The other Default subscriber type is Hypothetical. In this case the RVT Group exposes
fields allowing you to set a Subscriber Group, Billing type etc. This means you have to do more
work to set up the RVT Group, but allows you to run RVTs when you don't have a suitable
existing subscriber. For example, you can use RVTs with hypothetical subscribers to test the
configuration before you migrate some subscribers to the CFS. You will also need to use this
option if you have a pure Class 4 system with no subscribers.
The remaining mandatory fields on the RVT Group will only apply to child Trunk RVTs and
represent fields that may be signaled to the CFS in an incoming message.
The simplest possible RVT Group is one with just the Test name field plus the mandatory
fields set. However, depending on your translations configuration, you will need to set some
additional fields to test parts of your configuration. For example, if you have a Number Validation
Table that matches on the incoming trunk type, you should set the Remote media channel
field on some RVTs so that you can test that Table.
Create a Subscriber RVT

If you have set the RVT Group up appropriately then ideally you will only need to set 2 fields
to create a Subscriber Route Verification Test - the Dialed number and the Test name. The
Test name field is not mandatory but I strongly recommend filling in the field because it's used
as the display name in the object tree. A a good name makes it much easier to find your RVT
in the tree.
84 CONFIDENTIAL
The other settable fields on a Subscriber RVT object let you override values set on the RVT
Group. As with the RVT Group, you will use these if you want to test specific areas of your
configuration that match on particular Attributes.
Note: Both Subscriber and Trunk RVTs can be created by using the MetaView Explorer import
feature, which is great for bulk creation. This useful feature isn't specific to translations so
isn't covered in detail in this guide. For more information see the Exporting and Importing
Configuration Appendix in the MetaView Explorer User's Guide.
Create a Trunk RVT

Trunk RVTs are used to mimic a call arriving at the CFS from the network. A Trunk RVT has no
mandatory fields but, as with Subscriber RVTs, it's a good idea to fill in the Test name field so
that it's easy to find the RVT in the object tree.
After filling in the Test name, the required fields will depend completely on your configuration.
As with setting up the RVT Group object, if your translations match on a particular Attribute
then you should set the corresponding field on the RVT or the parent RVT Group.
Run and interpret RVTs

Once you have created a Subscriber or Trunk Routing Verification Test, it's time to run it and
see if the call will succeed or not. The RVT object will also show lots of details of the processing,
such as the Attributes attached to the test call during processing and any changes to the
numbers associated with the call.
CONFIDENTIAL 85
To run an RVT, make sure it is enabled and then use the run test button. You can also run all
RVTs in a Group using the run all tests button on the RVT Group object. (These actions are
also available on the right-click menu for the objects.)
The Test
result field is at the end of the configurable fields on the RVT object. An example is shown
below.
After the Test result field is the Expected result section. We'll cover this later in the chapter,
so ignore it for now. After that is the Number Validation section. This section shows the call
properties when the call left Number Validation. This includes all of the Attributes that were set
on the call and the final versions of any numbers associated with the call. For example, you can
see if the called number was modified as expected (prefix added, prefix deleted etc.)
86 CONFIDENTIAL
Below the Number Validation section is the Routing section, which contains similar
information about the results of the On Switch Lookup and Trunk Routing sections. Here you
can see where the CFS routed the call.
For example, it shows the called number, which may have been modified.
Checkpoint: You can now configure RVTs to test calls from subscribers and from trunks, and
you know how to read the fields on the RVT to see if a call behaved as you expected. Now let's
see how we can make RVTs even more useful by setting the Expected result.
Use Expected results to highlight failed RVTs

Looking at the fields on an RVT to see how the call was handled is fine if you're only running
one RVT, but will quickly get very boring if you have lots of RVTs! That's where expected results
come in. The Expected result section on a Routing Verification Test lets you configure the
expected result for an RVT. The RVT will then alarm if the actual result does not match the
expected result, making it really easy to spot which RVTs have failed. Let's see how you can
set up expected results for your RVTs.
The Expected result configuration section covers the full range of possible outcomes from
translations. For example:
• you may expect a call to fail in Number Validation because it's a misdial
• you may expect a call to route to a subscriber
• you may expect a call to route to a specific trunk.
When you change the Expected result field, the RVT will update to show the appropriate
other Expected result fields; some examples are shown below. You can also set the value on
the parent RVT Group and it will be inherited by child RVTs.
CONFIDENTIAL 87
You should aim to set the Expected result as explicitly as you can. For example, set the specific
trunk the call should use, rather than leaving the Expected destination as Any media channel
or on-switch subscriber (the default value). This makes your RVTs more effective as they will
detect any deviation from the expected behaviour. In particular, it lets you fully test the effect of
calls being rerouted because of trunks being unavailable. (We'll cover rerouting later in Handle
trunk failures and rerouting on page 107.)
When you run an RVT with an Expected result, the status icon and name shown in the object
tree show you if the RVT works as expected, as shown in the examples below. The failure is
also passed up to the parent RVT Group, so it's very easy to spot any failed RVTs, even if you
have hundreds of RVTs split into many Groups.
88 CONFIDENTIAL
Suggested Exercises
1. Create a new Route Verification Test Group, using your Config Set and with a real subscriber
as the default subscriber value.
2. In the RVT Group, create a new Subscriber RVT to test a national call from that subscriber.
3. Run the new RVT and check that it succeeds. Check that the Called address scope is set
to a suitable value (usually National) when the call completes Number Validation.
4. Deactivate your Config Set and run the RVT again. Check that the RVT fails. This is a
common mistake when editing and testing your configuration! Reactivate the Config Set
afterwards.
5. In the RVT Group, create another new Subscriber RVT that tests a call to a misdialed
number.
6. Run the new RVT and check that it fails.
7. Set the Expected result fields to show that you expect the misdial RVT to succeed. Rerun
the RVT and confirm that the RVT is now alarmed in the tree.
8. Change the Expected result fields to show that you expect the misdial RVT to fail. Rerun
the RVT and check that the RVT is no longer alarmed in the tree.
9. In the RVT Group, create a new Trunk RVT to test an incoming call to a subscriber from
a particular trunk. Use the Expected result fields to make it easy to spot that the RVT is
behaving as expected.
10. Run all of the RVTs in the Group by using the Run all tests button on the Group.
Checkpoint: You now know how to configure, run and interpret RVTs effectively. You'll find
these a great tool for checking your translations configuration. Now we're going to look at
getting translations diagnostics for calls.
CONFIDENTIAL 89
Get diagnostics for a call using the Service Assurance Server
Get diagnostics for a call using the Service Assurance

Server
Even if you know your translations configuration really well, it can still be useful to see how a
call was actually processed. Here you'll learn how to interpret the translations trace produced
by the Service Assurance Server (SAS).
I'm going to assume that you're already confidently using SAS to get diagnostics for calls, so
I'm not going to remind you why it's so fantastic or how to do searches. If you want a reminder,
take a look at the MetaView Service Assurance Server Guide. Here we'll look specifically at
how translations are traced in SAS.
The good news is that almost everything you'll ever need is shown in SAS. Simply find the
SAS record for the call and go to the Detailed Timeline tab. The default setting of High level
events shows all of the translations information. This screenshot shows an example.
If your SAS is monitoring multiple Metaswitch devices then it's a good idea to use the filter
drop-down so that you're only looking at events from the CFS. In particular, the translations
trace from a Perimeta Session Border Controller can look very similar to the trace from a CFS,
so it can be easy to get them mixed up.
The trace shows 3 stages of translations - Number Validation, On-Switch Lookups and
Trunk Routing. The trace from the CFS doesn't show the details of any Digit Map processing
since this is handled either by the UMG or by the end device. Let's look at the individual events
in order.
The first translations event is Starting number validation. It shows the starting numbers
associated with the call, and also the Config Set used for the call. If you're running Route
Verification Tests or making test calls, make sure to check that your call went through the right
Config Set!
90 CONFIDENTIAL
If Number Validation modifies the number, then you'll see events like NV has changed the
called address of the call.
Once Number Validation has finished going through the Number Validation Tables, you will
see events recording the first part of looking for the called number on the CFS. Remember
that lookups are actually a two-stage process, where the first stage is done as part of Number
Validation. (We covered this in Look for the called number on the CFS in On-Switch Lookups on page
73.) In the example above, the CFS found the called number in an On-Switch Lookup Number
Block. The CFS also checked that the Attributes on the call do not block doing a lookup; we
also covered this in the chapter on On-Switch Lookups.
If the call does not need a lookup, then you won't see these events.
The next event, NV succeeds, summarizes the call's flow through Number Validation. This
event is particularly useful because it lists which Tables and Entries were chosen.
The history format is: (Table index, Entry index, Attribute Set index). You can use these index
values in the MetaView Explorer to find the exact configuration that was used for the call. The
CONFIDENTIAL 91
next action is shown at the end in a slightly abbreviated format. The full list of next actions is
shown at the bottom of the event.
So, rather than manually working out which Tables and Entries a call will use, as we did in
Follow a call through Number Validation on page 42, you can now be lazy and just use SAS!
The next event in our example, Call is being routed to a local subscriber, shows the
second part of the lookup processing, where the CFS actually looks for the called number in
its subscriber database.
If Number Validation decided that no lookup was required then you'll see an event saying A
local subscriber lookup is not required instead.
Finally, the call will pass into Trunk Routing. If the call has already been routed to a subscriber
then Trunk Routing won't do anything and the Routing begins and Routing succeeds
events will look like these.
92 CONFIDENTIAL
If, on the other hand, the call was not routed to a subscriber, then Trunk Routing is responsible for
sending the call to a specific trunk. You haven't yet learned about Trunk Routing configuration,
so I'll just say that the SAS event when a call exits Trunk Routing, like the event when the call
exits Number Validation, shows you everything that happened to the call in Trunk Routing. We'll
cover Trunk Routing configuration soon in Route a call off the CFS using Trunk Routing on page 95.
View Route Verification Tests in SAS

SAS also records the same sort of events for Route Verification Tests (we covered RVTs in Do
thorough testing and build a test suite using Route Verification Tests on page 81). Remember: from
the perspective of translations, a call initiated by an RVT looks exactly the same as a real call.
So, most of the events produced by the translations components are exactly the same as for
the real call shown above.
CONFIDENTIAL 93
The only differences between RVTs and real calls are at the start and at the end of the trace.
At the start of the trace you'll see events recording that the RVT component has initiated a
call. The RVT feature is actually implemented as a call service on the CFS, hence some of the
events refer to "a call service".
The next events then show a call passing through translations as normal. The RVT component
then terminates the call after Trunk Routing (or earlier if the call fails earlier in the processing).
This generates a generic event saying A call service has hit an error, since normally it is an
error if a call service hits a problem and terminates the call!
Suggested Exercises
1. Make a call that uses the CFS, either by making a call from a subscriber or from a trunk.
Find the call in SAS and go to the Detailed timeline tab. Make sure that you're looking at
events from the CFS.
2. Find the event showing the start of Number Validation and check that the call is using the
correct Config Set.
3. Find the event showing that Number Validation has succeeded or failed. Check that the
Tables and Entries shown in the history match how you expected the call to be processed
in Number Validation.
4. Run an RVT and then find the call record in SAS. Check that you can tell from the events
that it's an RVT, not a real call.
Checkpoint: You can now use the Service Assurance Server to get a lot of useful diagnostic
information about how the CFS translations handled a call. Now let's get back to configuration
and look at the final stage of translations - Trunk Routing.
94 CONFIDENTIAL
Route a call off the CFS using Trunk Routing
Trunk Routing follows the On-Switch Lookups section and is the final stage of translations.
The Trunk Routing section chooses the outgoing trunk for a call, handles rerouting if necessary
and also controls some of the outgoing signaling.
The implementation of Trunk Routing is very similar to the implementation of Number Validation
(which we covered in Modify, classify and block calls in Number Validation on page 28) - it's a flow
chart.
The two key configuration objects are Routing Tables (equivalent to Number Validation Tables
in Number Validation) and Routing Actions (equivalent to Entries).
CONFIDENTIAL 95
Each Routing Table matches on one or more parameters and the child Actions match on
specific values for those parameters and then define what to do with the call. Again, this is very
similar to the configuration in Number Validation. The call passes between Tables until an
Action sends the call to a particular Trunk.
Did you know? Talking of trunks, an elephant can store up to 11 litres of water in its
trunk. For those of you from an American background, that's 10 quarts (short for 'quarter
of a gallon'). To be precise it's 10 United States liquid quarts, which are 0.946 litres. Don't
get US liquid quarts mixed up with US dry quarts, which are 1.101 litres. And neither type of
US quart should be confused with Imperial quarts, used in other countries, which are 1.14
litres. Phew, and you thought CFS translations were tricky!
Despite the similarities in configuration model, there are some significant differences between
Trunk Routing and Number Validation. The two main differences are:
• there are no standard Routing Tables
• Trunk Routing supports rerouting on failure.
The lack of a standard base configuration for Trunk Routing is the more obvious difference.
Compared with Number Validation, the Trunk Routing configuration varies a lot between different
deployments. Number Validation looks very similar on all systems because all deployments
need to identify national, international, operator etc. calls and therefore we provide a base
configuration that provides this functionality. However, once specific call types have been
identified, every deployment has different routing requirements. Therefore there is no standard
set of Routing Tables.
Rerouting is where the CFS will try sending the call to another trunk if the first trunk fails.
Handling rerouting is actually the more important difference between Trunk Routing and
Number Validation because it has a number of subtle impacts on how things are configured
and how this works. However, this probably feels rather theoretical to you at the moment so
I'm going to skip this topic for now (we'll cover it later in Handle trunk failures and rerouting on
page 107). Instead let's get our hands dirty with some real configuration first!
Checkpoint: You now know what Trunk Routing does and you know how the configuration fits
together to create a flow chart to decide where to send particular calls. Now we can move onto
the actual configuration objects, starting with Tables.
Understand Trunk Routing Tables

Now that you've got an overview of how Trunk Routing works, let's start looking at the actual
configuration. We'll start with the Trunk Routing Tables.
In Trunk Routing, all calls start in the same Routing Table (unlike Number Validation which has
different entry points for calls from subscribers and for calls from trunks). This starting Table is
defined by the Initial Routing Table field on the Config Set, which is also shown as a reference
in the object tree. Following the reference is the easiest way to get to the starting Routing Table.
96 CONFIDENTIAL
The fields that you'll see on the Table will then depend on the Routing Table type field, as
illustrated below. These fields are equivalent to the Address match type and Match Attribute
fields on a Number Validation Table and define what the Table is looking for.
There are many Table types; many are the same call properties that you can match on in
Number Validation, such as the incoming trunk, but others are specific to Trunk Routing, such
as the time of day. The table below outlines what the different Routing Table type values do
(for full definitions see the appropriate MetaView Object Reference manual for your system).
The Routing Table type value on the parent Table then controls which match fields are shown
on the child Action objects, which we'll cover later in this chapter.
Routing Table type When to use this type
Destination address These options let you match on the called or calling address.
and source address As you'll learn later in this chapter, these types match on the scope
of the address, as well as the digits. Using the scope (covered
earlier in Record call properties using Attributes on page 53) is an
easy way to split out the key types of call, such as national and
international.
Transit address (North This matches the carrier chosen for the call. This type is only used
America only) in NANP deployments.
Current time This option is used for time-of-day routing. For example, Trunk A
may be cheaper during the week while Trunk B may be cheaper at
the weekend.
Sequential selection With sequential selection each Routing Action is used in turn,
thereby distributing the calls evenly across all of the Actions in the
Table.
CONFIDENTIAL 97
Weighted random In a Weighted random Table, you assign a weighting to each Action
and then the Actions are chosen randomly according to those
weightings. This lets you spread the calls across all of the Actions
to achieve the required distribution.
Sticky random A Sticky random Table is configured in the same way as a

Weighted random Table and the first Action is chosen based on the
weightings. However, the CFS then continues to use that Action
until it fails. At that point the CFS will choose another Action based
on the weightings and then continue to use that Action until failure.
This type of Table is useful if the trunks are prone to failure because
the CFS will continue to use a known good trunk.
Call gapping In a Call gapping Table each Routing Action can only be used
once within an assigned period of time. The CFS will choose the
Action with the lowest index. Once an Action has been used, it is
effectively removed from the configuration until the call gapping
period has finished. If a call arrived during this period, the CFS will
look for the Action with the next lowest index in the Table.
Using call gapping Tables lets you restrict the traffic load on a trunk,
for example to comply with a contractual agreement or as a form of
congestion control.
If you want to use Call gapping Tables, make sure you read Handle
trunk failures and rerouting on page 107, so that you know how Call
gapping Tables interact with rerouting.
Incoming media type This lets you match on the incoming media. You can match on the
type (SIP, ISUP, ISDN etc.), the remote exchange or the specific
trunk. For example, a very simple way to implement transit routing
is to route all calls from Trunk A to Trunk B.
This Table type is equivalent to setting one of the Match Attributes
to Incoming Media on a Number Validation Table.
Subscriber NV and There are a few translations-specific attributes that can be set in the
routing attributes Number Validation and routing attributes field on a subscriber,
such as whether or not they are a Fax or Modem subscriber. You
may want to provide different processing in translations for these
subscribers.
This option is rarely used now because Line Class Codes (LCCs)
give more flexibility when defining subscriber properties. (We
covered LCCs in Extend the built-in Attributes using Line Class Codes
and User Defined Attributes on page 60.)
98 CONFIDENTIAL
Number Validation This matches on Attributes set up in Number Validation, such as

Attributes the Call Type (US Call Type or UK Call Type, depending on your
region). When you select this type, MetaView Explorer will expose 3
Match Attribute fields. These fields behave the same as the Match
Attribute fields on a Number Validation Table (we covered these in
Modify, classify and block calls in Number Validation on page 28).
Incoming release This is used if the CFS has previously tried to route a call and it
cause failed. The release cause from the previous rerouting attempt can
then be used to decide where to reroute the call. We'll look at how
to use this Table type later in Handle trunk failures and rerouting on
page 107.
Bearer capability The incoming signaling for a transit call may have specified the
bearer capability - the type of media channel that is required for the
call. Sample values are 64kps data or speech. This type of table
lets you select an Action based on this signaled bearer capability.
Checkpoint: You now know how to configure a Trunk Routing Table object to match on certain
call parameters. Now let's see how the CFS chooses the child Routing Action for a given call.
Identify which Routing Action matches a call

When a call reaches a particular Routing Table, the CFS will look at all the child Routing Actions
to see which Action is the best match. Here you'll learn how the CFS chooses the best match
Action.
The match properties on the Action depend on the type of the parent Routing Table, as shown
in this example.
CONFIDENTIAL 99
If there are multiple possible matches then the CFS will choose the most specific match. For
example, an Action that matches a specific property value is more specific than an Action that
matches any value. The following screenshots show a couple of examples of matching on
simple properties.
Identifying the best match for most Table types is simple. However, I think that the configuration
to match on numbers (destination, source or transit) is potentially confusing, so we'll look at
these match types specifically.
Before we do, there's one other interesting fact about matches in Routing: it's fine to have
multiple identical matches (unlike in Number Validation where this is a configuration error). This
is to support rerouting on failures, which we'll cover properly later in Handle trunk failures and
rerouting on page 107. The CFS will choose the identical Action with the lowest index. If this
initial route fails then it will use the other Actions.
100 CONFIDENTIAL
Match on Destination, Source or Transit address
The configuration to match on numbers (such as the destination or called number) is slightly
more complicated than in Number Validation. First create a Table with the Routing Table type
set to Destination address, Source address or Transit address. Any child Actions will then
automatically contain several address match fields.
Let's go through these fields in order and see how to use them.
Start by filling in the Description field with a good description of what this Action does. By
this point in the guide I hope that you've learned to fill in any name or description fields, even
if they're not mandatory!
Next set the Address type field. The options here are Not present, E.164 or Network ID.
If you're matching on the source or destination address, you need to choose between Not
present if there will be no number associated with the call (e.g. some operator calls have no
destination number by the time they reach Trunk Routing), or E.164 if there will be a number.
The Network ID value is only used if you're matching on the Transit address, which is used to
route by carrier in a NANP deployment, so we won't cover it here.
In the vast majority of cases there will be a number so you'll use the E.164 setting, so let's look
at that first. When you choose this value, the Address Scope field will appear. You must now
set the scope that you want to match. The scope defines the area over which the number is
unique (we covered the concept of scope in Record call properties using Attributes on page 53).
Using Match any means the CFS will effectively ignore the scope. Setting any other value,
such as National, will mean that the Action only matches that specific scope.
You then need to set the Wildcard address type field. This is the field that can confuse
people.
CONFIDENTIAL 101
The Wildcard address type field has 4 possible values. Firstly, if you only care about the
scope and not the actual digits, then use the Full wildcard - this type value.
If you want to match on the actual content of the number, then you need to use Explicit
wildcard or Part wildcard header. Explicit wildcard lets you define the number that you
want to match. It's like a complete match in Number Validation because the length has to
match, as well as the individual digits. Similarly, Part wildcard header is like a prefix match in
Number Validation: it lets you define the start of the number that you want to match.
For both of these values, you then need to fill in the Wildcard address field to define the match
number, as shown in the examples below. Unlike Number Validation, you must define the digits
and characters explicitly. In other words you can only use 0-9, the characters A, B, C and D,
and the * and # (representing the * and the # on the keypad).
The Wildcard address effective prefix length field for Part wildcard header matches is
rarely used. Despite the name, it's not really to do with the actual length of the match number.
Instead it's used to distinguish between two Actions with an identical match - the one with the
102 CONFIDENTIAL
large prefix length is treated as a better match. Unless you really know you need this function,
just leave this field as zero which means it won't be used!
That leaves one final value for the Wildcard address type field - Full wildcard - any type.
This option is a very wild wildcard and will match on any digits, from any type of number. In
other words it'll match on the source, destination or transit address. This value is likely to cause
confusion and you're unlikely to ever need to use it, so just ignore it.
That finishes the configuration for when you expect a number to be present. Now let's look at
an Address type of Not present, which means that there's no number associated with the
call. This may sound illogical, but can happen if Number Validation completely removes the
dialed digits, which is sometimes done for operator calls.
In this case, when you set the Address type to Not present, the Wildcard Address Type field
will appear with the same options we saw above.
Since there are no address digits in this case, you don’t want to use the Explicit wildcard
or Part wildcard - this type options and, as described above, you should ignore the Full
wildcard - any type option. That means you'll always use the Full wildcard - this type
option if there's no address present.
Checkpoint: You can now look at the Actions in a Trunk Routing Table and identify which
Action is the best match for a particular call, even in the potentially confusing case of matching
on an address. This best match Action is the one that the CFS will use to process the call. Now
let's learn how the Action controls what happens to the call.
Find out what happens when a Routing Action matches a call

When a call matches a specific Action in Trunk Routing, the configuration on that Action tells
the CFS what to do next, which may include sending the call to a trunk or rejecting a call. So,
you now need to learn what the remaining Routing Action fields do.
As for Number Validation Entries, this configuration has two parts. One part controls
modifications to the call and the other part says what to do next, after doing the modifications.
Like in Number Validation, we're going to look at the second part first. This approach lets you
quickly build up a mental picture of how the Trunk Routing Tables are connected.
So, first look at the Action field. This field is equivalent to the Next action field in Number
Validation, but with fewer options. It has 4 possible values.
• Table lookup. This means that the processing should move on to another Routing Table,
as defined by the Next table field.
CONFIDENTIAL 103
• Routing complete. Trunk Routing has finished analysing the call and the call will now be
sent to a specific trunk, as defined by the Media channel field.
• Reject. This will reject the call. Note that the CFS will not reroute the call if an Action
explicitly rejects a call. We'll cover rerouting properly in the next chapter, Handle trunk
failures and rerouting on page 107.
• Return for reroute. This will pass the call back to the previous Routing Table that the call
came from. This option is rarely used but occasionally comes in handy if it's easier to define
the list of things that shouldn't match a call than to define the things that do match the call.
In this case create a Routing Table with the things that don’t match and set the Action fields
to Return for reroute. Make sure that the previous Table has an Action that will match the
call and route it appropriately.
These values build up the flow chart we described at the start of the chapter.
Checkpoint: You can now use the Action field to understand how the Action fits into the Trunk
Routing flowchart. Now you need to learn how Routing Actions can modify calls, starting with
changing the numbers associated with a call.
Modify the called, calling or charge number in Trunk Routing

After looking at the Action field, the next key area to look at is Number action section which
is where you can modify the numbers associated with the call.
The notation for these Number action fields is the same as the modification fields in Number
Validation. Refer back to Modify, classify and block calls in Number Validation on page 28 if you
want more information. Note that, unlike Number Validation, you can modify all 3 numbers at
the same time and you can modify the numbers even if the Table doesn't match on an address.
There's one big difference between number actions in Number Validation and number actions
in Trunk Routing: in Trunk Routing, the number action is only applied at the end. This has two
important consequences.
• In Trunk Routing, address matches in subsequent Routing Tables match on the original
number, not the modified number.
• You can't combine number actions from multiple Routing Tables. If multiple number actions
are applied while routing a call, only the last one is used at the end.
Number modification is normally done in Number Validation so these Routing fields are typically
used only if the particular destination or route has a specific requirement for the number format.
For example, the remote exchange may require the number to be sent without the area code
prefix. Since the required modification depends on the destination trunk, it's easiest to make
the change in Trunk Routing once you've identified the target trunk.
104 CONFIDENTIAL
Since the modifications are assumed to be destination-specific, if the routing fails then the
modifications are rolled back appropriately. We'll cover this in more detail later in Handle trunk
failures and rerouting on page 107.
Checkpoint: You now know when you might want to modify numbers in Trunk Routing and you
know how to modify them. We'll now look at the final part of configuring an Action - Optional
attributes.
Use optional attributes in Trunk Routing

In Trunk Routing you can apply Optional attributes to a call. These are generally trunk-specific
or destination-specific properties, such as signaling routing codes and rerouting control. Here
we'll look at how to use the optional attributes.
The optional attributes are configured in the Optional attributes section on a Routing Action
object. There are 2 steps to configure an individual optional attribute. Firstly, select the check
box in the list of attributes. This indicates that you want to change the field. When you check/
tick a box, the Settings panel will then adjust to display the appropriate field below the attribute
list. This new field is where you can change the value of the attribute. Be careful - just checking
the box does not change the attribute!
CONFIDENTIAL 105
Once set, the attributes are maintained if the call passes to another Table. For example, in
some cases it may be neater to set some of the optional attributes in one Table and then pass
the call into another Table containing lots of Actions which route the call to specific trunks.
However, since these attributes are destination or trunk-specific, they will only be used if the
call is successfully routed. If the call is rerouted then the optional attributes are rolled back
appropriately. We'll look at this, and the AAR allowed and ARR allowed attributes, in more
detail in the next chapter.
Suggested Exercises
1. Follow a national, international and emergency call through your Trunk Routing configuration.
Check that these calls are handled as you expect.
2. Create an RVT that will test a call that goes through Trunk Routing. Run the RVT and find
the call record in SAS. Use the events in SAS to check which Routing Tables and Actions
are used for that call.
The rest of these suggestions form an advanced exercise.
1. Choose an existing Action that routes a call to a trunk. Change the Action to send calls to a
new Table that load-balances the calls between the original trunk and another trunk. (Hint:
the new Table can be either a Sequential selection or a Weighted random Table.) Make sure
your Actions and Tables have clear names to make it clear what they do!
2. Create a new RVT that will send a call to the new Table. Run the RVT several times and use
SAS to check that calls are load-balanced between the two trunks.
Checkpoint: You now know how Number Validation configuration fits together to create a
simple flowchart for processing calls and you can now follow a call through Trunk Routing.
Now let's make things more interesting by learning how to Handle trunk failures and rerouting
on page 107.
106 CONFIDENTIAL
Handle trunk failures and rerouting
One key feature of Trunk Routing is that it handles rerouting; if the initial route is unavailable
for some reason then Trunk Routing can try rerouting to other trunks. Here you'll learn how to
configure rerouting (also known as overflowing) and also how to block rerouting.
A trunk may be unavailable to process a call for various reasons. For example:
• the configuration for the trunk has been deactivated or disabled
• the trunk is out of service, e.g. the cable has been disconnected
• the Trunk is already full of calls.
If the initial route fails then you need to decide if you want to fail the call or reroute it to another
trunk. If you allow rerouting then the CFS will look for the next best Routing Action in the final
Table. If there's no possible matching Action in the Table then the CFS will move back through
the Tables until it finds a possible match. Once it has found a suitable next best match the CFS
will continue forward through the Routing Tables as usual.
Let's see that in some real configuration. Consider the following two Routing Tables and a
national scope call (see Record call properties using Attributes on page 53 for more on scope)
going to a destination that starts with 510. This will take a bit of thinking, so make sure you've
had your morning coffee!
In this example the call will start in Routing Table 19, match Routing Action 1 and then go into
Table 20, where it will match on Action 1 (since it's the more specific match in this Table) and
then be routed to Trunk A. What happens if Trunk A is unavailable for some reason?
If the CFS is configured to support rerouting then the CFS will first look for another possible
matching Action in Table 20. It will match on Action 2, since this matches all possible prefixes,
and be routed to Trunk B.
If Trunk B is unavailable and the CFS is configured to support multiple reroutes then the CFS
will look for another possible matching Action in Table 20. It won't find one, so the CFS will then
go back to the previous Table, Table 19, and look for an alternative match there. It has already
used Action 1, so now it will choose Action 3 and send the call to Trunk C.
Note: Choosing good names for your objects can really help you, and everyone else, to understand
how your particular Trunk Routing configuration works. For example, if an Action is only used
as a backup, then call it something like "Backup route for all national calls".
As you can see, if you don't consider how you want to handle trunk failures when you design
your Trunk Routing then you can end up with calls rerouting to unexpected places! This is
something that Metaswitch Support will discuss with you when designing and commissioning
your translations.
In the rest of this chapter we'll look in more detail at how to control rerouting, how attributes
and number modifications are affected by rerouting and how to test that your Trunk Routing
will reroute calls correctly.
CONFIDENTIAL 107
Checkpoint: You now know that Trunk Routing supports rerouting if a routing attempt fails, and
you know that you have to consider rerouting at the design stage. Now we'll look in more detail
at how to control rerouting.
Modify the parameters that control rerouting

Rerouting will stop if any of the following are true.
• The CFS chooses a Routing Action that has the Action field set to Reject.
• There are no possible remaining Actions that match the call.
• The maximum number of reroutes has been reached.
• Rerouting for the specific level of failure has been set to false.
The first two bullets are controlled by how your Routing Actions are configured and we covered
these previously in Route a call off the CFS using Trunk Routing on page 95. That just leaves the last
two bullets to cover in more detail.
Firstly, the maximum number of times a call can be routed is controlled globally by the Maximum
number of routing requests field on the Trunk Routing and Policy Services object, as shown
below. The default is 3, which means a call will be rejected if it fails to route 3 times (i.e. if the
initial trunk and then two backup trunks all fail).
Secondly, you can permit or block rerouting for two different levels of failure.
• Switch-level rerouting is when a call is rerouted before it leaves the switch. For example,
a call may be rerouted if the trunk is full or isn't suitable for the type of call. This level
of rerouting is called Automatic Alternative Routing (AAR) and is controlled by the AAR
allowed Optional attribute.
• Network-level rerouting is when a call needs to be rerouted after leaving the switch. For
example, a call may be rerouted if the original remote destination rejected the call attempt.
This level of rerouting is called Automatic Re-Routing (ARR) and is controlled by the ARR
allowed Optional attribute.
108 CONFIDENTIAL
These two attributes are usually set in parallel, i.e. both AAR allowed and ARR allowed
are either both true or both false for a call. By default they are both true, in other words both
levels of rerouting are permitted. If you want to change the values, use the check boxes in the
Optional attributes section and then use the drop-down fields to change the value. (See
Route a call off the CFS using Trunk Routing on page 95 for more on setting Optional attributes in
Trunk Routing.)
A trunk where overflow routing is blocked is sometimes known as a choke trunk. Choke trunks
are used where you want to make sure one type of traffic does not use up all of the capacity
and block other calls from getting through. As with all translations make sure you configure
RVTs that test what happens if the choke trunk is unavailable. In this case, the call should be
rejected rather than rerouting to another trunk. We'll look at how to configure RVTs to test
rerouting later in this chapter.
Checkpoint: Now you know how to allow or block rerouting. Now let's see how the call
properties are affected if a call is rerouted.
Understand how optional attributes and number modifications are affected

by rerouting
In Trunk Routing it's assumed that any optional attributes and number modifications are
destination or trunk specific. So if a call is rerouted, the optional attributes and number
modifications are removed as appropriate. This means that any modifications and attributes
applied in the final Routing Action will be removed before rerouting to the next best Action. Any
modifications and attributes applied in earlier Actions will be maintained if those Actions are still
part of the new path through Trunk Routing.
This is easiest to explain with an example, though this will take a fair amount of thinking so
make sure that your morning coffee was a strong one! Consider the same configuration as at
the beginning of this section, but now some of the Actions modify the called number, as shown
in their name in the following screenshot. (We covered the notation for modifying numbers
earlier in Modify, classify and block calls in Number Validation on page 28.)
Let's assume we start with the destination number 510 1234567. The call starts in Routing
Table 19 and matches Action 1, which has a number action to remove the first digit from
the prefix, giving us 10 1234567. The call then passes into Routing Table 20 and matches
Action 1 (remember we match on the original number not the modified number). Action 1 has
a number action which adds a prefix of 11, which overrides the number action we applied in
Routing Table 19, so the destination number passed to Trunk A is therefore 11510 1234567.
If Trunk A fails, the PA11 is rolled back, giving us 10 1234567 as the destination number
again, which is what the destination number was when the CFS first entered Table 20. The call
is then passed to Action 2, which adds a prefix of 22. Once again this overrides the number
action that was applied in Routing Table 19, therefore 22510 1234567 is the destination
number passed to Trunk B.
If Trunk B also fails, the PA22 is rolled back so the destination is now back to 10 1234567
again. The CFS looks for another possible match in Table 20 but since it doesn't find one it has
to move back to Table 19. Action 1 in Table 19 has already been tried but it failed, so the PD1
CONFIDENTIAL 109
from that action is rolled back, so the destination is now back to 510 1234567, which was
the destination number when the CFS first entered Table 19.
The CFS then looks for another possible match in Table 19 and sends the call to Action 3
(which doesn't modify the number) and the call is sent to Trunk C with a destination of 510
1234567. In other words, the result of the number modifications is always the same when you
get to a given Action, regardless of whether the call was rerouted before reaching the Action.
This example looked at number modifications but the same mechanism applies to how optional
attributes are handled during rerouting. (See Route a call off the CFS using Trunk Routing on page
95 for more on optional attributes.)
Blocking rerouting when you're using Call gapping - a note

If you're not using Call gapping Routing Tables then you can skip this section, but I want to
mention this information because it sometimes catches people out. If you want to stop calls
from rerouting in a Routing Table of type Call gapping then you can't use AAR and ARR. (We
covered Call gapping Tables in Route a call off the CFS using Trunk Routing on page 95.)
When a Call gapping Action's limit has been exceeded (i.e. the maximum number of calls for
the configured time period has been reached), then that Action is effectively removed from the
configuration. The CFS will then look for the next best matching Action to use for the next call.
This means that any optional attribute set on the original Action will not be applied to the next
call. Therefore setting AAR and ARR to false on the original Action will not stop the call from
being rerouted when that Action reaches its limit.
To stop a Call gapping Action from overflowing to another trunk, you need to add an explicit
backup Action with the Action field set to Reject. Since the best match in a Call gapping Table
is the Action with the lowest index that is currently available, this special Action needs to have
the highest index in the Table because any Actions with a higher index will never be chosen.
When the main Call gapping Action is unavailable because the limit has been exceeded, the
CFS will choose the backup Action, which will immediately reject the call without any rerouting.
Reroute based on the failure reason

You may want to set up your Trunk Routing configuration so that, if an initial call attempt fails,
then the new route will depend on the error code returned on the initial attempt. Here we'll look
at how to configure this using a Routing table type of Incoming release cause.
To configure this, create a Routing Table of type Incoming release cause, then add child
Actions that route the call to the new trunks based on the release causes that you expect to
receive. The Actions are configured using Q.850 release causes.
Note: There's a lot more information on release cause values at the bottom of the MetaView
Explorer help for the Routing Action object.
Once you've configured the "route by error release code" Table, update the appropriate
overflow/backup Actions to go into the new Table. Here's an example configuration so you can
see how it might look.
110 CONFIDENTIAL
Test your rerouting
As you've probably realized by now, it's important to consider in advance how you want to
handle trunk failures, so that calls are either rejected or rerouted appropriately. It's therefore a
very good idea to set up RVTs that test the effect of trunks being unavailable. This is simple
to do - just use the appropriate configuration in the Included media channels section of the
RVT. By default all media channels are included but you can change this to provide a list of the
good trunks or the bad trunks, or to specify that no trunks are available. This screenshot shows
an example of this.
CONFIDENTIAL 111
This is one situation where you definitely want to use the Expected results section on the RVTs,
so that you can check that calls are rerouted to the expected trunk, or blocked if you prefer.
See Do thorough testing and build a test suite using Route Verification Tests on page 81 for more
on using Expected results.
Checkpoint: You can now configure Trunk Routing to support rerouting (or to block rerouting)
and you can configure RVTs that test that calls will reroute as expected. We're now going to
finish looking at a topic that we started in the last chapter - how rerouting means that Trunk
Routing differs from Number Validation.
Understand how rerouting impacts translations

In the previous chapter, Route a call off the CFS using Trunk Routing on page 95, we started
to discuss the differences between Trunk Routing and Number Validation. In that chapter I
mentioned that the need for rerouting has several subtle impacts on how things are configured
and how they work. It's now time to look at these impacts in more detail. The main one is on
performance, so we'll cover that first.
Impact on performance and overall design of translations

Trunk Routing needs to support rerouting and it also has to support choosing the best match
Action based on dynamic information such as the time of day. This means that the underlying
code used to identify the best match in a Routing Table is different from the code used in
Number Validation. As a result Number Validation is faster at finding the best match, especially
for larger Tables. So, where possible, you should put your configuration in Number Validation
rather than Trunk Routing, especially if it involves long lists.
Note: If you're mathematically minded, then the differences in requirements mean that finding the
best match in a Routing Table is an O(N) operation, while finding the best match in a Number
Validation Table is O(log N).
A common example is where you want to route national calls by the area code. The most
obvious approach is probably to have some very large Tables in Routing that list all of the area
codes and route each code to the appropriate trunk. However, this is not efficient. The better
approach is to have the area code lists as Tables in Number Validation. The Entries in the Tables
then set User Defined Attributes (I told you they'd be useful! See Extend the built-in Attributes
using Line Class Codes and User Defined Attributes on page 60 if you want to refresh your memory)
to identify which trunks to use. Trunk Routing then just needs to look at a short list of UDAs to
decide where to route the calls.
Another example is file-based Tables, which are often used for very large Tables. Since it's
best to have your large Tables in Number Validation, the CFS supports file-based Number
Validation Tables (covered in Use file-based Number Validation Tables on page 68) but not file-
based Trunk Routing Tables. Again, this may impact how you and Metaswitch Support design
your translations.
Impact on Trunk Routing Action configuration

In order to support rerouting, Trunk Routing is designed to look for alternative matches if an
Action fails. This results in another couple of differences between Number Validation and Trunk
Routing.
As a reminder, in Number Validation it's a misconfiguration to have two Entries that match
identically and the CFS must find a matching Entry for a call, otherwise the call will fail. (Re-read
Modify, classify and block calls in Number Validation on page 28 if you want a reminder on this.)
In Trunk Routing, on the other hand, it's fine to have two Actions that match identically. The
CFS will simply choose the one with the lower index first. If that Action fails, the CFS will use
the Action with the next higher index. You can also end up with identical Actions with certain
Routing Table types. For example, in a Sequential selection Table the Actions are selected
112 CONFIDENTIAL
simply based on the index value. (We covered the different Routing Table types earlier in Route
a call off the CFS using Trunk Routing on page 95.)
Note: Once you've created a Routing Action, you can't edit the index. If you need to edit lots of
index values, you can export and then re-import the configuration with the updated indices.
If you only need to swap a few Actions then it's easiest just to edit the non-index fields
manually to swap the names and trunks.
It's also fine to have a Routing Table with no matching Actions, unlike in Number Validation.
In this case the CFS will back-track to the previous Table and look for a match there. This will
typically happen if the one matching Action in the Table has already been used but failed.
Suggested Exercises
1. Check your Config Set object to see how many reroutes are permitted on your system.
2. Follow some sample calls through Trunk Routing and check what happens if the initial
routing attempt fails. Are the calls rerouted; if so, where to? Are calls rerouted to the correct
trunks?
3. Create RVTs to test some of the rerouting scenarios by using the Media channel included
to test the effect of some trunks being unavailable. Use the Expected result fields to make
it easy to spot if the call is not rerouted to the correct trunk.
4. Find an existing Action that routes a call to a trunk. Convert this to a choke trunk by setting
AAR allowed and ARR allowed to false. Use an RVT to check that calls that use this
Action will not be rerouted if the trunk is unavailable.
Checkpoint: You now know how rerouting impacts Trunk Routing configuration and how it may
impact the overall design of your translations. We've now covered all of the configuration areas
for translations so it's time to take a step back and consider the ways in which you can edit
translations.
CONFIDENTIAL 113
Follow a call through Trunk Routing

After learning about all the individual pieces of configuration, it's useful to follow an example call
through Trunk Routing so that you can see how it all fits together.
You'll notice that the process we go through is very similar to what we did in Follow a call
through Number Validation on page 42 - that's because Number Validation and Trunk Routing
are very similar.
In this example, I'm going to be following a call to 03069990000 (a UK non-geographic national
number) as it's processed by a system running our standard Trunk Routing configuration for
International deployments. Your system may use this configuration model, but even if it doesn't,
the basic concepts still apply.
Before Trunk Routing

Prior to entering the Trunk Routing tables, the call passes through Number Validation. This
does two important things:
1. The dialed number is normalized to remove the national dialing prefix 0, so the number
going into Trunk Routing is 3069990000.
2. Attributes are assigned to the call. There are many different attributes assigned in Number
Validation, but for this example you only need to be aware that we assign UDA 20 the value
5002.
The standard Trunk Routing configuration

Before we dive into the tables, it's helpful to understand at a high level how the standard Trunk
Routing configuration for International Deployments works. The model is quite simple - we
make two decisions:
• In the first table, we choose a destination table based on the value of UDA20 (assigned in
Number Validation, usually based on number prefix).
• In each destination table, we choose from one or more trunks to that destination, using
either sequential selection or weighted random selection if there is more than one trunk.
Now let's follow a call in detail.
Find the first Table

To start following the call through Trunk Routing, you need to find the starting Trunk Routing
Table. Much like finding the starting Number Validation table, you need to look at the references
under the relevant Config Set object and find the Initial Routing Table reference.
The fastest way to get to the first Table is to click twice on the reference, then MetaView
Explorer will take you to the Table. Remember that the first Table may not be the one at the top
of the list in MetaView Explorer. In our example, it is Table 1000: "Destination Selection".
114 CONFIDENTIAL
Table 1000: "Destination Selection"
Now that you've got to the starting Table, you need to find out what the Table is matching on.
To find this, look at the Routing Table type field:
In this example, the table is matching on Number Validation Attributes. Looking at the
Match Attribute fields below tells us that the table is matching on the value of UDA 20 only -
the other two possible attributes aren't being used.
Find the matching Routing Action

Now that you've identified what the Table is looking for, you need to look at the child Routing
Actions and decide which one is the best match. Here are the Routing Actions in our example.
Before we started, we said that in Number Validation we'd assigned UDA 20 the value 5002
for this call. So, we just need to go through the Routing Actions until we find one that matches
this value.
Let's take a look at Routing Action 3:
Looking at the Attribute values section of the Action, you can see that we're looking for an
Exact match of the UDA 20 value, and that value has to be 5002. This exactly matches the
UDA 20 value of our call, so there's no need to look at any other Routing Actions - this will be
the one we match first.
CONFIDENTIAL 115
Find out what happens next

Finally, find out what will happen next by looking at the Action field. This has been set to Table
lookup, which means that the call will now go to the table specified in the Next table field:
So, we continue by going to Table 5002. Note that the table index is the same as the value of
UDA 20 - while the value of UDA 20 could have been arbitrary, we've designed things so that
the table indexes and UDA 20 values match up, making it easy to tell which destination table
you'll end up in just from the value of UDA 20.
Table 5002: "NonGeoNational"

We've now arrived in our final routing table, which contains one or more trunks to the destination
of the call. We first need to look at the table to see how it will choose an appropriate Routing
Action.
Here the Routing Table Type is set to Weighted Random. That means we'll be picking one
of the routing actions at random, with some actions having a higher probability of being chosen
depending on their weight.
Let's take a look at the actions:
There are two Actions, and as you can probably tell by the names we're going to choose Action
1 60% of the time, and Action 2 the other 40%. This is determined by the Action probability
field on each Action.
On each of Routing Actions 1 and 2, the Action field has the value Routing Complete,
indicating we have reached the end of Trunk Routing! The trunk we are going to use is specified
in the Media channel field.
116 CONFIDENTIAL
Now that we've found our destination trunk, that's the end of Trunk Routing. Of course, if it
turned out that the trunk was busy or unavailable we may have to go back in to reroute it to
an alternative trunk - for example, the Routing Action in table 5002 that we didn't pick in our
random selection. But I don't want to take you round in circles, so let's say in this example that
our call went through successfully!
Suggested Exercises
1. Follow some calls through the Routing Tables in your deployment. Record which Tables
and Entries are used to process the call.
2. Test the calls you followed in Exercise 1 using RVTs - do the results match the path you
followed?
Checkpoint: You've now followed a simple call through Trunk Routing and you can describe
roughly how the International Trunk Routing scheme works.
CONFIDENTIAL 117
Choose how to edit your translations

Most people start editing their translations by making manual changes in the object tree. This
is an excellent way to start but there are other options, especially if you want to make bulk or
programmatic changes. Here we'll look at the pros and cons of the various options so that you
can choose which one(s) work best for you.
The 4 options for editing translations configuration on the CFS, in increasing order of complexity
of initial set up, are as follows.
1. Manual edits in the object tree
2. Importing files using MetaView Explorer
3. File-based Number Validation Tables
4. CORBA programmatic API
Let's look at these options in more detail.
The simplest approach is to make manual edits in the object tree, which is why we use this
method in training classes. It also gives full access to all of the features so many customers
only ever use this approach. If you don't need to edit your translations very often, then this is
probably the best method for you.
Advantages Disadvantages
It's easy. You just need to point and click. It's a manual process so it can be tedious
and error-prone if you frequently make
similar changes.
You can see the configuration in the tree, so It can be difficult to navigate the tree if
it's relatively easy to work out how a call will there's lots of configuration. For example,
be processed. Tables with hundreds of Entries can be slow
to open up.
You get full access to all of the translations If you have multiple users they need to
features and options. coordinate together so that everyone is
editing the same new Config Set.
You can only add or edit one object at

a time. If you want to add a lot of similar
configuration (e.g. lots of Number Validation
Entries) then you have to add each object
individually.
If you want to address the final disadvantage and speed up bulk changes then you can import
files using MetaView Explorer. A lot of the translations configuration (including Route
Verification Tests) can be edited using the import feature. The import feature is not specific to
translations so we won't cover it in any detail in this guide.
Note: For more information on importing configuration see the Exporting and Importing
Configuration Appendix in the MetaView Explorer User's Guide.
Importing configuration from text files is a great way to do bulk additions and in fact Metaswitch
Support use this method when commissioning CFS systems. However, importing configuration
118 CONFIDENTIAL
is fundamentally still editing the object tree directly, so it shares some of the disadvantages of
editing the configuration manually.
It's a very easy way to add a large number The configuration is added as objects in the
of objects quickly. tree. After importing the configuration it can
be difficult to navigate the tree if there's lots
of configuration.
You don't need any programming If you have multiple users they need to
experience. For example, you can create the coordinate together so that everyone is
import files using mail merge (see https:// editing the same new Config Set.
communities.metaswitch.com/docs/DOC-
8545).
You get full access to all of the translations

features and options.
In comparison, file-based Number Validation Tables (covered earlier in Use file-based

Number Validation Tables on page 68) mean that configuration is not stored as objects in the
tree. This method has its own advantages and disadvantages.
You can have much larger Number File-based Entries are not shown in the
Validation Tables - up to 500 000 Entries (as object tree, which may make troubleshooting
of V8.2). harder.
Entries aren't shown in the object tree, so It only applies to Number Validation. This is
it's easy to navigate around the object tree. because you should not have large Tables
in Trunk Routing; we covered this at the end
of Handle trunk failures and rerouting on page
107.
You can update a Number Validation Table Only a limited amount of functionality is
without needing to change the live Config available. In particular, File-based Entries
Set. This makes it easier for multiple people can only match on a number, not on other
to work on the configuration at the same Attributes, and file-based Entries can only do
time. a limited number of things.
You can combine object-based and file-

based Tables in the same Config Set.
The combination of these 3 methods addresses most customer requirements, but there is one
final option - the CORBA programmatic API - that is worth knowing about. This API gives
you programmatic access to all of the objects and options that you see in MetaView Explorer,
which lets you move away from manual updates. The API is documented in the Innovators
section of Communities (https://communities.metaswitch.com/community/innovators/).
CONFIDENTIAL 119
You get full access to all of the translations It's best for changes that you make
features and options. frequently or can be predicted. Infrequent
and one-off changes are probably best
done manually.
You can make some or all of your changes You need a reasonable level of programming
programmatically. This will be faster, less skill!
error-prone and less boring than making the
changes manually.
You can integrate with external systems and

databases.
As you can see, all of the methods have their own advantages and no single method is perfect,
so many customers decide to use a mix of methods. It's also fine to choose to use one method
now and then move to using other methods in the future when you've got more experience.
Checkpoint: You can now decide how you want to edit your translations configuration. We're
now going to change topic completely and take a high-level look at number portability.
120 CONFIDENTIAL
Get ready to discuss Number Portability
Number Portability is where a user can keep their phone number when moving to a different
service provider. If your CFS needs to handle Number Portability (and most CFSs do), then
Metaswitch Support will discuss this with you and implement the appropriate configuration
during the commissioning phase. This chapter gives you the necessary background information
so that you're prepared for any discussions.
Note: Number Portability was introduced to increase competition between service providers
because without number portability you have to change your phone number if you move to
a different service provider, which means people tend to stick with their original provider. In
some countries the telecommunications regulators have made number portability mandatory.
You may also hear people talking about Local Number Portability (LNP). This is where
number portability is supported but only within the same local area. In other words, users
can port their number but only to a service provider covering the same local calling area. This
restriction has the advantage that billing for a call is the same whether the destination number
is ported or not. This is important in areas such as the USA where local calls are typically free.
In a network with number porting, when someone makes a call the network needs a way to
find out where the destination number is currently based, rather than just routing based on the
area code. This has been implemented in different ways in different countries and networks. As
part of the commissioning process we'll discuss your exact requirements with you. This section
will give you some background information that will be useful when you come to discuss
number portability with us.
The CFS supports all of the four most commonly deployed Number Portability mechanisms,
which are summarized in the table below.
Configuration on Configuration on Configuration on

Originating CFS Donor CFS Recipient CFS
All Call Query Use file-based Just delete If necessary, remove

(ACQ) Number Validation subscribers that port porting prefix in Number
to track ported away. Validation when call arrives
subscribers in the from trunk.
network. Make sure the ported
number matches a Lookup
Number Block.
Configure the subscriber
with Number Status =
Ported to.
Onward No special Use file-based As for ACQ.

Routing (OR) configuration Number Validation
(also known as required. to track where
indirect routing) ported-away
subscribers have
gone.
Query on We recommend you As for ACQ. As for ACQ.

Release (QoR) implement this as for
ACQ.
CONFIDENTIAL 121
Configuration on Configuration on Configuration on

Originating CFS Donor CFS Recipient CFS
Return to No special Use file-based As for ACQ.

Pivot (also configuration Number Validation
known as Call required but the CFS to track where
Dropback) needs to handle the ported-away
reroute information subscribers have
in the Release. gone.
There 3 types of network (also known as service providers or operators) that are involved in
handling ported numbers:
• Originating - the operator hosting the caller who is making a call to a number that may
have been ported.
• Donor - the operator that originally owned the number held by a subscriber who has
ported that number to another operator.
• Recipient - the operator now providing service to the ported subscriber.
Keeping these network definitions in mind, let's look at the four Number Portability methods
in more detail.
All Call Query (ACQ)
In ACQ, the originating operator checks a centralized database for all calls to get the details of
the current service provider.
Note: In NANP deployments with Local Number Portability, the originating operator does not do the
portability query for long-distance calls. Instead the query is done when the call reaches the
local network for the destination number.
The originating operator then routes the call to the recipient network. The CFS supports 3
mechanisms for accessing a portability database.
• TCAP queries - typically carried over the SS7 network. TCAP queries are mostly used in
NANP deployments so are not covered in this guide.
• SIP to a redirect server - this is invisible to translations. Trunk Routing simply routes calls
to a SIP trunk which goes to the redirect server.
• A local copy of the number portability database - usually implemented using File-
Based Number Validation Tables (see Use file-based Number Validation Tables on page 68 for
more information).
The simplest way to implement ACQ is for the Originating CFS to have file-based Number
Validation Tables listing the ported numbers. After finding the destination number in one of
these Tables, the CFS will route the call using one of the following methods.
• Concatenated addressing with a routing prefix.
• Explicit addressing with a network-number.
• Transit Network Selection.
• Location Routing Number of the destination exchange (North America).
• Dedicated trunks for ported traffic.
The Donor CFS does not need any special configuration to support portability; simply delete a
subscriber if they port away. Remember not to re-use the phone number though!
122 CONFIDENTIAL
On the Recipient CFS you need to make sure that there is an On-Switch Lookup Number Block
that will match the ported subscriber's number. The subscriber object itself must be configured
with a Number Status of Ported to, so that the CFS knows that the phone number will not be
in a configured Number Range. (We covered Lookup Number Blocks, Number Ranges and the
Number Status field earlier in Look for the called number on the CFS in On-Switch Lookups on page
73.) Finally, depending on how the call is routed, the Recipient CFS may also need to remove
a routing prefix when the call arrives in Number Validation from a trunk.
Onward Routing (OR)
In Onward Routing, the originating operator sends the call to the donor operator. If necessary
the donor operator reroutes the call to the recipient operator. This doesn't need a co-ordinated
database, but will result in multiple onward routings if a number is ported more than once. In
this situation, the Originating CFS requires no special porting configuration since it is unaware
if a destination number has been ported and just sends the call to the donor operator.
The Donor CFS needs a local database listing which numbers have been ported and where
they've gone. This is done using file-based Number Validation Tables. The call can then be
routed from the Donor CFS to the recipient operator using any of the methods listed above for
ACQ and the Number Validation configuration on the Recipient CFS is the same as for ACQ
(remove any routing prefix).
Query on Release (QoR)
In QoR, the originating operator checks all calls with the donor operator. If the donor operator
says that it no longer possesses the number, the originating operator checks with a centralized
database, as in ACQ. If most numbers are unported then this method results in fewer database
queries than ACQ. However, if you use an on-switch database on the Originating CFS (by using
file-based Number Validation Tables) it makes more sense for the Originating CFS to query all
calls, since this avoids unnecessarily routing ported calls to the donor network.
For QoR the configuration on the Donor CFS is the same as for Onward Routing (use file-based
Number Validation to keep track of subscribers that have ported away) and the configuration
on the Recipient CFS is the same as for ACQ (remove any routing prefix).
Return to Pivot
In Return to Pivot, the originating operator checks all calls with the donor operator. The donor
operator responds with the route to the recipient operator. The originating operator then routes
the call to the recipient operator. Like Onward Routing this avoids needing a co-ordinated
database, but can result in multiple onward routings. This method is rarely used.
With Return to Pivot the Originating CFS does not have a database of ported subscribers; it
just handles the reroute after getting the response from the donor. The configuration on the
Donor CFS is similar to that for Onward Routing (use file-based Number Validation to keep
track of subscribers that have ported away) while the configuration on the Recipient CFS is the
same as for ACQ (remove any routing prefix).
Checkpoint: You now know the options on the CFS for supporting number portability, so that
you can discuss with Metaswitch Support how number portability should be implemented for
your specific deployment. Now let's finish learning about the configuration by considering long
distance call services.
CONFIDENTIAL 123
Get started with long distance call services and the associated terminology
Get started with long distance call services and the

associated terminology
The call services we're going to cover in this section are typically applied to long distance calls.
Unlike other CFS call services, the CFS can provide long distance services both to subscribers
managed by the CFS and to subscribers managed by other switches, if the other switches
route the subscriber's long distance traffic to the CFS. Before we look at long distance services
in detail, we're going to start by looking at some terminology because it's easy to get confused
in this area. For some reason a lot of the terminology starts with the letter A, so we're doing the
start of the alphabet at the end of this guide!
Firstly, we sometimes refer explicitly to
two types of subscriber to avoid confusion Did you know? It's well known that
when we're dealing with long distance call Alexander Graham Bell made the first ever
services. On-switch or local subscribers phone call in 1876, to his colleague Thomas
are the subscribers managed directly by
A. Watson. It's less well known that they also
the CFS and are configured as Individual
Lines, Business Group Lines etc. Long made the first ever transcontinental phone
distance subscribers are those which call. In 1915 Dr. Bell in New York phoned Mr.
are managed by remote switches but send Watson in San Francisco. It took 5 operators
their long distance traffic to the CFS to get and 23 minutes to connect the call.
their long distance call services.
Secondly, you may hear the long distance services called Class 4 services. This is because
these services are typically provided by a Class 4 switch (also known as a tandem switch). A
pure Class 4 switch has no direct connections to subscribers. The CFS can be configured as a
pure Class 4 switch, but it can provide these services to on-switch subscribers when the CFS
is providing Class 5 functionality, so I try to avoid using this terminology.
Now you know the terminology, let's look at the services. The CFS supports 2 long distance
call services in all regions (as of V8.2) - ANI Screening and Authorization codes.
ANI Screening is the simpler service to understand so let's start there. In the ANI Screening
service the CFS checks the ANI of the caller and blocks or permits the call as appropriate.
The configuration on the CFS therefore consists mostly of lists of permitted and blocked
numbers. We'll cover the configuration properly in the next chapter, Maintain and understand
the configuration for ANI Screening on page 124.
Note: ANI stands for Automatic Number Identification. It's a feature of the network that allows
a phone number that identifies the caller to be passed through the network. This number is
usually the billing number. This number is separate from the caller ID, which is the number
that may be displayed on the called phone. Even if the caller withholds their caller ID, their
ANI (billing number) will be passed through the network so that it can be used for features
such as ANI Screening.
If the call is permitted then it will go into Trunk Routing and will be routed as required. From a
subscriber's perspective, when they make a long-distance call their call will either work (because
it was permitted and routed off the CFS) or the call will be blocked with an announcement. The
subscriber can only invoke the ANI Screening service if they call from their own phone because
the call needs to arrive at the CFS with their phone number as the calling number.
Authorization codes on the other hand require more interaction from the caller. The caller first
dials a number to access the long distance service provider. For example, this number may
be a special toll-free number that's routed to a long distance carrier such as AT&T in the US.
The CFS recognizes the special called number and asks the caller to enter a valid authorization
code. The caller may also need to enter a PIN. If the authorization code (and PIN if required) is
accepted then the caller can dial the phone number that they wish to call.
124 CONFIDENTIAL
Get started with long distance call services and the associated terminology
This service is typically used to let subscribers make long distance calls that are billed to a
particular carrier, regardless of which phone they call from. For example, a business woman
can call a freephone number from a hotel phone, then enter her authorization code and PIN
and then call an international number as the final destination. This avoids paying hotel rates for
international calls, which are typically high. The carrier may provide a small card with the details
of the Freephone number and the authorization code so that users can carry it in their wallet for
easy reference. As a result, the authorization code service is also known as the calling card
service.
The configuration for Authorization codes consists mostly of a list of acceptable codes, with
the associated PIN if required. We'll cover the configuration in more detail later in Maintain and
understand the configuration for Authorization codes on page 124.
Note: Authorization and Account codes (also known as Mandatory Account Codes) sound very
similar but are different services. As discussed, with Authorization codes the caller needs to
dial the initial access number, then the authorization code (plus potentially a PIN) and finally
the number that they want to call. With Account codes, the caller starts by dialing the number
they want to call and then, depending on the type of call, they have to dial an account code.
See the Mandatory Account Codes section (under Outgoing Call Services) in the MetaSphere
CFS and Metaswitch AGC Call Services Manual for more information on account codes.
Finally, note that the CFS does not store any financial information on subscribers, so neither
long distance service can check to see if the caller has sufficient funds to make the call. If you
want to screen the call based on financial information then you will need to configure Trunk
Routing to route the call to an off-switch platform which performs the check.
Before we look at the individual services in more detail, there's one final important point to
cover. You need to make sure the long distance call services are turned on before you can use
them! This is controlled by the Long Distance Service support field.
Checkpoint: You now know which long distance services are supported on the CFS and what
they do from a subscriber's perspective.
• If you won't be deploying these services and you don't want to know about them, you can
skip ahead to Celebrate - you’ve finished! on page 135.
• If you want to deploy these services then keep your coffee cup topped up and move on to
the next chapters - Maintain and understand the configuration for ANI Screening on page 124
and Maintain and understand the configuration for Authorization codes on page 124!
CONFIDENTIAL 125
Maintain and understand the configuration for ANI Screening

In this chapter you'll learn how to maintain the ANI Screening lists. You'll also take a look at
the Number Validation configuration required to support ANI Screening. Typically, Metaswitch
Support will set up the Number Validation side of things during commissioning and then the
service provider is responsible for maintaining the list of permitted and/or blocked ANI numbers.
So, first let's consider the ANI Screening lists.
Manage your ANI Screening number lists

The ANI Screening lists are simple to configure. The configuration is in the Long Distance
Service Configuration section under the CFS.
Each ANI Screening Table contains a list of ANI Screening Entries where each Entry defines
the ANI number that it matches and whether the number is Allowed or Denied. You can have
multiple ANI Screening Tables because, for example, you may have different sets of long
distance subscribers on different trunks.
Now let's look at the ANI Screening Table object in more detail.
As well as defining a name for the Table, you need to set a Default locale that will be used
for the child ANI Screening Entries. This is the language that will be used for announcements.
Use the Default second locale field if you want bilingual announcements. These values can
be overridden on a per-Entry basis. You can only use languages that have been installed on
your system, so please talk to Metaswitch Support if you need a language that isn't listed on
the CFS.
126 CONFIDENTIAL
The ANI Screening Table also defines whether the child Entries will have a fixed length. This lets
the CFS check that any configured ANI Screening Entries are defined with the correct length.
When you add a child Entry, the key two fields are the ANI, which defines which number this
Entry matches, and the Entry type, which defines whether the caller is Allowed or Denied.
Setting the Entry type to Allowed or Denied does not actually permit or block the call
immediately. Instead the call is passed back into Number Validation with an Allowed or Denied
flag. Number Validation then decides how to handle the call. You may decide that you want
to block Denied callers, but you could also decide to route them via different trunks, bill them
differently etc.
Since ANI Screening Entries can be Allowed or Denied, you can choose whether to use a
white list or black list approach. With a white list all calls are blocked unless they match an ANI
Screening Entry while with a blacklist all calls are permitted unless the caller matches an ANI
Screening Entry. There's no difference in functionality between the approaches - just use the
one that's easiest to configure for your particular deployment!
To make the configuration even easier, the ANI field can either be an explicit complete match,
or it can be a prefix match. To configure a prefix match set the ANI field to the digits (including
A-D) that you want to match, followed by enough Xs to match numbers of the correct length.
This lets you simplify your configuration by defining blocks of numbers that are allowed or
denied, rather than having to define each ANI Screening number individually.
Looking at the rest of the ANI Screening Entry object, you can define other properties for
the ANI. In effect this is a type of subscriber, so you can configure the key properties that
you can configure for on-switch subscribers. So, you can suspend their service (typically
for non-payment), set Number Validation and Routing attributes and define the locale for
announcements. The other key subscriber properties used in Number Validation and Routing
are the Line Class Codes, which are set via a Long Distance Service Class object.
Note: We covered Line Class Codes earlier in Extend the built-in Attributes using Line Class Codes and
User Defined Attributes on page 60.
CONFIDENTIAL 127
Checkpoint: You now know how to add and configure ANI Screening Entries in an ANI
Screening Table. Now you need to learn how Number Validation invokes and handles ANI
Screening when processing a call.
Understand the ANI Screening configuration in Number Validation

Typically, Metaswitch Support will configure Number Validation to do ANI Screening as part of
the commissioning process, so you don't need to do this. However, you still need to understand
how the configuration works, in case you need to troubleshoot it. Here we'll look at how ANI
Screening is configured in Number Validation.
The ANI Screening configuration in Number Validation does two things.
1. Tell the CFS when to do ANI Screening. The CFS will then compare the ANI with the
Screening Entry lists managed by the service provider.
2. Tell the CFS what to do after ANI Screening.
Taking these in order, we first need to identify the calls that require ANI Screening. This is often
based on the incoming trunk for tandem calls, but you can use any of the Number Validation
Table match types to isolate the calls that need ANI Screening and add the ANI Screening
lookup Attribute. You need to change the ANI Screening lookup type field from the default
of None to Lookup in specific table and set the ANI Screening lookup table field to point
to the ANI Screening list for this type of call. (The Lookup on carrier code option is typically
only used in North America and means that the CFS will always use the ANI Screening Table
with index 1.)
Note: Originally ANI Screening (and some other features) were only supported in North American
deployments and the fields were named to reflect this, such as the ANI Screening lookup
(North America only) Attribute. The restriction has now been removed but, to maintain
backwards compatibility, the field names were not always changed. Don't worry - this feature
is now supported in all regions!
If the ANI Screening lookup Attribute is present when a call completes Number Validation,
then the CFS will compare the call against the appropriate ANI Screening Table and record
whether the ANI is allowed or denied in the ANI Screening Entry Attribute. Note that a denied
call will not be blocked at this point. After checking the ANI Screening Table, the call will be
passed back into Number Validation for further processing. This time the call will start at the
Post ANI Screening lookup Table defined on the Config Set.
128 CONFIDENTIAL
This Post ANI Screening lookup Table then needs to match on the ANI Screening Entry, to see
whether the call is allowed or denied. The Next action then defines what to do with the call.
Typically you will accept allowed calls by completing validation or passing to another Number
Validation Table. An example of this is shown below.
Obviously this is a very simple example where no additional processing is required after ANI
Screening. Depending on your deployment you may need to pass the call to another Number
Validation Table, for example to do processing based on the Line Class Codes applied by the
Screening Entry.
CONFIDENTIAL 129
Similarly your configuration will typically reject denied calls. In this situation you need to decide
what announcement you want to play to callers. If you set the Next action field to Fail ANI
Screening then they will get an announcement saying that the carrier code is not valid. If
you set the Next action field to Reject and announce then they will hear a generic failure
announcement or tone. An example of this is shown below.
Note: By default you cannot modify Attributes after doing the ANI Screening lookup. This can be
modified by Metaswitch Support so it's something we'll discuss with you during the design
and commissioning stage.
Note also that this example Entry is set up to catch any ANI Screening Entry value, including
no ANI Screening Entry set. This is cautious design to ensure that only calls that have been
Allowed by ANI Screening are permitted and any other types of call going through this Table
are rejected.
Checkpoint: You now know how to maintain your ANI Screening lists and you have a reasonable
idea of what the Number Validation configuration associated with ANI Screening looks like.
That's all you need to know about ANI Screening, so now we'll take a look at the other long
distance service - Authorization codes.
130 CONFIDENTIAL
Maintain and understand the configuration for Authorization codes
Maintain and understand the configuration for Authorization
codes
In this chapter you'll learn how to maintain the Authorization code lists. You'll also learn
about the Number Validation configuration required to support Authorization codes. Typically
Metaswitch Support will set up the Number Validation side of things during commissioning and
then the service provider is responsible for maintaining the list of Authorization codes and any
associated PINs. So, first let's consider the Authorization code lists.
Manage your Authorization code lists

Like the ANI Screening lists, the Authorization code lists are configured in the Long Distance
Service Configuration section under the CFS.
Each Authorization Code Table contains a list of permitted Authorization Codes. Each Code
object defines a particular Code and the associated call properties if a call uses that Code.
You can have multiple Authorization Code Tables because you may want to support different
Codes for different types of calls. All Codes in a Table also need to be the same length, so you
will need multiple Tables if you want to use Codes with different lengths.
Now let's look at the Authorization Code Table object in more detail.
CONFIDENTIAL 131
Most of the fields control which announcements or tones to play at the various points in the call
where the CFS needs to ask the caller for input. You can also define the Second locale field if
you want bilingual announcements.
Looking at a child Code object, the key fields are for the actual authorization code and for the
PIN (if it's required by the parent Table). Here's an example of an Authorization Code with a PIN.
The Code is also linked to a Long Distance Service Class, which lets you associate Line Class
Codes with the call. This is the same as for an ANI Screening Entry object (see Maintain and
understand the configuration for ANI Screening on page 124) so I won't cover it again here.
If there's a PIN associated with the Code then the Code will be blocked if a caller tries to enter
the wrong PIN too many times. The limit is controlled by the Maximum incorrect attempts
field on the parent Authorization Code Table. Normally the Service blocked field is read-only
but if the limit is exceeded and the Code is blocked then the field will be changed to an editable
field so that you can change it back to False to unblock the Code.
Checkpoint: You now know how to add and configure Authorization Codes in an Authorization
Code Table. Now you need to learn how Number Validation invokes and handles Authorization
codes when processing a call.
Understand the Authorization Code configuration in Number Validation

Typically Metaswitch Support will configure Number Validation to handle Authorization Codes
as part of the commissioning process, so you don't need to do this. However, you still need to
understand how the configuration works, in case you need to troubleshoot it. Here we'll look at
how Authorization Codes are implemented and configured in Number Validation.
The Authorization Code configuration in Number Validation does two things.
1. Tell the CFS when to gather the Authorization Codes (and PIN if required). The CFS will
collect the Code (and PIN) and compare it with the Authorization Code lists managed by
the service provider.
2. Tell the CFS what to do after collecting a valid Code (and PIN if required).
Let's look at these in turn.
Firstly your Number Validation configuration needs to identify the calls where the CFS should
ask for an Authorization codes. This service is typically offered as a calling card service so your
Number Validation will probably be configured to recognize the specific destination numbers.
132 CONFIDENTIAL
When you have identified the relevant calls, you must then add the Authorization Code
Service Attribute. When Number Validation completes, the CFS will then ask the caller for the
code and PIN. In the example below, Number Validation processing will complete immediately,
but this is not a requirement. You can add the Attribute to several tables before completing
validation if that is easier to configure.
Now let's look at the Authorization Code Service Attribute in more detail, as shown in
the example below. The key parameter is the Authorization Code Operation field, which
determines how the switch should get the code. To implement a standard Authorization Code
service where the CFS asks the caller to enter a code, this field will be set to On-Switch
Calling Card / Hotline. The CFS will ask the caller for a code and will then use the specified
Authorization Code list to validate the code (and PIN).
Once the CFS has collected and checked the code (and PIN), the CFS will then play an
announcement to ask the caller to enter the number they wish to call. The Authorization Code
Table, which we covered earlier, controls which prompts are played. Once the caller has dialed
the number, the call needs to come back into Number Validation for processing, effectively as
a new call to the new destination number. The entry Table for this second round of Number
Validation is defined by the Number Validation Table - post Authorization Code Table field
on the Config Set, as shown in the example below.
CONFIDENTIAL 133
The behaviour at this point depends on your deployment. You may consider this to be a call
from a subscriber and put it through similar (or even the same) Tables as a call directly from an
on-switch subscriber. On the other hand, you may want to do just minimal digit checking in
Number Validation and then route the call directly to the network.
Checkpoint: You now know how to maintain your Authorization Code lists and you have a
reasonable idea of what the Number Validation configuration associated with Authorization
Codes looks like. That's all you need to know about Authorization Codes, which means you're
ready for a quick conclusion and then you've finished this guide!
134 CONFIDENTIAL
Celebrate - you've finished!
Celebrate - you've finished!
You've now completed this Learn How To guide and you're ready to start managing your CFS
Translations. Before you leave, here's a quick recap of the key things that you've learned…
• There are 4 stages in CFS translations.
• Digit Maps
• Number Validation
• On Switch Lookups
• Trunk Routing
• Digit Maps and On-Switch Lookups are simple to configure.
• The Number Validation and Trunk Routing configuration are more complicated to configure.
They are both based on flowcharts.
• Do as much processing as possible in Number Validation and keep Trunk Routing as simple
as possible.
• If there's a name field, use it and use it wisely.
• Test, test and test again. Build up a test suite of Route Verification Tests so you can quickly
check that everything is working as expected.
• The translations configuration can seem overwhelming but we will provide you with a base
configuration that gives you a lot of the necessary functionality.
And finally - Don't Panic! Metaswitch Communities, Support and Professional Services are all
here to help you make a success of your translations!
CONFIDENTIAL 135
Glossary
Glossary
Translations are particularly rich with acronyms and specialist jargon and you won't be the first
person to complain that they don't understand it! This final chapter provides a quick reference
to the terminology used in this guide and in the translations configuration.
If there is anything that you still don't know after looking here, make a suggestion to Metaswitch
to include it in the next version of the guide and then go and look it up!
Abbreviations
There are expanded definitions for most of these abbreviations in the following Terminology
section.
AAR Automatic Alternative Routing
ACQ All Call Query
ANI Automatic Number Identification
ARR Automatic Re-Routing
C4 Class 4
C5 Class 5
CFS Metaswitch Call Feature Server
ETSI European Telecommunications Standards Institute
FB NV File-based Number Validation
LCC Line Class Code
LNP Local Number Portability
LRN Location Routing Number
NANP North American Numbering Plan
NANPA North American Numbering Plan Administration
NV Number Validation
OR Onward Routing
QoR Query on Release
SAC Service Access Code
SAS Service Assurance Server
UDA User Defined Attributes
UK United Kingdom
UMG Universal Media Gateway
US United States. Shortened version of United States of America
RVT Route Verification Test
Terminology
7 Steps: A simple list showing how a call is processed on the CFS.
All Call Query (ACQ): An implementation of Number Portability.
136 CONFIDENTIAL
Glossary
ANI Screening service: A call service that permits or blocks calls based on the caller's
number. ANI Screening is a long distance service.
Attribute: A property of a call, such as which trunk it came from. Attributes are added when a
call arrives and in Number Validation.
Attribute Set: A group of attributes. In Number Validation attributes are applied to a call by
applying an Attribute Set.
Authorization code service: A call service where the call has to enter an authorization code
(and potentially a PIN) before they can dial their final destination number. This is also known as
a calling card service. Authorization codes are a long distance service.
Automatic Alternative Routing (AAR): A feature that allows the CFS to reroute a call if it
decides the initial trunk was not suitable, before the call was routed off the switch. Compare
with Automatic Re-Routing.
Automatic Number Identification (ANI). A network feature that lets a phone number that
identifies the caller be passed through the network. It's typically used to mean the caller's
phone number.
Automatic Re-Routing: A feature that allows the CFS to reroute a call if the call is rejected
after it has been routed off the switch. Compare with Automatic Alternative Routing.
Base configuration: The initial translations configuration that Metaswitch Support provides
for your CFS. This will either be the NANP version or the International version.
Called address complete: An Attribute that indicates that the CFS has received all of the
digits for the destination number. This Attribute is important when dealing with overlap signaling.
Carrier ID: A unique code used to identify a carrier. Typically used in NANP deployments.
Class 4: A telecoms switch that has no directly associated subscribers.
Class 5: A telecoms switch that has directly associated subscribers.
Complete match Table: A type of Number Validation Table that looks at all of a number, both
the contents and the length.
Config Set: The high-level object that contains almost all of the configuration you need to
define your translations.
CORBA API: The CORBA API is used between the MetaView Explorer and the MetaView
Server. The details of the CORBA API are published on the Innovators section of Communities,
so that you can use it as a programmatic API.
Digit Maps: The translations component that collects the dialed digits from a subscriber.
Destination: Another name for the terminating or called number or address.
E.164: A number format standard for the telephone network developed by the ITU-T.
Enbloc signaling: In enbloc signaling the entire destination number is signaled in a single
message. Compare with overlap signaling.
European Telecommunications Standards Institute (ETSI): An organization that produces
globally-applicable standards for telecoms (and other technologies). ETSI plays a similar role
to Telcordia in the US.
Expected result: You can set Expected result fields on a Route Verification Test. If the test
result does not match the Expected result then the test object will alarm in the object tree.
File based Number Validation: A Number Validation feature that lets you define large Tables
as text files, rather than as MetaView Explorer objects.
Freephone: It's free to call a Freephone number. Also known as a toll-free number.
CONFIDENTIAL 137
Glossary
Import: A MetaView Explorer feature that lets you upload plain text files to create configuration.
International base configuration: (Also known as the International scheme.) A generic,
easy-to-customize, initial translations configuration that Metaswitch Support will put on your
CFS if you're not part of the NANP scheme.
International Telecommunication Union (ITU): A United Nations agency that develops
global standards for information and communication technologies.
ITU-T: The division of the ITU that deals with telecommunications.
Line Class Code (LCC): A special type of customizable Attribute that's used to define per-
subscriber features.
Live Config Set: The Config Set that is currently carrying all of your traffic. Also known as the
in-use Config Set.
Local Number Portability: Number portability but only within the local calling area.
Local subscriber: Another name for an on-switch subscriber.
Locale: The language used for announcements.
Location Routing Number (LRN): In some forms of Number Portability, each switch is
identified by a unique phone number, known as its Location Routing Number.
Long distance services: A group of call services that are typically applied to long distance
calls. These services include ANI Screening and Authorization codes.
Long distance subscriber: A subscriber who uses the long distance call services on the
CFS. The subscriber may or may not be managed directly by the CFS, but their long-distance
calls are routed via the CFS. Compare with on-switch subscriber.
Media Channel: Another name for Trunk or Trunk Group.
Metaswitch Universal Media Gateway (UMG): A device that handles interconnects
between legacy signaling protocols and TDM media to IP signaling and media. It also provides
media service function, for example to play announcements.
NANP base configuration: (Also known as the NANP scheme.) The initial translations
configuration that Metaswitch Support will put on your CFS if you're part of the NANP scheme.
North American Numbering Plan: A telephone numbering scheme that's used in several
countries and territories, mostly in North America. We have a separate standard base
configuration for use in NANP deployments which is optimized for their numbering plan
requirements. People sometimes use NANP and NANPA interchangeably.
North American Numbering Plan Administration: The organization that is responsible for
organizing the NANP numbering resources. NANPA, i.e. the organization, is often used when
people really mean NANP, i.e. the numbering plan itself.
Number Block: The object in On Switch Lookups which defines a block of numbers that may
reside on the CFS.
Number Portability: The ability to keep your phone number if you move your service to a
different service provider.
Number Range: An object used in the subscriber configuration area for number space
management. Do not confuse this with Number Blocks.
Number Validation: The translations component responsible for classifying calls. It also has
the main responsibility for modifying calls and rejecting bad calls.
On Switch Lookups (On Switch and LNP Lookups on NANP systems): The translations
component that's responsible for looking for the called number in the CFS subscriber database.
138 CONFIDENTIAL
Glossary
On-switch subscriber: A subscriber that is managed directly by the CFS. All calls from on-
switch subscribers are initially handled by the CFS. Compare with a long-distance subscriber.
Onward Routing (OR): An implementation of Number Portability.
Optional attributes: Attributes that can be added in Trunk Routing.
Overlap signaling: Also known as overlap addressing. In overlap signaling the destination
number may be sent spread over several signaling messages.
Overriding Config Set: The Override Config Set feature lets you put real phone calls through a
non-live Config Set. This is used for testing purposes. It's configured by setting the Overriding
Config Set field on a subscriber, for calls from subscribers, or Call Trace object, for calls from
trunks.
Prefix match Table: A type of Number Validation Table that only looks at the start of a number.
Compare with Complete match Table.
Query on Release (QoR): An implementation of Number Portability.
Return to Pivot: An implementation of Number Portability.
Route Verification Test: A MetaView Explorer object that lets you send a test call into the
translations configuration and check that the call is handled as expected.
Scope: The area over which a number is unique. For example, a national scope number
includes the area code but not the country code.
Service Access Code (SAC): A special phone number used to invoke a call service.
Service Assurance Server: A MetaView component that automatically collects detailed call
traces for all calls passing through Metaswitch components.
Source: Another name for the originating or calling number or address.
Subscriber Group: A MetaView Explorer object used to link subscribers to the Digit Map
for those subscribers. On older systems it may also be used to distinguish different groups of
subscribers in translations.
Telcordia: A research and development company based in the US and currently owned by
Ericsson. It defines many telecommunication standards for the US. Telcordia plays a similar role
to ETSI in the other regions.
Trunk: Also known as a Media Channel or Trunk Group. This is a protocol-independent name
for the connection that carries a call between systems.
Trunk Routing: The translations component that chooses the trunk for outgoing calls to other
switches.
Unique match Table: A rare type of Number Validation Table that looks for a number between
two lengths.
User Defined Attribute (UDA): A special type of customizable Attribute.
CONFIDENTIAL 139
Tell us what you think!
Metaswitch is interested to know what you think about this Learn How To Guide. If
you have any feedback, or you spot any inconsistencies while using it, please don’t
hesitate to contact us.
You can send any general comments or report any specific issues to:
LHTfeedback@metaswitch.com.
Thanks for your time on this; your support will help us to make these guides better
and even more useful for you!
CONFIDENTIAL

Learn How To Manage Your Cfs Translations

Uploaded by

Copyright:

Available Formats

You might also like

Learn How To Manage Your Cfs Translations

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Learn How To Manage Your Cfs Translations

Uploaded by

Copyright:

Available Formats

LEARN HOW TO

MANAGE YOUR CFS

This manual is issued on a controlled basis to a specific person on the

Metaswitch and the Metaswitch logo are trademarks of Metaswitch Networks.

Learn How To Page

Get to grips with the guide...................................................................................................7

What are "translations"?.......................................................................................................8

Identify your base configuration..........................................................................................10

Manage your translations using Config Sets.......................................................................11

Look inside a Config Set.....................................................................................................19

Fit translations into the 7 steps...........................................................................................21

Collect digits using Digit Maps............................................................................................23

Modify, classify and block calls in Number Validation..........................................................28

Use search selection fields to set values easily in translations.............................................41

Follow a call through Number Validation.............................................................................42

Record call properties using Attributes...............................................................................53

Get ready to discuss overlap signaling................................................................................64

Use file-based Number Validation Tables............................................................................68

Look for the called number on the CFS in On-Switch Lookups...........................................73

Decide how to test your translations...................................................................................77

Do live testing using Override Config Sets..........................................................................78

Get diagnostics for a call using the Service Assurance Server............................................90

Learn How To Page

Route a call off the CFS using Trunk Routing......................................................................95

Handle trunk failures and rerouting...................................................................................107

Follow a call through Trunk Routing..................................................................................114

Choose how to edit your translations................................................................................118

Get ready to discuss Number Portability...........................................................................121

Maintain and understand the configuration for ANI Screening...........................................126

Maintain and understand the configuration for Authorization codes..................................131

Celebrate - you've finished!..............................................................................................135

Will I be an expert at the end?

What are "translations"?

Did you know? "DON’T PANIC" is a quote from the

Get help with translations

5. Click on Receive email notifications in the Actions box on the left.

Get even more help

Identify your base configuration

Recognize the different Config Set states

Use Config Sets

The second key point is:

Reduce the load on the CFS

Create a new Config Set, step-by-step

First, here's an overview of the process.

Step 1: Clone the existing live Config Set

Step 2: Name the new Config Set

Checkpoint: You've completed all of your edits.

• Select your new Config Set from the list.

Step 7: Disable the old Config Set

Stage 1 in a call - Digit Maps

Stage 2 in a call - Number Validation

Stage 3 in a call - On-Switch Lookups

Stage 4 in a call - Trunk Routing

Understand the notation used for Digit Maps

() Digit Maps start and end with round brackets.

| The vertical pipe separates valid entries in the Digit Map.

X X is a wildcard that matches any digit 0-9.

* # These represent the * and # keys on a keypad.

* and # The * and # on the 55 matches 55