Welcome to Week Nine! VoIP and IPTV + Introduction to Multicast

P00556-7-1

MultiserviceNetworks

Oxford Brookes University VoIP and IPTV + Intro Mcast: Chris Cooper/Geoff Tagg Mar 2010

Welcome to Week Nine!VoIP and IPTV + Introduction to Multicast

Topics:

VoIP and IPTV

Introduction to Multicast

References and Tutorial Topics

P00556-7-2



Welcome to Week 4:Multimedia Frameworks and VoIP

Background

RTP and RTCP

Standards

Signalling

P00556-7-3



Multimedia Transport over Data Networks

UNIVERSE (1980 – 1983) – and many other R&D projects IETF

– Early voice experiments carried out in 1970s

– Effort accelerated during 1990s» Leading to work on IntServ and DiffServ

ITU-T– Introduction of digital telephone networks led to development of multimedia-

aware signalling» Signalling System Number 7 (Q.700 Series) within the network» ISDN Q.931 for user-network signalling» ATM (Q.2931) had a fully-fledged multiservice signalling scheme

– A number of multimedia frameworks followed» Discussed later

QoS schemes need to be integrated with the multimedia streams– Requires a multi-faceted approach

» End-to-end and hop-by-hop components

P00556-7-4



Protocol Considerations

VoIP protocol structures are designed to be lightweight Existing Transport protocols pose problems

– TCP introduces

» possibility of retransmissions

» variable-rate throughput owing to congestion control mechanisms

– UDP provides application demultiplexing and checksum

» necessary, but insufficient

VoIP frameworks– Use existing (public network) standard voice and video coding schemes

– Define two new transport protocol: RTP and ScTP

– Add call control alternatives: H.323 (public networks) or SIP (IP networks)

– Operate best in conjunction with QoS-aware network differentiation

» IntServ or DiffServ

RTP = Real-time Transport ProtocolScTP = Stream control Transport Protocol

P00556-7-5



Multimedia Transport over IP

IP

UDP

Multimedia applications

RTP RTCP

Audio and video codecs

Note: shows data transfer protocols only; signalling protocols and control infrastructure are discussed later

P00556-7-6



Voice over IP

Background

RTP and RTCP

Standards

Signalling

P00556-7-7



RTP: The Real Time Transport Protocol

Supports isochronous transmissions over IP networks– For example multicast audio and/or video

– Incorporates provision for audio and video mixers and translators

– RTP is for isochronous transmission while TCP and UDP are asynchronous transmission

Operates with unicast or multicast streams Uses minimalist approach to protocol design: Little supports

– Adds timestamps and sequence numbers to outgoing voice/video stream

– Timestamps provide receiver synchronization support and help with jitter compensation

– Sequence numbers help to indicate packet loss or out-of sequence delivery

– Leaves UDP to add checksum for packet verification

Supports mixers and translators– Mixers can merge several streams onto single stream

– Translaters (or ‘transcoders’) translate between different transmission schemes

P00556-7-8



RTP Packets

Voice or video samples are encapsulated in RTP packets– Generally speaking, one UDP datagram carries one RTP packet

Timestamp

SSRC (synchronizing source identifier)

CSRCs (contributing source identifiers)

Sequence numberFlags Payload type

payload

optional header extension

P00556-7-9



RTP Header Flags

V: version = 2

P: set to 1 to indicate payload padding (length is in last byte)

X : set to 1 if extension headers present (rare)

CC: = CSRC count (number of contributors)

M: marker bit (marks, e.g., new talkspurt or end of video frame)

Timestamp

Sequence numberPayload typeV XP CC M

bit 0 2 3 4 8 169

P00556-7-10



Common RTP Payload Types

0 PCM μ-law (PSTN audio) 26 JPEG video

3 GSM audio 31 H.261 video

8 PCM A-law (PSTN audio) 33 MPEG-2 video

9 G.722 audio 34 H.263 video

15 G.728 audio 35-95 Unassigned or reserved

18 G.729 audio 96-127 Dynamic payload types

Timestamp

Sequence numberPayload typeV XP CC M

bit 0 2 3 4 8 169

P00556-7-11



RTCP

Adds periodic control frames into session traffic– Can support multiple sessions having multiple data streams

Provides several services to RTP session participants– Stream reception reports

– Session source descriptor

– Optional participant information

– Participant leaving session

– Other, application-specific, functions

Includes self-imposed rate-based flow control for scalability– Ensures RTCP messages do not exceed 5% of overall session (RTP) traffic

Several RTCP messages can be packed into a single UDP datagram

P00556-7-12



RTCP Messages

Sender report contains transmission and reception information from active senders

– Associates RTP timestamps, packet and byte counts with an NTP timestamp

– Includes reception report blocks (one for each SSRC known to sender)

Receiver reports– Transmission and reception information from listeners who are not also

active senders

» Similar to sender reports, but exclude timing information

Source description packet– Includes participant CNAME

– May optionally include one or more of:

» Sender name, email, telephone number, location

BYE contains details of sender(s) leaving session

P00556-7-13



Voice over IP

Background

RTP and RTCP

Standards

Signalling

P00556-7-14



ITU-T Voice and Video Codec Standards

ITU-T standards focus on voice and video capture for transport over public networks

Voice codec standards include– PCM-based: G.711 (64kbps), G.722 (64kbps wideband voice),

G.726 (32kbps ADPCM)

– Predictive modelling: G.728 (16kbps), G.729 (8 kbps) and G.729A (8 kbps)» Computationally complex and lower quality than PCM-based schemes» May introduce additional coding delay

Video codec standards include– Intra-frame compression only: H.261 (64-1920kbps for video over ISDN),

H.262 (video over ATM)

– Intra- and inter-frame compression: H.263 (video over PSTN)

Video standard also devised by Moving Picture Experts Group (MPEG) MPEG-4 and H.264 (2003) are the same

– Result of ITU-T/MPEG collaboration

P00556-7-15



ITU-T Audio and Video Frameworks

ITU-T have addressed audio and video standards for many years– Initially concentrating on capture, compression and transmission over

circuit networks

– Latterly, including packet networks

» H.323 called these ‘Networks with no QoS guarantees’

Have developed a series of frameworks for integrated solutions– H.320: Videoconferencing over ISDN (v1 – 1996)

– H.321: Videoconferencing over Broadband ISDN (ATM/SDH) (1998)

– H.322: Videoconferencing over LANs with QoS (1996)

» E.g. isochronous Ethernet – IEEE 802.9

– H.324: Videoconferencing over PSTN (v1 – 1995)

– H.323: Videoconferencing over packet networks (v1 – 1996)

» v2 – 1998; v3 – 1999

» v4 – 2000; v5 - 2003

ITU-T = International Telecommunications Union :Telecommunications (Standardization Sector)

P00556-7-16



Standards for Voice

Codec standard

Compression algorithm

Digital bitrate(kbps)

Sample size(ms)

MOS Use

G.711 PCM 64 0.125 4.1 PSTN

G.726 ADPCM32, 24,

160.125 3.85 ISDN

G.728 LD-CELP 16 0.625 3.61 ISDN

G.729 CS-ACELP 8 10 3.92 VoFR and VoIP

G.729A CS-ACELP 8 10 3.7Algorithm less

complex than G.729

G.723.1 ACELP 5.3 30 3.65 Speech modems

ADPCM = adaptive differential pulse code modulationCS-ACELP = conjugate-structure algebraic-code-excited linear predictionLD-CELP = low-delay code-excited linear predictionVoFR = voice over frame relay

P00556-7-17



Other Audio Standards

Format Sampling rate Digital bitrate Use

MP2 32–48 kHz 32–284 kbpsDigital audio broadcasting

MP3 32–48 kHz 32–320 kbpsPC, personal and

Internet

WMA 8 Up to 48 kHz Variable Near-CD quality

WMA 9 Variable Variable Lossless, high-quality

MPEG-4AAC

8–96 kHzVariable,

depending on algorithm

MP3 replacementUses different

algorithms dependingon required quality

and bitrate

AAC = advanced audio codingMPEG = Moving Picture Experts GroupMPn = MPEG-1 Layer nWMA = Windows Media Audio

P00556-7-18



Standards for Video

Codec standard

Date published

Digital bitrate(Mbps)

Use

H.261 1990 0.46–1.92 Videoconferencing over ISDN

H.262/MPEG-2 1997 4–9 DVD, satellite and cable TV

H.263 1997 1–9 Small-screen PSTN,

videoconferencing, VoIP;extensible to larger resolutions

H.264/MPEG-42003–2005

1.5–2.5 High-quality video at relatively low bitrates; e.g., HD video storage,

IPTV

P00556-7-19



Voice over IP

Background

RTP and RTCP

Standards

Signalling

P00556-7-20



Topics:

VoIP and IPTV



P00556-7-21




Overview

Why Multicast?

Trees, addressing and membership

Dense and sparse mode; reverse path forwarding; more trees

Tutorial Topics

P00556-7-22



Reminder of some application examples I

one-to-many:

– web or Internet TV

» subscriber joins in real time at point

‘live programme’ has reached

– (streaming) video on demand

» subscriber typically wishes to see

from beginning

many-to-many:

– conferencing (usually all-to-all within a

group)

– group teaching (all listen, maybe only

subset speak)

P00556-7-23



Reminder of some application examples II

many-to-one: Concast

– statistics logging

– sensor ‘fusion’ (plant or utility infrastucture monitoring, wildlife tracking)

– coursework submission

– not studied very much, except as a particular case of many-to-many

P00556-7-24



Terminology reminder I

Often classified in terms of numbers of senders and receivers (m:n) Distinguish application and network views of communication

– telephony is (mostly!) two-way alternate

» underlying communications channel may be full-duplex, half-duplex, or a pair of simplex channels in opposing directions

P00556-7-25



Terminology reminder II

one-to-one: unicast (1:1)– one-to-one: usually of application

– unicast almost always refers to layers below application

one-to-many: (sometimes many-cast, also multicast & broadcast) (1:n)– one-to-many: application or lower layers

– multicast: mainly lower layers, implies subset of all possible recipients

– many-cast: often application

– broadcast: application or lower layers; implies all possible recipients

many-to-one: (sometimes concast) (m:1)– many-to-one: application

– concast: deprecated

m-to-n: (sometimes multipeer) (m:n), or all-to-all if m = n

P00556-7-26



Senders and Receivers I

Group communication– each member may be a sender, a receiver, or both

If no member is a receiver, communication is pointless!– important to operation of multicast routing protocols

Most communication is thought of in terms of multiple one-to-many– m-to-n is often thought of as m instances of 1-to-n

– rather like constructing full-duplex channels out of simplex channels

– Note that this implies nothing about any relationship between senders and receivers

P00556-7-27



Senders and Receivers II

For a member that is both receiver and sender, does it receive its own transmissions?

– audio channel in conference: usually not, confusing

– video channel in conference: sometimes could be useful

– email to a list: often an option on the list; defaults vary!

– CSMA/CD: CD would not work without it!

» but host usually chooses not to listen to own frame at a higher level

– So, typically not

P00556-7-28



Issues for multicast I

Identifying group members– Neither unicast nor broadcast are adequate

– Achieved with special addressing scheme for active participants

Tracking current group membership– Uses a dynamic membership protocol

– Not required for fixed groups

Efficient distribution mechanism– To avoid multiple copies of same information traversing same part of network

– Network must be multicast-aware

– Capable of packet replication and controlled flooding

Multicast routing scheme to maintain fault-tolerant distribution topology– Discussed later in course

P00556-7-29



Issues for multicast II

Scaling

– how to deal with large numbers of users (100s, 1,000s, …)?

– affects network and end stations

– reliable unicast protocols need acknowledgements from receiver to sender

» reliable multicast cannot operate in the same way

Timing

– a much more complex set of issues in group communication since there are more than two views of time

– group aspects are primarily end host application concerns,not network

We will confine our attention to network support for multicast

Audio-video conference as exemplar: major application driver

P00556-7-30




Overview

Why Multicast?



Tutorial Topics

P00556-7-31



Network Multicast I

An immediate scaling problem:– multipoint conference: all senders need to reach all receivers with each stream

» audio, video, shared application (e.g., whiteboard, powerpoint, excel)

Problems with using replicated unicast:– senders will (with large number of receivers) be overloaded– links near senders will also be overloaded– delay will increase: sender sends many copies sequentially– large conferences, TV distribution, etc, will be impossible– [see diagram]

P00556-7-32



Using replicated unicast

S

Rx Rx

Rx

Rx

Rx

Rx

Rx

Rx

Rx

R

R

R

R

9

3

2

2

1

1

P00556-7-33



Network Multicast II


– audio, video, shared applications (eg, whiteboard, powerpoint, excel)

Problems with using replicated unicast (recap.):– senders will (with large number of receivers) be overloaded– links near senders will also be overloaded– delay will increase: sender sends many copies sequentially– large conferences, TV distribution, etc., will be impossible

Solution:– eliminate multiple copies of same packet on any link and from sender– ensure ‘best’ routes are used: much harder– [see diagram]

P00556-7-34



Using multicast

S

Rx Rx

Rx

Rx

Rx

Rx

Rx

Rx

Rx

R

R

R

R

E.g., sender-based tree, overlaid on physical network:1 copy of each packet per link

P00556-7-35



Network Multicast III


» audio, video, shared application (e.g., whiteboard, powerpoint, excel)

Problems with using replicated unicast (recap.):– senders will (with large number of receivers) be overloaded– links near senders will also be overloaded– delay will increase: sender sends many copies sequentially– large conferences, TV distribution, etc., will be impossible

Solution:– eliminate multiple copies of same packet on a link;– ensure ‘best’ routes are used: much harder

NB sender-based tree not necessarily optimal: » receiver-based possible;» core-based tree (CBT) has advantages, idea incorporated into PIM-SM

Overload at or near receiver?– only few (one) sender(s) active: may be able to receive all– select or combine near receiver

P00556-7-36




Overview

Why Multicast?



Tutorial Topics

P00556-7-37



Types of Multicast Tree

sender-based (as previous diagram)– SBT is were the tree is routed at the sender

– is most economical way of doing isolated multicast in a network

– is not static like in the case of spanning tree protocol its changes as the number as host changes so the router has to argile enough for instance I got no people here I don’t need to send any packet here, I got many ppl here I need to send more packet here

receiver-based tree also possible– natural for fusion-based applications

– not studied here

» but we will mention destination-based flows in the context of MPLS core-based

– compromise

– may be appropriate as default

– engineer sender-based as traffic begins to flow

P00556-7-38



Routing and Membership

Growing, pruning, removing multicast trees is job of multicast routing– algorithms and protocols

– remember, IP routing is amongst subnets (whether unicast or multicast)

– So if a person come or leave the network there is a membership group to coordinate the trees for the multicast distribution of packets

– -there are two major membership protocols

– The major was IGMP v1

Starts from membership and addressing– Internet Group Management Protocol: IGMP

» two versions; IGMPv1 largely obsolete

P00556-7-39



Multicast Addressing

Fixed multicast groups use “well-known” (reserved) addresses– Specified in IETF Assigned Numbers list

– Gives reserved L2 and L3 addresses

– For example

» The All Spanning Tree Bridges MAC address

» The All OSPF Routers IP address Dynamic multicast groups can select from a range of reserved addresses

– Most of the original Class D address group

» IP address range 224.0.0.0–239.255.255.255 (IP Prefix 224/4)

– Special ranges include

» 224.0.0/24: reserved for link local multicast Router will not forward off subnet

» 224.2/16 reserved for multimedia conference calls

» 239.252/14 reserved for site-local multicast IETF also gives mapping of L3 to L2 equivalent addresses

– Programmed dynamically into network interface cards

P00556-7-40



Some Multicast Addresses

224.0.0.1All systems

on this subnet

224.0.0.2All routers on this subnet

224.0.0.6All (OSPF) Designated

Routers

224.0.0.9All RIP2 routers

224.0.0.10

All EIGRP routers

224.0.0.11

All mobile agents

224.0.0.13

All PIM routers

Some reservedmulticast addresses

All OSPF routers224.0.0.5 (IP)

All Spanning Tree bridges01-80-C2-00-00-00 (MAC)

All conference participants224.2.1.225 (IP)

P00556-7-41



IGMP: Internet Group Membership Protocol

Timer-driven query/response protocol between routers and hosts

– Hosts join group using multicast address for that group

– Router polls All Systems group (224.0.0.1) periodically

» To reaffirm membership

Two versions of IGMP

– IGMPv1 specified in RFC 1112

» Largely historical

» Leaves group by not respondingto Membership Report

» Allows association to time out

– IGMPv2 specified in RFC 2236

NB. In IPv6, IGMP is part of ICMPv6

Leave Group

Join/ReaffirmMembership

P00556-7-42



IGMP (Version 2)

Each subnet has at least one multicast router– Where there is more than one router, one

becomes the Querier for that subnet

– Multicast routers defer to Queriers with a lower IP address

» Prevents excessive query traffic

The Querier for a subnet– Tracks active group addresses

» Periodically sends Query messages Either general query to AllSystems group

– 224.0.0.1

Or a Group-specific Query

– Stops sending when no hosts respond

» Or all hosts have left group

» And informs multicast routing protocol

Still some members of 224.2.1.225out there?

P00556-7-43



IGMP (Version 2 – cont.)

Multicast host on subnet– Joins group by multicasting a Membership

Report for that group address

– Remains in group by respondingto Query messages

» Includes addresses of all groupsfor which host wishes to retainmembership

» Delays response for random periodto reduce number of responses forsame group

– Leaves group by sending Leave message toAllRouters group

» 224.0.0.2

Still some members of 224.2.1.225out there?

MRep224.2.3.1

Yes

Leave Group224.2.3.1

P00556-7-44




Overview

Why Multicast?



Tutorial Topics

P00556-7-45



DM / SM Protocols

There are two ways of distributing multicast: Dense Mode:

– DM is sending the multicast packet to everyone in the group. Periodically sending to everybody it important when you got a lot of people in a company LAN but it wont woke in the IP internet u got periodic saturation

– Typified by ‘flood and prune’ behaviour

– Appropriate only if:

– restricted scope: not whole world

– most hosts in scope want to receive

– Sparse Mode:

– you send when someone sign on– Typified by ‘send on request’ behaviour

– group membership (though actually, it’s likely needed anyway).– End-system gets nothing unless it explicitly asks for it

– Appropriate when:

– only some of hosts want to receive

– scope is potentially worldwide

P00556-7-46



Topics:

VoIP and IPTV



P00556-7-47



References for VoIP

Author Chapters and main topics Notes

Peterson &Davie

9.3 Multimedia ApplicationsRTP, RTCP, SIP and SDP, but not much on H.323

Halsall 5.3 IPC StandardsOverviews of the H.32x frameworks and their constituent standards

There is some VoIP in one of the texts from last semester:

Forouzan

(4th edition)29.5 Real-Time Interactive Audio/Video As P&D

Note: Use manufacturers’ web pages with care!

P00556-7-48



Refs. for multicast, RSVP & IntServ

Wittman & Zitterbart: Multicast Communication– parts of Chapter2; parts of Chapter 3: 3.1–3.3; parts of Chapter 4 (up

to 4.1.2); Mbone & application: parts of Chapter 7.

Peterson & Davie: Computer Networks (3rd ed.)– Section 4.4,esp. 4.4.3.

– Chapter 6, 6.1, 6.2, 6.5.2

Stallings: High-Speed Networks (2nd ed.)– Section 16.2 (multicast); Chapter 17: Sections 17.1, 17.2.

– Chapter 18: 18.1 RSVP.

Zheng Wang: Internet QoS– Chapter 1: 1.1; Chapter 2, 2.1, 2.3, 2.4, 2.5

P00556-7-49



VoIP and IPTV Tutorial Questions

1. General pointsa) What is signalling and what differences would you expect to see between

normal telephony and multimedia communication protocols?

b) What type of voice do G.722 and G.729.1 encode?

c) Which protocols are responsible for voice/video transport?

2. H.323a) What is an ITU-T framework, and in what way does it support QoS?

b) What are the main components of an ITU-T framework?

3. SIPa) What happens immediately after the initial handshake?

b) SIP supports ‘presence’. What is this?

P00556-7-50



VoIP and IPTV Tutorial Questions (cont.)

4. RTP

a) What is an RTP session?

b) Are RTP packets carried individually across an IP Network?

5. RTCP

a) What are the main functions of RTCP?

b) What sort of QoS information is included in an RTCP reception report block?

P00556-7-51



Tutorial topics: multicast

1. What IEEE MAC group addresses are IP multicast addresses 224.1.5.20 & 227.129.5.20 mapped into? What happens at a receiver interested in only one of these?

2. Multicast is good for senders. What about receivers? Why does audio multicast work for the receivers? What about video? Discuss.

3. What is IGMP snooping?

P00556-7-52



Tutorial topics: multicast (cont.)

5. Consider the set of four routers interconnected as in the diagram.

If a single multicast packet is injected at a, using simple flooding (forward on all links exceptentry link), what will happen on the internal & external links (b, c, d)? Now use RPF.

6. Draw a diagram to demonstrate flooding + RPF delivering duplicate packets.

7. What messages in which protocol might you use for pruning and grafting?

R

R R

Ra

dc

b

Date post:	15-Jan-2016
Category:	Documents
Upload:	yaholo
View:	50 times
Download:	0 times

Welcome to Week Nine! VoIP and IPTV + Introduction to Multicast

Documents