OLI and ISUP call classification in Australian networks

Originating Line Information (OLI) is an optional Information Element in the ISUP Initial Address Message (IAM). When present, it identifies the line or access point that launched the call. The originating exchange builds this data into the IAM, while MTP3 or SIGTRAN transports it towards the next signalling point.

The field provides a basis for classifying calls. Depending on the national network, classification may distinguish access lines, identify a subscriber category, or support charging and service-treatment decisions. OLI complements the calling party number and destination number rather than replacing either.

Calling-party information describes the presented identity of a subscriber, whereas OLI describes the originating line context. A presentation can be withheld or unavailable, while the originating exchange may still know which local line or gateway handled the request. Treating the two as interchangeable can produce faulty routing, charging or customer records.

Australian networks add complexity. Legacy fixed-line services in Sydney and Melbourne remain tied to exchange-aware access, while NBN and other IP-based services increasingly terminate through different gateways. Emergency calling, non-geographic service numbers and business connectivity coexist with national ISUP variants, making an agreed interpretation essential.

What OLI actually identifies

OLI is not a general-purpose identifier for the person making a call. It describes the origin from the signalling system’s point of view: a line, a logical access, or a switching or gateway function. Its digits and flags are defined by the national ISUP implementation, so an encoded value can mean different things in different networks or switch releases.

The information element can include indicators associated with calling-party, called-party and sub-address information. These links help a switch relate the originating-line identity to number fields elsewhere in the IAM. Analysts should decode the complete IAM and its context before assigning a category. An isolated value is evidence of a signalling convention, not proof of identity or physical location.

From IAM fields to call categories

The IAM establishes the called number, the presented calling number and the optional context elements used by subsequent exchanges. A switch can use OLI to select a treatment plan, apply charging rules, invoke a special service or restrict a call that does not match the expected access category. The outcome is operational classification, not merely a display label.

Classification logic must be explicit. A mapping might treat a value as an operator-defined line class, a shared access point or a gateway origin, but labels such as “business” or “public” are not universal. One switch may regard an absent element as normal for an IP gateway; another may use its presence to select a fallback treatment. The meaning of absence also needs a definition: not applicable, not supplied or unknown.

National implementations have used originating-line data for automated public access and other special-service categories. Modern gateways can apply similar classifications for managed services, provided the receiving switch has an agreed mapping and defined handling for malformed values.

Emergency and service-number handling

Australia’s 000, 112 and 911 arrangements show why the field must be interpreted carefully. Emergency routing relies on dedicated signalling, routing data and location processes, especially where mobile, VoIP and satellite services are involved. An originating-line identity may help narrow the relevant exchange or network, but it is not the caller’s dispatch address or a sufficient emergency classification on its own.

Special service numbers create another boundary. 1800 and 1300 numbers are non-geographic and can be routed nationally, so the called number says little about the caller’s location. Originating-line data can still reveal access context needed for charging or eligibility, but classification should combine it with the service-number plan and subscriber records. This field supports routing decisions rather than becoming the routing key by itself.

PSTN, SIGTRAN and interoperability

ISUP is an application protocol, whereas MTP3 supplies reliable transport over SS7 links. In an IP-based deployment, SIGTRAN commonly carries the same ISUP messages through M3UA over SCTP. OLI remains part of the ISUP IAM in that arrangement, but its practical value depends on how accurately each signalling gateway preserves and maps the national encoding.

Interoperability testing should cover more than message delivery. Capture the IAM, decode the OLI Information Element, compare it with the originating line’s classification, and test both presence and absence across an interworking boundary. The training solutions provide a structured way to practise these message flows and verify the mapping.

Australian deployment considerations

Local market conditions make an operator-specific mapping indispensable. Mobile carriers, NBN access providers, enterprise SIP trunks and specialist service providers can reach the same core through different gateways, each with its own approach to optional Information Elements. A reference table should record the OLI encoding, originating access category, permitted treatment, and handling rule for an absent or invalid value.

Melbourne’s intelligent-parking programmes offer a useful analogy for context-aware classification: curb and bay data help determine what a vehicle may do in a particular place. The parking technology examples illustrate that broader use of context data, although parking systems and ISUP serve entirely different purposes. The transferable principle is to combine a concise signal with authoritative service records.

Operational evidence completes the picture. Compare decoded IAMs with switch logs, service orders and charging outcomes, especially for complex business services and legacy lines in metropolitan and regional areas. Protect captures because originating-line data can be linked to subscriber infrastructure even when the displayed calling number is unavailable. Governance should assign ownership of the mapping and record any national or vendor-specific interpretation that changes.

OLI remains a compact but consequential input to ISUP call classification: it can expose origin context that a presented number conceals, while remaining optional, implementation-specific and unable to replace routing or location records. The next concrete step is a controlled capture of one sanitised IAM, reconciled against the operator’s approved call-classification table.