Outline• Multimedia is different• Real Time Protocol (RTP)• Session Description Protocol (SDP)• Session Initiation Protocol (SIP)Elastic vs. Inelastic Workloads• Some applications adapt to network performance- Examples: file transfer, printing.- Will perform the same task regardless of bandwidth- Such workloads are elastic—they adapt fine to lowerperformance• Other apps have traffic performance requirements:- Example: video requires a certain available bandwidth- Workloads that fail if requirements not met are inelasticWhy is this an issue?• Most data networks provide best effort delivery- Try their best to deliver your data, but no guarantees• Traditional data applications:- Use protocols such as TCP to deal with data loss andunknown network available bandwidth,- Tend to generate data in bursts, and- Normally do not require any kinds of guarantees from thenetwork• Elastic workloads will often swamp inelastic ones- BitTorrent can make Skype sound terrible• Traditional networks have not been designed withQuality Of Service (QoS) in mindWhere do things break?EncoderDecoderVideoDecoderVideoVideoDecoderHubRouter1.5 Mb/sRouterHub700 kb/s700 kb/s700 kb/sVideoEncoderVideoVideoEncoder•Things break when there is a contention for resources• Service may be unacceptable for allExample of a Network with QoS:The Phone Network• Before you can communicate- Must negotiate a channel with the network- If network lacks the resources, your call is not completed• If call is completed, you “own” circuit- Yours for the duration of the call- Regardless of the additional traffic in the network• Circuit has appropriate capacity for voiceQoS Components• Must know traffic characteristics and requirements- Must describe them to the network to reserve bandwidth• Need signaling protocol betw. nodes & net. mgmt• The Network must implement Admission Control- Reject connections exceeding available bandwidth• The Network may also implement Traffic Policing- Make sure traffic emitted by the nodes conform to theagreed parametersWhere to Provide?• 1990s and early 2000s saw a lot of work on getting QoSinto layer 3: Resource ReSerVation Protocol (RSVP)- Fine for walled garden networks, e.g., IP-telephony backbones- Consumer applications do not want to assume QoS support• There’s a lot more to multimedia than simple QoS- Session establishment, media negotiation• Higher layers need to be involved- Transport: Real Time Protocol (RTP)- Session: Session Description Protocol (SDP)- Application: Session Initiation Protocol (SIP)Outline• Multimedia is different• Real Time Protocol (RTP)• Session Description Protocol (SDP)• Session Initiation Protocol (SIP)RTP [RFC 3550]• Provides end-to-end delivery services for datawith real-time characteristics- E.g. interactive audio and video- Services include: Source & payload type identification,Sequence numbering, Time-stamping, Delivery monitoring• Typically used on top of UDP- Relies on UDP for multiplexing & checksums• Work over other network or transport protocols- Lower-level must provide framing & length indicationRTP continued• Supports data transfer to multiple destinations- Uses network-level multicast if available• Does not ensure timely delivery/QoS guarantees- Relies on lower-layer services to do so• Does not guarantee in-order delivery• Does not even guarantee delivery- Underlying network need not be reliable- Underlying network need not deliver packets in sequence- RTP sequence numbers determine proper location of packetTwo parts to RTP1. RTP- Carries data that has real time properties2. RTCP- Monitors quality of service- Conveys information about participants in a session(for “loosely controlled” sessions)RTP protocol framework• RTP is not a complete protocol- It is a protocol framework, deliberately not complete- Tailored to applications through modification, not options• Each applications needs a profile specification- defines set of payload type codes- defines mapping of payload types to payload formats• Also need actual payload format specificationRTP Session• Association among a set of participantscommunicating with RTP• A session is defined by a particular pair ofdestination transport addresses- One network address- A pair of ports (one for RTP and one for RTCP)- May be common to all participants (as in IP multicast)- May be different for each (individual network address +common port address)Synchronization Source (SSRC)• Source of a stream of RTP packets- Randomly chosen 32-bit numeric identifier- Intended to be globally unique- Carried in RTP header (not dependent on network address)• Timing & sequence number space are per-SSRC- Lets receiver separately handle packets from same source- RTCP sender/receiver reports are per SSRC• One participant may use multiple SSRCs- Should use one for each stream- Different streams may have different media clock rates- Or one stream may switch encodings mid-stream• Binding of SSRCs is provided through RTCP- E.g., if participant uses multiple cameras in one sessionRTP Translators and Mixers• Intermediate act as gateways at RTP layer- Allow RTP traffic to pass through firewalls- Mix and/or recode data to fit over a low bandwidth link• Translators leave original SSRC intact- So sources distinct even when all packets from translator- Translator may change payload type or combine packets• Mixers combine streams from multiple sources- Output requires new SSRC with new seq/timestamps- Original sources conveyed in each packet using“contributing sources” (CSRC) listRTP Packet• Fixed RTP packet header• List of contributing sources (possibly empty)• RTP Payload- E.g. audio samples, compressed video data, etc. . . .RTP Data Header0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X| CC |M| PT | sequence number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| timestamp |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| synchronization source (SSRC) identifier |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| contributing source (CSRC) identifiers || .... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RTP Data Header details• Padding (P, 1 bit)- Packet ends w. padding octets ending in padding length- E.g., useful when encrypting with block cipher• Extension (X, 1
View Full Document