Configuring traffic processing rules takes real expertise: the same logic can be built several different ways, and configurations quietly accumulate duplicate or outdated rules over time. This article covers a different problem – not what’s unused, but what’s misconfigured or duplicated. It’s about the traffic-rules-configurator skill.
Note: This is part four of JeraSoft’s series on AI agents in telecom operations. Read part one: How JeraSoft enables billing platform to be AI ready, part two: MCP, skills and AI agents in telecom billing operations, and part three: AI skills in telecom billing: less time investigating, more time operating.
What is a Traffic Processing rule, in plain terms?
Every billing platform needs a way to decide what happens to a call, message, event, token – before, during, or after it’s rated and routed: rewrite a number, strip a prefix, dip a portability database, block a specific vendor for a specific client. In JeraSoft, all of this is expressed through Traffic Processing (TP) rules.
A TP rule bundles three kinds of decisions: when it fires (Stage), what it applies to (Origin, Src/Dst Match, equipment, client, tags, time profile, and a dozen other filters you can combine), and what it does once matched – rules can stack multiple actions. Get the combination wrong, and the rule can end up matching different traffic than you intended, or not firing at all.
The real cost of manual configuration
Traffic Processing rules are one of the most powerful parts of the platform. A single rule can rewrite a number, dip a portability database, block one client from one vendor, or reshape how a whole class of traffic gets routed and rules can be layered to handle cases a simpler system couldn’t. That power is exactly why the configuration surface is broad: multiple stages, a long list of match filters, and actions that behave differently depending on where in the pipeline they run.
None of that is a design flaw – a tool this capable is supposed to have real depth, the same way a flight console has more controls than a car dashboard. But it does mean two engineers can build the “same” rule differently, and neither may be fully sure whether an existing rule already covers a new case. Most people learn the model by finding something similar and adapting it, which works fine until a case falls outside what they’ve already seen.
That’s exactly the kind of expertise a skill is built to carry, so your team doesn’t have to hold the whole model in their heads to configure a rule correctly.
Skill: traffic-rules-configurator – “which Stage do I need for this?”
The situation
That expertise gap shows up in two kinds of requests. The first is building something new: a number rewrite, a portability dip, a routing block, where the right combination of Stage, Origin, and match type isn’t obvious unless you’ve built dozens of these before. The second is auditing what already exists: dozens of TP rules accumulated over years, some of them possibly redundant, with no fast way to tell without reading each rule’s match conditions line by line.
What happens today
Getting a rule right today depends on an engineer holding the whole model in their head: which rule type fires at the right point, which leg it applies to, whether a regex match or a prefix list is the right tool, and – for portability – which gateway and party ID to dip. That’s exactly the kind of judgment call experienced engineers make quickly and newer ones second-guess, often by hunting for a similar rule to copy rather than reasoning through the combination from scratch.
Auditing what already exists is the same problem in reverse. Someone has to open each rule, read its match conditions and priority order, and work out by hand whether two rules can be safely merged without changing what traffic they catch – which is rarely done proactively when there are dozens of rules per origin.
What the skill does
On the design side, you describe the intent in plain language, and the skill maps it to the correct configuration.
“I want to rewrite the calling number before rating, for a client using DID prefix 1201.”
“That’s an after-client rule – it needs to run after the client is identified, but before rating. Use a Parties ID Translation on src_party_id, matched by that client’s prefix.”
“Which Stage do I need if this rule should only fire after a route has already been picked, so I can block one client from one specific vendor?”
“That’s after-routing. Use a Routing Block, not a translation – rules at this stage can allow, deny, or block a client/account from the selected route, but they can no longer rewrite numbers.”
On the audit side, you ask a direct question, and the skill checks match conditions across the rule set instead of you reading each one by hand.
“I have 34 TP rules on origination – are any of these redundant?”
“Rules #114 and #119 both run after-client, on origination, and match the same destination prefix range. #119 additionally excludes three prefixes that #114 also excludes elsewhere in the rule set. These can likely be merged into one rule without changing which traffic is matched.”
What it doesn’t do
The skill drafts a configuration or a merge proposal for review – it doesn’t create or update rules on its own. It doesn’t decide business intent either: it can tell you how to express “block this client from this vendor” correctly, not whether you should. And it isn’t a substitute for the other two skills in this area – for diagnosing why a specific call was routed to an unexpected vendor, or why a specific rule fired during routing, use jera-routing-analyzer; for finding TP rules tied to clients that no longer exist, use jera-usage-audit.
Why this matters
A rule that’s technically active but subtly off from what was intended doesn’t announce itself – it just doesn’t do quite what you meant, until someone traces a billing or routing anomaly back to it. That’s the cost of not having the expertise on hand at configuration time, not a flaw in the platform. Rule sprawl compounds the same problem: it’s the cognitive-overhead issue covered in the usage-audit article, except these rules are technically still active, just redundant or inconsistent – and the bigger the list gets, the harder it is to trust at a glance.
What changes in practice
Building a rule stops being a matter of finding something similar and hoping the analogy holds – the Stage, Origin, match type, and action get decided correctly on the first pass. Consolidation becomes something a team can actually do periodically instead of a project nobody has time to start. And engineers who are new to the platform can configure a correct TP rule without first memorizing the full rule-type and priority model.
FAQ
A Traffic Processing (TP) rule defines what should happen to telecom traffic at a specific stage of the billing and routing process. It determines when a rule applies, which traffic it affects, and what action should be performed, such as number rewriting, portability lookup, routing blocking, or other traffic transformations.
AI can translate a configuration request written in plain language into the appropriate TP rule settings. It can help determine the correct Stage, Origin, match conditions, and action based on the intended traffic behavior.
Yes. The traffic-rules-configurator skill can compare match conditions across existing TP rules and identify rules that may overlap or be safely consolidated. It can provide a merge proposal for review rather than changing the configuration automatically.
No. The skill drafts configurations and merge proposals for an engineer to review. It does not independently create, update, or delete TP rules, and it does not make business decisions about how traffic should be handled.
The traffic-rules-configurator skill focuses on designing, validating, and auditing Traffic Processing rules. jera-routing-analyzer is used to investigate specific routing outcomes, such as why a call was routed to an unexpected vendor or why a particular rule fired.
It reduces the need for engineers to memorize the full TP rule model and makes configuration and rule auditing faster. Teams can describe the intended behavior in plain language, identify potentially redundant rules, and review technically appropriate configurations before applying them.