Reading ISUP CPG Messages in SS7 Call Control
In a traditional SS7 network, call setup is a conversation between signaling points. The originating exchange sends an Initial Address Message (IAM), the destination side evaluates the called number and route, and backward messages report what is happening. These reports allow switches to distinguish ringing, in-band announcements, congestion, and final answer conditions.
The ISUP Call Progress (CPG) message is central to this intermediate stage. It is sometimes informally described as an ISUP “C-message,” although CPG is the formal message name. Its purpose is to communicate call progress before the called party answers, giving the network enough information to manage tones, announcements, timers, and interworking behavior.
Understanding CPG requires more than memorizing its message code. Engineers must relate the event information to the surrounding IAM, Address Complete Message (ACM), Answer Message (ANM), and release procedures. They must also account for national ISUP variants and the way signaling gateways translate SS7 into SIP or another IP-based protocol.
Where CPG Fits In The Call Sequence
The originating switch typically sends an IAM containing the called number, calling party information, bearer requirements, and routing data. When the destination exchange has received enough digits and can continue processing, it responds with an ACM. A CPG may follow when a specific call event needs to be reported before answer.
CPG is therefore a backward message, traveling toward the originating exchange. It does not mean that the call has been answered. The ANM remains the definitive indication that the called party or service has accepted the call. Confusing CPG with ANM can cause premature billing, incorrect answer supervision, or an application to stop providing ringback too early.
What The Event Information Communicates
The most important CPG field is Event Information. It identifies the progress condition being reported, such as alerting, call progress, in-band information, or a service-related redirection event. The exact values and permitted combinations depend on the applicable ITU-T or national specification.
A CPG can tell the originating side that audible information is available in the backward direction. This matters when the network should pass an announcement or tone transparently instead of generating a locally synthesized ringback tone. The message may also include optional parameters, such as cause information, connected-number data, generic digits, or backward call indicators.
Distinguishing CPG From Related Messages
CPG works alongside several other ISUP messages, and each has a separate signaling responsibility. ACM generally confirms that routing and address analysis are complete, while CPG describes an additional event during call establishment. ANM marks answer, and REL begins clearing when the call cannot continue or one party disconnects.
| Message | Direction | Main Meaning | Answer Confirmed? |
|---|---|---|---|
| IAM | Forward | Starts call setup and carries address information | No |
| ACM | Backward | Destination has received sufficient address information | No |
| CPG | Backward | Reports an intermediate call-progress event | No |
| ANM | Backward | Called side has answered | Yes |
| REL | Either direction | Requests release of the circuit | No |
The distinction is especially important during troubleshooting. An IAM followed by ACM and repeated CPG messages may indicate normal alerting or a service announcement. An IAM followed by CPG containing in-band information may indicate that media should be connected through, while a missing ANM after prolonged progress may point to a remote network, timer, or routing problem.
Parameters And Media Handling
When a CPG indicates that in-band information is present, the media path must be treated carefully. A gateway or exchange may need to connect the bearer path so that the caller hears an announcement generated by the far-end network. If the bearer remains blocked, the signaling trace can look correct while the subscriber hears silence.
The Event Information parameter should be interpreted together with backward indicators and cause-related data. Implementations should validate mandatory parameters, reject malformed messages according to the relevant protocol rules, and preserve meaningful optional fields when translating between ISUP and SIP. A careless translation can turn a progress event into a false answer, a rejected call, or an absent early-media indication.
Timers And Trace Analysis
ISUP timers provide a practical framework for analyzing CPG behavior. T7 is commonly associated with waiting for an ACM or equivalent backward response after IAM, while T9 is commonly associated with waiting for an answer after ACM. Exact timer use and values can vary by specification, operator policy, and implementation.
A useful trace begins with the CIC, point codes, message direction, and timestamps. Follow the IAM, ACM, CPG, ANM, REL, and RLC sequence, then compare signaling events with bearer-channel activity. Check whether CPG repeats, whether the event value changes, and whether the originating exchange starts or stops local tones at the expected moment. These details often reveal whether the fault lies in routing, signaling translation, media cut-through, or timer handling.
Interworking With SIGTRAN And SIP
In an IP-based signaling environment, M2PA, M2UA, or M3UA can carry ISUP traffic over SIGTRAN without changing the meaning of the CPG message itself. The signaling gateway still needs to preserve the circuit identification code and message sequence while transporting traffic across SCTP associations and signaling points.
SIP interworking introduces a semantic conversion rather than a simple packet copy. An ISUP CPG with alerting may map toward SIP 180 Ringing, while progress with early media may be represented by SIP 183 Session Progress and suitable SDP. The correct mapping depends on the event, media status, and gateway policy. Engineers building these systems can reinforce their protocol knowledge through SS7 training materials covering ISUP, MTP3, timers, and network architecture.
Practical Checks For Operators
Reliable diagnosis comes from correlating protocol fields with observable call behavior. A signaling trace should be read in context rather than treating every backward message as an answer or every missing CPG as a failure.
Use these checks when reviewing a CPG-related issue:
- Confirm that the CPG direction, CIC, point codes, and message type are correct.
- Decode Event Information and verify it against the governing ISUP variant.
- Check whether in-band information requires bearer cut-through or early-media handling.
- Compare CPG timing with T7, T9, release timers, and gateway transaction timers.
- Verify that SIP interworking preserves progress semantics without generating false answer supervision.
A well-interpreted CPG message gives operators a precise view of what is happening between call initiation and answer. Apply these checks to live traces, lab simulations, and SIGTRAN gateway configurations to make call-progress faults easier to isolate and resolve.
