1 / 52

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

Welcome to Week Nine! VoIP and IPTV + Introduction to Multicast. Topics: VoIP and IPTV Introduction to Multicast References and Tutorial Topics. Welcome to Week 4: Multimedia Frameworks and VoIP. Background RTP and RTCP Standards Signalling. Multimedia Transport over Data Networks.

yaholo
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related