9 Coding

24.5813GPPMission Critical Video (MCVideo) media plane controlProtocol specificationRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

9.1 Introduction

9.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 9.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.

9.1.2 RTCP: APP message format

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

Table 9.1.2-1 shows the RTCP APP packet format.

Table 9.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

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

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

| SSRC |

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

| name (ASCII) |

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

| application-dependent data |

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

| Secure RTCP message part |

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

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 = "MCV0" (i.e. Transmission control messages sent by the transmission control participant to the transmission control server): Table 9.2.2.1-1;

– Name field = "MCV1" (i.e. Transmission control messages sent by the transmission control server and transmission control participant): Table 9.2.2.1-2;

– Name field = "MCV2" (i.e. Transmission control messages sent by transmission control participant to the transmission control server and by the transmission control server to the transmission control participant): Table 9.2.2.1-3; and

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

– Name field= "MCV4" (i.e. Notification control): Table 9.4.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 transmission 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 transmission control protocol messages sent by the client to the server specified in the present document the ASCII name string is: MCV0;

2. For the transmission control protocol messages sent by the server to the client specified in the present document the ASCII name string is: MCV1; and

3. For the transmission control protocol messages sent by both the client to the server and the server to the client specified in the present document the ASCII name string is: MCV2; and

4. For the MBMS subchannel control protocol specified in the present document the ASCII name string is: MCV3.

Application-dependent data

The application-dependent data contains zero or more application specific data fields is specified in clause 9.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 x and in IETF RFC 3711 [4].

9.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 9.1.3-1 shows the application dependent data field structure when the field ID is less than 192. Table 9.1.3-2 shows the application dependent data field structure when the field ID is equal to or greater than 192.

Table 9.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 9.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 > :

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

9.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.

9.2 Transmission control

9.2.1 Introduction

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

For the transmission control protocol the ASCII name string is: MCVx (Mission Critical Video x) with x=0, 1 or 2 as specified in clause 9.1.2.

A list of transmission control messages can be found in clause 9.2.2.1.

The transmission control specific fields are specified in clause 9.2.3.

9.2.2 Transmission control messages

9.2.2.1 General

The table 9.2.2.1-1 provides a list of transmission control messages sent by the transmission participant.

Table 9.2.2.1-1: Transmission control specific messages sent by the transmission participant

Message name	Subtype	Reference	Direction
Transmission Request	x0000	Clause 9.2.4	Client 🡪 server
Transmission Release	x0010	Clause 9.2.7	Client 🡪 server
Queue Position Request	x0011	Clause 9.2.11	Client 🡪 server
Receive media request	x0100	Clause 9.2.14	Client 🡪 server
void	x0101	void	void
Remote Transmission request	x0111	Clause 9.2.22	Client 🡪 server
Remote Transmission cancel request	x1000	Clause 9.2.24	Client 🡪 server
NOTE: The transmission control server is the server and the transmission participant is the client.

The table 9.2.2.1-2 provides a list of transmission control messages sent by the transmission control server.

Table 9.2.2.1-2: Transmission control specific messages sent by the transmission control server

Message name	Subtype	Reference	Direction
Transmission Granted	x0000	Clause 9.2.5	Server 🡪 client
Transmission Rejected	x0001	Clause 9.2.6	Server 🡪 client
Transmission Arbitration Taken	x0010	Clause 9.2.8	Server 🡪 client
Transmission Arbitration Release	x0011	Clause 9.2.9	Server 🡪 client
Transmission Revoked	x0100	Clause 9.2.10	Server 🡪 client
Queue Position Info	x0101	Clause 9.2.12	Server 🡪 client
Media transmission notification	x0110	Clause 9.2.13	Server 🡪 client
Receive media response	x0111	Clause 9.2.15	Server 🡪 client
Media reception notification	x1000	Clause 9.2.16	Server 🡪 client
void	x1001	void	void
Transmission cancel request notify	x1010	Clause 9.2.19	Server 🡪 client
Remote Transmission response	x1011	Clause 9.2.23	Server 🡪 client
Remote Transmission cancel response	x1100	Clause 9.2.25	Server 🡪 client
Media reception override notification	x1101	Clause 9.2.28	Server 🡪 client
Transmission end notify	x1110	Clause 9.2.29	Server 🡪 client
Transmission idle	x1111	Clause 9.2.30	Server 🡪 client
NOTE: The transmission control server is the server and the transmission participant is the client.

The table 9.2.2.1-3 provides a list of transmission control messages sent by both the transmission control server and transmission control participant.

Table 9.2.2.1-3: Transmission control specific messages sent by both the transmission control server and transmission control participant

Message name	Subtype	Reference	Direction
Transmission end request	x0000	Clause 9.2.20	Client 🡪 server and Server 🡪 client
Transmission end response	x0001	Clause 9.2.21	Client 🡪 server and Server 🡪 client
Media reception end request	x0010	Clause 9.2.26	Client 🡪 server and Server 🡪 client
Media reception end response	x0011	Clause 9.2.27	Client 🡪 server and Server 🡪 client
Transmission control ack	00100	Clause 9.2.31	Client 🡪 server and Server 🡪 client
NOTE: The transmission control server is the server and the transmission 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 6.

If an acknowledgment is required the Transmission control ack message is used to acknowledge the message.

9.2.3 Transmission control specific fields

9.2.3.1 Introduction

This clause describes the transmission control specific data fields.

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

Table 9.2.3.1-1 lists the available transmission control specific data fields including the assigned field ID.

Table 9.2.3.1-1: Transmission control specific data fields

Field name	Field ID		Reference
	Decimal	Binary
Transmission Priority	000	00000000	Clause 9.2.3.2
Duration	001	00000001	Clause 9.2.3.3
Reject Cause	002	00000010	Clause 9.2.3.4
Queue Info	003	00000011	Clause 9.2.3.5
Granted Party’s Identity	004	00000100	Clause 9.2.3.6
Permission to Request the Transmission	005	00000101	Clause 9.2.3.7
User ID	006	00000110	Clause 9.2.3.8
Queue Size	007	00000111	Clause 9.2.3.15
Message Sequence-Number	008	00001000	Clause 9.2.3.9
Queued User ID	009	00001001	Clause 9.2.3.14
Source	010	00001010	Clause 9.2.3.12
Track Info	011	00001011	Clause 8.2.3.13
Message Type	012	00001100	Clause 9.2.3.10
Transmission Indicator	013	00001101	Clause 9.2.3.11
SSRC	014	00001110	Clause 9.2.3.16
Result	015	00001111	Clause 9.2.3.17
Message Name	016	00010000	Clause 9.2.3.18
Overriding ID	017	00010001	Clause 9.2.3.8
Overridden ID	018	00010010	Clause 9.2.3.8
Reception Priority	019	00010011	Clause 9.2.3.19
MCVideo Group Identity	020	00010100	Clause 9.2.3.20
Functional Alias field ID	021	00010101	Clause 9.2.3.21
Reception Mode	022	00010110	Clause 9.2.3.22

The following clauses describe the coding of each field.

9.2.3.2 Transmission Priority field

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

Table 9.2.3.2-1 describes the coding of the Transmission Priority field.

Table 9.2.3.2-1: Transmission 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

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

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

The <Transmission Priority field ID> value is a binary value and is set according to table 9.2.3.1-1.

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

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

1. for on-network by the transmission control server as described in clause x.y; and

2. for off-network by the transmission arbitrator as described in clause y.z.

The spare bits are set to zero.

9.2.3.3 Duration field

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

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

Table 9.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 9.2.3.1-1.

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.

9.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 transmission control message dependent and is described per individual transmission control message carrying the Reject Cause field.

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

Table 9.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 9.2.3.1-1.

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 9.2.6.2 for Transmission Rejected message and as defined in clause 9.2.10.2 for Transmission Revoked 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 Cause> value is not (2 + multiple of 4) bytes, the Reject Cause field is 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.

9.2.3.5 Queue Info field

The Queue Info field includes information about the position for one MCVideo client in the transmission control queue and the priority of the transmission request.

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

Table 9.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

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

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

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

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 MCVideo client is not queued. The <Queue Position Info> value has the max value (‘255’) if the MCVideo client is queued but the MCVideo server is unable to determine the queue position or if MCVideo server policy is not to release information of the queue position to the MCVideo client.

The <Queue Priority Level> value is coded as the <Transmission Priority> value in clause 9.2.3.2.

9.2.3.6 Granted Party’s Identity field

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

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

Table 9.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 9.2.3.1-1.

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

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

If the length of the <Granted Party’s> value is not (2 + multiple of 4) bytes, the Granted Party’s Identity field 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.

9.2.3.7 Permission to Request the Transmission field

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

Table 9.2.3.7-1 describes the coding of the Permission to Request the Transmission field.

Table 9.2.3.7-1: Permission to Request the Transmission 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 Transmission value |

|Transmission field ID |Transmission length | |

| |value | |

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

The <Permission to Request the Transmission field ID> value is a binary value and is set according to table 9.2.3.1-1.

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

The <Permission to Request the Transmission> value is binary and coded as follows:

0 The receiver is not permitted to request transmission.

1 The receiver is permitted to request transmission.

9.2.3.8 User ID field

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

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

Table 9.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 9.2.3.1-1.

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 9.2.3.8-2.

Table 9.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 field 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.

9.2.3.9 Message Sequence Number field

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

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

Table 9.2.3.9-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 9.2.3.1-1.

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.

9.2.3.10 Message Type field

The Message Type field contains the transmission control message type of the message that is acknowledged.

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

Table 9.2.3.10-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

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

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

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

The <Message Type Length> value is a binary value and has the value ‘2’.

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 9.2.2.1-1, table 9.2.2.1-2 and table 9.2.2.1-3 (including the first bit (used by some transmission control messages to indicate that a Transmission control Ack message is requested) of the five bit subtype) preceeded by "000".

The spare bits are set to zero.

9.2.3.11 Transmission Indicator field

The Transmission Indicator contains additional information about a received transmission control message.

Table 9.2.3.11-1 describes the coding of the Transmission Indicator field.

Table 9.2.3.11-1: Transmission 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

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

|Transmission |Transmission |Transmission Indicator value |

|Indicator |Indicator | |

|field ID value |Length value | |

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

The <Transmission Indicator field ID> value is a binary value and is set according to table 9.2.3.1-1.

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

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

Table 9.2.3.11-2: Transmission 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

NOTE 1: The indicators C, D and E are only informative. There are no procedures specified for the C, D and E indicators in this release of the present document and the use of the indicators are implementation specific.

Bits F 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 transmission control server decides which combinations are possible and the priority of the indications.

9.2.3.12 Source field

The Source field contains the source of the message.

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

Table 9.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 |

|field ID |length | |

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

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

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 transmission participant is the source

‘1’ the participating MCVideo function is the source

‘2’ the controlling MCVideo function is the source

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

All other values are reserved for future use.

9.2.3.13 Track Info field

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

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

Table 9.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

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

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

| Participant Type |

: :

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

| Transmission Participant Reference 1 |

: | :

| Transmission 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 and one or more <Transmission Participant Reference> value items.

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

‘0’ the transmission participant in the MCVideo client does not support queueing

‘1’ the transmission participant in the MCVideo 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.

The <Participant Type> value is string coded as specified in table 9.2.3.13-1:

Table 9.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 MCVideo service provider specific and out of scope of the present document.

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

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

9.2.3.14 Queued User ID field

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

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

Table 9.2.3.14-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 9.2.3.1-1.

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

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

If the length of the <Queued User ID> value is not (2 + multiple of 4) bytes, the Queued User ID field 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.

9.2.3.15 Queue Size field

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

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

Table 9.2.3.15-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 |

|field ID |length | |

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

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

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.

9.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 9.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 |

|field ID |length | |

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

| SSRC |Spare |

| |

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

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

The <SSRC length> value is a binary value and has the value ‘6’.

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

The spare bits are set to zero.

9.2.3.17 Result

The Result field conveys the result of the operation (e.g. success, failure).

Table 9.2.3.17-1 describes the coding of the Result field.

Table 9.2.3.17-1: 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

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

|Result |Result |Result |

|field ID value |Length value |value |

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

The <Result field ID> value is a binary value and is set according to table 9.2.3.1-1.

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

The <Result> value is binary and is coded as follows:

0 The receiver is not permitted (rejected) to receive the media transmission.

1 The receiver is permitted (granted) to receive the media transmission.

9.2.3.18 Message Name field

The Message Name field contains the transmission control message name of the message that is acknowledged.

Table 9.2.3.18-1 describes the coding of the Message Name field.

Table 9.2.3.18-1: Message Name 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 Name |Message Name |Message Name |

|field ID value |Length value |value |

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

| Message Name value | Spare |

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

The <Message Name field ID> value is a binary value and is set according to table 9.2.3.1-1.

The <Message Name Length> value is a binary value and has the value ‘6’.

The <Message Name> value is as coded as the ascii name field in table 9.1.2-1.

The spare bits are set to zero.

9.2.3.19 Reception Priority field

The Reception Priority field describes the level of reception priority requested in a Reception Request message or granted in a Reception Granted message. The max reception priority that can be requested in a Reception Request message is negotiated between the transmission control participant and the transmission control server as specified in clause 14.

Table 9.2.3.19-1 describes the coding of the Reception Priority field.

Table 9.2.3.19-1: Reception 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

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

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

The < Reception Priority field ID> value is a binary value and is set according to table 9.2.3.1-1.

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

The < Reception Priority> value consists of 8 bit parameter giving the reception priority (‘0’ to ‘255’) where ‘0’ is the lowest reception priority and ‘255’ is the highest reception priority. If the Reception Priority field is not included in the message the default reception priority is used as the Reception Priority value. The value of the default reception priority is ‘0’. The default reception priority is sometimes referred to as normal reception priority.

The spare bits are set to zero.

9.2.3.20 MCVideo Group Identity field

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

Table 9.2.3.20-1 describes the coding of the MCVideo Group Identity field.

Table 9.2.3.20-1: MCVideo 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

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

|MCVideo Group |MCVideo Group |MCVideo Group Identity |

|identity field |identity field | |

|ID |length | |

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

: (Padding) :

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

The <MCVideo Group Identity field ID> value is a binary value and shall be set according to table 9.2.3.1-1.

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

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

Table 9.2.3.20-2: ABNF syntax of string values of the <MCVideo Group Identity> value

mcvideo-group-identity = URI

If the length of the <MCVideo Group Identity> value is not (2 + multiple of 4) bytes, the <MCVideo 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.

9.2.3.21 Functional Alias field

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

Table 9.2.3.3-1: Functional Alias 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

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

| Functional |Functional | Functional Alias |

|Alias field |Alias length | value :

|ID value |value | :

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

: :

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

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

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 9.2.3.3-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 set to zero. The padding bytes are ignored by the receiver.

9.2.3.22 Reception Mode Field

Reception Mode indicates whether the receiving party is granted permission to automatically receive RTP media packets from another transmission participant or not.

Table 9.2.3.22-1 describes the coding of the Permission to Request the Transmission field.

Table 9.2.3.22-1: Reception Mode 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

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

|Reception |Reception |Reception Mode value |

|Mode |Mode | |

|field ID value |Length value | |

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

The <Reception Mode field ID> value is a binary value and is set according to table 9.2.3.1-1.

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

The < Reception Mode > value is binary and coded as follows:

0 The receiver is granted permission to automatically receive media.

1 The receiver is not granted permission to automatically receive media.

9.2.4 Transmission Request message

The Transmission Request message is a request from a transmission participant to get permission to send media.

Table 9.2.4-1 shows the content of the Transmission Request message.

Table 9.2.4-1: Transmission 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

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

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

| SSRC of participant sending the Transmission Request message |

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

| name=MCV0 |

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

| Transmission Priority field |

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

: User ID field :

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

| Transmission Indicator field |

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

| Functional Alias 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 9.2.2.1-1.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission participant sending the Transmission Request message.

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

Transmission priority:

The Transmission Priority field is coded as described in clause 9.2.3.2.

User ID:

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

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

Functional Alias:

The Functional Alias field carries the functional alias URI of the transmitting user. The Functional Alias field is coded as described in clause 9.2.3.21

9.2.5 Transmission Granted message

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

Table 9.2.5-1 shows the content of the Transmission Granted message.

Table 9.2.5-1: Transmission 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

| Duration field |

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

| SSRC of granted transmission participant field |

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

| Transmission Priority field |

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

| User ID field |

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

| Queue Size field |

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

| SSRC of queued transmission participant field |

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

| Queued User ID field |

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

| Queue Info field |

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

| Transmission 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 transmission participant field, Queued User ID field and the Queue Info field shall be kept together.

Subtype:

The subtype is coded according to table 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field shall carries the SSRC of the transmission control server.

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 9.2.3.3.

SSRC of granted transmission participant:

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

Transmission Priority:

The Transmission Priority field contains the granted transmission priority and is coded as specified in clause 9.2.3.2.

User ID:

The User ID field is used in off-network only. The User ID field shall carries the MCVideo ID of the transmission participant granted the transmission. The User ID field is coded as described in clause 9.2.3.8.

Queue Size:

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

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

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

1. the SSRC of queued transmission participant;

2. the Queued User ID field; and

3. the Queue info field.

SSRC of queued transmission participant:

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

The content of the SSRC of queued transmission 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 MCVideo ID of the transmission participant in the queue.

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

Queue Info:

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

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

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

9.2.6 Transmission Rejected message

9.2.6.1 General

The Transmission Rejected message is sent as an action from the transmission control server to the requesting transmission participant to inform that the transmission request was rejected.

Table 9.2.6.1-1 shows the content of the Transmission Rejected message.

Table 9.2.6.1-1: Transmission Rejected 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

| Reject Cause field |

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

| User ID field |

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

| Transmission 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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

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

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 transmission request and can be followed by a text-string explaining why the transmission 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 9.2.6.2. The Reject Cause field is coded as described in clause 9.2.3.4.

User ID:

The User ID field is used in off-network only. The User ID carries the MCVideo ID of the requesting transmission participant to which the Transmission Rejected message is sent.

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

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

9.2.6.2 Rejection cause codes and rejection cause phrase

Cause #1 – Transmission limit reached

The <Reject cause> value set to ‘1’ indicates that the number of transmitters have reached maximum.

Cause #2 – Internal transmission control server error

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

Cause #3 – Only one participant

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

Cause #4 – Retry-after timer has not expired

The <Reject cause> value set to ‘4’ indicates that the transmission control server cannot grant the transmission 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 transmission control server cannot grant the transmission request, because the requesting party only has receive privilege.

Cause #6 – No resources available

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

Cause #255 – Other reason

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

9.2.7 Transmission Release message

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

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

Table 9.2.7-1 shows the content of the Transmission Release message.

Table 9.2.7-1: Transmission 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

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

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

| SSRC of participant with permission to send media |

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

| name=MCV0 |

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

| User ID field |

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

| Transmission 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 9.2.2.1-1.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission 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 MCVideo ID of the transmission participant sending the Transmission Release message.

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

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

9.2.8 Transmission Arbitration Taken message

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

In case of off-network, the transmission arbitrator acts as the transmission control server.

Table 9.2.8-1 shows the content of the Transmission Arbitration Taken message.

Table 9.2.8-1: Transmission Arbitration 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

| Granted Party’s Identity field |

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

| Permission to Request the Transmission field |

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

| User ID field |

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

| Message Sequence Number field |

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

| Transmission Indicator field |

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

| SSRC of granted transmission participant 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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

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

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 9.2.3.6.

Permission to request the transmission:

The Permission to Request the Transmission field is coded as specified in clause 9.2.3.7.

User ID:

The User ID field is used in off-network only. The User ID field carries the MCVideo user ID of the transmission participant sending the Transmission Arbitration Taken message.

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

Message Sequence Number:

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

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

SSRC of granted transmission participant:

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

9.2.9 Transmission Arbitration Released message

The Transmission Arbitration Released message is sent as an action from the transmission control server to inform non-requesting transmission participant(s) that the transmission control server has released the role of transmission arbitration.

In case of off-network, the transmission arbitrator acts as the transmission control server.

The Transmission Arbitration Released message is used in the off-network mode

Table 9.2.9-1 shows the content of the Transmission Arbitration Released message.

Table 9.2.9-1: Transmission Arbitration Released 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

| Granted Party’s Identity field |

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

| User ID field |

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

| Message Sequence Number field |

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

| Transmission Indicator field |

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

| SSRC of granted transmission participant 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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

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

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 9.2.3.6.

Permission to request the transmission:

The Permission to Request the Transmission field is coded as specified in clause 9.2.3.7.

User ID:

The User ID field is used in off-network only. The User ID field carries the MCVideo user ID of the transmission participant sending the Transmission Arbitration Released message.

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

Message Sequence Number:

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

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

SSRC of granted transmission participant:

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

9.2.10 Transmission Revoked message

9.2.10.1 General

The Transmission Revoked message is sent from the transmission control server to the transmission participant with the permission to send media to inform that the permission to send media is revoked.

The Transmission Revoked message is only used over the unicast bearer.

Table 9.2.10.1-1 shows the content of the Transmission Revoked message.

Table 9.2.10.1-1: Transmission Revoked 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

| Reject Cause value |

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

| Transmission 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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission 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 Transmission Revoked message includes <Reject Cause> cause value in the Reject Cause field explaining why the transmission control server wants the transmission 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 9.2.3.4.

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

9.2.10.2 Transmission revoked cause codes and revoked cause phrases

Cause #1 – Only one MCVideo client

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

Cause#2 – Media burst too long

The <Reject Cause> value set to ‘2’ indicates that the MCVideo User has transmitted too long (e.g., the stop-transmission 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 MCVideo 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 MCVideo client ‘s permission to send a media is being pre-empted. No additional information is included.

Cause#5 – Terminate the RTP stream

The <Reject Cause> value set to ‘5’ indicates that the MCVideo client’s permission to send a media is being revoked. No additional information is included.

Cause#6 – No resources available

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

Cause#7 – Queue the transmission

The <Reject Cause> value set to ‘7’ indicates that the MCVideo client’s permission to send a media is being queued. No additional information is included.

Cause #8 – No receiving participant

The <Reject cause> value set to ‘8’ indicates that the MCVideo client’s permission to send a media is being revoked because there is no participant to receive the stream.

Cause#255 – Other reason

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

9.2.11 Queue Position Request message

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

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

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

Table 9.2.11-1: 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

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

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

|SSRC of transmission control participant for queue status info |

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

| name=MCV0 |

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

| 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 9.2.2.1-1.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission control participant that is requesting information about its position in the transmission 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 MCVideo user ID of the transmission participant sending the Queue Position Request message.

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

Track Info:

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

9.2.12 Queue Position Info message

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

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

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

Table 9.2.12-1: 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

| User ID field |

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

| SSRC of queued transmission control participant field |

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

| Queued User ID field |

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

| Queue Info field |

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

| Track Info field |

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

| Transmission 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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

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

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 MCVideo ID of the transmission control participant sending the Queue Position Info message.

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

SSRC of queued transmission participant:

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

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

Queued User ID:

The Queued User ID field is used in off-network only. The Queued User ID field carries the MCVideo ID of the queued transmission control participant.

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

Queue Info:

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

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

Track Info:

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

Transmission Control Indicator:

The Transmission Control Indicator field is coded as described in clause 9.2.3.15.

9.2.13 Media transmission notification

The Media transmission notification message is sent by the transmission control server to notify the transmission control participant that a media transmission is available from another user.

The Media transmission notification message is used in off-network and in on-network mode. In the on-network mode the Media transmission notification message is used over both the unicast bearer and MBMS bearer.

Table 9.2.13-1 shows the content of the Media transmission notification message.

Table 9.2.13-1: Media transmission notification 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

| User ID field |

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

| SSRC of transmitter |

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

| Permission to Request the Transmission field |

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

| Transmission Indicator field |

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

| Track Info field |

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

| Functional Alias field |

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

| Reception Mode 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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

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

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

User ID:

The User ID field carries the MCVideo ID of the user transmitting the media.

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

SSRC of transmitter:

The SSRC of transmitter field carries the SSRC of the user transmitting the media.

The SSRC of transmitter field is coded as described in clause 9.2.3.16.

Permission to request the transmission:

The Permission to Request the Transmission field is coded as specified in clause 9.2.3.7.

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

Track Info:

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

Functional Alias:

The Functional Alias field carries the functional alias URI of the transmitting user. The Functional Alias field is coded as described in clause 9.2.3.21.

Reception Mode:

The Reception Mode field coded as specified in clause 9.2.3.22.

9.2.14 Receive media request

The Receive media request message is a request from a transmission control participant to get permission to send media. The Receive media request message is sent over unicast bearers only from the transmission control participant towards the transmission control server.

Table 9.2.14-1 shows the content of the Receive Request message.

Table 9.2.14-1: Receive media 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

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

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

| SSRC of participant sending the Receieve Request message |

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

| name=MCV0 |

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

: User ID field :

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

| SSRC of transmitter |

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

| Transmission Indicator field |

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

| Reception Priority field |

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

| Track Info field |

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

| Functional Alias 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 9.2.2.1-1.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission participant requesting the reception of the media from another user.

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

User ID:

The User ID field is used to carry the identity of the user who is requesting the reception of the media and is coded as described in clause 9.2.3.8.

SSRC of transmitter:

The SSRC of transmitter field carries the SSRC of the user transmitting the media.

The SSRC of transmitted field is coded as described in clause 9.2.3.16.

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

Reception priority:

The Reception Priority field is coded as described in clause 9.2.3.19.

Track Info:

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

Functional Alias:

The Functional Alias field carries the functional alias URI of the transmitting user. The Functional Alias field is coded as described in clause 9.2.3.21.

9.2.15 Receive media response

9.2.15.1 General

The Receive media response message is sent from the transmission control server to the transmission control participant to indicate whether the media reception is possible or not.

Table 9.2.15.1-1 shows the content of the Receive media response message.

Table 9.2.15.1-1: Receive media response 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

| Result |

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

| Reject Cause field |

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

| SSRC of transmitter |

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

| Transmission 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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

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

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

Result:

The Result field indicates whether media reception is possible as per the request. This field is coded as described clause 9.2.3.x.

Reject Cause:

The Reject Cause field includes the reason for the rejecting the media receive request and can be followed by a text-string explaining why the media receive 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 9.2.15.2. The Reject Cause field is coded as described in clause 9.2.3.4.

SSRC of transmitter:

The SSRC of transmitter field carries the SSRC of the user transmitting the media.

The SSRC of transmitted field is coded as described in clause 9.2.3.16.

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

9.2.15.2 Rejection cause codes and rejection cause phrase

Cause #2 – Internal transmission control server error

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

Cause #4 – Retry-after timer has not expired

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

Cause #5 – Send only

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

Cause #6 – No resources available

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

Cause #7 – Max no of simultaneous stream to receive is reached

The <Reject cause> value set to ‘7’ indicates that the transmission control server cannot grant the receive media request due to max number of simultaneous stream to receive is reached.

Cause #255 – Other reason

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

9.2.16 Media reception notification

The Media reception notification message is sent from the transmission control server to the transmission control participant to indicate that a media reception has been initiated to a user.

Table 9.2.16-1 shows the content of the Media reception notification message.

Table 9.2.16-1: Media reception notification 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

| User ID field |

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

| Functional Alias 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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

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

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

User ID:

The User ID field is used to carry the identity of the user who is receiving the media and is coded as described in clause 9.2.3.8.

Functional Alias:

The Functional Alias field carries the functional alias URI of the transmitting user. The Functional Alias field is coded as described in clause 9.2.3.21.

9.2.17 Void

9.2.18 Void

9.2.19 Transmission cancel request notify

The Transmission cancel request notify message is sent from the transmission control server to the transmission control participant..

Table 9.2.19-1 shows the content of the Transmission cancel request notify message.

Table 9.2.19-1: Transmission cancel request 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

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

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

9.2.20 Transmission end request

The Transmission end request message is sent from the transmission control participant to the transmission control server to terminate the Transmission request (if final response is not received from server) or to end the permission to send RTP media (if user has already received permission to send RTP media).

Table 9.2.20.1-1 shows the content of the Transmission end request message.

Table 9.2.20-1: Transmission end 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

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

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

| SSRC of transmission control participant |

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

| name=MCV2 |

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

| User ID field |

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

| Reject Cause value |

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

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 9.2.2.1-3.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission control participant.

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

User ID:

The User ID field is used to carry the identity of the user whose media transmission is requested to be terminated and is described in clause 9.2.3.8.

Reject Cause:

The Reject Cause field for the Transmission End Request message includes <Reject Cause> cause value in the Reject Cause field explaining why the transmission control server wants the transmission 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 9.2.3.4. The <Reject Cause> cause value is specified in clause 9.2.10.2.

9.2.21 Transmission end response

The Transmission end response message is sent from the transmission control participant to the transmission control server and from the transmission control server to the transmission control participant.

Table 9.2.21-1 shows the content of the Transmission end response message.

Table 9.2.21-1: Transmission end response 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

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

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

| SSRC of transmission control server |

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

| name=MCV2 |

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

| User ID 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 9.2.2.1-3.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

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

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

User ID:

The User ID field is used to carry the identity of the user whose media transmission is requested to be terminated and is coded as described in clause 9.2.3.8.

9.2.22 Remote Transmission request

The Remote Transmission request message is sent from the transmission control participant to the transmission control server.

Table 9.2.22-1 shows the content of the Remote Transmission request message.

Table 9.2.22-1: Remote Transmission 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

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

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

| SSRC of participant sending the Receieve Request message |

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

| name=MCV0 |

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

: Remote ID field :

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

: User ID 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 9.2.2.1-1.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission participant requesting the reception of the media from another user.

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

Remote ID:

The Remote ID field is used to carry the identity of the user who remotely initiated the media transmission of another user and is coded as described in clause 9.2.3.8.

User ID:

The User ID field is used to carry the identity of the user whose media transmission is requested and is coded as described in clause 9.2.3.8.

9.2.23 Remote Transmission response

The Remote Transmission response message is sent from the transmission control server to the transmission control participant.

Table 9.2.23-1 shows the content of the Remote Transmission response message.

Table 9.2.23-1: Remote Transmission response 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

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

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

9.2.24 Remote Transmission cancel request

The Remote Transmission cancel request message is sent from the transmission control participant to the transmission control server.

Table 9.2.24-1 shows the content of the Remote Transmission cancel request message.

Table 9.2.24-1: Remote Transmission cancel 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

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

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

| SSRC of participant sending the Receieve Request message |

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

| name=MCV0 |

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

: User ID 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 9.2.2.1-1.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission participant requesting the reception of the media from another user.

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

User ID:

The User ID field is used to carry the identity of the user whose media transmission is requested for cancellation and is coded as described in clause 9.2.3.8.

9.2.25 Remote Transmission cancel response

The Remote Transmission cancel response message is sent from the transmission control server to the transmission control participant.

Table 9.2.25-1 shows the content of the Remote Transmission cancel response message.

Table 9.2.25-1: Remote Transmission cancel response 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

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

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

| SSRC of participant sending the Receieve Request message |

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

| name=MCV1 |

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

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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission participant requesting the reception of the media from another user.

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

9.2.26 Media reception end request

The Media reception end request message is sent from the transmission control participant to the transmission control server and from the transmission control server to the transmission control participant.

Table 9.2.26.1-1 shows the content of the Media reception end request message.

Table 9.2.26-1: Media reception end 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

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

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

| SSRC of transmission control participant or server |

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

| name=MCV2 |

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

| SSRC of transmitter |

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

| Transmission 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 9.2.2.1-3.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission control server or the transmission control participant.

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

SSRC of transmitter:

The SSRC of transmitter field carries the SSRC of the user transmitting the media.

The SSRC of transmitter field is coded as described in clause 9.2.3.16.

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

9.2.27 Media reception end response

The Media reception end response message is sent from the transmission control participant to the transmission control server and from the transmission control server to the transmission control participant.

Table 9.2.27-1 shows the content of the Media reception end response message.

Table 9.2.27-1: Media reception end response 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

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

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

| SSRC of transmission control server or participant |

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

| name=MCV2 |

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

| SSRC of transmitter |

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

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 9.2.2.1-3.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission control server or the transmission control participant.

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

SSRC of transmitter:

The SSRC of transmitter field carries the SSRC of the user transmitting the media.

The SSRC of transmitted field is coded as described in clause 9.2.3.16.

9.2.28 Media reception override notification

The Media reception override notification message is sent from the transmission control server to the transmission control participant.

Table 9.2.28-1 shows the content of the Media reception override notification message.

Table 9.2.28-1: Media reception override notification 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

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

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

| SSRC of participant sending the Receieve Request message |

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

| name=MCV1 |

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

: User ID field :

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

: SSRC of transmitter :

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

: Overriding ID field :

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

: Overridden ID 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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission participant requesting the reception of the media from another user.

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

User ID:

The User ID field is used to carry the identity of the user who is requesting the reception of the media and is coded as described in clause 9.2.3.8.

SSRC of transmitter:

The SSRC of transmitter field carries the SSRC of the user transmitting the media.

The SSRC of transmitter field is coded as described in clause 9.2.3.16.

Overriding ID:

The Overriding ID field is used to carry the identity of the user of the overriding media and is coded as described in clause 9.2.3.8.

Overridden ID:

The Overridden ID field is used to carry the identity of the user of the overridden media and is coded as described in clause 9.2.3.8.

9.2.29 Transmission end notify

The Transmission end notify message is sent from the transmission control server to the transmission control participant.

Table 9.2.29-1 shows the content of the Transmission end notify message.

Table 9.2.29-1: Transmission end 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

: User ID field :

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

: SSRC of transmitter :

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

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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

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

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

User ID:

The User ID field is used to carry the identity of the user whose media transmission has been released and is coded as described in clause 9.2.3.8.

SSRC of transmitter:

The SSRC of transmitter field carries the SSRC of the user transmitting the media.

The SSRC of transmitter field is coded as described in clause 9.2.3.16.

9.2.30 Transmission idle

The Transmission idle message is sent from the transmission control server to the transmission control participant.

Table 9.2.30-1 shows the content of the Transmission idle message.

Table 9.2.30-1: Transmission 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

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

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

| SSRC of transmission control server |

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

| name=MCV1 |

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

| Message Sequence Number field |

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

| Transmission Indicator 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 9.2.2.1-2.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission 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 9.2.3.9.

Transmission Indicator:

The Transmission Indicator field is coded as described in clause 9.2.3.11.

9.2.31 Transmission control ack

The Transmission control ack message is sent from the transmission control server to the transmission control participant and from the transmission control participant to the transmission control server.

Table 9.2.31-1 shows the content of the Transmission control ack message.

Table 9.2.31-1: Transmission control 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

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

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

|SSRC of the sender (transmission control participant or server)|

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

| name=MCV2 |

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

| Source field |

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

| Message name field |

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

| Message type 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 9.2.2.1-3.

Length:

The length is coded as specified in to clause 9.1.2.

SSRC:

The SSRC field carries the SSRC of the transmission control participant or transmission control server sending the Transmission control ack.

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

Source:

The Source field contains the source of the message and is coded as described in clause 9.2.3.12.

Message name:

The Message name field contains the transmission control message name that is being acknowledged and is coded asdescribed in clause 9.2.3.18.

Message type:

The Message Type field contains the transmission control message type that is being acknowledged and is coded as described in clause 9.2.3.10.

9.3 MBMS subchannel control

9.3.1 Introduction

The MBMS subchannel control messages shall be coded as described in clause 9.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: MCV3.

The list of MBMS subchannel control messages can be found in the clause 9.3.2.

The MBMS subchannel control specific fields are specified in clause 9.3.3.

9.3.2 MBMS subchannel control messages

Table 9.3.2-1 provides a list of MBMS subchannel control protocol messages.

Table 9.3.2-1: MBMS subchannel control protocol messages

Message name	Subtype	Reference	Direction
Map Group To Bearer	00000	clause 9.3.4	Server 🡪 client
Unmap Group To Bearer	00001	clause 9.3.5	Server 🡪 client
Application Paging	00010	clause 9.3.6	Server 🡪 client
Bearer Announcement	a	clause 9.3.7	Server 🡪 client
NOTE: The participating MCVideo function is the server and the MCVideo client is the client.

9.3.3 MBMS subchannel control specific fields

9.3.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 9.1.3.

Table 9.3.3.1-1 lists the available fields including the assigned Field ID.

Table 9.3.3.1-1: MBMS subchannel control specific data fields

Field name	Field ID		Description
Field name	Decimal	Binary	Description
MBMS Subchannel	000	00000000	Clause 9.3.3.3
TMGI	001	00000001	Clause 9.3.3.4.
MCVideo Group ID	002	00000010	Clause 9.3.3.2
Monitoring state	b	b	Clause 9.3.3.5

9.3.3.2 MCVideo Group ID field

The MCVideo Group ID field contains a URI identifying the MCVideo group for which media and transmission control messages are going to be broadcasted over a MBMS subchannel.

The MCVideo Group ID field is coded as the MCVideo Group Identity field specified in clause 9.2.3.20.

9.3.3.3 MBMS Subchannel field

The MBMS Subchannel field describes which MBMS subchannel to use for media and for transmission control.

Table 9.3.3.3-1 describes the coding of the MBMS Subchannel field.

Table 9.3.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

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

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

| IP | Spare |

|Version| |

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

| Transmission control Port Number |

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

| Video Media Port Number |

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

| Audio Media Port Number |

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

| FEC Port Number |

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

: IP Address :

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

The <MBMS Subchannel field ID> value is a binary value and shall be set according to table 9.3.3.3-1.

The <MBMS Subchannel length> value is a binary value indicating the total length in octets of the <Video m-line Number> value, <Audio m-line Number> value, <Audio m-line Number> value, <Control m-line Number> value, <FEC m-line Number> value, <IP Version> value, spare, port number values and <IP address> items.

The <Video m-line Number> value shall consist of 4 bit parameter giving the number of the" m=video" m-line in the SIP MESSAGE request announcing the MBMS bearer described in 3GPP TS 24.281 [2].

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.281 [2]. The <Audio m-line Number> value is set to "0" when audio is combined with video.

The <Control 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.281 [2].

The <FEC 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.281 [2]. The <FEC m-line Number> value is set to "0" when the media is not protected by FEC.

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 <Transmission Control Port Number> value is a 32-bit binary value giving the port to be used if the<Control m-line Number> value is greater than ‘0’. If the <Control m-line Number> value is equal to ‘0’, the < Transmission Control Port Number> value is not included in the MBMS Subchannel field.

The <Video Media Port Number> value is a 32-bit binary value giving the port to be used.

The <Audio Media Port Number> value is a 32-bit binary value giving the port to be used. If the <Audio m-line Number> value is equal to ‘0’, the < Audio Port Number> value is not included in the MBMS Subchannel field.

.The <FEC Port Number> value is a 32-bit binary value giving the port to be used. If the <FEC m-line Number> value is equal to ‘0’, the < FEC Port Number> value is not included 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.

9.3.3.4 TMGI field

Table 9.3.3.4-1 describes the coding of the TMGI field.

Table 9.3.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 9.3.3.1-2.

The <TMGI length> value is a binary value indicating the length in octets of the <TMGI> value item.

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.

9.3.3.5 Monitoring state

Table 9.3.3.5-1 describes the coding of the Monitoring State field.

Table 9.3.3.5-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

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

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

The <Monitoring State field ID> value is a binary value and shall be set according to table 9.3.3.1-1.

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

9.3.4 Map Group To Bearer message

The Map Group To Bearer message is sent by the participating function when a transmission is started.

Table 9.3.4-1 shows the content of the Map Group To Bearer message.

Table 9.3.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

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

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

| SSRC of participating MCVideo function |

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

| name=MCV3 |

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

| MCVideo 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 9.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 MCVideo function.

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

MCVideo Group ID:

The MCVideo Group ID field is coded as described in clause 9.3.3.2.

TMGI:

The TMGI field is coded as described in clause 9.3.3.4.

MBMS Subchannel:

The MBMS Subchannel field is coded as described in clause 9.3.3.3.

9.3.5 Unmap Group To Bearer message

The Unmap Group To Bearer message is sent by the participating function when a transmission is ended.

Table 9.3.5-1 shows the content of the Unmap Group To Bearer message.

Table 9.3.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

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

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

| SSRC of participating MCVideo function |

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

| name=MCV3 |

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

| MCVideo 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 9.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 MCVideo function.

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

MCVideo Group ID:

The MCVideo Group ID field is coded as described in clause 9.3.3.2.

9.3.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 9.3.6-1 shows the content of the Application Paging message.

Table 9.3.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

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

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

| SSRC of participating MCVideo function |

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

| name=MCV3 |

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

| MCVideo 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 9.3.2-1.

Length:

The length shall be coded as specified in clause 9.1.2.

SSRC:

The SSRC field shall carry the SSRC of the participating MCVideo function.

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

MCVideo Group ID:

The MCVideo Group ID field is coded as described in clause 9.3.3.2.

9.3.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 9.3.7-1 shows the content of the Bearer Announcement message.

Table 9.3.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

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

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

| 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 9.3.2-1.

Length:

The length shall be coded as specified in clause 9.1.2.

TMGI:

The TMGI field is coded as described in clause 9.3.3.4. This field is mandatory.

Alternative TMGI:

Zero or more alternative TMGI fields are coded as described in clause 9.3.3.4. This field is coded immediately after the TMGI field.

Monitoring State:

The monitoring state field is coded as described in clause 9.3.3.5.

9.4 MBMS notifications

9.4.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 9.4.2.

The MBMS notifications specific fields are specified in clause 9.4.3.

9.4.2 MBMS notifications control messages

Table 9.4.2-1 provides a list of MBMS notifications protocol messages.

Table 9.4.2-1: MBMS notifications protocol messages

Message name	Subtype	Reference	Direction
Group Dynamic Data Notify	00000	clause 9.4.4	Server 🡪 client
NOTE: The participating MCVideo function is the server and the MCVideo client is the client.

9.4.3 MBMS notifications control specific fields

9.4.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 9.4.3.1-1 lists the available fields including the assigned Field ID.

Table 9.4.3.1-1: MBMS notifications control specific data fields

Field name	Field ID		Description
Field name	Decimal	Binary	Description
Status	000	00000000	Clause 9.4.3.2
Status changing MCVideo User Identity	001	00000001	Clause 9.4.3.3
Group call ongoing	002	00000010	Clause 9.4.3.4
Group broadcast alias	003	00000011	Clause 9.4.3.5
Group regroup alias	004	00000100	Clause 9.4.3.6

9.4.3.2 Status field

The Status field indicates the indication of the status of the group and also includes the MCVideo ID of the user that last changed the status of the group.

Table 9.4.3.2-1 describes the coding of the Status field.

Table 9.4.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 9.4.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.

9.4.3.3 Status changing MCVideo User Identity field

The Status changing MCVideo User Identity field contains the MCVideo ID identifying the Status changing MCVideo user.

Table 9.4.3.3-1 describes the coding of the Status changing MCVideo User Identity field.

Table 9.4.3.3-1: Status changing MCVideo 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 MCVideo |

|MCVideo User |MCVideo User |User Identity |

|Identity field |Identity length| |

|ID | | |

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

: (Padding) :

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

The <Status changing MCVideo User Identity field ID> value is a binary value and shall be set according to table 9.4.3.1-1.

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

The <Status changing MCVideo User Identity> value contains the MCVideo ID of the Status changing MCVideo user. The <Status changing MCVideo User Identity> value shall be coded as specified in the table 9.4.3.3-2. The MCVideo ID is specified in 3GPP TS 24.379 [2].

Table 9.4.3.3-2: ABNF syntax of string values of the <Status changing MCVideo User Identity> value

status-changing-mcvideo-user-identity = URI

If the length of the <Status changing MCVideo User Identity> value is not (2 + multiple of 4) bytes, the <Status changing MCVideo 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.

9.4.3.4 Group call ongoing field

Table 9.4.3.4-1 describes the coding of the Monitoring State field.

Table 9.4.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

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

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

The < Group call ongoing field ID> value is a binary value and shall be set according to table 9.4.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

9.4.3.5 Group broadcast alias field

The Group broadcast alias field contains the URI identifying the Group broadcast alias.

Table 9.4.3.5-1 describes the coding of the Group broadcast alias field.

Table 9.4.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 9.4.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 9.4.3.5-2. The group broadcast alias is specified in 3GPP TS 23.280 [23].

Table 9.4.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.

9.4.3.6 Group regroup alias field

The Group regroup alias field contains the URI identifying the Group regroup alias.

Table 9.4.3.6-1 describes the coding of the Group regroup alias field.

Table 9.4.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 9.4.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 9.4.3.6-2. The Group regroup alias is specified in 3GPP TS 23.280 [23].

Table 9.4.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.

9.4.4 Group Dynamic Data Notify message

The Group Dynamic Data Notify message is sent by the participating function when a conversation is started.

Table 9.4.4-1 shows the content of the Group Dynamic Data Notify message.

Table 9.4.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

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

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

| SSRC of participating MCVideo function |

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

| name=MCNC |

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

| Status field |

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

| Status changing MCVideo User Identity field |

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

| MCVideo 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 9.4.2-1.

Length:

The length shall be coded as specified in clause 9.1.2.

SSRC:

The SSRC field shall carry the SSRC of the participating MCVideo function.

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

MCVideo Group ID

The MCVideo Group ID field contains a SIP URI identifying the group that the group dynamic is related to.

The MCVideo Group ID field is coded as the MCVideo Group Identity field specified in clause 9.2.3.20.

Status:

The Status field is coded as described in clause 9.4.3.2.

Status changing MCVideo User Identity:

The Status changing MCVideo User Identity is coded as described in clause 9.4.3.3.

Group call ongoing:

The Group call ongoing field is coded as described in clause 9.4.3.4.

Group broadcast alias field:

The Group broadcast alias field is coded as described in clause 9,4.3.5

Group regroup alias field:

The Group regroup alias field is coded as described in clause 9.4.3.6