MCPTT: following a voice call

Which call variant is being explained?

MCPTT covers different procedures. For this lesson's FRMCS context we consider an ad hoc group call with an on-demand session. Ad hoc here means selecting participants for the call from the intended information or criteria. In our simplified case, Lea, Niko and Amir's separate test device are explicitly the intended participants. Permission and reachability remain separate prerequisites. [S09, clause 6.2.1]

Group membership and affiliation are general MCPTT concepts. Affiliation associates a user with a group for its use in the relevant procedure. We do not derive an additional universally mandatory step for every FRMCS ad hoc call from this concept. The sequence diagram focuses on establishment, participation, a later floor change and media. Actual participant determination and message parameters are completed against the deployed profile.

Connect establishment to SIP

The voice client's request is processed through the intended SIP functions towards MCPTT service control. A successfully observed establishment segment permits subsequent service steps but does not prove every participant state. During the later speaker change, Amir requests the floor. Niko can hear speech only after permission is granted and media actually flows. Incorrect destination resolution, a rejected floor request and missing audio output are therefore different diagnostic cases.

Choose a concrete case

Lea wants to reach Niko and Amir as participants in an ad hoc group call. For this exercise, Amir uses a separate FRMCS test device; he does not simultaneously take over Lea's driver role. All three are authorised for the communication and selected for this ad hoc call. This teaching case does not assume a pre-existing group assignment.

We consider an on-network group call. This means the communication uses the intended network and service functions. Different session variants exist. Our example uses a newly established group call followed by a separately illustrated floor change. It is not a complete normative message sequence.

Separate preparation from an ongoing call

Before the call, usable transport, network and service registration, suitable configuration and permission for the intended call are in place. This preparation is not repeated for every press of the talk button. Even an authorised user can be temporarily unreachable.

Floor Control regulates permission to speak. According to the intended rules, it handles requests, allocation and release of the floor. Floor Request means a request for the floor. A participant uses it to ask for permission to speak. Floor Granted means notification of allocation. It confirms permission to speak, not reception of speech.

Open diagram at full size (SVG, new tab) G05

The protocol message is called Floor Granted; “Floor Grant” is a common shortened description. Depending on the call variant, the first floor allocation may be associated with call establishment. The separate Request/Granted sequence here deliberately shows a later floor change. [S23, S24]

Locate a fault systematically

If Amir is not granted the floor, missing speech should not immediately be blamed on transport. If permission is granted, media flow and audio output are checked separately. Receiving a successful SIP response does not cover these checks.

Priority affects handling of the exchange but replaces neither call permission nor radio coverage. Railway Emergency Communication, the specified railway hazard communication, adds defined recipient, area and priority conditions. An ordinary test group call does not demonstrate their fulfilment. [S05]

Check your understanding

The session is active. Amir has received Floor Granted. Niko hears nothing. Which two pieces of evidence are missing at a minimum? Why would it be wrong to draw complete re-registration at every floor change?

Model answer

Evidence of the appropriate media flow to the recipient and correct audio output is missing. Also check whether Amir is actually sending speech. Registration is an earlier network or service registration; changing the speaker within an existing session is a different process. The selected variant must be stated in the flow diagram.

What to remember

• Permission, participation, the floor and audio are separate states.
• Releasing the floor does not automatically end the call.
• A concrete teaching flow explains one variant, not all MCPTT procedures.

Your Talbahn case file

Record the six observations and add the failure case “floor granted, no speech”. In 2.20 we extend the case to GSM-R; in 3.4 we examine corresponding event records.