Topic: Multimedia Networking - What you will learn GC - Unisalento
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
GC
Topic: Multimedia Networking 2021-2022
What you will learn
Multimedia in the Internet
Protocols for real-time conversational voice and video
applications
• RTP
• SIP
Multimedia 1/19GC
Multimedia Network Applications 2021-2022
❑ Service requirements of multimedia network
applications
highly sensitive to end-to-end delay and to delay variation
(jitter)
tolerant to occasional loss of data
very different from requirements of the traditional elastic
applications, such as e-mail, Web, file transfer
• delay tolerant
• loss intolerant
❑ Three broad categories:
Streaming stored audio/video
Streaming live audio/video
Real-time interactive audio/video
Multimedia 2/19GC
Streaming stored video 2021-2022
❑ Users request on-demand compressed video files stored on
servers (e.g., YouTube)
The multimedia content is pre-recorded and stored on a server
❑ Streaming
The client typically begins to play out the video a few seconds after it begins
receiving the file
Streaming avoids having to download the entire file before playout begins
❑ Interactivity
Since the media is pre-recorded, the user may pause, reposition forward,
reposition backward, fast forward, and so on through the multimedia
content (a protocol, such as the Real-Time Streaming Protocol-RTSP, is
required)
❑ Continuous playout
Playout should proceed according to the original timing of the recording
Continuous playout is possible using client-side buffering and prefetching
Multimedia 3/19GC
Streaming stored video (cont.) 2021-2022
The amount of delay added
to each packet should make
the total delay for each
packet the same
playout
Network delay for playout delay for
the first packet the first packet
Client-side buffering and playout delay mitigate the effects of delay jitter
• Data must be received in time for its playout time
The throughput fluctuates, but the average throughput (averaged over 5-10
seconds) must remain above the video rate
End-to-end delay constraints are less stringent than those for streaming live
and real-time interactive applications
Multimedia 4/19GC
Streaming live audio/video 2021-2022
❑ A user receives live audio and video through the
Internet (e.g., Internet radio and Internet TV)
❑ The distribution of live audio/video to many
receivers can be efficiently accomplished using IP
multicast
Presently, multicast distribution is mostly accomplished via
application-layer multicast or via multiple unicasting
❑ As with streaming stored multimedia, the average
throughput should be larger than the video
consumption rate
Multimedia 5/19GC
Real-time interactive audio/video 2021-2022
❑ People use the Internet to interactively communicate with one
another
Examples: Voice over IP (VoIP), Video conferencing
❑ Obviously, highly sensitive to end-to-end delay and to delay jitter
❑ Real-time data on a packet-switched network require the
preservation of the time relationships between the packets of a
session
❑ Jitter can be removed by the combination of three mechanisms:
Prepending each chunk with a sequence number
• Incremented by one for each of the packets the sender generates
• Used by the receiver to detect packet losses or restore packet sequence
Prepending each chunk with a timestamp
• The sender stamps each chunk with the time at which the chunk was generated
Delaying playout of chunks at the receiver
• A playout buffer is needed
• The arrival time is separated from the playout time
Multimedia 6/19GC
2021-2022
Protocols for Real-Time Interactive Applications
Multimedia 7/19GC
Real-time Transport Protocol (RTP) 2021-2022
❑ RFC 3550 defines RTP
❑ RTP allows to have a standardized
packet format that includes fields for
audio/video data, sequence number
and timestamp
❑ RTP stands between UDP and the
multimedia applications
❑ RTP packets are not limited to
unicasting, but they can also be sent
over one-to-many and many-to-many
multicast tree
RTP streams emanating from multiple
senders in a videoconference belong to an
RTP session
Multimedia 8/19GC
RTP packet header format 2021-2022
Four main fields: payload type, sequence number,
timestamp and source identifier
payload sequence Synchronization Miscellaneous
time stamp
type number Source ID fields
type
❑ Payload type (7bits): indicates the type of encoding
currently being used
The sender can change the encoding on the fly during a
session
❑ Sequence number (16 bits): used by the receiver to
detect packet losses or restore packet sequence Multimedia 9/19GC
RTP packet header format (cont.) 2021-2022
❑ Timestamp (32 bits)
Used to re-create proper timing on the receiving end by using a
playout buffer
It corresponds to the time when the first byte of data in the
packet has been sampled
The “timestamp clock” increases by one for each sampling
period
• Example: PCMA audio (8 kHz sampling → sampling period equal
to125sec), 160 samples in a chunk
– Payload type =8
– The timestamp increases by 160 for each RTP packet when the source is
active
– The timestamp clock continues to increase even if the source is inactive
❑ (SSRC)- Synchronization Source identifier (32 bits)
It uniquely identifies the source of an RTP stream
The source randomly generates it Multimedia 10/19GC
Session Initiation Protocol (SIP) 2021-2022
❑ The Session Initiation Protocol (SIP) is an application-
layer protocol similar to HTTP
❑ SIP provides mechanisms
to establish a multimedia session over an IP network
for the participants to agree on media encodings
for the caller to determine the current IP address of the callee
for call management (e.g., add new media streams during the
call, change encoding during the call, invite new participants,
transfer calls, hold calls)
❑ It can run over UDP or TCP using the well-known port
number 5060
Multimedia 11/19GC
Setting up a call to a known IP address 2021-2022
The Alice’s SIP INVITE message
Bob
❑ Alice
indicates her current IP address,
her port number for receiving 167.180.112.24 193.64.210.89
the RTP packets, the encoding INVITE bob
c=IN IP4 16
m=audio 38
@193.64.21
7.180.112.2
4
0.89
she prefers to receive (PCM) 060 RTP/AV
P0
port 5060 Bob's
terminal rings
❑ The Bob’s “200 OK” message 200 OK
c=IN IP4 193.64.2
10.89
indicates his current IP address, port 5060
m=audio 48753 RT P/AVP 3
his port number, the preferred ACK
port 5060
encoding (GSM)
Law audio
❑ Suppose that Bob does not have port 38060
a PCM law encoder
Bob will instead reply with “606 Not
GSM
port 48753
Acceptable“, listing his encoders
Alice can then send a new INVITE
message, advertising a different
time time
encoder
❑ Of course, Bob can reject the call Multimedia 12/19GC
Example of an SIP message 2021-2022
INVITE sip:bob@poly.edu SIP/2.0 ❑ Typically, Alice knows
Via: SIP/2.0/UDP 167.180.112.24 only Bob’s well-known
From: sip:alice@umass.edu SIP address (and not his
To: sip:bob@poly.edu IP address),
Call-ID: a2e3a@pigeon.umass.edu intermediate SIP
servers are needed
Content-Type: application/sdp
Content-Length: 885
❑ Whenever an SIP
message passes through
an SIP device (including
c=IN IP4 167.180.112.24 the sender), the device
m=audio 38060 RTP/AVP 0 attaches a Via header
line
Notes: ❑ Alice’s INVITE message
❑ HTTP-like message syntax specifies in the header
❑ sdp = session description protocol
that SIP user agent
sends/receives SIP
❑ Call-ID is unique for every call messages over UDP
Multimedia 13/19GC
Name translation and User Location 2021-2022
❑ Every SIP user has an associated SIP registration server
(SIP registrar)
❑ Whenever a user launches an SIP application on a device,
the application sends an SIP register message to the SIP
registrar, informing it of its current IP address
❑ The registrar acknowledges the successful registration by
sending a response which specifies how long the
registration is valid (so refresh register messages are
needed)
register message:
REGISTER sip:registrar.poly.edu SIP/2.0
Via: SIP/2.0/UDP 193.64.210.89
Binding
From: sip:bob@poly.edu
To: sip:bob@poly.edu
Contact: Multimedia 14/19GC
Name translation and User Location (cont.) 2021-2022
❑ Alice sends the INVITE message to her SIP proxy
The message contains the address sip:bob@poly.edu
The proxy is responsible for routing SIP messages to the callee
❑ The SIP proxy does a DNS lookup on the SIP proxy for
“poly.edu” and then forwards the INVITE message to it
❑ Based on the current registration information for Bob,
the SIP proxy for poly.edu can route the request to Bob
❑ Alice’s SIP proxy (that for “umass.edu”) returns the
Bob’s SIP response message to Alice
The message contains Bob’s IP address
❑ Often SIP registrars and SIP proxies run on the same
host
Multimedia 15/17GC
SIP example: alice@umass.edu calls bob@poly.edu 2021-2022
It is assumed that both SIP
DNS server
registrar and SIP proxy are
running on the same host
DNS
umass 2. Umass SIP proxy forwards poly SIP
SIP proxy request to poly SIP proxy server 2 Registrar/Proxy
5
1. Alice sends INVITE 6-8. SIP response returned to Alice 5. Poly proxy server
message to umass SIP 6 3 forwards INVITE to
4 197.87.54.21, which
proxy 1
is running Bob’s
SIP user agent
9
128.119.40.186
9. Data flows between clients
197.87.54.21
Of course, there is also an SIP acknowledgement. For brevity, it is not shown
Multimedia 16/19GC
SIP gateways 2021-2022
❑ An SIP gateway is an application that interfaces a SIP
network to a network utilizing another signaling protocol
❑ An SIP gateway terminates the signaling path and can also
terminate the media path
An SIP to PSTN
gateway terminates
both the signaling and
media paths
SIP user agents and
H323 terminals can
exchange RTP media
information directly
Multimedia 17/19GC
The IP Multimedia Subsystem 2021-2022
❑ The IP Multimedia Subsystem (IMS) is an architecture, originally
defined and standardized by the 3GPP consortium, thought to
provide multimedia services exploiting an ALL-IP domain
crucial part of 5G networks
❑ IMS uses SIP as signaling protocol
❑ The Call Session Control Function (CSCF) provides the central
control function in the IMS Core Network to set up, modify, and
tear down multimedia sessions
❑ The CSCF function is distributed
across three types of functional
elements: Proxy CSCF (P-CSCF),
Interrogating CSCF (I-CSCF),
Serving CSCF (S-CSCF)
❑ Each network will typically have
multiple CSCFs of each type,
allowing load sharing and increased
Multimedia 18/19
availability (backup servers)GC
The IP Multimedia Subsystem (cont.) 2021-2022
❑ The P-CSCF is the entry point for a user equipment (UE)
Its role is to function as a proxy by accepting incoming requests (the initial
registration request or an invitation for a multimedia session) and forwarding
them to the entity that can service them
It directs requests that are a session invitation to a serving CSCF
Since this is the first-hop access, it maintains a security association (see Ipsec
later in the course) with the UE
❑ The I-CSCF is responsible for determining which S-CSCF should be
assigned for controlling the session requested by the UE
The I-CSCF obtains the address of the S-CSCF from the Home Subscriber
Server (HSS) during a registration request, and provides it to the P-CSCF for
subsequent multimedia requests
❑ The S-CSCF is responsible for conducting both registration and
session control for the registered UE’s sessions.
It functions as a registrar and enables the network location information of the
UE to be available at the HSS. It makes a determination to allow or deny
service to the UE. It executes the session request by locating the destination
endpoint and conducting the signaling toward it Multimedia 19/19You can also read
