8 Coding

24.3803GPPMission Critical Push To Talk (MCPTT) media plane controlProtocol specificationRelease 18TS

8.1 Introduction

8.1.1 General

The media plane control protocols specified in the present document are based on the RTCP Application Packets (RTCP: APP), as defined in IETF RFC 3550 [3], but the media plane control messages do not conform to the rules for compound RTCP packets or RTCP packet transmission.

Each media plane control message is one RTCP: APP packet. These RTCP: APP packets are not to be sent in compound RTCP packets, but more than one media plane control message can be sent in a single IP packet.

The three first 32-bit words in any of the media plane control protocols defined in the present document are structured commonly as described in clause 8.1.2.

Outside tables, binary values are expressed with a decimal value with single quotation marks e.g. 00000000 is ‘0’, 00000001 is ‘1’, 00000010 is ‘2’ and so on.

8.1.2 RTCP: APP message format

The definition of the fields in the RTCP APP packet is found in IETF RFC 3550 [3].

Table 8.1.2-1 shows the RTCP APP packet format.

Table 8.1.2-1: RTCP: APP message format

0 1 2 3  

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name (ASCII) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| application-dependent data |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Secure RTCP message part |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

P

The padding bit P is set to ‘0’.

Subtype:

Dependent upon the relevant set of media plane control messages, as identified by the Name field, the possible Subtype values are defined in the following tables:

– Name field = "MCPT" (i.e. Floor control): Table 8.2.2.1-1

– Name field = "MCPC" (i.e. Pre-established session call control): Table 8.3.2-1

– Name field= "MCMC" (i.e. MBMS subchannel control): Table 8.4.2-1

– Name field= "MCNC" (i.e. Notification control): Table 8.5.2-1

Length

The length field in the RTCP header is the length of the packet in 32-bit words, not counting the first 32-bit word in which the length field resides.

NOTE: The length field can indicate message size longer than specified in this version of the protocol. This can be the case e.g. if message is of later version of this protocol.

SSRC

The content of this field is described for each floor control message separately.

Name

The 4-byte ASCII string in the RTCP header is used to define the set of media plane control messages to be unique with respect to other APP packets that the media plane might receive.

The present document specified the use of the following names:

1. For the floor control protocol specified in the present document the ASCII name string is: MCPT (Mission Critical Push-to-Talk).

2. For the pre-established session call control protocol specified in the present document the ASCII name string is: MCPC (Mission Critical Pre-established Session Control).

3. For the MBMS subchannel control protocol specified in the present document the ASCII name string is: MCMC (Mission Critical MBMS subchannel Control).

Application-dependent data

The application-dependent data contains zero or more application specific data fields is specified in clause 8.1.3.

This part is encrypted if SRTCP is used.

Secure RTCP message part

The content of the secure RTCP message part is in specified in clause 13 and in IETF RFC 3711 [16].

8.1.3 Application specific data field

Each application specific data field is composed of:

1. a field ID which is one octet long;

2. a length value which is:

– one octet long, if the field ID is less than 192; and

– two octets long, if the field ID is equal to or greater than 192;

3. a field value. The length in octets of the field value is indicated in the length value; and

4. a padding. The padding is zero, one, two, or three octets long. The value of the padding octet(s) is set to zero by sender and ignored by receiver.

An application specific data field has always a multiple of 4 octets.

Table 8.1.3-1 shows the application dependent data field structure when the field ID is less than 192. Table 8.1.3-2 shows the application dependent data field structure when the field ID is equal to or greater than 192.

Table 8.1.3.-1: Application specific data field structure when the field ID is less than 192

0 1 2 3  

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Field ID | Length value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +

: < F i e l d v a l u e > :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Table 8.1.3.-2: Application specific data field structure when the field ID is equal to or greater than 192

0 1 2 3  

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Field ID | Length value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +

: < F i e l d v a l u e > :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.1.4 Handling of unknown messages and fields

When an RTCP APP message is received, the receiver shall:

1. ignore the whole message, if the subtype is unknown;

2. ignore the unspecified fields in the message (e.g. specified in future version of the protocol); and

3. ignore the syntactically incorrect optional fields.

8.2 Floor control

8.2.1 Introduction

The floor control messages are coded as described in clause 8.1.2 where the floor control message is part of the application-dependent data.

For the floor control protocol the ASCII name string is: MCPT (Mission Critical Push-to-Talk).

A list of floor control messages can be found in clause 8.2.2.1.

The same floor control messages are used for on-network, off-network floor control and over the MBMS subchannel control channel.

In case of off-network, the floor participant that has the floor acts as the floor control server (referred to as floor arbitrator in clause 7) in the following clauses.

The floor control specific fields are specified in clause 8.2.3.

8.2.2 Floor control messages

8.2.2.1 General

The table 8.2.2.1-1 provides a list of floor control messages.

Table 8.2.2.1-1: Floor control specific messages

Message name	Subtype	Reference	Direction
Floor Request	00000	Clause 8.2.4	Client 🡪 server
Floor Granted	x0001	Clause 8.2.5	Server 🡪 client
Floor Deny	x0011	Clause 8.2.6	Server 🡪 client
Floor Release	x0100	Clause 8.2.7	Client 🡪 server
Floor Idle	x0101	Clause 8.2.8	Server 🡪 client
Floor Taken	x0010	Clause 8.2.9	Server 🡪 client
Floor Revoke	00110	Clause 8.2.10	Server 🡪 client
Floor Queue Position Request	01000	Clause 8.2.11	Client 🡪 server
Floor Queue Position Info	x1001	Clause 8.2.12	Server 🡪 client
Floor Ack	01010	Clause 8.2.13	Server 🡪 client Client 🡪 server
Unicast Media Flow Control	x1011	Clause 8.2.16	Client 🡪 server
Queued Floor Requests	x1110	Clause 8.2.15	Server 🡪 client Client 🡪 server
Floor Release Multi Talker	01111	Clause 8.2.14	Server 🡪 client
NOTE: The floor control server is the server and the floor participant is the client.

For some messages the first bit (marked as x in the subtype) can be used to indicate if the sender wants to have an acknowledgment. The x is coded as follows:

‘0’ Acknowledgment is not required

‘1’ Acknowledgment is required

NOTE: Whether a message needs to be acknowledged or not is described in clauses 6.

If an acknowledgment is required the Floor Ack message is used to acknowledge the message.

8.2.2.2 Void

8.2.3 Floor control specific fields

8.2.3.1 Introduction

This clause describes the floor control specific data fields.

The floor control messages can include floor control specific data fields contained in the application-dependent data of the floor control message. The floor control specific data fields follow the syntax specified in clause 8.1.3.

Table 8.2.3.1-1: Void

Table 8.2.3.1-2 lists the available floor control specific data fields including the assigned field ID.

Table 8.2.3.1-2: Floor control specific data fields

Field name		Field ID				Reference
		Decimal		Binary
Floor Priority		000		00000000		Clause 8.2.3.2
Duration		001		00000001		Clause 8.2.3.3
Reject Cause		002		00000010		Clause 8.2.3.4
Queue Info		003		00000011		Clause 8.2.3.5
Granted Party’s Identity		004		00000100		Clause 8.2.3.6
Permission to Request the Floor		005		00000101		Clause 8.2.3.7
User ID		006		00000110		Clause 8.2.3.8
Queue Size		007		00000111		Clause 8.2.3.9
Message Sequence-Number		008		00001000		Clause 8.2.3.10
Queued User ID		009		00001001		Clause 8.2.3.11
Source		010		00001010		Clause 8.2.3.12
Track Info		011		00001011		Clause 8.2.3.13
Message Type		012		00001100		Clause 8.2.3.14
Floor Indicator		013		00001101		Clause 8.2.3.15
SSRC		014		00001110		Clause 8.2.3.16
List of Granted Users		015		00001111		Clause 8.2.3.17
List of SSRCs		016		00010000		Clause 8.2.3.18
Functional Alias		017		00010001		Clause 8.2.3.19
List of Functional Aliases		018		00010010		Clause 8.2.3.20
Location		019		00010011		Clause 8.2.3.21
List of Locations		020		00010100		Clause 8.2.3.22
Queued Floor Requests Purpose		021		00010101		Clause 8.2.3.23
List of Queued Users		022		00010110		Clause 8.2.3.24
Response State		023		00010111		Clause 8.2.3.25
Media Flow Control Indicator		024		00011000		Clause 8.2.3.26

The following clauses describe the coding of each field.

8.2.3.2 Floor Priority field

The Floor Priority field describes the level of priority requested in a Floor Request message or granted in a Floor Granted message. The max floor priority that can be requested in a Floor Request message is negotiated between the MCPTT client and the controlling MCPTT function using the "mc_priority" fmtp parameter as specified in clause 14.

Table 8.2.3.2-1 describes the coding of the Floor Priority field.

Table 8.2.3.2-1: Floor Priority field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Floor Priority |Floor Priority |Floor Priority |spare |

|field ID value |Length value |value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Floor Priority field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Floor Priority length> value is a binary value and has the value ‘2’ indicating the total length in octets of the <Floor priority> value item and the spare bits.

The <Floor Priority> value consists of 8 bit parameter giving the floor priority (‘0’ to ‘255’) where ‘0’ is the lowest priority and ‘255’ is the highest priority. If the Floor Priority field is not included in the message the default priority is used as the Floor Priority value. The value of the default priority is ‘0’. The default priority is sometimes referred to as normal priority. Whether a floor priority is pre-emptive or not is determined:

1. for on-network by the floor control server as described in clause 4.1.1.4; and

2. for off-network by the floor arbitrator as described in clause 4.1.1.5.

The spare bits are set to zero.

8.2.3.3 Duration field

The Duration field describes the time in seconds for which the granted party is allowed to transmit.

Table 8.2.3.3-1 describes the coding of the Duration field.

Table 8.2.3.3-1: Duration field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Duration |Duration |Duration value |

|field ID value |length value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Duration field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Duration length> value is a binary value and has the value ‘2’ indicating the total length in octets of the <Duration> value item.

The <Duration> value is a binary value in seconds.

8.2.3.4 Reject Cause field

The Reject Cause field contains a <Reject Cause> value and can contain a <Reject Phrase> value. The content of the <Reject Cause> value is floor control message dependent and is described per individual floor control message carrying the Reject Cause field.

Table 8.2.3.4-1 describes the coding of the Reject Cause field.

Table 8.2.3.4-1: Reject Cause field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Reject Cause |Reject Cause | Reject Cause |

|field ID |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: Reject Phrase :

: |

| (Padding) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Reject Cause field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Reject Cause length> value is a binary value and indicates the total length in octets of the <Reject Cause> value and the <Reject Phrase> value items excluding any padding octets. If the length field is set to ‘2’, there is no <Reject Phrase> value in the Reject Cause field.

The <Reject Cause> value is a 16 bit binary value as defined in clause 8.2.6.2 for Floor Deny message and as defined in clause 8.2.10.2 for Floor Revoke message.

The <Reject Phrase> value is a text string encoded the text string in the SDES item CNAME as specified in IETF RFC 3550 [3].

If the length of the <Reject Phrase> value is not a multiple of 4 bytes, the <Reject Phrase> value is padded to a multiple of 4 bytes. The value of the padding bytes is set to zero. The padding bytes are ignored by the receiver.

8.2.3.5 Queue Info field

The Queue Info field includes information about the position for one MCPTT client in the floor request queue and the priority of the floor request.

Table 8.2.3.5-1 describes the coding of the Queue Info field.

Table 8.2.3.5-1: Queue Info field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Queue Info |Queue Info |Queue Position |Queue Priority |

|field ID value |length value |Info value | Level value |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Queue Info field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Queue Info length> value is a binary value and has the value ‘2’ indicating the total length in octets of the <Queue position info> value and the <Queue Priority Level> value items.

The <Queue Position Info> value is a binary value. The <Queue Position Info> value has the value ‘254’ if the MCPTT client is not queued. The <Queue Position Info> value has the max value (‘255’) if the MCPTT client is queued but the MCPTT server is unable to determine the queue position or if MCPTT server policy is not to release information of the queue position to the MCPTT client.

The <Queue Priority Level> value is coded as the <Floor Priority> value in clause 8.2.3.2.

8.2.3.6 Granted Party’s Identity field

The Granted Party’s Identity field identifies the MCPTT user that is granted to send media.

Table 8.2.3.6-1 describes the coding of the Granted Party’s Identity field.

Table 8.2.3.6-1: Granted Party’s Identity field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Granted Party’s|Granted Party’s| Granted Party’s Identity |

|Identity field |Identity length| :

|ID | | :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Granted Party’s Identity field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Granted Party’s Identity length> value is coded as the <User ID length> value in clause 8.2.3.8.

The <Granted Party’s Identity> value is coded as the <User ID> value in clause 8.2.3.8.

If the length of the <Granted Party’s Identity> value is not (2 + multiple of 4) bytes, the <Granted Party’s Identity> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes is set to zero. The padding bytes are ignored by the receiver.

8.2.3.7 Permission to Request the Floor field

The Permission to Request the Floor field indicates whether receiving parties are allowed to request the floor or not.

Table 8.2.3.7-1 describes the coding of the Permission to Request the Floor field.

Table 8.2.3.7-1: Permission to Request the Floor field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Permission to |Permission to | Permission to Request |

|Request the |Request the | the Floor value |

|Floor field ID |Floor length | |

| |value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Permission to Request the Floor field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Permission to Request the Floor length> value is a binary value and has the value ‘2’ indicating the total length in octets of the <Permission to Request the floor> value.

The <Permission to Request the Floor> value is 16 bit binary value and coded as follows:

‘0’ The receiver is not permitted to request floor.

‘1’ The receiver is permitted to request floor.

All other values are reserved for future use.

8.2.3.8 User ID field

The User ID field contains the MCPTT ID of an MCPTT user.

Table 8.2.3.8-1 describes the coding of the User ID field.

Table 8.2.3.8-1: User ID field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|User ID |User ID | User ID |

|field ID |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: :

: |

| Padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <User ID field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <User ID length> value is a binary value and includes the value indicating the length in octets of the <User ID> value item except padding.

The <User ID> value is coded as described in table 8.2.3.8-2.

Table 8.2.3.8-2: ABNF syntax of string values of the <User ID> value

user-id = URI

If the length of the <User ID> value is not (2 + multiple of 4) bytes <User ID> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes is to zero. The padding bytes are ignored by the receiver.

8.2.3.9 Queue Size field

The Queue Size field contains the numbers of queued MCPTT clients in an MCPTT call.

Table 8.2.3.9-1 describes the coding of the Queue size field.

Table 8.2.3.9-1: Queue Size field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Queue Size |Queue Size |Queue Size value |

|field ID value |length value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Queue Size field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Queue Size length> value is a binary value and has the value ‘2’ indicating the total length in octets of the <Queue Size> value item.

The <Queue Size> value is a 16 bit binary value.

8.2.3.10 Message Sequence Number field

The Message Sequence Number field is used to bind a number of Floor Taken or bind a number of Floor Idle messages together.

Table 8.2.3.10-1 describes the coding of the Message Sequence Number field.

Table 8.2.3.10-1: Message Sequence Number field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Message |Message |Message Sequence Number value |

|Sequence Number|Sequence Number| |

|field ID value |length value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Message Sequence Number field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Message Sequence Number length> value is a binary value and has the value ‘2’ indicating the total length in octets of the <Message Sequence Number> value item.

The <Message Sequence Number> value is a binary value. The <Message Sequence Number> value can be between ‘0’ and ‘65535’. When the ‘65535’ value is reached, the <Message Sequence Number> value starts from ‘0’ again.

8.2.3.11 Queued User ID field

The Queued User ID field includes information about the identity of a queued MCPTT user.

Table 8.2.3.11-1 describes the coding of the Queued User ID field.

Table 8.2.3.11-1: Queued User ID field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Queued User ID |Queued User ID| Queued User ID |

|field ID |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Queued User ID field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Queued User ID length> value is coded as the <User ID length> value in clause 8.2.3.8.

The <Queued User ID> value is coded as the <User ID> value in clause 8.2.3.8.

If the length of the <Queued User ID> value is not (2 + multiple of 4) bytes, the <Queued User ID> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes is set to zero. The padding bytes are ignored by the receiver.

8.2.3.12 Source field

The Source field contains the source of the message.

Table 8.2.3.12-1 describes the coding of the Source field.

Table 8.2.3.12-1: Source field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Source |Source | Source value |

|field ID value |length value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Source field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Source length> value is a binary value and has the value ‘2’ indicating the total length in octets of the <Source> value item.

The <Source> value is a 16 bit binary value where:

‘0’ the floor participant is the source

‘1’ the participating MCPTT function is the source

‘2’ the controlling MCPTT function is the source

‘3’ the non-controlling MCPTT function is the source

All other values are reserved for future use.

8.2.3.13 Track Info field

The Track Info field contains the path a floor control message has been routed along with the priority and the queueing capability of the MCPTT client.

Table 8.2.3.13-1 describes the coding of the Track Info field.

Table 8.2.3.13-1: Track Info field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Track Info |Track Info |Queueing |Participant |

|field ID value |length value |Capability |Type Length |

| | |value |value |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Participant Type value |

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Participant Reference 1 |

: | :

| Floor Participant Reference n |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Track Info field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Track Info length> value is a binary value and has a value indicating the total length in octets of the <Queueing Capability> value, the <Participant Type Length> value, the <Participant Type> value, and one or more <Floor Participant Reference> value items.

The <Queueing Capability> value is an 8 bit binary value where:

‘0’ the floor participant in the MCPTT client does not support queueing

‘1’ the floor participant in the MCPTT client supports queueing

All other values are reserved for future use.

The <Participant Type Length> value is 8 bit binary value set to the length of the <Participant Type> value item except padding.

The <Participant Type> value is string coded as specified in table 8.2.3.13-2:

Table 8.2.3.13-2: ABNF syntax of values of the <Participant Type> value

participant-type = 1*( %x20-7E / UTF8-NONASCII )

If the length of the <Participant Type> value is not a multiple of 4 bytes, the <Participant Type> value is padded to a multiple of 4 bytes. The value of the padding bytes is set to zero. The padding bytes are ignored by the receiver.

NOTE 1: The content of the <Participant Type> value is MCPTT service provider specific and out of scope of the present document.

The <Floor Participant Reference> value is a 32 bit binary value containing a reference to the floor participant in the non-controlling MCPTT function of an MCPTT group.

NOTE 2: The reference to the floor participant is a value only understandable by the floor control server interface in the non-controlling MCPTT function of an MCPTT group.

8.2.3.14 Message Type field

The Message Type field contains the subtype of the floor control message that is acknowledged.

Table 8.2.3.14-1 describes the coding of the Message Type field.

Table 8.2.3.14-1: Message Type field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Message Type |Message Type |Message Type |Spare |

|field ID |Length | | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Message Type field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Message Type Length> value is a binary value and has the value ‘2’ indicating the total length in octets of the <Message Type> value item and the spare bits.

The <Message Type> value is an 8 bit binary value containing the binary value consisting of the 5 bit message subtype as coded in table 8.2.2.1-1 (including the first bit (used by some floor control messages to indicate that a Floor Ack message is requested) of the five bit subtype) preceeded by "000".

The spare bits are set to zero.

8.2.3.15 Floor Indicator field

The Floor Indicator contains additional information about a received floor control message.

Table 8.2.3.15-1 describes the coding of the Floor Indicator field.

Table 8.2.3.15-1: Floor Indicator field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Floor Indicator|Floor Indicator|Floor Indicator value |

|field ID value |Length value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Floor Indicator field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Floor Indicator Length> value is a binary value and has the value ‘2’.

The <Floor Indicator> value is a 16 bit bit-map named as shown in table 8.2.3.15-2:

Table 8.2.3.15-2: Floor Indicator bit marking

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When set to 1, the bit has the following meaning:

A = Normal call

B = Broadcast group call

C = System call

D = Emergency call

E = Imminent peril call

F = Queueing supported

G = Dual floor

H = Temporary group call (NOTE 2)

I = Multi-talker

NOTE 1: The indicators A, B, C, D and E are only informative. There are no procedures specified for the A, B, C, D and E indicators in this release of the present document but they can be used to provide information to the user about type of call.

NOTE 2: An MCPTT group call is a temporary group session when the <on-network-temporary> element is present in the <list-service> element as specified in 3GPP TS 24.481 [12].

Bits J to P are reserved for future use and are set to 0.

There can be more than one bit set to 1 at the same time. The local policy in the floor control server decides which combinations are possible and the priority of the indications.

8.2.3.16 SSRC field

The content of the SSRC field is coded as specified in IETF RFC 3550 [3]. An SSRC field can also have a Field ID and a length value. This clause specifies an SSRC field including a Field ID and a length value.

Table 8.2.3.16-1: SSRC field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|SSRC |SSRC |SSRC value |

|field ID value |length value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC value |Spare |

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <SSRC field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <SSRC length> value is a binary value and has the value ‘6’ indicating the total length in octets of the <SSRC length> value item and the spare bits.

The <SSRC> value is coded as the SSSRC specified in IETF RFC 3550 [3].

The spare bits are set to zero.

8.2.3.17 List of Granted Users field

The List of Granted Users field contains a list of MCPTT IDs of MCPTT users that are allowed to send media in a multi-talker scenario.

Table 8.2.3.17-1 describes the coding of the List of Granted Users field.

Table 8.2.3.17-1: List of Granted Users field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|List of Granted|List of Granted| No of Granted| Granted User ID|

|Users field ID |Users length | Users value | length value |

|value |value | | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+

: Granted User ID :

: |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Granted User ID| Granted User ID :

| length value | :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+

: Granted User ID (continued) :

: |

| Padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <List of Granted Users field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <List of Granted Users length> value is a binary value and has a value indicating the total length in octets of the <No of Granted Users> value, and one or more pair of <Granted User ID length> and <Granted User ID> value items except padding.

The <No of Granted Users> value is a binary value and includes the number of Granted User ID entries in the list.

The <Granted User ID length> value is a binary value and includes the value indicating the length in octets of the <Granted User ID> value item.

The <Granted User ID> value is coded as described in table 8.2.3.17-2.

Table 8.2.3.17-2: ABNF syntax of string values of the <Granted User ID> value

granted-user-id = URI

If the length of the sum of all <Granted User ID length> values and all <Granted User ID> values is not (1 + multiple of 4) bytes, then the sum shall be padded to (1 + multiple of 4) bytes. The value of the padding bytes is set to zero. The padding bytes are ignored by the receiver.

8.2.3.18 List of SSRCs field

The List of SSRCs field contains the list of SSRCs of the users that are allowed to send media in a multi-talker scenario.

Table 8.2.3.18-1: List of SSRCs field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|List of SSRCs |List of SSRCs |Number of |Spare |

|field ID value |length value |SSRCs value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC value |

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC value |

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <List of SSRCs field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <List of SSRCs length> value is a binary value and has a value indicating the total length in octets of the <Number of SSRCs> value, spare bits and one or more <SSRC> value items.

The <Number of SSRCs> value is a binary value and contains the number of SSRCs in the information field.

The <SSRC> value is coded as the SSRC specified in IETF RFC 3550 [3]. <SSRC> value items have a length ‘4’.

The spare bits are set to zero.

8.2.3.19 Functional Alias field

The Functional Alias field identifies the Functional Alias that the MCPTT user has chosen to use.

Table 8.2.3.19-1 describes the coding of the Functional Alias field.

Table 8.2.3.19-1: Functional Alias field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Functional |Functional | Functional Alias |

|Alias field |Alias length | :

|ID | | :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Functional Alias field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Functional Alias length> value is a binary value and includes the value indicating the length in octets of the <Functional Alias field ID> value item except padding.

The <Functional Alias> value is coded as described in table 8.2.3.19-2.

Table 8.2.3.19-2: ABNF syntax of string values of the <Functional Alias> value

Functional Alias = URI

If the length of the <Functional Alias> value is not (2 + multiple of 4) bytes <Functional Alias field> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes is to zero. The padding bytes are ignored by the receiver.

8.2.3.20 List of Functional Aliases field

The List of Functional Aliases field contains a list of Functional Aliases of MCPTT users that are allowed to send media in a multiple talker scenario.

Table 8.2.3.20-1 describes the coding of the List of Functional Aliases field.

Table 8.2.3.20-1: List of Functional Aliases field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|List of FAs |List of FAs | No of FAs | FA length |

| field ID | length | | value |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+

: Functional Alias :

: |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| FA length | Functional Alias :

| value | :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+

: Functional Alias (continued) :

: |

| Padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <List of FAs ID> value is a binary value and is set according to table 8.2.3.1-2.

The <List of FAs length> value is a binary value and has avalue indicating the total length in octets of the the <No of FAs> value, and one or more pair of <FA length value> and <Functional Alias> value items except padding.

The <No of FAs> value is a binary value and includes the number of Functional Alias entries in the list.

The <FA length> value is a binary value and includes the value indicating the length in octets of the <Functional Alias> value item.

The <Functional Alias> value is coded as described in table 8.2.3.17-2.

Table 8.2.3.20-2: ABNF syntax of string values of the <Functional Alias> value

Functional Alias = URI

If the length of the sum of all <FA length> values and all <Functional Alias> values is not (1 + multiple of 4) bytes, then the sum shall be padded to (1 + multiple of 4) bytes. The value of the padding bytes is set to zero. The padding bytes are ignored by the receiver.

8.2.3.21 Location field

The location field contains the location of a user.

Table 8.2.3.21-1: Location field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Location field |Location length| Location |

|ID | | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +

: :

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Location field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Location length> value is a binary value and includes the value indicating the length in octets of the <Location> value except padding.

The <Location> value is coded as follows:

Table 8.2.3.21-2: Location value coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Location Type | Location Value |

+-+-+-+-+-+-+-+-+ – – – – – – – – – – – – – – – – – – – – – – – +

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Location type> value is selected from table 8.2.3.21-3:

Table 8.2.3.21-3: Location type

Location Type	Granted Party’s Location type code	Granted Party’s Location Value
Not provided	00000000	0 bits
ECGI	00000001	56 bits = MCC + MNC + ECI
Tracking Area	00000010	40 bits = MCC + MNC + 16 bits
PLMN ID	00000011	24 bits = MCC+MNC
MBMS Service Area	00000100	16 bits = [0-65535]
MBSFN Area ID	00000101	8 bits = [0-255]
Geographic coordinates	00000110	48 bits = latitude in first 24 bits + longitude in last 24 bits coded as in clause 6.1 in 3GPP TS 23.032 [19].
Altitude	00000111	16 bits = altitude coded as in clause 6.3 in 3GPP TS 23.032 [19].

NOTE: It is preferred that geographic coordinates are sent.

The <Location Value> format is specified in table 8.2.3.21-3. If location information of the requesting user is not available or is not allowed to be reported by the requesting user’s MCPTT profile, the location type field is set to ‘0’ (Not provided).

If the length of the <Location> value is not (2 + multiple of 4) bytes, the <Location> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes is set to zero. The padding bytes are ignored by the receiver.

8.2.3.22 List of Locations field

The List of Locations field contains the locations of users in a multi-talker scenario or when more than one Location Type needs to be included.

Table 8.2.3.22-1: List of Locations field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|List of |List of | Number of | Location |

|Locations field|Locations | Locations | |

|ID |length | | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: Location :

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: Location (continued) :

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <List of Locations field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <List of Locations length> value is a binary value and has a value indicating the total length in octets of the <Number of Locations> value and one or more <Location> value items (i.e. set of (<Location type> value plus <Location value> values) except padding.

The <Number of Locations> value is a binary value and shall be equal to the <No of users> field in the List of Granted Users field (see 8.2.3.17). The location information shall be maintained in the same order as the users in the List of Granted Users to allow location information to be matched to the correct user. When the location information for a granted floor participant is not available or not allowed, the location type field for that granted floor participant shall be set to ‘0’ (Not provided).

The <Location> field is coded per clause 8.2.3.21. The <Location type> value for a granted user for whom location information is either not available or not allowed shall be set to 0 (Not provided).

If the length of the sum of the set of <Location> values is not (1 + multiple of 4) bytes, then the sum shall be padded to (1 + multiple of 4) bytes. The value of the padding bytes is set to zero. The padding bytes are ignored by the receiver.

8.2.3.23 Queued Floor Requests Purpose field

The Queued Floor Requests Purpose field contains the type of the message requested i.e Cancel Request, Cancel Notification and Cancel Result.

Table 8.2.3.23-1 describes the coding of the Queued Floor Requests Purpose field.

Table 8.2.3.23-1: Queued Floor Requests Purpose field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Queued Floor | Queued Floor | Queued Floor Requests |

| Requests | Requests | Purpose |

| Purpose | Purpose | |

| field ID | Length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The < Queued Floor RequestsPurpose field ID> value is a binary value and is set according to table 8.2.3.1-2.

The < Queued Floor RequestsPurpose Length> value is a binary value and has the value ‘2’ indicating the total length in octets of the <Queued Floor Requests Purpose> value item.

The < Queued Floor RequestsPurpose> value is a 16-bit binary value with the following values:

‘0’ Cancel Request

‘1’ Cancel Result

‘2’ Cancel Notification

All other values are reserved for future use.

8.2.3.24 List of Queued Users field

The List of Queued Users field contains a list of MCPTT IDs of MCPTT users.

Table 8.2.3.24-1 describes the coding of the List of Queued Users field.

Table 8.2.3.24-1: List of Queued Users field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|List of Queued|     List of Queued Users      |  No of Queued|

|Users field ID|      length                     | Users       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+

: Queued User ID length         | Queued User ID                :

: value                         |                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

:                                                               :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Queued User ID length         |  Queued User ID               :

| value                         |                               :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+

: Queued User ID(continued)                                     :

:                                                               |

|                                        Padding                |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <List of Queued Users field ID> value is a binary value and is set according to table 8.2.3.1-2.

The <List of Queued Users length> value is a binary value and has a value indicating the total length in octets of the <No of Queued Users> value, and one or more pair of <Queued User ID length> and <Queued User ID> value items except padding.

NOTE: The receiver understands that the padding octets are not included in this length field and can calculate the number of padding bytes per the formula below.

The <No of Queued Users> value is a binary value that indicates the number of Queued User ID entries in the list.

The <Queued User ID length> value is a binary value that indicates the length in octets of the <Queued User ID> value item.

The <Queued User ID> value is coded as described in table 8.2.3.24-2.

Table 8.2.3.24-2: ABNF syntax of string values of the <Queued User ID> value

queued-user-id = URI

If the length of the sum of all <Queued User ID length> values and all <Queued User ID> values is not (1 + multiple of 4) bytes, then the sum shall be padded to (1 + multiple of 4) bytes. The value of the padding bytes is set to zero. The padding bytes are ignored by the receiver.

8.2.3.25 Queued Floor Requests Result field

The Queued Floor Requests Result field indicates the result of the Queued Floor Requestsmessage (Cancel Request).

Table 8.2.3.25-1 describes the coding of the Queued Floor Requests Result field.

Table 8.2.3.25-1: Queued Floor Requests Result field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Queued Floor | Queued Floor | Queued Floor |

| Requests | Requests | Requests |

| Result field ID | Result length | Result Value |

| value | | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Queued Floor Requests Result field ID> value is a binary value and shall be set according to table 8.2.3.1-2.

The <Queued Floor Requests Result length> value is a binary value and shall have the value ‘2’ indicating the total length in octets of the <Queued Floor Requests Result> value item.

The <Queued Floor Requests Result Value> value is a 16-bit binary value with the following values:

‘0’ Successfully removed the queued floor requests of all users specified in the List of Queued Users field in a message or all the queued floor requests from the floor request queue

‘1’ Not authorized to remove the queued floor requests of all users specified in the List of Queued Users field in a message or all the queued floor requests from the floor request queue

‘2’ The floor request queue is already empty

‘3’ The queued floor requests of all users specified in the List of Queued Users field in a message do not exist in the floor request queue

‘4’ Unable to remove some of the queued floor requests of the users specified in the List of Queued Users field in a message

‘5’ The queued floor requests of some of the users specified in the List of Queued Users field in a message do not exist in the floor request queue

‘255’ Unknown reason

All other values are reserved for future use.

8.2.3.26 Media Flow Control Indicator field

The Media Flow Control field is used to indicate to the floor control server whether the user wants to control reception of unicast media.

Table 8.2.3.26-1 describes the coding of the Media Flow Control field.

Table 8.2.3.26-1: Media Flow Control Indicator field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Media Flow | Media Flow | Media Flow |spare |

| Control ID |Control Length | value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Media Flow Control ID> value is a binary value and is set according to table 8.2.3.1-2.

The <Media Flow Control length> value is a binary value and has the value ‘2’ indicating the total length in octets of the <Media Flow> value item and the spare bits.

The <Media Flow> value is an 8 bit bit-map named as shown in table 8.2.3.26-2:

Table 8.2.3.26-2: Media Flow bit marking

+-+-+-+-+-+-+-+-+

|A|B|C|D|E|F|G|H|

+-+-+-+-+-+-+-+-+

The bits have the following meaning:

A = When set to ‘0’, it indicates unicast media stop request. And when set to ‘1’, it indicates unicast media resume request.

Bits B to H are set to zero.

The spare bits are set to zero.

8.2.4 Floor Request message

The Floor Request message is a request from a floor participant to get permission to send media. The Floor Request message is used in the off-network mode and in the on-network mode. In the on-network mode the Floor Request message is only used over the unicast bearer.

Table 8.2.4-1 shows the content of the Floor Request message.

Table 8.2.4-1: Floor Request message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of floor participant sending the Floor Request message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Priority field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: User ID field :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Indicator field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: Functional Alias field :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: Location field :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor participant sending the Floor Request message.

The content of the SSRC field is coded as specified in IETF RFC 3550 [3].

Floor priority:

The Floor Priority field is coded as described in clause 8.2.3.2.

User ID:

The User ID field is used in off-network only and is coded as described in clause 8.2.3.8.

Track Info:

The Track Info field is included when an MCPTT call involves a non-controlling MCPTT function. The coding of the Track Info field is described in clause 8.2.3.13.

Floor Indicator:

The Floor Indicator field is coded as described in clause 8.2.3.15.

Functional Alias:

The Functional Alias field is coded as described in clause 8.2.3.19.

Location:

The Location field is coded as described in clause 8.2.3.21 and contains the location information of the requesting user.

8.2.5 Floor Granted message

The Floor Granted message is sent by the floor control server to inform the requesting floor participant that it has been granted the permission to send media.

The Floor Granted message is used in the off-network mode and in the on-network mode. In the on-network mode the Floor Granted message is only used over the unicast bearer.

Table 8.2.5-1 shows the content of the Floor Granted message.

Table 8.2.5-1: Floor Granted message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of floor control server/floor arbitrator |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Duration field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of granted floor participant field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Priority field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| User ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Queue Size field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of queued floor participant field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Queued User ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Queue Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Indicator field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant. However, any set of Queue size field, SSRC of queued floor participant field, Queued User ID field and the Queue Info field shall be kept together.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor control server for on-network and floor arbitrator for off-network.

The content of the SSRC field is coded as specified in IETF RFC 3550 [3].

Duration:

The Duration field is coded as specified in clause 8.2.3.3.

SSRC of granted floor participant:

The SSRC of granted floor participant is coded as specified in clause 8.2.3.16.

Floor Priority:

The Floor Priority field contains the granted floor priority and is coded as specified in clause 8.2.3.2.

User ID:

The User ID field is used in off-network only. The User ID field carries the MCPTT ID of the floor participant granted the floor. The User ID field is coded as described in clause 8.2.3.8.

Queue Size:

The Queue Size field is only applicable in off-network and contains the numbers of queued MCPTT clients in the MCPTT call.

The Queue Size field is coded as specified in clause 8.2.3.9.

For each waiting floor participant the following set of fields are included:

1. the SSRC of queued floor participant;

2. the Queued User ID field; and

3. the Queue info field.

The set occurs as many times as the <Queue size> value in the Queue size field.

SSRC of queued floor participant:

The SSRC of queued floor participant is only applicable in off-network and carries the SSRC of the floor participant in the queue.

The content of the SSRC of queued floor participant is coded as the SSRC specified in IETF RFC 3550 [3].

Queued User ID:

The Queued User ID field is only applicable in off-network and contains the MCPTT ID of the floor participant in the queue.

The Queued User ID field is coded as specified in clause 8.2.3.11.

Queue Info:

The Queue Info field is only applicable in off-network and defines the queue position and granted floor priority in the queue.

The Queue Info field is coded as specified in clause 8.2.3.5.

Track Info:

The Track Info field is included when an MCPTT call involves a non-controlling function. The coding of the Track Info field is described in clause 8.2.3.13.

Floor Indicator:

The Floor Indicator field is coded as described in clause 8.2.3.15.

8.2.6 Floor Deny message

8.2.6.1 General

The Floor Deny message is sent as an action from the floor control server to the requesting floor participant to inform that the floor request was rejected.

The Floor Deny message is used in the off-network mode and in the on-network mode. In the on-network mode the Floor Deny message is only used over the unicast bearer.

Table 8.2.6.1-1 shows the content of the Floor Deny message.

Table 8.2.6.1-1: Floor Deny message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of floor control server/floor arbitrator |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Reject Cause field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| User ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Indicator field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor control server for on-network and floor arbitrator for off-network.

The content of the SSRC field is coded as specified in IETF RFC 3550 [3].

Reject Cause:

The Reject Cause field includes the reason for the rejecting the floor request and can be followed by a text-string explaining why the floor request was rejected. Therefore the length of the packet will vary depending on the size of the application dependent field.

The Reject Cause field contains:

1. a <Reject Cause> value; and

2. a <Reject Phrase> value.

Available <Reject Cause> values are listed in clause 8.2.6.2. The Reject Cause field is coded as described in clause 8.2.3.4.

User ID:

The User ID field is used in off-network only. The User ID carries the MCPTT ID of the requesting floor participant to which the Floor Deny message is sent.

The User ID field is coded as specified in clause 8.2.3.8.

Track Info:

The Track Info field is included when an MCPTT call involves a non-controlling MCPTT function. The coding of the Track Info field is described in clause 8.2.3.13.

Floor Indicator:

The Floor Indicator field is coded as described in clause 8.2.3.15.

8.2.6.2 Rejection cause codes and rejection cause phrase

Cause #1 – Another MCPTT client has permission

The <Reject cause> value set to ‘1’ indicates that another MCPTT user has permission to send a media.

Cause #2 – Internal floor control server error

The <Reject cause> value set to ‘2’ indicates that the floor control server cannot grant the floor request due to an internal error.

Cause #3 – Only one participant

The <Reject cause> value set to ‘3’ indicates that the floor control server cannot grant the floor request, because the requesting party is the only participant in the MCPTT session.

Cause #4 – Retry-after timer has not expired

The <Reject cause> value set to ‘4’ indicates that the floor control server cannot grant the floor request, because timer T9 (Retry-after) has not expired after permission to send media has been revoked.

Cause #5 – Receive only

The <Reject cause> value set to ‘5’ indicates that the floor control server cannot grant the floor request, because the requesting party only has receive privilege.

Cause #6 – No resources available

The <Reject cause> value set to ‘6’ indicates that the floor control server cannot grant the floor request due to congestion.

Cause #7 – Queue full

The <Reject cause> value set to ‘7’ indicates that the floor control server cannot queue the floor request, because the queue is full.

Cause #255 – Other reason

The <Reject cause> value set to ‘255’ indicates that the floor control server does not grant the floor request due to the floor control server local policy.

8.2.7 Floor Release message

The Floor Release message is sent as an action from the floor participant to the floor control server to inform that the floor can be released.

The Floor Release message can also be sent if the floor participant has a request in the floor request queue. In this case, the Floor Release message is sent to cancel the floor request in the queue.

The Floor Release message is used in the off-network mode and in the on-network mode. In the on-network mode the Floor Release message is only used on the unicast bearer.

Table 8.2.7-1 shows the content of the Floor Release message.

Table 8.2.7-1: Floor Release message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of floor participant with permission to send media |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| User ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Indicator field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor participant with permission to send media.

The content of the SSRC field is coded as specified in IETF RFC 3550 [3].

User ID:

The User ID field is used in off-network only. The User ID field carries the MCPTT ID of the floor participant sending the floor release message.

The User ID field is coded as specified in clause 8.2.3.8.

Track Info:

The Track Info field is included when an MCPTT call involves a non-controlling MCPTT function. The coding of the Track Info field is described in clause 8.2.3.13.

Floor Indicator:

The Floor Indicator field is coded as described in clause 8.2.3.15.

8.2.8 Floor Idle message

The Floor Idle message is sent as an action from the floor control server to the floor participant indicating that no floor participant has permission to send media.

The Floor Idle message is only used in the on-network mode. The Floor Idle message is used over both the unicast and MBMS bearer.

Table 8.2.8-1 shows the content of the Floor Idle message.

Table 8.2.8-1: Floor Idle message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length=2 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of floor control server |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Message Sequence Number field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Indicator field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor control server.

The content of the SSRC field is coded as specified in IETF RFC 3550 [3].

Message Sequence Number:

The Message Sequence Number field is coded as specified in to clause 8.2.3.10.

Track Info:

The Track Info field shall be included when an MCPTT call involves a non-controlling MCPTT function. The coding of the Track Info field is described in clause 8.2.3.13.

Floor Indicator:

The Floor Indicator field is coded as described in clause 8.2.3.15.

8.2.9 Floor Taken message

The Floor Taken message is sent as an action from the floor control server to inform non-requesting floor participant(s) that someone has been granted permission to send media.

The Floor Taken message is used in the off-network mode and in the on-network mode. In the on-network mode the Floor Taken message is used over both the unicast and MBMS bearer.

Table 8.2.9-1 shows the content of the Floor Taken message.

Table 8.2.9-1: Floor Taken message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of floor control server/floor arbitrator |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Granted Party’s Identity field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Permission to Request the Floor field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| User ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Message Sequence Number field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Indicator field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of granted floor participant field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Functional Alias field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| List of Granted Users field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| List of SSRCs of granted floor participants field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| List of Functional Aliases field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Location field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| List of Locations of granted floor participants field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor control server for on-network and floor arbitrator for off-network.

The content of the SSRC field is coded as specified in IETF RFC 3550 [3].

Granted Party’s Identity:

The Granted Party’s Identity field is coded as specified in clause 8.2.3.6.

Permission to request the floor:

The Permission to Request the Floor field is coded as specified in clause 8.2.3.7.

User ID:

The User ID field is used in off-network only. The User ID field carries the MCPTT user ID of the floor participant sending the Floor Taken message.

The User ID field is coded as specified in clause 8.2.3.8.

Message Sequence Number:

The Message Sequence Number field is coded as specified in to clause 8.2.3.10.

Track Info:

The Track Info field is included when an MCPTT call involves a non-controlling MCPTT function. The coding of the Track Info field is described in clause 8.2.3.13.

Floor Indicator:

The Floor Indicator field is coded as described in clause 8.2.3.15.

SSRC of granted floor participant:

The SSRC of granted floor participant is coded as specified in clause 8.2.3.16. The field is not used in multi-talker control scenario.

Functional Alias:

The Functional Alias field contains the functional alias of the granted party and is coded as specified in clause 8.2.3.19.

List of Granted Users:

The List of Granted Users field is used in a multi-talker scenario. The List of Granted Users field is coded as specified in clause 8.2.3.17 and indicates the list of users that have permission to send media.

List of SSRCs of granted floor participants:

The List of SSRCs field is used in a multi-talker scenario. The List of SSRCs of granted floor participants is coded as specified in clause 8.2.3.18. The list contains the SSRCs in the same order as the corresponding user IDs in the List of Granted Users field.

List of Functional Aliases:

The List of Functional Aliases field is used in multi-talker scenario. The List of Functional Aliases field is coded as specified in clause 8.2.3.20 and indicates the list of Functional Aliases that have permission to send media. The list contains the Functional Aliases in the same order as the corresponding user IDs in the List of Granted Users field.

Location:

The Location field is coded as specified in clause 8.2.3.21 and contains the location of the granted party.

List of Locations of granted floor participants:

The List of Locations field is used in a multi-talker scenario. The List of Locations of granted floor participants is coded as specified in clause 8.2.3.22. The list contains the Locations of granted floor participants in the same order as the corresponding user IDs in the List of Granted Users field.

8.2.10 Floor Revoke message

8.2.10.1 General

The Floor Revoke message is sent from the floor control server to the floor participant with the permission to send media to inform that the permission to send media is revoked.

The Floor Revoke message is used in the on-network mode. The Floor Revoke message is only used over the unicast bearer.

Table 8.2.10.1-1 shows the content of the Floor Revoke message.

Table 8.2.10.1-1: Floor Revoke message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of floor control server |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Reject Cause value |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Indicator field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor control server.

The content of the SSRC field is coded as specified in IETF RFC 3550 [3].

Reject Cause:

The Reject Cause field for the Floor Revoke message includes <Reject Cause> cause value in the Reject Cause field explaining why the floor control server wants the floor participant to stop sending media and can be followed by additional information. Therefore the length of the packet can vary depending on the value of the rejection cause.

The coding of the <Reject Cause> value is specified in clause 8.2.3.4.

Track Info:

The Track Info field is included when an MCPTT call involves a non-controlling MCPTT function. The coding of the Track Info field is described in clause 8.2.3.13.

Floor Indicator:

The Floor Indicator field is coded as described in clause 8.2.3.15.

8.2.10.2 Floor revoke cause codes and revoke cause phrases

Cause #1 – Only one MCPTT client

The <Reject Cause> value set to ‘1’ indicates that the MCPTT client is the only MCPTT client in the MCPTT session or the only participant connected to a floor control server. No additional information included.

Cause #2 – Media burst too long

The <Reject Cause> value set to ‘2’ indicates that the MCPTT User has talked too long (e.g., the stop-talking timer has expired). No additional information included.

Cause #3 – No permission to send a Media Burst

The <Reject Cause> value set to ‘3’ indicates that the MCPTT client does not have permission to send media. No additional information is included.

Cause #4 – Media Burst pre-empted

The <Reject Cause> value set to ‘4’ indicates that the MCPTT client ‘s permission to send a media is being pre-empted. No additional information is included.

Cause #6 – No resources available

The <Reject Cause> value set to ‘6’ indicates that the floor control server can no longer grant MCPTT client to send media due to congestion. No additional information is included.

Cause #255 – Other reason

The <Reject Cause> value set to ‘255’ indicates that the floor control server can no longer grant MCPTT client to send media due to the floor control server local policy. No additional information is included.

8.2.11 Floor Queue Position Request message

The Floor Queue Position Request message is a request from a floor participant to get information about the floor participant’s position in the floor request queue.

The Floor Queue Position Request message is used in the off-network mode and in the on-network mode. In the on-network mode the Floor Queue Position Request message is only used over the unicast bearer.

Table 8.2.11-1 shows the content of the Floor Queue Position Request message.

Table 8.2.11-1: Floor Queue Position Request message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of floor participant requesting floor queue status info |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| User ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor participant that is requesting information about its position in the floor request queue.

The SSRC field is coded as specified in IETF RFC 3550 [3].

User ID:

The User ID field is used in off-network only. The User ID field carries the MCPTT user ID of the floor participant sending the Floor Queue Position Request message.

The User ID field is coded as specified in clause 8.2.3.8.

Track Info:

The Track Info field is included when an MCPTT call involves a non-controlling MCPTT function. The coding of the Track Info field is described in clause 8.2.3.13.

8.2.12 Floor Queue Position Info message

The Floor Queue Position Info message is sent by the floor control server to notify the floor participant of its position in the floor request queue.

The Floor Queue Position Info message is used in off-network and in on-network mode. In the on-network mode the Floor Queue Position Info message is only used over the unicast bearer.

Table 8.2.12-1 shows the content of the Floor Queue Position Info message.

Table 8.2.12-1: Floor Queue Position Info message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of floor control server/floor arbitrator |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| User ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of queued floor participant field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Queued User ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Queue Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Indicator field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor control server for on-network and floor arbitrator for off-network.

The SSRC field is coded as specified in IETF RFC 3550 [3].

User ID:

The User ID field is used in off-network only. The User ID field carries the MCPTT ID of the floor participant sending the Floor Queue Position Info message.

The User ID value is coded as specified in clause 8.2.3.8.

SSRC of queued floor participant:

The SSRC of queued floor participant is only applicable in off-network and shall carry the SSRC of the queued floor participant.

The SSRC field shall be coded as specified in clause 8.2.3.16.

Queued User ID:

The Queued User ID field is used in off-network only. The Queued User ID field carries the MCPTT ID of the queued floor participant.

The Queued User ID value is coded as specified in clause 8.2.3.8.

Queue Info:

The Queue Info field defines the queue position and granted floor priority in the queue.

The Queue Info field is coded as specified in clause 8.2.3.5.

Track Info:

The Track Info field is included when an MCPTT call involves a non-controlling MCPTT function. The coding of the Track Info field is described in clause 8.2.3.13.

Floor Indicator:

The Floor Indicator field is coded as described in clause 8.2.3.15.

8.2.13 Floor Ack message

The Floor Ack message is used to acknowledge any floor control message that included the first bit (marked as x in the subtype) set to 1 (see clause 8.2.2).

The Floor Ack message is only used in the on-network mode. The Floor Ack message is only used over the unicast bearer.

Table 8.2.13-1 shows the content of the Floor Ack message.

Table 8.2.13-1: Floor Ack message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of the sender |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Message Type field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Location field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the source identified by the Source field.

The SSRC field is coded as specified in IETF RFC 3550 [3].

Source:

The Source field is coded as specified in clause 8.2.3.12.

Message Type:

The Message Type field contains the floor control message that is acknowledged by the Floor Ack message. The Message Type field is coded as specified in clause 8.2.3.14.

Track Info:

The Track Info field is included when an MCPTT call involves a non-controlling MCPTT function. The coding of the Track Info field is described in clause 8.2.3.13.

Location:

The Location field is coded as described in clause 8.2.3.21 and contains the location information of the granted floor user. This field shall be omitted when location information of the granted floor user is not allowed by the granted floor user’s MCPTT profile, or alternatively may be included with the location type field set to ‘0’ (Not provided).

8.2.14 Floor Release Multi Talker message

The Floor Release Multi Talker message is sent from the floor control server to the floor control participants to indicate that the indicated user has completed media transfer and floor is released.

The Floor Release Multi Talker message is only used in the on-network mode. The Release Multi Talker message is used over both the unicast and MBMS bearer.

Table 8.2.14-1 shows the content of the Floor Release Multi Talker message.

Table 8.2.14-1: Floor Release Multi Talker message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| User ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor Indicator field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor control server for on-network and floor arbitrator for off-network..

The content of the SSRC field is coded as specified in IETF RFC 3550 [3].

User ID:

The User ID carries the MCPTT ID of the floor participant releasing the floor.

The User ID field is coded as specified in clause 8.2.3.8.

Floor Indicator:

The Floor Indicator field is coded as described in clause 8.2.3.15.

8.2.15 Queued Floor Requests message

The Queued Floor Requests message represents a set of purposes (e.g. Cancel request, Cancel result, Cancel notification) that supports an authorized user (e.g dispatcher) to cancel the queued floor request of other MCPTT users; to notify other MCPTT users of their queued requests is being cancelled and to the originator of the request to indicate the status of cancellation of queued floor request.

The Queued Floor Requests message is used in the on-network mode. In the on-network mode the Queued Floor Requests message is only used over the unicast bearer.

Table 8.2.15-1 shows the content of the Queued Floor Requests message.

Table 8.2.15-1: Queued Floor Requests message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of floor participant/floor control server/arbitrator |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Functional Alias field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| List of Queued Users field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Requested Party’s Identity field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Queued Floor Requests Purpose field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Queue Floor Rquests Result field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields is irrelevant.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor participant / floor control server / floor arbitrator.

If the message is for cancellation of a queued floor request, then the SSRC shall be that of the floor participant who is requesting cancellation.

If the message is for notifying the cancellation of a queued floor request to the other floor participants or is a response to a message for cancellation of a queued floor request originated by a floor participant, then the SSRC shall be that of the floor control server / floor arbitrator.

The SSRC field is coded as specified in IETF RFC 3550 [3].

Functional Alias:

This field shall be included if the message is for a cancellation of a queued floor request from a floor participant or is a response to a message for cancellation of a queued floor request originated by a floor participant. The Functional Alias field is coded as described in clause 8.2.3.19.

Track Info:

The Track Info field is included when an MCPTT call involves a non-controlling MCPTT function. The coding of the Track Info field is described in clause 8.2.3.13.

List of Queued Users:

The List of Queued Users field is used only in sending a message for cancellation of a queued floor request of other MCPTT users and for sending a response message to the cancellation of a queued floor request. The List of Queued Users field is coded as specified in clause 8.2.3.24 and indicates the list of users whose request for permission to send media is queued.

In the case of sending a Queued Floor Requests message with a Cancel Result, the List of Queued Users field indicates the list of users whose queued floor requests were not possible to remove and their queued requests still exist in the active floor request queue.

If the request is for clearing all the users queued floor requests, this field is neither included in the request nor the response.

Requested Party’s Identity field:

The Requested Party’s Identity field shall be added only when the Floor Queue Cancel message is originated by a floor participant user. This field shall not be added if the Floor Queue Cancel message is originated by the floor control server (due to local policies). This field is also included when the Queued Floor Requests message is a response to the cancellation of a queued floor request originated by a floor participant. The Requested Party’s Identity field is coded as specified in clause 8.2.3.8.

Queued Floor Requests Purpose field:

The Queued Floor Requests Purpose field is coded as specified in clause 8.2.3.23.

Queued Floor Request Result field:

The Queued Floor Request Result field is included only when sending a response message to the cancellation of a queued floor request originated by a floor participant. The Queued Floor Request Result field is coded as specified in clause 8.2.3.25.

8.2.16 Unicast Media Flow Control message

The Unicast Media Flow Control message is sent from the floor participant to the floor control server to control reception of unicast media flow of the designated communication. The floor participant may use this message to indicate that the unicast media flow of the designated communication does not need to be sent to the MCPTT client. The floor participant may also use this message to request that the unicast media flow of the designated communication is to be sent to the MCPTT client, if it was stopped previously.

The Unicast Media Flow Control message is only used in the on-network mode. The Unicast Media Flow Control message is only used over the unicast bearer.

Table 8.2.16-1 shows the content of the Unicast Media Flow Control message.

Table 8.2.16-1: Unicast Media Flow Control message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of the floor participant sending the message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPT |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| User ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Track Info field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Media Flow Control Indicator field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype is coded according to table 8.2.2-1.

Length:

The length is coded as specified in clause 8.1.2.

SSRC:

The SSRC field carries the SSRC of the floor control server for on-network and floor arbitrator for off-network.

The content of the SSRC field is coded as specified in IETF RFC 3550 [3].

User ID:

The User ID carries the MCPTT ID of the floor participant releasing the floor.

The User ID field is coded as specified in clause 8.2.3.8.

Track Info:

The Track Info field is included when an MCPTT call involves a non-controlling MCPTT function. The coding of the Track Info field is described in clause 8.2.3.13.

Media Flow Control Indicator:

The Floor Indicator field is coded as described in clause 8.2.3.26.

8.3 Pre-established session call control

8.3.1 Introduction

The pre-established session call control messages shall be coded as described in clause 8.1.2 where the pre-established session call control message is part of the application-dependent data.

For the pre-established session call control protocol the ASCII name string shall be: MCPC (Mission Critical Pre-established session call Control).

A list of pre-established session call control messages can be found in the clause 8.3.2.

Pre-established session call control specific fields are specified in clause 8.3.3.

8.3.2 Pre-established session call control message

The table 8.3.2-1 provides a list of call control messages.

Table 8.3.2-1: Pre-established session call control specific messages

Message name	Subtype	Reference	Direction
Connect	x0000	Clause 8.3.4	Server 🡪 client
Disconnect	x0001	Clause 8.3.5	Server 🡪 client
Acknowledge	00010	Clause 8.3.6	Client 🡪 server
NOTE: The participating MCPTT function is the server and the floor participant is the client.

For some messages the first bit (marked as x in the subtype) can be used to indicate if the sender wants to have an acknowledgment. The x is coded as follows:

‘0’ Acknowledgment is not required

‘1’ Acknowledgment is required

NOTE: Whether a message needs to be acknowledged or not is described in clause 9.

If an acknowledgment is required, the Acknowledge message is used to acknowledge the message.

8.3.3 Pre-established session call control fields

8.3.3.1 Introduction

This clause describes the pre-established session call control specific data fields.

The pre-established session call control specific data fields are contained in the application-dependent data of the pre-established session call control message. The pre-established session call control specific data fields follow the syntax specified in clause 8.1.3.

Table 8.3.3.1-1: Void

Table 8.3.3.1-2 lists the available data fields including the assigned field ID.

Table 8.3.3.1-2: Pre-established session call control data fields

Field name		Field ID				Reference
		Decimal		Binary
Media Streams		000		00000000		Clause 8.3.3.2
MCPTT Session Identity		001		00000001		Clause 8.3.3.3
Warning Text		002		00000010		Clause 8.3.3.4
MCPTT Group Identity		003		00000011		Clause 8.3.3.5
Answer State		004		00000100		Clause 8.3.3.6
Inviting MCPTT User Identity		005		00000101		Clause 8.3.3.7
Reason Code		006		00000110		Clause 8.3.3.8
Reason Cause		007		00000111		Clause 8.3.3.11
PCK I_MESSAGE		192		11000000		Clause 8.3.3.10

The following clauses describe the coding of each data field.

8.3.3.2 Media Streams field

The Media Streams field describes which media streams to use in the session. At the minimum one <Media Stream> value shall be included. The <Control Channel> value item is only needed when floor control applies during the MCPTT call.

Table 8.3.3.2-1 describes the coding of the Media Streams field.

Table 8.3.3.2-1: Media Streams field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Media Stream |Media Streams |Media Stream |Control Channel|

|field ID value |length value |value |value |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Media Streams field ID> value is a binary value and shall be set according to table 8.3.3.1-2.

The <Media Streams length> value shall is a binary value indicating the length in octets of the <Media Stream> value and <Control channel> value items.

The <Media Stream> value shall consist of 8 bit parameter giving the number of the" m=audio" m-line negotiated in the pre-established session.

The <Control Channel> value shall consist of 8 bit parameter giving the number of the "m=application" m-line negotiated in the pre-established session. The <Control Channel> value is set to "0" when no floor control is used during the session.

8.3.3.3 MCPTT Session Identity field

The MCPTT Session Identity field contains the MCPTT session identity and the session type.

Table 8.3.3.3-1 describes the coding of the MCPTT Session Identity field.

Table 8.3.3.3-1: MCPTT Session Identity field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|MCPTT session |MCPTT session |Session Type |MCPTT Session |

|identity field |identity field | |Identity |

|ID |length | | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: (Padding) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <MCPTT Session Identity field ID> value is a binary value and shall be set according to table 8.3.3.1-2.

The <MCPTT Session Identity length> value shall is a binary value indicating the length in octets of the <Session Type> value and <MCPTT Session Identity> value items.

The <Session Type> value is coded as follows:

– 00000000 = no session type

– 00000001 = private

– 00000011 = prearranged

– 00000100 = chat

All other values are reserved for future use.

<MCPTT Session Identity> value contains a SIP URI, which identifies the MCPTT session between the MCPTT client and the controlling MCPTT function; see 3GPP TS 24.379 [2] clause 4.5. The <MCPTT Session Identity> value is coded specified in table 8.3.3.3-2.

Table 8.3.3.3-2: ABNF syntax of string values of the <MCPTT Session Identity> value

mcptt-session-identity = SIP-URI

If the length of the <MCPTT Session Identity> value is not (1 + multiple of 4) bytes, the <MCPTT Session Identity> value shall be padded to (1 + multiple of 4) bytes. The value of the padding bytes should be set to zero. The padding bytes shall be ignored.

8.3.3.4 Warning Text field

The Warning Text field contains the text string returned by the controlling MCPTT function in responses to a SIP INVITE request as described in 3GPP TS 24.379 [2] clause 4.4.

Table 8.3.3.4-1 describes the coding of the Warning Text field.

Table 8.3.3.4-1: Warning Text field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Warning Text |Warning Text |Warning Text |

|field ID |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: (Padding) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Warning Text field ID> value is a binary value and shall be set according to table 8.3.3.1-2.

The <Warning Text length> value is a binary value indicating the length in octets of the <Warning Text> value item excluding any padding octets.

The <Warning Text> value shall be coded as specified in 3GPP TS 24.379 [2] table 4.4.2-1.

EXAMPLE: If the Warning: 399 "107 User not authorised to make private calls" is received, "107 User not authorised to make private calls" is included as the <Warning Text> value.

If the length of the <Warning Text> value is not (2 + multiple of 4) bytes, the <Warning Text> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes should be set to zero. The padding bytes shall be ignored.

8.3.3.5 MCPTT Group Identity field

The MCPTT Group Identity field contains a SIP URI identifying the group that an MCPTT client is invited to.

Table 8.3.3.5-1 describes the coding of the MCPTT Group Identity field.

Table 8.3.3.5-1: MCPTT Group Identity field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|MCPTT Group |MCPTT Group |MCPTT Group Identity |

|identity field |identity field | |

|ID |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: (Padding) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <MCPTT Group Identity field ID> value is a binary value and shall be set according to table 8.3.3.1-2.

The <MCPTT Group Identity length> value is a binary value indicating the length in octets of the <MCPTT Group Identity> value item except padding.

<MCPTT Group Identity> value contains the MCPTT group identity or the temporary MCPTT group identity as defined in 3GPP TS 24.379 [2]. The <MCPTT Group Identity> value shall be coded as specified in the table 8.3.3.5-2.

Table 8.3.3.5-2: ABNF syntax of string values of the <MCPTT Group Identity> value

mcptt-group-identity = URI

If the length of the <MCPTT Group Identity> value is not (2 + multiple of 4) bytes, the <MCPTT Group Identity> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes should be set to zero. The padding bytes shall be ignored.

8.3.3.6 Answer State field

The Answer State field indicates if invited MCPTT users are invited using automatic or manual commencement mode.

Table 8.3.3.6-1 describes the coding of the Answer State field.

Table 8.3.3.6-1: Answer State field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Answer State |Answer State |Answer State value |

|field ID value |length value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Answer State field ID> value is a binary value and shall be set according to table 8.3.3.1-2.

The <Answer State length> value is a binary value and shall have the value ‘2’ indicating the total length in octets of the <Answer State> value item.

The <Answer State> value is a 16-bit binary value with the following values:

‘0’ Unconfirmed

‘1’ Confirmed

All other values are reserved for future use.

8.3.3.7 Inviting MCPTT User Identity field

The Inviting MCPTT User Identity field contains the MCPTT ID identifying the inviting MCPTT user.

Table 8.3.3.7-1 describes the coding of the Inviting MCPTT User Identity field.

Table 8.3.3.7-1: Inviting MCPTT User Identity field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Inviting MCPTT |Inviting MCPTT |Inviting MCPTT User Identity |

|User Identity |User Identity | |

|field ID |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: (Padding) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Inviting MCPTT User Identity field ID> value is a binary value and shall be set according to table 8.3.3.1-2.

The <Inviting MCPTT User Identity length> value is a binary value indicating the length in octets of the <MCPTT Group Identity> value item except padding.

The <Inviting MCPTT User Identity> value contains the MCPTT ID of the inviting MCPTT user. The <Inviting MCPTT User Identity> value shall be coded as specified in the table 8.3.3.7-2. The MCPTT ID is specified in 3GPP TS 24.379 [2].

Table 8.3.3.7-2: ABNF syntax of string values of the <Inviting MCPTT User Identity> value

inviting-mcptt-user-identity = URI

If the length of the <Inviting MCPTT User Identity> value is not (2 + multiple of 4) bytes, the <Inviting MCPTT User Identity> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes should be set to zero. The padding bytes shall be ignored.

8.3.3.8 Reason Code field

The Reason Code field contains the answer to a pre-established call control message.

Table 8.3.3.8-1 describes the coding of the Reason Code field.

Table 8.3.3.8-1: Reason Code field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Reason Code |Reason Code |Reason Code value |

|field ID value |length value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Reason Code field ID> value is a binary value and shall be set according to table 8.3.3.1-2.

The <Reason Code length> value is a binary value and shall have the value ‘2’ indicating the total length in octets of the <Reason Code> value item.

The <Reason Code> value is a 16-bit binary value with the following values:

‘0’ Accepted

‘1’ Busy

‘2’ Not Accepted

‘3’ Authentication of the MIKEY-SAKKE I_MESSAGE failed

‘4’ Integrity protection check failed

‘5’ Decrypting XML content failed

All other values are reserved for future use.

8.3.3.9 Handling of unknown fields and messages

When a pre-establish session control message is received the MCPTT client and the participating MCPTT function shall:

1. ignore the whole message, if the subtype is unknown;

2. ignore the unspecified fields in the message (e.g. specified in future version of the pre-establish session control protocol); and

3. ignore the syntactically incorrect optional fields.

8.3.3.10 PCK I_MESSAGE field

The PCK I_MESSAGE field is a MIKEY payload containing a MIKEY-SAKKE I_MESSAGE as defined in IETF RFC 6509 [17] and as received in the SIP INVITE message. The PCK I_MESSAGE contains the PCK and PCK-ID (see 3GPP TS 24.379 [2] clause 4.7).

Table 8.3.3.10-1 describes the coding of the PCK I_MESSAGE field.

Table 8.3.3.10-1: PCK I_MESSAGE field coding

0 1 2 3  

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|PCK I_MESSAGE |PCK I_MESSAGE |PCK I_MESSAGE |

|field ID value |field length value |field value |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| :

: (Padding) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <PCK I_MESSAGE field ID> value is a binary value and shall be set according to table 8.3.3.1-2.

The <PCK I_MESSAGE field length> value is a binary value indicating the length in octets of the <PCK I_MESSAGE field> value item.

The <PCK I_MESSAGE field> value contains the MIKEY-SAKKE I_MESSAGE for PCK as received in the SIP INVITE message.

8.3.3.11 Reason Cause field

The Reason Cause field contains the disconnect or reject reason for the pre-established call. The values can be subset from the Reason Code field contains the answer to a pre-established call control message other than ‘Accepted’ Reason code value as described in clause 8.3.3.8 or any other values.

Table 8.3.3.11-1 describes the coding of the Reason Cause field.

Table 8.3.3.11-1: Reason Cause field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Reason Cause |Reason Cause |Reason Cause value |

|field ID value |length value | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Reason Cause field ID> value is a binary value and shall be set according to table 8.3.3.1-2.

The <Reason Cause length> value is a binary value and shall have the value ‘2’ indicating the total length in octets of the <Reason Cause> value item.

The <Reason Cause> value is a 16-bit binary value with the following values:

‘0’ Busy

‘1’ authentication of the MIKEY-SAKKE I_MESSAGE failed

‘2’ integrity protection check failed

‘3’ unable to decrypt XML content

‘4’ inactivity timer expired

‘5’ there are only one or no participants in the MCPTT call

‘6’ the minimum number of affiliated MCPTT group members is not present

‘7’ group call timer expired

‘8’ the MCPTT session has lasted longer than the maximum duration of a private call

All other values are reserved for future use.

8.3.4 Connect message

The Connect message is sent by the participating MCPTT function on the originating side to the MCPTT client to confirm the establishment of an MCPTT call or sent on the terminating side to initiate an MCPTT call. The Connect message is only used in the on-network mode and only sent over the unicast bearer.

Table 8.3.4-1 shows the content of the Connect message.

Table 8.3.4-1: Connect message

0 1 2 3  

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of participating MCPTT function |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MCPTT Session Identity field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MCPTT Group Identity field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Media Streams field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Warning Text field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Answer State field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Inviting MCPTT User Identity field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| PCK I_MESSAGE field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype shall be coded according to table 8.3.2-1.

Length:

The length shall be coded as specified in to clause 8.1.2.

SSRC:

The SSRC field shall carry the SSRC of the participating MCPTT function.

The SSRC field shall be coded as specified in IETF RFC 3550 [3].

MCPTT Session Identity:

The MCPTT Session Identity field is coded as described in clause 8.3.3.3.

MCPTT Group Identity:

The MCPTT Group Identity field is coded as described in clause 8.3.3.5.

Media Streams:

The Media Streams field is coded as described in clause 8.3.3.2.

Warning Text:

The Warning Text field is coded as described in clause 8.3.3.4.

Answer State:

The Answer State field is coded as described in clause 8.3.3.6.

When the Answer State field is not included the value "confirmed" shall be assumed.

Inviting MCPTT User Identity:

The Inviting MCPTT User Identity field is coded as described in clause 8.3.3.5.

When the inviting MCPTT user requested privacy, the <sip:anonymous@invalid.invalid> identity shall be used.

PCK I_MESSAGE:

The PCK I_MESSAGE is used to transport the PCK and PCK-ID for use in private call.

This field is used when the terminating participating MCPTT function sends the Connect message to the terminating client for a private call.

8.3.5 Disconnect message

Table 8.3.5-1 shows the content of the Connect message.

Table 8.3.5-1: Disconnect message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of participating MCPTT function |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MCPTT Session Identity field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Reason cause field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype shall be coded according to table 8.3.2-1.

Length:

The length shall be coded as specified in clause 8.1.2.

SSRC:

The SSRC field shall carry the SSRC of the participating MCPTT function.

The SSRC field shall be coded as specified in IETF RFC 3550 [3].

MCPTT Session Identity:

The MCPTT Session Identity field is coded as described in clause 8.3.3.3.

Reason Cause:

The Reason Cause field is coded as described in clause 8.3.3.11.

8.3.6 Acknowledge message

Table 8.3.6-1 shows the content of the Acknowledge message.

Table 8.3.6-1: Acknowledge message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of floor participant |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCPC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Reason Code field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words the order of the fields are irrelevant.

Subtype:

The subtype shall be coded according to table 8.3.2-1.

Length:

The length shall be coded as specified in clause 8.1.2.

SSRC:

The SSRC field shall carry the SSRC of the floor participant.

The SSRC field shall be coded as specified in IETF RFC 3550 [3].

Reason Code:

The Reason Code field is coded as described in clause 8.3.3.8.

8.4 MBMS subchannel control

8.4.1 Introduction

The MBMS subchannel control messages shall be coded as described in clause 8.1.2 where the MBMS subchannel control message is part of the application-dependent data.

For the MBMS subchannel control protocol the ASCII name string shall be: MCMC.

The list of MBMS subchannel control messages can be found in the clause 8.4.2.

The MBMS subchannel control specific fields are specified in clause 8.4.3.

8.4.2 MBMS subchannel control messages

Table 8.4.2-1 provides a list of MBMS subchannel control protocol messages.

Table 8.4.2-1: MBMS subchannel control protocol messages

Message name	Subtype	Reference	Direction
Map Group To Bearer	00000	clause 8.4.4	Server 🡪 client
Unmap Group To Bearer	00001	clause 8.4.5	Server 🡪 client
Application Paging	00010	clause 8.4.6	Server 🡪 client
Bearer Announcement	00011	clause 8.4.7	Server 🡪 client
NOTE: The participating MCPTT function is the server and the MCPTT client is the client.

8.4.3 MBMS subchannel control specific fields

8.4.3.1 Introduction

This clause describes the MBMS subchannel control specific data fields.

The MBMS subchannel control specific data fields are contained in the application-dependent data of the MBMS subchannel control message. The MBMS subchannel control specific data fields follow the syntax specified in clause 8.1.3.

Table 8.4.3.1-1: Void

Table 8.4.3.1-2 lists the available fields including the assigned Field ID.

Table 8.4.3.1-2: MBMS subchannel control specific data fields

Field name	Field ID		Description
	Decimal	Binary
MBMS Subchannel	000	00000000	Clause 8.4.3.3
TMGI	001	00000001	Clause 8.4.3.4.
MCPTT Group ID	002	00000010	Clause 8.4.3.2
Monitoring State	003	00000011	Subcaluse 8.4.3.6

8.4.3.2 MCPTT Group ID field

The MCPTT Group ID field contains a SIP URI identifying the MCPTT group for which media and floor control messages are going to be broadcasted over a MBMS subchannel.

The MCPTT Group ID field is coded as the MCPTT Group Identity field specified in clause 8.3.3.5.

8.4.3.3 MBMS Subchannel field

The MBMS Subchannel field describes which MBMS subchannel to use for media and for floor control.

Table 8.4.3.3-1 describes the coding of the MBMS Subchannel field.

Table 8.4.3.3-1: MBMS Subchannel field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|MBMS Subchannel|MBMS Subchannel|Audio |Floor |IP | spare |

|field ID value |length value |m-line |m-line |Version| |

| | |Number |Number | | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Floor control Port Number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Media Port Number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: IP Address :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <MBMS Subchannel field ID> value is a binary value and shall be set according to table 8.4.3.1-2.

The <MBMS Subchannel length> value is a binary value indicating the total length in octets of the <Audio m-line Number> value, <IP Version> value, spare, <Port Number> value and <IP address> items.

The <Audio m-line Number> value shall consist of 4 bit parameter giving the number of the" m=audio" m-line in the SIP MESSAGE request announcing the MBMS bearer described in 3GPP TS 24.379 [2].

The <Floor m-line Number> value shall consist of 4 bit parameter giving the number of the "m=application" m-line in the SIP MESSAGE request announcing the MBMS bearer described in 3GPP TS 24.379 [2]. The <Floor m-line Number> value is set to "0" when the same subchannel is used for media and for floor control.

The <IP version> value indicates the IP version:

‘0’ IP version 4

‘1’ IP version 6

All other values are reserved for future use.

The "spare" 4 bits shall be set to "0000".

The <Floor control Port Number> value is a 32-bit binary value giving the port to be used if the<Floor m-line Number> value is greater than ‘0’. If the <Floor m-line Number> value is equal to ‘0’, the <Floor control Port Number> value is not included in the MBMS Subchannel field.

The <Media Port Number> value is a 32-bit binary value giving the port to be used. The <Media Port Number> value is always present in the MBMS Subchannel field.

The <IP Address> value is:

1. a 32 bit binary value containing the IP v4 address if the <IP version> indicates that the <IP Address> value is a IP v4 Address; or

2. four 32-bit words that together forms a 128 bit binary value representing the IP v6 address, if the <IP version> indicates that the <IP Address> value is a IP v6 Address

8.4.3.4 TMGI field

Table 8.4.3.4-1 describes the coding of the TMGI field.

Table 8.4.3.4-1: TMGI field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|TMGI |TMGI |TMGI |

|ID |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: (Padding) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <TMGI field ID> value is a binary value and shall be set according to table 8.4.3.1-2.

The <TMGI length> value is a binary value indicating the length in octets of the <TMGI> value item except padding.

The <TMGI> value is coded as described in 3GPP TS 24.008 [11] clause 10.5.6.13 excluding the Temporary Mobile Group Identity IEI and Length of Temporary Mobile Group Identity contents (octet 1 and octet 2 in 3GPP TS 24.008 [11] clause 10.5.6.13).

If the length of the <TMGI> value is not (2 + multiple of 4) bytes, the <TMGI> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes should be set to zero. The padding bytes shall be ignored.

8.4.3.5 Void

8.4.3.6 Monitoring state

Table 8.4.3.6-1 describes the coding of the Monitoring State field.

Table 8.4.3.6-1: Monitoring State field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Monitoring |length=1 |Monitoring |Spare |

|State ID | |State | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Monitoring State field ID> value is a binary value and shall be set according to table 8.4.3.1-2.

The <Monitoring State length> value is a binary value indicating the length in octets of the <Monitoring State> value item.

The <Monitoring State> value is a binary value where the following values are defined:

‘0’ Monitoring is inactive

‘1’ Monitoring is active

All other values are reserved for future use.

The spare bits are set to zero

8.4.4 Map Group To Bearer message

The Map Group To Bearer message is sent by the participating function when a conversation is started.

Table 8.4.4-1 shows the content of the Map Group To Bearer message.

Table 8.4.4-1: Map Group To Bearer message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype| PT=APP=204 | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of participating MCPTT function |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCMC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MCPTT Group ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TMGI field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MBMS Subchannel field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words, the order of the fields are irrelevant.

Subtype:

The subtype shall be coded according to table 8.4.2-1.

Length:

The length shall be coded as specified in clause 8.1.2.

SSRC:

The SSRC field shall carry the SSRC of the participating MCPTT function.

The SSRC field shall be coded as specified in IETF RFC 3550 [3].

MCPTT Group ID:

The MCPTT Group ID field is coded as described in clause 8.4.3.2.

TMGI:

The TMGI field is coded as described in clause 8.4.3.4.

MBMS Subchannel:

The MBMS Subchannel field is coded as described in clause 8.4.3.3.

8.4.5 Unmap Group To Bearer message

The Unmap Group To Bearer message is sent by the participating function when a conversation is ended.

Table 8.4.5-1 shows the content of the Unmap Group To Bearer message.

Table 8.4.5-1: Unmap Group To Bearer message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length=3 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of participating MCPTT function |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCMC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MCPTT Group ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words, the order of the fields are irrelevant.

Subtype:

The subtype shall be coded according to table 8.4.2-1.

Length:

The length shall be coded as specified in clause 8.1.2.

SSRC:

The SSRC field shall carry the SSRC of the participating MCPTT function.

The SSRC field shall be coded as specified in IETF RFC 3550 [3].

MCPTT Group ID:

The MCPTT Group ID field is coded as described in clause 8.4.3.2.

8.4.6 Application Paging message

The Application Paging message is sent by the participating function when an existing conversation is to be moved to unicast bearers or a new conversation is to be started on unicast bearers.

Table 8.4.5-1 shows the content of the Application Paging message.

Table 8.4.6-1: Application Paging message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length=3 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of participating MCPTT function |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCMC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MCPTT Group ID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words, the order of the fields is irrelevant.

Subtype:

The subtype shall be coded according to table 8.4.2-1.

Length:

The length shall be coded as specified in clause 8.1.2.

SSRC:

The SSRC field shall carry the SSRC of the participating MCPTT function.

The SSRC field shall be coded as specified in IETF RFC 3550 [3].

MCPTT Group ID:

The MCPTT Group ID field is coded as described in clause 8.4.3.2.

8.4.7 Bearer Announcement message

The Bearer Announcement message is sent by the participating function on an MBMS bearer for application control messages. It may be sent by the participating function in order to achieve a faster setup of the MBMS bearer

Table 8.4.7-1 shows the content of the Bearer Announcement message.

Table 8.4.7-1: Bearer Announcement message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype | PT=APP=204 | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCMC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TMGI |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Alternative TMGI fields |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Monitoring State |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words and the internal order of the TMGI field and the Alternative TMGI fields, the order of the fields is irrelevant.

Subtype:

The subtype shall be coded according to table 8.4.2-1.

Length:

The length shall be coded as specified in clause 8.1.2.

TMGI:

The TMGI field is coded as described in clause 8.4.3.4. This field is mandatory.

Alternative TMGI:

Zero or more alternative TMGI fields are coded as described in clause 8.4.3.4. This field is coded immediately after the TMGI field.

Monitoring State:

The monitoring state field is coded as described in clause 8.4.3.6.

8.5 MBMS notifications

8.5.1 Introduction

The MBMS notifications messages shall be coded as described in clause 8.1.2 where the MBMS notifications message is part of the application-dependent data.

For the MBMS notifications protocol the ASCII name string shall be: MCNC.

The list of MBMS notifications messages can be found in the clause 8.5.2.

The MBMS notifications specific fields are specified in clause 8.5.3.

8.5.2 MBMS notifications control messages

Table 8.5.2-1 provides a list of MBMS notifications protocol messages.

Table 8.5.2-1: MBMS notifications protocol messages

Message name	Subtype	Reference	Direction
Group Dynamic Data Notify	00000	clause 8.5.4	Server 🡪 client
NOTE: The participating MCPTT function is the server and the MCPTT client is the client.

8.5.3 MBMS notifications control specific fields

8.5.3.1 Introduction

This clause describes the MBMS notifications control specific data fields.

The MBMS notifications control specific data fields are contained in the application-dependent data of the MBMS notifications control message. The MBMS notifications control specific data fields follow the syntax specified in clause 8.1.3.

Table 8.5.3.1-1 lists the available fields including the assigned Field ID.

Table 8.5.3.1-1: MBMS notifications control specific data fields

Field name	Field ID		Description
	Decimal	Binary
Status	000	00000000	Clause 8.5.3.2
Status changing MCPTT User Identity	001	00000001	Clause 8.5.3.3
Group call ongoing	002	00000010	Clause 8.5.3.4
Group broadcast alias	003	00000011	Clause 8.5.3.5
Group regroup alias	004	00000100	Clause 8.5.3.6

8.5.3.2 Status field

The Status field indicates the indication of the status of the group and also includes the MCPTT ID of the user that last changed the status of the group.

Table 8.5.3.2-1 describes the coding of the Status field.

Table 8.5.3.2-1: Status field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Status |Status | Status |

|field ID |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

:User ID :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Status field ID> value is a binary value and is set according to table 8.5.3.1-1.

The <Status length> value is a binary value and shall have the value ‘2’ indicating the total length in octets of the <Status> value item.

The <Status> value is a 16 bit binary value where:

‘0’ emergency

‘1’ in-peril

All other values are reserved for future use.

8.5.3.3 Status changing MCPTT User Identity field

The Status changing MCPTT User Identity field contains the MCPTT ID identifying the Status changing MCPTT user.

Table 8.5.3.3-1 describes the coding of the Status changing MCPTT User Identity field.

Table 8.5.3.3-1: Status changing MCPTT User Identity field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Status changing|Status changing|Status changing MCPTT |

|MCPTT User |MCPTT User |User Identity |

|Identity field |Identity length| |

|ID | | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: (Padding) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Status changing MCPTT User Identity field ID> value is a binary value and shall be set according to table 8.5.3.1-1.

The <Status changing MCPTT User Identity length> value is a binary value indicating the length in octets of the <MCPTT Group Identity> value item except padding.

The <Status changing MCPTT User Identity> value contains the MCPTT ID of the Status changing MCPTT user. The <Status changing MCPTT User Identity> value shall be coded as specified in the table 8.5.3.3-2. The MCPTT ID is specified in 3GPP TS 24.379 [2].

Table 8.5.3.3-2: ABNF syntax of string values of the <Status changing MCPTT User Identity> value

status-changing-mcptt-user-identity = URI

If the length of the <Status changing MCPTT User Identity> value is not (2 + multiple of 4) bytes, the <Status changing MCPTT User Identity> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes should be set to zero. The padding bytes shall be ignored.

8.5.3.4 Group call ongoing field

Table 8.5.3.4-1 describes the coding of the Monitoring State field.

Table 8.5.3.4-1: Group call ongoing field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Group call |length=1 |Group call |Spare |

|ongoing ID | |ongoing | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The < Group call ongoing field ID> value is a binary value and shall be set according to table 8.5.3.1-1.

The <length> value is a binary value indicating the length in octets of the <Group call ongoing> value item and is set to ‘1’.

The <Group call ongoing> value is a binary value where the following values are defined:

‘0’ No Group call ongoing

‘1’ Group call ongoing

All other values are reserved for future use.

The spare bits are set to zero

8.5.3.5 Group broadcast alias field

The Group broadcast alias field contains the URI identifying the Group broadcast alias.

Table 8.5.3.5-1 describes the coding of the Group broadcast alias field.

Table 8.5.3.5-1: Group broadcast alias field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Group Broadcast|Group Broadcast|Group Broadcast alias |

|alias field ID |alias field | |

| |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: (Padding) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Group broadcast alias field ID> value is a binary value and shall be set according to table 8.5.3.1-1.

The <Group broadcast alias length> value is a binary value indicating the length in octets of the <Group broadcast alias> value item except padding.

The <Group broadcast alias> value contains the URI of the group broadcast alias. The <Group broadcast alias> value shall be coded as specified in the table 8.5.3.5-2. The group broadcast alias is specified in 3GPP TS 23.280 [23].

Table 8.5.3.5-2: ABNF syntax of string values of the <Group broadcast alias> value

group-broadcast-alias = URI

If the length of the <Group broadcast alias> value is not (2 + multiple of 4) bytes, the <Group broadcast alias> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes should be set to zero. The padding bytes shall be ignored.

8.5.3.6 Group regroup alias field

The Group regroup alias field contains the URI identifying the Group regroup alias.

Table 8.5.3.6-1 describes the coding of the Group regroup alias field.

Table 8.5.3.6-1: Group regroup alias field coding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Group regroup |Group regroup |Group regroup alias |

|alias field |alias field | |

|ID |length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

: (Padding) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <Group regroup alias field ID> value is a binary value and shall be set according to table 8.5.3.1-1.

The <Group regroup alias length> value is a binary value indicating the length in octets of the <Group regroup alias> value item except padding.

The <Group regroup alias> value contains the URI of the group regroup alias. The <Group regroup alias> value shall be coded as specified in the table 8.5.3.6-2. The Group regroup alias is specified in 3GPP TS 23.280 [23].

Table 8.5.3.6-2: ABNF syntax of string values of the <Group regroup alias> value

group-regroup-alias = URI

If the length of the <Group regroup alias> value is not (2 + multiple of 4) bytes, the <Group regroup alias> value shall be padded to (2 + multiple of 4) bytes. The value of the padding bytes should be set to zero. The padding bytes shall be ignored.

8.5.4 Group Dynamic Data Notify message

The Group Dynamic Data Notify message is sent by the participating function when a conversation is started.

Table 8.5.4-1 shows the content of the Group Dynamic Data Notify message.

Table 8.5.4-1: Group Dynamic Data Notify message

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P| Subtype| PT=APP=204 | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| SSRC of participating MCPTT function |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| name=MCNC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Status field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Status changing MCPTT User Identity field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MCPTT Group ID field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Group call ongoing field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Group broadcast alias field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Group regroup alias field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the exception of the three first 32-bit words, the order of the fields are irrelevant.

Subtype:

The subtype shall be coded according to table 8.5.2-1.

Length:

The length shall be coded as specified in clause 8.1.2.

SSRC:

The SSRC field shall carry the SSRC of the participating MCPTT function.

The SSRC field shall be coded as specified in IETF RFC 3550 [3].

MCPTT Group ID

The MCPTT Group ID field contains a SIP URI identifying the group that the group dynamic is related to.

The MCPTT Group ID field is coded as the MCPTT Group Identity field specified in clause 8.3.3.5.

Status:

The Status field is coded as described in clause 8.5.3.2.

Status changing MCPTT User Identity:

The Status changing MCPTT User Identity is coded as described in clause 8.5.3.3.

Group call ongoing:

The Group call ongoing field is coded as described in clause 8.5.3.4.

Group broadcast alias field:

The Group broadcast alias field is coded as described in clause 8.5.3.5

Group regroup alias field:

The Group regroup alias field is coded as described in clause 8.5.3.6