Chapter 6

Content Delivery Networks

(CDNs) and Over-the-top
content (OTT)
 Chapter 6 outline

• Introduction
• Content Delivery Networks
• Over-the-top content

2
Content distribution networks
(CDNs)
Content replication Origin server
• Challenging to stream large files in North America
(e.g., video) from single origin
server in real time
• Solution: replicate content at
hundreds of servers throughout
CDN distribution node
Internet
– content downloaded to CDN
servers ahead of time
– placing content “close” to
user avoids impairments
(loss, delay) of sending
content over long paths
– CDN server typically in CDN server
CDN server
edge/access network in S. America CDN server
in Asia
in Europe

1: Introduction 1-3
Content distribution networks
(CDNs)
Origin server
Content replication
in North America
• CDN (e.g., Akamai)
customer is the content
provider (e.g., as.com)
• CDN replicates customers’
CDN distribution node
content in CDN servers.
• when provider updates
content, CDN updates
servers

CDN server
CDN server
in S. America CDN server
in Asia
in Europe

1: Introduction 1-4
Content distribution networks
Use Cases
• Accelerate Web performance
– Content caching  reduction of load time
• Ease software updates and downloads
– Distribute software patches and updates (e.g.
mobile OS updates)
• Distribute end-to-end online video
– e.g. Netflix, Youtube

5
 CDNs Types

• Pure-play CDN
– ISPs not involved in control and distribution
– Delivery of audio/video “over-the-top” (OTT)
• Use of ISP infrastructure
– e.g. Akamai
• Own infrastructure
– e.g. Limelight, Level 3
• Carrier/Telco CDN:
– Implemented by ISPs
– Reduce the load of the “core” networks and
delay
– Verizon, AT&T, Telefónica
6
 CDNs Types (II)

• Managed CDN
– Pure-play CDNs help carriers to build and
manage CDN component in carrier’s network
– CDN managed by CDN provider
– e.g. Limelight Deploy
• Licensed CDN
– Pure-play CDNs provide software for integration,
testing and deployment on the carrier’s
infrastructure
– CDN managed by network operator
– E.g Aura Managed CDN (Akamai), EdgeCast
7
 CDNs Types (III)

• Federated CDN
– Interconnection of multiple CDNs
– Compete against pure-play CDNs
– e.g. Cisco and Highwinds federated CDNs

8
 CDN Composition

• Organization • Interaction
– Overlay-based protocols
– network approach – Network elements
• Servers (origin and and inter-cache
replication) • Content/services
• Relationship: type
– Client-to-edge-to- – Static
origin – Streaming
– Network element-to- – Dynamic
caching proxy
– Interproxy
9
 CDN Relationships:
Client-to-surrogate-to-origin
Origin Origin Origin
Server Server Server

Surrogates

Clients

10
 CDN Relationships:
Network-to-caching-proxy
Caching Proxy Array 1 Caching Proxy Array 2

Caching Master Caching Caching Master Caching

Proxy A Proxy B Proxy A Proxy B

Network elements

Clients

11
CDN Relationships:
Inter-proxy (Array)

Caching Proxy Array

Caching Master Caching

Proxy A Proxy B

Clients

12
CDN Relationships:
Inter-proxy (Mesh)

Caching Caching
Proxy Proxy

Cache Local Clients

Server caching
proxy
Caching Caching
Proxy Proxy

13
CDN Request Routing (rfc3568)

• Request Routing algorithms

– Adaptive vs non-adaptive
• Mechanisms
– DNS
• NS and CNAME redirect
• DNS only allows resolution at domain level  Ideally
per object/content request routing
– Transport layer (based on IPs/ports)
– Application layer:
• HTTP redirection (based on cookie, user-agent, client
IP)
• URL rewriting using centralized directory
14
DNS-based Request Routing
www.example.com www.example.com www.example.com

www.node3.example.com www.node3.example.com
User IP3 DNS Server IP3 CDN DNS
Server
IP3
connection

CDN Network
Node 1 Node 2 Node 3
15
 DNS-based Request Routing

• How to select CDN node?

– Reduce server load:
• Round Robin
• Least connections
– Select server with least active connections
– Improves server response time
– Reduce latency:
• Round Trip Time
– Map client IP to RTT to each CDN server
– Select lower RTT
• Geographically
– Geolocalize client IP
– Route request to CDN nearest node
16
 Header-Based Request Routing
www.example.com www.example.com

www.example.com
IP DNS Server
User
HTTP
connection Web Server

HTTP
HTTP Redirect
connection

CDN Network
Node 1 Node 2 Node 3
17
 URL-Rewrite Request Routing
www.example.com www.example.com

www.example.com
IP DNS Server
User
HTTP
connection Web Server
www.example.com/image.png

GET image.png Rewritten Web

Host:
node1.example.com

www.node1.example.com/image.png

CDN Network
Node 1 Node 2 Node 3
18
 CDN Distribution and
Management
• Content selection • Content-sourcing
and delivery – Push-based
– Empirical • Cooperative
– Popularity – Pull-based
• Cooperative
• Replica placement • Non-cooperative
– Single vs Multi-ISP
• Cache management
– Hot-spot
– Intra and inter-
– Tree-based
cluster
– On-demand
– Propagation and
invalidation 19
 Cooperative Push-based CDNs

• Customers upload content to CDN

• CDN redistributes content across the
servers
• Flexibility
– User specifies:
• What content must be uploaded
• Expiration time
• Update time
• Bandwidth saving
– Content is only uploaded when it is new or must
be updated
20
 Cooperative Push-based CDNs
Customer New New
Content Content

Origin Server Content-Replication

CDN Network

21
 Non Cooperative Pull-based
CDNs
• Client requests are directed to their closest
surrogate servers.
• If there is a cache miss, surrogate servers
pull content from the origin server.
• e.g. Akamai, Mirror Image
• Drawback  optimal server not always
selected

22
Non-Cooperative Pull-based
CDNs
Pull
Content

Origin Server
Query
Content

Cache
Miss
Client
CDN Network

23
 Cooperative Pull-based CDNs

• Client requests are directed to their closest

surrogate servers.
• If there is a cache miss, surrogate servers
try to pull content from other surrogate
servers.
• Use of distributed indexes to find nearby
copies of content.
• e.g. Coral (Academic CDN)

24
Cooperative Pull-based CDNs

Pull
Content

Origin Server
Query
Content

Cache
Miss
Client
CDN Network

25
 Cache Organization and
Managment
• Content management is essential for CDNs
– Minimize latency
– Increase hit-ratio

• How to organize the content?

– Caching techniques
– Cache update frequency
– Content Replication
• Failover and high availability

26
 Cache Organization and
Managment
• Caching techniques:
– Intra-cluster:
• Query-based
• Digest-based
• Directory-based
• Hashing-based
• Semi-Hashing-based

– Inter-cluster
• Query-based

27
 Query-based scheme

Cache
Miss
Cache
Miss

Query Miss
Broadcast reply
Content

Miss
reply
Query
Content

Cache
Miss
Client

28
 Query-based scheme

• Problems:
– Increment in bandwidth usage
• Extra traffic broadcasted to cooperating servers
– Increments in latency
• First server must wait until the last «miss reply» is
received to conclude that content is not avialable
– Implementation Overhead

29
 Digest-based scheme (Query)
S1 S2 S3

Query
Content 4
Content 4

Query
Digest
Content 4
Content 1  S2
Content 2  S2
Content 3  S1 Cache Content 4
Content 4  S3 Miss
Client

30
 Digest-based scheme (Update)
S1 S2 S3

New content 5

Content-update
broadcast

Digest
Content 1  S2
S4 Content 2  S2
Content 3  S1
Content 4  S3
Content 5  S1

31
 Digest-based scheme

• Solves query-based broadcast traffic

• First server can route content request to
other surrogate server instead of fetching
the content
• Problems:
– Digest update traffic overhead

32
 Directory-based scheme
(Query)

S1 S2 S3

Directory

Content 4 Query
search Content 4
Content 4

Query
Server S3
Digest Content 4
Content 1  S2
Content 2  S2 Cache Content 4
Content 3  S1 Miss
Client
Content 4  S3

33
 Directory-based scheme
(Update)
S1 S2 S3

New content 5

Content-update

Digest
Content 1  S2
Directory Content 2  S2
Content 3  S1
Content 4  S3
Content 5  S1

34
 Directory-based scheme

• Centralized version of Digest-based

approach
• One central server per cluster
• Updates are only notified to central server
• Problems:
– Single point of failure
– Bottleneck
• Queries and updates are received by directory

35
 Hash-based scheme (Query)
S1 S2 S3

Query Content 4
Content 4
(request route)

Query
hash(content
Content 4
name) = S3

Cache
Miss
Client

36
 Hash-based scheme (Update)
S1 S2 S3

New content 5

Hash(IP server
+content_name) Content placement
=S3

S4

37
 Hash-based scheme

• CDN servers use the same hashing

function:
– Content Name
– IP addresses of servers
• All request for a particular content are
directed to a specific server:
– Small implementation overhead
– High content sharing efficiency
• Problems with multimedia content
– Content served by other server (possible latency
increment)
38
 Semi-Hash-based scheme

• Each CDN server allocates 2 disk spaces:

– Cache most popular contents for its local users
– Cooperate with other CDN servers via hashing
scheme
• Increment local hit ratio
• Useful for multimedia content

39
 Caching schemes (additional
considerations)
• Hash-based scheme not appropriate for
inter-cluster caching
– Representative CDN servers of clusters are
geographically distributed
• Digest-based and directory-based not
suitable for inter-cluster:
– Servers have to maintain huge content digest
including information of servers in other clusters
• Query-based is the only scheme suitable for
inter-cluster caching.
40
Caching schemes (Big picture)

Cluster 1 Cluster 2
(intra-cluster hash/semi- (intra-cluster hash/semi-
hash) hash)

Inter-cluster Query-based caching

Cluster 3
(intra-cluster hash/semi-
hash)

41
 Cache update

• Contents must have expiration times

– Provide up to date information
– Avoid inconsistency between contents
• Update mechanisms:
– Periodic
– Propagation
– On-demand
– Invalidation
• Update mechanisms typically selected y
content provider
42
 Periodic update

• Time-driven approach
• Origin server marks :
– Which contents are cacheable
– How long each content is considered “fresh”
– When to check back for updated content
• Unnecessary update traffic when content
changes are minimal

43
 Propagation update

• Triggered with a change in the content

• Active content pushing to CDN servers
• “Broadcast copy”
• Excessive traffic when content changes are
frequent

44
 On-demand update

• Most recent copy of a content is copied to

the surrogate cache server based on prior
request for that content.
– Content is not updated unless it is requested
• Back-and-forth traffic between the cache
and the origin server to ensure that the
delivered content is up to date.

45
 Invalidation update

• Invalidation message sent to surrogates

when content changes at the origin server
– Cache access at surrogates forbidden while
updating contents
– Each cache fetches the updated content later
• Misuse of the full distribution network
• Inefficiency in the consistency management
when fetching delayed content

46
CDN Performance Measurement

• Internal and external measurements:

– Measure geographical proximity
– Latency, packet loss
– Downtime
– Server load
• Two approaches:
– Traffic monitoring
– Network probing

47
 CDN Traffic Monitoring

• Traffic between clients and surrogate

servers are monitored to obtain
performance metrics
• Feedback to request-routing systems
• Examples:
– Packet loss
– Latency/RTT (TCP)
– Distance estimation  IDMaps
• Performed periodically with day or hours
granularity
48
 CDN Network Probing

• Active measurement technique:

– Test all or a group of surrogate servers to
determine one or more metrics
• Typically used in P2P-based CDNs
• E.g. Periodic ICMP echo messages
– RTT / Availability
• Drawbacks
– Adds latency
– Adds extra traffic
– ICMP traffic often blocked
49
 CDNs Summary

CDN Organization Relationships Content

Akamai Network -C2S2O Static, dynamic,
Overlay -NE2CP Streaming, and
-Inter-proxy services
Edge Network N/A Video streaming,
Stream video hosting
Limeligth Overlay -C2S2O Static content,
Networks -NE2CP streaming media
Mirror Network -C2S2O Static content,
Image Overlay -NE2CP streaming, Web
computing and
reporting
services

50
 CDNs Summary (II)
CDN Surrogate Content Cache
Placement outsourcing
Akamai Multi ISP; Non-cooperative Intra and inter-cluster
Hotspot pull-based • Update
• Propagation
• On-demand

Edge Single ISP Non-cooperative Inter-cluster

Stream pull-based
Limeligth Multi-ISP Non-cooperative Intra-cluster
Networks pull-based Update:
• On-demand

Mirror Image Muti-ISP; Non-cooperative Intra-cluster

Superstore pull-based Update:
• On-demand
51
 CDNs Summary (III)
CDN Performance Measurement
Akamai Internal Measurement:
• Probing
• Monitoring (proactive)
External Measurement:
• Third-party

Edge Internal Measurement:

Stream • Monitoring using Real Time
Performance Monitoring Service
(RPMS)
Limeligth N/A
Networks
Mirror Image Internal Measurement:
• Probing
• Monitoring and reporting
52
CDN Netflix Use Case
upload copies of
Amazon cloud
multiple versions of
video to CDNs Akamai CDN

Netflix registration,
accounting servers
3. Manifest file
2. User browses returned for
requested video Limelight
Netflix video 2
3 CDN
1

1. User manages
Netflix account
Level-3
4. Streaming CDN

1: Introduction 1-53
 Over-The-Top Content (OTT)

• Delivery of audio, video or other

multimedia content
– Without ISPs collaboration
– Traffic control performed by third party (not
ISPs) typically at the edges
• Content Application Providers (CAPs)
– “service providers that can potentially substitute
traditional telecommunications and audiovisual
services such as telephony, SMS and television”
– Hulu, Netflix, Youtube, whatsapp

54
 Over-The-Top Content (OTT)

• OTT online content categories:

– TV and Video
• Youtube, Hulo, Netflix
– Music:
• Spotify, iTunes
– Communications:
• Skype, Whatsapp
– Productivity:
• Google Docs, Outlook
– Technology:
• Dropbox, Rackspace, Amazon Cloud

55
Over-The-Top Messaging (OTT)

• Instant message services provided by non

ISP enterprises
• Alternative to traditional SMS
• Use of TCP/IP connections and upper level
protocols
– eXtensible Messaging and Presence Protocol
(XMPP)
– SIP for Instant Messaging and Presence
Leveraging Extensions (SIMPLE)

56
 XMPP

• Open and extensible protocol for instant

messaging
• Based on XML
• Non centralized (similar to SMTP)
• Flexible:
– On-demand functionalities using extensions
• Defined in RFC 3920 and 3921
• Security extensions:
– TLS, SASL

57
 XMPP Architecture

• Decentralized client-server architecture

similar to HTTP or SMTP
• Federation between servers
– Inter-domain connections
– Single hop
• Extensible servers
– Plugins and add-ons

58
 XMPP Architecture

Client 2 Client 5

Server 1 Server 2 Client 6

Federation Server 3
between
servers

Client 3 Client 4 59
 XMPP Addressing

• Based on Jabber ID (JID)

• Similar to email addresses:
– [email protected]
• Use of subdomains to specify dedicated
servers:
– E.g. talk1.l.google.com
• XMPP URI:
– xmpp:user@domain
– Message extension: xmpp:user@domain?
message
60
 XMPP Addressing

• Resources:
– For each connection between client and server a
resource identifier is assigned
– Used for routing traffic to each concurrent
connection
– E.g. user@domain/home
– Each resource is a different PoP (Point-of-
Presence) with its own state and location

61
 XMPP Communications

• Use of XMPP “stanzas”:

– basic unit of communication, similar to a packet
or message in other network protocols
• Conformed by:
– Element Name:
• message
• presence
• IQ
– Type attribute
– Child elements  define the payload of the
stanza
62
 XMPP Message

• <message/>
– Basic push method for getting information from
one place to another
– Messages are typically NOT acknowledged
• Message Types:
– Normal  similar to e-mail
– Chat  real-time messages between 2 users
– Groupchat  multi-chat room
– Headline  alerts and notifications(no response)
– Error  returned when error detected

63
 XMPP Message Example

<message from=“user1@domain/foo"
to=“user2@domain"
type="chat">
<body>Hello World</body>
<subject>Query</subject>
</message>

• Server adds From address to avoid JID

spoofing.

64
 XMPP Presence

• Presence stanzas advertise network

availability of entities and their state
• Presence subscription
– Allow users to view availability
– Based on publish-subscribe methodology
• People subscribe to other people presence and receive
update whenever their state changes
<presence from=“user1@domain/mobile">
<show>xa</show>
<status>Custom state </status>
</presence>
65
 XMPP Presence Example

<presence from=“user1@domain/mobile">
<show>xa</show>
<status>Custom state </status>
</presence>
• Show values
• away  The entity or resource is temporarily away.
• chat  The entity or resource is actively interested in
chatting.
• dnd  The entity or resource is busy (dnd = "Do Not
Disturb").
• xa  The entity or resource is away for an extended
period (xa = "eXtended Away").

66
 XMPP IQ

• Info/Query (IQ) stanza provides structure

for request/response interactions (similar to
GET or POST in HTTP)
• IQ stanza can only include one payload
• Types:
– Get  Ask for information
– Set  Provide information
– Result  result of get or set operation
– Error  server was unable to process get or set
message

67
 XMPP IQ Example
<iq from=“user1@domain/pc"
id="rr82a1z7"
to=“user1@domain" type="get"> <query
xmlns="jabber:iq:roster"/> </iq>

<iq from=“user1@domain" id="rr82a1z7"

to=“use1@domain/pc" type="result">
<query xmlns="jabber:iq:roster">
<item jid=“user2@domain"/>
<item jid=“user3@domain"/>
<item jid=“user4@domain2"/>
</query> </iq>

68
 Jingle
• Jingle is an extension of XMPP to establish audio
and video sessions
• Similar to SIP
– The initiator offers to start a session to the responder
– Responder answers the offer either accepting it or
declining it
• Each offer comprises 2 parts:
– Application Type  what content is going to be
exchanged? E.g. voice via RTP
– Transport Method  How data is sent. E.g. UDP

69
Jingle Session Establishment
Initiator Responder

Offer:Jingle Session Initiate

Acknowledge Offer Receipt

Negotiate application type and

transport method parameters

Accept Offer

Acknowledge Offer Receipt

(IQ-Result)

Media Exchange

Terminate session
70
 Jingle Example
<iq from=“user1@domain/mobile"
id="v73hwcx9" to=“user2@domain/home" type="set">
<jingle xmlns="urn:xmpp:jingle:1"
action="session-initiate"
initiator=“user1@domain/mobile“
sid="a73sjjvkla37jfea">
<content creator="initiator" name="voice">

<description xmlns="urn:xmpp:jingle:apps:rtp:1“ media="audio">

<payload-type id="96" name="speex" clockrate="16000"/>

<payload-type id="97" name="speex" clockrate="8000"/>
<payload-type id="0" name="PCMU"/>
<payload-type id="8" name="PCMA"/>
</description>
<transport xmlns="urn:xmpp:jingle:transports:raw-udp:1">

<candidate candidate="1" generation="0“

id="a9j3mnbtu1“
ip="10.1.1.104“
port="13540"/>
</transport>
</content>
</jingle> 71
</iq>
 XMPP

• XMPP also defines other actions:

– Send binary data
– Transfer large files (out of band)
– Transmission of custom information
• Using forms
– Much more
• Use of XMPP extensions

72
 OTT Video and Audio Services

• Audio and video transfer using browsers is

quite common nowadays
– No need for extra applications
– Simple
– Mobile-friendly
– Easy to deploy new services over exsiting
infrastructure
• Simple solution
– Use of WebRTC

73
 WebRTC

• WebRTC (https://webrtc.org/) is an API

that enables:
– Browser-to-browser applications
• Voice, Video, P2P file-transfer
• Promoted by Google
• No need of extra plugins
• No mandatory signaling protocol
– SIP over WebSockets (rfc7118) is commonly
used

74
 WebRTC

• Components:
– Video Engine
• VP8 (WebM) video codec
• Dynamic Video Jitter Buffer
• Image Enhancements
– Noise reduction
– Voice Engine
• Codecs
– iSAC (variable bitrate 12-52 kbps)
– iLBC (bitrate 15.2 kbps/13.33 kbps)
– Opus (variable bitrate 6-510 kbps(
• Dynamic Audio Jitter Buffer

75
 WebRTC

• Components:
– Transport/Session Modules
• RTP network stack
• STUN/ICE
– NAT session establishment and connectivity
• Session Management:
– Abstract layer for call setup and management
– Protocol implementation dependent on developer

76
 WebSockets (WS)

• Transport protocol over TCP

• Connection handshake based on HTTP
– Client sends an HTTP GET with an "Upgrade"
request.
– Server answers with an HTTP 101 status code if
negotiation succeeded
– WebSocket subprotocol definition (protocol
using the WebSocket)
– After handshake connection changes from HTTP
to WebSocket (socket reuse)

77
 SIP over WebSocket

• Sec-WebSocket-Protocol field value set to

“sip”
• Recommended use of UTF-8 on SIP
messages over WS
• Use of Content-Length header in SIP
messages over WS is not necessary
– WS preserves message boundaries
• Change in SIP Via field:
– Use of WS or WSS (WS Secure) values

78
 SIP over WebSocket
Session Establishment

GET / HTTP/1.1
Host: sip-ws.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://www.example.com
Sec-WebSocket-Protocol: sip
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: sip

79
 SIP over WS
Invite through Proxy
Alice proxy.example.com Bob
SIP WSS SIP UDP

INVITE (1)

100 Trying (2)

INVITE (3)

200 OK (4)
200 OK (5)

ACK (6)
ACK (7)

Bidirectional RTP

80
 SIP WS:Invite through Proxy
1
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
From: sip:[email protected];tag=asdyka899
To: sip:[email protected]
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, gruu
Route: <sip:proxy.example.com:443;transport=ws;lr>
Contact: <sip:[email protected];gr=urn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp
2
SIP/2.0 100 Trying
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
From: sip:[email protected];tag=asdyka899
To: sip:[email protected]
Call-ID: asidkj3ss
CSeq: 1 INVITE
81
 SIP WS:Invite through Proxy
3
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=udp;lr>,
<sip:[email protected]:443;transport=ws;lr>
From: sip:[email protected];tag=asdyka899
To: sip:[email protected]
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Supported: path, outbound, gruu
Contact: <sip:[email protected];gr=urn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp

82
SIP WS: Invite through Proxy
4
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c
;received=192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=udp;lr>,
<sip:[email protected]:443;transport=ws;lr>
From: sip:[email protected];tag=asdyka899
To: sip:[email protected];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060;transport=udp>
Content-Type: application/sdp

83
SIP WS: Invite through Proxy
5
SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=udp;lr>,
<sip:[email protected]:443;transport=ws;lr>
From: sip:[email protected];tag=asdyka899
To: sip:[email protected];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060;transport=udp>
Content-Type: application/sdp
6
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
Route: <sip:[email protected]:443;transport=ws;lr>,
<sip:proxy.example.com;transport=udp;lr>,
From: sip:[email protected];tag=asdyka899
To: sip:[email protected];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70 84
SIP WS: Invite through Proxy
7
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP
proxy.example.com;branch=z9hG4bKhwpoc80zzx
Via: SIP/2.0/WSS
df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
From: sip:[email protected];tag=asdyka899
To: sip:[email protected];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69

85
 OTT: WhatsApp Case Study

• OTT messaging service

• Volume:
– ~500 million of active users
– ~64 billion messages per day
• Use of XMPP
• Non-proprietary infrastructure
• Use of SSL/TLS for both media and
messages

86
 OTT: WhatsApp Case Study

• Servers hosted in Softlayer

– IBM Cloud
– Located at Texas
• Content distribution using DNS naming
scheme:
– [cX,eX,dX].whatsapp.net  chat and control
(XMPP)
– [mmiXYZ,mmsXYZ].whatsapp.net  media
(photo, audio)[HTTPS]
– mmvXYZ.whatsapp.net  video [HTTPS]

87
 OTT: WhatsApp Case Study

• One persistent SSL connection to XMPP

servers (while app is running)
• Dedicated TLS (HTTPS) connections for
audio,video and photo transfer
• Traffic distribution:
– ~25% volume  chat
– ~75% volume  multimedia
– 90% chat flows < 10kB
– 50% chat flows > 70kB
– Flow timeouts depend on operating system
88