Multimedia Communication - ECE - VTU - 8th Sem - Unit 8 - Transport Protocols, ramisuniverse

M u l t i m e d i a Co m m u n i c at a t i o n s ( 1 0 E C8 4 1 )

U n i t 8 : T r a n s p o r t P r o t o co c o ls ls

TRANSPORT PROTOCOLS Unit 8: TRANSPORT PROTOCOL: Introduction, TCP/IP, TCP, UDP, RTP and RTCP 7 Hrs INTRODUCTION TCP/IP protocol suite Fig. shows – the position of the each protocol relative to the others in the TCP/IP suite

IP protocols and network-dependent protocols below tem are all part of the operating system kernel with the various application protocols implemented as separate programs/processes

Ram Ram esh esh S

Asst. Asst. Prof.(EC Prof.(ECE E Dept .), Bengalur Bengalur u

ram isuniverse@gm isuniverse@gm ail. ail.com

cell: cell: +91 94 498 519 13



TCP and UDP: 2 transport protocols – then, implemented to run either within the operating system kernel – as separate

programs/processes, or in a library package linked to the application program

Client-Server paradigm – is used in most networked applications

Client application protocol/program: runs in one computer – typically, a PC or workstation – and this communicates with a similar (peer) application program that runs (normally continuously) in a remote server computer Ex.: File transfers and the messages associated with email – both of which require a reliable service – that is, the

transferred information should be free of transmission errors and the messages delivered in the same sequence that they were submitted - Hence, applications of this type – use reliable service provided by TCP

Role of TCP: Is to convert best-effort service provided by IP – into reliable service UDP role:

1. For other applications: simple best-effort service is acceptable – hence, they use UDP as transport protocol Ex.: Interpersonal applications – that involve the transfer of streams of compressed audio and/or video in real time

Since, new information is being received and output continuously – it is inappropriate to request blocks – that are received with errors to be retransmitted This type of applications for – RTP and RTCP are used 2. Other applications that use – UDP – are HTTP and SNMP – both of which involve a single request-response message exchange

All message blocks – PDUs – relating to the protocols – that use the services of the IP layer – are transferred in an IP datagram

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Fig. As shown – there are a number of different protocols 0 that use the services of IP – TCP, UDP, ICMP, and IGMP

So, IP has to identify the protocols – to which the contents of the datagram relate It can be done by protocol field – in the IP datagram header Number of different application protocols – may use the services of both TCP and UDP – it is necessary for both these protocols to have – a field in their respective PDU header that identifies the application protocol – to which the PDU contents relate It can be done by using the port numbers - present in the header of the PDUs of both protocols

Server application, receives request from multiple clients – to have the server to send the responses to correct clients both the source port number and the source IP address from the IP datagram header are sent to the application protocol with the TCP/UDP contents Within the client host: port number of the source application protocol has only local significance and a new port number is allocated for each new transfer request - So, client port numbers are called – ephemeral ports – as they are shortlived - Ephemeral port numbers – are allocated in the range of – 1024 to 5000

Port numbers of the peer application protocol – in the server application protocols – are fixed and known as – wellknown port numbers Allocation is managed by IANA and are in the range of 1 to 1023 Ex.: Well-known port number of the server-side of the FTP - 21 Fig. As shown: All the protocols in both the application and transport layers communicate directly – with a similar peer

protocol in the remote host computer (end system) Protocols in both these layers – are said, therefore – to communicate on an end-to-end basis

In contrast: IP protocols – present in each of the two communicating hosts are network interface protocols These together – with the IP in each intermediate gateway/router involved – carry out the transfer of the datagram across the internetwork IP protocol in each host – is said to have local significance and the routing of each datagram is carried out on a hop-byhop basis

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



TCP TCP: Provides two communicating peer application protocols – one in client and one in server – With a two-way, reliable data interchange service APDUs associated with an application protocol have a defined structure – and is transparent two Communication peer TCP protocol entities - which treat all the data submitted by each local application entity as a stream of bytes Reliable way – in one TCP entity to the other (over the underlying network/internet) –the stream of bytes flowing in each direction is transferred i.e., each byte in the stream flowing in each direction is free of transmission errors – with no lost or duplicate bytes bytes - and bytes bytes are delivered in the same sequence, as they were submitted Reliable stream service: service provided by TCP

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



IP: service – is an unreliable best-effort service

Before any data is transferred between the two TCP entities – logical connection is to be established between them to – have sequence numbers in, TCP entity of - which is required for error correction and flow control purposes – to initialize Logical connection is closed – if both directions in, data transfer is over Data transmission phase:

Receiving TCP – to detect the presence of transmission errors – each TCP entity divided the submitted stream of bytes into blocks – called segments Segments: Segment may contain – single byte or many bytes (in large file transfers) MSS (Maximum Segment Size): there is agreed MSS value - in a connection – that is established by the 2 peer TCP

entities during the setting up of the connection MSS is of the value – such that – acceptable proportions of segments are received by the destination free of transmission errors Default MSS: 536 bytes – and larger sizes can also be agreed

Size chosen – such that no fragmentation is necessary – during segment transfer over network/internet and hence, determined by path MTU

TCP protocol – includes: 1. Retransmission procedure: To obtain error-free copies of segments that are received with transmission errors 2. Flow control procedure: Yo ensure no data is lost – when the TCP entity in the fast host, for ex. a large server – is

sending data to the TCP in a slower host like PC 3. Congestion control procedure: Which endeavors to control the rate of entry of segments into

the network/internet to the rate at which segments are leaving TCP formal specifications: RFC 793, RFC 1122, RFC 1323

User Services

User service primitives – used in TCP: socket primitives used with Berkeley Unix TCP – uses number of alternative set of primitives also

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Service primitives – are operating system calls - and collectively form API (Application Program Interface), to the underlying TCP/IP protocol stack Table: gives primitives list

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Two peer user application protocols/processes (APs) – creates first – communication channel between itself and its local TCP entity – called socket or endpoint Server AP: Involves AP issuing a sequence of primitive (also called as system of function) calls – each with a defined set

of parameters - associated with it: socket(), bind(), listen(), accept() Each of calls: has return value(s) or an error code associated with it

socket(): Parameters associated are:

1. Service required (reliable stream service) 2. Protocol (TCP) 3. Address format (Internet) SB/RB (Sent Buffer and Receive Buffer): are allocated – once, sockets been created

Socket descriptor – is sent to AP – which it uses – with each of subsequent primitive calls AP issues the bind() primitive

bind(): Parameters associated are:

1. Socket descriptor 2. Associated address parameter (socket address) – is the address the AP wishes to be assigned to the newly created socket 3. Socket address: contains Internet-wide IP address of the host For server AP: 16-bit well-known port number associated with this type of application protocol (ex.: FTP and so on)

listen():

Results in the local TCP entity creating a queue (whose minimum length is given as a parameter)- to hold incoming connection requests for the server AP

accept():

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Used to put the AP – in the blocked state – waiting for an incoming connection request to be received from a client TCP entity

Passive-open: collection of 4 primitives – socket(), bind(), listen(), and accept() connect():

For a client AP: can set up only a single TCP connection at a time so, socket address – has only local significance – it issues – a new socket with the same parameters as those used by server (AP)

Parameters associated:

1. Locally assigned socket descriptor 2. IP address of the remote (server) host 3. Well-known port number of the required server AP 4. Local port number that has been assigned to this socket by the client AP 5. Precedence value 6. Optional data – like user name and a password

Address to be assigned to this socket – is – local port number + host IP address Precedence parameter: collection of parameters – that enable the IP protocol to specify the contents of the type of service field in the header of the IP datagram – that is used to transfer the segments associated with the connection over the Internet IP address of the remote (server) host and the precedence parameters – used by IP protocol and not by TCP The above 2 parameters are ex. for – pass-through parameters – a parameter that is passed down from one protocol layer to another without modification

connect():

Results in calling AP – being put into the blocked state For the local TCP entity - initiates the setting up of a logical connection between itself and the TCP entity in the server

socket() and connect() – forms – an active-open

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



TCP entity: in the client host – may support multiple concurrent connections – involving different user APs TCP entity: in the server host – may also support – multiple connections involving different clients For the two TCP entities to relate each received segment to the correct connection – when each new connection is established – both TCP entities – creates – the connection record for it

Connection record: data structure – contains:

1. Connection identifier – comprising a pair of socket addresses –associated with the connection 2. Agreed MSS for the connection 3. Initial sequence number – associated with the acknowledgement procedure – to be used in each direction 4. Precedence value 5. Size of the window associated with TCP flow control procedure 6. And also a number of fields associated with the operation of the protocol entity – like – State variables and Current state of the protocol entity

Server side: When a new connection request (PDU) – is received – server AP is unblocked and proceeds to create the

new instance of the server AP to service this connection fork() primitive: of Unix – is used for this purpose

a new socket between new AP and the local TCP entity is – then created – and this is used to process the remaining primitives associated with this connection parent server AP: either returns to the blocked state waiting for a new connection request to arrive or, if one is already

waiting in the server queue – proceeds to process the new request new instance of the server AP – once created and linked to its local TCP entity by a socket – both the server and client APs - then, can initiate the transfer of blocks of data in each direction using – send() and receive() primitives Send Buffer and Receive Buffer: each socket for associated SB and RB will be SB: used by the AP – to transfer a block of data to its local TCP entity – for sending over the connection RB: used by the TCP entity – to assemble data received from – connection ready for reading by its local AP

send():

used by an AP to transfer – a block of data of a defined size to the send buffer associated with the socket ready for reading by its local TCP entity

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



parameters associated:

1. Local socket descriptor 2. Pointer to the memory buffer containing the block of data 3. Length (in bytes) of the block of data

TCP in – no correlation between – size of the data block(s) – submitted (by an AP to its local TCP entity for sending) and the size of the TCP segments that are used to transfer the data over the logical connection (normally, latter is determined by path MTU and in many instances, this value is smaller than the size of the data blocks submitted by an AP) Some applications in: Each submitted data block may be less than the path MTU Ex.: an interactive application – involving – a user at a keyboard interacting with a remote AP, the input data may

comprise just a few bytes/characters To avoid – the local TCP entit entity y waiting for more data to fill an MTU – user AP can request that the submitted block of data is sent immediately – done by : Push flag: setting a parameter associated with the send() primitive and Urgent flag: can also be set by a user AP – and used with the interactive applications to enable

(For ex.: a user AP to abort a remote computation that it has previously started) Urgent data – string of characters – associated with the abort command are submitted by the source AP with the urgent flag set Local TCP entity: then ceases – waiting for any further data – to be submitted and sends – what is outstanding – together with the urgent data – immediately

On receipt of this – remote TCP entity – proceeds to interrupt the peer user AP – which then reads the urgent data and acts upon it Finally – when client AP has completed the t he transfer of all data blocks associated with the connections - it initiates release of its side of the connection by close() or shutdown() primitive When this is informed of to server AP – by the local TCP entity – assuming it also had finished sending data – it responds by issuing a close() primitive – to release the other side of connection Both TCP entities – then delete their connection records – and also, the server AP that was forked to service the connection shutdown() – used – when only half of the connection – to be to close

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Protocol Operation

TCP protocol: involves 3 distinct operations 1. setting up a logical connection between 2 previously-created sockets 2. transferring blocks of data reliably over this connection 3. closing down – the logical connection In practice: Each phase is involves the exchange of one or more TCP segments (PDUs) usage of fields present in each segment header

Segment format Segment: all starts with a common 20-byte header

For acknowledgement and flow control segments – this is present all that is For connection-related segments: Options field – may be present Data field is present – when data is being transferred over a connection Fig. shows – the field making the header

Source port: 16-bit field

Used to identify – source APs at each end of a connection

Destination port: 16-bit field

Used to identify – destination APs at each end of a connection 48-bit socket address and 96-bit connection identifier formed with – 32-bit source and destination IP addresses of the related hosts Port number – in the client host –assigned by client AP Port number – in the server host – is a well-known port

Sequence number:

Performs the same function – as the send sequence number in the HDLC protocol Acknowledgement number – is the same function as the receive sequence number

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



HDLC as in: logical connection involves – 2 separate flows – one in each direction

Sequence number in the segment: relates – to the flow of bytes being transmitted by a TCP entity Acknowledgement number: indicates – the byte in the stream flowing – in the reverse direction that the TCP entity –

expects to receive next

Options: present in the segment header – means that the header can be of variable length

Header length: indicates – the number of 32-bit words in the header

Reserved: 6-bit field – as its name implies – is reserved for possible future use

Segments have the same header format and the validity of the selected fields, in the segment header – is indicated – by setting up of individual bits in the 6-bit code field If a bit is set: corresponding field is valid Note: multiple bits can be set – in a single segment Fig. shows – the meaning of the bits

Window size: relates – to a sliding window – flow control scheme Number in window size: indicates – number of data bytes (relative to the byte being acknowledged in the acknowledgement field) that the receiver is prepared to accept It is determined – by the amount of unused space in the RB, the remote TCP entity is using for this connection Max. size of RB and hence, max. size of window: can be different in each direction Has a default value typically, 4096, 8192, or 16384 bytes

Checksum: in the header of each IP datagram – applies only to the fields in the IP header and not the datagram contents

Covers – the complete segment – i.e., header + contents Since, only a simple checksum – is used to derive the checksum value in the IP header, in order to have an additional level of checking, some selected fields from the IP header also included in the computation of TCP checksum All these above fields – form – pseudo header of TCP and shown in Fig. Fig. in: Source and destination IP addresses and the protocol value (=6 for TCP) from the IP header + total byte count of

the TCP segment (header + contents)

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Computation of the checksum – uses same algorithm – as that used by IP

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Checksum is computed: by treating – the complete datagram as – being made up of a string of 16-bit words – which are then, added together using 1s complement arithmetic Number of data fields in the original TCP segment data field – may be odd To ensure – the same checksum is computed by both TCP entities – pad byte of zeros – added to the data field whenever, the original number of bytes in the data field is odd - So, byte count of a TCP segment – is always an even number

URG flag (in code field): when set – urgent pointer field is valid and indicates, the number of bytes in the data field that

follow the current sequence number – this is known as Urgent data or sometimes expedited data This data to be delivered – by the receiving TCP entity immediately it is received

Options: provides the means of adding extra functionality to that covered by the various field s in the segment header Ex.: it is used – during the connection establishment phase – to agree the maximum amount of data in a segment each

TCP entity is prepared to accept During this phase: each indicates its preferred max. size and hence, can be different for each direction of flow – this is called the MSS (Max. Segment Size) – and exclude, the fixed 20-byte segment header If one of the TCP entities – does not specify a preferred max. size – then, a default value of 536 bytes is chosen - TCP entity, in all hosts – connected to the Internet must accept a segment of up to 556 bytes (536 bytes + 20 byte header) - All IPs must – accept a datagram of 576 bytes +20 byte IP header Default MSS of 536 bytes – ensures – datagram (with TCP segment in its payload) – will be transferred over the Internet

without fragmentation Fig. shows – Format of MSS option

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



If this is last or only option present in the header –then, a single byte of zero – is added to indicate – this as the end of the option list

UDP TCP in - no correlation between the size of the messages/blocks of data submitted by a user AP and the amount of data in each TCP segment that is used to transfer the messages Latter - is determined by - the path MTU - to avoid fragmentation of each segment occurring In contrast with TCP: UDP in - each message/block of data - which is submitted by - a user Ap is transferred directly in a single IP datagram On receipt of each message - source UDP - adds a short header to it to form - UDP datagram UDP datagram - submitted to the IP layer - for transfer over the internet(fragmentation using if necessary) Destination in - IP: determines from the protocol field in the datagram header that the destination protocol is UDP passes - the contents of the IP datagram to the UDP

UDP:

Determines the intended user AP from a field in the UDP datagram header Passes the contents of the UDP datagram to the peer user AP for processing No error or flow control procedure - are involved in here, so, no connection set up is required Service offered by UDP to a user AP - so, is an extension of the service provided by IP

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Multicast group calls can be supported - in addition, to 2-party calls Set of service primitives and the protocol are simpler than TCP

User services

Like TCP - most widely used user services associated with UDP - Berkeley Unix socket primitives In most applications that use UDP: two user APs - either exchange messages on a request-response basis or simply initiate the transfer of blocks of data as these are generated Table shows: Typical list of service primitives - system/function calls

Fig. shows - Diagrammatic form of them Fig. in as: Prior to exchanging any messages - each of the user APs involved in the call: first establish a socket between

itself and its local UDP

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



socket() primitive:

Parameters associated with: 1. Service required (datagram service) 2. Protocol (UDP)

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



3. Address format (Internet) Once the socket had been created - sent/receive memory buffers allocated - a socket descriptor is returned to the AP which AP uses with each of the subsequent primitive calls If AP is the only running in the host - AP can start now to send and receive messages If AP is not the only running in the host (for ex. server is involved) AP issues bind() primitive

bind() primitive: Has socket descriptor + address parameter

Comprises the IP addresses of the host + 16-bit port number of AP wishes to be assigned to the socket For server AP case: this is related well-known port number bind() primitive - when not used - port number will be an ephemeral port number -port number is assigned here locally

User AP - can start to send and receive messages - once, a socket has been created AP must specify (since, no connection is involved, and hence no connection record as been created - in addition to the message): the IP address of the destination host or the IP multicast address in the case of multiple destinations and the port number of the destination socket/AP Type of service field (of IP datagram header) in - it must specify a precedence value to be sent, if required

sendto() primitive: includes each of these fields in its set of parameters

shutdown() call: used to - socket release

Protocol operation Fig. shows - format of each UDP datagram Source port: port number of the sending application protocol/socket - 16-bit integer

Destination port: is the peer of the - receiving application protocol(s) - 16-bit integer

Length field:

Number of bytes in the complete UDP datagram Includes 8-byte header + contents of the data field

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Checksum:

Covers the complete datagram (header + contents) UDP in checksum: like of TCP of only a simple checksum is used to compute the checksum value in IP header

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



to add additional level of checking - some selected field(called the UDP pseudo pseudo header) from the IP header are included in the computation of the UDP checksum Fig. shows: Source and destination IP addresses and the protocol value (=17 for UDP) from the IP header + value from

the length field in the UDP header

UDP checksum computation - same as that of IP Computation - done by treating the complete datagram - as being made up of string of 16-bit words which are added together using 1's complement arithmetic Checksum is sent as all 1s: if the computed 1s complements sum is all 0s Checksum usage is optional in UDP If the value in the checksum field is all 0s - indicates that the sender has not sent a checksum

Number of bytes: in the original UDP data field(and hence, submitted application protocol data unit) - may be odd - to ensure: checksum computed by both UDPs to same - a pad byte of zero is added to the data field - whenever the number of bytes in the original data field is odd. So, value in the length field is always an even integer UDP datagram is carried in a single IP datagram: so, to avoid fragmentat fragmentation ion - size of each application protocol data unit must be limited to that dictated by MTU of the path followed through the Internet by the IP datagram Ex.: Assume - a path of MTU of 1500 bytes - allowing for 8-bytes in the UDP header and 20-bytes in the IP header:

maximum submitted application PDU should be limited to 1472 bytes if fragmentation is to be avoided Maximum theoretical size of a UDP datagram: as determined by the maximum size of the IP datagram (65535 (64k-1) bytes - is 65507 (65535-20-8) bytes maximum value supported by most implementation is 8192 bytes or less

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



RTP

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Fig. shows - audio and/or video associated with an application are digitized using a particular coder

Each of the bit bit streams strea ms must be sent in the form of a stream of packets using for ex. UDP - when bit bit streams str eams are to be sent over a packet network At receiver: stream of received packets from - bitsteram must be reconstructed Transfer time of bit stream: some packets may lost and/or delayed by varying amounts so, packets may arrive at the destination in a different order Missing packets must be detected and compensated for- before reconstructed bitstream - passed to the decoder and dealy variations in the packet arrival times must be allowed These functions - done by RTP - Fig. illustrates the RTP usage

Packet format of RTP Fig. shows the packet format used by RTP

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



version(V)field: indicates the version of RTP that is being used P: pad bit X: an extension flag - to allow - extensions to the basic header to be defined and added in the future Multicast call/session: Contributing source (CSRC): each of thee participant contributes to the session (rather than passively listening)

uniquely identified - by using 32-bit identifier (typically IP address of the source) During multicast session: mixer: packet stream from multiple sources may be multiplexed together for transmission purposes Resulting RTP packet may contain - blocks/frames of digitized information from multiple sources CSRC identifier for each block/frame included in the header of the new packet - to enable the receiver to relate each block/frame to the appropriate participant CSRC count (CC) field:

gives the number of CSRC identifiers present in the packet is a 4-bit field - up to 15 contributing sources, so, can be present in the RT packet header

Sequence of blocks or frames each with a unique start and end delimiter - are present in the bitstram produced by the different types of audio and video codecs Marker (M): bit is a profile - which enables - the receiver to interpret the packet data on the correct block/frame

boundaries range of different audio and video codecs - are present payload type field: indicates the type of encoder - that has been used to encode the data in the packet type of encoder being used can be changed using a call should the QoS of the network being used change - since, each packet contains this payload type field

sequence number:

Is in each packet Used to detect lost or out-of-sequence packets In the case of - each case of lost packet being detected - contents of the last correctly received packet are used in its place Buffering - a number of packets before play out of the data they contain starts - overcomes the effect of out-of-sequence packets being received

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



time stamp field: value of it - indicates - time reference when the packet was created

Used to determine the current mean transmission delay time and the level of jitter being experienced Current QoS of the path through the network/internet: number of packets lost + time stamp field RTCP sends - this information to the sending RTP - so, QoS change if, the sending RTP may modify the resolution of the compression algorithm - being used Fig. shows that: Level of jitter is used to determine the size of the playout buffer that is required

Synchronization source (SSRC) identifier:

Identifies the source device that has produced the packet contents Video conferencing call - in - data generated from each contributing source may be from multiple different devices microphones, camera, computers and so on SSRC - indicates- source information - come from which device Receiving RTP: uses SSRC to relay the reconstructed bitstream to the related output device interface

Fig. as in: On receipt of each IP packet - various field in the UDP datagram header are used - within the destination host

to deliver the RTP packet to the receiving RTP entity Various fields in the RTP packet header - then, enable the receiving RTP - to reconstruct the bitstream for each device decoder associated with the session

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



RTCP RTP – concerned with the transfer of the individual streams of digitized data associated with a multimedia call/session RTCP – adds additional system-level functionality to its related RTP – such as the means for – Receiving RTP to integrate and synchronize the individual packet streams together Sending RTP for – to inform of the currently-prevailing network QoS

Fig. as in: RTCP:

Acts alongside of RTP and shares information with it Has different UDP port number associated with it – so that, it can operate independently with RTP In all of the systems – involved in a call/session – periodically exchange messages with one another

Each message is sent in a packet - to the same network address – but, with the different port number, as the RTP to which the message relates Fig. shows – general scheme

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Messages that are exchanged relate to: 1. Integrated media synchronization:

In applications – involving separate audio and video streams - that need to be integrated integrated together toget her – as in Fig – a common system time clock is used for synchronization purposes System that initiates- call/conference provides this function or sometimes a separate reference time server and the RTCP in all of the other systems then exchange messages with the RTCP in this system so that they are utilizing the same system time clock

2. QoS reports:

Each RTCP – computes continuously – for the packet streams they receive from all of the other contributing sources –the following parameters: 1. Number of lost packets 2. Level of jitter 3. Mean transmission delay Adjoining RTCP – then sends a message containing the related information to the RTCP in each of these systems at periodic intervals RTCP – in each of these systems – then performs – any system-level functions that may need to be performed Ex.: changing the resolution of the compression algorithm or size of the playout buffer

3. Participation reports:

Used during conference call Ex.: to enable a participant to indicate to the other participants that it is leaving the call

It is done by means of RTCP – in the participant’s system Participant enters – an appropriate message – and this is then sent via RTCP to the RTCP in each of the other systems Typically – a related message is then output on the screen of each of the other systems

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



4. Participation details:

Information such as name, email address, phone number, and so on – of each participant – is sent to all of the other participants in a RTCP message Each of the participants – knows the identity and contact information of all of the other participants

Ram Ram esh esh S



cell: cell: +91 94 498 519 13



Communicat ions: Applications, Networks, Protocols and Standards, Fred Halsall, Pearson Bibliography: Multimedia Communications: Education, Asia, Second Indian reprint 2002.

Ram Ram esh esh S



cell: cell: +91 94 498 519 13

Multimedia Communication - ECE - VTU - 8th Sem - Unit 8 - Transport Protocols, ramisuniverse

Recommend Documents