9 Coding
24.5813GPPMission Critical Video (MCVideo) media plane controlProtocol specificationRelease 18TS
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure RTCP message part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P
The padding bit P is set to ‘0’.
Subtype:
Dependent upon the relevant set of media plane control messages, as identified by the Name field, the possible Subtype values are defined in the following tables:
– Name field = "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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transmission |Transmission |Transmission |spare |
|Priority |Priority |Priority | |
|field ID value |Length value |value | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Queue Info |Queue Info |Queue Position |Queue Priority |
|field ID |length |Info | Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Message Type |Message Type |Message Type |Spare |
|field ID value |Length value |value | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Track Info |Track Info |Queueing |Participant |
|field ID |length |Capability |Type Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reception |Reception |Reception |spare |
|Priority |Priority |Priority | |
|field ID value |Length value |value | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 |
|
---|---|---|---|
Decimal |
Binary |
||
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MBMS Subchannel|MBMS Subchannel|Video |Audio |Control|FEC |
|field ID value |length value |m-line |m-line |m-line |m-line |
| | |Number |Number |Number |Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Monitoring |length=1 |Monitoring |Spare |
|State ID | |State | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <Monitoring State field ID> value is a binary value and shall be set according to table 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype| PT=APP=204 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name=MCMC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMGI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alternative TMGI fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Monitoring State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
With the exception of the three first 32-bit words and the internal order of the TMGI field and the Alternative TMGI fields, the order of the fields is irrelevant.
Subtype:
The subtype shall be coded according to table 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 |
|||||
---|---|---|---|---|---|---|---|
Decimal |
Binary |
||||||
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Group call |length=1 |Group call |Spare |
|ongoing ID | |ongoing | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The < Group call ongoing field ID> value is a binary value and shall be set according to table 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype| PT=APP=204 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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