Design · 3.4
Analysing and diagnosing voice services
Time: about 13–16 minutes including the task; estimate
Guiding question: What can actually be concluded from an event log?
Learning objective: You analyse voice faults using correlated control and media observations.
Prerequisites: Previous lessons through 3.3, particularly the case file developed there.
Successful establishment without audible speech
Talbahn repeats the MCPTT flow from 2.8. Registration, group permission and participation of the test devices are prepared. As in G05, Lea initiates the call; at the later floor change, Amir is to speak through his separate FRMCS test device. In this trial, however, Niko hears no speech from Amir. We explicitly return to the setup from 2.8, not the mixed GSM-R case from 2.20.
A trace is a time-ordered record of observed events or messages. It represents only the captured measurement points. A message visible at one interface has not necessarily arrived at every later interface.
The diagram shows the intended flow; the following trace describes a deviation. The diagram separates preparation, call establishment, floor control and media. It shows a simplified on-network case. Not every variant uses exactly this sequence; in particular, initial floor permission may be linked to call establishment.
Reading a fictional trace
Times are relative teaching values. They are neither FRMCS limits nor a complete protocol capture.
| Time | Observation |
|---|---|
| 0 ms | Call request recorded at the initiating client |
| 90 ms | Successful response to the observed SIP setup request at the client |
| 2000 ms | Amir requests the floor during the later speaker change |
| 2120 ms | Floor Granted recorded at Amir's client; permission to speak displayed |
| 2150–2900 ms | Amir's media packets recorded at measurement point A before transport |
| 2150–2900 ms | No corresponding packets recorded at measurement point B at Niko's end |
| 2950 ms | Niko reports no audible speech |
Signalling success means the observed success of a control step. It does not prove media transmission. Likewise, displayed floor permission does not establish successful audio output at the recipient.
From observation to a testable hypothesis
A hypothesis is a provisional explanation tested through further observations. One possible hypothesis here is that media packets are not forwarded correctly between A and B. Other possibilities include incorrect destination assignment or an incomplete capture at B.
Talbahn first checks the measurement itself: do both records concern the same call? Are the time base and filters appropriate? Do they capture the correct direction? Only then does it narrow down the transmission path using further measurement points.
If packets arrive at B but no speech is played, investigation shifts to the receiver. Processing or audio output could be affected there. However, this explanation is not the first established cause supported by the present observation of “no packets at B”.
Fault analysis needs responsibilities
A responsible party is named for every measurement point. The service owner examines call and floor states, the transport owner the packet path, and the terminal owner processing. A shared timeline connects the findings.
For each hypothesis, the case file gains a next test and an expected result that distinguishes explanations. “Network problem” without a measurement boundary is too vague to trigger a targeted correction.
Connect the trace to the known service functions
The successful SIP response belongs to the observed establishment segment. Floor Granted belongs to floor control. Media observations belong to the data path between sender, distribution function and receiver. This mapping from 2.4, 2.5 and 2.8 enables targeted measurement points instead of the blanket diagnosis “MCX broken”.
For a real capture, Talbahn adds SIP dialog association, participating service users, media parameters and a correlatable time base. A dialog is the SIP communication relationship to which messages belong. Different dialogs or media directions must not be mixed merely because timestamps look similar. [S21; S23]
Check your understanding
Someone concludes from the SIP response at 90 ms: “The service is completely fine; the loudspeaker must be at fault.” Which two reasoning errors do you see, and what next step do you propose?
Model answer
The SIP response establishes only the observed setup segment, not the complete service. In addition, missing packet evidence at B initially argues against attributing the cause solely to audio output. I check whether the measurements are comparable and then follow the media path between A and B. If packets arrive at B, investigation can be extended specifically to processing and audio output.
What to remember
A trace becomes informative through its measurement boundaries, not its length.
Your Talbahn case file
Record Amir's later floor change and measurement points A and B. Add a hypothesis, a next test and the result that would support or refute the hypothesis.
Sources
S21 · IETF RFC 3261: SIP
Version: June 2002 · Checked: 2026-10-11
Scope: Session establishment, modification and termination.
Limitations: SIP foundations, not a complete MCPTT flow.
Used in: 2.5, 3.4
S23 · 3GPP TS 23.379 / ETSI TS 123 379: MCPTT functional architecture and information flows
3GPP TS 23.379 / ETSI TS 123 379: MCPTT functional architecture and information flows
Version: 18.13.0, July 2025 · Checked: 2026-10-11
Scope: 5.3 affiliation; 7.3/7.4 functional model; 10.6 group calls.
Limitations: The teaching flow selects an on-network variant; not a universal message sequence.
Used in: 2.6, 2.8, 3.4
Your progress is stored in this browser on this device.