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

1. Welcome to Week Nine!VoIP and IPTV + Introduction to Multicast Topics: VoIP and IPTV Introduction to Multicast References and Tutorial Topics

2. Welcome to Week 4:Multimedia Frameworks and VoIP Background RTP and RTCP Standards Signalling

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

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 Protocol ScTP = Stream control Transport Protocol

5. Multimedia applications Audio and video codecs RTCP RTP UDP IP Multimedia Transport over IP Note: shows data transfer protocols only; signalling protocols and control infrastructure are discussed later

6. Voice over IP Background RTP and RTCP Standards Signalling

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

8. Sequence number Payload type Flags Timestamp SSRC (synchronizing source identifier) CSRCs (contributing source identifiers) optional header extension payload RTP Packets • Voice or video samples are encapsulated in RTP packets • Generally speaking, one UDP datagram carries one RTP packet

9. bit 0 2 3 4 8 9 16 Sequence number V Payload type P X CC M Timestamp 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)

10. bit 0 2 3 4 8 9 16 Sequence number V Payload type P X CC M Timestamp Common RTP Payload Types

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

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

13. Voice over IP Background RTP and RTCP Standards Signalling

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

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)

16. Standards for Voice ADPCM = adaptive differential pulse code modulation CS-ACELP = conjugate-structure algebraic-code-excited linear prediction LD-CELP = low-delay code-excited linear prediction VoFR = voice over frame relay

17. Other Audio Standards AAC = advanced audio coding MPEG = Moving Picture Experts Group MPn = MPEG-1 Layer n WMA = Windows Media Audio

18. Standards for Video

19. Voice over IP Background RTP and RTCP Standards Signalling

20. Topics: VoIP and IPTV Introduction to Multicast References and Tutorial Topics

21. Introduction to Multicast Overview Why Multicast? Trees, addressing and membership Dense and sparse mode; reverse path forwarding; more trees Tutorial Topics

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)

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

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

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

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

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

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

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

30. Introduction to Multicast Overview Why Multicast? Trees, addressing and membership Dense and sparse mode; reverse path forwarding; more trees Tutorial Topics

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]

32. Using replicated unicast Rx Rx R Rx 1 3 9 S Rx R 1 Rx 2 R 2 R Rx Rx Rx Rx

33. Network Multicast II • An immediate scaling problem: • multipoint conference: all senders need to reach all receivers with each stream • 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]

34. Using multicast E.g., sender-based tree, overlaid on physical network:1 copy of each packet per link Rx Rx R Rx S Rx R Rx R R Rx Rx Rx Rx

35. Network Multicast III • 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 (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 harderNB 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

36. Introduction to Multicast Overview Why Multicast? Trees, addressing and membership Dense and sparse mode; reverse path forwarding; more trees Tutorial Topics

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 flowsin the context of MPLS • core-based • compromise • may be appropriate as default • engineer sender-based as traffic begins to flow

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

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

40. All conference participants 224.2.1.225 (IP) All OSPF routers 224.0.0.5 (IP) All Spanning Tree bridges 01-80-C2-00-00-00 (MAC) Some Multicast Addresses Some reserved multicast addresses

41. Leave Group Join/Reaffirm Membership 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

42. Still some members of 224.2.1.225 out there? 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

43. MRep 224.2.3.1 Leave Group 224.2.3.1 Yes Still some members of 224.2.1.225 out there? IGMP (Version 2 – cont.) • Multicast host on subnet • Joins group by multicasting a MembershipReport 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

44. Introduction to Multicast Overview Why Multicast? Trees, addressing and membership Dense and sparse mode; reverse path forwarding; more trees Tutorial Topics

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

46. Topics: VoIP and IPTV Introduction to Multicast References and Tutorial Topics

47. References for VoIP

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

49. VoIP and IPTV Tutorial Questions • General points • What is signalling and what differences would you expect to see between normal telephony and multimedia communication protocols? • What type of voice do G.722 and G.729.1 encode? • Which protocols are responsible for voice/video transport? • H.323 • What is an ITU-T framework, and in what way does it support QoS? • What are the main components of an ITU-T framework? • SIP • What happens immediately after the initial handshake? • SIP supports ‘presence’. What is this?

50. VoIP and IPTV Tutorial Questions (cont.) • RTP • What is an RTP session? • Are RTP packets carried individually across an IP Network? • RTCP • What are the main functions of RTCP? • What sort of QoS information is included in an RTCP reception report block?