On October 23rd, 2014, we updated our
By continuing to use LinkedIn’s SlideShare service, you agree to the revised terms, so please take a few minutes to review them.
The contents of a compressed audio and/or video file are played out as they are being received. A playout buffer helps to smooth the variations in the time between each received packet in the stream (delay jitter).
Media player acts as the interface between the incoming compressed media bitstream and the related sound and/or video output cards.
For video, the browser first creates a window in the web page and passes the coordinates of the window to the selected video media player.
Video media player initializes the video card with the assigned coordinates and decompresses the video bitstream from the playout buffer and passes it to the video card for rendering
Media player consists of two parts : playout functions and control functions for interactivity
Browser sends a HTTP GET request to the web server
Web server responds by returning the contents of the meta file to the browser
Browser determines the media player to invoke from the “content type” field and passes the contents of the meta file to the selected media player
Control part of the media player requests control part of the streaming server to start a new session by sending RTSP SETUP request message (including the port number allocated to RTP). In response the control part of the server returns an RTSP accept message (with a unique session identifier)
Control part of the media player sends a RTSP PLAY request message; the control part on the server side initiates the access and transmission of the packet stream using the allocated port number of RTP in the header of each UDP datagram
RTSP TEARDOWN request message is used when the user activates the quit/end button
The timing information required by the receiver to output the received packet stream at the required rate is provided by RTP
RTCP is used to synchronize the two media streams prior to carrying out the decoding the decoding operation
RTP functions: (1) detecting missing packets and compensating for lost packets as well as delay variations (2) reconstructing bitstream (reordering the packets)
RTP Packet Format
CSRC -- contributing source used in a multicast call/session; each source is uniquely identified by means of a 32-bit identifier (which is typically the IP address of the source)
During a multicast session, the packet stream from multiple sources may be multiplexed together for transmission purposes by a device known as a Mixer.
Resulting RTP packet may contain blocks/frames of digitized information from multiple sources
To enable the receiver to relate each block/frame to the appropriate participant, the CSRC identifier for each block/frame is included in the header of the new packet
CC field (4 bits) indicates the number of CSRC identifiers present in the packet
RTP Packet Format (Contd.)
Payload type field indicates the type of encoder that has been used to encode the data in the packet. Since each packet contains this field, the encoder type used can be changed from packet to packet during a call depending on n/w load.
Each packet contains a sequence number which is used to detect lost or out-of-sequence packets.
In the case of a lost packet, the contents of the last correctly received packet are used in its place.
The effect of out of sequence packets is overcome by buffering a number of packets before playout of the data they contain starts.
RTP Packet Format (Contd.)
The value of the time stamp field indicates the time reference when the packet was created.
It is used to determine the current mean transmission delay time and the level of jitter that is being experienced.
Along with the delay information, the number of lost packets forms part of the current QoS of the path through the n/w.
RTCP periodically sends this info to the sending RTP source so that the sending RTP may modify the resolution of the compression algorithm if the n/w load changes. Level of jitter is used to determine the size of the playout buffer.
Synchronization source (SSRC) identifier identifies the source device that produced the packet contents. Receiving RTP uses the SSRC to relay the reconstructed bitstream to the related output device interface.
RTCP operates along side of RTP and shares information with it
Each RTCP has a different (UDP) port number associated with it so that it can operate independently of RTP
Periodic messages (RTCP packet) exchanged with the RTP hosts/clients
common system time clock for media synchronization
QoS reports computed by the receiving RTPs
RTCP from all call participants periodically exchange messages with one another. Each message is sent in a RTCP packet to the same network address as the RTP to which the message relates.
For applications that involve separate audio and video streams, a common system time clock is used for synchronization purposes.
The number of lost packets, the level of jitter, and the mean transmission delay are continuously computed by each RTP for the packet streams they receive from all other contributing sources. RTCP passes this information to all other RTCPs.
Participation reports used when a participant leaves the call.
Participation details includes information such as the name, email address, phone number and so on of each participant.
When a PC connected to the Internet needs to make a call to a telephone that is connected to a PSTN/ISDN, an internetworking unit known as telephony gateway is used.
PC user sends a request to make a telephone call to the preallocated telephony gateway using the g/w’s Internet address.
The g/w requests the source PC for the phone number of the called party.
Then the source g/w initiates a session w/ the telephone g/w nearest to the called party using the IP address of the g/w.
Called g/w initiates a call to the recipient telephone using its phone number and standard call setup procedure of the PSTN/ISDN.
Assuming the called party answers, the called g/w then signals back to the PC user -- through source g/w -- that the call can commence.
PC to PC : h/w and s/w to convert speech signal from the microphone to packets on input and back again prior to output to the speakers.
Session Initiation Protocol (SIP)
Provides services for user location, call/session establishment, and call participation management
A simple request-response protocol -- both the request and response are made through an application program called the user agent (UA) which maps the request and its response into the standard message format used by SIP
Each UA comprises two parts, a UA Client (UAC), which enables the user to send request messages (to initiate the setting up of a call/session) and a UA server (UAS) which generates the response message
Call/Session Set Up
SIP name/address is similar to an email name/address. A single user may have a number of alternative locations/addresses
Calling host sends an INVITE request message to the local proxy server (PS -A); the proxy server (PS-A) obtains the IP address of the proxy server (PS-B) for the called host and the SIP in the proxy server (PS-A) sends the INVITE request message to PS-B. PS -B determines that the user is currently logged in (gets name/address from the SIP message) and the IP address of the called host. If the called host can accept the call, an INVITE response message is returned over the same path. Receiving this the SIP in the calling host returns an ACK and the two users/hosts start exchanging the info.
Session Description Protocol (SDP)
To describe the different media streams involved in a call/session
Described in each SIP message body in text format:
media streams (list of media types and format in each SIP INVITE request message and a modified version of that in the INVITE response message)
stream addresses (destination address and UDP port number for sending and/or receiving each stream)