Qos & RTP SIP and WebRTC

1. Lecture 22: Quality of Service

1.1. Why best-effort service may not be sufficient

The Internet was designed around a best-effort service model. Routers try to forward packets, but the network does not promise that a packet will be delivered, how long delivery will take, or how much throughput a flow will receive.

The IPv4 TTL field limits how long a packet can continue to be forwarded. Its maximum value is 255, but it is fundamentally a hop limit: each router decrements it. It should therefore not be interpreted as a strict 255-second delivery guarantee.

Available throughput is also unpredictable. When several congestion-controlled flows share a bottleneck, TCP attempts to divide the available capacity among them. However, the resulting share depends on the number of competing flows, their RTTs, their congestion-control algorithms, and whether all senders actually behave cooperatively. A large non-responsive UDP flow may consume capacity without reducing its rate in the way TCP does.

This uncertainty is acceptable for many file transfers. It often matters very little whether a download finishes slightly earlier or later. However, it can seriously affect interactive or real-time applications whose usefulness depends on sufficiently low delay, jitter, loss, or a minimum data rate.

1.2. QoS and QoE

Quality of Service, or QoS, describes measurable network properties such as:

Property	Meaning
Bandwidth	The data rate available to an application or traffic class
Delay	The time required for data to reach the receiver
Jitter	Variation in packet delay
Packet loss	The fraction of packets that do not arrive
Availability	How often the service is usable

Quality of Experience, or QoE, describes how a user perceives the service. QoE depends partly on QoS, but it also depends on application design, codecs, screen size, user expectations, and human perception. Consequently, QoS can normally be measured directly, whereas QoE is more subjective.

1.3. Not all packets have identical requirements

The best-effort model treats packets similarly, but their purposes and performance requirements differ.

Routing and control-plane traffic is especially important. If BGP, OSPF, IS-IS, or network-management traffic cannot get through during congestion, routes may fail. Traffic can then move to another link, overload that link, and cause a sequence of further failures. Operators therefore commonly isolate or prioritize essential control traffic.

Voice, interactive video, and online games are sensitive to delay and jitter. A voice call with a large delay becomes awkward because participants repeatedly talk over one another or wait too long for a reply. Irregular delivery also makes audio sound discontinuous unless the receiver introduces sufficient buffering.

Low latency can also have direct economic value. Financial-trading systems, for example, may benefit from receiving information only a few milliseconds earlier than competitors.

In contrast, bulk file transfer and peer-to-peer downloads are usually elastic. They benefit from additional bandwidth but can continue operating when their rate temporarily falls.

Malicious traffic creates another reason not to treat every packet equally. Forwarding DDoS traffic, spoofed traffic, or unwanted traffic through the entire network wastes resources. However, allowing networks to classify and discard traffic also creates difficult policy, privacy, and censorship questions.

1.4. Three factors in a QoS design

A QoS mechanism must balance three connected questions.

1.4.1. Application requirements

The network or application must first determine what performance is actually needed. This is difficult because a single application does not necessarily have one fixed bitrate. A video showing a mostly static scene may compress much more efficiently than a video containing rapid movement.

Applications may also adapt their encoding or resolution. Therefore, the required bandwidth depends on both the content and the acceptable output quality.

1.4.2. Resources needed to provide the performance

After the application requirements are known, the network must determine how much link capacity, queue space, and processing capacity are required to meet them while still serving other traffic.

1.4.3. Complexity, cost, and policy

Traffic differentiation requires classification, accounting, policing, scheduling, configuration, and sometimes billing. These mechanisms consume processing resources and increase operational complexity.

A technically effective system may still not be deployed if implementing, operating, and charging for it costs more than simply adding capacity. Differentiation also conflicts with some interpretations of network neutrality, because improving one class usually means reducing the service available to another class.

1.5. Utility as the objective of resource allocation

A network should not merely maximize the number of transmitted bits. A more useful objective is to maximize the total utility experienced by its users:

\[ \sum_i U_i(x_i), \]

where \(x_i\) is the bandwidth allocated to user or flow \(i\), and \(U_i(x_i)\) describes how useful that allocation is to the application.

The shape of the utility function depends on the application.

1.5.1. Elastic applications

For an elastic application, utility rises as bandwidth increases, but the additional benefit of each extra unit of bandwidth becomes smaller. Its utility curve is therefore approximately concave.

The difference between an extremely slow download and a moderately fast download is important. The difference between a 50-second download and a 45-second download is usually less important.

Because of these diminishing returns, sharing a bottleneck among many elastic flows often produces high total utility. Even a small allocation remains useful, and no admission-control mechanism is normally necessary. This property is one reason why the Internet’s best-effort model works well for elastic traffic.

1.5.2. Tolerant real-time applications

Interactive audio and video usually have a lower limit below which the application becomes unusable. Above this limit, the application may adapt its codec, frame rate, or resolution to the available resources.

These applications are sometimes called tolerant real-time applications. They are not completely rigid, but their utility falls sharply if bandwidth becomes too low or delay becomes too high.

1.5.3. Hard real-time applications

A hard real-time application requires a strict performance bound. Examples may include some remote-control, industrial-control, or safety-critical medical applications.

For these applications, providing a little bandwidth to every flow may provide almost no utility. If every flow is kept below its minimum useful rate, all flows may fail. It can therefore be better to admit only some flows and give each admitted flow enough resources to operate.

1.6. Admission control

Admission control decides whether a new flow may enter a system.

Suppose a link has enough capacity to support ten calls at an acceptable quality. Allowing an eleventh or twentieth call may reduce every call below its usable performance threshold. Admission control refuses new calls before this overload occurs.

The controlled entity can vary. Admission control may operate per connection, per user, per customer, per application, or per traffic aggregate.

Admission control is therefore closely connected to inelastic traffic. Elastic traffic can normally share reduced capacity, whereas inelastic traffic may require the network to keep the number of admitted flows below a limit.

1.7. Dimensioning a best-effort network

One alternative to explicit QoS is to install enough capacity that congestion rarely occurs. This preserves the simple best-effort model and avoids most per-flow control mechanisms.

The difficulty is determining how much capacity is enough. A utilization graph alone may not answer this question. High utilization may be caused by a temporary event, a routing change, a major sports broadcast, or a short-lived traffic surge. After an upgrade, demand or routing may change again, producing a completely different result.

Providers therefore examine long-term patterns instead of isolated peaks. A continuously heavily used link may be considered for an upgrade, but keeping every link almost empty would be unnecessarily expensive. In a TCP network, some bottleneck normally exists because TCP increases its rate until it encounters congestion.

Common bottlenecks include:

the customer’s access link;
peering or customer-provider links between autonomous systems;
intercontinental links, which can be expensive to upgrade;
data-center ingress and egress links;
the server, storage system, or memory subsystem rather than the network.

CDNs also reduce the amount of expensive long-distance traffic. Earlier peer-to-peer systems could retrieve content from a distant peer without considering physical location. A CDN instead places popular content near its users.

1.8. Soft QoS and hard QoS

Soft QoS gives one traffic class better treatment than another but does not provide a strict end-to-end guarantee. Its effect is relative: a preferred class will normally experience lower delay or fewer drops than a lower class.

Hard QoS reserves resources and attempts to provide an explicitly defined absolute guarantee. Because the resources must actually be available, hard QoS requires admission control and significantly more state and coordination.

A high-occupancy road lane is analogous to soft QoS. Eligible vehicles normally receive better service, but the lane can still become congested. A road reserved exclusively for a specific vehicle or service is closer to hard QoS.

1.9. Principles for providing multiple service classes

1.9.1. Principle 1: Packets must be classified and marked

A router cannot provide different treatment unless it can identify the relevant traffic class. Applications, hosts, or edge routers must therefore classify packets and apply a suitable marking.

Historically, IP included a Type of Service field for this purpose. Modern DiffServ reuses the corresponding part of the IPv4 header and the Traffic Class field in IPv6.

Allowing applications to mark their own packets without verification is unsafe. Every application would have an incentive to request the highest priority. The network must therefore validate, overwrite, or police markings at a trusted boundary.

1.9.2. Principle 2: Classes must be isolated

A traffic class cannot receive dependable service if another class can inject an unlimited amount of traffic.

Suppose a customer declares a one-megabit-per-second voice flow but actually sends ten megabits per second. Without policing, this flow can consume the resources intended for other customers. The network must check whether traffic conforms to the declared profile.

Classification and policing are preferably performed near the network edge. Edge links operate at lower rates, and the provider still knows which user or customer generated the traffic. Core routers can then process a small number of aggregates instead of inspecting every individual flow.

1.9.3. Principle 3: Isolation should not waste unused resources

Giving a class a permanently fixed, non-shareable portion of a link provides isolation but may waste capacity whenever that class is idle.

A useful design should preserve the preferred class’s protection while allowing other traffic to use otherwise idle bandwidth. Scheduling mechanisms such as weighted fair queueing provide this form of statistical sharing.

1.9.4. Principle 4: Absolute guarantees require admission control

A network cannot promise more capacity than a link possesses. Once the sum of accepted reservations reaches the available capacity, further requests must be rejected or offered a weaker service.

When capacity is limited, the network must decide which reservation requests to accept. This is not only a technical capacity check: it must also choose whether to favor requests that use fewer resources, pay more, last longer, or are considered more important.

1.10. Queues, head-of-line delay, and bufferbloat

With one FIFO queue, a delay-sensitive packet can become stuck behind a long sequence of bulk-transfer packets. This is a form of head-of-line delay.

Very large buffers can make the problem worse. A bulk TCP flow may fill the buffer, after which an interactive voice or gaming packet must wait for the entire queued backlog. This phenomenon is commonly called bufferbloat.

Separate queues make it possible to keep the delay-sensitive queue short even when a lower-priority queue is full. Loss in the lower-priority queue then does not necessarily cause loss in the higher-priority queue.

Port-based classification has historically been common in home routers. A router can, for example, place traffic associated with selected application ports into a preferred queue. However, port-based classification is imperfect because applications can use arbitrary ports and much modern traffic is encrypted or multiplexed.

1.11. Packet-scheduling mechanisms

Packet scheduling selects the next queued packet to transmit on an outgoing link.

1.11.1. FIFO

First In, First Out sends packets in arrival order. If the buffer becomes full, the arriving packet is normally dropped, although another discard policy may choose a packet already in the queue.

FIFO is simple, but it provides no isolation between applications or traffic classes.

1.11.2. Strict-priority scheduling

Packets are divided into priority queues. The scheduler always transmits from the highest-priority non-empty queue.

This can give control or voice packets very low delay. However, a continuously busy high-priority queue can starve every lower-priority queue. Strict priority must therefore be combined with rate limits or careful provisioning.

1.11.3. Round-robin scheduling

The scheduler visits each non-empty queue in turn.

A simple packet-by-packet round robin does not necessarily divide bandwidth fairly because packet sizes can differ. A class sending large packets receives more transmitted bytes per turn than a class sending small packets.

1.11.4. Weighted fair queueing

Weighted Fair Queueing, or WFQ, generalizes round robin by giving classes different weighted shares of the link.

If all classes are active, class \(i\) receives approximately

\[ R_i = \frac{w_i}{\sum_j w_j}R, \]

where \(R\) is the link rate and \(w_i\) is the class’s weight.

If one class is idle, the other classes can use the unused capacity. WFQ therefore combines isolation with efficient sharing.

Different classes may also use different buffer sizes. A delay-sensitive class can have a small queue, while a bulk-transfer class can tolerate a larger queue.

1.12. Traffic policing and shaping

Traffic profiles commonly specify three properties:

Property	Meaning
Average rate	The permitted long-term transmission rate
Peak rate	The largest permitted short-term transmission rate
Maximum burst	The largest amount that may be transmitted consecutively

The averaging interval matters. A limit of 100 packets per second is not identical in behavior to a limit of 6000 packets per minute, even though their long-term averages are equal.

Policing detects non-conforming traffic and normally drops it or changes its marking.

Shaping delays traffic in a queue until it conforms to the traffic profile.

1.13. Token-bucket mechanism

A token bucket permits controlled bursts while limiting the long-term rate.

The bucket stores at most \(b\) tokens. Tokens are generated at rate \(r\) tokens per second. Transmitting a packet, or a certain number of bytes, requires consuming tokens.

When the source has been idle, tokens accumulate, allowing a burst of up to \(b\). After those tokens are consumed, the sustainable rate is limited by \(r\).

Over any interval of length \(t\), the admitted traffic is bounded by

\[ A(t) \leq rt+b. \]

The token bucket therefore limits both the average rate and the maximum accumulated burst while still allowing normal bursty Internet traffic.

In the simplified model used in the lecture, a token-bucket flow with maximum burst \(b\), served by WFQ at a guaranteed rate \(R\), has a queueing-delay bound of approximately

\[ D_{\max}=\frac{b}{R}, \]

provided that the long-term arrival rate is no greater than the allocated service rate.

1.14. Differentiated Services

1.14.1. Basic idea

Differentiated Services, or DiffServ, provides a small number of qualitative service classes, such as an ordinary, preferred, and highly preferred class.

DiffServ deliberately avoids maintaining per-flow state in every core router. More complicated processing occurs at the network edge, while the core handles only a small number of aggregates.

DiffServ specifies mechanisms from which an operator can construct service classes. A particular marking does not automatically have an identical commercial meaning in every autonomous system.

1.14.2. Edge-router functions

An ingress edge router may:

classify packets by user, address, port, application, or contract;
meter traffic against a profile;
mark packets by service class;
distinguish in-profile from out-of-profile traffic;
shape, re-mark, or drop non-conforming packets.

The edge is also the appropriate place to prevent a customer from simply marking all traffic as high priority.

1.14.3. Core-router functions

Core routers perform per-class rather than per-flow processing. Their queueing, buffer allocation, scheduling, and dropping behavior depends on the marking assigned at the edge.

An in-profile packet may receive preference over an out-of-profile packet. However, this remains a relative treatment rather than an absolute end-to-end guarantee.

1.14.4. DS field

The differentiated-services field contains:

Bits	Purpose
6	Differentiated Services Code Point (`DSCP`)
2	Explicit Congestion Notification (`ECN`)

The DSCP selects the packet’s per-hop behavior inside a DiffServ domain.

1.14.5. Advantages

DiffServ is relatively lightweight. Core routers maintain no state for every TCP or UDP flow, and no end-to-end reservation protocol is required.

It is practical to deploy inside one administrative domain. Operators can use it to isolate traffic for residential customers, business customers, managed video, voice, VPNs, internal services, and routing protocols on one physical infrastructure.

1.14.6. Limitations

DiffServ provides relative, not absolute, guarantees. A preferred class may still perform badly if it is overloaded.

Classes are coarse. All packets in a class receive similar treatment even though they may belong to unrelated applications or destinations.

End-to-end behavior is difficult to predict when traffic crosses several autonomous systems. One provider’s DSCP policy may not match another provider’s policy, and an intermediate network may ignore or rewrite the marking.

DiffServ also requires security at the trust boundary. Otherwise, users can obtain a service they did not purchase by assigning themselves a preferred DSCP.

2. Lecture 23: QoS Reflections and Real-Time Communication

2.1. From relative service to absolute service

Priority alone cannot guarantee a fixed level of performance, because the preferred class may itself become overloaded. The network must therefore limit the amount of traffic admitted to that class.

An SLA (Service Level Agreement) defines the customer’s permitted traffic profile and the service given to traffic that follows that profile. A bandwidth broker may accept a new SLA only when the network still has enough capacity to honor it.

The SLA should use simple and measurable conditions. Otherwise, neither the customer nor the provider can clearly determine whether the promised service was delivered.

2.2. Integrated Services

2.2.1. Goal

Integrated Services, or IntServ, attempts to provide precise end-to-end guarantees for individual flows.

The model resembles a circuit reservation. Before sending the traffic, an endpoint asks the network to reserve resources along the path. Each router must check whether it can support the requested rate and delay constraints.

If sufficient resources are not available, the new flow is rejected. Thus, IntServ necessarily changes the Internet from a model in which all flows are admitted to one in which some flows may receive a busy response.

2.2.2. Endpoint participation

Applications are assumed to know their own requirements and request suitable resources. This avoids requiring the network to infer whether a flow contains voice, video, medical control data, or a file transfer.

However, applications do not always know their needs accurately. Modern web pages can also contact many servers and open many transport connections. Making a separate reservation for every such flow would be extremely expensive.

2.2.3. Per-flow state

Every router on the path maintains state for each reserved flow. That state records the reservation and affects packet classification, policing, queueing, and scheduling.

This design does not scale well when a core router carries hundreds of thousands or millions of flows.

It also assumes that the path remains sufficiently stable. If routing changes, the reservation exists on the old path rather than automatically appearing on the new path.

2.2.4. Multicast orientation

IntServ was designed when large-scale IP multicast was expected to become a major method of distributing video.

Reservations are receiver-oriented because receivers in one multicast group may have different requirements. One receiver may request a high-rate stream, while another receiver can support only a lower-rate version.

2.3. RSVP

The Resource Reservation Protocol, or RSVP, signals IntServ reservations.

A simplified exchange is:

The sender transmits a PATH message towards the receiver.
Routers record path information as the message passes.
The receiver sends a RESV message towards the sender.
Routers along the return path attempt to install the requested reservation.
If the reservation cannot be supported, the request fails.

RSVP uses soft state. PATH and RESV messages must be refreshed periodically. If refreshes stop, router state eventually expires automatically.

Soft state makes failure recovery easier than permanently installed state, but periodic refresh messages and per-flow state still produce substantial overhead.

2.4. Problems with hard QoS

IntServ can give precise guarantees to accepted flows, but it conflicts with the scalable core of the Internet.

It requires classification, reservation, policing, scheduling, and per-flow state at every participating router. It also requires authentication and accounting because a malicious host could otherwise reserve large amounts of capacity as a denial-of-service attack.

Interdomain deployment is especially difficult. Independent providers must agree on how reservations are requested, priced, authenticated, and enforced.

Hard QoS may be reasonable for a valuable, long-lived session such as a specialized telemedicine connection. Its setup cost is much harder to justify for a short web transfer or a connection lasting only a few seconds.

Consequently, IntServ and RSVP are standardized but are not generally deployed across the public Internet.

2.5. Why extensive Internet QoS was not widely deployed

QoS received considerable research attention when Internet capacity appeared likely to become scarce. However, the large amount of fibre installed around the Internet boom created substantial unused or dark fibre. Lighting this fibre and upgrading links was often cheaper than deploying detailed per-application reservation and billing systems.

Overprovisioning also preserves the simple and robust best-effort model. A good best-effort network with sufficient capacity can be more useful than a complicated QoS network whose configuration is difficult to understand and maintain.

QoS mechanisms nevertheless remain useful for a small number of operational classes. Providers commonly separate routing, management, business, residential, voice, and managed-video traffic. The same mechanisms are also useful for network virtualization, allowing several logical services to share one physical infrastructure.

Radio spectrum is more difficult to expand than fibre capacity. Mobile networks therefore have a stronger motivation to reuse admission control, traffic differentiation, and usage-based charging.

2.6. Network neutrality and operational filtering

Network neutrality expresses the important principle that an operator should not arbitrarily disadvantage a service, viewpoint, company, or user.

At the same time, treating absolutely every packet identically is not always desirable. Control-plane traffic must remain available, and known attack traffic should not be allowed to consume every link.

Remote-triggered blackholing illustrates this tension. During a DDoS attack, an AS can announce a route with a blackhole BGP community. An upstream provider that recognizes the community discards traffic to the attacked address before it consumes downstream capacity. This protects the rest of the network, but the attacked destination itself becomes unreachable.

Filtering spoofed source addresses raises a similar question. An access provider normally knows the address range assigned to its customer and can discard outbound packets claiming unrelated source addresses. This improves security, although it requires operators to enforce traffic policies rather than forwarding everything blindly.

QoS therefore cannot be separated from policy. The same classification mechanism that protects a routing protocol or blocks an attack can also be misused to throttle competitors or restrict political information.

2.7. Business and deployment considerations

A technical mechanism is unlikely to be deployed unless someone is willing to pay for it and the benefit is easy to explain.

Micropayments for individual web objects or packets are unattractive because users do not want to make a pricing decision for every transfer. A simple monthly service tier is easier to market.

The lecture used low-latency DSL service for gamers as an example. Traditional DSL interleaving and error correction add robustness but also add delay. Disabling or reducing this protection can lower latency, allowing an ISP to sell a more attractive gaming service even though the line may technically have less error protection.

Operational complexity is also important. Every new queue, classifier, SLA, and exception creates opportunities for configuration mistakes. Networks should ideally be generated from a verified configuration database or source of truth, rather than treating the uncoordinated configuration currently installed on routers as the only authoritative record.

Backward compatibility further slows architectural change. Even a theoretically better design may fail if it requires every application, router, operator, and customer to change simultaneously.

2.8. Verifying an SLA

A speed test does not by itself prove that an access provider is violating a rate promise.

If the path to the test server contains a slower bottleneck after the access network, the measured throughput will remain below the access rate even when the access link is functioning correctly. Speed-test providers reduce this problem by deploying servers in many nearby CDN locations, but the measurement is still an end-to-end result.

Availability promises must also be interpreted carefully. For example, 95% annual uptime permits approximately 5% downtime, or about 18 days per year. A network can satisfy an aggregate statistical promise while a particular user experiences an inconvenient concentration of failures.

For these reasons, useful SLAs should be simple, measurable, and explicit about where and how a property is evaluated.

2.9. Practical comparison of service models

Model	Traffic treatment	Guarantee	Router complexity	Deployment
Best effort	Normally one common service	None	Low	Universal
DiffServ	A small number of classes	Relative or soft	Medium	Common within individual networks
IntServ	Per-flow reservation	Precise for admitted flows	High	Rare on the public Internet

Best effort remains dominant because it is simple, interoperable, and usually works well when capacity is sufficient. DiffServ is useful where one operator controls the complete domain. IntServ offers stronger semantics but normally does not scale to the public Internet.

2.10. Real-time conversational applications

The second part of Lecture 23 moves from network-layer service differentiation to application-layer protocols for interactive voice and video.

The protocols have different responsibilities:

Protocol	Main responsibility
SIP	Locating users and establishing, modifying, or terminating sessions
SDP	Describing the media, addresses, ports, and codecs for a session
RTP	Carrying timestamped audio or video packets
RTCP	Reporting reception quality and synchronizing media streams
WebRTC	Enabling secure real-time communication between web applications

An important distinction is that session control, media transport, and quality feedback are separate functions. SIP does not carry the audio itself, RTP does not establish the call, and RTCP does not reserve network bandwidth.

2.11. Session Initiation Protocol

2.11.1. Motivation

The long-term vision of SIP is that voice and video calls operate over the Internet without requiring users to know a current phone number, IP address, or device.

A user can be identified by a stable URI such as:

sip:bob@domain.com

The system then locates the device on which Bob is currently reachable. Location can change because the user moves, receives a new DHCP address, uses several devices, or applies different availability policies at different times.

SIP is standardized primarily in RFC 3261.

2.11.2. SIP services

SIP supports several related operations:

locating the current endpoint of a named user;
notifying a callee of an incoming session;
negotiating the media type, codec, address, and port;
accepting or rejecting the session;
modifying the media during a session;
inviting additional participants;
transferring or holding a call;
terminating the session.

SIP is therefore a signaling protocol. The negotiated audio or video is normally carried separately by RTP or another media protocol.

2.11.3. Calling a known IP address

When Alice already knows Bob’s IP address, a simplified call setup is:

Alice sends Bob a SIP INVITE.
The message body contains an SDP description of Alice’s media parameters.
Bob returns 200 OK with his own address, port, and chosen media format.
Alice sends an ACK.
Audio or video then flows between the negotiated media ports.
A later SIP BYE request can terminate the session.

For example, Alice’s SDP may contain:

c=IN IP4 167.180.112.24
m=audio 38060 RTP/AVP 0

The c= line gives the connection address. The m= line identifies an audio stream, its UDP port, the RTP profile, and the payload-type value.

Bob’s response may choose another port or codec. The two directions of a call do not necessarily have to use identical encoding parameters.

SIP messages may be sent over UDP or TCP. The traditional default SIP port is 5060.

2.11.4. Codec negotiation and rejection

If Bob does not support the codec proposed by Alice, he can return a 606 Not Acceptable response and list acceptable formats. Alice can then send a new INVITE containing a mutually supported codec.

A callee may also reject or redirect a call using responses such as busy, forbidden, gone, or payment required.

SIP deliberately uses an HTTP-like textual syntax and status-code structure, although it is an independent protocol.

2.11.5. SIP message structure

A SIP request can contain fields such as:

INVITE sip:bob@domain.com SIP/2.0
Via: SIP/2.0/UDP 167.180.112.24
From: sip:alice@hereway.com
To: sip:bob@domain.com
Call-ID: a2e3a@pigeon.hereway.com
Content-Type: application/sdp
Content-Length: 885

The Via field records the signaling transport and return path. From and To identify the parties. Call-ID uniquely identifies the call, and the message body contains the SDP session description.

SIP and SDP have roles comparable to a protocol plus a description format: SIP transports signaling messages, while SDP describes the proposed media session.

2.12. SIP registrars and proxies

2.12.1. Registrar

A SIP registrar maintains a temporary mapping from a user’s stable SIP URI to the user’s current contact address.

When Bob starts his client, it sends a REGISTER request such as:

REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/UDP 193.64.210.89
From: sip:bob@domain.com
To: sip:bob@domain.com
Expires: 3600

The registration is soft state. Its Expires value requires the client to refresh the mapping periodically. If the client disappears without explicitly deregistering, the stale mapping eventually expires.

The selected contact may depend on time of day, the identity of the caller, the user’s current device, or whether the user is already busy.

2.12.2. Proxy

A SIP proxy forwards signaling messages towards the callee. Alice normally sends the INVITE to her local proxy rather than directly discovering every remote server herself.

The proxy may consult DNS, a registrar, another proxy, or a redirect response. Replies generally return through the signaling path, after which the media can flow directly between the two endpoints.

2.12.3. Example proxy chain

In the lecture example, Alice at MPI calls Bob:

Alice sends an INVITE to the MPI SIP proxy.
The MPI proxy contacts the server associated with Bob’s earlier domain.
That server redirects the request to bob@trinity.edu.
The MPI proxy contacts the Trinity SIP proxy or registrar.
Trinity’s registrar maps Bob’s URI to his current IP address.
The INVITE reaches Bob’s client.
Bob’s SIP response returns to Alice through the proxies.
After negotiation, the voice data flows directly between the clients.

This resembles DNS and Mobile IP in that a stable name is mapped to a changing network location. However, SIP’s registrar also stores application-specific availability and contact information.

2.13. Real-Time Transport Protocol

2.13.1. Purpose

RTP defines a common packet format for audio and video carried over a packet network. Its purpose is interoperability: two implementations that understand the same RTP profile and media format can interpret each other’s packet metadata.

RTP runs in end systems and is normally carried inside UDP datagrams. It adds several functions not supplied by bare UDP:

payload-type identification;
sequence numbering;
media timestamps;
source identification.

RTP is standardized primarily in RFC 3550.

2.13.2. Why RTP normally uses UDP

For interactive media, a packet that arrives too late may be useless. Waiting for TCP retransmission can delay later data through head-of-line blocking and may be worse than concealing the missing audio or video.

UDP allows the application to decide how to react to loss and how long to wait for a packet.

However, RTP itself does not provide congestion control. A complete modern real-time application must adapt its sending rate using feedback or another congestion-control mechanism.

The lecture contrasted RTP with QUIC. QUIC also runs over UDP, but it includes congestion control and supports several logical streams within one connection. RTP is a narrower mechanism focused on media packet metadata.

2.13.3. PCM audio example

Consider 64-kbit/s PCM audio sampled at 8 kHz. One encoded sample occupies one byte.

If the application collects 20 ms of audio before creating a packet, each RTP payload contains:

\[ 8000\ \text{samples/s} \times 0.020\ \text{s} =160\ \text{samples}, \]

or 160 bytes.

The sender adds an RTP header, places the resulting RTP packet into a UDP datagram, and sends it to the receiver.

Collecting more samples per packet reduces header overhead but increases packetization delay and increases the amount of audio lost when one packet is lost.

2.14. RTP header fields

2.14.1. Payload type

The seven-bit payload-type field identifies the encoding used by the packet. It allows a sender to change encoding during a session, provided that the receiver understands the new payload type.

Examples used in the lecture include:

Payload type	Encoding
0	G.711 PCM \(\mu\)-law
3	GSM 06.10
7	LPC
26	Motion JPEG
31	H.261 video
33	MPEG-2 video

The payload type identifies the encoding; it does not by itself reserve bandwidth for that encoding.

2.14.2. Sequence number

The 16-bit sequence number increases by one for every RTP packet.

It allows the receiver to detect missing packets and restore the correct packet order. It does not cause RTP itself to retransmit a missing packet.

2.14.3. Timestamp

The 32-bit timestamp records the sampling instant corresponding to the first media sample in the packet.

For 8-kHz audio, the RTP clock advances once every 125 microseconds. If each packet contains 160 samples, consecutive active packets normally have timestamps that differ by 160.

The timestamp clock continues to progress at its defined rate even while a source is silent. It represents media time rather than packet arrival time or ordinary wall-clock time.

2.14.4. SSRC

The 32-bit Synchronization Source Identifier, or SSRC, identifies the source of an RTP stream. Separate streams in the same RTP session, such as one audio stream and one video stream, have distinct SSRC values.

2.15. Jitter, reordering, and playout buffering

Packets may arrive in a different order from the one in which they were sent, and their delays may vary.

Playing packets immediately in arrival order could therefore produce incorrectly ordered or irregular audio. The receiver normally stores arriving packets in a playout buffer. Sequence numbers restore packet order, while RTP timestamps determine the intended timing.

The buffer deliberately delays playback to give late or reordered packets time to arrive. A larger buffer tolerates more jitter but increases conversational delay. The receiver must therefore balance smooth playout against interactivity.

RTP does not eliminate loss, delay, or jitter. It supplies the metadata needed for the receiver to handle those effects.

The word “real-time” in RTP does not mean that the network provides a real-time QoS guarantee.

2.16. Real-Time Control Protocol

2.16.1. Purpose

RTCP operates alongside RTP. Participants periodically exchange control reports containing reception and transmission statistics.

RTCP does not carry the main media and does not reserve network resources. Its feedback allows an application to observe performance and adapt its behavior.

For example, a sender that observes substantial loss or jitter may:

select a lower-rate codec;
reduce video resolution or frame rate;
add more forward-error correction;
change packetization or recovery behavior.

Call transfer, participant invitation, and session establishment remain SIP functions rather than RTCP functions.

2.16.2. RTP and RTCP sessions

RTP and RTCP packets in one session usually use the same destination address but different UDP ports.

RTCP was designed with multicast conferences in mind. Every participant may send reports to the other members of the session. Because unrestricted feedback from thousands of receivers would create a feedback implosion, the reporting rate decreases as the group becomes larger.

The same mechanisms can also be used in unicast sessions.

2.16.3. RTCP packet types

Receiver reports
A receiver report contains information such as:
- the fraction of RTP packets lost;
- the highest sequence number received;
- interarrival jitter.
These are aggregate observations rather than an acknowledgement of every individual packet.
Sender reports
A sender report contains:
- the SSRC of the RTP stream;
- the number of packets sent;
- the number of payload bytes sent;
- an RTP timestamp;
- the corresponding wall-clock or NTP time.
Packet and byte counts help receivers interpret loss statistics even when entire groups of packets are missing.
Source-description packets

Source-description packets map an SSRC to information about the associated user or host. They allow participants to associate a numerical stream identifier with a human-readable identity.

2.17. Synchronizing audio and video

Audio and video are normally transmitted as separate RTP streams with different sampling clocks.

An audio RTP timestamp may count audio samples, while a video timestamp follows a video clock. The two RTP timestamp values cannot be compared directly, and neither is inherently tied to wall-clock time.

An RTCP sender report associates an RTP timestamp with an NTP or wall-clock timestamp. A receiver can use these mappings to determine which audio samples belong with which video frame and can therefore maintain lip synchronization.

2.18. RTCP bandwidth scaling

RTCP attempts to keep its traffic at approximately 5% of the session bandwidth.

In the lecture’s example, a sender transmits video at 2 Mbit/s. RTCP therefore uses approximately:

\[ 0.05 \times 2\ \text{Mbit/s}=100\ \text{kbit/s}. \]

Approximately 25% of this RTCP budget is allocated to senders and 75% to receivers. With one sender and \(R\) receivers:

\[ \text{sender budget}=25\ \text{kbit/s}, \]

and each receiver obtains approximately

\[ \frac{75}{R}\ \text{kbit/s}. \]

A participant uses its allocated rate and the average RTCP packet size to calculate how often it should send a report. As the number of receivers grows, each receiver sends reports less frequently.

2.19. Practical use of RTP and RTCP

RTP and RTCP remain relevant, but not every multimedia service uses the standard protocols directly.

Managed IPTV and many open-source conferencing systems may use RTP-based protocols. Large platforms such as Zoom may use proprietary extensions or protocols inspired by RTP and RTCP. Ordinary HTTP-based video delivery, such as much YouTube traffic, follows a different model because it is usually buffered streaming rather than a low-delay conversational session.

2.20. WebRTC

2.20.1. Purpose

The Web originally focused on retrieving and displaying documents. Modern web applications also need interactive voice, video, and data communication.

WebRTC provides browser APIs and protocols for establishing secure real-time communication between endpoints. When possible, media flows directly between the browsers rather than through the web server that delivered the application.

2.20.2. Signaling is deliberately unspecified

Traditional Internet telephony often uses SIP to exchange SDP objects and set up an RTP session.

WebRTC does not require one specific signaling protocol. Each application can transport session descriptions and ICE information using its own mechanism, such as:

an HTTP REST interface;
WebSockets;
SOAP;
another RPC or messaging protocol.

WebRTC only requires the necessary information to reach the remote peer. It does not specify how the application finds the peer, authenticates the user, or delivers the signaling messages.

2.20.3. ICE and NAT traversal

Direct browser-to-browser communication is difficult because one or both peers are usually behind NATs or firewalls.

Interactive Connectivity Establishment, or ICE, collects possible ways of reaching each peer. These are called ICE candidates.

Candidates can include:

Candidate type	Meaning
Host candidate	A local interface address
Server-reflexive candidate	A public NAT mapping discovered with STUN
Relay candidate	An address allocated by a TURN relay

STUN helps a peer discover how its address and port appear outside its NAT.

TURN relays traffic when a direct path cannot be established.

The peers exchange their candidate lists through the application’s signaling channel. ICE then tests candidate pairs and selects a working path. A direct peer-to-peer path is preferred, but communication may pass through a TURN relay when necessary.

2.20.4. WebRTC security

WebRTC media is protected using Secure RTP, or SRTP.

The peers use Datagram Transport Layer Security, or DTLS, over UDP to authenticate the connection and establish keying material. Those keys are then used to protect the SRTP media stream. This arrangement is commonly described as DTLS-SRTP.

2.21. End-to-end WebRTC establishment

A simplified WebRTC session proceeds as follows:

The application establishes an arbitrary signaling channel between the users.
The browsers create and exchange session descriptions.
Each browser gathers ICE candidates using local interfaces, STUN, and possibly TURN.
Candidate lists are exchanged through the signaling channel.
ICE connectivity checks select a working candidate pair.
The peers perform a DTLS handshake.
Audio and video are carried using SRTP.
RTP and RTCP mechanisms provide media sequencing, timing, feedback, and synchronization.

The signaling server is needed to introduce the peers, but it does not necessarily carry the resulting media.

2.22. Relationship among the real-time protocols

SIP, RTP, RTCP, and WebRTC solve complementary rather than competing problems.

SIP answers: “Whom am I calling, where are they now, and what media parameters will we use?”

SDP answers: “What address, port, codec, and media streams are being proposed?”

RTP answers: “What media data is in this packet, where does it belong in the sequence, and when should it be played?”

RTCP answers: “How well is the session performing, and how can separate media streams be synchronized?”

WebRTC answers: “How can a web application securely establish such a real-time session through NATs and firewalls without requiring one fixed signaling system?”

SIP establishes and manages sessions, RTP carries the media, RTCP reports and synchronizes the media, and WebRTC combines these ideas into a secure browser-based communication framework.